There are twin purposes for this paper:
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:
Config partsThese configs assume your router and network are already running 'normally' and that you are doing static redistribution into BGP. Black Hole Route Server Examples:
! ! 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
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 anyNow, Black Hole Route the victim IP address:
ip route victimip 255.255.255.255 Null0 tag 666 or set routing-options static route victimip/32 discard tag 666Now, turn on terminal monitoring on the router with the access list and see where unreachables originate. The interface from which the unreachable originates should be the ingress for the flood of traffic... :) Quick, easy, simple, anyone can do this, right?
Example log output for an attack:
SLOT 6:6w6d: %SEC-6-IPACCESSLOGDP: list 150 permitted icmp 18.104.22.168 -> 22.214.171.124 (3/1), 1 packet
SLOT 6:6w6d: %SEC-6-IPACCESSLOGDP: list 150 permitted icmp 126.96.36.199 -> 188.8.131.52 (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.
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.