Increasing accuracy using Bad Actor and Attacked Destination detection

Dear Reader,

In this article, I will return to the mitigation layer of static DoS vectors once again. Before I want to go to the next layers within subsequent articles, I would like to discuss some options I haven´t touched on regarding DoS vectors so far.

It is a functionality that helps to massively lower the chance of a false/positive when using static vectors. It also is the base of another mitigation technology we can use as the very first mitigation withing the hud-chain. This can be done by either using RTBH (Remote Triggered Black Hole) routing, Flowspec before the BIG-IP, or IP shunning (dropping on IP level at the speed of line) on the BIG-IP. I am talking about “Bad Actor Detection” and “Attacked Destination Detection”.

Bad Actor Detection

In my previous article “Explanation of F5 DDoS threshold modes”, I outlined the different Threshold modes: Fully Automatic, Auto Detection/Multiplier Based Mitigation, and Fully Manual, but I didn´t talk about the other options you can configure per vector.

The two I want to explain now are the “Bad Actor Detection” and the “Attacked Destination Detection” options.

Back in my first article “Concept of F5 Device DoS and DoS profiles”, I described that the idea of static DoS vectors is to lower the number of attack packets going into the BIG-IP (CPU) and to the services which need to be protected by BIG-IP. This is done by dropping these packets in a very early stage, ideally via a dedicated hardware chip (FPGA). It is like having the F5 TMOS operating system with all its smartness and feature-reach capabilities, but in front of it, there is a DDoS device protecting it. But, the beauty here is, that it is all in a single device and interacting with each other.

Figure 1: DDoS Mitigation Order

Anyhow, when the CPU detects the attack via a static vector and the mitigation threshold is reached, it programs that vector into the FPGA for mitigation. When you run DDoS protection on a BIG-IP VE, then of course the mitigation will be still done in software (CPU), but on a very early stage of the hud-chain as to not “waste” CPU cycles for additional functionalities.

At this point, I would like to recommend the article of my colleague Ryan Howard, “Mitigating 40Gbps DDoS Attacks with the new BIG-IP VE for SmartNICs Solution”, who posted on the option to offload DDoS mitigation from a BIG-IP virtual edition into the FPGAs sitting on a network card (smartNIC). This works especially well in the “new” modern world of highly virtualized environments, with the capability to do DDoS mitigation in hardware without having a dedicated device.

Using static DoS vectors has the strong advantage that they kick in within microseconds and protect the BIG-IP itself (Device DoS) or the service/network behind the BIG-IP via DoS profiles attached to protected object/virtual server configurations. When the attacker is using invalid packets like a bad header, then the FPGA has enough information to block exactly those bad packets. But when it is for example a TCP PUSH/ACK flood, then there is a chance of false/positives, because you do have many, many TCP PUSH/ACK packets within your legitimate traffic and the FPGA cannot differentiate with only the information of protocol “TCP” and flag set “PUSH/ACK”. This is why BDoS is a powerful functionality running in parallel, but executed before the static vectors from the hud-chain perspective.

But, if you can add information about the attacking source IPs (bad actors) and/or the information about the IPs being under attack (attacked destination), then you can potentially lower the chance of a false/positive. Or, at least you lower them to the IPs being involved in the attack rather than having to mitigate on a global level.

When you enable “Bad Actor Detection” on a vector and you use the “Fully Automatic” threshold mode, then the BIG-IP will automatically identify the “heavy” source-IP(s) causing the high load and will do the mitigation for that vector only on that source IP(s).

Figure 2: Fully Automatic Bad Actor Detection

Of course, if the attacker uses randomized source IPs and sends a different source IP with every packet, then it will not work. But it does work very well for example on Reflection and Amplification attacks, where specific DNS, LDAP, or NTP servers are being used for sending the attack traffic. These IP addresses can get easily identified and get used to driving a higher accuracy on the static DoS vector mitigation. In one of my next articles, I will also explain what else you can do with this bad actor IPs by using the “Add Source Address to Category” function.

If you choose the manual threshold configuration, then you can define your own thresholds for detecting bad actors and at which level you want to mitigate them. 

Figure 3: Manual Bad Actor Detection

Attacked Destination Detection

The next option that you can configure on the static vector is the “Attacked Destination Detection”. Here it works in the same way as on the “Bad Actor Detection”. But, using “Fully Automatic” mode, the system will automatically identify which IP(s) are under attack and will add them to the attack traffic definition.

 Figure 4: Fully Automatic Attacked Destination

This is very helpful on the Device-level protection of the BIG-IP, because as you know here the BIG-IP counts all packets into the specific vector which “hits” the device. It doesn´t matter if it is on a self-IP, a service behind the BIG-IP, or something else. If the BIG-IP must deal with it in any way, it will get counted.

Now let us assume an attacker starts a strong TCP PUSH/ACK packet flood against a service located behind the BIG-IP. As discussed in my article “Demonstration of Device DoS and Per-Service DoS protection” we know this flood will never hit the service, because the BIG-IP is a stateful-device (at least this is the recommended configuration, whenever possible). Therefore, all TCP packets not belonging to an existing connection will get dropped at the latest by the state engine. We also know, when the vector is configured in “Fully Automatic” mode, the mitigation will start when we see more packets/sec as the detection rate has calculated and the stress on the BIG-IP (CPU) gets too high. Let us imagine now that the flood is so strong that the mitigation starts and would be executed on all PUSH/ACK packets hitting the BIG-IP, it could lead to false/positives. But when “Attacked Destination Detection” is enabled, then the mitigation will only be done on PUSH/ACK packets targeted for that IP address (or IP addresses) being under attack. Therefore, we will only see false/positives for the destination(s) being under attack. If bad actors are also involved, then the attack mitigation will only be done on TCP PUSH/ACK packets coming from the bad actor(s) and targeting the attacked destination(s).

Of course, there is still a chance of a false/positive, but keep in mind this is the first mitigation that kicks in extremely fast and then the granular Behavioral DoS mitigation will take over.

I usually recommend enabling “Attacked Destination Detection” on the Device Protection for all vectors which do not cover “bad header” packets, because they are broken anyway and will not get forwarded. But, on all others, I want to differentiate if a packet belongs to a destination that is under attack or not.

On the PO/VS DoS profiles, I usually only enable it on network wildcard PO/VS, because on these objects we have multiple destinations. Not like on PO/VS which covers one IP.

I hope that this article gives you a little better inside into the two options available for configuring a DoS vector.

My next article will cover another layer of Network DoS mitigation: Cookie-based DoS protection, which gives you HW accelerated and granular DoS protection on different attack vectors.

Thank you, sVen Mueller