Security from Obscurity

Corey Nachreiner, Director of Security Strategy and Research at WatchGuard Technologies explains why it’s time to re-evaluate the idea of ‘security by obscurity’ I am sure many of...

Corey Nachreiner, Director of Security Strategy and Research at WatchGuard Technologies explains why it’s time to re-evaluate the idea of ‘security by obscurity’

I am sure many of us think that hiding our house keys under a plant pot or fake rock will do a good job of stopping people breaking into our house. After all, how many burglars are likely to find a key if it is well hidden from sight? The only problem is that if the key is discovered by a diligent intruder or simply by accident – your entire house security falls apart.

Maybe that is why most information security professionals deride the idea of ‘security by obscurity’ when it comes to protecting critical systems and data. Security by obscurity simply refers to relying on an aspect of secrecy to protect your systems, rather than on secure design. And certainly, when I started my formal infosec training, security by obscurity was considered as no security at all.

This dismissal of security by obscurity in our industry probably originates from an old cryptographer’s axiom called the Kerckhoff’s principle, which proposes that a cryptosystem should remain secure even if the attacker knows exactly how the system works. Assuming, the attacker doesn’t have the key to the system, of course.

There’s no doubt that this axiom holds true; the best security systems are ones that attackers fully understand, but still can’t break without the proper keys or credentials. For instance, bank robbers may understand how a vault door works, but they can’t open it without a disproportionate amount of time, tools, and effort – or having the actual combination to the vault.

So, it’s realistic to believe that most of your defences should rely on securely engineered systems and not on obscurity. However, that doesn’t mean there is not some value in the concept. Combined with proven security controls, obscurity can offer valuable additional protection, creating a worthy layer to a defence-in-depth strategy and posing significant speed bumps to an attack, causing hackers to move on to softer targets.

It’s like a bear chasing a group of people; you don’t have to run faster than the bear to survive, only faster than the slowest member. A little obscurity might just give you the edge to stay ahead of your peers’ defences.

So let’s talk concrete examples. Here are three practices many consider security by obscurity that could supplement your defences:

Changing a server’s default port. Internet and network services tend to run on common, default ports. For instance, SSH is port 22, Telnet is 23, RDP is 3389 and so on. However, there is nothing stopping you from changing these default ports. If you want your SSH server to listen on port 7624, it can; and this simple change will make it harder to find by automated network scans. Smart, persistent attackers targeting your network can still use full-range port scans and fingerprinting techniques to find your SSH server. However, a huge percentage of the malicious ports scans on the Internet are targeting common server ports. So this simple obfuscation can help.

Server header masquerading. Unfortunately, servers are a little too friendly, often totally identifying themselves in their reply headers. For instance, a Web server reply contains a Server: header, where it identifies what software and version it’s running. Here’s an example:

Server: Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.6 with Suhosin-Patch mod_ssl/2.2.8 OpenSSL/0.9.8g

That header is gold to an attacker, who now knows exactly what software your server runs, including any additional packages. If any of that software is unpatched, the attacker might have his or her way in. But you can change this. Many servers have configuration options that allow you to share less information about the server version. There are also network security tools that totally masquerade these server headers. A security stickler will argue that if you keep your servers patched and hardened, it won’t matter if an attacker knows what software they run. I say, patch and harden your servers, but go ahead and masquerade their headers too, making them a bit harder to enumerate.

Use non-standard naming conventions. Operating systems and servers often have default users and groups. Why not rename them? Rename the default ‘administrator’ username to ‘neo’, or whatever comes to mind. A smart attacker may still be able to discover how you renamed all the default users and groups, but any attack tools or scripts that rely on default installs will fail to operate.

These are just three examples of worthwhile obscurity examples, but I could go on.

By itself, security through obscurity is not to be relied on. However, obscurity can further bolster your defences when added as a complementary layer to true security controls. The fake rock with the key under it only offers the illusion of defence, since the burglar can enter by the front door if he finds your key. But imagine the same fake rock with a combination lock. Though the lock is the only true security control, coupling the lock with the hidden rock presents a far stronger security solution.

So, the lesson to learn is that not everything is what it seems on face value. In this fight against cyber criminals and hackers, we need to take a fresh look at all the options.

For more information on WatchGuard and their products, click here.

In this article

Join the Conversation