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.
- Systembash’s “Using rsync on an Alternate SSH Port or with OpenSSH Keys”
- Wikipedia entry for “Security Through Obscurity”
You seem to be missing something here. Running an administrative service on a non-standard port may not foil a probe from a human, but it certainly cuts down on the bot noise.
Not missing anything. Use iptables/ip6tables. There’s absolutely nothing a human will do that a bot won’t eventually do, too, including inspecting all open ports to see what they are.
I always suggest against running services on non-standard ports. It makes things harder (and complex), but doesn’t provide any positive value.
If you have a problem with lots of logging attempts from bots, perhaps you should look at filtering which IP ranges are allowed to connect to SSH.
THANK YOU. Finally somebody with some common sense.
You don’t even need the extra telnet to see it’s SSH, use the ‘-sV’ switch for version detection:
% nmap -sV -p 7022
Starting Nmap 6.01 ( http://nmap.org ) at 2012-10-21 09:44 UTC
Nmap scan report for
Host is up (0.20s latency).
PORT STATE SERVICE VERSION
7022/tcp open ssh OpenSSH 5.5p1 Debian 6+squeeze2 (protocol 2.0)
Service Info: OS: Linux; CPE: cpe:/o:linux:kernel
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 1.32 seconds
%
Oooh, I had forgotten about that. I’m not an expert nmap guy, that’s for sure. 🙂 Thanks!
Well from my own experience being sysadmin-amateur 🙂 i used combination of sshd + denyhosts + some iptables rules on my home router/gateway. It had public IP from isp rande and port 22 was quite a target. After moving it to some obscure port amount of activities on ssh dropped by like 95 per cent. And yeah those were mostly bots trying various default usernames and logins.
I’m glad it removed the annoyance of bots. Don’t confuse it with adding security, though. A smarter bot would have no trouble negotiating the change, and it’s just a matter of time until the script kiddies have a smarter bot.
Obviously 🙂 if somebody is determined to get somewhere in, it won’t help. Only stopping some script kiddies and bots.
Anything which port-scans me to see what port my non-standard service is on should be banned before it finds anything much. Port-knocking and moving things to non-standard ports are both “security though obscurity”, but I see nothing wrong with adding them to occasional boxes where you want to add some extra hoops (however minor) for attackers to jump through.
Once it’s common that attacks look for ssh on alternative ports then do something else, but until then why not?… (sometimes 🙂
Port knocking isn’t security through obscurity, it is a key-based authentication system that uses specially-crafted TCP packets or specially-crafted access sequences to open a port to the IP you’re coming from. That approach has problems, including supportability and effectiveness through client firewalls, but in my opinion it can be an interesting addition to your defense-in-depth.
But in SSH you can add security by the container-ship *and* simultaneously cut complexity and improve user-friendliness by just turning on public key authentication and turning off password authentication. After you’ve set up your public/private key pair of course.
Hackers know that trying to brute-force a public/private key pair is a complete waste of time. They don’t even try.
Security by obscurity is misnomer, as you point out it doesn’t actually add security. In saying that there are other benefits as pointed out by Alex S
I do use non-standard ports public facing servers simply as i does cut down on noise, one tactic I found particularly effective (for the likes of ssh) was port knocking.
The advantages of reducing bot attacks shouldn’t however be overlooked, if you have a high volume of attacks hitting your servers from automated bots then the logs generated from those attacks can obscure entries that might be cause for concern or just as bad a bot might “get lucky” after all you are relying on “jbloggs” not using “password” as his password.
Nothing is safe from someone with the skill and determination that wants it, failing software/hardware bugs they can just social engineer staff. The best we can do is mitigate the risk and try to make the reward not worth the effort.
ALl firewall solutions, at least the ones that I have used, all block port 22 be default. If they don’t, its in the configuration to do so.
Adding complexity where its not needed is a waste of resources.
Thanks for writing this Bob!
A followup question: is there any value in obscuring version numbers of the software we run, like ssh, apache etc ?
I think there’s value to obscuring the version numbers, in that you are making the attackers work harder because you aren’t giving them information they could use to attack you. I realize the same “work harder” argument can be made for moving SSH, it’s just that OpenSSH will always broadcast what it is for protocol reasons, so the only “working harder” is on the organization’s end.
Not leaking information to an attacker is a little different, and has different effects, but it’s a relatively trivial change on the system. It doesn’t affect the supportability, and it makes the attacker work harder to find flaws. “Working harder” in that way means that your other defenses have more opportunity to be effective.
So yes, I think it’s valuable in that it potentially has a high ROI (on a very small investment).
I’m glad I’m not alone Bob.
There are quite a few organizations that do this but there’s a pretty big downside that they don’t think about until after the users start calling. I know one EMR company that decided to move their Microsoft Terminal Services (RDP) to some port above 10,000 – let’s just say 13389 (see what I did there – how many times have you seen that before? aka 10443). That was fine although there are a number of public hotspots and firewalled networks that only allow outbound access on common well known ports – again trying to enact some measure of security. With the Terminal Services port changed to 13389 now their customers can’t access their application.
The response from the EMR company… that’s a security measure.
Cheers!
May be a late reply, but there you go, just read on /.:
http://bsdly.blogspot.ca/2013/02/theres-no-protection-in-high-ports.html
Bots now bruteforcing other ports too. It was just a question of time.