Remote Triggered Blackhole Filtering

Introduction

Architecture used to control the internal routing to filter traffic on the edges or core for issues like DDoS/worms or other undesired high volume traffic.

RTBH Overview

  • Used to effectively filter:
    • DDoS and worm attacks.
    • Traffic quarantine for a specific target.
    • Blacklist filtering.
  • The most effective way of filtering is as close to the edge as possible or even with at the upstream provider.
  • RTBH has better performance of filtering compared to using ACLs. Filtering is based on destination or source prefixes using host routes set to the Null0 interface.
  • Architectural components:
    • iBGP Protocol - used to distribute filtering information such as host routes. iBGP protocol does not modify the next-hop address within the AS so it can be used to advertise a prefix with a predefined next-hop that points to a static null0 route.
    • Trigger Router - Device closest to the NOC which which triggers the filtering route advertisement with the next hop to an IP address associated with a Null0 destination. Each router should have a static route pointing to the Null0 interface. This route has to have an iBGP session will all the edges or route reflectors within all clusters.
    • Sink -

Destination Based RTBH

  • Filtering is based on the destination network.
  • Trigger router advertises an iBGP update with a special next-hop address designated for null0.
  • Edges have a pre-configured static route pointing to the Null0 interface. This is a host route that is not used within the network, ideally within the RFC1918 address.
  • To start the filtering, NOC adds a static route with the destination of the desired filtering network. That static route is redistributed and sent to all edges.
  • Once filtering is not needed anymore, static route from trigger router is removed.
  • Biggest disadvantage is that all legitimate and malicious traffic is dropped at the edges.

Source Based RTBH

  • Using source based RTBH, only the specified sources are filtered.
  • This option might not work for DDoS with a large set of malicious source, but idea for a simple DoS.
  • This method relies on Unicast Reverse Path Forwarding (uRPF) being configured on edges and the same configuration as destination based RTBH.
  • Uses Loose uRPF checks, where a source only requires a valid interface to be permitted.
  • One specific rule within uRFP checks if the source interface points to a Null0 interface. If it does the packet is dropped.
  • Setting the next-hop to null0 interface is accomplished the same way as with destination based RTBH using iBGP and next-hop of a designated address pointing to null0.

Configuration

Trigger Device

  • Needs some sort of a mechanism to prevent the filtering network from being advertised to eBGP peers as regular advertisement.
    • This can be accomplished by adding the NO-Export BGP community or Local-as if using confederations.
    • Translating it to the eBGP peering blackhole community if supported by upstream ISP. For example Level3 uses 3356:9999 (source [http://onesc.net/communities/as3356/])
  • If filtering networks where they might not be shortest prefixes for example /24s (both regular and filtered route from triggered device have the same prefix-lenght), need to use a more preferred local-preference on the triggered route.
  • To make sure other static added to the trigger router are automatically redistributed for filtering, use a route tag when adding static trigger route. Make sure the redistribute blackhole policy only allow prefixes with that tag defined.
  • Two methods can be used to trigger blackholing:
    • Next Hop Method - Triggering device sets the next-hop to a preconfigured network that always point to a null0 interface on edges.
    • BGP Community - Triggering device sets a specially defined community on the update message. Each edge has a policy to match prefixes with this community value applied and set the next-hop to preconfigured static null route. The biggest advantage of this method is that each edge can independently decide to drop or perform another action. For example you could have a community to drop only peering sessions or IP transit X, instead of all of them. That is useful when knowing where the attack is coming from.

Edge Routers

Drop Location

  • Drop location is the place in the network that drop traffic due to RTBF.
  • Most common drop location is the network Edge.
  • Other drop location include:
    • Core
    • Peering Edges
    • Distributed Layer

Applications of RTBF

  • The most common application of RTBF are:
    • DDoS and Worm Mitigation
    • Quarantine/Redirection of Attack Traffic
    • Blacklist Filtering

DDoS and Worm Mitigation

  • Filtering as described in above sections, based on source or destination (mostly edge filtering)

Quarantine/Redirect of Traffic

  • Instead of dropping all of the traffic redirect it to a sink hole for analysis or for scrubbing.
  • Scrubbing can clear well know detected DDoS patterns and re-inject clean traffic back to the network. Scrubbing can use Arbor TMS or Cisco Gaurd.
  • This this accomplished in the following manner:
    • Edge router have GRE/IP tunnels to the sink hole router.
    • Trigger devices send a prefix with a community set to sink hole.
    • Edge routers match on the community and set the next-hop to an IP address on the other side of the GRE/IP tunnel to redirect traffic to sink hole.

Blacklist Filter

  • Blacklist filtering is used to prevent permanent access to network. This might be because of a worm or other business reasons.

Regionalization

  • RTBF can be triggered for the whole network or for regions.
  • Various method can be used to regional filtering, but the general concept is to assign RTBF communities for each regions. The trigger router sends prefixes with tags that eventually match in one region an not the other.
  • Alternate method would be to use different next-hops advertised from trigger router. The next-hops would point to the static null0 route. Each region would have a different static null0 route.
  • Make sure these updates come from specific ASNs only and not from outside.

Comments

rating: 0+x
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License