We are under attack! (of a DDoS)

I'm writing this article because lately my network, AS200132, has been having some hiccups. Not because the software is unstable, but because of attacks from the outside — infamously known as DDoS attacks.

• For reference — attacks involved multiple hundreds of Gbps... more than I can absorb.

I don't understand, and will never understand, why people resort to this kind of thing. My network is purely intended to help others — you know, supporting, helping. It's a bit like attacking a school: a place where people experiment, learn, and grow. You shouldn't do that either.

Despite everything, I had to take some measures to protect my network from downtime, which set me out to build an anti-DDoS engine.

Principles

There are various mitigation options and detection mechanisms for DDoS attacks. I'll restrict this article to how I built my DDoS shield, named Sentry-Flow (SF), which makes use of flow data. As a sneak preview, here's a screenshot of the app.

For people not interested in reading but but clicking: https://sentryflow-demo.netone.nl is a demo/mockup of the suite in production.

And now how i got there ...

I love the following two pictures from Pavel Odintsov of FastNetMon , which explain what's traveling in a "flow" — in this case, IPv4 and IPv6 packets.

This is also what i want to use for my anti-DDoS / mitigation / detection engine. I want to decode flows based on their content to initiate remediation actions where needed, eg looking inside the packets to determine if traffic is clean or malicious.

Building

A little epilogue is in order here. I could have downloaded an open-source suite or bought a commercial product, but since everything is paid out of my personal account, that's a tough call. There are some very good open-source products out there — check out the folks at FastNetMon , they have a nice suite.

For me, I'm using some specific automation tooling and setup, and I decided to set up a "date" with Claude.ai to build a suite of my own.

Basic components: Bird routing, VPP dataplane, RHEL 9 + 10 servers, Arista + Mikrotik networking.

Note: I'm not a developer, so yes — I've vibe-coded this. But there's vibe coding, and there's vibe coding. I put everything into the context/harness of Claude, based on the principles we preach at Red Hat when it comes to proper software building: testing, linting, SBOMs, hashing, CVE scanning, cleaning, and so on. For reference, when the GitLab runners build the Sentry-Flow application, each build runs nearly 81 "tests" to validate the app and each individual function, poller, trigger, job, etc.

find . -type d -print0 |
while IFS= read -r -d '' d; do
    printf "%8d %s\n" "$(find "$d" -type f | wc -l)" "$d"
done | sort -nr
      81 .TESTS
      64 ./backend
      17 ./worker

What did I need to build Sentry-Flow?

• Flow data
• Detection
• Baselining
• Actions / test area
• Generic management

I'll explain further what I used for each of these and how the various capabilities look in Sentry-Flow itself.

Flow data

There are basically two ways for me to get flow data — either by using the sFlow plugin from FD.io Vector Packet Processing on the routers themselves (I have three), or by using an sFlow exporter on a switch.

Since my routers are mainly connected to one switch (either DWDM/L2 or via dedicated port channels), and since I couldn't get the VPP plugin working, I decided to put an exporter on the Arista 7280 switch I have. I won't go into the config here.

Data is then exported to an application called Akvorado — a really nice suite that gathers flow data and presents it with various queryable options: destination ASN, source ASN, addresses, IPv4/IPv6, geographic information, and much more. See below a screenshot from their website, and check out https://demo.akvorado.net/ as well.

Detection

Now we have proper data — awesome! But we need to make sense of it. After some searching, I found this article by Vincent Bernat : https://vincent.bernat.ch/en/blog/2023-akvorado-ddos-flowspec, which was a great source of inspiration.

He describes a few patterns and queries we can run against the ClickHouse database behind Akvorado. I fed all of this into Claude and used it as the basis for the baselines.

Building on his work, Sentry-Flow ships with some pre-defined patterns and also lets you build your own. You can adjust the various weight factors of a pattern from within the app too. This is probably the part — patterns and weight factors — that will need the most rework and tweaking going forward.

Baselining

Next up: monitoring. Before you can take action, you need to determine what's "normal" and what isn't.

For this, Sentry-Flow has a baseline function that determines, based on historical Akvorado data, whether traffic is behaving as expected. The system adapts automatically via jobs in the backend containers, adjusting its expectations over time. It's also possible to manually adjust the time profile of the traffic — some downstreams and upstreams are day- or night-heavy, and that's a parameter I can tune.

