|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: ICMP Attacks???????
Danny McPherson wrote: > > [ 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 Not to trivialize the problem (cause its not trivial) but in a former life I helped develop MAC to IP and IP to MAC lookup software for a competitors product. It was written using all standard MIB information and could be written for just about and box with if and bridge tables. The real trick is getting everyone at the IXP or NAP to run this on their equipment. Having a distributed version would be nice but I don't think ops would buy it. Just something to think about. -pete
|