[unisog] Automated vulnerability tests upon host to network a ttachment

Radomski, Mike Mike.Radomski at itec.mail.suny.edu
Thu May 15 18:17:58 GMT 2003


I read a great article on the idea of scanning a pc with Nessus when they
are active on the VPN.  The article was published in the March 2003 Sys
Admin magazine.  The name of the article was "Proactively Protecting VPN
with Nessus"  It is a good read.

Mike Radomski 

SUNY - ITEC
Information Technology Exchange Center
Systems Programmer/Analyst 
E-mail: Mike.Radomski at itec.mail.suny.edu 
Systems E-Mail: scsys at itec.mail.suny.edu         
Phone: (716)878-4832
Cellular: (716)807-4040
Fax: (716)878-4235

 

-----Original Message-----
From: John Kristoff [mailto:jtk at depaul.edu] 
Sent: Wednesday, May 14, 2003 6:44 PM
To: unisog at sans.org
Subject: [unisog] Automated vulnerability tests upon host to network
attachment

Is anyone doing or aware of someone doing automated vulnerabiity tests
on hosts as they attach to the network.  So for example, as soon as a
host comes online and causes an ARP entry to be created in the first hop
router, a monitor process which watches the ARP table kicks of a job to
automatically scan the newly connected host for something like the top
10 SANS vulnerabilities, generating the necessary report/alert to an
admin?

There are some potential issues regarding faked ARP/IP entries, but some
clever coding and in-network protections (e.g. port security) could help
throttle or detect those sorts of problems so that an admin isn't
swamped.  There could also be some "not seen in X period of time" checks
that could be tweaked to suit the environment.

This is somewhat admittedly a strong-armed approach to identifying and
securing hosts, but my first thought is that it seems that the best time
with which to get admins to take down their host and fix it is before
its been online for too long.  Many people do periodic vulnerability
scans and those should continue, but if there are a lot of new hosts
that pop up on your network this could help reduce those new hosts'
first MTTC (mean time to compromise :-) who very often have bad
defaults.

Thoughts, pointers, experience to share?

John


More information about the unisog mailing list