• dies@pulltheplug.com who helped out with a suggestion to use an unused netblock to pull in the unreachables.
• robert@uu.net and jaw@ans.net for initial testing and evaluation of the Black Hole Route Server
• Transit Tactical Engineering, specifically Syed Malik for deployment and engineering support
• The TAC for putting up with nutty Security Engineers.

Purpose:
There are twin purposes for this paper:

1. To implement a method of dropping all traffic to a particular prefix, typically a /32 prefix, at the edge of any large IP network.
   (to protect your network and not cost you the transit cost for a flood)
2. To implement a method of tracking any traffic on a large IP network by leaveraging the previous item.
   (to quickly save your customer money and piece of mind)

Discsussion of methods

BGP implementations on, atleast Cisco and Juniper, routers allow you to arbitrarily setting the 'next-hop' to any IP address. This quirk can be used to your benefit when tracking spoofed traffic, by setting particular prefixes to a known and specially handled 'next-hop'. We can get some unique traffic tracking information off the network.

For instance we can set the 'next-hop' for an attacked host to a single address which will be routed locally, on all network equipment, to Null0 (or reject on a juniper). This will cause some interesting effects when traffic to the destination is spoofed.

Using this 'interesting effect' (backscatter traffic) we can easily and quickly track the attack traffic across our network to the ingress router interface.

The basis of the config pieces you will need on your equipment and the most likely places for the parts of the puzzle follow:

1. All routers in the network require a 'special' static to Null0 (or reject) so that when the attack traffic is reannounced as with the new 'next-hop' the network will handle this traffic appropriately.
2. One router should be designated the 'Black Hole Route Server' in your network. This host will be pushing out the new announcements for the victim host. This is usually a not-so-important core router in your network. There will be a slight change to the BGP router config to allow specially tagged static routes to be pushed into BGP with a new 'next-hop'. On a Cisco this equates to redistribution edits, a route-map and some static routes with tags. On a Juniper this means a new policy-statement and group export for your Internal BGP group along with some static routes when appropriate.
3. A 'customer' connection to your network that routes a large enough netblock which is unused... really any large block of unused address space that is routed to a customer link. For example, a /16 netblock you know a customer routes but does not use will work perfectly. Another example would be: route 96/6 to some 'customer' interface, set that advertisement to 'no-export' so it'll stay inside your AS only, and use this connection. Be sure to NOT advertise this route outside of your AS as Tony Bates will beat you with a club if it does...
4. The ability to filter the connection above when appropriate.

Config parts

!
! jump into the bgp router config
!
router bgp 31337
!
! set the static redistribution to include a route-map so we can filter 
! the routes somewhat... or atleast manipulate them
!
redistribute static route-map static-to-bgp
!
! add a stanza to the route-map to set our special nexthop
!
route-map static-to-bgp permit 5
match tag 666
set ip next-hop 172.20.20.1
set local-preference 50
set origin igp

#
# Setup the bgp protocol to export our special policy, like
# redistributing, NOTE: "XXX" is the IBGP bgp group... we don't 
# want to send this to customers do we?
#
set protocols bgp group XXX export BlackHoleRoutes
#
# Now, setup the policy option for BlackHoleRoutes, like a route-map
#
# if static route with right tag, set local-pref low, internal, no-export
# can't leak these or Tony Bates will have a fit, and set the nexthop to 
# the magical next-hop.
#
set policy-statement BlackHoleRoutes term match-tag666 from protocol static tag 666
set policy-statement BlackHoleRoutes term match-tag666 then local-preference 50
set policy-statement BlackHoleRoutes term match-tag666 then origin igp
set policy-statement BlackHoleRoutes term match-tag666 then community add no-export
set policy-statement BlackHoleRoutes term match-tag666 then nexthop 172.20.20.1
set policy-statement BlackHoleRoutes term match-tag666 then accept

ip route 172.20.20.1 255.255.255.255 Null0

set routing-options static route 172.20.20.1/32 reject install

Operational use

Ok, so you put in place the config bits above and you want to see how to use this new tool. Bascially this is what you are setting in place: Attack traffic floods in from some ingress points to pummel a customer of yours, you identify the victim IP address and verify that the attack is from spoofed sources, I'll note exactly what I mean below. Quickly erect your 'standard' ACL on the interface you specially routed that large block to above. A simple and effective filter is:

access-list 101 permit icmp any any unreachables log
access-list 101 permit ip any any

ip route victimip 255.255.255.255 Null0 tag 666

	or

set routing-options static route victimip/32 discard tag 666

Example log output for an attack:
SLOT 6:6w6d: %SEC-6-IPACCESSLOGDP: list 150 permitted icmp 65.208.80.242 -> 99.141.160.46 (3/1), 1 packet
SLOT 6:6w6d: %SEC-6-IPACCESSLOGDP: list 150 permitted icmp 65.208.80.242 -> 97.147.124.71 (3/1), 1 packet

Once you identify the ingress point simply filter incoming traffic and remove that which would be destined for the victim IP. You should, of course, follow-up with the downstream provider/customer and have them do what you did, track this attack to their ingress point.

Ok, now that you see how to track an attack in which there is atleast one stream of traffic in which the source addresses are spoofed, a synflood would be an excellent example of this, how can you track other attacks where the packets in the flood are not necessarily created as spoofed packets? Take a smurf attack for instance, how would you use this technique to track a smurf attack?

Smurf attacks are quite easy to track with this method also.

1. Find a broadcast being used in this attack which is directly connected to your network.
2. Place the unreachables filter on the victims interface
3. Black Hole the broadcast and network addresses for the broadcast you found in step 1
4. Wait for the unreachables to get logged and stop the flood at the ingress points

The real problem comes when the attacks are not spoofed, ingress points for the traffic are legit and the unreachables created through the Black Hole Route are going to never be seen by you or your specially routed netblock... The one good thing is that if there are not too many sources you can just block them where they should have entered your network... though this certainly is sub-optimal.