[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dealing with compromised Zimbra accounts



It has been our experience that setting the zimbraAccountStatus to
"locked" does kill the current session.  But you're right -- if used as
a "toggle" there's no useful effect.  The mailbox has to remain locked
long enough for the spammer to lose interest.

We use a semi-automated process of monitoring outbound message rates and
triggering alerts.  Since our customers do have the unfortunate habit of
 sending mail to massive lists of people, we try to verify messages as
being "spam" before we take punitive action.

If an account is compromised, one of our admins will trigger a process
to scramble the customer's password, lock their mailbox and send a
notice to our help desk so they can conduct "customer education".  We do
leave the mailbox locked until the customer has been contacted and reset
their password.

Inbound, we make very heavy use of the anti-phishing-mail-reply group
that was spun off from the hied-email-admin list onto Google groups.  It
is an excellent resource.

--Tom

Steve Hillman wrote:
> Hi folks,
>   Now that we've moved all of our students over to our Zimbra implementation, we're starting to see Zimbra accounts get used for spamming (after being successfully phished) -- we've had 3 in the last 3 days.
> 
> We're having to invent new ways of dealing with these -- simply changing the password or locking the account doesn't actually stop the current session. Our session timeout is 12 hours, so this would allow the spammer to keep functioning for quite awhile unless we can kill the session programmatically. 
> 
> I've found that setting the account to 'maintenance' mode will terminate the session *if* the end-user tries to do anything while it's in that state, but it's not enough to just flip the account into maintenance and back out.
> 
> I'm just wondering if any other sites are dealing with this yet, and if so, if you've figured out a semi-automated way of locking and unlocking the accounts?
> 
> (btw, we're also looking at Milters to do password detection (to prevent the phished account in the first place) and outbound rate limiting (to limit the damage the spammer can do), so if any of you are doing/done any work in this area, I'd love to hear about it too..)
>