🚨 FastFlowIPs

Wie alles begann

Open-Source oder nicht Open-Source - das ist die Frage.

Das ewige Dilemma zwischen etwas von der Stange nehmen und etwas Eigenes bauen ist im Zeitalter endloser KI-Tools nur noch schärfer geworden. Aber solltest du wirklich etwas selbst schreiben? Es gibt keine universelle Antwort. Aber wenn du deine Ängste in /dev/null entsorgst, scheint die Idee gar nicht mehr so verrückt.

Unsere Geschichte begann mit einem Upgrade von VyOS auf Produktionsroutern auf 1.5.x (circinus). Nach diesem ohnehin schon nervenaufreibenden Prozess entdeckten wir, dass sich ein Teil unserer Firewall-Regeln stillschweigend selbst gelöscht hatte. Und das Lustige - es war derselbe spezifische Teil auf jedem Router. Also öffneten wir widerwillig VyOS Project Updates, wo wir auf das hier stießen: FastNetMon-based service ids ddos-protection is removed from rolling and deprecated in LTS releases (T7241):

For quite a while, we had a CLI for configuring FastNetMon — a DDoS detection daemon. However, that integration was never especially deep, and we do not see a path to significant improvement.
The long-term plan is to move FastNetMon to an addon, once we finalize a mechanism for allowing addons to extend the system CLI. As for built-in components, the approach will be “quality over quantity” — it’s better to have a smaller number of integrations that serve a large number of users and play well together, but to provide an option for everyone to install or develop integrations for their own needs.

Das Problem war nicht extrem dringend oder kritisch, aber als IPv4-Broker und Hosting-Provider brauchten wir solche Überwachung. Daher beschlossen wir, sofort zu handeln.

Nach dem typischen Zyklus - Verleugnung, Wut, Verhandeln - akzeptierten wir schließlich den Verlust von service ids ddos-protection und versuchten, FastNetMon Community manuell wiederzubeleben. Da setzte die Depression ein. Die Community-Version weigerte sich aus Gründen zu installieren, die, seien wir ehrlich, jeder bereits ahnte. Und niemand war in Eile, die kommerzielle Version zu kaufen.

Das Problem war nicht katastrophal, aber für uns als IPv4-Broker und Hosting-Provider war solche Überwachung unerlässlich. Die Entscheidung war also klar: sofort handeln.

FastNetMon: Wir lieben dich, aber…

Unsere Beziehung zu FastNetMon begann nicht vor allzu langer Zeit, aber das Tool eroberte schnell unsere Herzen und lieferte echten Wert - obwohl es konsequent etwa 30% unserer CPU auffraß.

Die Traffic-Sichtbarkeit war perfekt, Grafana strahlte mit Metriken, und das Leben fühlte sich einfach ein wenig friedlicher an. Und jetzt? Jetzt starren wir auf leere Traffic-Dashboards und wählen aus irgendeinem Grund freiwillig den Weg “das Leben schwerer machen”. Nun… nicht freiwillig. Eher mit Gewalt. Und wie üblich fängst du erst an, dich an all die Mängel zu erinnern, sobald du etwas verlierst.

FastNetMon erfüllte im Allgemeinen unsere Erwartungen - und übertraf sie sogar. Aber bei all seinen Vorteilen sammelte es einen massiven Haufen völlig unnötiger Daten und verwandelte Dashboards in einen lärmenden Karneval aus Zahlen und Graphen. Und dann war da diese CPU-Last - nicht katastrophal, aber nervig genug. Daher bildeten wir nie ein festes “ja” oder “nein”. Die Seele sehnte sich nach Einfachheit und Leichtigkeit, nicht nach einem weiteren Abonnement und Feintuning jedes Mal, wenn das Tool nieste.

Die Idee, unser eigenes Tool zu bauen, kam nicht sofort. Der Kampf um FastNetMon ging weiter - wir versuchten sogar, es wiederzubeleben, indem wir eine alte Binärdatei von einem anderen Server holten. Ja, es war ein etwas fragwürdiger Ansatz, aber es funktionierte: FastNetMon erwachte wieder zum Leben. Außer… es gab keine Freude darin.

Es fühlte sich an, als hätten wir eine ausgestopfte Version eines längst verstorbenen Haustieres zusammengenäht: technisch stehend, vage erkennbar, aber mit ihm zu leben fühlte sich… beunruhigend an.

Also waren wir uns kollektiv einig: Das kann nicht so weitergehen. Und da begannen wir, unseren eigenen überwachungsbasierten DDoS-Protektor mit Blackjack und minimaler CPU-Last zu bauen.

Und dann eskalierte es

So begann die Entwicklung unseres eigenen Tools. Die hellsten Köpfe des Teams plus ein paar KI-Modelle schlossen sich natürlich der Brainstorming-Session an, und so entstand FastFlowIPs. FastFlowIPs ist ein hochperformantes eBPF-basiertes Netzwerk-Überwachungstool, das per-IP-Traffic-Statistiken in Echtzeit verfolgt. Es wurde für Produktionsumgebungen mit minimalem Overhead entwickelt.

Die Kernidee ist einfach: Es erfasst Netzwerktraffic über eBPF, berechnet per-IP-Statistiken (PPS, Mbps) und kann automatisch IP-Adressen blockieren, die konfigurierbare Schwellenwerte überschreiten. Metriken werden über das Graphite-Protokoll exportiert und passen wunderbar zu Grafanas Erwartungen. Die resultierenden Dashboards sind sauber, leichtgewichtig und schnell einzurichten.

FastFlowIPs läuft mit einem einzigen One-Liner, wo du -min-ips-pps und -min-flow-pps angibst, um nur die aussagekräftigsten Metriken zu exportieren, plus das Netzwerk und Interface zur Überwachung. Die einzige Must-Have-Anforderung ist die explizite Angabe von -graphite-host und -graphite-port, wenn du Metriken versenden möchtest.

Darüber hinaus ist FastFlowIPs für hochbelastete Netzwerke optimiert: 75% weniger Mutex-Operationen, 60% schnellere String-Behandlung verglichen mit typischen Implementierungen.

Ein Beispiel-Konfiguration ist unten gezeigt:

# Interface and basics
-interface eth0              # Network interface (default: eth0)
-interval 5s                 # Collection interval
-show-stats                  # Display periodic tables
-verbose                     # Detailed logging

# Network filtering
-networks "192.168.1.0/24"   # Monitor specific networks only

# IP banning thresholds
-ban-pps-rx 1000             # Ban if receiving > 1000 PPS
-ban-pps-tx 500              # Ban if sending > 500 PPS
-ban-mbps-rx 100             # Ban if receiving > 100 Mbps
-ban-mbps-tx 50              # Ban if sending > 50 Mbps
-ban-time 5m                 # How long to ban
-ban-script /path/script.sh  # Script to execute on ban/unban

# Graphite export
-graphite-host localhost     # Graphite server
-graphite-port 32003         # Graphite port
-min-flow-pps 10             # Only export flows > 10 PPS
-min-ips-pps 5               # Only export IPs > 5 PPS

Es gab keinen Weg, die Überwachungsmodi zu überspringen - sie lassen dich dieses bescheidene kleine Tool nach deinem persönlichen Geschmack einstellen:

• Stiller Modus (Standard): zeigt nur Ban-Ereignisse und Startmeldungen. Perfekt für die Produktion.
• Stats-Modus (-show-stats): druckt periodische Traffic-Tabellen, sortiert nach Volumen.
• Verbose-Modus (-verbose): detaillierte Protokollierung, einschließlich Graphite-Export-Statistiken.

Und die Kirsche obendrauf - das Ban-Skript, das rücksichtslos jede verdächtige Aktivität blockiert, die die definierten Schwellenwerte überschreitet:

/path/to/script.sh ban 192.168.1.100    # IP exceeded threshold
/path/to/script.sh unban 192.168.1.100  # Ban expired

Ein einfaches Beispiel mit iptables:

#!/bin/bash
case $1 in
  ban)   iptables -I INPUT -s $2 -j DROP ;;
  unban) iptables -D INPUT -s $2 -j DROP 2>/dev/null ;;
esac

Aber in jedem Fall kannst du das Skript immer anpassen und es mehr oder weniger aggressiv machen - was auch immer deine Infrastruktur erfordert.

Und ein paar Worte über Graphite und Metriken. Ein Grafana-Dashboard kann in nur wenigen Minuten mit zwei Kern-Metriktypen erstellt werden:

Flow-Metriken: **network.flows.{SRC_IP}*to*{DST_IP}.{pps,mbps}.{rx,tx}**
IP-Metriken: **network.ips.{IP_ADDRESS}.{pps,mbps}.{rx,tx}**

Mehr Details über FastFlowIPs findest du im Repository selbst: https://github.com/denisix/fastflowips und du kannst den Autor immer unterstützen oder zur Entwicklung dieses kleinen aber bereits mächtigen Tools beitragen.

Architektur in 3 Absätzen (ohne das Leiden)

Wenn wir das Tool in menschlicher Sprache beschreiben, ist es im Inneren ein ordentlicher kleiner Go-Service, der auf NetFlow-Pakete hört, sie in Komponenten parst und einfache per-IP-Statistiken erstellt: pps, mbps, eingehend/ausgehend - im Grunde, wer Lärm im Netzwerk macht und warum. Alle Mathematik wird im laufenden Betrieb gemacht - Go ist perfekt für leichtgewichtige aber hochdurchsatzfähige Operationen wie diese.

