Nmap uses a variety of testing methods and fingerprints to determine - or at least guess at - what services are running on each discovered port, and what operating system is running on the host. (When -sV and -O, or other appropriate options, are used.) I'm sure all of this is fairly well-documented in the Nmap online documents, and in the scripts that are run for these purposes. However, Nmap itself doesn't seem to do a very good job of exposing these internals - at least, not with default settings.

I'd like to know if there's a way to add some sort of justification for Nmap's service/OS identity selections to its output. Something that, for each service/OS ID, says something along the lines of "[Service/OS ID] chosen because [Test(s) used for fingerprinting] resulted in [Response(s) received]". Even better might be an additional list of other possible fingerprint matches that are very close to the one observed, or any responses from the target system which deviated from those normally expected of the indicated service/OS.

I think some of this may be available through tweaking verbosity and debugging output levels. However, I'd rather (if natively supported) be able to get these details without bloating the output beyond what's necessary to serve this purpose.

How do I get Nmap to provide output that provides additional transparency into its service/OS fingerprinting logic? Is there a way to do this without adding a lot of other noise to the output?

  • This really belongs on a different stack site since it's asking about specific hardware/software and not really security. I'd recommend the serverexchange stack since they would really be the people to know Nmap(if anyone) Commented Feb 23, 2016 at 23:10
  • I have had the same problem, and my process has simply been to verify the nmap results by specific tools for the reported service.
    – schroeder
    Commented Feb 23, 2016 at 23:28
  • 2
    @RobertMennell security tools are in topic. Why do you think this doesn't belong here? Commented Feb 24, 2016 at 2:49
  • @NeilSmithline I'm not surprised that some might suggest it's off-topic. Nmap is, in many ways, useful beyond just the IT Security realm. And this is mainly about getting visibility into the internals of the tool itself - not anything particularly security-specific. I'm totally okay if it ends up migrated to Super User or Server Fault. I just figured I'd give it a shot here first.
    – Iszi
    Commented Feb 24, 2016 at 14:06
  • @NeilSmithline It's because it's not really about the security it can be used to find, more about the inner workings of it. This is really asking more for how the command line arguments work for it and how to use the tool more efficiently. If it were about how to use it to find something for security reasons, I never would have suggested it. I just think people on server/super might have more use for this question in the future than here. Commented Feb 24, 2016 at 17:14

1 Answer 1


Ok, let's see if I can help:

OS Fingerprinting

  • At default verbosity, the OS fingerprinting engine provides the line number of the matched fingerprint in the nmap-os-db file in the XML output as the "line" attribute of the "osmatch" element. (For IPv6, this number is the ordinal group within the classifier. Because of the machine-learning approach, it's harder to see why a particular scan matched a particular OS group.)
  • With -v2 or higher or -d, the exact fingerprint (observation) that was used to match is printed in Normal and XML output formats.
  • Sometimes an OS will be printed on a "Service Info" line in the Normal output. This comes from the o// template in the nmap-service-probes file. The XML output has this info directly under the "service" tag as the "ostype" attribute. More on this in the next section...

Service fingerprinting

  • At default verbosity, the service fingerprint (exact probe responses) will be printed if no match is found and you did not reduce version intensity with a command-line option (--version-intensity or --version-light).
  • The --version-trace option turns on lots of interesting Normal-mode output regarding which probes are sent, and which ones match.
  • The --packet-trace option can print exact hex dumps of what is sent and returned.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .