Remote OS detection via TCP/IP Stack FingerPrinting
by Fyodor <fyodor@dhp.com> (www.insecure.org)
October 18, 1998

ABSTRACT

This paper discusses how to glean precious information about a host by querying its TCP/IP stack. I first present some of the "classical" methods of determining host OS which do not involve stack fingerprinting. Then I describe the current "state of the art" in stack fingerprinting tools. Next comes a description of many techniques for causing the remote host to leak information about itself. Finally I detail my (nmap) implementation of this, followed by a snapshot gained from nmap which discloses what OS is running on many popular Internet sites.

REASONS

I think the usefulness of determining what OS a system is running is pretty obvious, so I'll make this section short. One of the strongest examples of this usefulness is that many security holes are dependent on OS version. Lets say you are doing a penetration test and you find port 53 open. If this is a vulnerable version of Bind, you only get one chance to exploit it since a failed attempt will crash the daemon. With a good TCP/IP fingerprinter, you will quickly find that this machine is running 'Solaris 2.51' or 'Linux 2.0.35' and you can adjust your shellcode accordingly.

A worse possibility is someone scanning 500,000 hosts in advance to see what OS is running and what ports are open. Then when someone posts (say) a root hole in Sun's comsat daemon, our little cracker could grep his list for 'UDP/512' and 'Solaris 2.6' and he immediately has pages and pages of rootable boxes. It should be noted that this is SCRIPT KIDDIE behavior. You have demonstrated no skill and nobody is even remotely impressed that you were able to find some vulnerable .edu that had not patched the hole in time. Also, people will be even _less_ impressed if you use your newfound access to deface the department's web site with a self-aggrandizing rant about how damn good you are and how stupid the sysadmins must be.

Another possible use is for social engineering. Lets say that you are scanning your target company and nmap reports a 'Datavoice TxPORT PRISM 3000 T1 CSU/DSU 6.22/2.06'. The hacker might now call up as '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 patch -- I just mailed it to you ..." Some naive administrators might assume that only an authorized engineer from Datavoice would know so much about their CSU/DSU.

Another potential use of this capability is evaluation of companies you may want to do business with. Before you choose a new ISP, scan them and see what equipment is in use. Those "$99/year" deals don't sound nearly so good when you find out they have crappy routers and offer PPP services off a bunch of Windows boxes.

CLASSICAL TECHNIQUES

Stack fingerprinting solves the problem of OS identification in a unique way. I think this technique holds the most promise, but there are currently many other solutions. Sadly, this is still one the most effective of those techniques:

playground~> telnet hpux.u-aizu.ac.jp
Trying 163.143.103.12...
Connected to hpux.u-aizu.ac.jp.
Escape character is '^]'.

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

login:

There is no point going to all this trouble of fingerprinting if the machine will blatantly announce to the world exactly what it is running! Sadly, many vendors ship _current_ systems with these kind of banners and many admins do not turn them off. Just because there are other ways to figure out what OS is running (such as fingerprinting), does not mean we should just announce our OS and architecture to every schmuck who tries to connect.

The problems with relying on this technique are that an increasing number of people are turning banners off, many systems don't give much information, and it is trivial for someone to "lie" in their banners. Nevertheless, banner reading is all you get for OS and OS Version checking if you spend $thousands on the commercial ISS scanner. Download nmap or queso instead and save your money :).

Even if you turn off the banners, many applications will happily give away this kind of information when asked. For example lets look at an FTP server:

payfonez> telnet ftp.netscape.com 21
Trying 207.200.74.26...
Connected to ftp.netscape.com.
Escape character is '^]'.
220 ftp29 FTP server (UNIX(r) System V Release 4.0) ready.
SYST
215 UNIX Type: L8 Version: SUNOS

First of all, it gives us system details in its default banner. Then if we give the 'SYST' command it happily feeds back even more information. If anon FTP is supported, we can often download /bin/ls or other binaries and determine what architecture it was built for.

Many other applications are too free with information. Take web servers for example:

playground> echo 'GET / HTTP/1.0\n' | nc hotbot.com 80 | egrep '^Server:' 
Server: Microsoft-IIS/4.0

playground>

