Automatically filtering bogons with BGP and Team Cymru Bogon Route Server Project

What do you do if someone knocks at your door, you see him through the peephole, and you notice he has a black cowl, a crowbar and a big bag? I’m quite sure: you do not open that door! Why? Because, sometimes, the gown does make the friar! And, actually, he’s really not a friar!

Same thing should happen in a network! If you know a packet is a bad packet, why should you let it go through?

In this (stupid) example bad packets are those coming from or going toward bogon IP addresses, that is, addresses picked up from unallocated or private (so, not routable) address spaces. As you know, there are many subnets used only for private addressing (RFC 1918), other are reserved (RFC 3330), and few subnets are still not allocated by IANA… so, if your router is sending or receiving a packet to/from one of these addresses, there is something you should be concerned about (of course, some restrictions may apply!)

How to identify bogons

In order to identify and catch bogon packets we need to know which subnets have to be marked as bogon.

One way to achieve this goal is to deploy static ACLs or route filters on every router we want to secure… a quite boring job on its own! But, what happens when IANA allocate one of the previously unallocated (so, bogon) subnets? Well, we have to change those ACLs on every router! This is a very boring job! Someone at RIPE knows that well!

Do you really want this?

Fortunately, we can use a great utility by Team Cymru: Bogon Route Server Project.

What is Bogon Route Server Project?

For the sake of our sanity, Team Cymru deployed some route servers running BGP which announce bogon prefixes over eBGP peering sessions. Once we have a BGP-aware box, we can get those prefixes and do what we want of them.

Here, I’ll show how to automatically handle bogon prefixes using a Linux box running Quagga, a routing software suite providing implementation of BGP.

What can we do with bogon prefixes?

From our central Quagga box we can distribute those prefixes to our routers, or to customers CPEs, and here we can filter traffic on the basis of source or destination addresses.

For example, we can avoid to route packets with a bogon destination address, simply by adding a route toward bogon prefixes with a null-pointing next-hop; it’s a kind of blackhole filtering:

ip route 192.0.2.1 255.255.255.255 Null0
ip route 1.0.0.0 255.0.0.0 192.0.2.1

With Cymru Bogon Route Server Project we can do this job in a fully automatic and central way.

Of course, we can also drop incoming packets presenting bogon source IP addresses; we can accomplish this using uRPF in a kind of source-based black hole filtering:

interface Serial1/0
 ip verify unicast source reachable-via any

Anyway, you, and only you know what’s better for your network!

Now, I would like to show you how to setup a Linux box running Quagga, with a peer session with Cymru routers, and how to use it to distribute bogon prefixes to our routers.

Peering with Cymru Bogon Route Server

At first, we have to ask Team Cymru to setup a BGP session with our Quagga box: to do so we have to contact them on the basis of what we can find on their website. We have to tell them our AS number, our peering IP addresses and optional MD5 passwords and GPG/PGP public key.

You don’t need to have a public AS number, you can also peer with them using a private AS number.

Quagga: bgpd configuration

Once we have installed Quagga and received Cymru details, we just have to edit the bgpd.conf file and add a few lines.

Quagga bgpd.conf:

router bgp YOUR_AS_NUMBER
 bgp router-id YOUR_ROUTER_ID
 neighbor cymru-bogon peer-group
 neighbor cymru-bogon remote-as 65333
 neighbor cymru-bogon ebgp-multihop
 neighbor cymru-bogon prefix-list cymru-out out
 neighbor cymru-bogon route-map CYMRUBOGONS in
 neighbor cymru-bogon maximum-prefix 100

 neighbor CYMRU_PEER_1_IP peer-group cymru-bogon
 neighbor CYMRU_PEER_2_IP peer-group cymru-bogon
!
ip community-list 10 permit 65333:888
!
route-map CYMRUBOGONS permit 10
  match community 10
  set ip next-hop 192.0.2.1
!
ip prefix-list cymru-out seq 5 deny 0.0.0.0/0 le 32

Prefix-list prevents any update to leave our box toward Cymru routers; route-map allows marked prefixes and set their next-hop to 192.0.2.1, null-pointing route.

Automagically our Quagga box gets bogon prefixes:

QuaggaBox#show ip bgp
BGP table version is 0, local router ID is YOUR_ROUTER_ID
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*  1.0.0.0          192.0.2.1                0             0 65333 i
*>                  192.0.2.1                0             0 65333 i
*  5.0.0.0          192.0.2.1                0             0 65333 i
*>                  192.0.2.1                0             0 65333 i
[cut]
*  192.168.0.0/16   192.0.2.1                0             0 65333 i
*>                  192.0.2.1                0             0 65333 i
*  198.18.0.0/15    192.0.2.1                0             0 65333 i
*>                  192.0.2.1                0             0 65333 i
*  223.0.0.0/8      192.0.2.1                0             0 65333 i
*>                  192.0.2.1                0             0 65333 i

Total number of prefixes 32

Now, setup our Quagga box to bring up peering with your routers; just add few config lines to bgpd.conf:

router bgp YOUR_AS_NUMBER
 neighbor Clients peer-group
 neighbor Clients prefix-list DoNotAcceptAnything in
 neighbor Clients route-map CYMRUBOGONS out
 neighbor Clients ebgp-multihop
 neighbor Clients send-community

 neighbor YOUR_ROUTER1_IP remote-as YOUR_AS_NUMBER
 neighbor YOUR_ROUTER1_IP peer-group Clients

 neighbor YOUR_ROUTER2_IP remote-as YOUR_AS_NUMBER
 neighbor YOUR_ROUTER2_IP peer-group Clients
!
ip prefix-list DoNotAcceptAnything seq 5 deny 0.0.0.0/0 le 32

Routers configuration

We can deploy iBGP or eBGP configuration on our routers and automatically get bogon prefixes.

This is a sample configuration:

ip route 192.0.2.1 255.255.255.255 Null0
!
ip bgp-community new-format
!
router bgp YOUR_AS_NUMBER
 no synchronization
 bgp log-neighbor-changes
 neighbor YOUR_QUAGGA_BOX_IP remote-as YOUR_AS_NUMBER
 neighbor YOUR_QUAGGA_BOX_IP update-source Loopback0
 neighbor YOUR_QUAGGA_BOX_IP prefix-list DoNotAnnounceAnything out
 neighbor YOUR_QUAGGA_BOX_IP route-map CymruBogons in
 no auto-summary
