uRPF-based Blackhole Routing System Overview
Robert A. Hayden
rhayden at geek.net
Fri Nov 7 19:19:01 UTC 2003
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
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
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
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
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.
Network Guy @ UW Madison
More information about the NANOG