IDS mailing list archives

Re: Router/Switches and viruses


From: Kevin <kkadow () gmail com>
Date: Thu, 5 May 2005 13:29:38 -0500

On 5/3/05, Seek Knowledge <aseeker03 () yahoo com> wrote:
Does anyone have any first-hand experience with a
single infected desktop machine (or windows server for
that matter) taking out a LAN switch?

I've encountered Cisco routing engines start to lose traffic with just
a few (3-8) infected machines all emitting the "Nachi" ICMP packets. 
Never just one host.

Generally the issue was on a router handling layer-2 connectivity to
many VLANs, or a few very large (and sparsely populated) VLANs.  For
example, if you have an office that is using 10/8 as their local
network (not kidding!), when a (remote) host starts to scan into the
10.* address space, the router serving the 10/8 VLAN will attempt to
resolve and cache ARP information for every 10.* address targeted by
the worm host(s).

With 92-byte ICMP packets emitted Nachi, just a handful of hosts can
generate some really amazing packet rates.  It's an open secret that
routers tend
to fall over not from throughput (bytes per second) but from frame
rate (packets per second).


Would anyone have any stories from the trenches of
an infected machine causing a directly connected router
to stop functioning?

See http://www.bgpexpert.com/archive2003q3.php for one explanation of
how high-rate ping sweeping worms can cause CPU and memory exhaustion
on routers which support a large range of directly attached networks.

My employer deploys just about every modern router product Cisco is
willing to sell a support contract for, and when Nachi hit, no model
was exempt from failure.    With the exception of "core" and "egress"
routers that saw
aggregate traffic from many sources, routers that did pure layer-3
routing tended to survive with few issues (CEF cache exhaustion); the
routers that rebooted or hung were almost exclusively serving layer-2
access for large chunks of IP space


If so, what could be done to prevent such an outage?
What IDS/IPS strategy might one implement to prevent
and or at least detect such an event?

The easy band-aid is the rate-limit access ports.  There is seldom any
reason for any one "host" to emit very small packets at very high
rates.

There are commercial products which are meant to detect hosts
exhibiting pathological behavior and isolate them from the production
network, or just not let them in in the first place.  Regarding the
latter, can anybody report experiences with Cisco Clean Access and or
"Cisco Clean Access Out-of-Band" ?


Kevin Kadow

--------------------------------------------------------------------------
Test Your IDS

Is your IDS deployed correctly?
Find out quickly and easily by testing it with real-world attacks from
CORE IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708
to learn more.
--------------------------------------------------------------------------


Current thread: