SCAMMERS ALERT READ THIS ASAP!
SS7

Gcore’s regular expressions are used to stop DDoS attacks

Posted on by ss7

regular expressions and regular XDP in DDoS Protection. This article will discuss why Gcore began using this solution (regex within XDP), and how they tied them together via an API and third-party engine.

We’ll explain the open-source method they use to handle regex in XDP, benchmarking and other results.

The XDP Framework is used.

They used a limited number of servers to protect their DDoS service. These nodes were running DPDK, a Linux framework that speeds up packet processing. Regular expressions filter traffic. This technology has allowed them to protect their client’s apps. The underlying infrastructure was eventually insufficient as DDoS attacks grew in power from 300 Gbps to 700 Gbps between 2021 and 2022.

DPDK needs network access in order to work effectively. It is impossible to integrate it with other applications. If the infrastructure needs to continue growing, it is necessary that DPDK acquires new dedicated nodes. Gcore decided that this wasn’t a viable option, and began to search for one.

Content delivery networks (CDN) infrastructure that includes over 1000 CDN nodes. It makes perfect sense to use it for traffic screening and content distribution.

Gcore chose to utilize the XDP framework, as DPDK is not compatible with CDN nodes. The main difference between the new version and the old one is the integration with other applications. DDoS protection was only possible on servers that had DPDK (Fig. DDoS Protection was previously only available on dedicated servers with DPDK (Fig. This allows for increased scalability.

Fig. 1 DDoS Protection using dedicated servers (DPDK).

Source. Gcore

Fig. 2 DDoS protection integrated into CDN servers. (XDP).

Source: Gcore

Gcore thinks XDP is useful

  • Efficiency. It is cost-efficient. Developers don’t have to spend hours integrating with XDP.
  • Fast attack detection. This framework is easily installed on many CDN servers. DDoS Protection can be installed on hundreds of CDN servers. This means it is easier to protect client applications as well as malicious traffic. Attacks are therefore stopped more quickly and do not penetrate the infrastructure.

However, it has its drawbacks.

  • Low performance. Separated Nodes with XDP perform less than DPDK but, because there are more nodes in the solution, it is overall more efficient.
  • Unable to handle regex. XDP does not have a built-in engine that can handle regular expressions. They had to find a way to modify regular expression processing.

Gcore uses regex to filter traffic

Two methods can be used to filter out malware in DDoS protection: using packet parsers or handling regular expressions (regex).

These packet parsers can be manually programmed filters to block or detect suspicious activity within applications that use a specific protocol. This is a complex task, particularly if you need to quickly be able accept new protocols.

The time required to make filters is significantly reduced by using regex that’s based on analysis of packet payloads. It’s also more flexible and allows packets processed with lower kernel loads.

Two modes of checking packets sent to customers are used for their applications

  • Manual mode of response to attacks They analyse malicious traffic that is generated by a particular payload (pattern). They then create regular expressions that refer to the payload, and apply them to traffic. Requests that have a similar payload are automatically blocked.
  • Game connection security mode. Most Gcore clients use the UDP protocol to send small packets. Regular expressions can describe the structure of packages that are sent to gaming services. The regular expressions are created for every client’s gaming service. These expressions then serve to establish an allowed list of packets. Any packets matching regular expressions are allowed. They will be rejected if they differ from the regular expressions.

When using regex, packet processing is done as follows

  1. Dissector. Each packet is analysed and divided into headers.
  2. Flow Router. The Flow Router routes packets to traffic protection profiles. This is an example of a set of rules that can be used for protection.
  3. Policy Pipeline. Special rules are applied (countermeasures), to disassembled packets into their components. Regular expressions are one countermeasure.
  4. Verdict. Blocks or skips a packet that is based on countermeasure check.

Gcore’s adaptation of regex processing to the XDP context. Challenges and Solutions

Working with regex can be resource-intensive. that they will check millions of packets to find regular expressions of various complexity and then use them. They concluded that regex engines must have performance.

Hyperscan is Intel’s best-selling engine. This engine is open-source and compatible with GPL. It is also fast due to its AVX2/AVX512 vector instructions set.

They had to adapt regex processing within XDP. These challenges were described below.

Challenge 1. The limitations of eBPF prevent regex filters from being used in the XDP program.

Solution. Gcore made the Hyperscan module loadable Linux kernel module available with eBPF assisters. Hyperscan, an engine that processes regular expressions in DPI systems (Deep Packet Inspection), checks if the packet’s payload matches predefined regular expressions.

Challenge 2 eBPF Helpers from loadable Modules can’t register for XDP.

Solution. Linux 5.16 introduced eBPF-helpers for loadable modules, but registration was only possible in Linux 5.18. Gcore had Linux 5.17 at the time of development so they needed to offer that option. This kind of patching is not required for mainline kernel builds.

Challenge 3 FPU instructions were not meant to be used in packet processing within the Linux kernel.

Solution. As they go into the module to process regex, they save and restore FPU registers. This is done per packet, without any effect on other packets that don’t require regex processing.

Gcore offers an open-source solution to its community. eBPF API that handles regex in XDP

Instead of starting from scratch, you could use a pre-made solution that XDP developers have provided to your infrastructure.

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) ? XDP_DROP : XDP_PASS

First, add a regex to the loadable module. Then reference the identifier in the eBPF Helper.

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

    echo '101:/foobar/' > patterns.txt echo '201:/a3.10/' > patterns.txt build/bin/hscollider -e patterns.txt -ao out/ -nl
  3. Upload compiled regex to the /sys/kernel/config/rex//database:

    dd if=$(echo out/".db) of=/sys/kernel/config/rex/hello/database
  4. Read or set a new regex identifier at /sys/kernel/config/rex//id
  5. Transfer regex identifier into eBPF program, and use it as a helper argument.

The full source code is available in the Gcore GitHub account by link:

Gcore has what benchmarks for regex use in XDP.

The DDoS filtering system is based upon 3rd Generation Intel(r), Xeon (r) Scalable processors, and 100GbE Intel Ethernet Network Adapter E810. Intel Hyperscan enabled pattern matching at high performance across multiple data streams.

Intel(r), which provided expert insights, also on the XDP technology used to filter packets, offered their expertise. They claim that the use of the new software with the latest Intel(r), Xeon(r), Scalable processors has significantly increased filtering capability from 100 Gbps up to 400 Gbps, or 200,000,000 packets per second.

Below are the tables that show the results from their testing.

  • Linerate (blue) refers to the maximum network throughput for 4×100 Gbps interfaces.
  • Base (red line) indicates how XDP could have dealt with it without regular expressions.
  • These are the packet handling lines when regular expressions are used.

Conclusion. The system is able to operate at the speed of the line rate for packets larger than 512 bytes. This effectively filters traffic. The system cannot perform at linerate speed for packets less than 512 bytes. Instead, it uses a higher packet rate and pressure.

is truly satisfied with the results. Their data shows that they are suitable for us, even though small packet processing speeds may not be as good. DDoS attacks are known to attack large numbers of packets. This makes the speed and efficiency acceptable.

According to tests, XDP can handle heavy processing but has sufficient speed for large volumes of traffic.

Written and sponsored by

ss7