I had a problem: I needed to detect DDoS attacks in a network and react to them automatically. I looked at the tools that were available, but none of them solved it for me. Especially the escalation, and changing the mitigation as an attack evolves, could not be adapted in most solutions. So I decided to build my own solution: flowwler.

If your network could talk, it would say: “I can see the attack. I just need help reacting to it.” That is the idea behind flowwler. Its design goal is simple logic, quick decisions and clear escalation levels, without overloading the operator.

How It Works

flowwler is a single daemon with an embedded GoBGP server, so no external BGP daemon is needed.

  1. Receive flow data from the routers: NetFlow v5/v9, IPFIX and sFlow v5.
  2. Detect anomalies by aggregating traffic per destination IP over sliding windows, with asymmetric rate smoothing.
  3. Escalate as the attack evolves, using a configurable state machine (Idle → Active → HoldDown). This is the part I could not get from other tools: the escalation and the change of mitigation are fully configurable.
  4. Mitigate via BGP: host blackholes (/32, /128), subnet blackholes (/24, /48) or Flow Spec filtering.

Subnets can be discovered automatically via IRR/WHOIS and NetBox IPAM, and the configuration reloads via SIGHUP or the API without a restart.

Notifications go out through webhooks, Slack, Telegram, PagerDuty, Jira, MS Teams and others. For observability there is a REST API, Prometheus metrics, a CheckMK plugin, an attack history in SQLite and optional PCAP capture.

What It Is Not

flowwler is deliberately not a traffic analytics or network insight tool. It does no traffic visualization, capacity planning or historical flow analysis. It does one thing, detecting attacks and reacting to them, and complements analytics tools such as Akvorado.

First Real-World Test

The first bigger attack was a UDP flood of more than 40 Gbit/s in a customer environment. It was detected through the flow data and then filtered automatically via Flow Spec on the routers.

Flow Spec Is More Than Dropping Traffic

Discarding traffic with Flow Spec is not always the ideal solution. For attacks that are tailored to applications, filtering in a scrubbing center or on a local appliance is often the only option.

flowwler can therefore also redirect matching traffic instead of dropping it. There are two ways to do this:

  • Route Target: The Flow Spec rule sets a Route Target for a dedicated VRF, which moves the matching packets to a scrubbing appliance or an analytics platform.
  • Next-Hop IP: The next hop is encoded directly in the Flow Spec route, so no dedicated VRF configuration is needed.

This allows selective handling. SIP traffic, for example, can be routed through an internal scrubbing appliance while other suspicious traffic is discarded directly on the router.

GeoIP and ASN Data

Many setups run a second tool next to flowwler for flow analysis, for example Akvorado. It enriches flow data with interface and AS path information from SNMP and BMP, which is great, but many customers only need to know where the traffic comes from: the ASN, the AS name and the country.

So flowwler now provides this itself, using MaxMind datasets for the GeoIP enrichment:

  • Traffic per ASN and country as dedicated Prometheus metrics
  • Attack details enriched with a country and ASN summary
  • Dropped traffic per country and ASN
  • All of it available in the UI, in notifications, through the API and on the Prometheus endpoint