ICMP Attacks???????

[Danny_McPherson1]

[ 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

[Peter_E_Giza]

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

[Michael_Dillon3]

Thank you Danny! This is exactly the sort of thing I was getting at. You've
basically laid out the algorithm for tracing an attack to a specific port
on your router. Now what we need to do is build a tool that can automate
this procedure, perhaps by using an "expect" script or something similar
like Python with PIPE.

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.

I suspect that this part would be a lot easier if some easy to use tools
exist. Ever since I heard that IOPS was being formed I've been curious
whether or not that would become a venue for building these kind of tools.
Perhaps if someone from IOPS would come to Phoenix and tell us what they
are up to, we might find some more ways to encourage this kind of
inter-network cooperation.