Stateful Mitigation: The Importance of it, and How Path Has Excelled In Providing it

What is state?

When we talk about "state", it refers to information maintained about a particular sequence of packets. This is usually done by tracking identifiers, including but not limited to, source and destination IP addresses and ports. When a packet arrives, a lookup can be done in the connection table to identify whether or not the packet belongs to an existing connection. State is already present in many different use cases. Transmission Control Protocol (TCP) is a connection-oriented, transport-layer protocol that requires a three-way handshake before two end devices can communicate. When the SYN ("synchronize") packet is received, which is the first step of connection establishment, resources must be allocated in order to "remember" the client (state). In our case, we would like to discuss how it fits in with DDoS mitigation.

Why does it matter?

Usually, DDoS attacks can be mitigated by blocking traffic with distinct attributes from legitimate traffic. This may include invalid values that do not comply with the protocol. For example, TCP headers can carry flags, but only some combinations make sense and are thus permissable to be used by applications. The SYN bit is used during connection establishment, whereas FIN is used to terminate connections. Given this information, it doesn't make sense that both would be used at the same time. SYN-FIN packets can effectively be blocked without the risk of dropping any attacks. This bears the question: So why does stateful mitigation matter?

Unfortunately, this is not always the case. For more sophisticated attacks, DDoS traffic cannot simply be filtered out by inspecting packet characteristics. In this case, we cannot decide whether or not a packet should be dropped without knowing how the packet in question relates to previously sent traffic. This is where state comes in. Using stateful mitigation, we can block these packets originating from DDoS attacks that are indistinguishable from legitimate traffic.

The most common vectors

You may be wondering what these sophisticated attacks that demand stateful mitigation are. Below, I cover some of the possible strategies that an attacker may use to overcome a DDoS mitigation deployment that either is not stateful or does not implement state well enough.

SYN-ACK floods

A SYN-ACK packet is the second step in TCP's three-way handshake. In a client-server model where the client is the one initiating a connection, the server would reply to the client with a SYN-ACK ("synchronize acknowledgement"). A SYN-ACK flood is where an attacker tries to saturate a host's resources by sending these packets at a high rate, with the intent to overwhelm the system or network. As these orphan SYN-ACK packets arrive at the server, it has to try figuring out why it is receiving this out-of-state traffic. With a large number of these packets arriving quickly, the system will be too busy trying to deal with the malicious traffic that it will not be able to handle legitimate traffic. Even for small deployments of stateful firewalls, this is challenging to mitigate. The stateful module must do a lookup to check if the packet that arrived belongs to any existing connection. Depending on its processing power and the solution being used, this may be significantly better, but still not ideal.

There are two different ways for an attacker to conduct a SYN-ACK flood. The first one involves using a botnet, and having all of the infected devices (often referred to as "bots", "slaves", or "zombies") send forged TCP SYN-ACK packets to the target. With a large number of bots at the attacker's disposal, he is able to quickly overload the target with more traffic than it can handle.

Another method, which has become more prominent over the past year, is referred to as TCP reflection. In this attack, the attacker sends forged TCP SYN packets to a legitimate server. These forged packets have the source IP address spoofed to that of the victim's. Once the spoofed SYN packet arrives at the server, it has no way of knowing that the source IP address stored in the IP header does not actually belong to the sender. The server replies to the host with a SYN-ACK packet. In this case, the host is the victim, and it receives unwanted traffic from a completely legitimate device. This is called reflection because the attacker has used another host to bounce its request off of, and from there reflected it to the victim. When this is happening tens or hundreds of thousands of times per second, the target can easily be flooded with too much attack traffic that it cannot accept legitimate traffic, thus causing a Distributed Reflected Denial of Service (DRDoS). The most common devices to be used as reflectors (the hosts bouncing the traffic to the victim) are usually webservers, but it can also be SMTP servers or any other TCP service.

ACK floods

Much like a SYN-ACK flood, these out-of-state TCP packets are used to confuse a host and consume resources by sending packets that do not belong to any existing connection. We will not go into too much detail about ACK floods because they work very similarly to SYN-ACK floods, except there is only one sensible way of launching these attacks. Like most other attacks, a botnet is used to send crafted TCP ACK packets from a large number of infected IoT devices.

UDP floods

We've covered the ways that TCP's three-way handshake can be abused in order to harm other networks on the Internet. What about other protocols?

With most UDP-based attacks, they are fairly straight-forward to mitigate. For UDP amplification, one may choose to rate-limit common amplification vectors, such as Memcache. With generic floods sent from botnets, DDoS traffic can usually be dropped by identifying the common attributes that distinguish it from regular traffic. As we've said, this is not always the case, and with a connectionless protocol that is often taken advantage of in order to launch attacks, UDP is no exception.

Let's look at some traffic coming from clients on a game server.

Now let us examine a DDoS attack sent to the same type of game server.

Whoah, which is which?! By examining these two separate samples of traffic, we have no way of telling which is the legitimate clients, and which is the DDoS attack! With an attack that is focused enough, the attacker may tailor it to appear very similar to regular traffic for that particular service. This calls for advanced stateful mitigation in order to make a decision on the packet based on previous traffic.

How Path handles stateful mitigation

Many DDoS mitigation providers fail to mitigate such sophisticated attacks; signature-based DDoS detection cannot recognize certain floods, and legitimate client traffic can often be dropped in the process of mitigating such attacks. Game servers are particular prone to complete disaster even from a small attack, and especially if the mitigation service is causing packet loss for clients. Path has deployed a completely stateful firewall in order to block even the most advanced types of attacks, including but not limited to, SYN, SYN-ACK, and ACK floods. When a DDoS attack is imminent, our 2.8 Tbps global network kicks in to filter out all forms of attacks, whether or not state is required in order to mitigate them. More recently, we have introduced application filters, which filter out traffic at the edge that does not confine to the service that the user wants to protect. You can read more about Path's application filters here. All of these filters are stateful, meaning we can not only prevent traffic that does not interest the application, but also traffic that doesn't make sense for the application to receive given the current state maintained about a particular host.

The majority of products used to protect our network against DDoS attacks are implemented using eBPF and XDP for bare-metal packet processing speeds, and only top-tier enterprise-grade hardware is used in order to achieve bleeding-edge performance.