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

[Kris Katterjohn <katterjohn () gmail com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 29 Apr 2010 12:34:12 +0200
"Luis MartinGarcia." <luis.mgarc () gmail com> 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.

Just what I was going to say.  Adding an option as you suggest sounds
fine, but I do *not* want Nmap to default to that.

I suppose if the option is created, the line mentioned which tells how
many IPs are retrieved could be followed by a sleep() like what
happens when you use Idle Scan with some ping type.  Note that I don't
really prefer this, it's just a thought since it also lets someone
quickly change their mind before the scan starts to redo their options.

> Luis MartinGarcia.

Cheers,
Kris Katterjohn

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBAgAGBQJL2Xv6AAoJEEQxgFs5kUfuXZgP+gKH6KxW2S42HLGVWForqIIu
oK1nUlxjPkyO7SfDwuhBIXhDO1C36KnYqeO76MqJmJElI7I5M4QbvLz5uHgUtL/F
Zt9rs9Jw0etpM+4twrBfJEFUBGhG+SV7+b/Jku7UT8LBzyFGDt/ZOEE4DEYpYAUx
wpI6w/cTOVW99+9+Uipo26MO7N3qCYFL8D3WDDj242NDZ+df2PzUz36KYLIm+HX2
/Kfy9yJbZ5X99S7tly1pKP0F3wOFUY3ZJi805ZrE6gqJzG1j/jZS0OxGg2SNOROj
y2FMld+TbQn4FXZSVNxrojNkQhFncxB+F3WK22aK8Gh7GzPlCZor2VgN+Bs2XE3K
+4+gapRVpw0PVGagE6Xk3NLPDLrEI4EBDHjMACS7qfwVngC+DOYudcF+VYbeqPq0
FJnzH4H5dGHi9h+rfoiW6nCedMYQXL/tKtMIvJlyRZ3iM9l97X9wscwzF6nOQVwE
YAPEvfa0o0Iu5kHLvatnzL2ztdsUTAQuqqKQpq8A3Wn/LoaQ0tt2U63PtaTp3j7o
xrqa1loWGKPCpfkT+LK/82QjRLOAcA8TrDNNZRjlQVHp8HRtX3107TrqXsDhduad
I1QrM9vX58gCWyNFPDNpICrCmb/R+149CGd0p7Me/h6sLjK1trdZDMXm+vlWV5mR
kGWVJHI8BQqfYDu9uqQ3
=1Zec
-----END PGP SIGNATURE-----
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/