From: Clem Skorupka (ragnor@mitre.org)
Date: Thu Jun 12 2003 - 17:00:03 EDT
I should have added that this particular test was done in a lab setting ; ) . In general, your scanning methodology should take into account the vagaries of a network's critical infrastructure, and arrangements should be made to have appropriate personnel available to fix what might break. So don't go taking out all the switches at a remote site in the off hours.
Now a nice thing would be to have your network/ops group include "ability to survive reasonable vulnerability scans" as part of their system requirements, and/or incorporate such probes in acceptance testing for production rollouts. But in this vale of tears we take what we are sent ; )
Clem Skorupka
Renaud Deraison wrote:
> On Thu, Jun 12, 2003 at 11:55:26AM -0400, Clem Skorupka wrote:
>
> > I had a case where an rpc scan using nessus (I forget the particular module or if it was the nmap precursor scan, this was a couple of years ago) against some large range of ports knocked out an allegro-based embedded web server on a network switch. It didn't crash this particular switch (though one had to reboot the switch in order to bring back the web interface).
>
> The bottom line is that as soon as you start to interfere with another
> host, you can never predict how it will react to actions that it has
> never been designed to handle, so no scan is totally risk-free[1], and
> it's often very hard to find the balance between a 99.9% accurate
> security audit and a non-intrusive one. Note that this does not only
> affects Nessus+Nmap, but any network vulnerability scanner.
snip
---------------------------------------------------------------------------
----------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:53:34 EDT