Re: ICMP Attacks???????

[Danny McPherson <danny () genuity net>]

[ Note:  To those that (strongly) dislike Cisco, admittedly or not, you don't 
have to read the non-intuitive examples included below, really ;-)]

>       It would be nice, but for now logging the hardware addresses along
> with the ip addresses would be cool.

After speaking with some Cisco folks, I've found that you can already do this on Ciscos .. as I believe someone 
mentioned here before.  I tried it on our MAE-East router (w/RSP2) and found that no significant amount of CPU was 
wasted logging the packets.  Given, I didn't leave the ACL applied to our NAP FDDI interface for any substantial amount 
of time, but there was really no need to, per all I wanted was enough data to verify the source router/network of the 
attack.

Consider the following:  Someone, somewhere, is using smurf.c (or any spoofing-type-program, for that matter) to launch 
a DoS attack on one of your customers.  All you know is that the attacker is "pinging" the broadcast address of a few 
of the public exchanges, with a source IP address of a customer's server(s). 

Finding the destination IP address isn't that difficult (at least for your customer ;-), it's the "real" source that's 
the problem.  You can build an ACL on your NAP router that logs all ICMP-type (or whatever) traffic bound to the IP 
address of the customer's server, as such (assuming you're customer's server ip address is 1.1.1.1):

access-list 199 permit icmp host 1.1.1.1 any log-input
access-list 199 permit ip any any

You then apply the access-list inbound to the NAP interface.  Then, assuming matches occur, you should receive 
something similar to:

Aug 15 20:04:45.087 MST: %SEC-6-IPACCESSLOGDP: list 199 permitted icmp 1.1.1.1 (Fddi6/0 0060.7017.a188) -> 
192.41.177.255 (0/0), 1 packet

The MAC address listed after the interface identifier is that of the router's interface on the ring from which you 
received the spoofed packet.  You can then match the MAC address to the IP address of the interface (via "sh arp", or 
other ways) .. and you've just identified the router/network from which the attack is being sourced.

Now comes the fun part, cooridinating with the Operations/Security folks from the corresponding network(s) to track the 
attack, hop-by-hop, through their network.  

If the attacker is using multiple public exchange subnets to source the echo replies, you may consider identifying the 
source router/network at another exchange as well, before pointing fingers.

Hope I haven't overlooked something obvious here .. but I'm sure that if a did someone will "enlighten" me ;-)  Of 
course, the one obvious thing I didn't mention is that if everyone were to deploy ingress filtering, this would be 
much, much easier to control.

-danny