Re: uRPF-based Blackhole Routing System Overview
Catching up on the thread.. vendor C also calls it IP Source-guard on the Cat 4K in IOS. And it acually works quite well (does require DHCP snooping). T - Original Message - From: Scott McGrath [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 12, 2003 5:17 PM Subject: Re: uRPF-based Blackhole Routing System Overview Vendor C calls it DHCP snooping and to the best of my knowledge it is only available under IOS not CatOS Scott C. McGrath On Fri, 7 Nov 2003, Greg Maxwell wrote: On Fri, 7 Nov 2003, Robert A. Hayden wrote: [snip] One final note. This system is pretty useless for modem pools, VPN concentrators, and many DHCP implementations. The dynamic IP nature of these setups means you will just kill legitimate traffic next time someone gets the IP. You can attempt to correlate your detection with the time they were handed out, of course, in the hopes you find them. Another approach to address this type of problem is the source spoofing preventing dynamic-acls support that some vendors have been adding to their products. I don't know if it's in anyone's production code-trains yet. The basic idea is that your switch snoops DHCP traffic to the port and generates an ACL based on the address assigned to the client. Removing a host is as simple as configuring your DHCP server to ignore it's requests and perhaps sending a crafty packet (custom written DECLINE) to burp the existing ACL out of the switch. Vendor F calls this feature Source IP Port Security, I'm not sure what vendor C calls it. Since this is a layer 2 feature you can configure it far out on the edge and not just at the router.
Re: uRPF-based Blackhole Routing System Overview
Vendor C calls it DHCP snooping and to the best of my knowledge it is only available under IOS not CatOS Scott C. McGrath On Fri, 7 Nov 2003, Greg Maxwell wrote: On Fri, 7 Nov 2003, Robert A. Hayden wrote: [snip] One final note. This system is pretty useless for modem pools, VPN concentrators, and many DHCP implementations. The dynamic IP nature of these setups means you will just kill legitimate traffic next time someone gets the IP. You can attempt to correlate your detection with the time they were handed out, of course, in the hopes you find them. Another approach to address this type of problem is the source spoofing preventing dynamic-acls support that some vendors have been adding to their products. I don't know if it's in anyone's production code-trains yet. The basic idea is that your switch snoops DHCP traffic to the port and generates an ACL based on the address assigned to the client. Removing a host is as simple as configuring your DHCP server to ignore it's requests and perhaps sending a crafty packet (custom written DECLINE) to burp the existing ACL out of the switch. Vendor F calls this feature Source IP Port Security, I'm not sure what vendor C calls it. Since this is a layer 2 feature you can configure it far out on the edge and not just at the router.
uRPF-based Blackhole Routing System Overview
I posted earlier mentioning that I was using uRPF to facilitate a blackhole routing system on our campus. I went off to lunch and came back to 38 private emails from people asking how I'm doing it. Rather than respond individually, I figured I'd post an informal synopsis here. First, I'm a network engineer at the University of Wisconsin Madison (I read NANOG from my personal email account). We have a large ethernet-based network that runs primarily on Cisco 6500s for core routing and switching, and 3550/3750 switches for edge aggregation. 802.1q is used for layer 2 networking, with each department network getting a unique .1q VLAN ID. uRPF was designed primarily to block spoofed IPs. However, you can trick it into blocking non-spoofed IPs by making the routing table think the IP address should legitimately be located somewhere else. So, the first step is to turn on strict uRPF checking on to the interface. We use the following as an example interface setup on an MSFC2 running 12.1.(19)E1: interface Vlan645 description Department of Nuclear Basketweaving LAN ip address 192.168.1.0 255.255.255.0 secondary ip address 10.0.0.1 255.255.255.0 ip verify unicast source reachable-via rx allow-self-ping ... end Second, we set up a small router and make sure it speaks OSPF with the rest of our backbone mesh. Any size router will do since it doesn't need to handle a lot of traffic. Heck, grab an old 2501 out of your suplus closet. Make sure that this router is set up to redistribute static routes. We use a 3550-12 switch because we forward certain traffic into a server for analysis so we wanted something with a little horsepower to handle it. In most cases, anything small will work. Now, let's pretend that the IP address of 192.168.1.100 is Nachi compromised and we want to blackhole it. That is, we want to make sure that it neither receives nor sends traffic beyond its router interface. On the blackhole router I can enter: ip route 192.168.1.100 255.255.255.255 null 0 OSPF will inject this /32 route into the backbone mesh. Back on the actual interface, uRPF will see in the routing table that the route belongs somewhere else and conclude that it must spoofed and dump it. In addition, traffic destined TO that IP address will follow the most-specific route and end up in the BH router. As soon as the nachi virus is removed, I do: no ip route 192.168.1.100 255.255.255.255 null 0 on the blackhole router and in a few seconds traffic to and from that IP flows properly because the /32 is no longer seen by the router interface. Note that if you don't use uRPF on that interface, or if you use loose-source uRPF, than this system won't work for outgoing traffic, only for packets destined TO the BHed IP address. Now, we also have a web-based front end we custom developed. It takes the IP address we want to manipulate and executes the 'ip route' command on the router by proxy. It also saves additional information into a historical database about who entered/removed the IP, any Clarify tracking case associated with it (our internal ticketing system), and any other relevant information. For notification, it checks against our WHOIS-based customer tracking database that associates people records with the vlan number, and send them a notification that the IP was blackholed, and then reminders every few days until the IP is removed. Unfortunately, this was also all custom developed. As a whole, the system works REALLY well and we can sugically remove IPs from the backbone without having to kill entire subnets, and then just as easily enable them again. One final note. This system is pretty useless for modem pools, VPN concentrators, and many DHCP implementations. The dynamic IP nature of these setups means you will just kill legitimate traffic next time someone gets the IP. You can attempt to correlate your detection with the time they were handed out, of course, in the hopes you find them. - Robert Network Guy @ UW Madison
Re: uRPF-based Blackhole Routing System Overview
FWIW, I presented a paper at LISA last week that described almost an identical configuration. Slides and paper are available from http://www.net.cmu.edu/pres/lisa03 -Kevin --On Friday, November 07, 2003 1:19 PM -0600 Robert A. Hayden [EMAIL PROTECTED] wrote: uRPF was designed primarily to block spoofed IPs. However, you can trick it into blocking non-spoofed IPs by making the routing table think the IP address should legitimately be located somewhere else.
Re: uRPF-based Blackhole Routing System Overview
On Fri, 7 Nov 2003, Robert A. Hayden wrote: [snip] One final note. This system is pretty useless for modem pools, VPN concentrators, and many DHCP implementations. The dynamic IP nature of these setups means you will just kill legitimate traffic next time someone gets the IP. You can attempt to correlate your detection with the time they were handed out, of course, in the hopes you find them. Another approach to address this type of problem is the source spoofing preventing dynamic-acls support that some vendors have been adding to their products. I don't know if it's in anyone's production code-trains yet. The basic idea is that your switch snoops DHCP traffic to the port and generates an ACL based on the address assigned to the client. Removing a host is as simple as configuring your DHCP server to ignore it's requests and perhaps sending a crafty packet (custom written DECLINE) to burp the existing ACL out of the switch. Vendor F calls this feature Source IP Port Security, I'm not sure what vendor C calls it. Since this is a layer 2 feature you can configure it far out on the edge and not just at the router.