Actions

Now the most tricky part — if something is detected (see the dashboard at the beginning of the article), what am I going to do?

After some investigation, there are basically three options available to me:

1. Blackholing I can blackhole a target or destination — either via a route to 0.0.0.0 or via a BGP community (666).
2. ACLs I can apply Access Control Lists on the dataplane, in this case VPP.
3. BGP FlowSpec I can use BGP FlowSpec, with fine-grained options to tweak incoming and outgoing traffic based on patterns.

I've decided to implement all three options into Sentry-Flow. For each remediation — and depending on the capabilities of each router, which are tested when it's added to the app — the relevant remediation options become available. This means you can have a mix of routers with more or less capability, and Sentry-Flow adapts to what each one supports.

For reference: Sentry-Flow currently only works against Bird 2.19+ and VPP. VPP only supports FlowSpec via a special plugin from FastNetMon , developed by a team led by Denys Haryachyy , on VPP 25.10 or VPP 26.06. Also, for each of the three remediation types, there's a "staged" variant and a "realtime" variant: realtime takes action immediately without making it permanent, while staged writes the change to the config files.

(The FastNetMon plugin isn't generally available yet — contact Pavel Odintsov if you want to test it too.)

The staged option is directly linked to my Git repo, where my automation tooling lives. I use Netwerkvereniging Coloclue KEES automation toolchain (though with heavy modifications). In my private repo, Sentry-Flow opens a PR/MR — for example, a blackhole in static-routes.conf — and merges it after my approval. For VPP, Sentry-Flow can edit the daemon's bootstrap file or execute the plugin commands directly, restricted to only those specific commands and nothing else.

A mitigation then looks like this — a sample detection with all the available actions. They light up green when I pick one 🙂 I particularly like the console output, where I can see exactly what's being executed.

Once a mitigation is applied, it shows up in the "Active Mitigations" tab, where I can see everything currently applied — realtime or staged — and withdraw it if needed. I also like the manual mitigation option here, including the ability to set a timer for automatic withdrawal. A similar pane called "Test Area" lets me test freely using RFC 5737 (203.0.113.0/24, 198.51.100.0/24, 192.0.2.0/24) and RFC 3849 IPv6 ranges — so I can experiment without breaking anything... I think 🙂

Generic management

To conclude - an engine is nothing without proper infrastructure management around it. So i have builtin the following features as well

• Configurable options for Akvorado — either polling via ClickHouse or a realtime Kafka bus query

• Adding/removing routers with proper connectivity and capability checks. In the router's edit pane, you can also select, based on a query to VPP, which interfaces the ACLs should apply to — either ACL or FastACL

• A notification system for detections, issues, and lost connectivity to Akvorado, with configurable alerts based on my needs. Notifications go out via SMTP or Matrix
• Branding: I can adjust the logo, colors, and text body colors, and Sentry-Flow has a dark/light mode
• User management: both local and LDAP-based, with built-in 2FA. Keycloak/SAML/OAuth is on the roadmap. Also includes session timers, avatars, username changes, and a full RBAC system with admin, operator, and read-only roles
• Configurable parameters for my Akvorado instance, GitLab/Forgejo/Gitea, ports, timeouts, etc.
• Retention jobs for the detection log
• SBOM generation with each build, plus calendar versioning (2026.9.X) of the appe

Lastly, a backup system for all settings, exported with proper keys and hashing. Note: all data is encrypted on initial launch of Sentry-Flow, so if you lose the original keys, the settings can't be imported into a new system.

Roadmap

The following items are on the roadmap/backlog:

• A DDoS simulator for the various patterns, to really test that the system works
• More options around BGP FlowSpec
• Making it scalable — more workers, backend, Kubernetes support
• Making it open source 🙂 — not sure yet, mainly because I don't want to compete with other great initiatives, but I'm definitely considering it

One more thing ....

Please — reading this doesn't mean you should start testing whether my network crashes, times out, or triggers Sentry-Flow. I unfortunately had to build this to protect myself and my downstreams.

Let's keep the internet safe and working properly, and treat everyone the way you'd want to be treated.

Cheers! Peter-Paul