Re: inconsistent results from nmap v7.30 when scanning the same IP twice

[Tudor-Emil COMAN <tudor_emil.coman () cti pub ro>]

Hi,


I just pushed a fix to this (revision 36361).

I was using a std::set for the incompleteHosts and completedHosts variables defined in scan_engine.cc.

I choose std::set because I thought elements there should always have different IP addresses but I guess that wasn't 
the case for -sT.


Anyway I redefined them to be std::multiset which seems to have solved the problem. Also I don't think this change 
would affect performance too much if not at all.


Cheers,

Tudor

________________________________
From: Daniel Miller <bonsaiviking () gmail com>
Sent: Saturday, October 15, 2016 3:55:11 PM
To: Cedric MICHEL
Cc: Nmap-dev; Tudor-Emil COMAN
Subject: Re: inconsistent results from nmap v7.30 when scanning the same IP twice

C?dric,

Thank you for reporting this. I can confirm the same thing happens on Linux, so it's not windows-specific. I think this 
might have been caused by some changes made by Tudor-Emil Coman this summer during Google Summer of Code, so I've added 
him to the CC line.

The things that stand out to me about this are:

1. The second report does not report the latency for the target. This is most likely because the target is only scanned 
once, so the "second" instance of the target object does not get updated at all.
2. Watching the debug output, Nmap does not even attempt to make connections twice; it only scans the target IP once.
3. Using -sS or other raw scan type, Nmap separates the two targets into separate hostgroups. Using -sT, it does not 
(even in older versions that "work properly")
4. In older versions that "work properly," connections are made twice, i.e. Nmap is scanning the each "target" 
separately.

In looking for a solution, we may be able to avoid repeating the port-scan phase or version scan, since the IP address 
is identical. But NSE would have to be done separately, because the same IP could be scanned by different DNS names, 
which could affect results of HTTP scripts and others.

Thanks again for the report. We'll work on a solution and update this message thread.

Dan

On Fri, Oct 14, 2016 at 7:38 AM, Cedric MICHEL <dr.cedric.michel () gmail com<mailto:dr.cedric.michel () gmail com>> 
wrote:
Hi,
I found a strange behaviour on the latest version of nmap ()on Windows 7 when scanning the same IP twice.

Command :
$ nmap.exe -p 80,443,8080,8443 -Pn -sT www.google.com<http://www.google.com> www.google.com<http://www.google.com>

Starting Nmap 7.30 ( https://nmap.org ) at 2016-10-14 14:14 Paris, Madrid (heure d??t?)
Nmap scan report for www.google.com<http://www.google.com> (216.58.208.196)
Host is up (0.031s latency).
rDNS record for 216.58.208.196<http://216.58.208.196>: par10s21-in-f196.1e100.net<http://par10s21-in-f196.1e100.net>
PORT     STATE    SERVICE
80/tcp   open     http
443/tcp  open     https
8080/tcp filtered http-proxy
8443/tcp filtered https-alt

Nmap scan report for www.google.com<http://www.google.com> (216.58.208.196)
Host is up.
rDNS record for 216.58.208.196<http://216.58.208.196>: par10s21-in-f4.1e100.net<http://par10s21-in-f4.1e100.net>
PORT     STATE    SERVICE
80/tcp   filtered http
443/tcp  filtered https
8080/tcp filtered http-proxy
8443/tcp filtered https-alt

Nmap done: 2 IP addresses (2 hosts up) scanned in 3.88 seconds


I tried a previous version of Nmap (v7.10) and it behaves correctly :
$ nmap.exe -p 80,443,8080,8443 -Pn -sT www.google.com<http://www.google.com> www.google.com<http://www.google.com>

Starting Nmap 7.10 ( https://nmap.org ) at 2016-10-14 14:15 Paris, Madrid (heure d??t?)
Nmap scan report for www.google.com<http://www.google.com> (216.58.208.196)
Host is up (0.040s latency).
rDNS record for 216.58.208.196<http://216.58.208.196>: par10s21-in-f4.1e100.net<http://par10s21-in-f4.1e100.net>
PORT     STATE    SERVICE
80/tcp   open     http
443/tcp  open     https
8080/tcp filtered http-proxy
8443/tcp filtered https-alt

Nmap scan report for www.google.com<http://www.google.com> (216.58.208.196)
Host is up (0.038s latency).
rDNS record for 216.58.208.196<http://216.58.208.196>: par10s21-in-f4.1e100.net<http://par10s21-in-f4.1e100.net>
PORT     STATE    SERVICE
80/tcp   open     http
443/tcp  open     https
8080/tcp filtered http-proxy
8443/tcp filtered https-alt

Nmap done: 2 IP addresses (2 hosts up) scanned in 3.15 seconds

Could you please investigate on that problem ?

Best regards,
C?dric Michel.


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

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