And a few operational notes....
We are working hard to get out the next RC for your scanning pleasure. In the meantime, please continue the use and bug reporting, it's been great thus far!
Now, as to a big bug and how to properly handle it. In previous versions of InProtect you were able to control the number of scans with the max_scans value in the Nessus Servers configuration dialogue. Unfortunately with the modification of the nessus_run.pl script to streamline the scanning process, the max_scans variable does not properly control the actual scans being processed by the scanner. A simple example is as follows;
Lets say you schedule a scan with 60 hosts (IP Addresses) to be scanned and have limited in the Nessus Scanner Max_Scans setting a maximum of 10 concurrent scans on said server. When this scheduled scan starts to run it will start out with 10 scans, once those begin to complete it will immediately say that it's running 20 scans then 30 and so on.
To remediate this issue, you need to do a couple of things...first lets go ahead and kill our sched.pl process so that we can clean up the database (if you still show multiple scans running and none are actually running "
ps -auxxx | grep nessus"). Once this is complete, go ahead and look in your Inprotect database under the nessus_scan table for any record with a value of 'R' in the status field (
select * from nessus_scan where status='R';". If you find that you do have records with 'R' as their status, you need to set them as 'C'
"UPDATE`inprotect`.`nessus_scan` SET `status` = 'C' WHERE `status` = 'R' ; ", you will also need to reset the current_scans value in the nessus_servers table "
UPDATE `inprotect`.`nessus_servers` SET `current_scans` = '0';". After completing these steps you can now start your sched.pl up again. As another note, you may want to set all of the status values to 'C' just to clean up that table, once you restart sched.pl it will clean out all of the 'C' status scans and set their main schedule back to a scheduled status.
Now that we have cleaned up the remnants of the aforementioned bug, lets go ahead and talk about the current workaround. This workaround is fairly straightforward and consists of two simple modifications to your scan profile and your nessus server settings. First, let's get into the InProtect GUI and select Settings -> Nessus Servers -> Edit, at this point we will be modifying the value for
Max number of hosts to scan and setting it to an extremely high number such as 10000 or more.
The next part of this workaround is to define the maximum hosts that will be scanned in the actual scan profile. This will tell the nessusd server itself how many scans that it is allowed to run at the same time. Select Settings -> Nessus Scan Profiles -> Edit your existing default profile -> Preferences, under the serverprefs section are the options max_checks and max_hosts. The max_checks value defines the number of test to be run concurrently against a single hosts and the max_hosts defines the maximum concurrent number of hosts that the nessusd server will scan. As you can see by the below image, I have set my default values to 4 checks and 10 hosts.
Regards,
JJC
