Re: Forward DNS names in output

[Fyodor <fyodor () insecure org>]

On Fri, Aug 28, 2009 at 01:54:37PM -0600, David Fifield wrote:
> On Thu, Aug 27, 2009 at 05:08:32PM -0500, Ron wrote:
> > On 08/27/2009 05:01 PM, Patrick Donnelly wrote:
>
> I think this is worth commenting on so I'm starting a new thread.
> Patrick is right that Nmap uses the reverse DNS name in its output.

Right.  The rDNS name can be useful in that it can expose ISPs, web
hosting providers, and more.  For example, if you scan
www.openbsd.org, Nmap forward resolves it to 129.128.5.191 and then
reverse-resolves that to openbsd.sunsite.ualberta.ca.  The latter
tells you that the site is hosted by a Sunsite server at the
University of Alberta in Canada.  This is useful information.

On the other hand, it can be confusing when you specify multiple
hostsnames on the command-line and you just get IP numbers back (or
rDNS names without an immediate relation to the hostname) and have
trouble figuring out which target is which.

> I have a personal TODO item to use the forward name in Zenmap, but I
> found that it is not even in the XML output.
>
> <host><status state="up" reason="conn-refused"/>
> <address addr="208.80.152.2" addrtype="ipv4" />
> <hostnames><hostname name="rr.pmtpa.wikimedia.org" type="PTR" /></hostnames>
> </host>

Yeah, adding the forward name here sounds reasonable.

> How should Nmap work in this regard? My quick proposal is
> to always prefer the forward name to the reverse name in normal output,
> and to use the reverse name when the forward name is not available.

I can support this (preferring the forward name as the main hostname
used by Nmap) as long as the rDNS name is still noted somewhere
prominently if they differ.  For example, look at this scan:

# nmap -v www.google.com
Starting Nmap 5.00 ( http://nmap.org ) at 2009-08-28 15:16 PDT
NSE: Loaded 0 scripts for scanning.
Warning: Hostname www.google.com resolves to 6 IPs. Using 74.125.127.103.
Initiating Ping Scan at 15:16
Scanning 74.125.127.103 [4 ports]
Completed Ping Scan at 15:16, 0.03s elapsed (1 total hosts)
[...]
Host pz-in-f103.google.com (74.125.127.103) is up (0.094s latency).
Interesting ports on pz-in-f103.google.com (74.125.127.103):
Not shown: 997 filtered ports
PORT    STATE  SERVICE
80/tcp  open   http
113/tcp closed auth
443/tcp open   https

Maybe that second section could be changed to:

Nmap scan report for www.google.com (74.125.127.103)
^^^ This is a new line, which I think is better than only listing the
    host/IP for "Interesting ports" table.  After all, we give a whole
    report now, often including NSE, traceroute, OS detection,
    etc. all below the interesting ports table.
Host is up, received echo-reply (0.094s latency).
^^^ This line still only appears in verbose mode.  I removed the
    name/IP since it is on the previous line.  I added the --reason
    information, as we now should have space to print it in all cases.
    In fact, maybe we should print this line in all cases?  I thinkd
    I'd favor that approach.
Hostname www.google.com resolves to 6 IPs. Only scanned 74.125.127.103
^^^ I'm suggesting moving this here to the target section so it is
    more closely associated with the particular target.  This means
    delaying the information a bit though, so we might still want to keep
    the earlier warning in -v mode (or maybe require -vv).
rDNS record for 74.125.127.103: pz-in-f103.google.com
^^^ This line is only printed if we get an rDNS record and it does not
    match the target name.
Not shown: 997 filtered ports
PORT    STATE  SERVICE
80/tcp  open   http
113/tcp closed auth
443/tcp open   https
^^^ These 5 lines are the same as before, though I removed the line
    "Interesting ports on ..." because we now already know the target
    name/IP, and the "PORT STATE SERVICE" line introduced the port table
    just as well IMHO.

What do folks think about this plan?  It is a moderately big change to
the look of Nmap output.  It will break Nmap -oN parsers, but maybe
that will give them the incentive they need to parse -oX instead.

Sorry for letting the thread wander again :).

Cheers,
Fyodor

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