OS Fingerprinting For Fun and Profit


Dec 4, 2013 (3 years and 4 months ago)


OS Fingerprinting

For Fun and Profit

Christopher Soghoian

JHU Information Security

December 8 2003

What is OS Fingerprinting

OS Fingerprinting is a method of detecting the
remote host’s operating system using
information leaked by that host’s TCP stack. To
do this, we use:

the responses it gives to carefully crafted
packets (active mode)

or by observing captured network traffic (passive

These methods are possible because each OS
implements their TCP stack differently.

OS Fingerprinting (ab)uses these differences.

Why is this useful?

Learning remote OS versions can be an
extremely valuable network
reconnaissance tool, since many security
holes are dependent on OS version.

Why is this useful

an example

Lets say you are doing a penetration test and
find port 53 open. If this is a vulnerable version
of Bind, you only have one shot to exploit it
since a failed attempt is likely to crash the

Remember that an attack usually involves a
buffer overflow, followed by the execution of
OS/architecture dependent shellcode.

With a good TCP/IP fingerprinter, you will
quickly find that this machine is running 'Solaris
2.51' or 'Linux 2.0.35' and can adjust your
shellcode accordingly.


another example

Another possible use is for
social engineering
Lets say that you are scanning your target
company and the scanner reports a 'Datavoice
TxPORT PRISM 3000 T1 CSU/DSU 6.22/2.06'.
The hacker might now call up the target
pretending to be 'Datavoice support' and discuss
some issues about their PRISM 3000. "We are
going to announce a security hole soon, but first
we want all our current customers to install the

I just mailed it to you ..."


last example

Evil Cable/DSL companies like to charge
customers based on the number of hosts in their
home, not based on the bandwidth given.

Using passive OS fingerprinting, if they observe
two different operating systems, or two different
versions of windows sending traffic from the
same IP, they can assume you are running NAT,
and fine you for violating their Terms of Service.

OS TCP stack implementation

Differences between OSes

While many Operating Systems out there
base their TCP stack on the old BSD
release, there have been so many
changes made that there are now pretty
significant differences between all of the
main Operating Systems.

Differences between OS versions

As critical bugs come out, vendors issue
patches to their TCP stacks.

Vendors tweak the stacks between
releases, usually to improve them.

A paper by Michal Zalewski in 2001

Studied, and graphed the randomness of
Initial Sequence Numbers of various
operating systems.

Graphs the output of 100,000 ISNs for each

Attempts an ISN attack on each OS, and lists
the difficulty for each.

Final Verdict:

OpenBSD is great, Linux is pretty good.
Others have big problems.

Strange Attractors and TCP/IP
Sequence Number Analysis

ISN Graph of: Linux 2.2

ISN Graph of: OpenBSD 2.8

ISN Graph of: OpenBSD 2.9

rewritten by Niels Provos

ISN Graph of: Solaris, weak

ISN Graph of: Solaris,

strong mode

ISN Graph of: Windows 95

ISN Graph of: Windows 98SE

ISN Graph of: Windows 2000

OS Fingerprinting….

Active OS Fingerprinting

(old school)

babylon~> telnet hpux.u

Trying ...

Connected to hpux.u

Escape character is '^]'.

UX hpux B.10.01 A 9000/715 (ttyp2)


Active OS Fingerprinting

(old school, a bit more advanced)

babylon> telnet ftp.netscape.com 21

Trying ...

Connected to

Escape character is '^]'.

220 ftp29 FTP server ready.


215 UNIX Type: L8 Version: SUNOS

Active OS Fingerprinting

(old school, last example)

babylon> echo 'GET / HTTP/1.0
n' | nc hotbot.com
80 | egrep '^Server:‘

Server: Microsoft


Here, we send a HTTP GET request to a remote
server, and observe the webserver software
which is identified in the response.

Downsides to the old school

Sys admins usually turn the login banner
OS announce off.

Applications can be configured to lie.

What we really need is a solution that
doesn’t depend upon the honesty of the

Enter: New School Active OS

New school active

Pioneered by Queso, a now defunct tool,
and improved upon by the widely popular

Described by Nmap’s author, Fyodor, in
his paper “
Remote OS detection via
TCP/IP Stack FingerPrinting
October 18,


Fyodor’s fingerprint method

His basic idea was to send a specially
crafted packet, usually with an
invalid/strange set of options (which is
where OS vendors usually differ in
implementation), and see what

He uses several methods, none of
which individually identify the remote
OS, but combined together will give you
a good idea.

These methods include:

Methods used by Nmap

The FIN probe

Send a FIN packet (or
any packet without an ACK or SYN flag) to
an open port and wait for a response. The
RFC 793

behavior is to NOT
respond, but many broken
implementations such as MS Windows,

Methods used by Nmap

IPID sampling

Most operating systems
increment a system
wide IPID value for each
packet they send. Others, such as OpenBSD,
use a random IPID and some systems (like
Linux) use an IPID of 0 in many cases where the
"Don't Fragment" bit is not set. Windows does
not put the IPID in network byte order, so it
increments by 256 for each packet.

Remember that it was the predictability of the
IPID field which Bellovin used in his paper “A
technique for counting NATted hosts”.

Methods used by Nmap

TCP Initial Window

This simply involves
checking the window size on returned packets.
This test actually gives us a lot of information,
since some operating systems can be uniquely
identified by the window alone

AIX is the only OS which uses 0x3F25

In their "completely rewritten" TCP stack for
NT5, Microsoft uses 0x402E.

Interestingly, that is exactly the number used by
OpenBSD and FreeBSD.

Methods used by nmap

TCP Options

These are truly a gold mine in
terms of leaking information. The beauty of
these options is that:

1. You know if a host implements them by:
sending a query with a bunch of options set. For
all of the options which the server sets in its
reply, it is fair to assume that they are

2. You can stuff a whole bunch of options on
one packet to test everything at once.

Nmap sends these options along with almost
every probe packet: Window Scale=10; NOP;
Max Segment Size = 265; Timestamp; End of


TCP options (continued)

Even if several operating systems support
the same set of options, you can
sometimes distinguish them by the

of the options. For example, if you send a
small MSS value to a Linux box, it will
generally echo that MSS back to you.
Other hosts will give you different values.


TCP options (continued)

And even if you get the same set of supported
options AND the same values, you can still
differentiate via the

that the options are
given, and where padding is applied.

For example Solaris returns 'NNTNWME' which
means: <no op><no op><timestamp><no
op><window scale><echoed MSS>

While Linux 2.1.122 returns MENNTNW, which
means: <echoed MSS><no op><no
op><timestamp><no op><window scale>

Same options, same values, but different order!


difficulties guessing
specific windows versions.

Even with all the tests above, nmap is still
unable to distinguish between the TCP
stacks of Win95, WinNT, or Win98. This is
rather surprising, especially since Win98
came out about 4 years after Win95.

Fyodor’s solution to guessing
Windows software version #

Fyodor proposes:

“You can simply start with early Windows DOS
attacks (Ping of Death, Winnuke, etc) and move
up a little further to attacks such as Teardrop
and Land.

After each attack, ping them to see whether they
have crashed. When you finally crash them, you
will likely have narrowed what they are running
down to one service pack or hotfix.”

This is not implemented in nmap, although it
would be fun.

Defeating Nmap’s active scan

Essentially, you want to be able to modify
various aspects of your TCP stack, to cause
invalid (or even better, false) conclusions by

A number of methods for doing this are
explained in “A practical approach for defeating
Nmap OS
Fingerprinting” by David Barroso
Berrueta, 2003


Defeating nmap (ctd)

The best method he describes is the IP
Personality project.

This is a Linux kernel module that allows you to
change the IP stack behavior and 'personality‘ of
your system.

It allows you to have multiple network
personalities depending on parameters that you
can specify as an iptables rule.

Thus, with this project, not only can you protect
your own machine, but with a Linux NAT firewall,
you can mask the OS fingerprint of all hosts on
your network.

IP Personality

IP Personality allows you to modify the following


TCP Initial Sequence Number (ISN)

TCP initial window size

TCP options (their types, values and order in the

IP ID numbers

answers to some pathological TCP packets

answers to some UDP packets

IP Personality (ctd)

IP Personality ships with a few bogus OS
profiles out of the box, but it is pretty
simple to write a new one based on
nmap’s OS fingerprint database.

IP Personality


# nmap scan initiated Wed Feb 19 20:26:52 2003

Interesting ports on













Remote operating system guess:

Linux Kernel 2.4.0


Uptime 106.832 days (since Tue Nov 5 00:29:33

IP Personality


# nmap scan initiated Wed Feb 19 21:49:03 2003

Interesting ports on













Remote operating system guess:

Sega Dreamcast

IP Personality


Some characteristics of OS are related to the
host architecture (for instance, page sizes on
different kinds of CPU) which could lead to
performance issues.

Some of these changes are more "political"
aspects of the IP stack (initial sequence
numbers, window sizes, TCP options
available...). Tweaking those will allow you to
fool a scanner but might break regular
connectivity by changing network parameters.

It could also make the system weaker if the
emulated IP stack is not as strong as the
initial one

Other methods

He also mentions honeyd, written by Niels

Honeyd is part of the honeynet project, and
allows the user to create virtual/fake hosts.

Honeyd hosts take an nmap database file as
part of their config file, and can thus completely
emulate a given OS.

However, honeyd is for making virtual hosts, and
cannot help you disguise a real host.

Defeating TCP/IP Stack

There is also a paper on “Defeating TCP/IP
Stack Fingerprinting” by Smart, Malan and
Jahanian, Usenix Security 2000.

They describe a traffic normalizer which defeats
nmap’s active scans. They aim to confuse
nmap, and do not attempt to lie about their OS.

They also seem to hard code everything, rather
than supporting nice config files.

It is for this reason that IP Personality is IMHO a
lot cooler. By lying about your OS, you add an
additional layer of security to your network.

Passive OS Fingerprinting….

Passive OS Fingerprinting

The term for fingerprinting techniques that rely
solely upon snooped traffic. This has the added
benefit of allowing you to fingerprint hosts which
you cannot reach directly (i.e. behind a
corporate firewall).

This method is also a lot more covert.

Methods using ICMP were previously known,
but given the lack of ICMP traffic flowing from
most hosts, that method is not so reliable.

Passive OS Fingerprinting (ctd)

TCP based passive fingerprinting was first
described by Toby Miller in a SANS white
paper in 2001.

He noticed that by watching TCP packets
flow between hosts, there were enough
implementation differences to allow you to
tell the host OS versions apart.

Some of these include:

Linux 2.2/2.4 specifics…

The following things stand out as Linux specific:


Windows: 5840

TCP Options: Sets MSS, Timestamps,
sackOK, wscale and 1 nop

Packet Length:60


The following things stick out:

TCP Options: Uses the same options as Linux
BUT instead of setting one nop, OpenBSD
uses 5 nops

IP ID: Totally random. Will need more than
one packet to use effectively.

Total Packet Length: 64 Bytes. This is a key

Solaris 7…

TTL: 255

Window Size: 8760

TCP Options: MSS

IP ID: Increments by one ALL of the time.

Total Packet Length: 44 bytes

By combining the TTL of 255, and the packet
length of 44 bytes, you can be sure this came
from a Solaris box

Passive Fingerprinting tools

p0f is the best of the breed of this category.

Created by Michael Zalewski in 2001.

Works with 3 types of traffic:


Incoming connection fingerprinting

whenever you want to know what the guy who
connects to you runs.


Outgoing connection fingerprinting

to fingerprint systems you or your users connect to.


Outgoing connection refused fingerprinting

to fingerprint systems that reject your traffic.

p0f continued.

p0f employs the techniques described in the
SANS paper, as well as a few additional

Just like nmap, it depends upon a database of
OS profiles.

It also supports a mode to detect
NAT/Masquerade hosts, based on seeing two
different OS types sending traffic from the same

p0f info at: http://lcamtuf.coredump.cx/p0f.shtml

p0f/OpenBSD integration

Mike Frantzen

ported p0f’s detection code to the
OpenBSD firewall subsystem, thus allowing
OpenBSD hosts to detect the OS of any
machine it connects to, or which connects to it.

Uses the same database as p0f.

Is now included in openBSD releases.

More info at:


Defeating Passive fingerprinting

Rob Beck, a security guy at @stake wrote an
article for Linux Journal in 2002 describing a
proof of concept linux iptables module which
would allow you to lie about your OS, and fool
passive OS scans.

However, this was his first ever C program, and
thus the code is not so great.

Your first C program should not involve icky
network code. Start with Hello World.

Also, all values were hard coded and did not
support config files.

Defeating passive fingerprinting

IP Personality has all the infrastructure in
place to do this, and their codebase is a
lot nicer.

As it was written before Passive OS
Fingerprinting had become widespread,
the authors didn’t tackle this subject.
However, it would be pretty trivial to
modify their scripts to do so.


OS Fingerprinting is a very valuable
technique for attackers.

By probing a wide variety of hosts ahead
of time, it is possible for attackers to
prepare hit
lists to use as soon as the next
application/OS exploit is released.

This allows attackers to not waste their
time trying IIS exploits against Linux hosts.


Considering how much attackers can
gain through using OS fingerprinting, it
is important that we be able to defend
against their probes.

By being able to trick their probes, you
are essentially adding yourself to a
hacker do
call list (somewhat).

They will only try to attack you with
exploits for the OS type which you


Users can protect themselves against
active scans by installing a NAT/firewall
box (either an embedded solution, or a
linux box)

They can fool active scans by using IP
personality, or other tools.

They cannot defend against passive OS
fingerprinting by installing a $50 d
router. Which means that the majority of
users will not do it.

Conclusion (ctd)

It is quite realistic to expect evil ISPS to start
deploying passive OS scanners on their
networks in the future.

Given the technical skills needed to configure IP
Personality and a Linux router, many users will
be exposed to information leakage, and thus
could be subject to future targeted attacks by