Passive-Aggressive Resistance: OS Fingerprint Evasion

If we do not wish to fight, we can prevent the enemy from engaging us even though the lines of our encampment be merely traced out on the ground. All we need do is to throw something odd and unaccountable in his way. --Sun Tzu, The Art of War
Why Fingerprint Evasion?

If you have read up to this point, you are at least no doubt a little curious as to why one would go to the trouble of OS fingerprint evasion. Good question! I think the logic here varies from person to person. Everyone has his or her own reasons for wanting, or not wanting for that matter, operating system obscurity.

For some, the extra layer of obscurity helps them feel fuzzy and warm inside. Like the people who feel the need to remove the issue banner from their Telnet login screens, but resort to Telnet rather than SSH for remote access security (obscure, but technically less secure). For others, the notion of operating system obscurity at the network level allows them to fine-tune and tweak their IDS (intrusion detection system) since they have a fairly good idea not only of what should be coming into their network, but also of what data should be leaving it (obscure, cautious and hopefully secure). Some might even have a need for security, where every network they plug in to is a potential hostile network; and the more obscure their operating system is, the bigger the window of opportunity they have to complete whatever the task is at hand without being noticed (obscure, cautious, secure and probably reading your e-mail). Finally, there are those of us who do it for fun, because we can and because we get some small kick out of being able to fool the unknown individuals around us who persist on launching scans in our direction (yes, guilty as charged).


Now it's time to try our luck at fingerprint evasion. Familiar with some of the common techniques used in determining a host's operating system, we can reverse engineer these concepts to aid us in hiding our operating identities.

First, we need to make sure that all patches are in place and the system is secured. As I stated before, obscurity should only be entertained after security has been implemented. I'm sure some would disagree here, relying solely upon obscurity for their means to a secured system, but what good is obscurity if that script kid33's automated script gains root on your machine tonight? I'm willing to bet once he has root access, what flavor of Linux you are running isn't on his or her list of things to figure out.

Second, we need to observe our services. Do they match up with the operating system we are hoping to pass ourselves off as using? In most cases this isn't as much of a concern since most UNIX environments share similar if not the same services. But if you are hoping to present yourself as a Windows machine, or even a Cisco router for that matter, it may not be to your advantage to show up having IRCd running. Make an effort in matching up your services with a suitable decoy host.

While we're on the subject of services, it is also a good idea to begin greping through the source code of these services looking for banners or common identifiers of the services. Some subtle identifiers could be the supporting of ASP pages or web content that is served compressed in gzip format. For most people this will be a lot of work. Again, it's up to you to gauge what level of obscurity and conformity with your new decoy host you are trying to achieve.

Next, we need to look at how our host appears on a network vs. how our decoy host should look on a network. To make this a little bit easier I suggest studying already documented materials, namely the current fingerprint files used by the tools themselves. Time should be taken to note not just how your decoy host responds to usual queries, but also what special flags it supports in TCP. TCP flags are useful information for outsiders to determine what OS you are running. The fingerprint files don't include all possible responses a host might give, just simple techniques that work reproducibly. Depending on what level of obscurity you hope to achieve, it may be worth looking into fingerprint information not used by nmap (OSPF, OOB, IPv6, etc.). Or the joy of thoroughness could be outweighed by the sleepless nights you would spend gathering this information.

Finally, a decision needs to be made. Are you crafty, or are you paranoid? If you answer to the latter, then you most likely want to continue by obfuscating your client software. As mentioned above, a host's client software tends to give out all kinds of information regarding the system, either directly or indirectly. In our previous example an IRC client lists itself as being for Win32, but there are also more subtle ways of determining a host, such as reading the e-mail headers of outgoing mail. Once again, it all comes down to how many sleepless nights you are willing to spend before your system meets your criteria.

Potential Problems

OS fingerprint evasion is like any other aspect of security; it takes planning, proper execution and most importantly, understanding. If security policies are not properly implemented, the system could be more vulnerable than if these policies were not implemented at all.

Popularity gives way to recognition. In most realms of software, popularity is a great thing; it brings attention to all your hard work and determination. In the case of OS fingerprint evasion, recognition works against you. If you are using a popular tool or package, eventually vulnerabilities and particulars will be discovered; this is inevitable. These same software-specific identifiers will allow others to fingerprint your counter-measure accurately rather than the operating system itself.

Most every OS attempts to make its TCP ISN sequencing random, in attempt to thwart TCP hijacking and more complex attacks on the system. If your chosen implementation of evasion attempts to alter TCP initial sequence numbers, great care should be taken to ensure you do not downgrade this functionality and put your host at risk to these types of attacks.

As with any software package that makes it onto your system, application security should be a primary concern. Part of the evasion process is masking existing services; the other comes in the form of code, which is meant to filter your traffic and mask what you put on the wire. Great care should be taken to ensure that the application produced for this task is secure through good programming practices and rigorous testing. All it takes is one poorly thought-out strcpy() to turn this asset quickly into a liability.

One of the evasion tactics previously listed is to alter the service banners of software that identifies itself. Be careful because some add-on software packages actually use these same banners to determine compatibility with the current system software.