From: Nancy Magers (Nancy_Magers@brown.edu)
Date: Fri Feb 13 2004 - 14:50:04 CST
Hi Brad,
I was the project manager here at Brown when we revamped our Netreg for
the start of this semester. JPB is our in house programmer he wrote the
Net::Nessus::ScanLite module now available on CPAN. We are doing scans
on systems with valid returns coming in ~2 seconds from the client
host,we are scanning for(18085,11835,12029) rpc and mydooom. We have
our nessusd servers setup on a pair of load balanced sun v100's, but the
load on them is insignificant with this scanning. I'm sure you could
get by with a single server, but we consider this a 7x24 service so we
want to engineer our systems for that.
Additionally we wrote a in house program that we call Reggie that uses
the same network scans to perform constant scans of the resnet flagging
hosts that are vulnerable to these exploits. Here is the write up I did
on the app for our help desk.
Hope this is helpful.
nm
A little history: Last semester we introduced netreg to the resnets, as
soon as this was implemented the Microsoft RPC/DCOM vulnerability came
out and we were asked to see if we could do anything to stop this from
within the netreg process. Thanks to some smart people over at UConn we
were able to implement a scan of the computer during the registration
process and redirect the vulnerable hosts to a page where they could fix
the host before continuing. This system was sufficient and helped us
stop what could have been a massive problem. There were some short
comings though - The UConn scanner was a piece of C Code that required
coding every time a new vulnerability was introduced, also because of
our network topology we were required to run the system scans on a
system behind the resnet firewall and this was thrown in without it
being a production ready system.
We replaced the C Code with a nessus scanner run on a load balanced
production class system. Thanks to JPB looking into the nessus code we
are able to do very fast targeted scans of any given host or subnet.
Additionally we wanted the ability to scan hosts that have already
registered, because there is the possibility of the host becoming
vulnerable after they have already registered and also to allow us to
quickly add new scans. So we came up with the Reggie process - last
semester this worked off of a feed coming from a scanner system that
identified vulnerable Mac addresses and we would then email them give
them 24 hours and deregister them. The first round of this worked but
there were a number of issues in the way we were doing things,
particularly we weren't doing a final check to insure the host was still
vulnerable before deregistering and we needed to modify our process to
include the nessus scans rather than the C Code. So JPB and Bob Morse
came up with Reggie V2.
Reggie runs a daemon process that is constantly scanning the resnet
networks for targeted nessus vulnerabilities. We currently scan for
nessus plugins 10181, 10185 and 12029 (RPC DCOM vulnerability and MyDoom
infection). It takes about 3 hours to run through all of the networks
in the resnet and then starts all over again scanning the subnets this
process is constantly running adding and clearing hosts from the
vulnerable list.
Mean while every 15 minutes a script is run that checks the database of
scanned machines it identifies the owner of the vulnerable host -
notifies the user of infection (emails them once) - and then if 24
hours has passed and they are still in the database it rescans them one
more time and deletes their host registration from myconnect.
There are two ways the host can get cleared out of the database
1. Through the scan daemon it self - if it scans a host as clean after
it has marked it as vulnerable it will remove the host from the
vulnerable database.
2. If after 24 hours the host is still vulnerable it is rescanned
before deletion the vulnerabilities are no longer present then the host
be removed from the vulnerable database.
If we have a new vulnerability and want to get a quicker scan of the
resnets we can do a "mass scan" This runs in approx 15 minutes, it is
extremely resource intensive so we wouldn't want to run this on a
regular basis , but it is good for the announcement of a new critical
vulnerability.
We can target particular operating systems with scans. This allows us to
look for different vulnerabilities, depending on the OS. We can also
customize the messages we give to users with vulnerable machines.
We have also included web templates so the infected hosts get the same
message from the myconnection registration process and from the targeted
emails. Hopefully this will make the cleaning the vulnerable host
process more straight forward.
Additionally we have a view into the database through our regular
provisioning database pages we can see who is added / notified / cleared
and purged on any given day.
Possible future enhancement:
Admin override screen to manually clear/override IP's
-----Original Message-----
From: owner-netreg@southwestern.edu
[mailto:owner-netreg@southwestern.edu] On Behalf Of Brad Pinkston
Sent: Friday, February 13, 2004 3:17 PM
To: netreg@southwestern.edu
Subject: NetReg: Nessus Scan Module
Has anyone implemented a Netreg/Nessus scan module where they are
satisfied with the speed? We have decided to revamp out netreg server
this summer after realizing problems that could resurface. I would like
to implement Nessus instead of rpcscan if someone could lead me in the
right direction of configuration on how best to speed it up. Thanks in
advance for your responses.
Brad Pinkston
Firewall/Network Administrator
Checkpoint CCSA
Centenary College of LA
(318) 869-5721
bpinksto@centenary.edu
_____
--------------------------------------------------------------------
This email has been scanned for viruses by Centenary College of LA
**********************************************************************
To unsubscribe from this list, send an e-mail message to
majordomo@southwestern.edu containing a single line with the words:
unsubscribe netreg
Send requests for assistance to: owner-netreg@southwestern.edu
**********************************************************************
This archive was generated by hypermail 2.1.4 : Thu Aug 12 2004 - 12:01:44 CDT