On Using Alternate Ports for SSH

There’s a post I read the other day that’s really been stuck in my craw (link is below). It was about the effects of moving SSH to an alternate port. The post starts out like this:

Best practices state that you should run ssh on an non-standard port. Unfortunately some programs use port 22 by default and it isn’t obvious what the switch is to change this port.

First, whose best practices say this? Some self-appointed security expert on the web? I ask because this sort of activity is known as “security through obscurity” and isn’t regarded well as a security tactic. The Wikipedia article on security through obscurity has a section called “Arguments For” which reads more like an apologist’s version of the “Arguments against” section. Even the end of the pro-obscurity section concedes:

…it can be argued that a sufficiently well-implemented system based on security through obscurity simply becomes another variant on a key-based scheme, with the obscure details of the system acting as the secret key value.

There is a general consensus, even among those who argue in favor of security through obscurity, that security through obscurity should never be used as a primary security measure. It is, at best, a secondary measure; and disclosure of the obscurity should not result in a compromise.

That’s sort of like my argument to my wife about wearing wedding rings: if that’s the only thing keeping us faithful to each other then we’ve got problems.

My second argument is that if you connect to OpenSSH, no matter what port, it tells you it’s OpenSSH:

$ telnet localhost 10000
Trying ::1...
Connected to localhost.
Escape character is '^]'.
SSH-2.0-OpenSSH_5.3

“Oh yeah, how will they know to look for port 10000?” someone might ask.

$ nmap -O localhost

Starting Nmap 6.01 ( http://nmap.org ) at 2012-10-19 00:36 CDT
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000032s latency).
Other addresses for localhost (not scanned): 127.0.0.1
Not shown: 974 closed ports
PORT      STATE SERVICE
25/tcp    open  smtp
110/tcp   open  pop3
143/tcp   open  imap
993/tcp   open  imaps
995/tcp   open  pop3s
10000/tcp open  snet-sensor-mgmt
Device type: general purpose
Running: Linux 2.6.X|3.X
OS CPE: cpe:/o:linux:kernel:2.6 cpe:/o:linux:kernel:3
OS details: Linux 2.6.32 - 3.1
Network Distance: 0 hops

OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 1.92 seconds

Hacker: “Hmm, looks like a Linux mail server, but there’s no SSH. There is something weird on port 10000… Maybe I’ll telnet to it and see what it does!” Of course, upon telnetting to it OpenSSH tells them it’s OpenSSH. The sneaky port moves took about 10 seconds to defeat, and that’s if the attacker is a moron.

“So what?” they ask. “Why are you complaining? At worst it’s no better than the default, and maybe it’ll work.”

I contend that by making this type of change you’re making the system more complex. Complexity isn’t good — it drives up costs. Everything you change away from the defaults requires:

education, because absolutely everybody & everything assumes that SSH is on port 22,
maintenance, in that you need to keep the SSH configuration up to date, along with all the other stuff that connects to it,
testing, as every change to every ancillary system that connects to your hidden SSH will need to be tested to make sure it still works after every patch,
documentation, so that when you’re hit by a bus the poor sap who takes over for you can figure out what the hell you changed,
and customization of other systems, which was the whole point of the original post, that rsync requires a non-obvious solution, which in turn wastes more time because you have to look up that non-obvious solution, test it, document it, etc.

Since it’s a dubious security tactic anyhow wouldn’t you rather spend time implementing reputable security controls like proper firewalls, two-factor authentication, password complexity, proper SSL certs, VPNs, or, god-forbid, good patching techniques? More importantly, what would your boss say about the ROI of this alternate port goat rodeo? Tell your boss that you’re spending hours on something that might deter a hacker for a few seconds and see what they say.

IT staff should always be fighting complexity, and only adding more when there’s clear value gained. This is not one of those situations. Leave SSH right where it belongs and work on a real problem your organization has.