Re: Vulnerability Scanning Problem

[Michael Hornung <hornung () CAC WASHINGTON EDU>]

Kim,

At the University of Washington I have a network scanning system based on
Nmap.  Of the many hurdles involved in regular port scanning, I too was
impacted by the growing number of hosts that block ICMP echo requests by
default.  In at least one sense that to be welcomed, but for the sake of
scanning it is then difficult to know if a given target (host) is up and
responsive.

I'm not sure how NeXpose works, but with Nmap if you don't ping a target
(in some way) before scanning it, there is a chance you may be spewing
packets to an IP address unused by any host!  Doing that significantly
decreases time-to-scan and can immensely negatively impact the time spent
probing the entire target address-space.  This time-consuming issue can be
addressed in several ways, for example lowering the number of
retransmissions, closely limiting probe timers, and limiting the maximum
time-to-scan a given target, but I found all of those alone to be
troublesome in fighting the problem of knowing which targets to scan.

My approach to this problem was to find a way to discover live hosts on
the network without having to talk to a given target host.  I assume that
if a host/target is on the network it will communicate on the network.
Given that communication and the nature of IP, its IP address will have an
ARP entry in the router serving the given subnet.

At regular short intervals my organization retrieves the ARP cache from
all routers in our network (via SNMP) for network monitoring and
management purposes.  What I do is regularly peek into the recovered ARP
cache and populate a list of targets known to be on the network---the
targets are tracked by MAC address, thus resolving the problem of
correlating results for known hosts (actually known network interfaces)
over time no matter which IP address they happen to be using.

Scans run for a period of time and I remember when a given device was last
scanned.  When the timer runs out I go back and populate another list of
devices most recently seen on the network.  I skip devices already scanned
within the target scanning frequency and proceed scanning new devices or
ones that need to be scanned again.

Using this approach I have negated the need to test a given host to see if
it's responsive.  I also have negated the need to send ICMP echo requests
(or Nmap's TCP ping) to IPs that are actually not in use, then waiting
some period of time before the attempt times out.  What I have traded for
is a slight risk that a device has left the network between the time the
ARP cache entry was populated and when the given scan begins.  In general
I have found this technique to save time and provide results I might
otherwise have missed when a firewalled host failed to respond to a ping.

_____________________________________________________
 Michael Hornung          Computing & Communications
 hornung () washington edu   University of Washington

On Mon, 11 Dec 2006 at 15:55, Logan, Kimberly (loganks) wrote:

|The University of Cincinnati is using Rapid7's NeXpose as our OS level
|vulnerability scanner.  Last week, we scanned 57 IP addresses and only
|got returns on 14.  We believe the reason is that Microsoft SP2
|installed the firewall with ICMP blocked.  We don't necessarily want to
|have it unblocked for all devices, but we need to be able to scan our
|devices on all subnets.  Has anyone experienced this problem and have
|you been able to find any workarounds without opening things up?
|
|Kim Logan
|Information Security Officer
|University of Cincinnati
|(513)556-9070
|kim.logan () uc edu