FastNetMon Community Edition: a DDoS sensor that watches traffic, not packets

The detection problem FastNetMon Community is built for

FastNetMon watches for hosts in your network that send or receive unusually large volumes of traffic, measured in packets, bytes or flows per second, and then runs a configurable action when a host crosses a threshold. That is the whole product in one sentence. The README describes the trigger as "if an IP exceeds defined thresholds for packets/bytes/flows per second", and the action can be a notification, a script call, or a BGP announcement.

The audience is narrower than the phrase DDoS detector suggests. You need routers or switches that can export flow data, or a port mirror you can feed into a capture interface. If you operate a network where you already collect NetFlow or sFlow for capacity planning, FastNetMon is a second consumer of data you are paying to generate anyway. If you are a web application owner behind a load balancer with no control over the network path, this tool does not fit your problem: it sees traffic volumes, not HTTP requests, and it cannot act on traffic it cannot announce to a router.

Detection speed is stated as 1 to 2 seconds. That number depends on your export interval, not on FastNetMon alone. A router that exports flows every 60 seconds gives the sensor a 60 second blind spot no matter how fast the analyzer is, which is a constraint the README does not spell out.

How the capture engines and threshold logic fit together

The architecture is a set of capture engines feeding one analyzer. The README lists the supported engines: NetFlow v5, v9 and v9 Lite, IPFIX, sFlow v5, PCAP, AF_PACKET (marked recommended), AF_XDP, Netmap (deprecated, FreeBSD only) and PF_RING / PF_RING ZC (deprecated, available only for CentOS 6 in 1.2.0).

Flow-based engines (NetFlow, IPFIX, sFlow) receive records from routers. The sensor aggregates them per host and compares the result against thresholds. Because flow records are summaries, this path scales to what the README calls terabits on a single server, at the cost of granularity: you see volumes per host, not individual packets. The packet-based engines (AF_PACKET, AF_XDP, PCAP) read a mirrored copy of the traffic itself, which gives full packet visibility and the ability to capture attack fingerprints in PCAP format, but caps throughput at what a single server can absorb from a mirror. The README puts that at 40G and above in mirror mode.

Thresholds are not global. The hostgroups feature lets you configure them per subnet, which matters in any network where a storage node legitimately moves more traffic than a web server. There is also a list of integrations that consume the sensor's output: Prometheus for system metrics and total traffic counters, Kafka export in JSON and Protobuf, ClickHouse, InfluxDB, Graphite, Redis, and MongoDB protocol support compatible with native MongoDB and FerretDB. Announcements of blocked IPs go out via BGP through ExaBGP or GoBGP, with GoBGP marked recommended in the README.

Installing FastNetMon Community and running a first detection

The README does not contain install commands. It points to three places: Linux install instructions at fastnetmon.com/install/, macOS via Homebrew, and a FreeBSD port. It also notes distribution packaging tracked on repology and a Snap package named fastnetmon-community. Because the repository itself gives no build steps, the honest first step is to open the Linux install page and follow it for your distribution rather than guessing at a build command.

On macOS the README gives the Homebrew formula page as the install reference:

brew install fastnetmon

The binary is `fastnetmon`. It reads a configuration file, and the README links a specific line of `src/fastnetmon.conf` as the ClickHouse configuration reference, which tells you the file lives at `src/fastnetmon.conf` in the source tree and is installed alongside the binary by the packages. The configuration holds the capture engine selection, the interface or flow listening settings, the thresholds, and the action to run.

The quickest way to see whether the sensor is alive is to start it and watch the command line interface, which the README shows in a screenshot under docs/images/fastnetmon_screen.png. That screen is where per-host counters appear. If nothing appears, the usual cause is that the selected capture engine is not receiving data: a flow engine with no exporter pointed at it, or a mirror engine bound to an interface with no mirrored traffic.

For a first real detection, pick a hostgroup, set a bytes per second threshold you know normal traffic will not reach, and point the action at a script that logs the event. The README describes the action as a "block/notify script" triggered when an IP exceeds the thresholds, so a script that appends a line to a file is a safe first action before you wire anything to BGP.

Where FastNetMon Community is the wrong tool

The clearest limitation is the one implied by the feature list: this is a volumetric detector. It counts packets, bytes and flows per second. A layer 7 attack that stays under your volumetric thresholds, or one that arrives through a CDN or proxy so the traffic never reaches your network edge, is invisible to it. There is no request parsing in the feature list.