!
ip community-list standard CymruBogons permit 65333:888
!
ip prefix-list DoNotAnnounceAnything seq 5 deny 0.0.0.0/0 le 32
!
route-map CymruBogons permit 10
 match community CymruBogons
 set ip next-hop 192.0.2.1

Tests

And now, let’s verify our job…

Router#show ip bgp
BGP table version is 163, local router ID is X.Y.Z.W
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>i1.0.0.0          192.0.2.1                0    100      0 65333 i
*>i5.0.0.0          192.0.2.1                0    100      0 65333 i
[cut]
*>i192.168.0.0/16   192.0.2.1                0    100      0 65333 i
*>i198.18.0.0/15    192.0.2.1                0    100      0 65333 i
*>i223.0.0.0/8      192.0.2.1                0    100      0 65333 i

BGP gets bogon prefixes from our Quagga box; let’s take a look at our routing table, with focus on 192.168.0.0:

Router#show ip route | i 192.168
O IA 192.168.4.0/24 [110/196] via 192.168.254.3, 5d05h, Tunnel1
O IA 192.168.5.0/24 [110/196] via 192.168.254.1, 5d05h, Tunnel0
[cut]
O IA 192.168.1.0/24 [110/196] via 192.168.254.1, 5d05h, Tunnel0
B    192.168.0.0/16 [200/0] via 192.0.2.1, 1d01h

Here we have some private prefixes from OSPF, used for branch offices, and they have the right paths; in the last line, the whole 192.168.0.0/16 goes toward the null-pointing route.
Remember: more specific route wins; until we have our private prefixes from OSPF no packets will be filtered out.

Router#sh ip cef 192.168.222.1
192.168.0.0/16, version 411, epoch 0
0 packets, 0 bytes
  via 192.0.2.1, 0 dependencies, recursive
    next hop 192.0.2.1, Null0 via 192.0.2.1/32
    valid null (drop) adjacency

Well done: it’s simple and it works fine! Anyway, remember to take precautions: do no send bogon prefixes to your BGP peers (no-export plus safeguard communities) and keep in mind every network is different from others!

References

Team Cymru: Bogon Route Server Project

Quagga: Quagga Software Routing Suite

Andree Toonk: Bong Traffic Analysis in 2006

Rob Thomas (on Team Cymru website): 60 Days of Basic Naughtiness, a study conducted in 2001.

GNS3 Labs: Source-based Remote Triggered Black Hole (RTBH) Filtering with Unicast Reverse Path Forwarding (uRPF)

This post is part of a series about “ISP Security Tools and Techniques“; in this series I talk about some (I think) useful practices:

1. Remote Triggered Black Holing

2. BGP Customer triggered black holing

3. BGP triggered rate limiting and less-than-best-effort (LBE) with QPPB

4. Source-based RTBH with Unicast Reverse Path Forwarding (uRPF)

Stay tuned!

Today I drew inspiration from a brand new RFC to add a post to this little series: RFC-5635, Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF).

Especially, I would like to focus on section 4 of this RFC, Source Address RTBH Filtering.

To fully understand this post I would suggest to read my previous post Remote Triggered Black Holing.

What is source-based RTBH? and what are the differences with destination-based RTBH?

Until now, in my previous posts, I always talked about destination-based RTBH. But a source-based RTBH filtering exists too.

This mitigation technique allows an ISP to stop malicious traffic (let’s think to DDOS) on the basis of the source address it comes from. Indeed, destination-based RTBH can just be used to stop traffic on the basis of the attacked hosts addresses, or in the best case, on the couple attacked-hosts/incoming-upstream-provider (you can use different BGP communities to black-hole a prefix only on specific edge routers).

As mentioned in the RFC, if a DDOS software is instructed to attack an host name rather than an IP address, even if you change the IP address resolved by that host name, the attack won’t stop. In this scenario you just have to disrupt the whole service by filtering out the attacked prefix. Source-based RTBH can help you!

How does it work?

Source-based RTBH uses Unicast Reverse Path Forwarding (uRPF) as background mechanism to work.
As RFC says…

uRPF performs a route lookup of the source address of the packet and checks to see if the ingress interface of the packet is a valid egress interface for the packet source address (strict mode) or if any route to the source address of the packet exists (loose mode). If the check fails, the packet is typically dropped.

So, in order to stop incoming traffic from hosts A, B and C toward host Z through router R we just need to add discard routes for A, B and C on router R. And, as seen for destination-based RTBH, we can do it using BGP and communities.

Is that all?

Well, no! Some policy enforcements are due!

As first, in the same way we did for destination-based RTBH, we must use the no-export community to be sure our black-holed prefix doesn’t leave our AS.

Our policy must accept prefixes outside our network (while destination-based RTBH only accepts prefixes within our network) and, as a rule of thumb, we should not accept source-based RTBH prefixes from our customers, but we should just use this tool from management workstations under our control.

Configuration

The starting configuration is the one we left on the post BGP triggered rate limiting and less-than-best-effort (LBE) with QPPB.

In our scenario source-based RTBH is triggered from the Core router, using tagged static routes redistribution in BGP; nothing different from destination-based RTBH. So, let’s define the tags and communities:

300:300 - tag 300 - global source-based black-hole
300:301 - tag 301 - ISP1 source-based black-hole
300:302 - tag 302 - ISP2 source-based black-hole

On the Core router, here used as RTBH trigger, we have to enable BGP redistribution of static routes tagged with the news tags; indeed, we will trigger RTBH by adding tagged static routes:

route-map RTBH permit 50
 match tag 300
 set local-preference 200
 set origin igp
 set community 300:300 no-export
route-map RTBH permit 60
 match tag 301
 set local-preference 200
 set origin igp
 set community 300:301 no-export
route-map RTBH permit 70
 match tag 302
 set local-preference 200
 set origin igp
 set community 300:302 no-export

On edge routers facing upstream providers we have to implement our new communities in the route-map:

Edge1:

