I’ve been getting some very valid questions over the last few days about oubliette and what exactly the TCP Challenge/Response mechanism protects against. It seems I might have been a little too vague in my initial excitement. Let’s clear the air and look at the actual bounds of this protection.

What it does and doesn’t do

To put it plainly: we are not protecting against spoofed real IPs (IPs that are actively assigned to online machines).

If an attacker spoofs a SYN packet using an IP belonging to an active machine, our edge node will send the garbage SYN-ACK to that real machine. And what does a real machine do when it receives an unsolicited, nonsensical SYN-ACK? It sends an RST right back. Our edge sees the RST, validates the challenge, and whitelists the IP. The attacker is then free to use that spoofed real IP to bypass the challenge and hit the backend.

So, what are we protecting against? We absolutely protect against spoofed IPs that are not online, unannounced, or unrouted. When the edge challenges those IPs, the SYN-ACK just vanishes into the void. No RST comes back, and the traffic is dropped at the NIC.

Why this changes the game

The core idea here isn’t to magically solve every spoofed packet. Instead, it’s to radically reduce the traffic flow hitting your origin servers.

Origin servers can’t be expected to have multiple hundreds of gigabits of interconnect capacity. It is far more likely that a website or service is hosted on 10G or 25G pipes nowadays, not 400G or 800G.

However, a single oubliette box can easily be equipped with 100/400/800G NICs and placed completely inline to handle the scrubbing for an entire fleet of origin servers.

Think of it as a massive sponge. oubliette filters out a massive chunk of the attack: the union of the set of IPs that don’t reply to the challenge, and the set of IPs that do reply but don’t send subsequent SYNs.

A Volumetric DDoS must now satisfy a much higher bar. An attacker doesn’t just need 10/25G of SYN-only packets. They specifically need 10/25G of SYN packets from real IPs that actually reply to the RST challenge. That drastically reduces the pool of usable attack vectors. And for the trickle of spoofed real IPs that do make it through the scrubber, the origin server can employ SYN-Cookies as a second line of defense to easily brush them off.

Okay, what about UDP?

With the TCP state machine now more or less handled by this centralized scrubbing layer, we can focus our efforts entirely on UDP Reflection and volume-only attacks.

oubliette is designed to cover common UDP Reflection attacks too. Because we’re operating in the eBPF/XDP layer, we have direct access to the raw packet payload before the kernel even wakes up. We can parse UDP payloads at line rate to look for classic amplification footprints, like massive influxes of DNS ANY responses, NTP monlist replies, Memcached stats, or SSDP garbage.

If a UDP packet matches a known reflection signature, or if it doesn’t align with an expected inbound flow, we nuke it instantly at the NIC. The real beauty of using eBPF here is agility. If a new amplification vector emerges, we don’t need a kernel patch or a heavy service restart. We just push updated signature maps from userspace, and the XDP hook begins dropping the new vector in milliseconds.

Centralizing the Edge

Traditionally, surviving massive floods meant overprovisioning your entire network path from edge to top-of-rack. It’s an incredibly expensive nightmare.

This centralized model isn’t a completely new concept. It is exactly why the industry moved to centralized stateful Firewalls decades ago. You don’t put heavy traffic inspection on every single backend server; you put massive iron at the perimeter to protect the soft interior.

But unlike an “always-on” inline firewall that constantly inspects everything, oubliette is designed to be purely surgical.

We don’t need to force all daily traffic through the scrubbers. Instead, individual target IPs are dynamically rerouted through the oubliette cluster strictly on-demand. By containing the blast radius at the edge, your inner network can be cost-effectively sized for actual, legitimate peak traffic. When the attack stops, the routes are withdrawn, and traffic returns to the shortest path.

To make this completely hands-off, I’m currently working on native integrations with FastNetMon. The goal is simple: FastNetMon detects the volumetric anomaly, automatically announces the targeted IP via BGP to swing ingress traffic through oubliette, and the scrubber nukes the flood at line rate before the backend ever breaks a sweat.

I’m incredibly hyped about where this architecture is heading. Let’s see what happens next!