Brute force password-guessing attacks against ssh are all too common these
days. But, various countermeasures can be used to blunt their impact. A
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
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.
to post comments)