Die Daten werden in kleinen Speicherstrukturen aggregiert, sortiert und periodisch nach außen gesendet: entweder an Graphite/Grafana oder an jede andere Senke, die du angibst. IP-Blockierung über ein externes Skript wird durch PPS/Mbps-Schwellenwerte und einen Aufruf an BanScript implementiert - nur für den Fall, dass jemand plötzlich beschließt, ein kleines lokales DDoS-Festival zu veranstalten.

Das Beste: Es ist eine einzige saubere Binärdatei ohne Haufen von Abhängigkeiten und ohne die übliche “Open-Source-Kleinunternehmen-Hölle”. Konfigurationen werden über Flags übergeben, Statistiken werden direkt gesammelt, die Logik ist transparent. Am Ende bekamen wir ein leichtgewichtiges und ehrliches Tool, das genau das tut, was wir brauchen - keine übermäßige Magie, keine schweren angehängten Dämonen.

Ergebnisse nach ein paar Tagen

Der Debugging-Prozess erwies sich als viel länger und komplizierter als das Schreiben des Tools selbst. Anfangs planten wir nicht einmal, Schwellenwerte für FastFlowIPs zu setzen, also hielt Grafana mehrmals (viele Male) nervös den Atem unter der schieren Menge an Metriken an und weigerte sich, sie uns überhaupt zu zeigen. Die Dashboard-Legende enthielt so viele IP-Adressen, dass man stundenlang scrollen konnte und wahrscheinlich trotzdem nie das Ende erreichte. Wir hatten uns verrechnet - aber wo?

Das Debugging brach immer wieder Dinge, stabilisierte sie dann, dann brach es unsere erschöpfte FastFlowIPs wieder, bis es anfing, leise in Eckfällen zu weinen. Es gab entweder zu viele Metriken, oder zu wenige, oder gar keine. Offenbar von emotionaler Überlastung. Darüber hinaus stellte sich das größte Rätsel für uns als die Flows RX/TX-Metriken heraus, die sich leicht vertauschten, etwas, das in Echtzeit auf VyOS-Routern wunderbar sichtbar war. Die hellsten Köpfe unseres Teams rangen damit, und schließlich wurde das Ziel erreicht: Die Metriken wurden stabilisiert und Grafana wurde von seinem Asthma geheilt.

Heute haben wir ordentliche, aufgeräumte und informative Metriken, die genau den Netzwerktraffic zeigen, den wir brauchen:

Wann es Zeit ist, deinen eigenen Mini-FastNetMon zu bauen

Eigene Fahrräder zu bauen ist schlecht. Bis zu dem Moment, wo du einfach nicht mehr ohne einen vorwärts kommst.

Dein eigenes Tool zu schreiben macht absolut Sinn, wenn die bestehenden Lösungen entweder zu schwer oder zu klug für deine spezifische Aufgabe sind. Wenn du keine 100500 Features, Integrationen mit einer Raumstation und Dashboards über 19 Monitore brauchst - wenn du einfach nur Zahlen brauchst, schnell und ohne Kopfschmerzen.

Du solltest auch erwägen, deine eigene Lösung zu entwickeln, wenn die Situation Flexibilität erfordert: Du musst eine Metrik im laufenden Betrieb hinzufügen, benutzerdefinierte Anti-DDoS-Logik einbetten, die Überwachung mit deiner eigenwilligen Hardware harmonieren lassen oder einfach Einschränkungen umgehen, die plötzlich aus deiner Lieblings-Firmware entfernt wurden (ein warmes Hallo an VyOS 1.5).

Kurz gesagt, dein eigenes Tool zu bauen geht um Kontrolle, Geschwindigkeit, Minimalismus und nicht von Komponenten abhängig zu sein, die plötzlich aus Repositories verschwinden. Das Wichtigste ist, sich an die goldene Regel zu erinnern: Wenn es einfacher gemacht werden kann - mach es einfacher.

Und noch eine Regel: Wenn es funktioniert - fass es nicht an.

Das große Finale

Am Ende geht diese ganze Geschichte nicht um Traffic, DDoS oder sogar FastNetMon. Es geht darum, dass manchmal ein Team einfach ein Tool will, das funktioniert, nach einem Update nicht kaputt geht und dein Leben nicht in eine Wiederholung von Die Verurteilten verwandelt.

Wir haben das Fahrrad nicht neu erfunden - wir haben unseren eigenen kleinen Roller gebaut, der perfekt zu unserer Straße passt. Und daran ist nichts falsch. In einer Welt, wo massive Open-Source-Projekte ihr eigenes unvorhersagbares Leben leben, ist es schön, etwas Eigenes zu haben - vertraut, stabil und wunderbar langweilig.

Also wenn du jemals ein weiteres “perfektes aber etwas zu perfektes” Tool angeschaut und gedacht hast: “ehrlich gesagt, wäre es einfacher, es selbst zu schreiben” - könntest du tatsächlich auf dem richtigen Weg sein. Mach es nur klug, mit Tests… und sei bereit, ein wenig zu leiden.