🚨 FastFlowIPs

Comment tout a commencé

Open-source ou pas open-source - telle est la question.

Le dilemme éternel entre prendre quelque chose tout fait et construire le sien n’a fait que s’accentuer à l’ère des outils IA infinis. Mais devriez-vous vraiment écrire quelque chose vous-même ? Il n’y a pas de réponse universelle. Cependant, si vous jetez vos peurs dans /dev/null, l’idée ne semble plus si folle.

Notre histoire a commencé avec une mise à jour de VyOS sur les routeurs de production vers 1.5.x (circinus). Après ce processus déjà stressant, nous avons découvert qu’une partie de nos règles de pare-feu s’était silencieusement auto-supprimée. Et la partie amusante - c’était la même partie spécifique sur chaque routeur. Alors nous avons ouvert à contrecœur VyOS Project Updates, où nous sommes tombés sur ceci : 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.

Le problème n’était pas extrêmement urgent ou critique, mais en tant que courtier IPv4 et fournisseur d’hébergement, nous avions besoin d’un tel monitoring. Par conséquent, nous avons décidé d’agir immédiatement.

Après avoir traversé le cycle typique - déni, colère, négociation - nous avons finalement accepté la perte de service ids ddos-protection et tenté de ressusciter FastNetMon Community manuellement. C’est là que la dépression s’est installée. La version Community refusait de s’installer pour des raisons que, soyons honnêtes, tout le monde soupçonnait déjà. Et personne n’était pressé d’acheter la version commerciale.

Le problème n’était pas catastrophique, mais pour nous en tant que courtier IPv4 et fournisseur d’hébergement, un tel monitoring était essentiel. La décision était donc claire : agir immédiatement.

FastNetMon : nous vous aimons, mais…

Notre relation avec FastNetMon a commencé il n’y a pas si longtemps, mais l’outil a rapidement conquis nos cœurs et livré une vraie valeur - même s’il dévorait constamment environ 30% de notre CPU.

La visibilité du trafic était parfaite, Grafana brillait de métriques, et la vie semblait juste un peu plus paisible. Et maintenant ? Maintenant nous fixons des tableaux de bord de trafic vides et, pour une raison quelconque, choisissons volontairement la route “rendre la vie plus difficile”. Eh bien… pas volontairement. Plutôt par la force. Et comme d’habitude, vous ne commencez à vous souvenir de tous les défauts qu’une fois que vous perdez quelque chose.

FastNetMon répondait généralement à nos attentes - et les dépassait même. Mais malgré tous ses avantages, il collectait un énorme tas de données absolument inutiles, transformant les tableaux de bord en un carnaval bruyant de chiffres et de graphiques. Et puis il y avait cette charge CPU - pas catastrophique, mais assez ennuyeuse. Donc nous n’avons jamais formé un “oui” ou “non” ferme. L’âme aspirait à la simplicité et à la légèreté, pas à un autre abonnement et à un réglage fin chaque fois que l’outil éternuait.

L’idée de construire notre propre outil n’est pas venue instantanément. La bataille pour FastNetMon a continué - nous avons même essayé de le faire revivre en tirant un ancien binaire d’un autre serveur. Oui, c’était une approche un peu questionnable, mais ça marchait : FastNetMon est revenu à la vie. Sauf… il n’y avait pas de joie dedans.

Ça donnait l’impression d’avoir recousu une version taxidermisée d’un animal de compagnie décédé depuis longtemps : techniquement debout, vaguement reconnaissable, mais vivre avec était… troublant.

Donc nous nous sommes collectivement mis d’accord : cela ne peut pas continuer. Et c’est là que nous avons commencé à construire notre propre protecteur DDoS alimenté par monitoring avec blackjack et charge CPU minimale.

Et puis les choses ont dégénéré

Ainsi a commencé le développement de notre propre outil. Les esprits les plus brillants de l’équipe plus quelques modèles IA, bien sûr, se sont joints à la session de brainstorming, et c’est ainsi qu’est né FastFlowIPs. FastFlowIPs est un outil de monitoring réseau haute performance basé sur eBPF qui suit les statistiques de trafic par IP en temps réel. Il a été conçu pour les environnements de production avec un overhead minimal.

L’idée centrale est simple : il capture le trafic réseau via eBPF, calcule les statistiques par IP (PPS, Mbps), et peut automatiquement bloquer les adresses IP qui dépassent les seuils configurables. Les métriques sont exportées via le protocole Graphite et s’accordent parfaitement avec les attentes de Grafana. Les tableaux de bord résultants sont propres, légers et rapides à configurer.

FastFlowIPs fonctionne avec un seul one-liner où vous spécifiez -min-ips-pps et -min-flow-pps pour exporter seulement les métriques les plus significatives, plus le réseau et l’interface à surveiller. La seule exigence must-have est de définir explicitement -graphite-host et -graphite-port si vous voulez expédier des métriques.

En plus, FastFlowIPs est optimisé pour les réseaux à haute charge : 75% moins d’opérations mutex, 60% plus rapide dans la gestion des chaînes comparé aux implémentations typiques.

Un exemple de configuration est montré ci-dessous :

# 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

Il n’y avait aucun moyen de passer outre les Modes de Monitoring - ils vous permettent d’ajuster ce petit outil modeste à votre goût personnel :

• Mode silencieux (par défaut) : montre seulement les événements de bannissement et les messages de démarrage. Parfait pour la production.
• Mode stats (-show-stats) : affiche des tableaux de trafic périodiques, triés par volume.
• Mode verbose (-verbose) : journalisation détaillée, incluant les statistiques d’export Graphite.

Et la cerise sur le gâteau - le script de bannissement, qui bloque impitoyablement toute activité suspecte qui dépasse les seuils définis :

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

