Protecting SSH from brute force attacks
Quick and simple protection from login attacks for SSH
by Daniel Bachfeld
Using just open source tools and a few tweaks, it is possible to detect and block suspicious login attempts.
Many people who run servers with SSH access and password authentication get butterflies when it comes to security. If a glance at the server logs shows high volumes of failed logins by automated scripts, it's natural to wonder whether a carefully selected password is going to be adequate to fend off future brute force attacks. Recent attacks on a number of security sites illustrate that the people who run them don't always take their own advice.
Simple measures can repel repeated cracking attempts. There are tools available which count failed logins from specific IP addresses and block further access once a set threshold is reached. These tools utilise a range of approaches for dealing with unwanted attention.
Access controls for TCP connections can be implemented on Unix and BSD systems using TCP wrappers. These switch between the TCP/IP stack and the actual service. Traditionally, this occurs in conjunction with the (x)inetd super-server daemon, which first passes incoming connections to the TCP wrapper. The former can, for example, log connections or block connection attempts from individual IP addresses. Which addresses are allowed and which are blocked is specified in the /etc/hosts.allow and /etc/hosts.deny files. Only if all the relevant boxes are ticked does the wrapper launch the service program and pass it the open connection. Some services, such as OpenSSH, are already linked against the libwrap wrapper library, which performs this same function, and do not therefore require an intermediary. You can test whether your OpenSSH daemon is linked against the libwrap library and therefore evaluates hosts.deny using ldd /usr/sbin/sshd.
Another approach to blocking unwanted access in Linux is the netfilter firewall, the rules/tables for which are configured using the iptables userland tool. Applications are also able to add rules in order to help keep attackers at bay. Tools differ in the way they collect information on suspicious login attempts. Some search the log files at regular intervals for information on failed authentication attempts, others simply count the number of connection attempts from a given IP address.
All blocking tools which evaluate log files at regular intervals suffer from the problem of not being able to react to attacks in real time. As long as an attacker is running through names and passwords manually they are able to keep up, but as soon as automated scripts for conducting high-speed assaults come into play, they tend to be too slow and respond too late. In tests we observed attacks in which dozens of failed login attempts appeared in the log within just a few seconds – it took the tools around 40 seconds before they sprang into action. It is possible to reduce the intervals at which log files are evaluated, but doing so can cause the tools to hog resources.
They are also susceptible to crafted log entries – attackers can insert specific entries into the log remotely using crafted user names or other calls to trick the tools into blocking legitimate IP addresses (details on this can be found in Attacking Log analysis tools).