Hints for tracing SYN flooders (and others) through Ciscos

(Sorry I dropped off the face of the earth. Been busy, dontcha know :frowning: )

Jeff Rizzo writes:

Apologies to those to whom what I present here is blindingly obvious; I'm
killing some time while waiting for a response from an ISP that we've traced
an attack on one of our customers to, and I thought I'd share a tip:

Since virtually everyone who has a Cisco has at least fast switching, if not
cbus switching, enabled, the "debug ip packet [access-list] detail" suggested
here the other day won't show much, as the processor (which is doing the
debugging) won't actually see the whole packet. You can sit there for quite
some time without results. :slight_smile: Obviously it makes no sense from a performance
perspective (at least if you have even moderate traffic) to turn off fast
switching, you *can* clear the ip cache for the attacked network. This forces
the processor to look at a number of packets to rebuild a cache entry.
Now, if you're especially lucky, your debug may catch the packets you're
looking for right off, and tell you the ingress interface. More likely,
however, is you'll need to clear the cache entry a number of times to get a

There's a much better way to do this. Simply add a line to the active filter
  permit tcp any host website.customer.com eq 80

Now you'll see matches in the access list, and more importantly, you'll
see all the packets in show ip packet. Be warned, you can get a *LOT* of
data very quickly this way. be sure you type "undeb all" as soon as you
hit return after you've typed the "debug ip" line. You'll still get screens
full of data, if you're being attacked.

You're still on your own when you get to a shared IXP fabric, and you'll need
a sniffer there, but it can help.

(Hey Cisco! Any chance of putting a source MAC address in the "detail"
information? :slight_smile:

Now that would indeed be useful. I wonder if that info is actually available
to their code at that point. I suspect it may be lost by then.