You Can Run, but You Can't Hide (SSH and other open services)

Published: 2014-01-20
Last Updated: 2014-01-20 18:35:55 UTC
by Rob VandenBrink (Version: 1)
8 comment(s)

In any study of internet traffic, you'll notice that one of the top activities of attackers is to mount port scans looking for open SSH servers, usually followed by sustained brute-force attacks.  On customer machines that I've worked on, anything with an open port tcp/22 for SSH, SFTP (FTP over SSH) or SCP will have so many login attempts on these ports that using the system logs to troubleshoot any other problem on the system can become very difficult.

We've written this up many times, and often one of the initial things people do - thinking that this will protect them - is move their SSH service to some other port.  Often people will choose 2222, 222 or some "logical" variant as their new home for SSH, this really just takes away the background noise of automated attacks, real attackers will still find your service.  We've covered this phenomena and real options for protecting open services like SSH in the past (google for ssh for a list)

What got me thinking about this was a bit of "data mining" I did the other night in the Dshield database using the reporting interfaces on the ISC site, as well as our API.  Port 22 traffic of course remains near the top of our list of ports being attacked:

However, this past week we saw an unusual spike in TCP port 222:


On the 14th, port 222 actually topped our list.  This event only lasted 2 days, and was primarily sourced by only two IP addresses.  Note the other spike in December.


This looked like a full internet scan for port 222, sourced from these two addresses (I won't call them out here).  Looking closer at the IP's, they didn't look like anything special, in fact one was in a DSL range, so two days for a full scan is about right, given the fast scanning tools we have these days and bandwidth a home user will usually have.

The moral of the story?  No matter where you move your listening TCP ports to, there is someone who is scanning that port looking for your open service.  Using a "logical" approach to picking a new port number (for instance, 222 for scp or ssh, 2323 for telnet and so on) just makes the job easier for the attacker.  And that's just accounting for automated tools doing indiscriminate scanning.  If your organization is being targetted, a full port scan on your entire IP range takes only a few minutes to set up and will complete within an hour - even if it's on a "low and slow" timer (to avoid your IPS or to keep the log entry count down), it'll likely be done within a day or two.  Moving your open service to a non-standard port is no protection at all if you are being targetted.

If you don't absolutely need to have a service on the public internet, close the port.  If you need to offer the service, put it behind a VPN so that only authorized folks can get to it.  And in almost all cases, you don't need that SSH port (whatever the port number is) open to the entire internet.  Restricting it to a known list of IP addresses or better yet, putting it behind a VPN is by far the best way to go.  If you MUST have "common target" services like SSH open to the internet, use certificates rather than or in addition to simple credentials, and consider implementing rate limiting services such as fail2ban, so that once the brute-force attacks start, you've got a method to "shun" the attacker (though neither of these measures will protect you from a basic port scan).

Rob VandenBrink

Keywords: API SSH
8 comment(s)


Just to be clear though, port re-location for high traffic attack services is STILL a good idea. It does NOT reduce the risk from a targeted attack, but it DOES lower threat event frequency and often dramatically. This is a good thing, and in the case of one of your examples, should return your system logs back to a useable state for actual troubleshooting and other (even security) uses.
Port re-location DOES make the job of detection and monitoring significantly easier in many cases. This benefit alone makes it a worthwhile move.
However, I still agree, re-location is a last resort. Removal, compensating controls and hardening should always come first.
I've always found that requiring a client-side certificate on the device port does wonders. You don't have to mess with any configurations that might be reset to the default by upgrades and if someone tries to connect to the port and doesn't have the proper certificate, their connection gets dropped. End of problem.
Public key only for auth pretty much negates these scans. The old axiom "security through obscurity is not security"... is true, but moving off of port 22 to a non-obvious different port cuts down on the noise that is logged, making it easier to spot targeted attacks vs the random background "script kiddy" noise, and is worth doing for that reason alone in my opinion. One of the first things I would do (after enabling public key only auth) is move ports. Simple and easy to do and really no downside, so why not?
[quote=comment#29312]I've always found that requiring a client-side certificate on the device port does wonders. [/quote]

Yup. Or requring a strong 2-factor authentication... :-)
What comes to mind is closing off port 22 completely, and not allowing SSH from the world on any part.

For a small number of systems used for SSH-based offsite access to get into the network....
Port knocking, or rather.... fwknop
Could this be happening by researchers who report out on scanning the Internet and the findings? I happen to know of at least one very prominent name in the security business who does this. Perhaps this may be an item to consider to filter out findings that are not as they seem.
We relocated ssh ports on about sixty client Internet-facing devices just to reduce log clutter, not as a security method. We were shocked to see attacks dropped from hundreds an hour to zero a year. I was surprised to see no scans. I expected the script kiddies to drop out; I just didn't expect to see no one else. We saw the same complete elimination of connection attempts whether it was SSH, VNC or RDC. We did see a few HTTP scans, but more than 99% connections of those simply stopped. We do do many of the other security methods mentioned, however, I was amazed to see security through obscurity working so well. :-)

I am not complaining, just bemused.
While security researchers must contribute some traffic, I doubt it is appreciable.

Out of the last 65,000 SSH probes we logged, 62,000 were from China, 3,000 from schools, dark net, and places such as Ukraine, Kazakhstan, etc, and only a fraction from "known" addresses. Some of those could be security researchers, but I doubt much.

Diary Archives