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

OS fingerprinting is a process for determining the operating system a remote host computer is running, based on characteristics of the data returned from the remote host. This can be as simple as connecting up to the host and reading a service banner or as complex as statistical analysis of TCP initial sequence numbers and flags. An outsider has the capability to discover general information, such as which operating system a host is running, by searching for OS-specific differences in implementation of the TCP stack. In some cases, these differences can reveal information as detailed as the OS version number and processor architecture.

By pinpointing the exact OS of a host, an attacker can launch an educated and precise attack against a target machine. In a world of buffer overflows, knowing the exact flavor of an OS and architecture could be all the opportunity an attacker needs. By using software such as Netfilter for Linux, an administrator can evade accurate OS-fingerprinting methods and in some cases even manipulate the results gathered by the external force. While these practices should never be considered a sound security solution, sometimes they can deter and even confuse a would-be attacker if the host poses as an obscure network entity.

While fingerprint evasion does offer a nice layer of obscurity as to the actual OS a host is running, it does not in any way secure the host from various vulnerabilities. Security practices and policies attempt to raise the level of skill required to compromise the system, obscurity only attempts to mask the actual target. Even if your system appears to be running Microsoft IIS5 to the world, this won't protect you if you are running a vulnerable version of let's say sendmail, and some script kiddy's automated scanner attempts to exploit you. Fingerprint evasion is meant to deter attacks, not prevent them.

Techniques for Discovery

Before attempting to dissuade a potential attacker through OS deception, one must familiarize themselves with the tools and methods used in fingerprinting an OS. The term “attacker” here is used loosely and encompasses those who would attempt to fingerprint a host or those who might have the intentions of doing the system harm. Security has been, and in the writer's mind always will be, a sequence of measure and counter-measure scenarios. By becoming accustomed to the tools and methodologies available for this type of attack you cannot only prepare and plan for current engagements, but also gain insight into what the future may have in store.

Several publicly available tools exist for attempting to fingerprint an OS. Of these tools, one seems to be the popular choice: nmap ( by Fyodor of nmap uses several techniques for attempting to determine the host operating system from a network level, some of them primitive in their approach and others more complex, requiring a good understanding of the TCP/IP protocol and protocol standards. Of the methods nmap incorporates, some of the most notable are:

  • FIN Probing—by sending a packet to an open port on a host with nothing more than the FIN flag set in the packet, an attacker can glean information from certain hosts that respond to the requests. This behavior is non-RFC-compliant so it is a good indicator of OS.

  • TCP ISN Sampling—TCP packet ISN (initial sequence number) sampling can be a valuable way to determine and categorize the remote host. By watching the ISNs for patterns an attacker can make an educated guess as to the host OS.

  • ICMP Error Messaging—through the use of ICMP (internet control message protocol) error messages, an attacker can find useful information based on the host responses. Particular areas of interest are the checksums, error message echo integrity and TOS (type of service) fields in the reply packets.

  • TCP Options—perhaps the most revealing aspect of any TCP stack is how it handles optional TCP flags and data. By making specific requests to a host and varying window scales and segment sizes, one can determine which operating system a host is running based on its willingness to accept or respond with these optional parameters.

While all of these methods of OS fingerprinting are at the packet level, great care should be taken to understand your system at a service level. An attacker could sort and compare packet structures but will often simply query a web server for the “Server” field in the HTTP response header. Knowing which services readily identify themselves, and more importantly the operating system architecture, will show us other avenues that can be used for remote information retrieval.

Client modesty (or lack thereof) can be an excellent way to glean information from a host as well. Unlike the other options, this process can be completely passive. By watching how a client application presents itself to a service, you can make a reasonable guess at the operating system and possibly the architecture. Of these clients, web browsers, e-mail clients and IRC (internet relay chat) clients are most often the biggest offenders. If we were on IRC and requested a CTCP version from a user, and received the reply of “mIRC32 v5.81 K.Mardam-Bey”, we could make an educated guess at this point that the host is running some form of the Windows operating system.

Finally, there is exploit testing. While less tactful, it can nevertheless be useful in discovering the operating system of a host. By initiating a series of OS-specific denial-of-service attacks an outsider can test to see if a host is vulnerable. This can determine which rating system a host is running, usually down to the patch level. The Windows community should be grateful that Fyodor and the other fingerprinting-tool authors didn't decide to incorporate this method into their usual slew of scanning techniques.