[c-nsp] Slammer (1434) attack

Tim Stevenson tstevens at cisco.com
Thu Dec 23 10:29:28 EST 2004


See below:

At 04:53 AM 12/23/2004, Amol Sapkal exclaimed:
>On Wed, 22 Dec 2004 14:09:29 -0800, Tim Stevenson <tstevens at cisco.com> wrote:
> > Yes, you should NOT use ACL w/log keyword in this version, everything
> > matching the ACE(s) with "log" will be punted to the CPU.
> >
> > With this code, there are not as many options as w/later code (or later
> > supervisors), such as h/w rate limiting of traffic punted due to ACL 
> logging.
> >
> > But, do you have icmp unreachables or redirects enabled on your vlan
> > interfaces? ACL drops are all done in the h/w, but if you have unreachables
> > or redirects enabled on sup2, we leak a small # of packets to the CPU
> > (.5pps per vlan). (Assume this is straight IOS, not CatOS/IOS...)
> >
> > This means that the s/w netflow options others suggested will work for you
> > (ie, enabling ip route-cache flow on the vlan i/fs & either monitoring at a
> > NF collector, or on the box itself w/sh ip cache flow). If unreachables and
> > redirects are off though, nothing gets punted and you won't see any 
> stats here.
> >
>
>I am not sure of how ACLs are processed on normal routers, but I
>remember reading on a site that 'on a cat 65xxACLs are processed in
>hardware and so the length of ACLs do not affect the performance of
>the swith'.

That is correct, *if* your ACL fits in the hardware, and *if* you are not 
using some parameter, particularly the "log" keyword, that is not supported 
in the hardware.


>Now I am unsure whether access-list logging has anything to do with
>the load on the cpu.


Yes, it does. First from having to process (route or drop) the packet in 
the software, and additionally, from having to generate a syslog message.


>How is it going to affect the performance of the
>switch.

It is entirely dependent on how much traffic is hitting that "log" ACE in 
your ACL - if an ACE doesn't have log, then traffic hitting it is processed 
in h/w. If the ACE has log, then traffic hitting it is punted to the CPU. 
So if 1Mpps is hitting a log ACE, you are going to kill your CPU. Note I am 
talking about ACEs, not ACLs - only the individual lines of an ACL that 
have log are punted, not all the traffic.

Also, FYI, 12.2SX IOS on both sup2 & sup720 has a configurable hardware 
rate limiter for "ACL bridge" packets - so in 12.2 code you can go ahead & 
use the log keyword to your heart's content (with some caveats) as long as 
you configure the RL for some relatively low rate that protects the CPU.


>And interestingly, what happens in case of a router like a
>75xx, incase logging is enabled?

There is a CPU impact here as well. Certainly from generating the syslogs, 
and probably also in terms of a slower switching path, tho I am no 75xx expert.





> > Note that we do install NF entries in the h/w as well even for ACL denied
> > flows, but stats are not incremented & so no export occurs for them. But
> > you can do sh mls ip to see the flows. But this might be cumbersome to do,
> > since you'll see all flows, not just those punted to s/w as above, and cuz
> > the output is split over 2 lines so | filters aren't going to work as well
>
>
>Are you saying that irrespective of what is configured in the ACL, the
>packets arriving on an i/f will be showing up in the 'sh ip cache
>flow' (but with a NULL destn)?

I am saying that if we have a deny entry, and either unreachables or 
redirects are enabled (either one - there is only one bit in the h/w to 
control this), then traffic matching that entry is dropped in hardware, but 
a small amount is leaked to the software. Which means, the software is now 
seeing some traffic and can create s/w NF entries with NULL destination 
interface.

If unr/red are disabled, then everything is dropped in hardware & this is 
not possible cuz the s/w never sees any traffic.


Tim




> > ... Also, you'll only see the "relevant" info if you are running with a
> > full flow mask, mls flow ip full, so you can see the L4 info.
> >
> > Hope that helps,
> >
> > Tim
> >
> > At 11:47 AM 12/22/2004, Amol Sapkal exclaimed:
> > >Hey Tim,
> > >
> > >Apologies for not posting this directly to the list. I do not have
> > >direct access to the switches, very new to the current setup.
> > >
> > >Here are the details:
> > >
> > >
> > >MSFC2
> > >12.1(8b) E18
> > >SUP2
> > >
> > >
> > >
> > >On Wed, 22 Dec 2004 10:39:03 -0800, Tim Stevenson <tstevens at cisco.com> 
> wrote:
> > > > Please let us know what supervisor engine & s/w version you are 
> using on
> > > > the 6500s. That will greatly impact the recommendations.
> > > >
> > > > For example, ACL w/log is harmless on some sups - with the right
> > > > configuration -and disastrous on others.
> > > >
> > > > Tim
> > > >
> > > > At 09:00 AM 12/22/2004, cisco-nsp-request at puck.nether.net exclaimed:
> > > > >Message: 6
> > > > >Date: Wed, 22 Dec 2004 11:48:34 -0500
> > > > >From: Rodney Dunn <rodunn at cisco.com>
> > > > >Subject: Re: [c-nsp] Slammer (1434) attack
> > > > >To: Gert Doering <gert at greenie.muc.de>
> > > > >Cc: cisco-nsp <cisco-nsp at puck.nether.net>
> > > > >Message-ID: <20041222114834.C4647 at rtp-cse-489.cisco.com>
> > > > >Content-Type: text/plain; charset=us-ascii
> > > > >
> > > > >I haven't done it on the 65xx but I know for software
> > > > >the DST interface for an ACL drop is Null0 as Gert said.
> > > > >I would think the 65xx works the same way.
> > > > >
> > > > >I don't suggest people do the "log" route.
> > > > >Export the traffic and see if it shows up as
> > > > >Null0.
> > > > >
> > > > >That's the most scalable way to do it.
> > > >
> > > >
> > > > Tim Stevenson, tstevens at cisco.com
> > > > Routing & Switching CCIE #5561
> > > > Technical Marketing Engineer, Catalyst 6500
> > > > Cisco Systems, http://www.cisco.com
> > > > IP Phone: 408-526-6759
> > > > ********************************************************
> > > > The contents of this message may be *Cisco Confidential*
> > > > and are intended for the specified recipients only.
> > > > _______________________________________________
> > > > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > > archive at http://puck.nether.net/pipermail/cisco-nsp/
> > > >
> > >
> > >
> > >--
> > >Warm Regds,
> > >
> > >Amol Sapkal
> > >
> > >--------------------------------------------------------------------
> > >An eye for an eye makes the whole world blind
> > >- Mahatma Gandhi
> > >--------------------------------------------------------------------
> >
> > Tim Stevenson, tstevens at cisco.com
> > Routing & Switching CCIE #5561
> > Technical Marketing Engineer, Catalyst 6500
> > Cisco Systems, http://www.cisco.com
> > IP Phone: 408-526-6759
> > ********************************************************
> > The contents of this message may be *Cisco Confidential*
> > and are intended for the specified recipients only.
> >
>
>
>--
>Warm Regds,
>
>Amol Sapkal
>
>--------------------------------------------------------------------
>An eye for an eye makes the whole world blind
>- Mahatma Gandhi
>--------------------------------------------------------------------



Tim Stevenson, tstevens at cisco.com
Routing & Switching CCIE #5561
Technical Marketing Engineer, Catalyst 6500
Cisco Systems, http://www.cisco.com
IP Phone: 408-526-6759
********************************************************
The contents of this message may be *Cisco Confidential*
and are intended for the specified recipients only.


More information about the cisco-nsp mailing list