Getting Started with Fail2Ban on Linux | Hacker News Reader

Getting Started with Fail2Ban on Linux

ittavern.com

9 pointstodsacerdoti13 comments

The name of this project always irked me because it implies that it “fails to ban” unauthorized logins, which is the exact opposite of its purpose.

(ip addresses with failed login attempts)(go to)(the ban list)

(fail)(2)(ban)

I think fail2ban should never be used to directly add rules with iptable. This will get the iptable too bloated and each additional rule hurts performance. There are benchmark about that.

A solution is to use ipset and have fail2ban adding/removing up with ipset. I intend to write a blog about it, and other things about running your own server, as soon as I get some free time.

Does it meaningfully hurt performance though? Like, if I'm serving Google.com, adding microseconds to reply to a packet really add up to be a problem, but for a raspberry pi sitting at my house, what's the performance impact of having a million iptable rules?

In general, hobbyists will add the rule updates via a firewall whisper command override in fail2ban.

For example, shorewall/shorewall6 has rule set optimization for blrules (be warned single threaded Perl can take awhile for 300k IPs, and quick-boot rule-caching should be off during initial configuration).

I also use a crude ban-list generator script for certain persistently annoying country codes poking around, that currently imports a lot of iblocklist, spamhaus, known compromised IP posts on dodgy forums, and malformed whois records.

Yes it is rude to black-hole entire countries, but these same areas often tend to ruin the games with lagged connections and lame vulnerability/exfiltration scans.

https://www.youtube.com/watch?v=eGOtZDk6wRc

fail2ban had an RCE vulnerability a little over two years ago. I've been wary of it ever since.

https://news.ycombinator.com/item?id=28679761

There are always CVE reports on popular code eventually.

The question you have to ask is: "are you better off not knowing?"

Minimizing attack surfaces often means role specific servers, and some sort of proprietary virtualization/sandbox. There are some good arguments to rotate and burn mail server instances every 3 months like clockwork, and expire your keys. i.e. makes sure permission rot, deleted user files, and failed binary sums are auto-deleted or captured in a peer forensic log.

https://www.youtube.com/watch?v=eGOtZDk6wRc

I used to set up Fail2Ban on any new server, but in the classic case of using it to protect SSH, I haven't allowed password logins for a long time, and so all it really does is cut down on log noise.

Simply changing the default SSH port cuts it down even more, and I'm not convinced that fail2ban actually adds much security. It may even increase your surface of exposure, if it happens to have a security bug in it.

I mapped the SSH port to 122 on the external network while it stays 22 on the LAN. Then, I limit the number of connectons to port 122 at the firewall, using iptables (https://www.cyberciti.biz/tips/howto-limit-linux-syn-attacks...).

Now the failed logins on ssh is down to 1-2 per day instead of hundreds.

fail2ban is nice, but I found attacks on my servers went down by about 70% when I used the Spamhaus DROP list. Attacks on port 22 went down to almost nothing when I also used the xt_geoip module from xtables-addons to only allow SSH from my own country.

thanks for sharing!

I like denyhosts, because of the sharing blacklist feature. I'd rather not give the attackers a chance to guess the password when they've already hit 10 other hosts and it's a pattern.

Unfortunately denyhosts hasn't been updated in a while.

We have fail2ban send a request to a central server, then edge ban ips that have hit a couple hosts. Works well for us.

Reply on news.ycombinator.com