Application Filters Using eBPF/XDP

"Work smarter, not harder" is a motive that the engineers at Path stand closely by, which is why we are re-envisioning DDoS (Distributed Denial-of-Service) mitigation techniques in unprecedented ways using the power of eBPF and XDP. Our latest addition to the stack, known as filters, allows a customer to seamlessly receive protection against a multitude of different attacks, both known and unknown, at the click of a button.

How eBPF and XDP work

If you are not familiar with what eBPF or XDP is, we provided a brief introduction to this fairly new technology in a previous blog post. Essentially, it allows one to programmatically filter out packets at very high speeds. Large companies such as Cloudflare and Facebook are already leveraging its flexibility to squeeze as much performance as possible out of their systems.

Addressing current DDoS mitigation solutions

The most prominent way to defend against DDoS involves deploying rules to block commonly known attacks. These solutions often base their stack heavily off of sequential filtering, where a chain of rules are implemented. Every time a packet arrives, the packet must traverse through every rule one-by-one until it hits a match. This approach will linearly increase how expensive it is to filter a packet, and limits scalability as the rule-set grows. iptables, a user-space program to filter packets in the Linux kernel, is one of the biggest culprits, and yet it is immaculate as to how many companies still put this software behind the wheel to drive their DDoS mitigation.

Another concern is where the packet filtering is done. Many services use "scrubbing centers", which involves rerouting traffic far away in order to mitigate attacks, and thus decreasing performance. In certain scenarios, the overhead of these expensive diversions may impact the network almost as badly as the attack would have.

More fundamentally, the issue lies in the mindset. With the Internet constantly growing and evolving, attackers are not too far behind. New DDoS attacks are on the rise everyday, and despite best efforts, it is impossible to keep track of every single one. This bears the question as to how traditional DDoS mitigation providers will handle attacks that they have yet to encounter.

Where application filters fit in

Using firewall rules, it is often difficult to express exactly what the user would like. Typically, the most granular level of control you can receive involves being able to filter at the transport layer, which only includes UDP and TCP. While this is great for blocking poorly coordinated attacks by blocking or restricting traffic on ports, it is not enough.

For instance, let's say you have an OpenVPN server running on UDP port 1194. If UDP traffic on no other ports is required, it may look like this:

In the event that a UDP-based DDoS attack targets a port other than 1194, this solution will work fine. However, what will this ACL (Access Control List) do when an attacker targets UDP port 1194? It'll allow it! This isn't necessarily the fault of your firewall for doing something other than it was told; it provided exactly what was requested. The problem is that the user does not have a fine enough level of control to properly represent what is required. What we would like to express is that all OpenVPN traffic should be permitted on this port, not all UDP traffic. With how many DDoS attacks abuse the connection-less properties of UDP, permitting all of it is simply unacceptable. So how do we make decisions on packets that are as precise as possible? The answer: application filters.

At Path, we've eliminated those frustrations. Using eBPF/XDP, application filters are deployed at the edge of the network for an ever-growing number of protocols. As soon as a filter is applied, all traffic going to a specific service passes through this application filter, where the software ensures that each packet confines to the conventions that the application uses. This is done through careful research to discover what distinguishes a packet belonging to the application we would like to protect from any other packet. All of our application filters use stateful packet filtering to block even the most advanced types of floods. Clean traffic passes through seamlessly, while malicious or unauthorized packets are rejected; all without any intervention required, or the possibility that client traffic may get dropped in the process. We've currently created application filters for a various number of different services, including OpenVPN, TeamSpeak 3, TLS, and more!

The results

Since the initial release of our application filters, clients have benefited from an unmatched level of resilience against DDoS, whether they be volumetric attacks, low-bandwidth application floods, or anything in between! Path's application filters are not only a more logical way of providing packet filtering, but they are also very efficient, highly scalable, and more future-proof. Path plans to continue the expansion of this technology, as our infrastructure becomes more modular.