(Sorry I dropped off the face of the earth. Been busy, dontcha know :-( ) 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. :) 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 hit.

There's a much better way to do this. Simply add a line to the active filter on the port you know they're going to (ie, the one that connects your customer), whichs explicitly *permits* the attacking packets. For example, if my customer's website is under attack, add a line (before a "deny ip any any" if you have it) that says 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? :)

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. /a --- Alexis Rosen Owner/Sysadmin, PANIX Public Access Unix & Internet, NYC. alexis@panix.com