Context-Aware DDoS Protection with aXAPI
In a complex infrastructure the system state is rather fluid. Addresses, hostnames, routing, availability and health of services change frequently. As a result, any device designed to “protect” this system needs to react to the dynamic state change to be effective.
One of the goals of A10 Thunder TPS is to keep the system immediately informed of any pertinent changes in service state. With this dynamic context awareness, A10 provides first-class DDoS protection. In this post we will give you a high-level overview of this concept and how we apply it to TPS.
Aside from the RESTful API that ACOS brings to TPS (which will be covered in other posts) there are a few dynamic mechanisms TPS can use to learn the following.
- Destinations and services to be protected
- Sources to apply policy to (white/black/grey lists)
- Content to apply policy to (hostnames, URI, etc)
As an introduction to these, I will describe learning destinations and adding the appropriate policy using BGP. TPS allows me to create a “Policy Peering” of sorts. This allows TPS to hear an update from the peer and instead of adding it to the RIB/FIB, this prefix information is sent to the TPS DDoS application.
To demonstrate, I have snippets of a configuration below.
ip community-list 1 permit 101:50
#I define a community which TPS will listen for
!
router bgp 1
bgp router-id 1.1.1.1
#local TPS BGP information
neighbor 2.2.2.2 remote-as 2
neighbor 2.2.2.2 description policy-peer
neighbor 2.2.2.2 acos-application-only
#”Policy Peer” definition seen here as “acos-application-only"
neighbor 2.2.2.2 route-map protection-context in
#now we add the route-map we see below to process
#inbound prefixes received from the policy peer
!
route-map protection-context permit 1
match community 1
set ddos zone protected-servers
#much like any BGP aware system we create route-maps to
#control policy. The difference here however is we have
#added A10 specific set statements. The one I show here
#is “set ddos zone.”So, what does this all mean? Well, now we have the ability to make protection extremely dynamic. TPS will add a prefix to the appropriate zone immediately upon hearing the announcement. TPS will also remove it based on hearing the withdraw (after a wait state, of course).
Now, this is just the tip of the iceberg, so to speak. Here is a very basic representation of a DDoS “zone” and how context fits in to it. On the TPS, the configuration for the zone then looks like this:
ddos dst zone protected-servers
#The name of our zone
operational-mode monitor
from-l3-peer
#command to allow the route map to add prefixes
#directly to the zone
port 53 dns-udp
level 0
indicator pkt-rate
zone-threshold 1
#Very basic DNS protection example with a static PPS thresholdAt this point, any route received from the policy peer that has the community 101:50 attached will be added to this zone and will inherit this very basic DNS policy. I will go much deeper into DNS policy in later posts.
Seeing is believing.
Schedule a live demo today.