ip community-list 5 permit 19661100     ! 300:300
ip community-list 5 permit 19661101     ! 300:301
ip community-list 6 permit 19661102     ! 300:302
!
ip as-path access-list 2 permit ^$
!
ip access-list extended InternalNetworks
 permit ip 192.168.0.0 0.0.255.255 255.255.0.0 0.0.255.255
 deny   ip any any
!
route-map FROM_RR deny 30
 match community 6
!
route-map FROM_RR deny 35
 match ip address InternalNetworks
 match community 5
!
route-map FROM_RR permit 40
 match as-path 2
 match community 5
 set community no-export no-advertise
 set ip next-hop 192.0.2.1

Here, 300:300 and 300:301 communities (community-list 5) are welcome, while 300:302 community is not accepted – it’s only for ISP2 facing router. Moreover, we just accept prefixes external to our network (192.168.0.0/16).

Similar config is on Edge2:

ip community-list 5 permit 19661100     ! 300:300
ip community-list 5 permit 19661102     ! 300:302
ip community-list 6 permit 19661101     ! 300:301
!
ip as-path access-list 2 permit ^$
!
ip access-list extended InternalNetworks
 permit ip 192.168.0.0 0.0.255.255 255.255.0.0 0.0.255.255
 deny   ip any any
!
route-map FROM_RR deny 30
 match community 6
!
route-map FROM_RR deny 35
 match ip address InternalNetworks
 match community 5
!
route-map FROM_RR permit 40
 match as-path 2
 match community 5
 set community no-export no-advertise
 set ip next-hop 192.0.2.1

Finally, we have to enable uRPF on ISP-facing interfaces; we use the loose mode here:

Edge1:

interface Serial1/0
 ip address 172.16.1.1 255.255.255.252
 ip verify unicast source reachable-via any

Edge2:

interface Serial1/0
 ip address 172.16.2.1 255.255.255.252
 ip verify unicast source reachable-via any

Tests

To test the solution we have to add another loopback interface to ISPs routers, in order to have two different source IP addresses for each ISP:

ISP1:

interface Loopback1
 ip address 10.0.1.2 255.255.255.255
!
router bgp 100
 network 10.0.1.2 mask 255.255.255.255

ISP2:

interface Loopback1
 ip address 10.0.2.2 255.255.255.255
!
router bgp 200
 network 10.0.2.2 mask 255.255.255.255

Now, suppose we have an attack from ISP1 Loopback1 toward Cust10 (so, from 10.0.1.2 to 192.168.10.1).

We can stop the attack using destination-based RTBH, but traffic from Loopback0 will be disrupted too:

Core(config)#ip route 192.168.10.1 255.255.255.255 null0 tag 101

ISP1#ping 192.168.10.1 so lo1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.1.2
.....
Success rate is 0 percent (0/5)

ISP1#ping 192.168.10.1 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.1.1
.....
Success rate is 0 percent (0/5)

As you can see, both source addresses can’t reach our host.

So, let’s try our new solution; as first remove the previous RTBH filter:

Core(config)#no ip route 192.168.10.1 255.255.255.255 null0 tag 101

then trigger the source-based filtering for the attacking IP address:

Core(config)#ip route 10.0.1.2 255.255.255.255 null0 tag 301

Edge1 receives the new BGP announcement and it adds the discard interface route:

Edge1#sh ip route bgp | i 10.0.1.2
B       10.0.1.2 [200/0] via 192.0.2.1, 00:01:03

Edge1#sh ip cef 10.0.1.2
10.0.1.2/32, version 32, epoch 0
0 packets, 0 bytes
  via 192.0.2.1, 0 dependencies, recursive
    next hop 192.0.2.1, Null0 via 192.0.2.1/32
    valid null adjacency

As we can see, packets from ISP1 Loopback1 are dropped at Edge1, while packets from Loopback0 pass:

ISP1#ping 192.168.10.1 so lo1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.1.2
.....
Success rate is 0 percent (0/5)

ISP1#ping 192.168.10.1 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 476/608/724 ms

Download

You can download the updated GNS3 file and configs here. The ZIP file contains multiple config subdirectories, one for each step covered on previous posts, and the new “6. Source-based RTBH filtering”.

References

IETF: RFC-5635, Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)

GNS3 Labs: BGP triggered rate limiting and less-than-best-effort (LBE) with QPPB

This post is part of a series about “ISP Security Tools and Techniques“; in this series I talk about some (I think) useful practices:

1. Remote Triggered Black Holing

2. BGP Customer triggered black holing

3. BGP triggered rate limiting and less-than-best-effort (LBE) with QPPB

4. Source-based RTBH with Unicast Reverse Path Forwarding (uRPF)

Stay tuned!

As I already wrote in my previous posts, an ISP can provide their customers some useful tools to mitigate (D)DoS attacks: Remote Triggered Black Holing and its NOC-independent version, Customer triggered black holing are tools that, once identified attacked hosts or networks, let us to stop malicious traffic at the provider’s edge.

Anyway, when we drop traffic toward attacked hosts, we can’t investigate the attack anymore; we would need a tool which allowed us to analyze traffic and, in the meantime, that would avoid wasting network resources. Our (dear) provider could provide it by implementing rate limiting and less-than-best-effort services using QoS Policy Propagation via BGP (QPPB).

Scenario and goals

The scenario I will use in this post is the same I used for previous posts I already mentioned before. We are the AS 300 provider, we have 2 customers and 2 upstream providers connected with BGP sessions. Edge1 and Edge2 are routers toward the upstream providers, Edge3 is the router our customers are connected to.

Startup configurations are the same I left on my last post, “Customer triggered black holing”.

As said, the goal is to provide a tool customers can use to rate-limit traffic toward attacked hosts, in order to let them to investigate attacks. This tool should be used by customers avoiding NOC intervention. Scalability is a must.

The solution and how it works

The solution proposed here is based on QoS Policy Propagation via BGP (QPPB).

Cisco defines it as a feature that “allows you to classify packets by IP precedence based on BGP community lists, BGP autonomous system paths, and access control lists” (see Cisco 10000 Series Router Quality of Service Configuration Guide). And, of course, that is all! There’s not much more to say!

