On 6/28/2013 12:31 PM, John Fawcett wrote: > One type of connection which I cannot block in fail2ban are clients that > try the AUTH command on port 25, where I have disabled it. I got 245 > connections this morning in the space of 5 minutes and those are the > ones that got through despite the connection concurrency limit being hit > 277 times.
In a span of 26 minutes on June 9th I got hit with parallel connections of this "AUTH bot" junk, totaling over 5,100, from a hacked Argentinian MX server. This with a concurrency limit of 4. That's just over 3 connections/second. Above you show less than 1 connect per second. ~$ zgrep " connect " /var/log/mail.log.3|grep -c 190.210.114.210 5116 ~$ zgrep "concurrency limit" /var/log/mail.log.3|grep -c 190.210.114.210 3755 Jun 9 11:01:17 greer postfix/smtpd[30422]: warning: Connection concurrency limit exceeded: 5 from mail.cqr.com.ar[190.210.114.210] for service smtp ..... Jun 9 11:27:43 greer postfix/smtpd[30525]: warning: Connection concurrency limit exceeded: 5 from mail.cqr.com.ar[190.210.114.210] for service smtp None were rejected. The client disconnected each time. ~$ zgrep reject /var/log/mail.log.3|grep -c 190.210.114.210 0 ~$ zgrep AUTH /var/log/mail.log.3|grep -c 190.210.114.210 1360 Looks like Anvil was responsible for the bulk of the disconnects. Anvil did its job preventing a DOS condition on smtpd. Even if these had progressed far enough to be rejected they'd still have not put significant load on the server. Thus the sum total negative impact of this attack on my MX is a bloated log. For me, personally, it's not worth the hassle to implement fail2ban simply to keep the log tidy. In your case John are you suffering anything more than a bloated log? Is one extra connect/second causing problems? -- Stan
