Nmap OS Fingerprint Scan as an Administrative Tool

You are here: SecurityOwned Home » Penetration Testing Toolkit » Nmap » Nmap OS Fingerprint Scan as an Administrative Tool

30Jun/090

For an administrator, Nmap is not only cost effective, but it can also save you an enormous amount of time and labor. It can even save you money by keeping your license information to date. The operating system fingerprint scan gives all of these benefits to us in the -O flag. Something as simple as:

#nmap --O <ip subnet>

Or even a happy median for a typical system administrator performing an inventory scan or security audit might be something along the lines of:

#nmap --fuzzy -sV -F <ip address or subnet>

The --fuzzy flag tells Nmap to take its best guess at determining the type of operating system running. The --fuzzy flag is comparable to another liberal guessing algorithm that can be utilized by issuing the --osscan_guess flag in your commands. The -sV flag tells Nmap to try to determine service version information as well. Version detection is dependant upon the OS fingerprint scan finding an open TCP or UDP port. After port

discovery, version detection takes over and starts its process of probing for information regarding what is open and running on the target. This portion of the scan can be the key to an easy attack in the hands of would be hackers. For example, imagine how simple it might be to find a HP-UX system running an unpatched, older version of BIND. Imagine further still, how easy an attack would be given the added luxury of knowing

the BIND service version number. This, indeed, would narrow the time needed for an attacker to infiltrate the system and potentially gain root access. A smaller attack footprint equals a lesser chance you have to detect the attacker before the damage is done. All too often, administrators come in well after an intrusion has occurred and are left with a shadowy trail leading back to an unknown, foreign system that makes it impossible to pursue any viable prosecution avenues. This is why proactive administrators should fully understand Nmap and put into place methods to protect themselves from it, by using its assets to their own advantage. With this understanding comes protection and the ability to use Nmap as a very powerful tool in your organization.

And now, back to our scan. Version scanning has its place, but a wealth of information alone can be obtained about a system by simply utilizing Nmap's OS fingerprinting facilities with the option to allow Nmap to take its best guess at the OS if its not exactly matched using the -- osscan_guess flag.

Here we see the return on the scan of a Cisco Linksys Wireless G router using such tactics:

#nmap -F -O --osscan_guess 192.168.10.24

...

Interesting ports on 192.168.10.24:

Not shown: 1254 closed ports

PORT STATE SERVICE

80/tcp open http

443/tcp open https

MAC Address: 00:12:17:34:XX:XX (Cisco-Linksys)

Aggressive OS guesses: Linux 2.4.22 (Fedora Core 1, x86) (90%), Ipcop V1.4.11

firewall (Linux 2.4.31) (90%), Xerox WorkCentre Pro 265 multifunction printer (89%),

Linux 2.4.20 - 2.4.32, Linux-based embedded device (Linksys WRT54GL WAP, Buffalo

AirStation WLA-G54 WAP, Maxtor Shared Storage Drive, or Asus Wireless Storage

Router) (89%), Linux 2.4.18-10 (Red Hat 7.3) (87%), Netgear DG834 or DG834G

(wireless) DSL Router (86%), Aladdin eSafe security gateway (runs Linux 2.4.21)

(85%), D-Link DSL-G604T ADSL router WAP, runs Linux 2.4.17 (85%), Belkin Wireless

Pre-N Router (85%), Siemens Gigaset SE515dsl wireless broadband router (85%)

No exact OS matches for host (If you know what OS is running on it, see http://

insecure.org/nmap/submit/).

TCP/IP fingerprint:

OS:SCAN(V=4.50%D=11/18%OT=80%CT=1%CU=40873%PV=Y%DS=1%G=Y%M=001217%TM=4740A1

OS:A8%P=i686-pc-linux-gnu)SEQ(SP=D0%GCD=1%ISR=CC%TI=Z%II=I%TS=7)OPS(O1=M5B4

OS:ST11NW0%O2=M5B4ST11NW0%O3=M5B4NNT11NW0%O4=M5B4ST11NW0%O5=M5B4ST11NW0%O6=

OS:M5B4ST11)WIN(W1=16A0%W2=16A0%W3=16A0%W4=16A0%W5=16A0%W6=16A0)ECN(R=Y%DF=

OS:Y%T=40%W=16D0%O=M5B4NNSNW0%CC=N%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F=AS%RD=0%Q

OS:=)T2(R=N)T3(R=N)T4(R=N)T5(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(

OS:R=N)T7(R=N)U1(R=Y%DF=N%T=40%TOS=C0%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUC

OS:K=G%RUL=G%RUD=G)IE(R=Y%DFI=N%T=40%TOSI=S%CD=S%SI=S%DLI=S)

Uptime: 0.060 days (since Sun Nov 18 13:08:02 2007)

Network Distance: 1 hop

As it turns out, Nmap does not have an exact match for the operating system of this host. In this situation, Nmap prints out the TCP/IP fingerprint in hopes that the end-user ultimately verifies the OS of the targeted system and in turn, submits the fingerprint to help upgrade Nmap's fingerprint database. In order to more easily interpret the output, it is helpful to have some insight into how the fingerprint is formed. The block of text that we just saw is formatted for easy submittal to the insecure.org website for research and potential entry into the Nmap database. For our purposes in understanding the output, we'll reformat the block to better see the tests:

TCP/IP fingerprint:

SCAN(V=4.50%D=11/18%OT=80%CT=1%CU=40873%PV=Y%DS=1%G=Y%M=001217%TM=4740A1A8%P=

i686-pc-linux-gnu)

SEQ(SP=D0%GCD=1%ISR=CC%TI=Z%II=I%TS=7)

OPS(O1=M5B4ST11NW0%O2=M5B4ST11NW0%O3=M5B4NNT11NW0%O4=M5B4ST11NW0%O5=M5B4ST11NW0%O6=

M5B4ST11)

WIN(W1=16A0%W2=16A0%W3=16A0%W4=16A0%W5=16A0%W6=16A0)

ECN(R=Y%DF=Y%T=40%W=16D0%O=M5B4NNSNW0%CC=N%Q=)

T1(R=Y%DF=Y%T=40%S=O%A=S+%F=AS%RD=0%Q=)

T2(R=N)

T3(R=N)

T4(R=N)

T5(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)

T6(R=N)

T7(R=N)

U1(R=Y%DF=N%T=40%TOS=C0%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUL=G%RUD=G)

IE(R=Y%DFI=N%T=40%TOSI=S%CD=S%SI=S%DLI=S)

Here are a few more things we need to know in order to understand this output:

Multiple sub-tests can be attempted for each main test: SCAN, SEQ, OPS, WIN, ECN, T1-T7, U1 and IE.

Sub-tests are separated by the % symbol. For example: R=Y%DF=Y%T=40 describes the results of 3 sub-tests.

Sub-test results may be empty in which case you will see a % or right-hand terminating parentheses. In this example, RD=0%Q=) the sub-test RD reported a result of 0, whereas the Q sub-test did not report any result.

In order for a fingerprint to match an entry in the database, the sub-test results must exactly match the fingerprint definition.

R=N means that no result was returned for any tests of that main test.

What's going on in this OS fingerprint? Let's break down the block to see.

The first line, SCAN(V=4.50%D=11/18%OT=80%CT=1%CU=40873%PV=Y%DS=1%G=Y%M=001217%TM=4740A1A8% P=i686-pc-linux-gnu), is a record of Nmap version and other related local info pertaining to this scan. We can see the Nmap version (4.50) being utilized, in addition to some date, timestamp, and scanning operating system information:

SCAN(V=4.50 Describes the version of Nmap utilized.

D=12/13 is the date the scan was run.

OT=80%CT=1 describe the Open and Closed TCP ports that Nmap used during the fingerprinting process

CU=40873 is the Closed UDP port utilized for the fingerprint test.

PV=Y this tells us that the IP address fingerprinted resides in Private (RFC-1918) IP address space.

DS=1 is the number of hops in network distance from the Nmap scanner to the scanned host.

G=Y this means that our fingerprint results are Good enough to submit to insecure. org, if we decide to do so.

M=001217 if DS=1, then Nmap is able to discern the MAC OID of the targeted system.

TM=4740A1A8 this is the time the scan was performed in Unix hexadecimal time format.

P=i686-pc-linux-gnu) Describes the platform the scan was conducted from.

Next we'll check out the SEQ, OPS, WIN, and T1 variables. These results are derived from a set of 6 very precise probes that are sent to the open TCP port on the targeted host.

The SEQ test, SEQ(SP=D0%GCD=1%ISR=CC%TI=Z%II=I%TS=7) returns information regarding sequence analysis:

SEQ(SP=D0 Reports on TCP Initial Sequence Number (ISN) Predictability.

GCD=1 Greatest Common Denominator, this sub-test provides feedback about TCP ISN incrementation.

ISR=CC Describes the ISN sequence rates.

TI=Z Evaluates the TCP SEQ probe IP header ID field. In this example, Z means that all IP ids returned were set to 0.

II=I Evaluates the IP IDs based on the responses to the ICMP probes. A value of I reflects incremental ids.

TS=7) Returns information about the TCP timestamp attached to the responses. 7 reflects a 100Hz frequency in use by the target

The OPS response, OPS(O1=M5B4ST11NW0%O2=M5B4ST11NW0%O3=M5B4NNT11NW0%O4=M5B4ST11NW0%O5= M5B4ST11NW0%O6=M5B4ST11) contains the TCP options received for each of the 6 probes.