How does it work? A BGP router running QPPB receives a prefix and matches it using a route-map, then it sets that prefix’s IP precedence or QoS-group accordingly; router’s interfaces are configured to match traffic’s source or destination address against the prefix and to classify packets; once classified, packets can be matched against normal QoS class-matches and policies. Take a look at the picture for a diagram.

Be aware, no attributes or other infos are added to BGP UPDATEs; it’s just a local mechanism to mark routes and classify packets.

Implementation

Now that we know how QPPB works we can use it to implement rate-limiting QoS policies and to trigger them via BGP.

As first, we have to define on each edge router a QoS policy with two class-maps: one used to rate-limit traffic, and the other used to mark the traffic as less-than-best-effort (LBE): lets say we’ll use QoS-group 1 to rate-limit traffic at 8Kbps and QoS-group 2 to mark traffic as LBE.

Edge1 and Edge2:

class-map match-all QPPB-QoSGroup-1
 match qos-group 1
class-map match-all QPPB-QoSGroup-2
 match qos-group 2
!
policy-map QPPB
 class QPPB-QoSGroup-1
   police cir 8000
     conform-action transmit
     exceed-action drop
 class QPPB-QoSGroup-2
  set dscp cs1

Then we can apply our policy to the core facing interfaces, for outgoing traffic (traffic from upstream providers toward our core/customers):

Edge1 and Edge2:

interface FastEthernet0/0
 service-policy output QPPB

Now, we have to define BGP communities to map QoS groups: we will use the following mapping:

300:201 - QoS group 1 (rate-limit to 8 Kbps)
300:202 - QoS group 2 (LBE marking)

Once defined, we have to implement communities in BGP:

Edge1 and Edge2:

ip community-list 3 permit 300:201
ip community-list 4 permit 300:202
!
route-map QPPB permit 10
 match community 3
 set ip qos-group 1
route-map QPPB permit 20
 match community 4
 set ip qos-group 2
route-map QPPB permit 1000
!
router bgp 300
 table-map QPPB

As you can see, the route-map used for QPPB can’t be the same used for the inbound BGP UPDATEs. We must add another route-map to the BGP process using the table-map subcommand: as Cisco says in the Command Lookup Tool this command is used “to modify metric and tag values when the IP routing table is updated with BGP learned routes”.

Now we can enable QPPB on upstream ISPs facing interfaces to classify incoming traffic based on its destination IP address:

Edge1 and Edge2:

interface Serial1/0
 bgp-policy destination ip-qos-map

For the sake of completion, I say you can use this command to match source or destination address of a packet, and to use IP precedence or QoS-groups for classification. Here we use destination based matching and QoS-groups.

Now, let our customer routers to trigger the services: as usual, we will use a tagged static route redistributed in BGP. We already configured the route-map and redistribution in previous posts, so we just need to add some entries to it:

Cust10 and Cust20:

route-map RTBH permit 100
 match tag 201
 set community 300:201
!
route-map RTBH permit 110
 match tag 202
 set community 300:202

Tests

To test the solution we just have to add a static route toward the prefix we want to rate-limit (or to mark as LBE) on the customer router:

Cust10(config)#ip route 192.168.10.20 255.255.255.255 fa1/0 tag 201

On the edge router we have the new /32 prefix with the expected community:

Edge1#sh ip bgp 192.168.10.20
BGP routing table entry for 192.168.10.20/32, version 12
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Advertised to update-groups:
     2
  65310
    192.168.0.2 (metric 66) from 192.168.255.0 (192.168.255.0)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Community: 19661001
      Originator: 192.168.3.2, Cluster list: 192.168.255.0

and we also have a route and a CEF entry tagged with QoS-group 1:

Edge1#sh ip route 192.168.10.20
Routing entry for 192.168.10.20/32
  Known via "bgp 300", distance 200, metric 0
  Tag 65310, qos-group 1, type internal
  Last update from 192.168.0.2 00:00:55 ago
  Routing Descriptor Blocks:
  * 192.168.0.2, from 192.168.255.0, 00:00:55 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 65310

Edge1#sh ip cef 192.168.10.20
192.168.10.20/32, version 34, epoch 0, cached adjacency 192.168.1.1
0 packets, 0 bytes, qos-group 1
  via 192.168.0.2, 0 dependencies, recursive
    next hop 192.168.1.1, FastEthernet0/0 via 192.168.0.0/30
    valid cached adjacency

Now, we ping 192.168.10.20 from ISP1 (don’t expect echo replies, there is not a host at that address, but we just need traffic going toward it):

ISP1#ping 192.168.10.20 source lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.20, timeout is 2 seconds:
Packet sent with a source address of 10.0.1.1
.....
Success rate is 0 percent (0/5)

On Edge1, fa0/0 output policy counters show 5 packets classified as QPPB-QoSGroup-1 class-match:

Edge1#sh policy-map interface fa0/0 output
 FastEthernet0/0

  Service-policy output: QPPB

    Class-map: QPPB-QoSGroup-1 (match-all)
      5 packets, 570 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: qos-group 1
      police:
          cir 8000 bps, bc 1500 bytes
        conformed 5 packets, 570 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop
        conformed 0 bps, exceed 0 bps

[cut]

Let’s try with Cust20 and LBE service:

Cust20(config)#ip route 192.168.20.40 255.255.255.255 fa1/0 tag 202

The prefix is on Edge2, right community, right route tag:

Edge2#sh ip bgp 192.168.20.40
BGP routing table entry for 192.168.20.40/32, version 15
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Advertised to update-groups:
     2
  65320
    192.168.0.6 (metric 66) from 192.168.255.0 (192.168.255.0)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Community: 19661002
      Originator: 192.168.3.2, Cluster list: 192.168.255.0

Edge2#sh ip route 192.168.20.40
Routing entry for 192.168.20.40/32
  Known via "bgp 300", distance 200, metric 0
  Tag 65320, qos-group 2, type internal
  Last update from 192.168.0.6 00:01:15 ago
  Routing Descriptor Blocks:
  * 192.168.0.6, from 192.168.255.0, 00:01:16 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1
      Route tag 65320

