What has worked for me. Develop a policy where user must have 8 char min password that is not dictionary based. Linux Pam for example helps with this.
Then obtain and run fail2ban against your smtp/pop/imap logs. Most passwords are guessed using dictionary attacks, which fail2ban you can blacklist ips if they get the password wrong X number of times. This will not stop 100% of the spam due to compromised accounts as some accounts are compromised from the users PC but for me it has made a huge improvement, it has cut down on spam generated from my servers by 98%. The other thing to do is subscribe to yahoo/aol/etc spam feedback loops as this will let you know if there is spam from your network and email you at which point you can minimize the issue and fix the problem. I used to have an issue with compromised accounts generating spam but using the combination of things I mentioned above it have almost no issues. I now go several months without any issues and haven't gotten blacklisted in years and this is running 4 smtp servers. p -----Original Message----- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of lcon...@go2france.com Sent: Wednesday, March 05, 2014 4:42 PM To: postfix-users@postfix.org Subject: Re: Compromised Passwords On Wednesday 05/03/2014 at 9:25 am, Blake Hudson wrote: > > Homer Wilson Smith wrote the following on 3/4/2014 4:38 PM: >> >> >> Dear Gentle Folk, >> >> What is the state of the art in dealing with users whose SASL >> password has been compromised? >> >> Running CentOS, and latest postfix. >> >> When a password gets compromised, spam starts to pour out of >> the server from endless numbers of IP's, to endless numbers of >> addresses. >> >> Rate limiting is interesting but doesn't really stop the spam. >> >> Counting client=[IP] addresses until a threshold is reached is >> highly effective, but then what? Change their password? >> >> Thanks in advance. >> >> Homer >> > > Just to confirm what others have said. Yes. Monitor activity for > abusive/suspicious behavior and take action to stop it as soon as it's > discovered. If you can automate it, even better. > > While one could use a policy server, we chose to use an out of band > monitoring solution that used the postfix logs. We track emails sent > and then geolocate by IP of the client. If a single customer is > simultaneously (or very quickly) spending time in several countries or > continents then we know there's a problem. This has had a very low > false positive hit rate and does a good job of catching most of the > abuse we see coming from our customer accounts. We use other > thresholds based on volume to catch spam sent from one or two IP > addresses. Like another poster, we also use fail2ban, anvil, and have > minimum password requirements to help create a layered solution to > slow or prevent abuse in an automatic fashion. > > We typically change the password on accounts flagged for abuse and > then contact the customer to inform them of the problem and recommend > they take action to secure their systems and change their passwords on > any other accounts that may have shared similar credentials. > > --Blake We run a dedicated outbound mx, omx1, which runs postfwd tht does sender rate limiting, at 3 levels of quantity. This box's my_networks contains only the 3 IPs of our 3 mail servers. 50 msgs max for everybody not whitelisted for the 50 msg limit. 700 msgs max for users we know are legit volume senders send more than 50 but less than 700 are legit volume senders a few legit senders send over 700, so they have their own whitelist. 2000 msgs max for everybody, since no legit user sends that many. So even if one of the above whitelisted senders gets cracked, the cracker is HOLDed at 2000 msgs. when these limits are hit, postfwd returns a HOLD action to postfix for that sender. Monit is watching the HOLD queue and sends an alert. On the box doing SMTP AUTH submission, we observed how many different IPs legit users submitted from per day. that number was 10 IPs. We run a script every 10 minutes that checks PER THIS HOUR for any SMTP AUTH login that exceeds 10 IPs. That script doesn't react to block that cracked SMTP AUTH user (that's next), but does email an alert with username and number of SMTP AUTH IPs. this two-level checking has, so far, killed our exposure to password cracks. Len >
