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 --------------------------------------------------------------------------- ----------------------------------------------------------------------------
