Security

Distributed brute force ssh attacks

Brute force password-guessing attacks against ssh are all too common these days. But, various countermeasures can be used to blunt their impact. A recent discussion on the freebsd-hackers mailing list looks at the problem and some solutions.

Ssh is generally the tool of choice for connecting to remote servers and it is rare that it is disabled on any true multi-user, network-connected machine. Typically, it is configured such that users need to log in with their normal username/password pair. But, since users often use poorly-chosen passwords—and usernames are relatively easily guessed—trying a large number of combinations of credentials will often gain unauthorized access.

In addition, most Linux (or UNIX, for that matter) machines have several known usernames that can be tried ("root", "news", "mail", etc.), which can reduce the search space significantly. Of course, gaining access to the root account compromises the entire system, so many ssh installations do not allow root to log in via ssh. In fact, disabling root logins (using "PermitRootLogin no" in /etc/ssh/sshd_config) is generally one of the first suggestions for making ssh more secure.

Another countermeasure against these kinds of attacks is turning off password authentication entirely, which can be done using "PasswordAuthentication no" in the configuration file. In that case, only users who have installed public keys for the hosts and accounts they wish to use to log in will be allowed. That completely eliminates the possibility of password guessing attacks, but does require that users protect the corresponding private keys. An attacker who gains access to the private key can immediately log in as the user.

A brute force attempt on a server generally leaves an audit trail in a server's log files, which can be used by an administrator to block the offending IP address. Of course, attackers quickly recognized that repeatedly trying passwords from a single address was likely to result in either being blocked or being caught by the authorities. So, distributed brute force attacks were born.

In a distributed attack, multiple hosts—quite possibly members of a botnet of some kind—attack multiple victim machines so that there are many more addresses to block. In addition, those addresses change frequently, so an administrator needs some kind of automated tool to keep up. Enter DenyHosts and other, similar tools, such as Fail2ban.

The basic idea behind these tools is that they scan various log files for evidence of a brute force attack. Once they find an offending IP address—based on various criteria—they update firewall or other access-control configurations to deny access from those addresses. Essentially, they automatically ban the addresses of hosts participating in these distributed brute force attacks.

There is a balance to be struck in terms of the criteria used to determine "bad" hosts. Denying access to legitimate users—who forget their password or try to log in from a host without the right private key—needs to be avoided. Typically, hosts that do not misbehave for some period of time will age off the bad host list, but legitimate users are unlikely to be willing to wait that long.

On the other hand, setting the criteria too high will still allow too many attempts from attack hosts before they get stopped. In addition, with the size of today's botnets, there may be no reason for a particular address to make more than one attempt per hour, or day, which will generally fly under the radar of most configurations. But, DenyHosts turns the tables on distributed attacks, by collecting distributed data itself—from many different hosts in what is called "synchronization mode".

Basically, a central server collects information from DenyHosts's users on which IP addresses they have determined to be bad. That information can then be used by other DenyHosts installations to effectively ban addresses that have not yet attacked them, but are currently attacking other DenyHosts users.

There are dangers to this approach, of course, and it still may not catch the largest botnets where individual IP addresses never quite reach the thresholds required to ban them, but it can help. The standard problems with blacklists and false positives certainly apply, and one could imagine all kinds of havoc that could come from malicious DenyHosts installations, but it is one way to leverage the data from multiple victims. A further refinement might be to provide the raw failure data, rather than just the bad IP addresses filtered by each site's failure criteria, to the central server. That server could then correlate single attack attempts on multiple hosts to more easily catch the larger botnets.

Much like the spam problem, brute force ssh attacks are a kind of arms race. Administrators will need to change tactics periodically as the types of attacks change. Turning off password authentication is not possible for all installations—and still doesn't get rid of the log file mess that brute force attacks leave behind—so techniques like DenyHosts's synchronization mode will, unfortunately, be needed for the foreseeable future.

Comments (34 posted)

New vulnerabilities

camlimages: integer overflows

Comments (none posted)

django: denial of service

Comments (none posted)

gd: buffer overflow

Comments (none posted)

kernel: multiple vulnerabilities

        if (optlen < sizeof(int))
                return -EINVAL;

Comments (none posted)

mysql-ocaml: missing escape function

Comments (none posted)

perl-net-oauth: session fixation vulnerability

Comments (none posted)

pidgin: denial of service

Comments (none posted)

poppler: integer overflow

Comments (none posted)

postgresql-ocaml: missing escape function

Comments (none posted)

pygresql: missing escape function

Comments (none posted)

xpdf: integer overflows

Comments (none posted)

Page editor: Jake Edge
Next page: Kernel development>>