Avoid Security Through Obscurity

When reviewing publications and commentary about security principles, you frequently encounter the postulate "security through obscurity is not security." Although it is said often, it is frequently misunderstood and is used as an excuse or justification for all sorts of security ills. Let's consider a few scenarios to better understand this axiom:

• Paper currency is the basis for many of our day-to-day transactions, and counterfeiting is an ongoing concern. Nations could rely on restricting access to and knowledge of the materials used for the paper fabric and ink components, but they do not. Instead, other methods are used to make forgery difficult. These include watermarks, color-shifting ink, polymer security threads that glow under an ultraviolet light, and micro printing that is hard to replicate. In this case, obscurity is not relied on to prevent counterfeiting. That said, I wouldn't expect to see detailed specifications for printing U.S. $100 bills posted to the U.S. Treasury website anytime soon.
• It is not hard for an intelligent attacker to figure out the brand of a firewall by fingerprinting it with tools available in the public domain (Nmap at www.insecure.org, for example). A proper security posture, therefore, does not rely on keeping this information private; rather, it relies on the firewall performing its access control function properly. Further, if exploits are discovered regarding the firewall product, they must be quickly patched. Do not rely on either the fact that possibly no one knows the brand of firewall or whether a particular exploit will or will not work against the specific technologythat would be security through obscurity. That said, there is no reason to make the brand of your firewall a matter of public record or to quit striving for a firewall as resistant to identification as possible.

The preceding example focuses on obscuring the knowledge of the brand of a security technology you deploy. The next example considers the value of obscuring the fact that you use a security technology at all in your network:

• Over the past few years, there has been quite a bit of activity in trying to find ways to identify whether a NIDS has been deployed in a network. The intent is that, if a NIDS is discovered, the attacker might be able to find ways to fly under the radar of the scanning engine. Usually this involves trying to force the NIDS state table to misrepresent what the actual target system is experiencing, such as by adjusting IP Time-to-Live fields or deliberately fragmenting packets in an attempt to confuse the NIDS.

  Although you should not deploy a NIDS if someone who knows it is deployed could get around it, you should keep its specific configuration and location private. Here, you are not practicing "security through obscurity," you are practicing common sense.

  NOTE

  There is a good paper on defeating an NIDS at the following address: http://secinf.net/info/ids/idspaper/idspaper.html.

• Network Address Translation (NAT) is sometimes inappropriately promoted as a security feature. Instead, it is really providing obscurity of the Layer 3 addressing. When you use NAT on your Internet gateway, you still require access control at the same time. A full stateful firewall can provide access control over Layer 3 and Layer 4, as well as more sophisticated functions such as sequence number validation, fragmentation abuse checks, and IP options misuse identification. These capabilities are not related to NAT but are needed since the hacker can potentially spoof the translated address. This logic also applies when doing many-to-one translations. See Chapter 6 for more information on avoiding reliance on NAT in a security role.

WARNING

Also realize that NAT (and, to a lesser extent, firewalls) can make your overall network less secure since the applications your users run will try to tunnel over ports you are permitting (such as TCP port 80). This makes it harder to categorize the traffic. Certainly, the benefits outweigh the drawbacks of firewalls in most cases, but be aware of these issues when designing your access control policies.

These cases are intended to show the importance of making sure your design is as indifferent as possible to what others know about it. Consider cryptography: it is an accepted practice in the security community to vet algorithms to broad audiences and thus ensure that the strength of the cipher stands on its own, not on whether the attacker has figured out the algorithm.

This does not mean you should never make use of obscurity mechanisms. It means you should never rely on them. If using an obscurity feature or design element is free of administrative burden, it is practical to use it. But if benefiting from an obscurity capability means shouldering an administrative burden, often it is not worth the little added benefit.

For example, obfuscating the login banner on devices causes little administrative hardship, so it is generally a good idea. It is also a good idea to keep your system design and device selection confidential. Conversely, deciding that you are going to change all of your internal Simple Mail Transfer Protocol (SMTP) servers to operate on TCP port 2525 instead of 25 is of questionable value. All host applications will need to be modified to use the new port, and this will only add to the complexity of any help desk call from your users to you or from you to your security vendor.