Security through obscurity and SSH

Security through obscurity is generally considered to be a bad thing, especially when it relates to bugs in software or encryption methodologies. It is not about making a product or service more secure, but rather hiding some detail or vulnerability in the hope that no one finds it.

However, we can sometimes use the principle to good effect so long as we understand the limitations. Take securing the commonly used SSH service, for example. We often recommend running the SSH service on a non-standard port as a way to prevent the vast majority of brute-force attempts to crack system accounts. Anyone who operates an SSH server on the standard tcp port 22 will be very familiar with the many logged attempts to gain access and simply moving SSH to a non-standard port will eliminate the vast majority of these attempts. Why does this work? Well, the bad guys will typically scan a network segment for IP addresses running SSH services on port 22 and then run automated tools against identified hosts to attempt to gain access using commonly used username/password combinations. How successful are they? If they weren't getting some success then they wouldn't still be doing it. If you think your SSH server won't get detected or noticed amongst the millions of others out there then you are wrong. The average IP address will get probed on port 22 around 3-5 times per day. Interestingly, recent studies estimate that any reasonably sized botnet is capable of scanning the entire IPv4 address space for a single port in a single day so the bad guys have the capability to locate every single SSH server on the Internet running on port 22 in a day. That's scary!

By moving SSH to a non-standard port we are hiding our needle in the proverbial haystack of 65,535 available ports. But it's important to understand that it's still security through obscurity as we haven't improved the inherent security of the service, just made it harder to find. The popular nmap network scanning tool will by default scan about 1600 of those ports. However, if a determined attacker or one launching a targeted attack decides to probe your IP address they will still find the hidden SSH service if they happen to knock on the right port:

So picking a non-standard port a little less obvious than port 2222 is probably a good idea!

Taking it a stage further

However, we can take the concept a stage further. Besides hiding our SSH service on a non-standard port we can also run a second instance of the service on the standard port. Why would we possibly want to do that I hear you ask? Well, the second instance running on the standard port can be configured as a dummy service on which it is impossible to log in. The principle here is that we show attackers a door, the wrong door, in the hope that they will then hammer away at it rather than go looking for the real door. An example of how to run a second instance of SSH is detailed here. Once the second instance is set up it should be deliberately (mis-)configured to not allow logins. The simplest way to achieve this is probably with the AllowUsers directive by specifying a non-existant user (you MUST specify something - a blank AllowUsers will allow logins from ALL users):

Here we configure the dummy SSH daemon to run on the standard port 22, to not allow root logins (always a good idea) and to only allow logins from the user 'none' which (presumably) doesn't exist on the system. Now anyone attempting to gain access will be invited to enter their password none the wiser that it is impossible to log in as there are no valid username/password combinations.

Hopefully I have shown how with a little creative thinking we can use security through obscurity to our advantage to trick even the most determined of attackers into hammering away on the wrong door. Show the attacker what they are expecting to see whilst hiding away the real entry point. In addition, we can also use the dummy service for logging failed attempts and gaining valuable insight and information about those trying to gain access to our systems. But of course it's still security through obscurity.