The second limitation is operational. Detection is only half of mitigation. FastNetMon can announce a blocked IP via BGP using ExaBGP or GoBGP, or call a script, but the actual dropping happens in your routers, your scrubbing centre, or your upstream. If your BGP announcements do not reach a device that filters, the sensor will report attacks accurately and change nothing.

The third is the capture backend churn. Two engines are marked deprecated in the README: Netmap, supported only for FreeBSD, and PF_RING / PF_RING ZC, available only for CentOS 6 in 1.2.0. Anyone with a long-standing deployment built on PF_RING is on an engine the project has stopped developing, and the README's own recommendation has moved to AF_PACKET and AF_XDP.

Finally, the Community edition is a tier, not the whole product. The README links a comparison table between Community and Advanced, and an Advanced commercial edition with a one-month trial. Features that exist only in Advanced are not listed here, so treat the Community feature list as a boundary rather than a promise of parity.

FastNetMon alternatives and what changes if you switch

The obvious alternative to a flow-based sensor is a packet-based one. Tools that sit on a mirror port and inspect every packet, including layer 7 proxies and WAFs, see things FastNetMon's flow engines cannot: request patterns, malformed payloads, application behaviour. The trade is throughput and placement. A packet inspector has to be in the traffic path or on a mirror that carries the full volume, so it scales with the size of the pipe rather than with the number of flow records. FastNetMon's own packet modes (AF_PACKET, AF_XDP, PCAP) sit in that same category, so the real choice is which engine you enable, not which product you buy.

The second alternative is to build the detection yourself on the flow data you already collect. If you already run a flow collector and a time-series database, a threshold alert on per-host bytes per second is a small amount of code. What you would be reimplementing is the hostgroup threshold model, the attack fingerprint PCAP capture, the BGP announcement path through ExaBGP or GoBGP, and the export integrations to Kafka, ClickHouse, InfluxDB and Graphite. That is a real amount of glue, and it is the part FastNetMon has already written.

The third is the vendor's own Advanced edition. The README links a difference table, which is the document to read if you are choosing between the two. The Community edition is GPL-2.0, so the licence terms differ from a commercial licence in ways that matter if you plan to redistribute or embed the code.

Licence, maintenance and what an upgrade actually costs

FastNetMon Community is GPL-2.0. If you deploy it internally as a sensor, the copyleft obligation is mostly about what happens if you distribute modified binaries; the repository's LICENSE file is the authoritative text and this article is not legal advice. Note also that the README states the software is a product of FastNetMon LTD, UK, with a registered trademark, and that installing or using it means you agree to the Community Edition terms and conditions and privacy notice. Those are separate documents from the code licence, and they are linked from the README. Read them before a production rollout, because they are the terms the vendor says apply to your installation.

The README also states that the project tracks platform and environment-specific usage metrics to prioritise development. That is a data-collection behaviour you should confirm against the privacy notice if your environment has restrictions on telemetry leaving the network.

On maintenance: the repository is not archived, and the last push was on 2026-09-03. The release history shows v1.2.9 on 2026-05-31, v1.2.8 on 2024-12-16 and v1.2.7 on 2024-07-01. The gap between 1.2.7 and 1.2.8 was roughly eighteen months, and the gap to 1.2.9 roughly five and a half months, so release cadence has not been uniform. Plan upgrades around the release notes rather than an assumed schedule.

Upgrade cost is dominated by the capture backend, not the binary. If you are on a deprecated engine, moving to AF_PACKET or AF_XDP is a configuration and possibly a kernel change, not a package swap. The README does not document rollback procedures, so a version pin plus a copy of your working configuration is the practical safety net.

Editorial conclusion

Adopt FastNetMon Community if you run your own routers, can export NetFlow, IPFIX or sFlow to a collector, and want a script or a BGP announcement to fire when a host crosses a bytes, packets or flows per second threshold. Do not adopt it if you have no flow-export capability, if you need per-request HTTP layer 7 inspection, or if you need vendor support with a response time commitment, because the Community edition is the free tier and FastNetMon sells an Advanced edition alongside it. Before committing, verify two things in your own environment: that your router model exports the flow version you intend to send, and that the action you configure (script, email, ExaBGP or GoBGP) actually reaches the device that can drop the traffic. The repository is not archived and the last push was on 2026-09-03, so the code is being touched, but the install path is documented on fastnetmon.com rather than in the README, and that is the first page you should read before you download anything.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. pavel-odintsov/fastnetmon on GitHub
4. README
5. Releases