Re: Duplicate IPs in hostgroup (was: Feature request list all IP addresses of a host name)

[David Fifield <david () bamsoftware com>]

On Thu, Apr 29, 2010 at 12:03:33PM -0700, Fyodor wrote:
> On Thu, Apr 29, 2010 at 07:04:49PM +0100, Rob Nicholls wrote:
> > This actually gets more interesting (in my opinion) if I want to do the
> > opposite and scan a host with two (or more) FQDNs that always resolve to
> > the same IP (e.g. someone running a nameserver and mailserver on a single
> > host). If you enter both hostnames (for example mail.yyy.zzz and
> > ns.yyy.zzz) into Nmap, it'll provide two scan reports and appears to send
> > double the number of packets when scanning exactly the same IP (i.e. it's
> > being scanned twice!). This is essentially a huge waste of packets, and the
> > bad news is that based on some very brief testing I've done at home from a
> > Windows box I'm very concerned that it also results in inaccurate scan
> > reports! The majority of such scans result in the second host returning
> > everything filtered, even though the number of returned packets at the
> > bottom suggests that there were more responses than are displayed.
>
> Good catch.  I was able to reproduce this with scanme2.nmap.org and
> scanme3.nmap.org, which resolve to the same IP:
>
> # nmap -F scanme2.nmap.org scanme3.nmap.org
>
> Starting Nmap 5.30BETA1 ( http://nmap.org ) at 2010-04-29 11:46 PDT
> Nmap scan report for scanme2.nmap.org (64.13.134.48)
> Host is up (0.011s latency).
> rDNS record for 64.13.134.48: nmap.org
> Not shown: 98 filtered ports
> PORT    STATE  SERVICE
> 80/tcp  open   http
> 113/tcp closed auth
>
> Nmap scan report for scanme3.nmap.org (64.13.134.48)
> Host is up (0.012s latency).
> rDNS record for 64.13.134.48: nmap.org
> All 100 scanned ports on scanme3.nmap.org (64.13.134.48) are filtered
>
> Nmap done: 2 IP addresses (2 hosts up) scanned in 2.32 seconds
>
>
> Now we have some NSE scripts which depend on the host name given
> (especially some of the web scripts), so this is a legitimate use case
> which should work.  We should probably either force them into separate
> host groups (very easy to implement and maintain, but less efficient
> execution), or we could check for duplicates in the host group later
> and then skip host discovery, port scanning, OS detection, and version
> detection for the duplicates, but copy the information over to the
> duplicate target structures after those phases are completed, then
> include the duplicates for the NSE phase.  The latter solution will
> run more quickly because so much scanning is skipped and the host
> groups are not split, but it would be much more of a pain to implement
> and I'm not sure if it is worth it for an edge case like this.
>
> My initial thoguht is that we might want to do the host group split
> thing now to fix the bug, and then we can deal with a more complex
> optimization if we find that a lot of people want more speed when
> scanning many different hostnames for the same IP.  Given that it
> mostly doesn't even work now and we haven't been hearing about it
> until now, its probably not a super common need.

I fixed this a little while ago but forgot to announce it. Now hosts
with the same IP address are forced into separate host groups. Scanning
scanme2.nmap.org and scanme3.nmap.org will use two host groups. The
commit was r17934.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/