Hi there,
I'm glad you point the blame mostly on the equipment vendors. We try really hard to make Nessus as low-impact as possible, but when sending SYN packets to management ports crashes a device, there is not much we can do about it. I feel this is symptomatic of all network scanners, and not just Nessus. Tenable does get contacted by many equipment manufacturers who have scanning outages and we make tweaks to the NASL checks to avoid these crashes.
I do want to point out one thing though. This issue of causing network impact during a scan was one of the main reasons we developed NeVO. With NeVO you sniff and get data that is very comparable to that obtained with a Nessus scan. When you consider that you may not be scanning all 65,000 ports 24x7 or looking for client vulnerabilities with an active scan, it could be argued that passive scanning may be more accurate. But what we felt the most when writing NeVO was the political damage that the security team can suffer when they accidently took out the DNS server, database, firewall, .etc. With NeVO, you can find new hosts, applications and networks as fast as IT can deploy them without any impact.
Please do not send NeVO questions/comments to this list and I apologize for the subtle vendor pitch. However, everyone should realize that while Tenable writes the NASL checks for Nessus, we also look at which checks can be accomplished passively with NeVO or through UNIX/NT patch audits. Although the white paper is "Tenable-centric", the readers of the list may want to take a look at:
http://www.tenablesecurity.com/images/pdfs/blended_security_checks.pdf
This details the pros and cons of active, passive and host vulnerability assessments.
Ron Gula, CTO Tenable Network Security
At 09:20 AM 3/16/2005, Luke Youngblood wrote:
James,
Excellent post. I too have been troubled by the ability of Nessus to completely bork otherwise reliable network devices. Indeed it does illustrate the lack of quality control that many network equipment vendors have. A recent experience I have had is that a Nessus scan of our DR network took down an entire DS3 Mux. Luckily this was our DR network and no traffic was currently routed through it, but the effects of over 500 simultaneous voice circuits going dead as the Mux suffered from a buffer overflow and rebooted itself would have been devastating in our production environment. Well, now I know not to scan that device any more... :-)
One of the real issues I face is a loss of credibility with other departments in the company that I'm responsible for scanning. All it takes is one small outage caused by a Nessus scan and now I'm responsible and the other department is understandably paranoid about being scanned again. "What will it break this time?" is something I've heard before. Since I'm the one individual in my company that is tasked with running scans, this is definitely a hot-button issue.
If you would like to volunteer to run some type of web-based database of network equipment that may be vulnerable to Nessus scans, I would applaud this effort. I would also be happy to contribute to it, and I think it would benefit a lot of us, especially the consultants on this list that use Nessus to scan many different organizations.
Regards,
Luke
_______________________________________________ Nessus mailing list [email protected] http://mail.nessus.org/mailman/listinfo/nessus