Edge2#sh ip cef 192.168.20.40
192.168.20.40/32, version 32, epoch 0, cached adjacency 192.168.2.1
0 packets, 0 bytes, qos-group 2
  via 192.168.0.6, 0 dependencies, recursive
    next hop 192.168.2.1, FastEthernet0/0 via 192.168.0.4/30
    valid cached adjacency

We try to ping the host from ISP2…

ISP2#ping 192.168.20.40 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.20.40, timeout is 2 seconds:
Packet sent with a source address of 10.0.2.1
.....
Success rate is 0 percent (0/5)

… and Edge2 policy counters go up for QPPB-QoSGroup-2:

Edge2#sh policy-map interface fa0/0 output
 FastEthernet0/0

  Service-policy output: QPPB

    Class-map: QPPB-QoSGroup-1 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: qos-group 1
      police:
          cir 8000 bps, bc 1500 bytes
        conformed 0 packets, 0 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop
        conformed 0 bps, exceed 0 bps

    Class-map: QPPB-QoSGroup-2 (match-all)
      5 packets, 570 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: qos-group 2
      QoS Set
        dscp cs1
          Packets marked 5

[cut]

Download

In the RateLimit_LBE.zip file you can find the GNS3 Lab with previous and current configuration files. On the RTBH_Configs directory you will find the “5. Rate-limit and LBE” subdirectory with the configuration discussed in this post.

References

QoS Policy Propagation with BGP (QPPB) on Informit: http://www.informit.com/content/images/9781587201240/appendix/QPPBSection.pdf

Cisco 10000 Series Router Quality of Service Configuration Guide: http://www.cisco.com/en/US/docs/routers/10000/10008/configuration/guides/qos/10qqppb.html

GNS3 Labs: BGP Customer triggered black holing

This post is part of a series about “ISP Security Tools and Techniques“; in this series I talk about some (I think) useful practices:

1. Remote Triggered Black Holing

2. BGP Customer triggered black holing

3. BGP triggered rate limiting and less-than-best-effort (LBE) with QPPB

4. Source-based RTBH with Unicast Reverse Path Forwarding (uRPF)

Stay tuned!

In this post I’ll show you how to let your customers to trigger black holing for their prefixes. What I will write is based on my previous post GNS3 Lab: Remote Triggered Black Holing: same scenario, same startup config (the final one of that post).

What is customer triggered blackholing?

Suppose a customer notices one of its hosts is under attack; using customer triggered black holing he can stop malicious traffic toward the attacked host at the ISP edge, and he can do this without the need to ask the provider’s NOC to run RTBH.

While the customer’s staff is analyzing the attack, other hosts remain reachable from the outside, because just the attacked host has been black-holed. Furthermore, all RTBH features can be used: if the customer knows the attack is coming into ISP network from a specific upstream provider, he can just black-hole the attacked prefix on the ISP edge routers facing this specific provider, maintaining full service for networks behind other upstream providers. Of course, when the attack is over, he can resume the prefix and the regular traffic toward it, always avoiding to ask provider’s NOC.

Customer-triggered blackholing let our customers to lower their response time against attacks and it also lower work load and liability of our NOC.

How does it work?

To let our customers to activate RTBH we just need them to announce prefixes they want to black-hole using the specific BGP community. For example, if customer 10 (AS 65310) wants to black-hole 192.168.10.20/32 toward ISP2 (AS 200) he just has to announce that prefix with community 300:102.

As we already did in the Core router, our customers will trigger RTBH just adding a tagged static route toward the prefix they want to blackhole.

Configuration

On the customers routers we need to add the send-community keyword to the neighbor, in order to let them to send communities to our Edge router:

Cust10(config)#router bgp 65310
Cust10(config-router)#neighbor 192.168.0.1 send-community

Cust20(config)#router bgp 65320
Cust20(config-router)#neighbor 192.168.0.5 send-community

We need to set send-community in our Edge router too, so that it could send communities to our RR:

Edge3(config)#router bgp 300
Edge3(config-router)#neighbor 192.168.255.0 send-community

Our RR router already has the send-community keyword, so it already sends communities to other peers (RR clients):

Core#sh run | sec bgp
router bgp 300
 no synchronization
 bgp log-neighbor-changes
 redistribute static route-map RTBH
 neighbor Edge peer-group
 neighbor Edge remote-as 300
 neighbor Edge update-source Loopback0
 neighbor Edge route-reflector-client
 neighbor Edge send-community
 neighbor Edge soft-reconfiguration inbound
 neighbor 192.168.1.2 peer-group Edge
 neighbor 192.168.2.2 peer-group Edge
 neighbor 192.168.3.2 peer-group Edge
 no auto-summary

(look at the neighbor Edge send-community line)

Now, we need to add the RTBH route-map to our customers routers; we will match static route tags in order to add the AS300 RTBH community to prefixes:

route-map RTBH permit 10
 match tag 100
 set community 19660900
route-map RTBH permit 20
 match tag 101
 set community 19660901
route-map RTBH permit 30
 match tag 102
 set community 19660902
route-map RTBH permit 40
 match tag 199
 set community 19660999
route-map RTBH deny 1000

As opposed to the Core router’s RTBH route-map, here we have to remove the no-export community from the set community statements, otherwise black-holed prefixes will not cross the customer’s AS borders.

Now we just have to redistribute static routes into BGP using the route-map:

Cust10(config)#router bgp 65310
Cust10(config-router)#redistribute static route-map RTBH

Cust20(config)#router bgp 65320
Cust20(config-router)#redistribute static route-map RTBH

Testing

At this point, customers just have to add static routes for their attacked prefixes to black-hole traffic at AS300 edges:

Cust10(config)#ip route 192.168.10.20 255.255.255.255 fa1/0 tag 100

In the example, Cust10 announces 192.168.10.20/32 prefix to our Edge3 router with community 300:100 (19660900):

Edge3#sh ip bgp 192.168.10.20
BGP routing table entry for 192.168.10.20/32, version 19
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Advertised to update-groups:
     1          2
  65310
    192.168.0.2 from 192.168.0.2 (192.168.10.1)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: 19660900

Edge3 sends it to our RR wich, in turn, reflects it to Edge1 and Edge2 routers:

