On Wed, Mar 02, 2016 at 02:49:35PM +0100, Karel wrote: > I am running small Postfix server for personal use. My logs are > flooded with: > > relay access denied > hello rejects > connection rate limit exceeded ... > lost connection after AUTH from ... > > Often there are hundreds of these logs from the same IP address. > I know, that I can use fail2ban to block these IP addresses > using iptables. > > But I very much dislike the way fail2ban works: > > Postfix logs errors -> rsyslog writes them to text file -> > fail2ban parses those text files and creates iptables rules. > > Seems to me, the only step missing to make it even more ugly would > be to print the logs on paper, and then use OCR to scan them back.
Hehe, I quite agree. OCR is a nice touch. :) > Does this process have to be so complicated ? Is there no easier > way to block offending IP addresses using iptables ? Before I launch into all of this, I'll have to agree with the earlier poster who said, "Don't worry about it." It's interesting to see how much garbage your Postfix is rejecting. The bandwidth savings from blocking abusers is minimal. That said ... One way in which this process could be greatly improved would be if fail2ban supports (or can be made to use) ipset(8). Then rather than mucking about with your iptables rules, fail2ban simply updates the ipset. http://ipset.netfilter.org/ , any recent GNU/Linux distro should include this already. I saw that our colleague Robert Schetterer of sys4.de has done some experimentation with the string match. Ugh. That's brave. Read about it (auf Deutsch) here: http://sys4.de/en/blog/2015/11/07/abwehr-des-botnets-pushdo-cutwail-ehlo-ylmf-pc-mit-iptables-string-recent-smtp/ as well as an older blog here: http://sys4.de/en/blog/2014/03/27/fighting-smtp-auth-brute-force-attacks/ The former (2015) article only targets a specific EHLO command, "EHLO ylmf-pc", thus only one specific botnet. The latter (2014) article was interesting, but as pointed out by a commenter, unlikely to be useful in the the real world where we usually don't offer AUTH before STARTTLS. I would add, though, that further work on the 2014 idea is warranted. It is easily possible to limit submission by absolute number of initial connections, using the iptables "recent" match. Determine a maximum number of connections that a human user's MUA might initiate, pad it appropriately for safety, then use the "recent" match to blacklist any IP address which exceeds that number. It's likely that the same approach could work with IMAP/POP3 as well. We're using it to keep our SSH log noise down here. Here are some excerpts from our "iptables-save -c": [705889514:346428143355] -A INPUT -j State [8656221:504934726] -A INPUT -p tcp -j AllowTCP ... [14442:796892] -A AllowTCP -p tcp -m tcp --dport 22 -j Ssh ... [49214:2905108] -A BlockHosts -m recent --rcheck --name BADGUY --mask 255.255.255.255 --rsource -j DROP [100:5456] -A PermBlock -p tcp -m recent --set --name BADGUY --mask 255.255.255.255 --rsource -j NFLOG --nflog-prefix "PermBlock: " [100:5456] -A PermBlock -p tcp -m recent --set --name BADGUY --mask 255.255.255.255 --rsource -j DROP ... [0:0] -A Ssh -p tcp -m tcp -m recent --rcheck --name BADGUY --mask 255.255.255.255 --rsource -j DROP [100:5456] -A Ssh -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -m recent --rcheck --seconds 45 --hitcount 6 --name SSH --mask 255.255.255.255 --rsource -j PermBlock [1035:59760] -A Ssh -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -m recent --update --seconds 30 --hitcount 3 --name SSH --mask 255.255.255.255 --rsource -j Reject [13210:723896] -A Ssh -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -m recent --set --name SSH --mask 255.255.255.255 --rsource -j ACCEPT [705921891:346430644196] -A State -j BlockHosts The counters tell the story. Since initiating this ruleset we have had 100 ssh attackers, and out of ~706 million packets, we blocked almost 50 thousand. That doesn't seem like much, but when you consider that each of those 50K would have been 3 or more lines in logs, you see this is doing quite a lot to keep the logs readable. Since it's not really on topic here I'll just post a link which explains what the "recent" rules do: http://rlworkman.net/conf/firewall/sshattacks The one difference is that we're no longer just using the "BADGUY" blocklist for ssh; we now apply that to all traffic. (Note the rule in Ssh with zero counters: that's because we already dropped those packets in the BlockHosts chain.) Back to SMTP, the same rules we use for ssh will not work. Most legitmate SMTP traffic is from automated processes. We're assuming that legitimate SSH traffic is initiated by a human. If a human wrote a script which was doing multiple scp(1) or rsync(1) commands with key-based authentication, that script might end up in our BADGUY list. Legitimate submission and IMAP traffic, like SSH, is more likely to come from a human sitting at a computer (smartphone.) So possibly similar limits will work. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
