SSH brute force defense

Posted: 26 November 2012 (13:14) | More posts about Arch Linux Ubuntu SSH

I have several VPS hosts with different providers using different virtualisation platforms. Naturally I have OpenSSH running on these VPS hosts and deploy either DenyHosts or Fail2Ban to add an extra security layer to thwarte SSH brute force attacks and other abuse.

DenyHosts blocks brute force attacks by adding offending IP addresses to /etc/hosts.deny. It therefore requires the SSH server is configured with tcp_wrappers. Arch Linux dropped support for tcp_wrappers so DenyHosts is not suitable for Arch. Fail2Ban supports blocking via iptables and/or tcp_wrappers and can also block offending hosts that are abusing services other than just sshd.

DenyHosts on Ubuntu

Here is a simple example for DenyHosts on Ubuntu Lucid 10.04 LTS Server.

sudo apt-get install denyhosts

That's it. The default configuration will provide suitable prevention, but do take a look at /etc/denyhosts.conf for a full run down of all available options. I use the defaults with the following exceptions:

PURGE_DENY = 5d
PURGE_THRESHOLD = 2
ADMIN_EMAIL =
SYSLOG_REPORT=NO

DenyHosts can be restarted by executing:

sudo /etc/init.d/denyhosts restart

Fail2Ban on Arch Linux

Fail2Ban currently requires syslog-ng logging because systemd journalctl is not currently supported. Fail2Ban patches for adding support for journald are available.

sudo pacman -S fail2ban syslog-ng

Enable and start syslog-ng.

sudo systemctl enable syslog-ng
sudo systemctl start syslog-ng

You'll need to enable one of the jails in /etc/fail2ban/jail.conf. The following example will block SSH, without sending email alerts.

[ssh-iptables]

enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=ssh, protocol=tcp]
logpath  = /var/log/auth.log
maxretry = 5

Enable and start the Fail2Ban daemon.

sudo systemctl enable fail2ban.service
sudo systemctl start fail2ban.service

See the Arch Linux Fail2Ban Wiki page for more details.

SSH best practice

DenyHosts and Fail2Ban do not provide complete protection against SSH brute force attacks. I employ other SSH best practice to better secure the SSH services I expose to the Internet, and so should you. The following is a good reference.

Getting started with SSH security and configuration

Other SSH brute force prevention tools

In the interests of fairness, other SSH brute force preventation tools are available.

Do you know any other tools that help prevent SSH brute force attacks?