North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

uRPF-based Blackhole Routing System Overview

  • From: Robert A. Hayden
  • Date: Fri Nov 07 14:25:21 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 
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