What are the pros/cons of the various methods to block brute force SSH attacks?

Question

There are a number of different packages out there to shut out IPs from which brute-force SSH attacks are launched on your system. For example:

• DenyHosts
• Sshguard
• fail2ban

What are the pros/cons of these, or any others?

My current solution is to take the email that logwatch generates every day and dump the egregious IP addresses into a text file which I feed into a script that then rebuilds iptables. It's hacky, time-consuming and manual, and I'd like a better way.

(Note that I didn't ask what was the "best" way to solve the problem, because there is no "best" way to do anything.)

Answer 1

Another one is fail2ban, which relies on iptables (so it works with any service, not just ssh). With fail2ban, you can:

• Specify path to any log file (apache, ssh, nginx, mail server, ...).
• Specify regex for attack patterns (e.g., more than 10 "404 errors" by the same ip on nginx access log in 6 seconds)
• Specify regex to ignore certain patterns (very useful!)
• Specify ban time
• Send an email (or any other alert...)
• Fully customizable (you can write your own alerts and filters)

One "disadvantage" of DenyHosts is that it requires tcp wrappers, so it will only work with services that look at the /etc/hosts.deny file. But to be fair with DenyHosts, sshd is compiled to use TCP Wrappers on most Linux distributions. I also find DenyHosts to be easier to configure out of the box than fail2ban (but less powerful).

Reference to a similar SF question

Answer 2

I use DenyHosts, so I can at least answer for that:

Pros

• It's completely automatic
• It's configurable (how many failed attempts before blacklisting, for usernames that don't exist, usernames that do exist, and a special entry for root)
• It can e-mail you with a list of newly blacklisted hosts periodically, and/or run a given program every time a new host is blacklisted
• It supports automatically un-blacklisting hosts after a while

Cons

I don't have any irreparable cons, as long as you use it correctly:

• In its default configuration it won't alert you to newly blacklisted hosts, so if somebody is attacking your network from hundreds of different addresses you might not notice right away like you would if you're monitoring your logs manually, but (as mentioned in the pros section) it can e-mail you or run an executable to alert you when new hosts are added
• By default it will blacklist your hosts the same as any other, so you probably want to add them to /etc/hosts.allow. I locked myself out once just failing at typing my password, and once somebody from work tried to login to my root account as a joke and blacklisted my work IP, and it took me a few days to figure out why I suddenly couldn't connect to my network from work anymore

Answer 3

A simple and in practice effective protection against scan-based attacks is not to use the standard port. 443 (the https port) exposes you to different brute-force attacks that aren't going to crack your weak passwords, and possibly works through more firewalls than the default port (22).

Most methods to prevent ssh brute force attacks are great ways to self-DoS (oops, I screwed up the configuration! Oops, I did a bunch of quick rsync's and am now banned for the day!) or assisted-self-DoS (Oops, the attacker comes from/has subverted a machine in the same subnet as me (dynamic IP range, college network...) and I'm getting banned as well!).

If you only log in from a few places, you can just whitelist source IP addresses. That's obviously no good if you want to ssh from your laptop or cell phone on the go.

Having an ssh daemon that only listens to IPv6 connections should protect you from scans for a few years yet. But many firewalls won't let you transport IPv6 in any reasonable way.

Another method you don't mention is port knocking. It doesn't suffer from as self-DoS problems (other than misconfiguration), but it doesn't cross firewalls well, and can add several seconds' latency to connection establishment.

If you have good passwords, or you can live without password authentication, disable password authentication. (Keys and one-time passwords are sufficient for most use cases: if you don't trust the client machine enough to store an ssh key, you don't trust it not to have a keylogger either). Then brute force attacks will cost you a bit of CPU and bandwidth but don't expose you to an intrusion (as long as you've checked none of your keys came from a Debian low-entropy OpenSSL).

All in all, do note that changing the port does not significantly reduce your exposure. You'll get less scanning, but all you can cut off is the low-hanging fruit that seeks to exploit old vulnerabilities and weak passwords. As long as you keep your daemon up to date and either enforce reasonable passwords or and reasonable attempt rate limits, switching the port is more of a liability than a security measure.