[acatton]

> I wouldn't say fail2ban is bad advice per se. The kind of companies running deployments that do auditing on iptables are going to be very different to the types of companies that benefit from dynamic rules created by services like fail2ban. […] There is a gulf of difference between hardening a Linux server for an independent web shop vs running Linux at Google.

I agree that there is a difference between running Linux at a FAANG and running Linux for an independent web-shop.

However, my advice was targeted at the hobbyists like me who likes to run their own webserver. (Independently from my employer) And I think it is appropriate for independent web-shop as well.

Auditing is not just reserved to bigcorps, I personally like to log diffs between "nft list ruleset" and "cat /etc/nftables.conf" on my personal servers. If you run fail2ban this becomes impossible.

Also, IMHO, fail2ban doesn't really solve the problem, a botnet attack could try to bruteforce your SSH. All it does is try to prevent one person from trying too much, it can also lock you out during an emergency. spiped is, IMHO, easier to setup and cheaper to maintain. It also provides a higher degree of protection. (As I explained before, it is a 256bit combination port knocker)

I personally think that fail2ban is a cargo-cult.

[ozim]

Everyone should do key based auth anyway - so I don't even see use for fail2ban anymore in context of SSH.

[UI_at_80x24]

Yes everyone should use key-based authentication. What fail2ban and other firewall styled security measures do is to move the point of contact on your network.

1 - You want to limit the number of times that SSHD initializes the connection handshake, this initialization period is when/where 0-day exploits can get through.

2 - With active auditing you can add the banned IP's to your edge device. Odds are that a legitimate IP won't be trying to SSH into your systems so block everything from them. I go one step further and share that banned IP list on all my edge devices.

[acatton]

spiped is not an exclusive or to key based auth. I advise to use spiped + key based authentication.

spiped allows also for circumventing zero-day attacks on openssh.

[handrous]

On smallish servers it can keep the logs human-browsable without filtering. Not necessary, but nice.

[hnlmorg]

Since we're talking about two different points in time that are nearly a decade apart, lets be clear about the context here. spiped didn't exist when that article was written (or if it did, it certainly wasn't mature). Back then fail2ban was a pretty good recommendation for the domain in question. Which was my point.

If we shift the focus to 2021 then I'm more inclined to agree with you that it's less important. However I still disagree that it is "bad" advise and think you're overstating the reasons why it should be considered "bad advise". I'm not going to discount the problems you raise but I believe them to be less significant than the benefits fail2ban brings. To be clear, I do also agree that the benefits it brings are also small, however the risks are smaller.

The problem with the discussion here is you're focusing just on SSH. There are clearly a number of ways one can protect SSH without fail2ban. Much better ways in fact. But fail2ban isn't an SSH firewall, it's a log watch. If you have a machine exposed on the internet with no other firewalls between the internet and your server (eg no AWS security groups, router firewalls, etc) or even if you do have other firewalls in place but have several services running off the same host, fail2ban can protect you against some of the more casual directed attacks. eg you can set it up as a WAF and have all services blocked if your Apache/nginx logs detect suspicious activities.

Also your point about botnets are true but the point of security is to slow down attacks in the hope of preventing them. There isn't a silver bullet, only layering hurdles. fail2ban does slow down the smaller scale bot net attacks.

Let's also remember that there is a fair amount of bots out there that aren't part of botnets but rather just scripts run by opportunists. fail2ban can cut down on that annoyance as well.

Going back to your point about auditing, most independent hosts wouldn't even think to run auditing. The fact you do only demonstrates your enterprise background. And I'm not even convinced your example even adds any value since if nftables.conf is on the same host as iptables then it's not unreasonable to assume any successful penetration that has rewritten your iptables rules might also rewrite your nftables.conf too. In fact the first thing they'd do would be to check what agents are running for auditing and configuration management; and then kill them. I also think you're overstating the difficulty of working around dynamic deny lists -- it wouldn't take a complex script to filter out the rules added by fail2ban and frankly the rules you'd be more interested in auditing would be the allow rules anyway.

That all said, I don't disagree with your point about fail2ban (in 2021) being cargo-cult. I do disagree with your point that it is bad and your reasons for why it is bad. But I do agree that it's benefits are largely marginal in most cases.

[acatton]

> Since we're talking about two different points in time that are nearly a decade apart, lets be clear about the context here. spiped didn't exist when that article was written (or if it did, it certainly wasn't mature). Back then fail2ban was a pretty good recommendation for the domain in question. Which was my point.

That is simply not true. spiped 1.0 was released in 2011, 2 years before the article was written. And it was used in production on tarsnap's infrastructure since it is the same author. It had 4 minor releases by the time the article was written. [1] And it was in debian by the end of the year 2013. [2]

[1] https://www.tarsnap.com/spiped.html

[2] https://metadata.ftp-master.debian.org/changelogs//main/s/sp...

[hnlmorg]

> > spiped didn't exist when that article was written (or if it did, it certainly wasn't mature).

> it was used in production on tarsnap's infrastructure since it is the same author. It had [3 minor] releases+ by the time the article was written. And [the initial release] was in debian [unstable] by the end of the year 2013 [after the article was written].

You're not exactly making a strong case there but fine, I'll concede it did exist and had some undefined degree of maturity that we're never going to prove nor disprove. :)

+ it was 3 minor releases not 4. The 4th was released in April, the article in March. But in fairness to yourself there were also 2 patch releases you didn't count.

[handrous]

fail2ban works for a lot more than just SSH.