Feeling Secure is Not Necessarily Being Secure

If you ask most system administrators, “How do you prevent bots from bruteforcing your ssh password on a Linux box?” the vast majority of them would tell you, “I install fail2ban.”

When I was younger, I used to install fail2ban on every server. I remember a very passionate senior system administrator who told me fail2ban was bad. He never told me why, but now I understand why he was right.

Problems with fail2ban

To understand which problems fail2ban can lead to, you have to understand how fail2ban works:

• fail2ban is a deamon that reads from /var/log/auth.log.
• This deamon detects IP addresses which failed to authenticate multiple time within a certain period of time.
• Once it has found these IP addresses, it adds them to the firewall.
• fail2ban keeps track of which IP it added to the firewall, and removes them after a grace period.

This leads to multiple problems. As Systems Administrators, we should always strive to reduce as much as possible the number of programs running as root. I'm already very uncomfortable having ssh running as root, but it is okay to me since it has a very good security record.

But fail2ban has to run as root, so that it can add rules to your firewall. This is one possible attack vector. Some remote code executions on log analyzers have happened in the past.

At Fusionbox, we use transactional iptables, so that iptables don't get into an inconsistent state. (We do that using iptables-save and iptables-restore, along with netfilter-persistent in Debian)

Another problem with fail2ban is that (in the case you're using password authentication) you can actually get banned from your own server.

Feeling Secure

This is, in my humble opinion, the main feature of fail2ban: the feeling of security, or the feeling that “now, I know my SSH access is protected.”

Security issues fail2ban tries to prevent

What fail2ban is trying to do is:

• Prevent simple password bruteforcing
• Avoid wasting bandwidth on SSH

Issues fail2ban can't address by design

But fail2ban can't address the following issues:

• The package maintainer screwed up and created a user with a hardcoded password.
• Distributed bruteforce attack with botnets

Being Secure

There's a very simple way to really secure your SSH access without using fail2ban. First of all only allow public key authentication. Do this by using these settings in your sshd_config:

1
2

PubkeyAuthentication yes
PasswordAuthentication no

Public public key authentication makes most bruteforcing bots abandon after the first try. It saves bandwidth.

Moreover, simple passwords are not an issue anymore since they're not used to authenticate.

The other thing to do is to only allow your user, or create a group for the users you want to be able to SSH in. This is what you put in your sshd_config:

1
2
3
4

# For users:
AllowUsers userfoo userbar
# For groups
AllowGroups groupfoo groupbar

If you administer your server with only one user, use AllowUser. Otherwise, it is a common practice to create a group ssh, and add users to this group if you want them to be able to connect.