Edge1#sh ip bgp
BGP table version is 3, local router ID is 192.168.1.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>i192.168.10.0     192.168.0.2              0    100      0 65310 i
*>i192.168.10.20/32 192.0.2.1                0    100      0 65310 ?

Edge1#sh ip bgp 192.168.10.20
BGP routing table entry for 192.168.10.20/32, version 3
Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to any peer)
Flag: 0x820
  Not advertised to any peer
  65310
    192.0.2.1 from 192.168.255.0 (192.168.255.0)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Community: no-export no-advertise
      Originator: 192.168.3.2, Cluster list: 192.168.255.0

Edge1#sh ip cef 192.168.10.20
192.168.10.20/32, version 22, epoch 0
0 packets, 0 bytes
  via 192.0.2.1, 0 dependencies, recursive
    next hop 192.0.2.1, Null0 via 192.0.2.1/32
    valid null adjacency

Edge2#sh ip cef 192.168.10.20
192.168.10.20/32, version 22, epoch 0
0 packets, 0 bytes
  via 192.0.2.1, 0 dependencies, recursive
    next hop 192.0.2.1, Null0 via 192.0.2.1/32
    valid null adjacency

Of course we need strong policy enforcement on the customers facing edge router (Edge3) in order to avoid customers to announce prefixes assigned to other customers, or to use unproper communities.

In this post what I missed to implement is customer triggered blackholing on the same Edge3 router. Indeed there is not a route-map which sets next-hop to null0 for blackholed prefixes. This solution works fine for global and ISP-specific blackholing, but not for customers blackholing. To achieve this goal more work is needed, maybe I will write another post about this!

Download the lab

You can download the GNS3 Lab here. Within the .zip file, in the config directory, you can find the previous post configurations and the new “4. Customer trigger blackholing” subdirectory containing the final config.

GNS3 Lab: Remote Triggered Black Holing

This post is part of a series about “ISP Security Tools and Techniques“; in this series I talk about some (I think) useful practices:

1. Remote Triggered Black Holing

2. BGP Customer triggered black holing

3. BGP triggered rate limiting and less-than-best-effort (LBE) with QPPB

4. Source-based RTBH with Unicast Reverse Path Forwarding (uRPF)

Stay tuned!

In this post I would like to talk about Remote Triggered Black Holing, a mechanism to protect a network by filtering malicious traffic at the edge. It’s a powerful tool ISPs can (and should) adopt to stop DDOS attacks on their networks.

UPDATE 2009-06-21: You can find a related solution to use customer triggered blackholing in this new post!

Scenario

We have a network in AS 300 with a core router connected to 3 edge routers: 2 of these have an upstream link to 2 ISPs, AS 100 and AS 200, the third has connections toward customers. In our network OSPF is running as IGP; BGP peering sessions are up with ISPs and customers.

Objectives

While providing connectivity to our customers, we want to protect our network against possible DOS coming from external attackers. We want to deploy a solution which let us to stop malicious traffic to overwhelm our core as quickly as possible.

BGP basic configuration

As first, we setup the Core router and we elect it as route-reflector…

Core:

interface Loopback0
 ip address 192.168.255.0 255.255.255.255
!
router bgp 300
 no synchronization
 bgp log-neighbor-changes
 neighbor Edge peer-group
 neighbor Edge remote-as 300
 neighbor Edge update-source Loopback0
 neighbor Edge route-reflector-client
 neighbor 192.168.1.2 peer-group Edge
 neighbor 192.168.2.2 peer-group Edge
 neighbor 192.168.3.2 peer-group Edge
 no auto-summary
!

All peers are grouped under a common peer-group and configured as route reflector clients.

Then we setup the ISPs facing edge routers: on each router we need an iBGP session with our RR, and an eBGP session with the ISP:

Edge1 (and similar on Edge2):

router bgp 300
 no synchronization
 bgp log-neighbor-changes
 neighbor 172.16.1.2 remote-as 100
 neighbor 172.16.1.2 remove-private-as
 neighbor 172.16.1.2 filter-list 1 out
 neighbor 192.168.255.0 remote-as 300
 no auto-summary
!
ip as-path access-list 1 permit ^65[0-9][0-9][0-9]$

We don’t want our AS to be a transit-AS between ISP1 and ISP2, so we just advertise locally originated prefixes on the ISPs facing routers: the filter-list matches just AS numbers in the form 65xxx, so only our customer originated prefixes will pass… and we remove the private numbers from the AS path list.

Our providers simply have an eBGP peering session with our AS, advertising their loopbacks:

ISP1 (and similar on ISP2):

router bgp 100
 no synchronization
 bgp log-neighbor-changes
 network 10.0.1.1 mask 255.255.255.255
 neighbor 172.16.1.1 remote-as 300
 no auto-summary

On Edge3, the customers facing router, we have a configuration that let us to be sure our customers will only advertise their assigned subnets or sub-prefixes:

router bgp 300
 no synchronization
 bgp log-neighbor-changes
 neighbor 192.168.0.2 remote-as 65310
 neighbor 192.168.0.2 route-map BGP-Cust1 in
 neighbor 192.168.0.6 remote-as 65320
 neighbor 192.168.0.6 route-map BGP-Cust2 in
 neighbor 192.168.255.0 remote-as 300
 no auto-summary
!
ip access-list extended BGP-Cust1
 permit ip 192.168.10.0 0.0.0.255 255.255.255.0 0.0.0.255
ip access-list extended BGP-Cust2
 permit ip 192.168.20.0 0.0.0.255 255.255.255.0 0.0.0.255
!
route-map BGP-Cust1 permit 10
 match ip address BGP-Cust1
!
route-map BGP-Cust2 permit 10
 match ip address BGP-Cust2

You can find these configurations on the “2. Routing” subdirectory within the main config dir.

Now, we are ready to deploy our solution: Remote triggered black holing.

The solution

Remote triggered black holing (RTBH) let us to prevent malicious traffic from entering our network and it can be applied in a centralized, quick and selective way. How does it work?

1) On each edge router we add a static route pointing to the null0 interface, so that all routers have the same route toward null0:

ip route 192.0.2.1 255.255.255.255 null0

2) When a host is under attack (for example 192.168.10.5/32), from a central router (the trigger) we inject a specific route for that host into BGP, with a specific BGP community used for RTBH.

