Eric made several very good points about Nessus under VMWare, and I'd
like to add a bit more information about what Tenable has seen from
users running Nessus under VMWare.
The most common "worse case" we've seen is a Windows user, running
Nessus under a VM, which is short on memory, with a NATed interface,
with a local firewall on the Windows side. There are lots of
opportunities for resources to not be available for the Nessus scan and
the scan to be inaccurate because of some filtering, a dropped packet or
so on. We run into this situation often enough that you get the message
about abysmal performance with Nessus under a VM.
Today, with more organizations deploying ESX and resourcing their
machines adequately, there still is a performance hit, but it isn't
nearly as bad as what I previously described. We're definitely
considering detecting ESX (as compared to an OS hosted VM) and either
not displaying the performance warning, or displaying one less alarming.
For organizations that do have multiple Nessus scanners under VM and
also stand-alone, try the following tests:
- Between scanning with native scanners and VM scanners, are there
different counts of open ports or even number of identified hosts?
- Are the actual scan times that different? (Consider the total scan
time as well as the average scan times for each host which you can get
from plugin 19506)
If the differences are acceptable, moving to a virtual environment for
your scanners may be an option.
My last point on Nessus and VMs though is that I've seen many
organizations load up more and more applications on the VM servers, be
they ESX or a nice system just running VMs. As with any type of VM
environment, the more other applications you end up putting on the same
physical host, the more chances you have at running out of physical
system resources to your VMs.
Ron Gula, CTO
Tenable Network Security
_______________________________________________
Nessus mailing list
Nessus@list.nessus.org
http://mail.nessus.org/mailman/listinfo/nessus
