On 7/3/2013 12:35 AM, John Fawcett wrote:
The point is to stop spambot connections to pop and imap (which are usually done to try and steal credentials).
This is not the usual way spambots work. Generally, spambots scrape addresses from various sources in order to get lists of emails to send spam to.
What you seem to be experiencing may be zombie nets trying to brute force credentials so they can then send spam from compromised accounts. This is a different beast with a different solution.
Regardless, you have a spcific problem that needs addressing.
I ran an ISP for almost two decades and have dealt with these issues myself. My recommendations:
- Enforce strong user passwords. I use 12 characters minimum. 14 characters or more would be better, but this length starts to make it hard for mere humans to remember. Enforce a rule that the password contains at least 2 or 3 of the following: lower case letter, upper case letter, digit, and symbol which is not one of the prior three.
Some systems require the user's password have all four. This actually weakens the password (if you care to know why, I can go into the math in a later post).
After enforcing your chosen rules, run the password through cracklib before accepting it from the user. Or even better, what I started doing was having the system generate passwords and not let the user choose their own. Initially people grumbled a bit, but they soon got used to it and security was much better.
- Fail2Ban with rules that seem like they are pretty weak, but trust me, they work fine and you limit complaints from users.
a) If you get 3 invalid login attempts within a minute from more than 1 IP address, block that login for 10 minutes. If you have blocked a login and another attempt to log in to that account is made then tarpit that connection. Usually 60 seconds is sufficient. Do not extend the original block time past the original 10 minutes. b) If you get 5 invalid login attempts within a minute from the same IP, block that IP for 5 minutes. This is usually a valid user who forgot their password, as opposed to a) which is usually a malicious third party.
Some of this you can do with off the shelf tools, some of it may require some glue code (Perl or Python works nicely) on your part. If you can implement this, it will stop the abuse cold.
- provides security and makes brute forcing infeasible. 2) helps reduce load on your systems.
I was imagining a distributed solution which is already in use in many mtas applied also to imap and pop so that connections could be stopped from the first one.
I am assuming that if there is such a feature then data is available (e.g. sorbs) or if not yet being collected that it could be done.
I feel your pain and frustration. I do not believe there is an RBL list of offending IP's for brute force attacks and I think one would be hard to build and keep up to date enough to be useful, since most of these systems are compromised home computers, but they get fixed and there is a lot of turnover - infected systems are repaired and new ones infected.
Most of them are in the far east, so if you do not mind applying a cudgel to the problem, you can block entire ranges of IPs altogether. Of course, one of your users traveling to one of those areas would need to use some other method to access email (mobile device, webmail, etc).
Dem