3) Each edge router receives an UPDATE such this: 192.168.10.5/32 -> community 300:XXX; the router handles the UPDATE accordingly to the community and maps the prefix to the null-pointing route; in this way it forwards traffic for the attacked host to the null0, in other words it drops traffic avoiding useless resource consuption.

4) When the attack is over, we remove the route from our trigger, so edge routers will receive a withdrawal for that route, they remove the FIB entry pointing to null0 and traffic return to flow in the usual way.

In order to facilitate operations, we can extend the use of RTBH to our customers too, so that they can stop malicious traffic as soon as they detect an attack.

UPDATE 2009-06-21: You can read more about customer trigger blackholing in this new post!

RTBH policy

As first we have to decide the communities-driven policy we want to apply to RTBH: we use community 300:100 to block traffic on any edge router, 300:101 to block just traffic coming from ISP1, 300:102 to block traffic from ISP2 and 300:199 to black-hole traffic on Edge3, the customer facing router. With this kind of policy, if we know the source of the attack, we can stop it while maintaining partial service. For example, if the attack is from a network that reach us via ISP1, we can block just ISP1 traffic while maintaining traffic from ISP2. Of course, in any case we just black-hole traffic toward the attacked host/subnet, not all the traffic!

300:100 - global black-holing
300:101 - ISP1 black-holing
300:102 - ISP2 black-holing
300:199 - customers black-holing

At this time, we need to elect a router as trigger: in our example we’ll use Core router. Please note that in this example many decisions are forced by the limited number of routers we can deploy in GNS3, because of CPU and memory resources they take.

Trigger configuration

To trigger an UPDATE we use a static route manually added to the Core router. In order to let this UPDATE to go out, we need to redistribute static routes into BGP, after a little route-map handling.

The route we add to the Core router to block incoming traffic is in the form ip route ATTACKED_HOST 255.255.255.255 null0 tag XXX.

Of course, we can block a subnet instead of a host simply changing the destination IP and mask.
The tag XXX used to add the route let us to filter which routes we need to apply RTBH policy to, and also to understand what kind of policy to use.

All this stuff is handled by a route-map, applied to the static route redistribution in BGP:

Core#sh run | sec route-map
route-map RTBH permit 10
 match tag 100
 set local-preference 200
 set origin igp
 set community 19660900 no-export
route-map RTBH permit 20
 match tag 101
 set local-preference 200
 set origin igp
 set community 19660901 no-export
route-map RTBH permit 30
 match tag 102
 set local-preference 200
 set origin igp
 set community 19660902 no-export
route-map RTBH permit 40
 match tag 199
 set local-preference 200
 set origin igp
 set community 19660999 no-export
route-map RTBH deny 1000

Core(config)#router bgp 300
Core(config-router)#redistribute static route-map RTBH
Core(config-router)#neighbor Edge send-community

In the route map we match the route tag and we set the BGP community accordingly: tag 100 = community 300:100, tag 101 = community 300:101 and so on.

300:100 - tag 100 - global black-holing
300:101 - tag 101 - ISP1 black-holing
300:102 - tag 102 - ISP2 black-holing
300:199 - tag 199 - customers black-holing

We also set a higher than default local preference value (200 vs default 100) and a better origin (IGP instead of the incomplete used for redistribution): we want this prefix to be preferred to other.
It’s very important to add the no-export community too: in this way we avoid our black-holed prefix to leave our AS.

Don’t forget to configure the send-community!

Edge routers configuration

As first, we have to configure edge routers with the null-pointing route: we use the IANA TEST-NET 192.0.2.0/24 subnet.

Edge1(config)#ip route 192.0.2.1 255.255.255.255 null0
Edge2(config)#ip route 192.0.2.1 255.255.255.255 null0
Edge3(config)#ip route 192.0.2.1 255.255.255.255 null0

When a packet is dropped, an “ICMP unreachable” message is sent back to the source: to avoid a flooding of “ICMP unreachable” messages we need to add the “no ip unreachables” command to the null0 interface on the edge routers:

Edge1(config)#int null 0
Edge1(config-if)#no ip unreachables

Edge2(config)#int null 0
Edge2(config-if)#no ip unreachables

Edge3(config)#int null 0
Edge3(config-if)#no ip unreachables

Now, we have to setup the route-map used to handle incoming UPDATES.

Edge1#sh run | begin ip community-list
ip community-list 1 permit 19660900	! 300:100, always accepted (global black-holing)
ip community-list 1 permit 19660901	! 300:101, accepted just on Edge1 (ISP1)
ip community-list 2 permit 19660902	! 300:102, accepted just on Edge2 (ISP2), dropped here
ip community-list 2 permit 19660999	! 300:199, accepted just on Edge3 (customers), dropped here
ip as-path access-list 1 permit ^65[0-9][0-9][0-9]$
ip as-path access-list 1 permit ^$
!
!
route-map FROM_RR deny 10
 match community 2
!
route-map FROM_RR permit 20
 match as-path 1
 match community 1
 set community no-export no-advertise
 set ip next-hop 192.0.2.1
!
route-map FROM_RR permit 1000

Edge1(config)#router bgp 300
Edge1(config-router)#neighbor 192.168.255.0 route-map FROM_RR in

This is the route-map used on Edge1. Here we have to black-hole just prefixes tagged with communities 300:100 (global black-holing) or 300:101 (ISP1 black-holing), so as first we have to drop prefixes tagged with 300:102 (reserved for ISP2 black-holing) and 300:199 (customer-side).

In the second instance we match just prefixes coming from our AS (locally generated) or from our customers (ASs 65XYZ) matching the right communities. Here we set the next-hop for these prefixes to the null-pointing route (192.0.2.1) and set net no-export and no-advertise community.

In the last instance we permit all other prefixes.

We need a similar configuration for Edge2 and Edge3; here we just change the community-list:

Edge2#sh run | begin ip community-list
ip community-list 1 permit 19660900
ip community-list 1 permit 19660902
ip community-list 2 permit 19660901
ip community-list 2 permit 19660999

Edge3#sh run | begin ip community-list
ip community-list 1 permit 19660900
ip community-list 1 permit 19660999
ip community-list 2 permit 19660902
ip community-list 2 permit 19660901

