It’s been some time since I wrote something. Not because I got lazy but because I’ve been cooking something up in the lab that I just can’t wait to share.

Late Q2, I’ll be publishing a new open-source project called oubliette. It’s a linerate DDoS scrubber, and I promise you, it’s pretty neat.

I’ve been dealing with DDoS attacks for what feels like a lifetime. The ones that always get me riled up are TCP SYN Floods with spoofed IPs.

Why do people even do this?

Honestly, what drives people to just blast networks with bogus traffic?

It’s 2026 and it absolutely blows my mind that lazy ISPs are still not implementing BCP38 correctly. Because of their negligence, attackers can easily spoof their source IPs with zero consequences.

In a typical TCP 3-Way handshake, the client sends a SYN, the server replies with a SYN-ACK, and the client finishes with an ACK. Simple, right?

But in a spoofed SYN flood, the attacker sends an avalanche of SYN packets claiming to be from random, fake IPs. The poor server allocates resources, sends out a SYN-ACK into the void, and waits. And waits. Until it completely falls over :'(.

This broken architecture is a massive pain for anyone trying to keep a service online.

So how do we fix it? eBPF and XDP!

How do we actually fix this without dropping a fortune on proprietary hardware? With eBPF and XDP (eXpress Data Path), of course!

XDP allows us to hook directly into the NIC’s driver, making decisions about packets before they even hit the Linux kernel’s networking stack. It’s ridiculously fast and avoids all the overhead of context switching into userland code.

oubliette relies on a very specific, beautiful quirk of the TCP handshake to filter out the noise.

A beautiful quirk in the TCP Handshake

Here is how the magic happens.

When oubliette sees an incoming SYN packet from an unknown IP, it doesn’t just pass it along. Instead, it crafts a deliberate, erroneous SYN-ACK with an entirely wrong sequence number and sends it right back.

sequenceDiagram
    participant C as Client / Attacker
    participant O as oubliette

    C->>O: SYN
    Note over O: eBPF/XDP Hook
    O-->>C: Erroneous SYN-ACK
    Note over C: Spoofed IP goes to void.<br/>Real IP replies with RST.

If the source IP was spoofed, that wrong SYN-ACK goes nowhere. The attacker doesn’t care, and the target machine’s userland code never even knows it happened. The packet is silently dropped at the NIC level.

But what if it’s a legitimate client?

Okay, but what if it’s a real user?

I don’t blame you for wondering how this doesn’t break everything. If it’s a real user, their TCP stack receives the wrong SYN-ACK and immediately thinks, “Whoa, this sequence is garbage.”

The client will automatically reply with an RST (Reset) packet.

The moment oubliette sees that RST in response to the challenge, it knows the IP is legitimate. It whitelists the IP address.

The legitimized client then automatically and transparently retries the 3-way handshake. This time, since the IP is whitelisted, the traffic flows right through to the backend server.

Does it actually scale?

The short answer is yes. Very much yes.

In my own setup, I rely heavily on hot-potato routing with as many as 7 WECMP/UCMP paths active at all times. You might think stateful packet filtering in a highly distributed multi-path environment is a nightmare, but oubliette scales effortlessly here.

You can simply rack and stack additional oubliette servers side-by-side and let your WECMP/UCMP groups run their course. Because ECMP hashes the flows, it guarantees that the client’s RST reply will hit the exact same oubliette instance that posted the challenge. This means the challenge/response logic remains entirely local to that specific node.

Once an IP is validated, the whitelist state is seamlessly synchronized across the cluster through Redis.

The entire setup is meant to run on semi-commodity hardware. As long as your NICs support XDP, you’re golden.

Let’s look at the routing flows depending on the current state:

1. Normal Operation (No DDoS)

flowchart LR
    I((Internet)) <--> E[Edge Router] <--> D[Distribution Router] <--> S[Server]

2. During DDoS: Challenge Traffic

flowchart LR
    A((Attacker)) -- SYN --> E[Edge Router] -- SYN --> O{oubliette}
    O -- Wrong SYN-ACK --> E -- Wrong SYN-ACK --> A

3. During DDoS: Whitelisted Legit Traffic

flowchart LR
    C((Client)) -- Ingress --> E[Edge Router]
    E --> O{oubliette}
    O --> D[Distribution Router]
    D --> S[Server]
    S -- Return Traffic --> D
    D -- Bypasses Scrubber --> E
    E --> C

By keeping the return path asymmetrical, legit replies from your servers bypass the scrubbers completely.

I’ve been running early lab experiments using SolarFlare NICs, and the results are honestly staggering.

When facing a massive amount of fake traffic mixed in with legitimate flows, the scrubber achieves 99.99% linerate scrubbing.

And the latency? The added delay of that first failed roundtrip is absolutely negligible for the end user. It’s practically invisible.

So let’s see what happens…

I’m incredibly excited to push this out in late Q2 and see how the community tears it apart or improves it.

Building this has been an incredible learning experience, and I can’t wait to see what happens when the community gets their hands on it.