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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Tony > Sent: Wednesday, October 25, 2006 2:36 PM > To: [email protected] > 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 > [email protected] > http://mail.nessus.org/mailman/listinfo/nessus _______________________________________________ Nessus mailing list [email protected] http://mail.nessus.org/mailman/listinfo/nessus
