July 27, 2006
Will an nmap Operating System scan work through a firewall?
From the mailbag, Jesse C. writes:
I have been assigned a project within my organization to perform OS Fingerprinting on subnets. What I find is that end-users that do not use Windows Firewall (have it disabled or not installed), I am able to detect their OS with no problem. The problem lies that many new users have Windows SP2 Firewall enabled which are limiting my scan results. I am using the following nmap command in Linux. (# nmap -sS -O -PI 192.168.0.1/24)
What should I do to accurately perform an OS Fingerprint scan on my subnet? If not 100% accurate, what nmap commands would your suggest?
OS Fingerprinting against a filtered device is certainly a challenge. In most cases where a firewall or packet filter is in place, the OS fingerprint won't be very accurate. This is because the OS fingerprinting process needs to find at least one open port and one closed port to make the resulting fingerprint worthwhile.
Nmap only sends eight frames to complete an OS scan. Four of the frames are TCP frames to an open port, three are TCP frames to a closed port, and one is a UDP frame to a closed port. The resulting operating system determination is based on the responses of these eight tests. If we only get to run four or five of the eight tests, the fingerprinting obviously won't be as accurate. We need to determine which TCP ports are open or closed prior to the OS scan, which is why nmap requires a TCP-based scan to run along with the operating system tests.
When it comes to OS scans, personal firewalls are problematic. Since most port scans are going to be dropped unless administratively allowed in the firewall, nmap won't ever find a closed port. If the firewall is tightened down to disregard exceptions, you won't even find an open port!
There's not a lot you can do to improve the accuracy of the OS fingerprinting when a firewall is in place. Once the firewall has decided to drop the frames to the port, you're out of luck regardless of the nmap scan type.
If the system you’re scanning is using Microsoft’s Windows Firewall and you have more control over your location on the network, you may find that you're able to find open or closed ports if you're on the same subnet as the target devices. Some of the Windows file sharing features are automatically configured in Windows Firewall to trust devices on a local IP subnet when attempting to connect with port 445.
If you're scanning across subnets, you may want to take advantage of idlescan to determine if the ports might be open to a local device but not a remote device. An idlescan won't support an OS scan, but it might get you a little closer to the information you need.
In the end, you may be able to tell more about the operating system running on a remote device by running a version scan (-sV). Unfortunately, a version scan is relatively invasive and you’ll certainly show up in an application log on the target device.
Posted by james_messer at July 27, 2006 07:12 PM