4 ms·

fail2ban is fine for effectively slowing brute-force attacks for services that can't by themselves or where significant complexity would be needed. it's easy t

• marcus0x62 3y ago
  > EDIT: fail2ban vulnerabilities? what is this guy talking about? There have been several: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=fail2ban https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=fail2ban. Mostly DoS. At least one RCE, admittedly with a non-default fail2ban config and a somewhat unlikely attack chain: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-32749 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3274...
  • rigid 3y ago
    > At least one RCE, admittedly with a non-default fail2ban config and a somewhat unlikely attack chain: you had to manipulate answers from a whois server. Sure, it increases attack surface (like any additional piece of code) but argueing to better let an IP hammer your mailserver with infinite stuffed credentials just to avoid possible bugs, is questionable at least. fail2ban's CVE track record is quite good in comparision, if you take that as metric. It might be even more secure than using multiple different rate-limiting implementations that were written in C.
    • marcus0x62 3y ago
      Yes, as I said, the attack chain was unlikely to be used it practice.