Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


05:16 PM
David Maynor
David Maynor

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.

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

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Former CISA Director Chris Krebs Discusses Risk Management & Threat Intel
Kelly Sheridan, Staff Editor, Dark Reading,  2/23/2021
Security + Fraud Protection: Your One-Two Punch Against Cyberattacks
Joshua Goldfarb, Director of Product Management at F5,  2/23/2021
Cybercrime Groups More Prolific, Focus on Healthcare in 2020
Robert Lemos, Contributing Writer,  2/22/2021
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Building the SOC of the Future
Building the SOC of the Future
Digital transformation, cloud-focused attacks, and a worldwide pandemic. The past year has changed the way business works and the way security teams operate. There is no going back.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-03-01
The fix for CVE-2020-9484 was incomplete. When using Apache Tomcat 10.0.0-M1 to 10.0.0, 9.0.0.M1 to 9.0.41, 8.5.0 to 8.5.61 or 7.0.0. to 7.0.107 with a configuration edge case that was highly unlikely to be used, the Tomcat instance was still vulnerable to CVE-2020-9494. Note that both the previousl...
PUBLISHED: 2021-03-01
When responding to new h2c connection requests, Apache Tomcat versions 10.0.0-M1 to 10.0.0, 9.0.0.M1 to 9.0.41 and 8.5.0 to 8.5.61 could duplicate request headers and a limited amount of request body from one request to another meaning user A and user B could both see the results of user A's request...
PUBLISHED: 2021-03-01
In Dataiku DSS before 8.0.6, insufficient access control in the Jupyter notebooks integration allows users (who have coding permissions) to read and overwrite notebooks in projects that they are not authorized to access.
PUBLISHED: 2021-02-27
SerComm AG Combo VD625 AGSOT_2.1.0 devices allow CRLF injection (for HTTP header injection) in the download function via the Content-Disposition header.
PUBLISHED: 2021-02-27
An issue was discovered in through SaltStack Salt before 3002.5. salt.modules.cmdmod can log credentials to the info or error log level.