Oh No! Is SSH Not Secure Enough?

A lot of people use Secure Shell (SSH) as the remote administration tool of choice. In this day of Internet worms and zero-day vulnerabilities, it is important to get every bit of security one can possibly get their hands on. One of the most important security systems administration tools is SSH. Recently, an Informit Article describes how SSH can be more dangerous and can give a false sense of security to administrators.

SSH is one of the most attacked services. As the SANS Institute states in its current top 20 vulnerabilities roundup, “Of particular interest this year are attacks against SSH.” SSH is rated U1, the top UNIX vulnerability. Why is SSH such a target? In this article, you’ll learn why people are implementing SSH on Windows, mainframe, and UNIX devices. We’ll explore port forwarding, a cool SSH capability. Then we’ll take apart the clever administrator’s SSH design, including attacks against key authentication itself.

Most of the exploits here are pretty difficult to execute. But, one can never be too careful. Here are some SSH tips that can be done to improve your current setup:

  • Change the Default SSH Port. This can’t do much. But, by changing the default port, you can make it a wee bit harder for the bad guy to get in.
  • Restrict Access to the SSH Host. This is especially true if you are using this host as a vector to other parts of your protected network. Only allow particular networks and hosts to access your SSH service. This way you can limit the potential pool of attacker hosts. Host-based firewalls are a good place to put these restrictions. It is also best to put the SSH host in the DMZ and restrict access from this host to only the barest minimum of services in the secure network.
  • Restrict SSH Access to Particular Users. Identify users who should be given SSH access. Not everybody should have access to this critical service. Many systems have been compromised because one user couldn’t keep his account safe. In most cases, this user did not even need SSH access.
  • Implement Security in Multiple Layers. If you can restrict access to a host do it in as many layers as you can (the network perimeter, the department firewall, the DMZ, and/or the host itself). The more layers the harder it is to get in.
  • Disable unecessary SSH features. A lot of the exploits in the article have to do with port and agent (authentication) forwarding. I believe that these should be disabled unless absolutely necessary. If they are necessary great caution must be placed in their use. Other dangerous SSH features are X11 forwarding, SSH version 1, agent forwarding and key-based password-less authentication. If you have to use these be careful.
  • Use one-way SSH Tunnels. If you have to use SSH tunnels make them one-way. It is possible to get compromised because an unsecured network (like your home) was used as a vector to enter your secured network.
  • Update Software. Since SSH is commonly used to protect important systems and hosts, it is important to kept it up to date. A vulnerability in your SSH host can lead to further outbreaks in your network.
  • Review logs. This is especially true for security and access logs. Try to look for anything unusual in them. There are tools that automatically do this for you. These can help. But, nothing beats swimming through /var/log/messages and /var/log/secure. Intrusion Detection Systems can also help do some monitoring in the network level.

The bottom line of all these tips are to be careful. Even, the best information security tools and technologies are of “no use” if not implemented properly. These tips are just the tip of the iceberg when it comes to protecting your SSH setups. The Principle of Least Privilege is also a good rule to keep. There are much much more things you can do. However, I hope that this would serve as a good start.

Leave a Reply