Obscurity Through Security

An old colleague recently sent me a message to ask for my opinion on something. He was reading a penetration testing report — not one of ours, sadly — which raised an issue that Secure Shell (SSH) was running on its default port of 22/tcp. The report claimed that this was “a lack of defence in depth”; the recommendation was to move SSH to a random, more obscure port.

My first thought was “that’s rubbish, you should never rely on security through obscurity.” I’m not alone in this line of thinking, it’s a view held by security experts for over a hundred years. In 1851, a locksmith named Alfred Charles Hobbs published information about the weaknesses of state-of-the-art locks. He was accused of making the locks more vulnerable by disclosing his methods. He replied, “Rogues are very keen in their profession, and know already much more then we can teach them.”

This principle is also generally accepted in cryptography. Projects like OpenSSL and PGP, which respectively secure most of the Internet and implement “military-grade” encryption both have their source code publicly available. So, it’s widely accepted among security experts that obscurity should never be the only security mechanism.

Hang on. On that last line, the word “only” changes my old colleague’s question completely. His report only recommended that SSH be moved to a non-default port as part of a defence-in-depth approach. Maybe I’ve jumped on my soapbox too quickly. They weren’t proposing wholly relying on obscurity as a defence mechanism, but rather to use it in addition. After all, the SSH service was fully patched and required certificate authentication, so what’s the harm in moving it? It only adds another challenge that a would-be-attacker must overcome, and it would probably reduce the number of drive-by attacks on the service.

But let’s face it. A determined attacker is going to find your SSH service regardless of what port you hide it behind. Your SSH service, if patched and properly configured, is going to keep them out. Is the inconvenience of running it on non-default port worth it? From a day-to-day operations point of view, you’ll need to make sure that all your beloved users remember the new port number— along with everything else. How many support tickets and man-hours are you going to waste because users forget which port the service is on?

Think of it as your front door. If like most well-adjusted people, your front door is in plain view at the front of your house then you may get the odd ne’er-do-well having a go at the door handle. That’s fine because you rely on your locks to keep out unwanted visitors. Now say you think about hiding your front door, such as behind a bush or by placing it on the side of your house. Yes, you’d probably get fewer people trying the handle, but you would also get genuine visitors calling you to ask where the door is. Are you any more secure for hiding the door? No, because you’re still relying on door’s lock for security. An intruder who is determined enough to try and pick the lock is going to be determined enough to find all your property’s entry points.

One advantage to leaving your SSH port on 22/tcp is that you’d hope the administrators will prioritise patching and securing the configuration. You’re less likely to have someone think “Meh, I don’t need to patch that straight away because it’s not on a default port.”

Of course, you could question: Why is the SSH service publicly exposed at all? Certainly, in our reports we would raise this as a ‘Publicly Accessible Administrative Interface’ low-level issue. That said, in the circumstance of my old colleague there was a valid business case for exposing the service and it was also patched and well-configured.

To summarise: If someone wants to change the default port of a service, would we advise against it? No; it’s not going to do any harm. To ask the opposing question, if someone is running a service on the default port, would we advise that they do move it to a non-standard port (even as part of defence-in-depth)? No, place trust in the security mechanisms you have in place.