SSH Password Authentication

Threats and Countermeasures

The Secure Shell (SSH) architecture is a set of protocols and tools based on the ability to enable encrypted remote system login. SSH has largely replaced tools such as TELNET and rsh for most system administrative needs. Most SSH implementations have had good track records, having been responsible for relatively few bugs that lead to widespread anonymous attacks against the protocol or implementation. However, like many systems, SSH is only as safe as its weakest link. Often the weakest link in SSH configurations is the reliance on username and password authentication. When passwords are weak or easily guessed, other underlying SSH benefits are rendered worthless. Unfortunately, many SSH systems are susceptible to brute force password guessing and dictionary attacks. Recent report data from the SANS Internet Storm Center has shown that TCP port 22, most commonly associated with SSH, is one of the most prevalent and widely reported threat vectors seen in the wild today.¹² The Dataplane.org patches to OpenSSH are helping to monitor and combat this threat.³

This whitepaper is the first in series to help educate and foster security best practices within the Internet community. Below we discuss some common SSH password authentication threats and countermeasures.

Password Strengths and Weaknesses

It might be argued that any reliance on static usernames and passwords for critical system authentication is prone to failure, particularly at scale. The threat of weak passwords and brute force password attacks (aka key search and dictionary attacks) have been discussed in literature for many years.⁴ Improving the strength of user selected passwords without a loss in the memorability has also been studied.⁵⁶ With so many services and systems making use of usernames and passwords, it is wise to publish a sound password selection strategy like the one outlined by J. Yan, et al. Gene Spafford, has discussed password change policies and other password best practice issues on his blog.⁷⁸ More recently, Joe St. Sauver gave a good summary talk about password authentication issues.⁹ With the history and threat of password security in mind, it may be tempting to hand-wave the problem away and dictate a different, or at least enhanced, authentication system. We will cover some SSH-specific strategies to consider below, but for many, password authentication is not likely to be completely eliminated for years to come, if ever. Here are some things you can consider if password authentication is required on your systems:

• Log failed and successful remote connection events preferably to a remote syslog server. Be sure the clock on the logging system and log collector system are correct and in sync. If possible, summarize connection logs and monitor for anomalous logins or login attempts.
• Periodically run a password auditing tool such as John the Ripper on all user accounts.¹⁰
• Periodically audit all accessible accounts and lock those that are inactive after some reasonable period of disuse.
• Help users select passwords with a higher than average degree of entropy and length, then enforce the policy. Avoid setting a maximum password length that is too short. Minimum password lengths tend to vary between 5 and 8 characters. This may be inadequate in today’s landscape, consider longer minimums if possible.
• Carefully consider threats to password reset policies. Simple “personal” questions can often be defeated through social engineering attacks. Furthermore, once private details about an individual are increasingly being made public as a result of other threats and the rise of social media.

SSH Policy and Configuration Options

set of useful configuration and policy options you may wish to examine further.¹¹ Consult the specific documentation for other implementations about similar features and usage instructions. The following is a list of OpenSSH server daemon configuration options that may be worth adjusting from their default settings. Each is briefly described. Options not listed are generally presumed to be set to reasonable defaults as listed in the OpenSSH sshd_config manual page.¹²

DenyUsers, AllowUsers, DenyGroups, AllowGroups

These options contain a list of group names or user names, separated by whitespace. They will be permitted or prohibited from remotely authenticating per rule processing. The options are processed in the order listed. The most restrictive approach is to only configure AllowUsers to a small subset.

AuthorizedKeysFile

We don’t recommend changing this option, but you may wish to consider limiting a user’s ability to make changes to their own ~/.ssh directory and files such as this in their directory. You can do so through the use of directory and file permission changes. This will require the system administrator to setup a user’s public keys, known_hosts file and any necessary ~/.ssh/config options, but this may offer some additional protection.

Match

This option permits the use of more complex conditional rules processing. We cannot offer any specific guidance to using this option since its applicability may vary widely. However, by way of example, you could disable PasswordAuthentication for all hosts by default, but permit it for a set of local networks.

PasswordAuthentication

This option is usually enabled by default, but unless you are able to integrate a one-time password authentication system on the back-end, we highly recommend it be disabled if possible. For larger, legacy systems this may be difficult, but it can greatly reduce remote authentication attacks, practically eliminating all brute force authentication threats.

PermitRootLogin

As of this writing, the most often attacked user account is the root account.¹³ In our experience, this setting is safe to disable for most systems. System administrators can use their own accounts to remotely authenticate and then obtain root privileges only when needed with utilities such as su or sudo.

Port

The default TCP port used by SSH is 22. It is understandable therefore that practically all anonymous SSH brute force attempts are only targeting TCP port 22. While we do not generally consider running the service on an alternative port a reliable measure to enhance SSH password authentication security long-term, it can offer some limited protection. We consider this a short term hack and ideally a site with a sound security posture would not need to change this option.

In addition to the server configuration options listed above, some sites limit accessibility to the server daemon from a range of source addresses such as a VPN. Doing this may limit the exposure, but it alone does not completely eliminate the threat of password attacks. We have seen some VPN credentials compromised. If an organization is not addressing issues throughout the infrastructure and is not carefully monitoring access and usage except at a few well known “choke” points, more targeted attacks can be devastating in those environments. Other options might be to limit accessibility to SSH servers during specific times of the day or to require a predetermined series of events before the SSH process will accept a connection, such as through the use of port knocking.¹⁴

Most SSH servers support the use of public key authentication as it is typically enabled by default. However, users and often even many administrators choose to use password authentication if available. We encourage the use of public key authentication. Jeremy Mates and David McNett have each written walk-through instructions for those new to the process.¹⁵¹⁶

Monitoring and Alerting

