PyCon Hong Kong 2025

Introduction:
In recent years, Distributed Denial of Service (DDoS) attacks targeting previously compromised injected websites have become increasingly prevalent. This trend poses a significant threat to Indonesian web infrastructure, particularly domains under the .id top-level domain associated with governmental or institutional organizations. Unlike attacks that rely on specific Layer 7 pattern - such as SQL Injection or Cross-Site Scripting (XSS) - these DDoS attacks exploit volumetric or stateful protocol-layer weakness (e.g., OSI Layer 4 and Layer 7) without leaving standard application-layer signatures. Consequently, conventional Web Application Firewalls (WAFs) often fail to detect or mitigate the threat effectively, and attempting to do so can result in excessive resource consumption on the WAF itself. Mitigating such attacks typically requires volume-based or stateful traffic analysis tools capable of distinguishing between legitimate requests and malicious traffic patterns. While low-volume Layer 7 DDoS attacks may still be managed at the origin server level, doing so risks overwhelming the server’s firewall and web server stack - particularly when filtering rules impose high latency loading time then require the web server to have health checks that resulted in reload or restart. If the health check of the web server causes too many restarts it could have a bad effect on the site.
Another commonly used defense mechanism is BGP Flowspec, which enables volume-based traffic analysis and filtering at the network level [1]. While effective against high-bandwidth volumetric attacks, this method has limitations - it cannot mitigate stateful DDoS attacks that exploit the stateful connection layer 4 request. In such cases, traffic must be redirected to scrubbing center, where more sophisticated inspection and mitigation are performed. To execute filtering at these centers, one of the most advanced and increasingly adopted technologies is eBPF XDP (eXpress Data Path). XDP enables high-performance packet processing in the Linux kernel, allowing packets to be intercepted at the NIC driver level, thus avoiding unnecessary transitions to user space for blocking. This results in faster, more efficient mitigation [2].
XDP works by attaching hooks at low level in the network kernel stack, enabling the implementation of custom filtering logic using eBPF. However, most BGP Flowspec and XDP integrations are designed to protect specific IP addresses, not domain names. This approach is therefore unsuitable for organizations that do not own BGP Flowspec-enabled routers or need filtering on domain names. Furthermore, deploying this infrastructure solely to block domain-based attacks may lead to unnecessary overhead and resource use.
Instead of relying on BGP Flowspec in combination with XDP, this paper proposes an alternative approach that integrates domain name resolution via DNS, reverse proxy-based WAF, and XDP filtering using the bpfilter tool. By leveraging DNS resolution, domain-specific DDoS attacks can be mitigated without the need of BGP-based redirection. In this model, DNS is used to reroute targeted domain traffic to a reverse proxy server that is integrated with bpfilter XDP rules for rarely-stage packet filtering.
Furthermore, widely adopted reverse proxy WAF - such as Safeline or BunkerWeb - can be configured to route clean traffic to appropriate origin server after initial filtering. This layered approach not only enables domain-focused filtering at the kernel level, but also reduces the computational burden on the reverse proxy WAF by offloading early blocking to XDP. As a result, DDoS attacks against specific domains can be handled more efficiently with lower resource consumption, without requiring access to advanced routing infrastructure such as BGP Flowspec.
Methodology:
To effectively mitigate DDoS attacks on specific domains, a volume-based traffic analysis system-similar in function to BGP Flowspec-is required. However, instead of implementing full-scale, low-level volume analysis mechanism, this solution adopts a simplified version that minimizes complexity and avoids kernel-level development.
Before detailing the meethod, the following are the key components that make up the solution:
- Volume-Based Analysis Tool at the origin server, which detects volumetric attacks and uploads attacker IPs to a centralized IP list (“Bucket IP List”).
- DNS A Record Redirection, pointing the targeted domain to a Reverse Proxy WAF (e.g. Safeline).
- iplist_to_bpfrule Linux Service, which executes a Python script to pull thousands of attacker IPs from the central Bucket IP List
- bpfilter XDP tool and service, responsible for enforcing the ruleset at the kernel level using XDP_HOOK
- safeline WAF as it's reverse proxy WAF
The Volume Based Analysis Tool runs on the origin server and monitors resource-intensive, volumetric HTTP behavior. In its original implementation, it blocked detected attacker IPs directly using the server’s firewall. However, as the volume of malicious IPs grew, this approach became problematic - it caused excessive rule loading and triggered frequent restarts due to health check failures.
To address this, this tool was redesigned to offload blocking to a reverse proxy layer. Once the attack threshold is surpassed, the origin no longer performs direct mitigation. Instead, it uploads the identified attacker IPs to cloud bucket (the “IP List”) and switches the targeted domain’s DNS A record to point to pre-configured Reverse Proxy WAF server.
The reverse proxy server (e.g., Safeline) forwards clean traffic to the origin server, while the initial filtering of malicious requests is handled at the kernel level using bpfilter XDP ruleset. In front of the reverse proxy, the bpfilter tool combined with iplist_to_bpfrule service dynamically injects XDP_HOOK rulesets based on attacker lists fetched from the bucket. This functionality is driven by iplist_to_bpfrule service, a Python-based daemon that periodically pulls new IPs and applies them to the ruleset using bpfilter.
This architecture allows for efficient L3/L4 blocking, reduces the resource burden on the WAF, and eliminates the need for high-cost BGP or scrubbing center infrastructure, making it suitable for smaller-scale or budget-conscious environments.