Contents
Overview
What Is SSH?
Understanding SSH Attacks
Sources of the Attacks
Key Lessons Learned
PermitRootLogin? Why?
Does the Site Have a Password Policy?
Have Administrators Considered Public Key Logins?
Are All Users Allowed? Why?
Is the Server Exposed to Untrusted Hosts? Is It Necessary?
Should You Run the SSH Server on a Different Port?
Conclusions
Overview
This white paper provides an overview of Secure Shell (SSH) login activity that administrators and engineers may use to reduce the exposure and risk of compromise via SSH.
What Is SSH?
RFC 4251 describes SSH as "a protocol for secure remote login and other secure network services over an insecure network." Most administrators use SSH as a secure replacement for Telnet and the older BSD r commands such as rsh and rcp. SSH provides similar functionality while offering encrypted communications, password-less logins via public key authentication, and host-based verification.
Understanding SSH Attacks
Because SSH provides mechanisms for remote access or remote file transfer, attacks against SSH typically either attempt to gain remote access to a system or to cause a denial of service condition. This paper will focus on the attempts to gain remote access to a system using data collected from an SSH honeypot on the Internet during a period of approximately 6 months.
Typically, SSH servers listen for connection attempts on TCP port 22. After the three-way handshake completes setting up the TCP connection between the client and server, both client and server exchange SSH version information and cryptographic encryption keys. After the encrypted channel is established, the remote user can attempt authentication. If this authentication fails, the connection is closed. If the authentication succeeds, the user is granted remote access to the system.
The SSH honeypot was configured to allow logins from any location using common username and password combinations. Login attempts for less common usernames were recorded even if they were unable to successfully authenticate to the system. After a user was logged in, he or she entered an emulated environment that allowed observation of the attempted logins and any actions that the user attempted after the successful login. Although the users' attempted actions may be interesting, this paper will focus only on the access attempts. In general, users attempted to gain knowledge about the server—such as the processes running on the system and the version of the operating system—and to download files that could allow them to increase their system privileges or run software such as an IRC network bouncer.
The most popular account used in the attempted logins was the username root. The root user has superuser privileges and is a well-known account for UNIX-, Linux-, and BSD-based systems. This account is very powerful:
- Read, delete, or copy any file on the local system
- Reset any other user's password on the local system
- Use the identity and privileges of another user
- Access devices that are recognized by the running operating system kernel
- Access the memory of processes that are running on the system
- Install software
- Execute any program
During the observation period, we observed approximately 1.56 million total access attempts. Login attempts for the root user accounted for 34.47 percent of all login attempts in the SSH honeypot. This is best visualized in the following figure, which depicts the top 20 accounts for which logins were attempted:
Figure 1. User IDs Attempted
In the preceding graph, the bar for "All other logins" accounts for 47.26 percent of attempts to log in to the SSH honeypot and represents 17,312 different user IDs that were not in the top 20 user IDs.
There are other account login attempts worth noting. For example, the user IDs oracle, mysql, and postgres are all used for popular database packages. The associated packages are typically installed and configured to run as one of these user IDs. Not to be left out, the user IDs of other database packages such as Informix and Sybase were tried as well, just not often enough to qualify for the top 20.
There are a number of accounts similar to admin in the top 20. Not only did accounts such as admin, administrator, administrador, andadministration get tried, but so did other variants such as admin2, adminsite, sysadmin, and adminroot. There were also some account names with an international twist, such as administrateur.
Those who think that renaming the user ID in a foreign language may offer some protection would be wise to reconsider. Not only didstudent make it into the top 20, but further down in the list is the Spanish version of "student": estudiante.
Brute-force login attacks such as those attempted against the SSH honeypot are usually carried out by using a dictionary of user IDs that are commonly found on a system, along with slight variations on those users. If a known or guessable user ID also has a weak, easily guessable password on a particular system, it is easier to gain access to that system. Some well-known combinations of user IDs and passwords are easy to find on the Internet. Sometimes products are shipped with default accounts and passwords. Common examples might be admin/admin, root/password, or admin/cisco. Continued use of default passwords after the initial configuration of products is highly discouraged, and it is advisable to consider this practice to be a policy violation.
Sources of the Attacks
Geographic distance has little relevance when dealing with hosts that are logically located on the Internet, which is physically worldwide. Regardless of the physical location of an attacker, the Internet makes everyone close enough to break in and steal things. Thus it can be important to examine the source of login attempts. For the SSH honeypot, the top 50 attackers were sourced from 19 countries. In the following figure, two countries in particular stand out: the United States (U.S.) and China.
Figure 2. Top 50 Attackers by Country
What can we conclude from this graph? Actually, not much because more information is needed. Does it mean that the U.S. and China are filled with folks who want to break into others' systems? Not necessarily. What it does mean is that China and the U.S. had a higher number of systems in the top 50 attackers (16 and ten systems respectively). These tallies could be a result of the percentage of the population with Internet access, the large number of people in those countries who are on the Internet, or possibly the number of vulnerable or compromised systems in those countries. What we can gain from the geographic data is the ability to report the remote IP addresses of those who accessed the honeypot to the proper individuals who can fix the compromised hosts. Knowing where the system is physically located can provide a route for resolving the problem for those countries that have country-level computer response teams to handle network security issues within their jurisdictions.
If we look instead at the top 50 attackers from a volume perspective, the graph looks much different.
Figure 3. Top 50 Attacking Countries by Volume
In the preceding graph, the U.S. and China are still a significant chunk of the volume of login attempts, but note how much larger the bars for Columbia (CO) and Poland (PL) have become. In Figure 2, the U.S. accounted for ten of the top 50 attackers, and China had 16 of the top 50. In that figure, Columbia and Poland had only three of the top 50 and two of the top 50 attackers, respectively.
Does this mean that administrators should block network access from certain countries? Not necessarily, at least not because of the results shown in Figures 2 and 3. We will get back to this point later.
All that these graphs depict is where the login attempts originated. They do not depict the location of the actual miscreant who is attempting to break into the honeypot. The miscreant could be thousands of miles away or as close as next door. We can never know, because those who wish to do harm on the Internet often use compromised machines from all over the planet to accomplish their means and evade detection and prosecution.
Key Lessons Learned
PermitRootLogin? Why?
Figure 1 showed just over a third of the login attempts trying to access the system via the user ID root. There is very little reason for enabling root to log in directly to the system via SSH. Disabling root logins is easily accomplished using the configuration file for the SSH daemon. On systems that are running the OpenSSH version of the SSH server, simply setting the configuration directive PermitRootLoginto no is all that is required. Usually PermitRootLogin is set to no by default. After changing the SSH configuration to disable root logins, administrators must restart the daemon to force it to reread the configuration file.
Is there a downside to this configuration? The only disadvantage is a slight amount of inconvenience. Instead of being able to log in directly and have administrative privileges immediately available, users may need to run a utility such as sudo or su after authenticating to enable the higher privilege level. From a security standpoint, this configuration is typically preferable because it requires double authentication before such privileges are granted and does not easily facilitate attempts to guess the password of the root user. It also provides more detailed log messages—beyond simply an IP address—to identify those users who have attempted to increase their privilege level.
Does the Site Have a Password Policy?
If a site does not have a password policy, administrators are advised to seriously consider implementing one and adhering to it. Best practices for user accounts and passwords are readily available. Most policies would have provisions for properly securing system accounts such as those for database packages (for example, accounts with the usernames oracle, sybase, informix, mysql, andpostgres), disallowing shared accounts for individual users, and specifying acceptable reuse of passwords and a minimum password complexity.
If login access via a password must be permitted, the user ID is often not a secret so the password must be sufficiently strong to withstand brute-force guessing attempts. Guidance for sufficiently strong passwords typically includes a minimum password length along with a sufficient random mix of upper- and lower-case characters, numbers, and symbols.
Have Administrators Considered Public Key Logins?
The SSH protocol allows users to create a public/private key pair for authentication. The user simply copies his or her public key into a file on the remote host under the user's account and stores the private key locally. The private key can and should be protected by an additional passphrase on the local machine. When the user logs in to a system via SSH, the user never types the local password on the local machine; he or she simply uses the public/private key pair for authentication along with the passphrase used to secure the private key.
Are All Users Allowed? Why?
Using the SSH configuration file, administrators can specify users and/or groups of users that are specifically allowed or denied login via SSH. Besides the normal precautions regarding system accounts, such as changing the shell to something invalid or scrambling the password on the account, administrators are advised to take the extra step to deny those accounts access via remote login unless it is truly necessary.
Is the Server Exposed to Untrusted Hosts? Is It Necessary?
We mentioned earlier that we would get back to the point about blocking access from hotspots of malicious activity on the Internet. If administrators must expose any system on the Internet, including an SSH server, they are advised to consider who will need to access it. Compromised hosts come and go on the Internet, and keeping up with their IP addresses may be too much work because doing so will require frequent updates. For small companies or those who configure special-purpose servers, administrators may very well have a pretty good idea of the location of any legitimate remote users. If so, these administrators can take precautions to accept connections only from those locations. These controls can be accomplished via many methods, including but not limited to the following:
- Router access lists
- Firewall rules
- IPtables on Linux-based systems
- TCPwrappers
It is important to note that steps may need to be taken to limit access via both IPv4 and IPv6.
Should You Run the SSH Server on a Different Port?
The conventional port on which an SSH server listens for incoming connections is TCP port 22. In our observations of the honeypot, we did not note any other obvious connection attempts for SSH on any other ports. It is possible to run SSH on a port other than TCP port 22. From our data, moving the SSH server to run on a different port would have provided some level of protection from the attempted logins because the access attempts may have used a tool that tries only the default SSH port.
Often this kind of approach is referred to as "security through obscurity" because it only hides the port where the server is running. Simply moving the SSH server to another port will not secure the server from a would-be attacker if the attacker learns the new port. A determined attacker can also quickly find the SSH port by using commonly available tools.
Conclusions
The first steps in securing any asset on the Internet are to configure it correctly, employ best practices, and limit the attack surface of the asset. Securing an SSH server can be done cheaply by using the security features offered in the product as well as by using protective features on the network devices through which traffic flows to and from the SSH server.
This document is part of the Cisco Security portal. Cisco provides the official information contained on the Cisco Security portal in English only.
This document is provided on an “as is” basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information in the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document without notice at any time.