How A Little Obscurity Can Bolster Security

One of the first maxims I remember learning when I began my formal information security (InfoSec) training was, "Security by obscurity is no security at all." If you haven’t heard this saying before, security by obscurity refers to relying on an aspect of secrecy to protect your systems, rather than on truly secure design. Most security professionals utter the phrase with derision.

A good example of a system that relies on security by obscurity? Those fake rocks that hide house keys. It’s doubtful the average burglar will realize you’ve hidden your key in plain sight. If one does stumble (perhaps literally) upon the imitation rock, your entire security system falls apart, and the robber has the key to your kingdom.

In the security world, our distaste for security by obscurity originates from an old cryptographer’s axiom called Kerckhoff’s principle, which proposes that a cryptosystem should remain secure even if the attacker knows exactly how the system works. (We're assuming the attacker doesn’t have the “key” to the system.) There’s no doubt 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 totally understand how a vault door works, but they can’t open one without a disproportionate amount of time, tools, and effort -- or the actual combination to the vault. That’s why most of your defenses should rely on securely engineered systems, and not on obscurity.  

However, that doesn’t mean obscurity doesn’t hold some value. In fact, I believe, as an industry, we’ve given security by obscurity too bad of a name. Combined with proven security controls, obscurity offers valuable additional protection, creates a worthy layer to a defense-in-depth strategy and can pose significant speed bumps to an attack, causing hackers to move on to softer targets. It’s kind of like that popular joke about the 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 boost you need to “outrun” your peers’ defenses.

So let’s talk concrete examples. Here are three practices many consider security by obscurity, but I think actually could supplement your defenses:

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. This simple change will make it harder to find by automated network scans. Sure… this is security by obscurity. 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 way in. 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 else floats your boat. 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.

I could go on with worthwhile obscurity examples, but you get the point.

By itself, security through obscurity is not good. However, obscurity can bolster your defenses when added as a complementary layer to a true security control. Remember that fake rock ? It only offers the illusion of defense, since the burglar easily has access to your key if he finds your hidden rock. Now imagine that same fake rock, but with a combination lock. Though the lock is the only true security control, coupling the lock with the hidden rock presents a very strong security solution. While I may not want to live without my lock, I also don’t see why I should leave it in plain sight.

What do you think? Does obscurity have any place as a complementary layer of your security strategy, or is it a waste of time and effort? Let us know in the comments section.