Test the solution

Let’s suppose the host 192.168.10.1/32 on Customer10 is under attack and we don’t know what network the DOS come from.

As first, we can trigger a global black-hole:

Core#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Core(config)#ip route 192.168.10.1 255.255.255.255 null0 tag 100

Edge1 receives the new prefix and add it to the routing table:

Edge1#sh ip bgp
BGP table version is 12, local router ID is 192.168.1.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.0.1.1/32      172.16.1.2               0             0 100 i
*>i10.0.2.1/32      172.16.2.2               0    100      0 200 i
*>i192.168.10.0     192.168.0.2              0    100      0 65310 i
*>i192.168.10.1/32  192.0.2.1                0    200      0 i
*>i192.168.20.0     192.168.0.6              0    100      0 65320 i

Edge1#sh ip route 192.168.10.1
Routing entry for 192.168.10.1/32
  Known via "bgp 300", distance 200, metric 0, type internal
  Last update from 192.0.2.1 00:01:10 ago
  Routing Descriptor Blocks:
  * 192.0.2.1, from 192.168.255.0, 00:01:10 ago
      Route metric is 0, traffic share count is 1
      AS Hops 0

A recursive lookup shows as CEF drops these packets:

Edge1#sh ip cef 192.168.10.1
192.168.10.1/32, version 30, epoch 0
0 packets, 0 bytes
  via 192.0.2.1, 0 dependencies, recursive
    next hop 192.0.2.1, Null0 via 192.0.2.1/32
    valid null (drop) adjacency

The same is on every edge router:

Edge2#sh ip route 192.168.10.1
Routing entry for 192.168.10.1/32
  Known via "bgp 300", distance 200, metric 0, type internal
  Last update from 192.0.2.1 00:03:31 ago
  Routing Descriptor Blocks:
  * 192.0.2.1, from 192.168.255.0, 00:03:31 ago
      Route metric is 0, traffic share count is 1
      AS Hops 0

Edge3#sh ip route 192.168.10.1
Routing entry for 192.168.10.1/32
  Known via "bgp 300", distance 200, metric 0, type internal
  Last update from 192.0.2.1 00:04:13 ago
  Routing Descriptor Blocks:
  * 192.0.2.1, from 192.168.255.0, 00:04:13 ago
      Route metric is 0, traffic share count is 1
      AS Hops 0

ISPs, as expected, don’t know anything about this new prefix:

ISP1#sh ip bgp | beg Network
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.0.1.1/32      0.0.0.0                  0         32768 i
*> 192.168.10.0     172.16.1.1                             0 300 i
*> 192.168.20.0     172.16.1.1                             0 300 i

Traffic toward the attacked host is dropped at the edge:

ISP2#ping 192.168.10.1 source lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.2.1
.....
Success rate is 0 percent (0/5)

Edge2#debug ip cef drops
IP CEF drops debugging is on
Edge2#
*Mar  1 00:28:46.947: CEF-Drop: Packet for 192.168.10.1 to null0 (silent)
*Mar  1 00:28:46.947: CEF-Drop: Packet for 192.168.10.1 -- switch to null0
*Mar  1 00:28:48.915: CEF-Drop: Packet for 192.168.10.1 to null0 (silent)
*Mar  1 00:28:48.915: CEF-Drop: Packet for 192.168.10.1 -- switch to null0
*Mar  1 00:28:50.883: CEF-Drop: Packet for 192.168.10.1 to null0 (silent)
*Mar  1 00:28:50.883: CEF-Drop: Packet for 192.168.10.1 -- switch to null0
*Mar  1 00:28:53.023: CEF-Drop: Packet for 192.168.10.1 to null0 (silent)
*Mar  1 00:28:53.023: CEF-Drop: Packet for 192.168.10.1 -- switch to null0
*Mar  1 00:28:54.963: CEF-Drop: Packet for 192.168.10.1 to null0 (silent)
*Mar  1 00:28:54.963: CEF-Drop: Packet for 192.168.10.1 -- switch to null0

When we know the attack is over, we just remove the route from the trigger…

Core(config)#no ip route 192.168.10.1 255.255.255.255 null0 tag 100

… and everything back to normal:

Edge1#sh ip cef 192.168.10.1
192.168.10.0/24, version 28, epoch 0, cached adjacency 192.168.1.1
0 packets, 0 bytes
  via 192.168.0.2, 0 dependencies, recursive
    next hop 192.168.1.1, FastEthernet0/0 via 192.168.0.0/30
    valid cached adjacency

ISP2#ping 192.168.10.1 source lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.2.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 544/651/744 ms

If we know the attack come from ISP2, we can black-hole the attacked host on the ISP2 facing router:

Core(config)#ip route 192.168.10.1 255.255.255.255 null0 tag 102

Edge1 and Edge3 reach the host as usual…

Edge1#sh ip cef 192.168.10.1
192.168.10.0/24, version 28, epoch 0, cached adjacency 192.168.1.1
0 packets, 0 bytes
  via 192.168.0.2, 0 dependencies, recursive
    next hop 192.168.1.1, FastEthernet0/0 via 192.168.0.0/30
    valid cached adjacency

Edge3#sh ip cef 192.168.10.1
192.168.10.0/24, version 31, epoch 0, cached adjacency to Serial1/0
0 packets, 0 bytes
  via 192.168.0.2, 0 dependencies, recursive
    next hop 192.168.0.2, Serial1/0 via 192.168.0.0/30
    valid cached adjacency

… while Edge2 drops traffic toward it:

Edge2#sh ip cef 192.168.10.1
192.168.10.1/32, version 33, epoch 0
0 packets, 0 bytes
  via 192.0.2.1, 0 dependencies, recursive
    next hop 192.0.2.1, Null0 via 192.0.2.1/32
    valid null (drop) adjacency

Download

You can download the GNS3 Lab here. You will find 3 subdirectories within the main config dir: “1. Interfaces and IP”, with just interfaces and their IP address, “2. Routing”, with OSPF and BGP config and “3. RTBH” with the final RTBH configuration.

Resources

Cisco.com: Remotely Triggered Black Hole Filtering

Marco d’Itri: BGP-triggered blackholing