Hiding In Plain Sight Doesn't Work

I do a lot of penetration tests and vulnerability assessments for an assortment of business of all sizes. While doing these types of tests, I run into a lot of goofy configurations, strange setups, and wacky ideas that are an attempt by the client to improve security. The most head-scratching setup I constantly run into involves SSH on a port other than the one it is assigned, Port 22.In recent years, a low tech, brute-forcing of user names and passwords has gained popularity because of how easy it is, so it seems to be a widely held belief among system administrators that by changing the default SSH port, they increase their level of security.

In honor of this phenomenon, I now keep a text file of the ports I find an SSH daemon running on, and the explanation offered by the administrator of how this change improves security. I won't list the explanations here, but here's the gist of their justifications: attackers will not bother launching a scan against the entire port range of a box, and a scanning tool is not advanced enough to grab service banners. Admins generally provide me with these explanations during a post assessment wrap-up meeting, and they are typically surprised that their SSH daemon running on port 65022 is listed in the report at all. It's almost like pointing out a trap door or a mirror in a magic act. This is not meant to make fun of these system administrators. In fact, I applaud anyone who actually thinks enough about security to try something new. The problem I have with this constant reinvention of the wheel is that clever little tricks like this will often get overlooked when it comes time for patching, setting up access controls, and regular maintenance.

A few months ago, I ran into a situation that epitomized why this sort of port trickery is not just bad practice, but downright dangerous. During an audit for a financial institution, an SSH server was found to be listening on a port above 10000 and was accessible to anyone on the Internet. To compound the problem, the host also ran a Web server with a custom-written PHP Web application that was vulnerable to a file-retrieval problem, which gave me access to /etc/passwd. After a few minutes, "John the Ripper" and the usernames had passwords associated with them -- allowing for an easy login for an outsider. I need to pause for a second and talk about the security setup there. The security manager was mistakenly under the impression that SSH was administratively forbidden by the corporate security policy and enforced at the firewall. Remote access is granted by requiring administrators to login through a VPN first, and then SSH to a server. When the security manager performed scans, only well-known ports were targeted. Any request by a system administrator to open port 22 to a server was denied. Soon, SSH went from port 22 to random ports above 10000, and the firewall did not stop them because the rules were written to protect the only well-known ports. The SSH port problem makes compromising the network much easier, and that server provided a foothold in the network that allowed the rest of the hosts to be compromised. Needless to say, the security manager was furious. The results of the audit very plainly showed that 32 of the 40 servers they had Internet-facing had SSH open to the world on a port above 10000. They were surprised I would waste my time scanning the entire range of ports on the server. That's like not bothering to lock your door because no one will check it.

To set the record straight, most automated SSH brute-force tools will only check port 22, moving on if it is unreachable. A directed attack -- someone who is after you or something you have -- will have time to wait. The popular tool Nmap can find open SSH servers with just the command line option "-sV." Running a test of Nmap looking for just port 22 versus scanning all available TCP ports yields a difference of about 20 seconds. Although that can add up, the dirty little secret of attackers and penetration testers is that nobody sits in front of a console waiting for the scans to complete. You start the scan and wait to get notified when it is complete. Because of this, the "time consuming" argument holds no merit. Keep this in mind: Circumventing normal operational procedures will not make you more secure, and in most cases it has the exact opposite result. If you are worried about people brute-forcing your SSH server, run some type of access control that will restrict who has access to it.

David Maynor is CTO of Errata Security. Special to Dark Reading