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

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

[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.

Vendor C calls it DHCP snooping and to the best of my knowledge it is only
available under IOS not CatOS

                            Scott C. McGrath

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