SSH brute force defense
Posted: | 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
tcp_wrappers and can also block offending hosts that are abusing services other than just
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
You might want to consider whitelisting some of your own IP address. Create a
/var/lib/denyhosts and list each of your
"trusted" IP addresses.
DenyHosts can be restarted by executing:
sudo /etc/init.d/denyhosts restart
Fail2Ban on Arch Linux
Fail2Ban currently requires
syslog-ng logging because systemd
not currently supported. Fail2Ban patches for adding support for journald are available.
sudo pacman -S fail2ban syslog-ng
Enable and start
sudo systemctl enable syslog-ng sudo systemctl start syslog-ng
You'll need to enable one of the jails in
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.
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?