Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: [Patch] Improving OS Detection
From: Daniel Miller <bonsaiviking () gmail com>
Date: Fri, 4 Jul 2014 14:45:42 -0500

On Fri, Jul 4, 2014 at 1:46 AM, Jay Bosamiya <jaybosamiya () gmail com> wrote:

Hi All!

During OS detection, Nmap choses one open TCP port, one closed TCP port
and one closed UDP port to work with. However, if the chosen open TCP
port is "tcpwrapped" (possibly due to a firewall), we may sometimes not
get accurate results.

To get past this, we can choose another open port to work with (since we
only need an open port, the actual port doesn't matter).
The attached patch does this.

I have tested this using multiple VMs with different OSs installed (both
with and without tcpwrapping (using tcpd) and using differing port
ranges too). All tests pass.

Cheers,
Jay

PS: With the current usage of the PortList::isTCPwrapped() function, the
o.debugging>1 messages will NEVER appear but they are there to
facilitate debugging if the function is used elsewhere at some point of
time.


To clarify the intent of this patch, I'll give an example of a case where
this was a problem:

We received an OS fingerprint correction where Nmap had classified a system
as Windows, but it was clearly some sort of Linux-based host.
Unfortunately, there was a firewall in between Nmap and the host that was
responding on behalf of the host, opening TCP connections and then closing
them immediately. Because of this, the "open" TCP port that Nmap chose to
send probes to was actually on the firewall, so Nmap wasn't really
fingerprinting the target system. In this particular case, because the user
had requested a version scan (-sV), Nmap had one bit of information that it
could have used to choose a more appropriate port: the firewalled ports
were all labelled "tcpwrapped."

This is probably a very unlikely scenario for most users, and there is
nothing wrong with a truly tcpwrapped port being used in OS fingerprinting
when the host OS is the one responding, but it seemed worth the effort to
choose a different port.

If anyone else has ideas on how to avoid choosing ports that are actually
responses by a firewall, I'd welcome them. This goes for TCP ports in open
and closed states, and closed UDP ports (ICMP Port Unreachable responses).

Dan
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault