My cohort can answer better than me as he's done most of the work
concerning this.....but...we've kind of discovered a few things
about spammers using our Zimbra...
1) The spammers don't waste much time sending single messages,
except while testing which maybe helps our little trap.
2) The spammers automation stuff only seems to work in the
HTML(Standard) client.
So, when we find an outgoing message with an envelope that contains
more than X (I think 50) recipients AND it's been sent from the
HTML(Standard) client, we dump it into a queue and don't deliver
until it's manually reviewed by an administrator.
I'd guess we're catching almost 100% of the outgoing SPAM attempts
now when an account gets compromised. The AJAX client may be too
difficult for them to script around(I'm guessing), and they like to
send to LOTS of recipients. We've only found one or two valid
senders who have been caught so far....and they've either switched
back to the AJAX client or understand why we delay their multi-
recipient messages.
Phishing is one of those issues that separates the regular people
from the idiots....and we seem to have our fair share of the latter
here. Not only do they continue to respond after lots of training
and high profile example cases....but they respond when the message
is delivered TO THE JUNK!! folder...AND...the subject line INCLUDES
some text that reads [Fraud Alert: Suspected SPAM]....
HELLOOO??? The lights are on but no one is home.....I imagine the
thought process goes like this...
....must...fight...urge....but...I...have....no....common...sense...
must...hit..."Reply"
button....and...give...away...my...private...info...
It's cause for much consternation....but we do get a few laughs out
of it sometimes. Maybe immense public ridicule would work? :)
Matt
----- Original Message -----
From: "Tom Golson" <tgolson@tamu.edu>
To: "Steve Hillman" <hillman@sfu.ca>
Cc: "zimbra-hied-admins" <zimbra-hied-admins@sfu.ca>
Sent: Tuesday, January 13, 2009 2:41:10 PM GMT -06:00 US/Canada
Central
Subject: 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..)