In this section we briefly discuss four general areas that offer additional insight and ability to alert an administrator about SSH password authentication attacks. Each offers their own unique perspective on attacks. Not all sites need to make full use of each, but having multiple views of your landscape improves your ability to detect and respond. Each category consists of an approach that has been widely implemented in other networks. Other systems and processes are possible, including many packages available from commercial vendors. However, in each section below, use of these subsystems can generally be done with little to no additional cost except for the time required for setup and management.

Netflow

Netflow was a concept originally developed by Cisco to summarize network traffic traversing routers.¹⁷ Today it is widely implemented in many vendor hardware platforms as well as a general tool to summarize network traffic by other means. There are a number of tools available for Netflow collected data. Using them for SSH attack monitoring is relatively straightforward since generally SSH attacks occur over TCP port 22. Netflow tools are good at monitoring and alerting on well known traffic characteristics such as this. Furthermore, you can use Netflow to monitor for TCP port 22 traffic from your hosts since a successful brute force attack may result in the compromised system becoming part of a larger brute force attack network.

DNS PTR queries

By default, many SSH server daemons will perform a series of DNS-based checks on a connecting IP address. This consists first of a DNS PTR type query for the connecting IP address (e.g. 1.2.0.192.in-addr.arpa.). The name associated with the answer is then used in an A or AAAA query to see if that answer matches the IP address of the connecting system. If not, typically a warning message is logged. If your SSH server performs this action, there are two places to watch for anomalies. First, you can watch your SSH server logs for warning messages when this DNS query check fails. Consult your SSH implementation documentation for details. In addition, you could monitor DNS queries at the recursive name server used by the SSH server. If you see an SSH server making unusual PTR queries for an IP address you do not recognize, or perhaps making an unusual number of PTR queries, this may be a telltale sign that the SSH server is undergoing an SSH attack.

Syslog

Most SSH implementations will log some minimal information about login attempts. Typically systems will log to the local disk, but to ensure survivability of those logs, you should have SSH server logs sent to a collector that can withstand attack even when other systems may be penetrated. If an SSH attack is successful, local logs may be one of the first bits of information to be wiped out by an attacker. Since syslog operates in real-time, an offline collector will help ensure you have some sort of audit trail of events leading up to an attack. Be aware that some login monitoring tools will not display some active SSH sessions. For instance, most login tools such as w, who, and last will not show SFTP connections. Be sure to examine the SSH logs and not just the lastlog entries. Ideally if you are able to understand login patterns for all users on the systems, you may be able to alert on anomalous patterns. For example, if a user normally logs in from a source address of 192.0.2.1, but suddenly is logging in from an IPv6 address 2001:DB8::1 then you may wish to investigate.

Community alerts and notification

There are a number of freely available sources of alert data related to SSH authentication attacks. Typically these are, minimally, IP addresses that have been identified as being associated with malicious SSH activity in the recent past. As with any third party provided data, you must use the data wisely and be wary of relying on it if you are going to use it to actively affect traffic. Dataplane.org provides its own sshpwauth report.¹⁸ The DenyHosts project is a cooperative among anonymous parties who share IP addresses that each identifies as malicious.¹⁹ The SSH blacklist (sshbl.org) is another source of IP addresses they identify as malicious.²⁰

Tools

There are a number of tools available that aim to help administrators both detect and respond to SSH password authentication attacks. Most fall into one of two types; alert-only or alert-and-respond. We list a number of the tools we are aware of below. Note, we avoid including generic log parsing tools, but many generic log parsers also support SSH-related events including password authentication issues.

sshdict.pl²¹

An early Perl script that reads SSH log files and attempts to report on IP addresses that are conducting brute force attacks. Uses a simple scoring mechanism.

Fail2ban²²

UNIX-oriented utility that scans log files for IP addresses responsible for too many password failure attempts. Can update a host firewall rule blocking abusive IP addresses.

sshdfilter²³

A Perl script for Linux distributions that reads a SSH log file and updates the local system firewall filter rule table, blocking IP addresses it detects conducting brute force attacks.

dataplane-openssh³

The Dataplane.org OpenSSH patches, disables password authentication in the original source code, while enabling detailed logging of client connections and password authentication attempts at the syslog INFO priority level.

Kojoney²⁴

A Python-based SSH daemon that emulates a SSH server in order to obtain additional insight.

Kippo²⁵

Inspired by Kojoney, another Python-based SSH daemon that emulates a SSH server in order to obtain additional insight.

sshguard²⁶

This utility written in C monitors log files and automatically blocks an attacking IP address. It can also automatically clear a filter after a set interval.

Conclusions

SSH password authentication attacks exist and are a popular form of malicious activity because they yield results for an attacker. Take away password authentication mechanisms and you only eliminate one vector in an architecture where multiple avenues of attack are possible. The aim for any administrator should be to improve their monitoring, prevention, detection and response capabilities. The aim of this whitepaper was to help shed some light on SSH password authentication threats and countermeasures as a means to help improve your security posture in one or more of those four areas. We welcome your comments, feedback and support. Contact us.

Pointers to Other Reports

• The SANS Incident Storm Center has occasionally highlighted SSH password brute force attacks, including here, here and here.
• Jim Owens and Jeanna Matthews used honeypots to analyze anonymous, remote SSH password authentication attacks. Their paper is here and presentation here.
• Daniel Ramsbrock, Robin Bethler and Michel Cukler profile SSH attacks including what attackers do once they gain unauthorized access. Their paper is here.
• The Norwegian Chapter of the Honeynet Project highlighted a number things they were seeing in their SSH honeypots in their 2008 status report posted here.
• On the Securi blog, Daniel Cid shows some familiar statistics and what he saw when miscreants would gain access through a SSH brute force attack. His blog post is here.