Re: [Patch] Improving OS Detection

[Daniel Miller <bonsaiviking () gmail com>]

Jay,

This patch looks good, please commit it.

For future reference, my testing setup was the following:

sudo iptables -t nat -I OUTPUT -p tcp -d scanme.nmap.org --dport 22 -j DNAT
--to-destination 127.0.0.1:1234
ncat -lvp 1234 -k --sh-exec 'sleep 1' &
sudo ./nmap -d2 -O scanme.nmap.org -F -sV -sT

-sT was needed to allow the DNAT rule to work on my own system. Without -sV
(to detect tcpwrapped) this setup results in a very poor fingerprint, since
port 22 gets chosen, but Nmap's pcap filter doesn't detect the mangled
response packets (or is listening on the wrong interface?)

Dan



On Fri, Jul 4, 2014 at 2:45 PM, Daniel Miller <bonsaiviking () gmail com>
wrote:

> 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/