Nmap OS Fingerprinting
Introduction
Nmap OS fingerprinting can cover a wide range of topics pertaining to an enterprise environment. As an administrator, you can use Nmap for asset management, security audits, documenting equipment inventory, and as a crisis management tool. Aside from the positive uses of this tool, some have also been known to capitalize on its power for malicious deeds. Unfortunately, attacks against our enterprise infrastructures and computing environments are happening on an hourly basis. It is the way of the digital world today. Knowing this and knowing what an attacker can do with Nmap OS fingerprinting, and employing a few simple techniques of your own can help to secure your infrastructure. In the world of information security, we can often find positives from areas of negative influence; the important part is being aware in your environment. Nmap’s OS fingerprinting can be a very powerful tool in the realm of enterprise awareness.
In this chapter we will work through the mechanics of Nmap OS fingerprinting, how it can be used as a proactive tool by systems administrators, how nefarious individuals tend to use it as a weapon in their arsenal, and how you can defend against those techniques.
What is OS fingerprinting?
Operating system fingerprinting is so named because of its similarity to taking a person’s fingerprints in order to determine their identification. The unique characteristics of a person can be translated from the person’s fingertips to an object simply by touching it. As with OS fingerprinting, a rather innocuous session can be conducted between two computers where one acquires, via probes, a unique set of impressions or response data, relating to the destination machine. This process of analyzing the impressions of the destination machine is known as OS fingerprinting.
The Mechanics of Nmap OS Fingerprinting
OS fingerprinting can be done passively or actively as follows:
■ Passive OS fingerprinting involves sniffing network traffic at any given collection point and matching known patterns that pass to a table of pre-established OS identities. No traffic is sent with passive fingerprinting.
■ Active OS fingerprinting requires the use of a set of specialized probes that are sent to the system in question. System responses from this active probing give insight into what type of OS might be installed.
Nmap does not use a passive style of fingerprinting. Instead it performs its Operating System Fingerprinting Scan (OSFS) via active methodologies. The active process that Nmap applies in order to conduct its fingerprinting scan involves a set of as many as 15 probes. These powerful probes are designed to utilize TCP, UDP, and ICMP protocols. The probes are gentle manipulations of packet structure designed to reveal subtle nuances in response.
Ultimately, the information gathered via these specialized probes is used to generate the unique fingerprint that is compared in a database of known operating systems characteristics. These unique sets of OS traits are kept in the nmap-os-db file. Nmap uses this comparison to try to determine an OS fingerprint match. Thus, in the end, Nmap can take a very intelligent guess at just what OS the remote computer is running by conducting a rather low signature set of probes. Released in 2006, the nmap-os-db file is part of the second generation of OS fingerprinting featured in Nmap. In prior versions of Nmap, if you wanted to utilize the original style of OS fingerprinting, you had the option of invoking it by using an –O1 flag. This –O1 flag told Nmap to use the file nmap-os-fingerprints instead of the new standard. The current generation of OS fingerprinting simply uses the –O (letter O, not the number 0) flag. Accordingly, the base OS scan command with minimum ports is simply:
This performs the most basic OS fingerprint scan. Although you can employ advanced flag settings in an OS scan command, it’s not really necessary. Nmap’s base OS fingerprinting methodology has a very low network resource overhead. The reason for its small footprint is its streamline use of the probes. All of the probes are very lightweight, but pack a powerful punch in yielded information. Aside from a small network presence, it is also easy on local system resources.
The screenshot in Figure 6.1 represents resource utilization prior to the launch of the Nmap scan. Contrast this with Figure 6.2; notice how the Firefox session is consuming 3 times the system resources as an Nmap OSFS during its peak. Nmap does a very good job of using only minimal resources, both local and network, to achieve fantastic results. This OSFS example only consumed 4.2% of local system memory to conduct the scan for this particular example. Incidentally, this was also being run from within a small virtual machine … not bad.
Nmap OS Fingerprint Scan as an Administrative Tool
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:
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:
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.
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.
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
■ 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.
W2 = 16A0
W3 = 16A0
W4 = 16A0
W5 = 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.
Nmap to the Rescue! Tool for Crisis?
Nmap OSFS can be a useful tool for an administrator in more than a few ways. In addition to proactive usefulness, the information yielded by a well-planned and executed Nmap OS and version scan can aide an administrator in times of crisis.
For example, assume you have a computer on your LAN that’s been infected with a trojan-carrying virus that in turn, has spawned an e-mail server. A fairly simple Nmap OS and version scan can tell you the computer, its related IP and MAC address information, the type of services it has running and their related ports. This can save a battle-weary administrator a midnight “suspicious system search” in the event of an outbreak such as this. One common problem that exacerbates this example is when the owner of that suspicious computer is on vacation during the outbreak or otherwise unavailable. This makes it even more difficult to locate the afflicted computer. System administrators have long relied on various ways of performing this type of task using widely-regarded commercial appliances and lots of manpower. However, you can also become intimately familiar with your environments and utilize the full potential of powerful open source applications such as Nmap. Ultimately, this philosophy could save your organization money and make you a very valuable asset.
Saving Hard Money with the Nmap OSFS
Nmap OS fingerprinting can also assist your IT budget by providing important details on operating systems in the enterprise and making it much easier to keep your licenses and related contracts in order.
For example, you may think you have 142 SQL servers on your network, when in reality; Bob’s engineering team stopped using SQL databases 6 months ago. They did not inform you or your team of the changes. Their team previously accounted for 126 of those 142 total SQL databases. Lucky for you, you’re not relying on Bob’s good intentions to have your budgets and account payables in order. An Nmap OSFS of Bob’s subnet tells you that they are actually only using 97 SQL databases now. That’s a difference of 29 SQL databases and quite a savings when it comes down to the licensing. It is often quite difficult for the IT department to justify itself because of its inability to provide a positive cash flow for the organization. This method and approach to proactive savings will give you ability and credibility to justify your resource requirements and cost adjustments.
Another scenario that could be posed to the administrator is the task of finding all the computers across the network that are still using Windows 2000, and decommission them. At one point during the deployment of these systems, the organization had a restructure that required a few labs to switch around and expand or contract causing general mayhem in your otherwise well-documented and structured IT world. On top of it, two of the labs decided to trade some hardware with one another. All a savvy administrator needs to do in this situation is use Nmap and its OS fingerprinting capabilities. You can then take the results and parse them for IP addresses corresponding to the Windows 2000 signature. After you have your list of IP addresses, you can search through them against your network file to find their corresponding VLANs and subnets. This would then tell you the switch the machines are physically attached to, which should tell you a very close approximation to where they potentially sit.
Security Audits and Inventory
Nmap OS and version scanning can be an invaluable tool for recurring security audits. In the enterprise, we are frequently faced with mandatory security scans and audits for such federal regulations such as Sarbanes Oxley (SOX). This practice is something we should all strive to do, even if we do not have to satisfy SOX or other requirements. Scanning with Nmap can yield information such as open services, ports, and versions known to have exploits or otherwise malicious repercussions if left untouched. You may find that you have a rather easily exploited version of BIND running in a lab somewhere that you were not informed of.
For example, every year we have annual inventory. This helps us keep track of assets and manage them in a more proactive and financially beneficial way. Staying on top of asset inventory will help lessen employee theft as well as help you keep an eye on assets that are coming to the end of their life cycle.
Aside from equipment such as servers, Nmap can also discover information regarding appliances on the network. One common application could include staying up on network attached storage and its firmware and OS versions. An administrator could scan storage networks for OS and version information and yield a list of filers that are susceptible to a bug that could cause major issues regarding valuable data. Protecting high-risk or critical data is every admin’s number one goal. We should all strive to maintain a properly documented, patched, and protected network to house this valuable and sensitive information.
H4x0rz, Tigers and Bears…Oh MY!
Most security minded administrators keep abreast of the latest exploits being released that can affect systems in their networks. Upon hearing of a new exploit, a proactive administrator would start a scan across the network searching for versions of the potentially afflicted OS. Within a short period of time, a list could be generated and a targeted patching regiment could be initiated to get these machines back into a green state. Otherwise, if we do nothing, we leave ourselves open to a potentially crippling attack that could cost an organization untold amounts of money. Costs related to outages and data loss can easily be devastating to a business, not to mention the career of administrators asleep at the wheel.
Conversely an attacker can use Nmap and its OS fingerprinting and version detection against you in very devastating ways. If someone is allowed to scan even the most superficial areas of your network, they can ultimately gain the highest level of access and get at your information and intellectual property. Every enterprise environment of any scale is a constant target to the general hacking and malicious traffic going across the Internet at any given second. The bigger the enterprise and the more unique or valuable the data it houses, the more skilled hacker they attract. Keeping that in mind, know that even the least sophisticated hackers will use tools such as Nmap to do OS fingerprinting reconnaissance.
Information that was useful for you as a proactive admin is now a soft point for an attacker to work their way into your systems or otherwise deny them of services and impede your business flow. Aside from information regarding operating systems and exploits, an attacker could use the simple OS and version information derived from an Nmap fingerprinting attack to know the IP address of an externally facing router or wireless access point. For instance, an attacker could see a Linksys fingerprint, much like the one given as an example previously, and instantly have a foothold in attempting to gain further access to the network.
Detecting and Evading the OS Fingerprint Scan
One simple way to avoid a lot of these types of attacks is simply to stay patched and updated across the infrastructure. Unfortunately, patching and maintenance is not enough to deter a lot of hackers worth their salt. Some tactics you can use to hide from the dreaded Nmap fingerprinting scan are to employ firewalls and system-level virus protection and port stealthing. This will greatly increase your ability to remain invisible to Nmap. Other methods include the use of programs such as Morph and IP Personality. Another technique employs the use of strategically-placed honey pots. A few well placed and thought out honey pots can add a tremendous level of proactive security to your network, as well as allow you to more easily use Nmap on your network in a positive way. You simply need to exclude your honey pots in your fingerprinting scans, or take them offline while you conduct your security scans and audits.
Morph and IP Personality
One good way to avoid having Nmap successfully used against you by an attacker is to confuse the situation by presenting a false face. There are two ways to do this rather nicely. One is with a program called Morph and another called IP Personality.
Morph is a neat little program for Linux that allows a user to select some other OS to emulate. In doing so, the TCP, ICMP and UDP responses and behaviors can be modified to represent some other OS when an attacker tries to perform their reconnaissance OSFS on your network resources.
IP Personality is another program for Linux used to change how Nmap sees you in its scan results. It allows you to manipulate TCP and UDP parameters via iptables rules. This affords you the ability to further disguise yourself when it comes to giving up information regarding what OS you’re really running. The less valid information you provide to an attacker, the better.
Honey Pots
Honey pots stand as welcome hosts for would be attackers, crackers and other nefarious types. Bad guys are sucked in by the promise of an easy target and soon stuck in a sugarcoated death trap designed only in appearance to give them the soft target that they’ve been looking for. Depending on type and complexity of your honeypot setup, this technique can potentially thwart a number of mid-range hacker types that may know a thing or two, but aren’t experienced enough to recognize a trap like this until it is too late. Honey pots are meant to give you time to respond to a situation. They occupy an intruder and allow you precious time to do your own reconnaissance about their attack types and targets of interest in your infrastructure.
Summary
Knowing what you do now about operating system fingerprinting and how Nmap conducts its probes, you should have no problem thwarting unwarranted Nmap scans against your resources. By knowing how the probes are constructed, you can easily build access control lists (ACLs) or other rules to reject these packets. You can also run system level firewalls if you’re a Windows desktop user. The built-in Windows firewall actually does a pretty good job at hiding itself from basic Nmap scans. Most security appliances used in corporate networks are also quite capable of detecting Nmap operating system fingerprinting activity. All it takes is a little creativity and a solid working knowledge of your environment, and for literally no money, you can protect yourself from a potentially deadly reconnaissance attack. It is only a matter of time before an asset under your management will be attacked or otherwise probed for information. Arm yourself first with Nmap.
In this chapter we’ve discussed just what an operating system fingerprint scan is, and how Nmap goes about identifying operating systems running on detected hosts. We’ve discovered that operating system fingerprint scans are weapons in the hands of attackers. Conversely, the operating system fingerprint scan used in the hands of a skilled administrator can yield many rewards. Some of the main enterprise benefits to be gained from operating system fingerprint scans by Nmap are detailed inventory across vast environments, compliance with today’s security audit controls, and even the ability to save time and money.
The ability to modify the operating system fingerprint database gives administrators great flexibility in their environments. This feature makes it so that you can customize your database to reflect special operating system variances that may exist on only your network, and would be against non-disclosure agreements to send information regarding them to outside sources. Nmap recognizes this and puts the power in your hands with the option to submit the scan to the developers for further product enhancement for the community.
Ultimately, if hackers find their way to your network bandwidth and start to perform their OS fingerprint scans in their preliminary reconnaissance regarding your resources, the knowledge of how Nmap conducts its probes will give you the ability to properly defend your environment. Using such tactics as incorporating honey pots with Honeyd or manipulating return data with Morph or IP Personality will give you a solid start point for defending against such scans. Of course, with any good security model, you will need to apply multiple layers to be effective in thwarting would be attacks.
Solutions Fast Track
What is OS Fingerprinting?
☑ OS fingerprinting is the technique of identifying or intelligently guessing what operating system is running on a particular system by sending targeted probes or by passively listening on the network.
☑ Attackers will typically perform an OSFS on a target network as part of their information gathering process.
The Mechanics of Nmap OS Fingerprinting
☑ Nmap conducts its OS fingerprinting actively with a series of probes.
☑ TCP, UDP, and ICMP protocols are used by the probes.
☑ The probes consist of various structured packets.
☑ Some probes are very similar in nature, only varying slightly in composition. These subtle differences return values that are recorded as a fingerprint.
☑ Fingerprints are compared to a database of known signatures to attempt an OS guess.
Nmap OSFS as an Administrative Tool
☑ Nmap OSFS will yield information an administrator can use to conduct inventory scans of their environment.
☑ Compliance with typical security audits is made simpler by utilizing the Nmap OSFS.
☑ An administrator could use operating system fingerprinting to determine what machines need particular attention regarding patching or other matters.
☑ Nmap OSFS can save your organization money by helping administrators of vast networks establish efficient and detailed reports of particular systems or services that may or may not be running. This is beneficial because it allows you to fine tune your license agreements.
☑ Nmap gives you the ability to update its fingerprint database with your own custom entries. This ability will allow you to properly identify potentially sensitive information regarding systems on your network and make it a valid return on future operating system fingerprint scans.
Detecting and Evading the OS Fingerprinting Scan
☑ Firewalls, ACLs, and port masking are all ways to shield your network from Nmap OS scans.
☑ Morph and IP Personality are effective at sending deceptive and particular responses to Nmap probes.
☑ Honeypots are a great idea for giving desired returns to would be attackers to tie them up while you gain time to detect them.
Frequently Asked Questions
Q: Why would you want to edit the Nmap fingerprint database, instead of submitting it to Fyodor for addition to the official database?
A: For the most part, the proper thing to do is to enhance the community and the product and make your submission for the next official release. However there are many environments that have high security regarding internal information about operating systems and versions of software in use. For these enterprises, you are given the freedom to take the unrecognized signature generated by the OSFS, and enter it into your local Nmap database for a valid return on your next scan.
Q: I keep getting all these undetermined signatures when I scan. I really don’t want to edit the database this much. Is there anything I can do to make my scans return better information?
A: Certainly, with the breadth of operating systems available and in use these days, there will be times between version releases that invalid matches will be returned to you via the reported signature. There are two very robust methods for making Nmap take the plunge and take a guess. One of these methods is to use the --fuzzy flag. This option will force Nmap to “maybe” take a guess at what it thinks is the proper match for running OS. Another equally comparable option is given to Nmap with the --osscan_guess option.
Q: What can I do at a system level to protect myself from hackers and attackers performing these types of scans?
A: If you can hide your server behind a system level software firewall you are doing a fair job already. Turning on your firewall is always a good idea, but not necessarily quite enough to shield yourself from such scans. As another step in your plan of action, you should also consider a port stealther to mask open ports. There are also applications, such as Morph and IP Personality, that will allow a person to disguise themselves if these probes manage to eventually touch the system.
Q: I understand that Nmap can detect operating systems running on computers. Will it also help me detect info regarding my WI-FI adapters, filers, or switches on the network?
A: This is the beauty of the Nmap OS scan, especially when coupled with the version detection option. Almost any device out there that is alive on a network with an IP address is susceptible to yielding valuable data regarding its running OS and other services alive on some port.