Auditing Secure Shell - Part I

This blog entry outlines a wide variety of audits and monitoring techniques that can be used to keep watch over the Secure Shell applications in use on your network. Examples for auditing SSH client and server configurations, vulnerabilities and logs will be discussed using Nessus, the Passive Vulnerability Scanner, the Security Center and the Log Correlation Engine.

This will be a three part blog entry where we will consider discovering the SSH applications, auditing their configurations and then monitoring their logs and network activity. This is part 1 of 3.

Discovering SSH Servers with Nessus Network Scans

Before any type of audit can be accomplished, an accurate inventory of all Secure Shell (SSH) servers should be preformed.

The Nessus vulnerability scanner can find SSH daemons running on many types of operating systems. When it finds an SSH daemon running, it will report several things.

Plugin #10881 "SSH protocol versions supported" will list the specific version of the Secure Shell protocol supported by the daemon with a report similar to the following:

The remote SSH daemon supports the following versions of the
SSH protocol :
. 1.33
. 1.5
. 1.99
. 2.0
SSHv1 host key fingerprint : c2:3f:77:2a:72:10:7d:7d:2a:49:8f:21:a4:d2:20:27
SSHv2 host key fingerprint : 1d:31:f3:6a:5b:c9:86:fa:93:ee:9c:d3:c9:c5:d2:10

This output also includes the SSH host key fingerprints of the daemon being scanned.

Plugin #10267 also identifies the detected SSH daemon and logs the specific SSH banner in use. It also audits which type of authentication methods are available as shown below:

SSH version : SSH-1.99-OpenSSH_3.6.1p2
SSH supported authentication : publickey,password,keyboard-interactive

Nessus will also attempt to enumerate any SSH daemon vulnerabilities that can be discovered through network analysis. There are many vulnerabilities associated with Secure Shell. At the time of writing this blog, searching for Nessus plugins that had the string "SSH" in them returned more than 100 unique plugins.

And lastly, Nessus will attempt to discover SSH servers regardless of which port they are on. Typically, SSH servers listen on port 22, but if a Nessus port scan or services probe is performed against non-standard ports, the SSH daemon will still be discovered. It has become common practice for administrators and/or hackers, to run an SSH daemon on a port other than 22 to "hide". Tenable has also encountered customers who have configured port forwarding firewalls such that connecting to a high port on the outside results in a network connection to port 22 on the inside to a certain server.

Using Credentialed Nessus Scans to Discover SSH Applications

If a credentialed patch audit of a host is also accomplished, Nessus will perform a patch audit of not only the SSH daemons, but any missing patches for SSH clients. There have been many client-side related vulnerabilities in SSH clients.

And lastly, if your credentialed scan occurs on Linux, the "Remote listeners enumeration" check, plugin #25221, will list all open ports and the name of the process which opened the network connection. This is another way to find SSH servers that may have been running on a a port other than 22, or were perhaps blocked by a firewall or ACL rule. 

Passive network monitoring with the PVS

The Passive Vulnerability Scanner can also observer Secure Shell connections. It accurately enumerates all SSH daemons and clients it observes in the network traffic. Here is an example listing of detected SSH applications and security issues from the "SSH (PVS)" plugin family as viewed under the Security Center:

Since the PVS sniffs network traffic it can see all ports. This makes it ideal to find SSH daemons running on ports other than 22. This also makes it ideal to identify security issues with SSH clients. In the above screen shot, there was a detect of a vulnerable "WinSCP" client. This detect was accomplished without any client side credentials of the Windows host running the WinSCP client.

Detecting Change

Once a baseline of known SSH servers and clients has been determined, it must be updated. There are two main ways to accomplish this - repeated Nessus scans and continuous PVS network monitoring.

For repeated Nessus network scans to look for new SSH servers, the Security Center can be used to schedule scans which discover new hosts, discover new SSH servers and also identify new SSH vulnerabilities. The Security Center can be set up to schedule these scans on a needed basis, and email and "new" results to asset system owners.

The PVS can also be used to find new SSH systems. Since the PVS is real-time, it can syslog any new type of SSH issue. The Security Center can be used to alert asset owners when new SSH servers are detected, or if new vulnerabilities have been discovered.

If more generic Nessus scans and PVS monitoring are ongoing, the Security Center can also manually be used to show "what is new". There is a filter in the Cumulative Vulnerability Database view which can specify a discovery filter. This parameter accepts a count of days such that all SSH vulnerabilities or audits discovered in the past 5 days could be displayed and analyzed.

For More Information

Part II of this post will consider auditing the configuration of SSH daemons and clients on UNIX systems. Part III will consider how netflow, firewall logs and other types of traffic can be used to audit SSH usage and abuse such as "leap frog" attacks.