2

I am interested in using nmap for discovery, and to figure out the OS of each host. I understand that nmap does this, and can be enabled and controlled as described in the man page:

OS detection is enabled and controlled with the following options:

-O (Enable OS detection) .

Enables OS detection, as discussed above. Alternatively, you can use -A to enable OS detection along with other things. --osscan-limit (Limit OS detection to promising targets) . OS detection is far more effective if at least one open and one closed TCP port are found. Set this option and Nmap will not even try OS detection against hosts that do not meet this criteria. This can save substantial time, particularly on -Pn scans against many hosts. It only matters when OS detection is requested with -O or -A. --osscan-guess; --fuzzy (Guess OS detection results) . When Nmap is unable to detect a perfect OS match, it sometimes offers up near-matches as possibilities. The match has to be very close for Nmap to do this by default. Either of these (equivalent) options make Nmap guess more aggressively. Nmap will still tell you when an imperfect match is printed and display its confidence level (percentage) for each guess. --max-os-tries (Set the maximum number of OS detection tries against a target) . When Nmap performs OS detection against a target and fails to find a perfect match, it usually repeats the attempt. By default, Nmap tries five times if conditions are favorable for OS fingerprint submission, and twice when conditions aren't so good. Specifying a lower --max-os-tries value (such as 1) speeds Nmap up, though you miss out on retries which could potentially identify the OS. Alternatively, a high value may be set to allow even more retries when conditions are favorable. This is rarely done, except to generate better fingerprints for submission and integration into the Nmap OS database.

My question is if it is possible to disable the port scanning portion of the OS detection process. It doesn't seem to be possible considering the man page, but doesn't seem unreasonable in principle.

MattUebel
  • 927
  • 4
  • 13
  • 32

4 Answers4

5

Nmap requires at least 1 closed and 1 open port to do a reliable OS match. By default, Nmap's port scan scans 1000 TCP ports. You can reduce the time required by the port scan phase by reducing the number of ports scanned. Here is a good set that has a high probability of resulting in 1 open and 1 closed port:

nmap -p 22,80,445,65123,56123 -O scanme.nmap.org

This will only scan the 5 ports listed, which is 0.5% of a normal scan.

bonsaiviking
  • 4,420
  • 17
  • 26
4

There is the "-sn" option specified in the man page to disable port scanning, but nmap will complain about OS detection being unreliable without port scanning.

http://nmap.org/book/man-briefoptions.html

Michael
  • 468
  • 2
  • 13
4

A ping will not return enough information to identify an OS. The OS fingerprint is based on open and closed ports and responses to well-known ports. If you don't scan some ports, how will you know what ports are open and closed, and what the response is?

tl;dr: no.

longneck
  • 23,082
  • 4
  • 52
  • 86
  • ICMP probes are part of the OS detection process as well: http://nmap.org/book/osdetect-methods.html – MattUebel Jul 11 '13 at 17:18
  • 1
    the only thing that can be really said is that the detection will be unreliable, if unreliable is ok then yes you can use ping to do os detection. – tony roth Jul 11 '13 at 17:32
2

My question is if it is possible to disable the port scanning portion of the OS detection process. It doesn't seem to be possible considering the man page, but doesn't seem unreasonable in principle.

So the quick reply is: NO

Ping reply is pretty standard everywhere. You can't make a remote OS detection based on ping reply. Some firewalls disable ping replies altogether (stealth mode). Here you will find more details on ping alias ICMP or if you want to dig into it try the RFC.

NOTE: If your aim is remote OS detection without getting notice, you're better of reading HTTP headers - normally your weird GET request will get lost in the logs - or try something like p0f that does Passive OS Fingerprinting. Note POF will work only if you and the host are in the same network.

PF supports this option also.

Community
  • 1
atmosx
  • 189
  • 1
  • 9
  • fair enough that some hosts block ICMP, but it seems that ICMP can be used to make guesses at the host's OS: IP packets contain a field named time-to-live (TTL) which is decremented every time they traverse a router. If the field reaches zero, the packet must be discarded. This prevents packets from looping endlessly. Because operating systems differ on which TTL they start with, it can be used for OS detection – MattUebel Jul 11 '13 at 17:22
  • @atmosx not sure how looking at http headers would work very well either, 99.9% of my servers don't run http. – tony roth Jul 11 '13 at 18:38
  • 1
    p0f works fine from distant networks. Its signatures are for incoming connections, though. – bonsaiviking Jul 11 '13 at 21:07
  • @tonyroth sure, I was referring to the ones who run... You issue via netcat/telnet a "HEAD" request will show some info, sometimes enough (Apache/SSL Debian Wheezy, etc.). It's a very old *trick*. Same can be used for other ports but as you said, no server runs every service... – atmosx Jul 11 '13 at 21:29
  • 1
    @MattUebel well yes and no. Router can modify the TTL so again it's not an all-around idea, specially since some ISPs tend to play with these flags more often than not. – atmosx Jul 11 '13 at 21:30