Re: Non Zimbra question and I hope that is ok if this type of thing is not abused.

[Nathan Lager <lagern@lafayette.edu>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We've had similar problems in the past.  Two years ago we had a number
of accounts get compromised.  Enough that we had a heck of a time
getting removed from blacklists and whatnot. Since then, we've taken a
number of steps to try to squash phish, and compromised accounts.

Inbound:
We use an on-site hosted ProofPoint cluster.  Which has some pretty
sophisticated functionality.  It does its best to filter spam, and
phish, and does a pretty good job.  It's also classifies phish and spam
separately.


Outbound:
We have zimbra relaying through the same ProofPoint cluster.  The
proofpoint's customizability really shines here.  I've worked with
Barracuda's in the past, and I'm not certain if they can do this or not,
i know the one i used did not.  The outbound policy checks for
spam/phish, and quarantines if it hits a certain score.  The sender is
notified.  This is all pretty standard stuff.

Where it gets interesting is in some of the advanced features.  We
redirect the quarantined message to a zimbra account that we have setup
just for this purpose.  Then i have a perl script which polls that
e-mail account.  If a certain threshold of messages from a single user
hit that mailbox in a given amount of time, it returns an alert value.
This is then queried by our monitoring system, and our mail team is
alerted via SMS.  This polls every 5 minutes.

We set zimbra's outbound recipient limit to a reasonable maximum, and
drop any e-mail that reaches that limit (phishers/spammers commonly pack
as many recipients into an e-mail as possible).

IF messages exceeding a recipient warning threshold are sent from the
same account twice in 5 minutes, our monitoring system is alerted, and
the mail admins are alerted via SMS.

And lastly, we've created a rule in the ProofPoint cluster which blocks
any e-mail which is sent out of our system, from a local address, with a
reply-to address which does not contain our domain, and the recipients
is greater than a low threshold.  Phishers/spammers commonly forge a
reply-to address that goes somewhere other than the actually address
that they've compromised.  this rule catches that.  It's never (that
we're aware of) stopped a legitimate piece of mail.


User education:
This is, in my opinion, the most difficult part of the whole thing.  i
could go on for hours about users doing silly things, but i think we all
know where that leads.  The bottom line is, we make information about
how to spot phish publicly available, and do our best to educate users
about keeping their credentials safe.




All of this adds up to almost NO spam or phish originating from our
users.  If one does get compromised, it usually gets stopped by the PPS
filter, if the general phish/spam filter doesnt catch it, the forged
reply-to checker does.  If all else fails, the alerts we have in place
alert us minutes into the outbreak, and we lock the acount down.

False positives happen, but we have things in place to make response to
these as painless for both the user, and us mail administrators as
painless as possible.


On 08/22/2011 10:46 AM, Steve Elliott wrote:
> Situation:  We have staff/faculty on our campus that don't realize that
> you give out your email login data, including password to phishing
> emails.   So we get compromised accounts.
> We are in the works of putting an external MTA (barracuda system) that
> our Zimbra email will be filtered through if it leaves campus.   Of
> course this may hit some good emails with the bad ones.  Though I
> routinely check to see if we have a rogue account they usually have 2-4
> hours of uninterrupted time, especially during the night hours where
> they can spam their hearts out.
> 
> Question:  What solutions do you use to help in those situations?
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk5SrY4ACgkQsZqG4IN3sukWawCfcahIB34P0xlBLRoi/tPW4IFu
1b4AnAkCpi72HYKm0x7NZoWgQSCn6h8V
=UX9v
-----END PGP SIGNATURE-----