Hmmm ... I wonder what OS those lamers are running. Other classic techniques include DNS host info records (rarely effective) and social engineering. If the machine is listening on 161/udp (snmp), you are almost guaranteed a bunch of detailed info using 'snmpwalk' from the CMU SNMP tools distribution and the 'public' community name.

CURRENT FINGERPRINTING PROGRAMS

Nmap is not the first OS recognition program to use TCP/IP fingerprinting. The common IRC spoofer sirc by Johan has included very rudimentary fingerprinting techniques since version 3 (or earlier). It attempts to place a host in the classes "Linux", "4.4BSD", "Win95", or "Unknown" using a few simple TCP flag tests.

Another such program is checkos, released publicly in January of this year by Shok in Confidence Remains High Issue #7. The fingerprinting techniques are exactly the same as SIRC, and even the _code_ is identical in many places. Checkos was privately available for a long time prior to the public release, so I have no idea who swiped code from whom. But neither seems to credit the other. One thing checkos does add is telnet banner checking, which is useful but has the problems described earlier. [ Update: Shok wrote in to say that chekos was never intended to be public and this is why he didn't bother to credit SIRC for some of the code. ]

Su1d also wrote an OS checking program. His is called SS and as of Version 3.11 it can identify 12 different OS types. I am somewhat partial to this one since he credits my nmap program for some of the networking code :).

Then there is queso. This program is the newest and it is a huge leap forward from the other programs. Not only do they introduce a couple new tests, but they were the first (that I have seen) to move the OS fingerprints _out_ of the code. The other scanners included code like:

/* from ss */
if ((flagsfour & TH_RST) && (flagsfour & TH_ACK) && (winfour == 0) && (flagsthree & TH_ACK))
    reportos(argv[2],argv[3],"Livingston Portmaster ComOS");

Instead, queso moves this into a configuration file which obviously scales much better and makes adding an OS as easy as appending a few lines to a fingerprint file. Queso was written by Savage, one of the fine folks at Apostols.org .

One problem with all the programs describe above is that they are very limited in the number of fingerprinting tests which limits the granularity of answers. I want to know more than just 'this machine is OpenBSD, FreeBSD, or NetBSD', I wish to know exactly which of those it is as well as some idea of the release version number. In the same way, I would rather see 'Solaris 2.6' than simply 'Solaris'. To achieve this response granularity, I worked on a number of fingerprinting techniques which are described in the next section.

FINGERPRINTING METHODOLOGY

There are many, many techniques which can be used to fingerprint networking stacks. Basically, you just look for things that differ among operating systems and write a probe for the difference. If you combine enough of these, you can narrow down the OS very tightly. For example nmap can reliably distinguish Solaris 2.4 vs. Solaris 2.5-2.51 vs Solaris 2.6. It can also tell Linux kernel 2.0.30 from 2.0.31-34 or 2.0.35. Here are some techniques:

