Re: Feature request list all IP addresses of a host name

[Djalal Harouni <tixxdz () gmail com>]

On 2010-04-29 12:34:12 +0200, Luis MartinGarcia. wrote:
> On 04/29/2010 08:23 AM, Fyodor wrote:
> > On Wed, Apr 28, 2010 at 07:19:34PM -0600, David Fifield wrote:
> >   
> > > On Wed, Apr 28, 2010 at 09:11:21PM -0400, Derek wrote:
> > >
> > > We do keep track of all the IP addresses, in the Target::resolved_addrs
> > > member. But I don't think they're printed out anywhere. Please give us
> > > an example of what you want the output to look like.
> > >     
> > It is certainly an interesting issue.  When I scan Google.com, I get
> > (in verbose mode or not) a line like:
> >
> > Hostname google.com resolves to 4 IPs. Only scanned 74.125.19.147
> >
> > Of course the IP address shifts among the four each time, and someone
> > elsewhere might get a completely different set if it is geo based DNS.
> > I agree that printing all four IPs is desirable, but I wonder if we
> > should go even further.  Maybe instead of picking one of the IPs
> > arbitrarily to scan, we should scan ALL the IPs (and print a line
> > noting what we are doing)?  When I specify a host name without a
> > subnet mask, that is usually what I want.
> >
> > It is true that most clients (web browsers, ftp, etc.) do just what
> > Nmap does: pluck one A record from the list.  But a scanner is a very
> > different beast.  I normally want to look at scan results for each IP
> > and compare for differences.  Maybe one of the boxes isn't quite as
> > patched as the others.
> >
> > I suppose there is a risk that a hostname could have some obscene
> > number of A records.  I don't know how many can be returned from a
> > query, but I don't see this as a big issue. People can always specify
> > IP addresses if they don't want to match multiple A records.  Or we
> > could even provide an option to select Nmap's current
> > first-IP-in-the-list behavior.
> >
> > Subnet masks are another issue.  What should we do if someone
> > specifies google.com/24?  Well, right now I get these IPs for
> > google.com:
> >
> >   
> > > host google.com
> > >     
> > google.com has address 74.125.19.99
> > google.com has address 74.125.19.103
> > google.com has address 74.125.19.104
> > google.com has address 74.125.19.147
> >
> > So they are in the same /24 anyway.  So I think an ideal system would
> > scan 74.125.19.0/24.  But what if you specified google.com/28?  Then
> > #2 and #3 overlap #1, so we would just end up with 74.125.19.96/28 and
> > 74.125.19.144/28.  A potential downside is that it means the user (and
> > Nmap) can't predict how many IPs will be scanned total until DNS is
> > completed.  But users can avoid that risk by using IPs or checking
> > with -sL before they scan or using a special single-ip-per-hostname
> > option if we provide one.  And Nmap generally doesn't know how many
> > IPs it has left anyway (though it could know in most cases now if the
> > code was there, and that might provide nice "when will the whole scan
> > be completed" estimates).
> >
> > I haven't even thought about possible implementation issues yet.  I'm
> > trying to figure out what behavior is ideal from a user's standpoint
> > first.  Does anyone have opinions on what "nmap google.com" should do?
> >
> >   
>
> Well, in my opinion nmap should NOT change its default behavior. It is
> true that scanning all IPs returned by DNS may be interesting in some
> cases but certainly not it all cases. There are a lot of systems out
> there that have multiple network interfaces with different IP addresses
> assigned. Scanning all the addresses will probably produce the exact
> same results (after all, it's the same host, just a different
> interface). It is also true, that there may be some weird policies
> configured in the system (like interface-based drops or accepts) and in
> that case, scanning all IPs may produce interesting information. So the
> thing is, how often a DNS query for a hostname returns different IPs
> that actually represent different physical hosts and how often those IPs
> belong to just one host?
well, I have seen some systems with multiple network interfaces but they
use "interface-based drops or accepts": firewall rules, binding a service to a specific IP etc, which let you think 
that: perhaps this is not the same host?
If this is implemented, then having an option to compare results will be
cool, like ndiff ?

> I think the least surprising behavior for users is nmap's current
> behavior (let the user know that DNS returned more than one IP, but go
> for just one of them). If users want to scan all IPs associated with a
> single hostname, they should do it specifying a special flag like 
> "--scan-all; --scan-all-records; --full-dns" or something like that.
>
> Changing nmap's default behavior all of a sudden may be a bit
> problematic (I guess many sysadmins will get worried when their scan
> diffs show up "new hosts" out of the blue), and I don't think the
> improvement is significant enough to do it.
Yes, I agree that changing Nmap's default behavior may cause some
trouble to sysadmins etc.

> Just my two cents.
>
>
> Luis MartinGarcia.
>
>
>
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/

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