Silverline DDoS Architecture
I wrote on Wednesday about the why and what of F5 Silverline. Today we're going to dive a little deeper into the how of the DDoS service offering. Before we get into the scrubbing architecture itself, let’s take a look at the delivery options for getting traffic to and from the scrubbing centers!
In the proxy configuration, there is no change to your infrastructure required save for the DNS changes that need to be done once the Silverline DDoS service is configured and ready to receive traffic. Let’s start with the diagram.
Walking through the diagram, DNS A records are updated from the local VIPs to the Silverline proxies, and traffic begins flowing through the scrubbing datacenter and then to the customer over the public internet with source NAT-ing from Silverline, resulting in customer server egress traffic flowing through Silverline as well. With this deployment, it is highly recommended to apply ACLs matching Silverline source addresses to prevent direct IP-based attacks that will ignore the DNS instructions to flow through Silverline. One of the benefits of using the proxy scenario is that you can use it with an single IP service, including cloud services like Azure or AWS.
BGP routing was my bread and butter for years. I worked for several different backbone ISPs earlier in my career and I had THE text on BGP from Bassam Halabi (yes, this dates me..) pretty well memorized. This solution leans heavily on BGP to move the advertisement from the customer premises to Silverline so that even an IP-based attack would arrive at the front door of the scrubbing center.
In this scenario, the route is advertised from the scrubbing centers so traffic will come to the nearest one. Once the scrubbing has occurred, the traffic leaves the scrubbing center with the original source IP and transits a GRE tunnel to the customer premises, is handed off to the server, and then egress traffic returns to the original client source over the public internet with no need to be passed through the scrubbing center on the return trip. This can save on latency, but does require that customers control (read-can advertise) a /24 network as ISPs typically will not pass smaller blocks across peering points. Not too challenging for most enterprises, but usually a show-stopper for cloud services.
The Combo Meal: Routed + Proxy Configuration
This final scenario is a combination of the routed and proxy configurations. The DNS changes push the front door to Silverline, and the route advertisement is moved from the customer premises to the back end of Silverline, eliminating the need to manage ISP ACLs to avoid direct IP attacks locally.
Note that the traffic is sent across the GRE tunnel to the customer datacenter server infrastructure like the routed configuration, but returned not to the original client but the back end of the Silverline datacenter and then passed back to the original clients like the proxy configuration.
Aye, There’s the (Sc)rub
I know, terrible Shakespeare reference. But stay with me, we’re getting to the good part! I’ll let this diagram do most of the talking:
There is quite a bit of intelligence in the inspection plane. At each stage of the scrubbing, various tools and monitors are reporting and acting on traffic at layers 3 through 7 on a variety of protocols. Notice the vertical paths from inspection to data plane, informing and acting at each layer, and the malicious traffic flows starting to drop off at each mitigation zone before finally reaching the back end of the scrubbing center where the policies/rules get clean traffic where it needs to go.
And there it is, the architecture for the exciting and powerful Silverline DDoS service. The best part? It’s not just a mindless service acting in isolation, there is a most excellent SOC staff of talented F5ers watching over your applications, working directly with you to mitigate the attacks and defend your applications. If you haven’t checked out Silverline DDoS for your applications, schedule a demo today!