Re: [RFC] Ndiff

["Michael Pattrick" <mpattrick () rhinovirus org>]

Hey Thomas,

On Sun, Jun 15, 2008 at 11:14 PM, Thomas Buchanan
<TBuchanan () thecompassgrp net> wrote:
> 1.  What attribute (or set of attributes) will uniquely determine a
> specific host?  For directly connected hosts, it seems like MAC address
> is a pretty obvious choice.  For hosts one or more layer 3 hops away, IP
> address seems logical, but in certain situations this could lead to a
> lot of churn.  One example: a branch office on the Wide Area Network
> that you scan on a weekly basis, which consists primarily of DHCP
> connected workstations.  They get powered off over the weekend, or their
> leases expire, however they get new addresses, this leads to a lot of
> false positives for new, changed, or deleted hosts.  In situations like
> this, it might be helpful to be able to specify alternate attributes to
> track hosts by, for example, reverse DNS name.  If this is possible,
> then the tool would need a way to indicate that a host's address has
> changed, even though its ports and services may not have.
You've brought up a few good points here, MAC would work well but the
problem is that one scanned host  behind a router/firewall and you
can't maintain the consistency of the format, I think it would be
confusing  to have half the output in macs and half in IPs. A possible
feature would be to let the user select how they wanted to sort the
output; mac, ip, or dns. DNS may also pose a problem for networks
where the domain is dynamic and based on the ip
(10.9.8.7.workstations.company.com).

Also, I don't think that it will give all that many false positives,
most corporate workstations run the same images with the same firewall
policies, services, etc on all workstations. But I can see how this
could become annoying if you ran a mixed environment so half the hosts
changed from Windows services to Mac services.

> 2.  In your example for host 10.9.8.7, how does the XML indicate the
> previous state of a new port?  In the text output, it indicates port 53
> went from filtered to open, which is nice to know, but I don't see this
> information in the corresponding XML.
Yes, I should have explained that better, in the xml 'add' and 'del'
are associated with a transition too and from a host state that isn't
listed in the logs. Not scanned, Filtered, and Closed when there are
too many Closed ports. I did this for the reason that you pointed out,
based on some logs its not possible to know the exact state of a host,
so I just leave it blank. If it went from being listed as closed to
listed as open in the log I would use 'chgport' and 'chgstate'.

Cheers,
Michael

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