danielowen.com

Over the years anyone who is even vaguely familiar with the security world has had the idea of security through obscurity being worthless drilled into our heads. While I will agree that security through obscurity is exceptionally weak security there is still a place for it in a complete security plan.

After years of hearing the argument that security through obscurity is no security at all it becomes easy to assume that obscurity does not add any level of security to a security plan. As long as obscurity is a part of an overall security plan it should never hurt and will in most circumstances improve your security.

I will give a few examples where security through obscurity can and does help.

The first example is one that I personally experienced back in 2001 when Code Red was first releases. The company I work for allows employees to check e-mail through a secured web page. We do not use port 80 for web mail. While this is not all that effective if you are willing to search every port on every IP that we own it was very effective in hiding us from the affects of Code Red. Code Red simply tried to attach to port 80 and was dropped by the firewall. While we were fully patched and in theory otherwise protected I personally have a better feeling that a rudimentary precaution stopped Code Red before further testing was even attempted.

This same theory of moving away from well know ports works equally well for hiding from your friendly script kiddy looking for a vulnerable target to attack. This of course could work for any service as long as you can communicate the change to people using the service. For example moving SSH to another port is well worth the small amount of extra work involved. This also has the advantage of possible hiding you from someone who has a new unknown exploit that they are trying to hit as many PCs with as possible. Will this type of port shifting stop a determined attacker? No. It will not even close but if it cuts down on the scanning attempts and you no longer have to follow up on those it does cut out some headaches. I know that it is very common to see dropped traffic going to port 80 but much less common to see people looking at the port that legitimate traffic actually crosses.

Another precaution I take when possible is changing headers that are returned when connecting to services. Let me give you an example. When a connection is made to a default sendmail implementation you will get something like this “220 servername.com ESMTP Sendmail 8.12.10/8.12.10”. This is actually very convenient when you want to try you figure out why e-mail is not being delivered to a given host but it is also useful when someone is trying to determine what type of e-mail server you have as a precursor to determine what sorts of attacks to throw at your server. On the other hand if your sendmail server is responding with “ModusMail ESMTP Receiver Version 3.0.282.0” it is going to make for a more interesting day for your attacker. Many people will also respond with garbage such as “******************!#!#!@#*********”. This will hide the real service but anyone looking at it will realize that this is simply an obscured service identifier. The advantage of using garbage is that this is probably friendlier for someone trying to debug why traffic is not passing to your server.

Obscuring the server is of course still not fool proof. Fingerprinting techniques for determining what sort of server is running are available but considering the minimal level of work that is required to change some of these settings there really is not a good reason not to change server response headers when possible. This is one of those unfortunate areas where some manufacturers make it difficult to make changes easily so in some situations changing the response is not practical. It’s only an obscuring technique I don’t let it bother me too much if it is not practical.

Another form of obscuring is hiding systems. This is one place that security through obscurity is very popular. Most modern firewalls will give the option of dropping unwanted traffic rather than rejecting it. This makes it appear that there is not a system located on a given IP address. For Internet facing systems forcing an attacker to go through hundreds or thousands of port to determine if a given IP has a system associated with it will at least slow his progress and make him much more noticeable in log files.

I have described three common examples of security enhancements through obscurity. None of these will stop the determined attacker but they all should slow an attacker down. From that point more in depth security must take over. Obscurity should also have the added ability of stopping less experienced attackers without you having to concern yourself with their attacks.

Obscurity also has the added advantage of slowing down experienced attackers while stopping scripted attacks and some less experienced attackers. Obscurity also will assist in helping to cut down on the number of attacks you must look at to identify serious threats.

While security through obscurity is by no stretch of the imagination strong security by itself it can add to an overall security plan making a good plan better.

Daniel Owen

(original date 2002 or 2003)