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 2b30 : Thu Jun 12 2003 - 14:03:59 PDT