The FIN probe -- Here we send a FIN packet (or any packet without an ACK or SYN flag) to an open port and wait for a response. The correct RFC793 behavior is to NOT respond, but many broken implementations such as MS Windows, BSDI, CISCO, HP/UX, MVS, and IRIX send a RESET back. Most current tools utilize this technique.
The BOGUS flag probe -- Queso is the first scanner I have seen to use this clever test. The idea is to set an undefined TCP "flag" ( 64 or 128) in the TCP header of a SYN packet. Linux boxes prior to 2.0.35 keep the flag set in their response. I have not found any other OS to have this bug. However, some operating systems seem to reset the connection when they get a SYN+BOGUS packet. This behavior could be useful in identifying them.
TCP ISN Sampling -- The idea here is to find patterns in the initial sequence numbers chosen by TCP implementations when responding to a connection request. These can be categorized in to many groups such as the traditional 64K (many old UNIX boxes), Random increments (newer versions of Solaris, IRIX, FreeBSD, Digital UNIX, Cray, and many others), True "random" (Linux 2.0.*, OpenVMS, newer AIX, etc). Windows boxes (and a few others) use a "time dependent" model where the ISN is incremented by a small fixed amount each time period. Needless to say, this is almost as easily defeated as the old 64K behavior. Of course my favorite technique is "constant". The machines ALWAYS use the exact same ISN :). I've seen this on some 3Com hubs (uses 0x803) and Apple LaserWriter printers (uses 0xC7001).
You can also subclass groups such as random incremental by computing variances, greatest common divisors, and other functions on the set of sequence numbers and the differences between the numbers.
It should be noted that ISN generation has important security implications. For more information on this, contact "security expert" Tsutomu "Shimmy" Shimomura at SDSC and ask him how he was owned. Nmap is the first program I have seen to use this for OS identification.
Don't Fragment bit -- Many operating systems are starting to set the IP "Don't Fragment" bit on some of the packets they send. This gives various performance benefits (though it can also be annoying this is why nmap fragmentation scans do not work from Solaris boxes). In any case, not all OS's do this and some do it in different cases, so by paying attention to this bit we can glean even more information about the target OS. I haven't seen this one before either.
TCP Initial Window -- This simply involves checking the window size on returned packets. Older scanners simply used a non-zero window on a RST packet to mean "BSD 4.4 derived". Newer scanners such as queso and nmap keep track of the exact window since it is actually pretty constant by OS type. This test actually gives us a lot of information, since some operating systems can be uniquely identified by the window alone (for example, AIX is the only OS I have seen 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.
ACK Value -- Although you would think this would be completely standard, implementations differ in what value they use for the ACK field in some cases. For example, lets say you send a FIN|PSH|URG to a closed TCP port. Most implementations will set the ACK to be the same as your initial sequence number, though Windows and some stupid printers will send your seq + 1. If you send a SYN|FIN|URG|PSH to an open port, Windows is very inconsistent. Sometimes it sends back your seq, other times it sends S++, and still other times is sends back a seemingly random value. One has to wonder what kind of code MS is writing that changes its mind like this.
ICMP Error Message Quenching -- Some (smart) operating systems follow the RFC 1812 suggestion to limit the rate at which various error messages are sent. For example, the Linux kernel (in net/ipv4/icmp.h) limits destination unreachable message generation to 80 per 4 seconds, with a 1/4 second penalty if that is exceeded. One way to test this is to send a bunch of packets to some random high UDP port and count the number of unreachables received. I have not seen this used before, and in fact I have not added this to nmap (except for use in UDP port scanning). This test would make the OS detection take a bit longer since you need to send a bunch of packets and wait for them to return. Also dealing with the possibility of packets dropped on the network would be a pain.
ICMP Message Quoting -- The RFCs specify that ICMP error messages quote some small amount of an ICMP message that causes various errors. For a port unreachable message, almost all implementations send only the required IP header + 8 bytes back. However, Solaris sends back a bit more and Linux sends back even more than that. The beauty with this is it allows nmap to recognize Linux and Solaris hosts even if they don't have any ports listening.
ICMP Error message echoing integrity -- I got this idea from something Theo De Raadt (lead OpenBSD developer) posted to comp.security.unix. As mentioned before, machines have to send back part of your original message along with a port unreachable error. Yet some machines tend to use your headers as 'scratch space' during initial processing and so they are a bit warped by the time you get them back. For example, AIX and BSDI send back an IP 'total length' field that is 20 bytes too high. Some BSDI, FreeBSD, OpenBSD, ULTRIX, and VAXen fuck up the IP ID that you sent them. While the checksum is going to change due to the changed TTL anyway, there are some machines (AIX, FreeBSD, etc.) which send back an inconsistent or 0 checksum. Same thing goes with the UDP checksum. All in all, nmap does nine different tests on the ICMP errors to sniff out subtle differences like these.
Type of Service -- For the ICMP port unreachable messages I look at the type of service (TOS) value of the packet sent back. Almost all implementations use 0 for this ICMP error although Linux uses 0xC0. This does not indicate one of the standard TOS values, but instead is part of the unused (AFAIK) precedence field. I do not know why this is set, but if they change to 0 we will be able to keep identifying the old versions _and_ we will be able to identify between old and new.
Fragmentation Handling -- This is a favorite technique of Thomas H. Ptacek of Secure Networks, Inc (now owned by a bunch of Windows users at NAI). This takes advantage of the fact that different implementations often handle overlapping IP fragments differently. Some will overwrite the old portions with the new, and in other cases the old stuff has precedence. There are many different probes you can use to determine how the packet was reassembled. I did not add this capability since I know of no portable way to send IP fragments (in particular, it is a bitch on Solaris). For more information on overlapping fragments, you can read their IDS paper (www.secnet.com).
TCP Options -- These are truly a gold mine in terms of leaking information. The beauty of these options is that:
1. They are generally optional (duh!) :) so not all hosts implement them.
2. You know if a host implements them by sending a query with an option set. The target generally show support of the option by setting it on the reply.
3. 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 Ops;
```
The timestamp option [Sec 24.5, Stevens] allows the sender TCP to estimate RTTs.
A window scale of 10 makes the window 2¹⁰ x 65535.
When you get your response, you take a look at which options were returned and thus are supported. Some operating systems such as recent FreeBSD boxes support all of the above, while others, such as Linux 2.0.X support very few. The latest Linux 2.1.x kernels do support all of the above. On the other hand, they are more vulnerable to TCP sequence prediction. Go figure.
Even if several operating systems support the same set of options, you can sometimes distinguish them by the _values_ 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.
And even if you get the same set of supported options AND the same values, you can still differentiate via the _order_ 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. Same options, same values, but different order!

I have not seen any other OS detection tools utilizes TCP options, but it is very useful.

There are a few other useful options I might probe for at some point, such as those that support T/TCP and selective acknowledgements.

Exploit Chronology -- Even with all the tests above, nmap is 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. You would think they would have bothered to improve the stack in some way (like supporting more TCP options) and so we would be able to detect the change and distinguish the operating systems. Unfortunately, this is not the case. The NT stack is apparently the same crappy stack they put into '95. And they didn't bother to upgrade it for '98.

But do not give up hope, for there is a solution. 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.

I have not added this functionality to nmap, although I must admit it is very tempting :).

SYN Flood Resistance -- Some operating systems will stop accepting new connections if you send too many forged SYN packets at them (forging the packets avoids trouble with your kernel resetting the connections). Many operating systems can only handle 8 packets. Recent Linux kernels (among other operating systems) allow various methods such as SYN cookies to prevent this from being a serious problem. Thus you can learn something about your target OS by sending 8 packets from a forged source to an open port and then testing whether you can establish a connection to that port yourself. This was not implemented in nmap since some people get upset when you SYN flood them. Even explaining that you were simply trying to determine what OS they are running might not help calm them.

NMAP IMPLEMENTATION AND RESULTS

I have created a reference implementation of the OS detection techniques mentioned above (except those I said were excluded). I have added this to my Nmap scanner which has the advantage that it already _knows_ what ports are open and closed for fingerprinting so you do not have to tell it. It is also portable among Linux, *BSD, and Solaris 2.51 and 2.6, and some other operating systems.

The new version of nmap reads a file filled with Fingerprint templates that follow a simple grammar. Here is an example:

FingerPrint  IRIX 6.2 - 6.4 # Thanks to Lamont Granquist
TSeq(Class=i800)

T1(DF=N%W=C000|EF2A%ACK=S++%Flags=AS%Ops=MNWNNT)
T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
T3(Resp=Y%DF=N%W=C000|EF2A%ACK=O%Flags=A%Ops=NNT)
T4(DF=N%W=0%ACK=O%Flags=R%Ops=)

T5(DF=N%W=0%ACK=S++%Flags=AR%Ops=)

T6(DF=N%W=0%ACK=O%Flags=R%Ops=)

T7(DF=N%W=0%ACK=S%Flags=AR%Ops=)

PU(DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)

Lets look at the first line (I'm adding '>' quote markers):

```
> FingerPrint IRIX 6.2 - 6.3 # Thanks to Lamont Granquist
```
This simply says that the fingerprint covers IRIX versions 6.2 through 6.3 and the comment states that Lamont Granquist kindly sent me the IP addresses or fingerprints of the IRIX boxes tested.
```
> TSeq(Class=i800)
```
This means that ISN sampling put it in the "i800 class". This means that each new sequence number is a multiple of 800 greater than the last one.
```
> T1(DF=N%W=C000|EF2A%ACK=S++%Flags=AS%Ops=MNWNNT)
```
The test is named T1 (for test1, clever eh?). In this test we send a SYN packet with a bunch of TCP options to an open port. DF=N means that the "Don't fragment" bit of the response must not be set. W=C000|EF2A means that the window advertisement we received must be 0xC000 or EF2A. ACK=S++ means the acknowledgement we receive must be our initial sequence number plus 1. Flags = AS means the ACK and SYN flags were sent in the response. Ops = MNWNNT means the options in the response must be (in this order):
```
<MSS (not echoed)><NOP><Window scale><NOP><NOP><Timestamp>
```
```
> T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
```
Test 2 involves a NULL with the same options to an open port. Resp=Y means we must get a response. Ops= means that there must not be any options included in the response packet. If we took out '%Ops=' entirely then any options sent would match.
```
> T3(Resp=Y%DF=N%W=400%ACK=S++%Flags=AS%Ops=M)
```
Test 3 is a SYN|FIN|URG|PSH w/options to an open port.
```
> T4(DF=N%W=0%ACK=O%Flags=R%Ops=)
```
This is an ACK to an open port. Note that we do not have a Resp= here. This means that lack of a response (such as the packet being dropped on the network or an evil firewall) will not disqualify a match as long as all the other tests match. We do this because virtually any OS will send a response, so a lack of response is generally an attribute of the network conditions and not the OS itself. We put the Resp tag in tests 2 and 3 because some operating systems _do_ drop those without responding.
```
> T5(DF=N%W=0%ACK=S++%Flags=AR%Ops=)
> T6(DF=N%W=0%ACK=O%Flags=R%Ops=)
> T7(DF=N%W=0%ACK=S%Flags=AR%Ops=)
```
These tests are a SYN, ACK, and FIN|PSH|URG, respectively, to a closed port. The same options as always are set. Of course this is all probably obvious given the descriptive names 'T5', 'T6', and 'T7' :).
```
> PU(DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)
```
This big sucker is the 'port unreachable' message test. You should recognize the DF=N by now. TOS=0 means that IP type of service field was 0. The next two fields give the (hex) values of the IP total length field of the message IP header and the total length given in the IP header they are echoing back to us. RID=E means the RID value we got back in the copy of our original UDP packet was expected (ie the same as we sent). RIPCK=E means they didn't fuck up the checksum (if they did, it would say RIPCK=F). UCK=E means the UDP checksum is also correct. Next comes the UDP length which was 0x134 and DAT=E means they echoed our UDP data correctly. Since most implementations (including this one) do not send any of our UDP data back, they get DAT=E by default.

The version of nmap with this functionality is currently in the 6th private beta cycle. It may be out by the time you read this in Phrack. Then again, it might not. See http://www.insecure.org/nmap/ for the latest version.

POPULAR SITE SNAPSHOTS

Here is the fun result of all our effort. We can now take random Internet sites and determine what OS they are using. A lot of these people have eliminated telnet banners, etc. to keep this information private. But this is of no use with our new fingerprinter! Also this is a good way to expose the <your favorite crap OS> users as the lamers that they are :)!

The command used in these examples was: nmap -sS -p 80 -O -v <host>

Also note that most of these scans were done on 10/18/98. Some of these folks may have upgraded/changed servers since then.

Note that I do not like every site on here.

# "Hacker" sites or (in a couple cases) sites that think they are

www.l0pht.com        => OpenBSD 2.2 - 2.4
www.insecure.org     => Linux 2.0.31-34
www.rhino9.ml.org    => Windows 95/NT     # No comment :)
www.technotronic.com => Linux 2.0.31-34
www.nmrc.org         => FreeBSD 2.2.6 - 3.0
www.cultdeadcow.com  => OpenBSD 2.2 - 2.4
www.kevinmitnick.com => Linux 2.0.31-34  # Free Kevin!
www.2600.com         => FreeBSD 2.2.6 - 3.0 Beta
www.antionline.com   => FreeBSD 2.2.6 - 3.0 Beta
www.rootshell.com    => Linux 2.0.35  # Changed to OpenBSD after
                                      # they got owned.

# Security vendors, consultants, etc.
www.repsec.com       => Linux 2.0.35
www.iss.net          => Linux 2.0.31-34
www.checkpoint.com   => Solaris 2.5 - 2.51
www.infowar.com      => Win95/NT

# Vendor loyalty to their OS
www.li.org           => Linux 2.0.35 # Linux International
www.redhat.com       => Linux 2.0.31-34 # I wonder what distribution :)
www.debian.org       => Linux 2.0.35
www.linux.org        => Linux 2.1.122 - 2.1.126
www.sgi.com          => IRIX 6.2 - 6.4
www.netbsd.org       => NetBSD 1.3X
www.openbsd.org      => Solaris 2.6     # Ahem :)
www.freebsd.org      => FreeBSD 2.2.6-3.0 Beta

# Ivy league
www.harvard.edu      => Solaris 2.6
www.yale.edu         => Solaris 2.5 - 2.51
www.caltech.edu      => SunOS 4.1.2-4.1.4  # Hello! This is the 90's :)   
www.stanford.edu     => Solaris 2.6
www.mit.edu          => Solaris 2.5 - 2.51 # Coincidence that so many good
                                           # schools seem to like Sun?
                                           # Perhaps it is the 40%
                                           # .edu discount :)
www.berkeley.edu     => UNIX OSF1 V 4.0,4.0B,4.0D  
www.oxford.edu       => Linux 2.0.33-34  # Rock on!

# Lamer sites

www.aol.com          => IRIX 6.2 - 6.4  # No wonder they are so insecure :)
www.happyhacker.org  => OpenBSD 2.2-2.4 # Sick of being owned, Carolyn?
                                        # Even the most secure OS is
                                        # useless in the hands of an
                                        # incompetent admin.
# Misc
www.lwn.net          => Linux 2.0.31-34 # This Linux news site rocks!
www.slashdot.org     => Linux 2.1.122 - 2.1.126
www.whitehouse.gov   => IRIX 5.3
sunsite.unc.edu      => Solaris 2.6

Notes: In their security white paper, Microsoft said about their lax security: "this assumption has changed over the years as Windows NT gains popularity largely because of its security features.". Hmm, from where I stand it doesn't look like Windows is very popular among the security community :). I only see 2 Windows boxes from the whole group, and Windows is _easy_ for nmap to distinguish since it is so broken (standards wise).

And of course, there is one more site we must check. This is the web site of the ultra-secret Transmeta corporation. Interestingly the company was funded largely by Paul Allen of Microsoft, but it employs Linus Torvalds. So do they stick with Paul and run NT or do they side with the rebels and join the Linux revolution? Let us see:

We use the command: nmap -sS -F -o transmeta.log -v -O www.transmeta.com/24

This says SYN scan for known ports (from /etc/services), log the results to 'transmeta.log', be verbose about it, do an OS scan, and scan the class 'C' where www.transmeta.com resides. Here is the gist of the results:

neon-best.transmeta.com (206.184.214.10) => Linux 2.0.33-34
www.transmeta.com 206.184.214.11) => Linux 2.0.30
neosilicon.transmeta.com (206.184.214.14) => Linux 2.0.33-34
ssl.transmeta.com (206.184.214.15) => Linux unknown version
linux.kernel.org (206.184.214.34) => Linux 2.0.35 
www.linuxbase.org (206.184.214.35) => Linux 2.0.35 (possibly the same machine as above)

Well, I think this answers our question pretty clearly :).

ACKNOWLEDGEMENTS

The only reason Nmap is currently able to detect so many different operating systems is that many people on the private beta team went to a lot of effort to search out new and exciting boxes to fingerprint! In particular, Jan Koum, van Hauser, Dmess0r, David O'Brien, James W. Abendschan, Solar Designer, Chris Wilson, Stuart Stock, Mea Culpa, Lamont Granquist, Dr. Who, Jordan Ritter, Brett Eldridge, and Pluvius sent in tons of IP addresses of wacky boxes and/or fingerprints of machines not reachable through the Internet.

Thanks to Richard Stallman for writing GNU Emacs. This article would not be so well word-wrapped if I was using vi or cat and ^D.

Questions and comments can be sent to fyodor@DHP.com (if that doesn't work for some reason, use fyodor@insecure.org). Nmap can be obtained from http://www.insecure.org/nmap .

Remote OS detection via TCP/IP Stack FingerPrinting by Fyodor <fyodor@dhp.com> (www.insecure.org) October 18, 1998

CLASSICAL TECHNIQUES

CURRENT FINGERPRINTING PROGRAMS

FINGERPRINTING METHODOLOGY

NMAP IMPLEMENTATION AND RESULTS

Remote OS detection via TCP/IP Stack FingerPrinting
by Fyodor <fyodor@dhp.com> (www.insecure.org)
October 18, 1998