IPFIX-based DDoS detection: open source
tools and setup guide

Back to Blog

What IPFIX Is (and Isn't)

IPFIX (IP Flow Information Export) is a standard protocol (RFC 7011) for exporting traffic flow data from network devices. Your router samples packets passing through it, aggregates them into flow records (source IP, destination IP, source port, destination port, protocol, byte count, packet count), and exports those records to a collector over UDP.

IPFIX is the IETF-standardized successor to Cisco's NetFlow v9. In practice, they're very similar. Most tools that support IPFIX also support NetFlow v5 and v9. sFlow is a related but different protocol that sends raw packet headers rather than aggregated flow records.

What IPFIX gives you:

• Network-wide visibility from a single collection point (your router)
• Traffic data for every IP behind the router, not just one server
• Source and destination IP, port, protocol, and byte/packet counts
• No agent required on individual servers

What IPFIX doesn't give you:

• Packet-level detail (no payload, no TCP flags in most implementations)
• Real-time data (flow records are aggregated over intervals, typically 30-60 seconds)
• Unsampled counts (most routers sample 1-in-1000 or 1-in-4096 packets)

Step 1: Configure Your Router to Export IPFIX

The configuration depends on your router platform. Here are the most common setups. In all cases, replace COLLECTOR_IP with the IP of the server running your IPFIX collector.

VyOS

set system flow-accounting interface eth0
set system flow-accounting netflow version 9
set system flow-accounting netflow server COLLECTOR_IP port 4739
set system flow-accounting netflow sampling-rate 1000
set system flow-accounting netflow timeout expiry-interval 60

Juniper (JunOS)

set forwarding-options sampling input rate 1000
set forwarding-options sampling output flow-server COLLECTOR_IP port 4739
set forwarding-options sampling output version ipfix
set forwarding-options sampling output inline-jflow source-address ROUTER_LOOPBACK

Mikrotik (RouterOS v7)

/ip/traffic-flow set enabled=yes interfaces=ether1
/ip/traffic-flow/target add dst-address=COLLECTOR_IP port=4739 version=ipfix

Cisco IOS-XE

flow exporter FLOWTRIQ
  destination COLLECTOR_IP
  transport udp 4739
  export-protocol ipfix
  template data timeout 60
!
flow monitor DDOS-MONITOR
  exporter FLOWTRIQ
  record netflow ipv4 original-input
!
interface GigabitEthernet0/0
  ip flow monitor DDOS-MONITOR input

Step 2: Set Up a Collector

The collector receives IPFIX records from your router, aggregates them, and either stores them or feeds them into a detection engine. Here are the open source options:

GoFlow2

GoFlow2 is a lightweight Go-based flow collector that receives NetFlow/IPFIX/sFlow and outputs to Kafka, stdout, or custom backends. It's fast and easy to deploy, but it's a collector only. It doesn't do DDoS detection. You need to build detection logic on top of whatever backend you feed the data into.

# Install and run
go install github.com/netsampler/goflow2/cmd/goflow2@latest
goflow2 -listen netflow://:4739 -transport.type kafka -transport.kafka.brokers localhost:9092

pmacct / nfacctd

pmacct is a mature C-based network monitoring toolkit. Its nfacctd daemon collects NetFlow/IPFIX and can write to PostgreSQL, MySQL, MongoDB, Kafka, or flat files. Like GoFlow2, it's a collection and accounting tool, not a detection engine. You can build threshold-based alerting using SQL queries against the stored data, but that's manual work.

ntopng

ntopng is a web-based traffic analysis tool that can receive IPFIX via its nProbe companion. It provides dashboards, traffic visualization, and some anomaly detection. It's more of a monitoring platform than a DDoS-specific detection tool, but it can show you traffic patterns and alert on thresholds.

Flowtriq Agent (with flow ingestion)

The Flowtriq agent can receive IPFIX/NetFlow/sFlow records in addition to its native packet capture. This means you get both network-level flow data from your router and per-server packet analysis from the agent, correlated in a single dashboard. Flow-based detection runs alongside agent-based detection, and both feed into the same baseline and alerting engine.

# In the Flowtriq dashboard, configure the node's Flow Config:
# Protocol: IPFIX
# Port: 4739
# Sample rate: 1000 (must match router config)

The Sampling Problem

This is the most important thing to understand about IPFIX-based detection, and it's the thing that vendors gloss over.

Most routers sample packets before creating flow records. A sampling rate of 1:1000 means the router looks at 1 out of every 1,000 packets and extrapolates the totals. This is necessary because inspecting every packet on a 100 Gbps link would overwhelm the router's CPU.

Sampling has consequences for detection:

• Small attacks disappear. A 5,000 PPS SYN flood at 1:1000 sampling produces approximately 5 sampled packets per second. That's noise-level in the flow data. The attack is real and could take down a web server, but it's invisible to the flow collector.
• Detection latency increases. The flow export interval (typically 30-60 seconds) plus the collector's analysis window means you're always looking at traffic that happened 30-120 seconds ago. A short, sharp attack might start and end before you detect it.
• Attack classification gets harder. With sampled data, you see a statistical approximation of the traffic, not the actual traffic. Port distributions and protocol ratios have sampling error. A small DNS amplification attack might not have enough sampled port-53 packets to confidently classify the vector.

Rule of thumb: IPFIX-based detection reliably catches volumetric attacks above approximately 1 Gbps (at 1:1000 sampling on a 10G link). Below that threshold, you need per-server agent-based detection to catch the attack before it's statistically significant in sampled flow data.

IPFIX vs sFlow vs NetFlow

If your router supports multiple export protocols, here's how to choose:

• IPFIX (RFC 7011): The standard. Template-based, flexible, supports IPv6 natively, variable-length fields. Use this if your router supports it.
• NetFlow v9: Cisco's template-based format. Functionally very similar to IPFIX. Most collectors that support IPFIX also support NetFlow v9.
• NetFlow v5: The legacy fixed-format version. IPv4 only, no templates, limited fields. Still widely supported but no reason to use it on modern hardware.
• sFlow: Sends raw sampled packet headers rather than aggregated flow records. Gives you more packet-level detail (TCP flags, etc.) but generates more collector-side processing. sFlow is common on switching platforms (Arista, Cumulus, some Juniper).

For DDoS detection specifically, IPFIX and sFlow are both good choices. IPFIX gives you cleaner aggregated data. sFlow gives you richer packet detail. Either works. The detection quality depends more on your collector/analysis engine than on the export protocol.

Putting It All Together: IPFIX + Agent Detection

The strongest detection architecture combines both approaches:

1. IPFIX from the router gives you network-wide visibility. You see traffic to every IP behind the router, including traffic that gets filtered before it reaches the server. Good for catching large volumetric attacks and getting a global view.
2. Agent on the server gives you per-server precision. You see every packet hitting the server with zero sampling. Good for catching small/medium attacks, classifying attack vectors accurately, and building per-node baselines.

The two data sources are complementary. IPFIX catches what the agent can't see (upstream-filtered traffic, traffic to other IPs). The agent catches what IPFIX misses (small attacks lost in sampling, sub-second detection, packet-level classification).

With Flowtriq, both data sources feed into the same detection engine. The dashboard shows a unified view: flow data from the router and packet data from the agent, correlated per-node, with a single set of alerts and mitigation rules.

Back to Blog

Related Articles