Account abuse management

[Stephen Opal <sno@merit.edu>]

Hello all,

Our Zimbra infrastructure is deployed across twelve clusters of varying sizes hosting subscribers (we call them Members).  Many of these clusters are dedicated to one Member.  The rest are shared clusters hosting dozens of Members.  Over the last three years, We have worked toward detecting and responding to account theft and service abuse within our ZCS subscription platform.  I'd like to have a conversation regarding our solutions and those you may have employed.

Let me outline some of the tools we use and some I have developed.

- Cisco Ironport

All inbound e-mail traffic goes through our Ironport Cluster and is directed to the proper cluster for delivery.  Some Members also have their MTA set to the Ironport which is reducing our Postfix log visibility for other tools.

- Preference Change Management (custom)

We monitor every mailbox.log for 'Create' and 'Modify' requests.  When a save is performed in an account, the process examines the IP of origin and the identities and signatures for that account.  These values are compared to a set of regular expressions which match historical abuse values.  If a match is found, the account is immediately locked and an email notification is sent to our team and to the Member's tech team.

This service has provided high confidence account securing services, sometimes before any SPAM can be sent out.  Obviously, it can not be perfect since mail can be sent before any preference changes are made.  However, by carefully managing our black-list there is high confidence when it acts.  We have had less than ten false positives over our entire service during its two and a half year period of service.

- Outbound Sender Volume Monitoring (custom)

Tracking the Postfix maillog files on our hosts, we are able to observe pulses of mail.  When a hosted account sends mail, a record of the event retained.  By counting the number of postings within a window of time, we can get a total volume and a count of distinct destination addresses.  When thresholds are reached, notifications with account attribute dumps are sent out to our team for further investigation.  Since this is very nebulous, human interpretation and investigation is usually needed.

- SASL Authentication Tracking (custom)

Some of our MTA hosts are configured to allow SASL auth to Postfix.  We track these authentications and associate the session mail postings by IP and destinations.  With this, we can monitor pulses of volume and sources.  Currently we automatically secure accounts posting with 30 auths and over 500 messages within 10 minutes.  An account is locked if it has authenticated from three or more countries outside the US/CAN within 20 minutes.  Since the data is stored in MySQL, we can generate activity reports with account attributed volume and IP sources for visual inspection to find activity under these thresholds that require a human response.

- Discussion

What we have found is while moving the MTA service off from the Zimbra MTA hosts, we are losing our visibility into the SASL authentication tracking.  SASL auth can be found in zimbra.log, but we no longer can determine the senders mail volume when the From header field is spoofed.  I would prefer not to lose this visibility, but I have no control over this move, so I am looking for strategic options and am willing to accept a mind-set change.

How do you manage breached account detection and response?  Have you found commercial or open-sourced products that help capture and respond to abuse?

--
Stephen Opal <sno@merit.edu>
Systems Programmer/Analyst,  Merit Network, Inc.
734-527-5763