On Mon, Jul 17, 2017 at 01:33:24PM -0400, Wietse Venema wrote: > I don't think there is much to gain from parsing postscreen logging > to produce fail2ban rules. postscreen is designed to handle a lot > of abuse with near-zero resources.
Granted, not much benefit within Postfix. But consider: these botnets are also attacking other services: http, ssh, DNS, and more. I think it's a reasonable goal to want to block botnets in the firewall. [ Linux-specific ] We do it with ssh attacks here using the "recent" iptables module. (On my TODO is a plan to port those rules to the --match set and --jump SET modules and ipset(8).) These attacks, when exceeding established maximum new connection rates, cause the attacker to be entirely blocked in the firewall. That obviously won't work for SMTP, where [FSVO] legitmate sites might have a bunch of new connections in short periods. For ssh, we're using the assumption that these connections are humans who are seeking shell access, although indeed a poorly-written script could easily go beyond the limits. So the move to ipset would allow broader participation in attack deflection; fail2ban could help populate the firewall blocking with input from httpd, named, and others (including Postfix.) Another advantage of firewall blocking is at the human level: decrease of noise in the logs, to potentially save time for the admin. I haven't had many systems which were vulnerable to the brute-force ssh attacks, but I don't need to see that spam in the system logs. To be clear, I don't have an answer for the OP; I am just tossing out a couple of coins in support of the goal. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