Un exemple simple utilisant 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

Mais dans tous les cas, vous pouvez toujours ajuster le script et le rendre plus ou moins agressif - selon ce que votre infrastructure requiert.

Et quelques mots sur Graphite et les métriques. Un tableau de bord Grafana peut être construit en quelques minutes seulement en utilisant deux types de métriques centrales :

Métriques de flux : **network.flows.{SRC_IP}*to*{DST_IP}.{pps,mbps}.{rx,tx}**
Métriques IP : **network.ips.{IP_ADDRESS}.{pps,mbps}.{rx,tx}**

Vous pouvez trouver plus de détails sur FastFlowIPs dans le dépôt lui-même : https://github.com/denisix/fastflowips et vous pouvez toujours soutenir l’auteur ou contribuer à l’évolution de ce petit mais déjà puissant outil.

Architecture en 3 paragraphes (sans la souffrance)

Si nous décrivons l’outil en langage humain, à l’intérieur c’est un petit service Go propre qui écoute les paquets NetFlow, les analyse en composants, et construit des statistiques simples par IP : pps, mbps, entrant/sortant - basiquement, qui fait du bruit dans le réseau et pourquoi. Toutes les mathématiques sont faites à la volée - Go est parfait pour des opérations légères mais à haut débit comme celle-ci.

Les données sont agrégées dans de petites structures en mémoire, triées, et périodiquement envoyées vers l’extérieur : soit vers Graphite/Grafana, soit vers tout autre récepteur que vous spécifiez. Le blocage IP via script externe est implémenté à travers des seuils PPS/Mbps et un appel à BanScript - juste au cas où quelqu’un décide soudainement d’organiser un petit festival DDoS local.

Le meilleur : c’est un binaire unique et propre sans tas de dépendances et sans l’habituel “enfer des petites entreprises open-source”. Les configs sont passées via des flags, les stats sont collectées directement, la logique est transparente. Au final, nous avons obtenu un outil léger et honnête qui fait exactement ce dont nous avons besoin - pas de magie excessive, pas de démons lourds attachés.

Résultats après quelques jours

Le processus de debugging s’est avéré beaucoup plus long et compliqué que l’écriture de l’outil lui-même. Initialement, nous n’avions même pas prévu de définir des valeurs de seuil pour FastFlowIPs, donc plusieurs fois (beaucoup) Grafana a nerveusement retenu son souffle sous le volume pur de métriques et a refusé de nous les montrer du tout. La légende du tableau de bord contenait tellement d’adresses IP que vous pourriez faire défiler pendant des heures et probablement ne jamais atteindre la fin. Nous avions mal calculé - mais où ?

Le debugging continuait de casser les choses, puis de les stabiliser, puis de casser encore notre FastFlowIPs épuisé, jusqu’à ce qu’il commence à pleurer silencieusement dans des scénarios de cas limites. Il y avait soit trop de métriques, soit trop peu, soit aucune du tout. Apparemment par surcharge émotionnelle. En plus, le plus grand mystère pour nous s’est avéré être les métriques Flows RX/TX, qui se sont légèrement échangées, quelque chose qui était magnifiquement visible en temps réel sur les routeurs VyOS. Les esprits les plus brillants de notre équipe se sont battus avec ceci, et finalement l’objectif a été atteint : les métriques ont été stabilisées, et Grafana a été guéri de son asthme.

Aujourd’hui, nous avons des métriques propres, rangées et informatives qui montrent exactement le trafic réseau dont nous avons besoin :

Quand il est temps de construire votre propre mini-FastNetMon

Construire ses propres vélos, c’est mal. Jusqu’au moment où vous ne pouvez tout simplement plus avancer sans un.

Écrire votre propre outil a absolument du sens quand les solutions existantes sont soit trop lourdes soit trop intelligentes pour votre tâche spécifique. Quand vous n’avez pas besoin de 100500 fonctionnalités, d’intégrations avec une station spatiale, et de tableaux de bord sur 19 moniteurs - quand vous avez juste besoin de chiffres, rapidement et sans migraines.

Vous devriez aussi considérer développer votre propre solution si la situation demande de la flexibilité : vous devez ajouter une métrique à la volée, intégrer une logique anti-DDoS personnalisée, faire jouer le monitoring avec votre matériel capricieux, ou simplement contourner des limitations qui ont soudainement été retirées de votre firmware favori (un chaleureux bonjour à VyOS 1.5).

En bref, construire votre propre outil, c’est une question de contrôle, vitesse, minimalisme, et ne pas dépendre de composants qui disparaissent soudainement des dépôts. Le principal est de se souvenir de la règle d’or : si cela peut être fait plus simplement - faites-le plus simplement.

Et une règle de plus : si ça marche - n’y touchez pas.

Le grand final

Au final, toute cette histoire ne concerne pas le trafic, les DDoS, ou même FastNetMon. Elle concerne le fait que parfois une équipe veut simplement un outil qui fonctionne, ne se casse pas après une mise à jour, et ne transforme pas votre vie en rediffusion d’Évadés de Shawshank.

Nous n’avons pas réinventé la bicyclette - nous avons construit notre propre petit scooter qui convient parfaitement à notre route. Et il n’y a rien de mal à cela. Dans un monde où de massifs projets open-source vivent leur propre vie imprévisible, c’est agréable d’avoir quelque chose à soi - familier, stable, et merveilleusement ennuyeux.

Donc si vous avez déjà regardé un autre outil “parfait mais un peu trop parfait” et pensé : “honnêtement, ce serait plus facile de l’écrire moi-même” - vous pourriez être sur la bonne voie. Faites-le juste intelligemment, avec des tests… et préparez-vous à souffrir un peu.