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.
> 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]
> > 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.
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.