[ 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
danny@genuity.net said:
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
I'm pretty sure this is a new feature. Wow. Useful. That's exactly what I wanted. Given you are doing this I take it it's in 11.1.11CA1.
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.
The other nice solution would be an inverse traceroute that went back to each router in turn, passing it a bit of BPF saying "where are you getting packets like this from please?". If such a protocol existed, this would allow trace back to source (or at least trace back to the point where the protocol wasn't supported) which would automate most of the tracking and reduce the need to persuade NOCs to cooperate. There are obviously security concerns in allowing 3rd parties to remotely apply packet tracking in your network, but I'm sure with a cold flannel applied to forehead these could be worked through. RFC time anyone? Alex Bligh Xara Networks
On Sat, 16 Aug 1997, Alex.Bligh wrote:
The other nice solution would be an inverse traceroute that went back to each router in turn, passing it a bit of BPF saying "where are you getting packets like this from please?". If such a protocol existed, this would allow trace back to source (or at least trace
I think UUNet has a tool similar to this that they use internally. ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/message. Florida Digital Turnpike | ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____
"Alex.Bligh" writes:
danny@genuity.net said:
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
I'm pretty sure this is a new feature. Wow. Useful. That's exactly what I wanted. Given you are doing this I take it it's in 11.1.11CA1.
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.
The other nice solution would be an inverse traceroute that went back to each router in turn, passing it a bit of BPF saying "where are you getting packets like this from please?". If such a protocol existed, this would allow trace back to source (or at least trace back to the point where the protocol wasn't supported) which would automate most of the tracking and reduce the need to persuade NOCs to cooperate. There are obviously security concerns in allowing 3rd parties to remotely apply packet tracking in your network, but I'm sure with a cold flannel applied to forehead these could be worked through. RFC time anyone?
Alex Bligh Xara Networks
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
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. ******************************************************** Michael Dillon voice: +1-650-482-2840 Senior Systems Architect fax: +1-650-482-2844 PRIORI NETWORKS, INC. http://www.priori.net "The People You Know. The People You Trust." ********************************************************
participants (6)
-
Alex.Bligh -
Danny McPherson -
David Ross -
Jon Lewis -
Michael Dillon -
Peter E. Giza