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 inurl:isc.sans.edu 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:
https://isc.sans.edu/port.html?startdate=2013-01-01&enddate=2014-01-16&port=22&yname=sources&y2name=targets

However, this past week we saw an unusual spike in TCP port 222:
https://isc.sans.edu/api/topports/records/10/2014-01-13
and
https://isc.sans.edu/api/topports/records/10/2014-01-14

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.

https://isc.sans.edu/port.html?port=222

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
Metafore