4 ms·

I have never understood the point of Fail2ban other than feeling kinda smug. If your SSH server is more at risk because an attacker simply has more attempts, s

I have never understood the point of Fail2ban other than feeling kinda smug. If your SSH server is more at risk because an attacker simply has more attempts, surely your SSH server is not secure? It is just adding another attack surface.

ericbarrett 5y ago
I have seen it used for legacy SFTP installations where password auth is still a thing (customers uploading CSV files and such).
tbrownaw 5y ago
It's one of the many things designed to make lousy passwords become actually ok-ish. Specifically for ssh, I've also had my vps eating a surprising amount of cpu just to verify and reject bad logins when some scanner or other spent a couple days on it before moving on.
- mordechai9000 5y ago
  You can also just use a firewall rule to rate limit syn packets from a source. It won't affect legit traffic, and doesn't require running a userland process to watch the logs.
avian 5y ago
If nothing else, fail2ban reduces the staggering amount of logs that result in bots hitting services with useless password attempts.
outworlder 5y ago
Defense in depth. We can't ever prove that something is "secure", we can only take precautions. Is your SSH server secure? You can't tell, by definition, in a world where 0 day exploits exist. If you know where your requests are coming from, you can restrict to those IP addresses. It doesn't mean you think your server is insecure - but it's making the lives of people trying to get to it that much harder. If you don't know, then maybe fail2ban is a worthwhile alternative. It doesn't even necessarily mean you are trying to prevent brute forcing (password logins should always be disabled anyway) - but some exploits require multiple attempts. In the past I was against measures like changing the default port (although it should still be <1024). But these measures are helpful the moment some new exploit is in the wild that could twart naive scanning scripts. Same thing goes for hiding the banner. The best thing is still to automate things so that SSH access becomes a 'break the glass' moment. If you are always logging in via SSH(and it's a server, not a workstation that you work on), it means that there's something missing in the automation (or observability) that needs to be fixed.
- xorcist 5y ago
  Adding more stuff isn't necessarily defense in depth. It's also an opportunity to make mistakes, which in worst case could provide free root shells to people with funny host names.
tommiegannert 5y ago
> If your SSH server is more at risk You can have it block all ports for the attacking host, so it might help other protocols. Aside from just reducing load on the host. By dropping the TCP SYN packet, you also introduce delays for the attacker.
kiririn 5y ago
The main benefit for me is protecting password services like HTTP basic auth, ftp, mailserver, etc. It’s pretty pointless for SSH when keys are involved

ericbarrett 5y ago

I have seen it used for legacy SFTP installations where password auth is still a thing (customers uploading CSV files and such).

tbrownaw 5y ago

It's one of the many things designed to make lousy passwords become actually ok-ish. Specifically for ssh, I've also had my vps eating a surprising amount of cpu just to verify and reject bad logins when some scanner or other spent a couple days on it before moving on.

mordechai9000 5y ago
You can also just use a firewall rule to rate limit syn packets from a source. It won't affect legit traffic, and doesn't require running a userland process to watch the logs.

avian 5y ago

If nothing else, fail2ban reduces the staggering amount of logs that result in bots hitting services with useless password attempts.

outworlder 5y ago

Defense in depth. We can't ever prove that something is "secure", we can only take precautions. Is your SSH server secure? You can't tell, by definition, in a world where 0 day exploits exist. If you know where your requests are coming from, you can restrict to those IP addresses. It doesn't mean you think your server is insecure - but it's making the lives of people trying to get to it that much harder. If you don't know, then maybe fail2ban is a worthwhile alternative. It doesn't even necessarily mean you are trying to prevent brute forcing (password logins should always be disabled anyway) - but some exploits require multiple attempts. In the past I was against measures like changing the default port (although it should still be <1024). But these measures are helpful the moment some new exploit is in the wild that could twart naive scanning scripts. Same thing goes for hiding the banner. The best thing is still to automate things so that SSH access becomes a 'break the glass' moment. If you are always logging in via SSH(and it's a server, not a workstation that you work on), it means that there's something missing in the automation (or observability) that needs to be fixed.

xorcist 5y ago
Adding more stuff isn't necessarily defense in depth. It's also an opportunity to make mistakes, which in worst case could provide free root shells to people with funny host names.

tommiegannert 5y ago

> If your SSH server is more at risk You can have it block all ports for the attacking host, so it might help other protocols. Aside from just reducing load on the host. By dropping the TCP SYN packet, you also introduce delays for the attacker.

kiririn 5y ago

The main benefit for me is protecting password services like HTTP basic auth, ftp, mailserver, etc. It’s pretty pointless for SSH when keys are involved