incremental port scanning

[Graham Toal <gtoal () UTPA EDU>]

Christopher E. Cramer wrote:

> Joe's got a great list of things below.  To that, I would add:
>
> * periodic (monthly?) scans for open mail relays on port 25.  We've done
> this for years and recently opted to scale back because we haven't found
> any in the past 12 months or so.
changing the subject (which I just did above as it happens :-) ), it
makes more
sense to scan your entire campus monthly *on all ports* than to look for
specific ports like this.

However we've found that with the advent of personal firewalls and other
obstacles
(such as some obscure issues we're having with VLANs), our campus scans
(we have a class B network) now take over a week to complete instead of
being possible during working hours which was true a couple of years
ago.  Single
machines can take as long as 6 minutes to scan with nmap, even with the
various
timeout parameters tweaked to be as short as practicable.  Obviously
this means
seegments of the net are scanned at night when desktop systems are likely to
be powered down.

Recently I've been working on a new model to gather the same information
incrementally rather than by brute-force scanning.  (This code is partially
complete; don't ask for it yet, but I will release it here when finished)

I use snmpwalk to enumerate our five Cisco routers, and then feed the
resulting
table of MAC vs IP into a program called "arpsnmp" which keeps a database
of active systems and when they came online.  As a system appears for the
first time, it is scanned with NMAP and logged in a file (using the MAC
as the
filename, because DHCP IPs tend to change more frequently than MACs do).
Entries are aged out after a month so that we get the same frequency of
results as a full scan would give us (once finished and debugged we may
decide to age them out faster if the load is not too high).  Newly
discovered
(and re-scanned) entries are compared to previous or baseline entries to
detect new ports appearing.  (This has to be done carefully as nmap sees
temporary ports open on windows systems which really have no significance
and change every few minutes :-(  )

I did originally use "arpwatch" which used actual ARP broadcasts as its
data source, but we have several routers internally on campus and only
machines in my own segment were giving their real MAC:IP pairs (obviously)
so that just wasn't feasible.

I plan to enhance this later so that MAC:IP info can come from any
source, not just the snmpwalk data - for example a sniffer on the
campus edge.  However I'm reasonably sure that you cannot have
a machine on the net that does not tell its router what its MAC address
is, no matter how tightly firewalled (otherwise it couldn't talk at all,
right?)
so as long as you can see *every* router on campus, the snmpwalk
should be sufficient.

Graham