If your scan system is powerful enough you could use multiple nics
each on a different vlan. That won't really solve the problem but it
will make an improvement. You could use a dual proc, dual core opteron
system for example with a nic bound to each core (four!) and run four
seperate nessus processes. I almost tried that on our similar sized
network last year.
Karl
On Fri, 2006-10-27 at 09:10 -0500, Doty, Timothy T. wrote:
All I have for our class b network is a single scan system so there is no
load balancing. A shame, but a reality (what I would like would be a scanner
per building, that isn't happening any time soon).
We do three scans: nmap sweeps to enumerate hosts, nessus sweeps hitting a
select list of plugins, and queued "full" scans (due to policies and for
legal reasons some plugins are disabled). The closest to your situation is
the last, though with only one scan system.
"full" scans can be queued manually, but they are also queued automatically:
if a system is seen on the network and has not been "full" scanned for x
days then a scan is queued. Queueing is done in an Oracle database.
As we (mostly) match subnets to buildings if I had additional scan boxes
they would be located in a building. When selecting targets they would
filter on subnet. As computers, especially laptops, have a tendency to roam
this determination would be made at scan time.
To deal with load issues I have two settings for the wrapper to determine
how many (if any) systems to start scanning. Basically, no run will have no
more than x hosts in a run (determination is made if the system is in fact
on the network before adding to the list) and there is a maximum of y hosts
that can be scanned at any time. Currently this is tracked in the database
using the queueing table. If I had multiple scanners I would need to add a
column to identify the scan box and some sort of locking mechanism to
prevent multiple scan boxes claiming a host (actually, if I had a scan box
per building that last would not be an issue).
The arrangement works well enough, though it has taken time to setup. It has
taken around 6 months to setup, but that includes the web front end,
reports, etc. (as well as the fact that this is only part of my job). As
noted I would prefer to have additional scan boxes, the problem is
convincing management of the return.
One other thing I'd note is the advantage of putting the scanner on the
subnet: you can get the hardware address that way (I have a hack job with
some light weight probes our networking group put in some subnets). This is
good for identifying systems and catching mac spoofing.
In short, if you have the time and expertise you can build a good solution
around nessus. If you don't but do have the money than looking at Tenables
other products may satisfy.
Tim Doty
-----Original Message-----
From: nessus-bounces@list.nessus.org [mailto:nessus-bounces@list.nessus.org]
On Behalf Of Tony
Sent: Wednesday, October 25, 2006 2:36 PM
To: nessus@list.nessus.org
Subject: one client, multiple scanners - nightly automatic scans
Looking into some options here and thought i'd send out to the list. Im new
to network auditing was told to get nessus working - it works, just looking
for a possible better option. Or some input on how my current multiple
simultaneous scans model works.
What im trying to do is automate nightly scans, gathering targets from a
database sending that output to a target file and have nesses be run on each
of the targets file.
Simple enough, except its ran one at a time (target1, target2, etc). What
im also trying to accomplish is that these scans be kicked off from a client
system deciding what scanner to use. Problem goes back to only being able
to start one scan at any given time. On a very large network, such as the
one im in charge of auditing this can be very time consuming - trying to
balance the load with one central point (or more depending on load) handling
all the post processing / reporting and letting the scanners do their own
thing.
what im currently doing, and I would hope there is a better option is the
following.
1. Gather targets from database send to a target file
2. Bash script that goes over each target file and kicks off a custom perl
script that determines the scanner to use, initiates the scan, and post
processes the results (generating alarms, updating a database, and a few
other items).
This model seems to work well but seems like a hack job to me, thought there
might be a better way to go about this instead of running 10 or so scans as
background process on the client machine (ex, foreach target - "nessus
nessus -q -x -T nbe scanner port username password target scan_out &").
My current model includes three scanners and one client system (linux
systems FC4). I will be expanding this to quite a few more scanners to
break out the load across the network.
Is anyone else doing anything similar? How did you go about it, other then
having each scanner system doing its own scans via cron jobs.
_______________________________________________
Nessus mailing list
Nessus@list.nessus.org
http://mail.nessus.org/mailman/listinfo/nessus
_______________________________________________
Nessus mailing list
Nessus@list.nessus.org
http://mail.nessus.org/mailman/listinfo/nessus