OPS(O1=M5B4 Test O1 reports a Maximum Segment Size (MSS) of 0x5B4.

ST11 provides information about a permitted Selective ACK and the timestamp of the packet.

N is a NOP or No Operation.

W0 reflects a Window scale size of 0.

You can determine the makeup of the responses for the remaining responses of this test:

O2=M5B4 Test O2 reports a MSS of 0x5B4

ST11

N

W0

O3=M5B4 Test O3.

N

N

T11

N

W0

O4=M5B4 Test O4.

ST11

N

W0

O5=M5B4 Test O5.

ST11

N

W0

O6=M5B4ST11) Test O6

WIN, WIN(W1=16A0%W2=16A0%W3=16A0%W4=16A0%W5=16A0%W6=16A0) returns the TCP initial windows size information for each of the 6 probes.

WIN(W1=16A0

W2=16A0

W3=16A0

W4=16A0

W5=16A0

W6=16A0)

Finally, we see the ECN(R=Y%DF=Y%T=40%W=16D0%O=M5B4NNSNW0%CC=N%Q=) or explicit congestion notification response.

ECN(R=Y indicates whether or not the target responded to our probe.

DF=Y evaluates whether the IP don't fragment bit is enabled or not.

T=40 The IP time-to-live value found in the response.

W=16D0 TCP initial window size information.

O=M5B4NNSNW0 TCP Options information.

CC=N Examines the Explicit Congestion Notification (congestion control) capability of the target. N indicates the target does not support ECN.

Q=) Looks for any known quirks in the TCP stack of the target.

Next in the process, we see 6 TCP specific probes. This is part of the second wave of probes. By now you should have a feel for interpreting these test results. If any of the following sub-tests look unfamiliar, or if you are interested in even more information about these tests, you can also check out http://insecure.org/nmap/osdetect/osdetect-methods.html.

This is the first of the TCP probes that are sent. This is the more intense of the TCP probes. T1(R=Y%DF=Y%T=40%S=O%A=S+%F=AS%RD=0%Q)

T2 is a null packet sent with the IP DF bit set and a window field size of 128. T2(R=N)

T3 is a TCP packet set with FIN, URG, PSH, and SYN flags all set and a window field size of 256. T3(R=N)

T4 sends a TCP ACK packet with a window field of 1024 and IP DF bit set. T4(R=N)

T5 sends a SYN packet with the ubiquitous and glorious prime 31337 as its window field size. T5(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)

T6 is very similar to T4, just a larger window field size of 32768 and to a closed port, instead of open. T6(R=N)

Here we finish up this set of TCP probes by sending a packet with FIN, URG, and PSH flags set. This probe goes to a closed port with a window field size of 65535. T7(R=N)

This is the U1, UDP probe results. This probe goes to a closed port and the character 'C' is repeated 300 times in the data field. U1(R=Y%DF=N%T=40%TOS=C0%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUL=G%RUD=G

The IE probe is based on the ICMP protocol. It is a two part probe, both being very similar in structure and comprised of such elements as: type-of-service (TOS), IP ID, sequence numbers, and data payloads consisting of the typical repeated character methodology used in other probes. IE(R=Y%DFI=N%T=40%TOSI=S%CD=S%SI=S%DLI=S)

One question you might ask at this point would be, "Yes, but how can this help me in my enterprise environment? How can I use this as a tool and in a proactive way in my environment?"

An Nmap OSFS will yield information on any live IP addresses found in the range specified at command issuance. This means that it can supply information regarding your switches, routers, storage appliances, servers of all types, and anything else alive on an IP address. As you get more comfortable running and interpreting the fingerprints for your enterprise, you will be able to take any fingerprint returned and unknown by Nmap, and modify the OS fingerprint database, nmap-os-db. All you need to do is clean up the returned unidentified OS fingerprint as we did above, and integrate it into the nmap-os-db to reflect the format of the current standard entries.

By adding your own fingerprints into the database, you will build up your custom database with relevance to your particular infrastructure. This way, you have the power of expanding the functionality of Nmap in your environment, instead of waiting for your particular fingerprints to be incorporated into the next release by the Nmap development team. Of course, you also have the option of documenting it and sending the related information to Fyodor at http://insecure.org/nmap/submit/. Taking the time to submit your fingerprints to Nmap for their reference, you in turn aide the community in making Nmap a more powerful overall product. Every user is highly encouraged in this way to participate fully in the open source philosophy. Doing so, we all work together to further enhance products and make our networks even more secure.

The ability to modify your local OS fingerprinting database gives you a very powerful tool in the area of asset management and equipment inventory documentation. Of course, utilizing this capability will require that systems administrators be proactive and thorough in their execution and documentation.

Share and Enjoy: