In DDoS Protection, Gcore uses the XDP and regular expressions (regex) package. This article explains why Gcore started using this solution (regex in XDP) and how they linked them through third party engine and API development.

Additionally, we will also explain their open source solution for regex handling in XDP and benchmarking results.

The reason behind using the XDP framework

At the start of their DDoS protection service, they ran on a small number of dedicated servers (nodes) running DPDK (a Linux framework for fast packet processing) and filtered traffic with regular expressions. By using this technology, they have managed to protect their customers’ applications with this pack. However, as the capacity for DDoS attacks increased from 300 Gbps in 2021 to 700 Gbps in 2022, the underlying infrastructure ultimately proved insufficient.

DPDK requires exclusive access to the network card to operate effectively. In this way, integrating it with other uses is extremely difficult (and unreasonable) to the point of being impossible. This requires the acquisition of new dedicated nodes for DPDK if the existing infrastructure is to grow without modification. Gcore concluded that this was not a cost-effective option and set out to find one.

In addition to their DDoS protection services, Gcore also offers Content Delivery Network (CDN) infrastructure consisting of more than a thousand CDN nodes. So it makes sense for them to start using it for content distribution and traffic filtering, because more nodes mean better security against increasingly powerful attackers.

Since DPDK cannot work with CDN nodes (it needs dedicated ones), Gcore opted to use the XDP framework instead. They claim that the main improvement over the previous version is the quality of its integration in the stack with other applications. DDoS protection was previously only available on dedicated servers with DPDK (Fig. 1), but it can now be integrated into CDN servers (Fig. 2), allowing for greater scalability.

Why Gcore finds XDP useful:

• Cost efficiency. The framework can be installed on servers with any edge network application, such as web servers and DNS servers, so it does not require expensive dedicated equipment and developers do not need to spend hours integrating other apps with XDP.
• Attack detection speed. The framework can be installed on hundreds of CDN servers. This means DDoS protection is closer to client applications and sources of malicious traffic. As a result, attacks are stopped faster and do not penetrate deep into the infrastructure.

But it also has several disadvantages:

• Lower performance. Split nodes with XDP have lower performance than DPDK, but due to the incorporation of multiple nodes, the overall efficiency of the solution is ultimately higher.
• Inability to handle regex. XDP doesn’t have a built-in engine to handle regular expressions, so they had to come up with a solution to adapt regular expression processing to it.

Why Gcore continued to use regex to filter traffic

There are two approaches to filtering malicious traffic in DDoS Protection: packet analyzers and regular expression (regex) handling.

Packet analyzers are manually written filters that are programmed to detect and block suspicious activity in applications using a particular protocol. Writing such packet analyzers requires a lot of programming work, especially if DDoS protection needs to be able to quickly accept new protocols.

Regular expression handling based on analysis of packet payloads reduces the time required to create filters compared to the packet analyzer approach. Additionally, it is a more flexible approach that allows packets to be processed more efficiently with less kernel load.

Packets sent to their client applications are checked in two ways:

• Reaction to attacks (manual mode). They analyze malicious traffic generated by a specific payload (pattern). Then create regular expressions that point to that payload and apply it to traffic. All requests containing a similar payload will be automatically filtered.
• Game connection protection mode. Many Gcore customers are online game service providers characterized by queries over UDP protocol and small packet sizes. Packages for game services have a strict structure that can be described using regular expressions. They create regular expressions for each client’s game service and use that to create an allow list of packages. All packets that match regular expressions will be allowed. If the packets differ, they will be blocked.

Packet processing when using regex is organized as follows:

How Gcore adapts regex processing in the XDP context: challenges and solutions

Working with regex is a resource intensive process, and Gcore Claims they will check millions of packets and use regular expressions of different complexity. This led them to conclude that performance is a must-have requirement for a regex engine.

The best engine available is Hyperscan, designed by Intel. It is open-source with a GPL-compatible license, which is fast because it uses an AVX2/AVX512 vector instruction set and is used as an industry standard for DPI applications.

To adapt regex processing in XDP, they encountered several challenges, which are described below.

Challenge 1. eBPF limitations do not allow implementing regex filters as part of the XDP program.

The solution. Gcore has rebuilt the Hyperscan engine as a loadable Linux kernel module providing eBPF helpers. Hyperscan is an engine designed to process regular expressions in DPI (Deep Packet Inspection) systems, checking whether a packet’s payload matches predefined regular expressions.

Challenge 2. Loadable module eBPF helpers cannot be registered for XDP.

The solution. eBPF helpers in loadables were first introduced in Linux 5.16, but registering them for XDP was not possible until Linux 5.18. Because Gcore only had Linux 5.17 during development, they had to provide this capability. Major kernel releases do not require this type of patch.

Challenge 3. Vector (FPU) instructions were not meant to be used when processing packets in the Linux kernel.

The solution. They save and restore the state of the FPU registers when they enter the module for regex processing. They do this on a per packet basis when needed without affecting other packets where regex processing is not required.

What open source solution does Gcore offer to the community: eBPF API to handle regex in XDP

If your infrastructure needs to handle regular expressions in XDP, you can use an out-of-the-box solution provided by their developers instead of starting from scratch.

Their custom eBPF helper ‘bpf_xdp_scan_bytes()’ can now be used in the same way as other eBPF helpers.

struct rex_scan_attr attr = 
    .database_id = regex_id,
    .handler_flags = REX_SINGLE_SHOT,
    .nr_events = 0,
    .last_event = ,
;
err = bpf_xdp_scan_bytes(xdp, payload_off, payload_len, &attr);
if (err < 0)
    return XDP_ABORTED;
return (attr.nr_events > 0) ? XDP_DROP : XDP_PASS

To evaluate the regular expression against the packet buffer, first add a regular expression in the loadable module and reference its identifier when calling the eBPF helper:

1. Create a node using mkdir under /sys/kernel/config/rex
2. Compile the model database:

   echo ‘101:/foobar/’ > patterns.txt
   echo ‘201:/a3.10/’ > patterns.txt
   build/bin/hscollider -e patterns.txt -ao out/ -nl

3. Load the compiled regular expression into /sys/kernel/config/rex//database:

   dd if=$(echo out/".db) of=/sys/kernel/config/rex/hello/database

4. Read or set new regex id in /sys/kernel/config/rex//id
5. Pass the regex identifier to the eBPF program and use it as a helper argument.

The complete source code is available in the Gcore GitHub account by link: https://github.com/G-Core/linux-regex-module

What benchmarks does Gcore have on using regex in XDP

Their DDoS filtering solution is based on 3rd generation Intel® Xeon® Scalable processors and an Intel® 100GbE E810 Ethernet network card. Intel® Hyperscan enabled high performance pattern matching between data streams.

Intel® provided expert information, including the XDP technology used for packet filtering. According to them, using the new software on the latest 3rd Generation Intel® Xeon® Scalable processors increased the filtering capacity from 100 Gbps to 400 Gbps or 200 million packets per second.

In the tables below you can see what the results of their own tests are.

• The linerate (blue line) is the maximum network throughput for 4×100 Gbps interfaces.
• The base (red line) is a measure of how well XDP would have handled it without using regular expressions.
• The last three lines are about package management when using regular expressions.

Conclusion. On a packet size larger than 512 bytes, the system can operate at line speed, effectively filtering traffic. On packets smaller than 512 bytes, the packet rate and pressure for the system is much higher, and the system cannot maintain line rate performance and operates at around 40-50% of the line rate speed. line.

Google Core is really satisfied with these results. According to their data, they are suitable for us even if the performance of processing small packets is lower. Since true DDoS attacks tend to use large packets, the efficiency and speed are acceptable enough.

Tests show that using regex in XDP is fine for processing heavy processes, but fast enough to handle heavy traffic.

Sponsored and written by Google Core