On 03/07/13 12:47, Professa Dementia wrote: > 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. Yes I have evidence that passwords found by brute force on pop3 were then used to send email via smtp. > > 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: > > 1) 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. > > > 2) 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. > > > 1) provides security and makes brute forcing infeasible. 2) helps > reduce load on your systems. these look like good suggestions. >> 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 I take the point that ips in such a dnsbl would probably have a short life span.
However, whatever may be the difficulties, such a list would not make sense if there is no functionality in the server to use it. I am going to look into Timo's suggestion though on tcpwrappers to see how this would work. John
