CFM 4 Linux : Déploiement et administration centralisés des règles Iptables, Netfilter et pare-feu pour Linux

Le problème : quand la gestion de centaines de serveurs devient un véritable cauchemar

Si vous administrez des serveurs Linux depuis quelques années, vous savez exactement de quoi nous parlons. Ces derniers mois, le phénomène est devenu tout simplement intenable : des vagues de plus en plus agressives de bots en provenance d’Asie du Sud-Est, de Chine et de Russie, et plus récemment, une nouvelle génération de robots d’exploration dotés d’IA qui passent au crible chaque page de chaque site web, ignorant complètement le fichier robots.txt et toute forme de bonne conduite numérique.

Chez Managedserver.it, nous gérons un parc de machines réparti à l'échelle mondiale. Il s'agit de milliers de serveurs Linux hébergés chez OVH, Hetzner, Aruba, AWS, Azure, Google Cloud et sur site chez nos clients en Italie, en Europe et ailleurs. Pendant environ six mois, nous avons reçu un flot incessant de tickets : « Le site est lent », « Le serveur est surchargé », « Il y a un problème ». Et dans la grande majorité des cas, la cause était la même : du trafic indésirable. Des bots bombardant les API, des robots d'exploration téléchargeant des sites web entiers, des attaques par force brute sur SSH et des analyses de ports à grande échelle.

La réponse classique était toujours la même : se connecter au serveur via SSH, analyser les journaux, identifier les adresses IP, ajouter manuellement des règles iptables, éventuellement configurer Fail2ban, vérifier qu’aucune autre règle n’avait été enfreinte. Puis passer au serveur suivant. Et à celui d’après. Et ainsi de suite.

C'était devenu une activité à temps plein qui ne se développait pas.

Le moment où nous avons dit « ça suffit »

Le point de rupture est survenu lors d'une semaine particulièrement chargée où nous avons dû gérer simultanément une attaque DDoS distribuée sur une douzaine de serveurs clients, une vague d'exploration agressive par GPTBot et ClaudeBot sur des dizaines de sites WordPress, et une série d'analyses automatisées sur des plages d'adresses IP hébergeant plusieurs serveurs clients.

Notre flux de travail était terriblement fragmenté :

• Ligne de commande Bash sur chaque serveur individuel pour appliquer les règles iptables
• netdata pour surveiller les ressources, mais sur une interface distincte pour chaque serveur
• UptimeRobot pour les alertes de disponibilité, avec des notifications arrivant sans contexte
• Feuilles de calcul pour garder une trace des règles appliquées et de leur application.

Nous n'avions pas de vue d'ensemble claire. Il nous était impossible de voir immédiatement quels serveurs appliquaient les mêmes règles, lesquels étaient protégés contre une plage d'adresses IP spécifique et lesquels ne l'étaient pas. Appliquer une nouvelle règle de blocage à tous les serveurs impliquait de se connecter un par un, avec le risque réel d'oublier une machine ou, pire encore, d'insérer une règle erronée bloquant du trafic légitime sans possibilité de retour en arrière rapide.

Nous avions besoin d'un outil unique et centralisé qui nous donne un contrôle total.

Et comme nous ne trouvions rien sur le marché qui réponde exactement à nos besoins (un logiciel léger, compatible avec toutes les distributions Linux et ne nécessitant ni agents lourds ni dépendances complexes), nous avons décidé de le construire nous-mêmes.

C’est ainsi que naquit CFM 4 Linux — Centralized Firewall Manager — ou plus simplement, CFM.

Architecture : Un serveur, plusieurs agents, aucun problème de NAT

Avant de passer en revue les fonctionnalités, un petit mot sur l'architecture s'impose, car c'est l'un des choix de conception dont nous sommes le plus satisfaits.

Le CFM est composé de deux éléments :

Le serveur (la « salle de contrôle »)

Le serveur est une application web construite dans PHP 8.3 avec Nginx e PostgreSQL 18 en tant que base de données. Le choix de PostgreSQL n'est pas accidentel : son type natif CIDR Les index GIST nous permettent d'interroger les adresses IP avec une rapidité et une précision que MySQL ne pouvait offrir. JSONB pour les données structurées, des fonctionnalités d'agrégation avancées et des déclencheurs garantissent l'immuabilité des journaux d'audit.

Le serveur propose une console web moderne, conçue avec Tabler (un framework Bootstrap 5 pour les tableaux de bord d'administration), offrant une interface épurée et réactive, agréable à utiliser pendant des heures. Elle prend en charge les thèmes clair et sombre, et – pour les nostalgiques – un mode « Matrix » avec un effet de phosphore vert sur fond noir, évoquant les lignes de balayage des écrans cathodiques.

L’agent (le « soldat sur le terrain »)

L'agent est un unique fichier binaire statique écrit en Go 1.22 , compilé pour Linux amd64 et arm64. Aucune dépendance, aucun environnement d'exécution à installer, aucune bibliothèque partagée. Il suffit de le télécharger, de le rendre exécutable et de le lancer. C'est tout.

L'agent fonctionne selon un modèle de type « pull » : il contacte périodiquement le serveur via HTTPS pour vérifier la présence de nouveautés, télécharger la politique mise à jour et l'appliquer. Cette solution contourne élégamment les problèmes liés à la NAT et aux pare-feu intermédiaires : inutile d'ouvrir des ports entrants sur les serveurs gérés, ni de configurer de VPN. Si le serveur peut établir une connexion HTTPS sortante, tout fonctionne.

L'authentification s'effectue via un jeton Bearer (hachage SHA-256 stocké dans la base de données), et l'inscription initiale utilise des jetons à usage unique. Les modifications de politique sont détectées via les ETags HTTP ; si aucune nouveauté n'est détectée, l'agent reçoit un code 304 Not Modified et n'utilise ni bande passante ni ressources inutilement.

Comment les règles sont appliquées

L'agent détecte automatiquement le pare-feu dorsal disponible sur le système :

• iptables (Le classique, disponible partout)
• nftables (le successeur moderne, avec des ensembles nommés pour une recherche en O(1))
• pare-feu (RHEL/CentOS/Fedora, avec repli intelligent)

Les règles sont appliquées à l'aide de chaînes personnalisées (CFM_SAFETY, CFM_INPUT, CFM_FORWARD) à travers iptables-restore --noflushLe drapeau --noflush c'est fondamental : cela signifie que CFM touche seulement ses chaînes, sans interférer avec Fail2ban, CSF, Docker ou tout autre outil gérant ses propres règles iptables sur le même serveur. La coexistence est garantie par conception.

La chaine CFM_SAFETY Il est inséré en position 1 sur la chaîne INPUT avec la priorité maximale et contient :

• La règle ESTABLISHED/RELATED (le trafic provenant de connexions déjà établies n'est jamais bloqué)
• La boucle de retour (idem pour des raisons évidentes)
• Les adresses IP des interfaces locales du serveur (pour empêcher le nœud de se bloquer lui-même)
• L'adresse IP du serveur CFM (pour ne jamais perdre la connectivité de gestion)
• Les serveurs de noms DNS du système et le DNS public le plus courant (pour éviter de perturber la résolution DNS)
• La liste blanche mondiale (adresses IP qui doivent toujours être joignables, quoi qu'il arrive)

Les règles de blocage ne sont appliquées qu'après la mise en place de la chaîne de sécurité. CFM_INPUT e CFM_FORWARD.

En cas d'échec de l'application des règles, l'agent rétablit automatiquement la configuration précédente, garantissant ainsi que le serveur ne se trouve jamais dans un état incohérent.

Le tableau de bord : Tout est sous contrôle en un coup d'œil

Lorsque vous vous connectez à CFM, la première chose que vous voyez est le tableau de bord. Et il est conçu pour répondre à la question la plus importante : « Quoi de neuf ? »

Les cartes KPI en haut

Une rangée de cartes colorées vous indique immédiatement :

• Nœuds actifs / périmé / révoqué / total
• Règles de politique actif
• Géoblocs attivi
• Blocs ASN attivi
• whitelist entrées
• Groupes configuration
• Flux de menaces attivi
• Remplacer spécifique au nœud
• Blocs temporaires (dernières 24 heures)

En cas de situations nécessitant une attention particulière (pare-feu désactivés, nœuds désynchronisés, blocages expirant), un panneau d'avertissement orange s'affiche automatiquement avec les détails.

La carte du monde

Au centre du tableau de bord se trouve une carte interactive (basée sur amCharts) affichant la répartition géographique de vos nœuds. Chaque point représente un serveur géré, sa couleur indiquant son statut. C'est un outil extrêmement pratique pour obtenir un aperçu visuel immédiat de votre infrastructure.

Chronologie des activités

À droite, une chronologie affiche les actions récentes : qui a ajouté une règle, qui a modifié une dérogation, quand un nœud a été synchronisé pour la dernière fois. C’est le « fil d’actualités » de votre pare-feu.

Graphique de synchronisation

Un graphique dédié affiche l'état de synchronisation des nœuds au fil du temps : combien sont alignés sur la dernière politique, combien sont en retard et combien ont rencontré des erreurs.

Gestion des politiques : le cœur de la CFM

La page « Stratégie » est l'endroit où tout se joue. C'est le point central à partir duquel vous pouvez contrôler simultanément les règles de pare-feu de tous vos serveurs.

La liste blanche mondiale

En haut de la page, vous trouverez la liste blanche globale : les adresses IP et les CIDR qui doivent toujours être accessibles sur tous les nœuds, quelles que soient les règles de blocage. Chaque entrée requiert une justification obligatoire (pour la traçabilité) et peut inclure une date d’expiration facultative.

La liste blanche est puissante : vous pouvez ajouter des adresses IP individuelles (93.184.216.34), CIDR (10.0.0.0/24), plage d'adresses IP (192.168.1.100-192.168.1.200 — qui sont automatiquement convertis en ensemble CIDR minimal), et même les entiers ASN (AS13335 pour Cloudflare, par exemple, qui résout automatiquement tous les préfixes IPv4 et IPv6 à partir du système autonome).

Les règles de la liste blanche sont insérées dans la chaîne CFM_SAFETY avec cible ACCEPT et traité première En cas de blocage d'une adresse IP, si celle-ci est à la fois bloquée et autorisée, c'est la liste blanche qui prévaut.

Les règles de blocage

Le tableau des règles actives affiche toutes les politiques en vigueur, avec :

• CIDR de l'adresse IP bloquée
• Direction (Entrée, transmission ou les deux)
• action (Abandonner ou refuser)
• Protocole e Port (facultatif — pour les blocs chirurgicaux)
• terrains
• date limite (badge de couleur indiquant le temps restant)
• Qui a créé la règle

Au-dessus du tableau, vous trouverez une barre de recherche en temps réel et des filtres par direction, action et statut (permanent, temporaire, expirant). La pagination permet de gérer facilement les politiques comportant des milliers de règles.

Le formulaire d'ajout de règle accepte des entrées flexibles. Vous pouvez saisir :

• Une seule adresse IP : 185.220.101.34
• Un CIDR : 185.220.101.0/24
• Une gamme : 185.220.101.1-185.220.101.50
• Un ASN : AS4134 (China Telecom — et CFM résout automatiquement tous les préfixes)
• Un code pays : CN (et CFM bloque tous les préfixes GeoIP associés)

Pour chaque règle, vous pouvez spécifier une durée : permanente, 1 heure, 3 heures, 6 heures, 12 heures, 24 heures, 3 jours, 7 jours ou 30 jours. Les règles temporaires expirent automatiquement et sont supprimées par une tâche cron dédiée.

Géoblocage

C'est l'une des fonctionnalités que nous utilisons le plus. La section Géoblocage vous permet de bloquer des pays entiers ou des continents entiers en un seul clic.

Deux modes d'affichage :

• Par pays: une liste de tous les pays avec cases à cocher, barre de recherche et action rapide
• Par continentSélectionnez un continent : tous les pays qui s’y trouvent seront bloqués/débloqués.

Les données GeoIP proviennent de deux sources configurables :

• DB-IP Lite (base de données gratuite et de haute précision)
• Délégations RIR (les registres Internet régionaux : RIPE, ARIN, APNIC, LACNIC, AFRINIC)

Le système importe les préfixes CIDR associés à chaque pays et les insère comme des règles de politique normales, à ceci près qu'ils sont marqués « GEO : » dans la raison et sont protégés contre toute suppression accidentelle (vous ne pouvez pas les supprimer du tableau des règles — vous devez utiliser la section Geo dédiée).

Lorsque l'agent applique un géoblocage à grande échelle (bloquer la Chine signifie environ 80 000 préfixes IPv4), il utilise des stratégies optimisées pour éviter de créer des centaines de milliers de règles iptables linéaires :

• Su nftables: utiliser ensemble nommé avec indicateur d'intervalle — Recherche en O(1) quel que soit le nombre de préfixes
• Su iptables: utiliser un système propriétaire permettant d'améliorer les performances et de réduire la taille des enregistrements en mémoire.

Le blocage pour ASN

Le numéro de système autonome (ASN) est l'identifiant d'un réseau. Au lieu de bloquer des adresses IP individuelles, vous pouvez bloquer un réseau entier par ASN. CFM résout automatiquement l'ASN en ses préfixes IP à l'aide de deux sources :

• API RIPEstat (source primaire)
• Vue BGP (se retirer)

Le blocage des ASN est dynamique : le bouton « Actualiser tout » permet de résoudre à nouveau tous les ASN bloqués afin de prendre en compte les nouveaux préfixes ajoutés par l’opérateur réseau. Un maximum de 5 000 préfixes par ASN est autorisé afin d’éviter les abus.

Flux de menaces

CFM peut importer automatiquement les listes de blocage provenant de sources de renseignements sur les menaces :

• FireHOL (agrégateur de listes de blocage)
• Spamhaus DROP (Ne pas router ni peering)
• Abus.ch (logiciels malveillants, botnet C2)
• Et bien d'autres encore — avec la possibilité d'ajouter des flux personnalisés

Chaque flux est automatiquement mis à jour selon la planification configurée, et les règles sont étiquetées avec « Flux : nom_du_flux » pour une identification facile.

Opérations en vrac

En cas d'urgence (par exemple : c'est vendredi soir et un réseau de zombies attaque 47 serveurs), CFM propose :

• importations en vracCollez une liste d'adresses IP (une par ligne, les commentaires # sont pris en charge), choisissez la direction, l'action, la durée et la motivation, prévisualisez puis exécutez en un clic.
• Suppression en masseSélectionnez les règles à l'aide des cases à cocher et supprimez-les en masse.
• Supprimer les filtres: appliquer un filtre et supprimer toutes les règles visibles
• Configuration d'exportation/importationExportez la configuration complète (politique, liste blanche, zone géographique, ASN, groupes, remplacements) dans un fichier JSON et réimportez-la sur une autre instance CFM.

Gestion des versions des politiques

Chaque modification apportée à la politique (ajout, suppression ou importation) génère automatiquement une nouvelle version immuable . Aucun brouillon à enregistrer manuellement : modifiez un élément, une nouvelle version est créée et, lors de la prochaine interrogation, les agents la téléchargent.

Depuis la page Politique historique, vous pouvez :

• Voir toutes les versions avec horodatage, auteur et nombre de règles
• Comparer deux versions côte à côte (différence visuelle)
• Réussir rollback vers n'importe quelle version précédente en un seul clic

La restauration d'une version antérieure ne supprime pas la version actuelle ; elle crée une nouvelle version identique à la version cible. L'historique est systématiquement conservé pour une traçabilité complète.

Mode brouillon

Pour les modifications complexes nécessitant plusieurs étapes, CFM propose un mode brouillon . Lorsque vous l'activez :

• Les agents continuent de voir la version « gelée » (celle qui est active lorsque le brouillon est activé).
• Vous travaillez sur la version en direct dans la console web
• Une bannière jaune vous indique le nombre de modifications en attente.
• Vous pouvez voir leavant-première des différences (règles ajoutées/supprimées)
• Lorsque vous serez satisfait, publiez le brouillon et tous les agents recevront la nouvelle version.
• Si vous changez d'avis, mis au rebut Le repêchage et tout le reste reviennent à la normale.

Ceci est particulièrement utile lorsque vous devez procéder à une restructuration importante des règles sans risquer d'exposer les agents à des politiques intermédiaires incomplètes.

Les nœuds : gestion individuelle et collective

La page des nœuds

La liste des nœuds représente votre flotte. Affichable en mode liste (tableau détaillé) ou en mode carte (grille visuelle avec statut), chaque nœud affiche :

• Nom, adresse IP, système d'exploitation
• Statut (actif/inactif/révoqué) avec badge de couleur
• Dernière synchronisation
• Version de la politique appliquée
• Version de l'agent installé (avec indication si une mise à jour est disponible)
• État du pare-feu (activé/désactivé)
• Basculer entre différents moniteurs (CPU, RAM, trafic, disques, réseau)

L'inscription d'un nouveau nœud est simple : générez un jeton depuis la console, exécutez la commande d'inscription sur l'agent, et le nœud apparaît automatiquement dans la liste.

Détail du nœud

En cliquant sur un nœud, une page de détails très complète s'ouvre :

Fiche d'information en haut avec nom d'hôte, adresse IP, système d'exploitation, temps écoulé depuis le dernier contact, état de la synchronisation et bouton pour activer/désactiver le pare-feu sur ce nœud spécifique.

Règles spécifiques à un nœud : vous pouvez ajouter des règles qui s’appliquent uniquement à ce nœud : « autoriser » (liste blanche locale) ou « refuser » (blocage local). C’est idéal dans des situations comme celle où le serveur du client X doit être accessible depuis son adresse IP professionnelle, même si cette adresse IP fait partie d’une plage bloquée au niveau global.

Exclusions : Vous pouvez exclure des règles globales spécifiques à un nœud. Si vous avez bloqué globalement un certain CIDR, mais qu’un nœud spécifique doit y accéder, l’exclure résout le problème sans affecter la politique globale.

Politique géographique par nœud : Chaque nœud peut avoir sa propre politique géographique indépendante, avec trois modes :

• Hériter: suit la politique mondiale
• Autoriser uniquementSeuls les pays figurant sur la liste blanche peuvent accéder au serveur (utile pour les serveurs desservant un marché spécifique).
• Refuser uniquement: bloquer certains pays (comportement par défaut dans la plupart des cas)

Avec des actions rapides pour bloquer/autoriser des continents entiers ou rechercher des pays individuels.

Historique de synchronisation : Tableau répertoriant chaque synchronisation d'agent — horodatage, version de la politique, résultat (appliqué/échoué/annulé), nombre de règles appliquées et tout message d'erreur.

Appartenances aux groupes : Liste des groupes dont le nœud est membre, avec un lien direct vers la gestion des groupes.

Étiquettes : paires clé-valeur personnalisables (environnement : production, client : acme, rôle : serveur web) utiles pour organiser et filtrer les nœuds.

I Gruppi

Les groupes permettent d'organiser les nœuds par client, environnement, rôle ou tout autre critère. Un nœud peut appartenir à plusieurs groupes simultanément.

La force des groupes réside dans la possibilité de définir des règles spécifiques à chaque groupe : des règles qui s’appliquent uniquement aux nœuds membres de ce groupe, en plus des règles globales. Idéal pour des scénarios comme :

• « Tous les serveurs clients ACME doivent bloquer cette plage d'adresses IP. »
• « Tous les serveurs de production doivent disposer de cette liste blanche supplémentaire. »
• « Tous les serveurs web doivent bloquer les ports non standard. »

La politique effective d'un nœud est toujours : règles globales + règles du groupe d'appartenance + substitutions spécifiques au nœud.

Le testeur de politiques

L'une des fonctionnalités les plus utiles au quotidien. Saisissez une adresse IP, un CIDR ou un ASN, et CFM vous indique immédiatement sur quels nœuds le trafic serait bloqué, par quelle règle et quelle action serait appliquée.

C'est inestimable pour le dépannage : « Le client dit qu'il ne peut pas accéder à son serveur, son adresse IP est 203.0.113.45 » → vous la saisissez dans Policy Tester → vous découvrez qu'il est bloqué par la règle GEO:CN car son FAI utilise une plage d'adresses IP initialement attribuée à la Chine → vous ajoutez une autorisation de remplacement pour ce nœud → problème résolu en 30 secondes.

Et puis on s'est dit : « Et si on ajoutait aussi un système de surveillance ? »

Le contrôle centralisé du pare-feu était un atout considérable. Cependant, nous devions toujours jongler entre CFM, Netdata, CheckMK et UptimeRobot pour avoir une vue d'ensemble. À chaque alerte de charge, nous devions ouvrir une nouvelle interface pour comprendre la situation.

Nous nous sommes donc dit : l'agent est déjà sur le serveur, il communique déjà avec le serveur central, pourquoi ne pas lui faire collecter également des données de surveillance ?

Et depuis, CFM est devenu bien plus qu'un simple gestionnaire de pare-feu.

Surveillance de la disponibilité

La page Uptime affiche la disponibilité historique de chaque nœud sur des périodes de 7, 30 et 90 jours.

Pour chaque nœud, voir :

• Pourcentage de disponibilité (avec couleurs : vert > 99.9 %, jaune > 99 %, rouge le reste)
• Nombre de contrôles effectués
• Nombre d'accidents
• Une carte thermique temporelle un élément extensible qui indique visuellement quand le nœud était actif/désactivé

Les données de disponibilité sont dérivées du signal de présence de l'agent : si l'agent ne contacte pas le serveur dans le délai configuré (10 minutes par défaut), le nœud est considéré comme « obsolète » et l'incident est consigné.

CPU Monitor

L'agent lit /proc/loadavg et envoyez les valeurs de charge moyenne à 1, 5 et 15 minutes ainsi que le nombre de threads actifs. Le serveur conserve l'historique et la page de surveillance du processeur affiche :

• Liste de tous les nœuds avec surveillance CPU active
• Colonnes triables : Chargement 1 min, Chargement 5 min, Chargement 15 min, Pourcentage d’utilisation du processeur
• Pour chaque nœud, un graphique extensible avec sélecteur d'intervalle de temps (30 minutes, 1 heure, 3 heures, 6 heures, 12 heures, 24 heures)
• cabillot Live mise à jour automatique toutes les 10 secondes
• Affichage en liste ou en carte

Les groupes de boutons permettant de sélectionner la plage horaire utilisent un style uniforme sur toutes les pages de surveillance : des boutons compacts dont l’état actif est mis en évidence en bleu et une case à cocher « En direct » pour l’actualisation automatique.

Moniteur de RAM

L'agent lit /proc/meminfo et collecte :

• Mémoire totale, disponible et utilisée (en Mo et en pourcentage)
• Tampon et cache
• Échange total et utilisé

La page RAM Monitor affiche des badges synthétiques pour chaque nœud (RAM%, Mo utilisés, Mo en cache, Swap utilisé) et des graphiques extensibles avec les mêmes commandes de plage de temps et une mise à jour en direct que le CPU.

Cela nous a permis d'identifier rapidement les serveurs présentant des fuites de mémoire, des processus incontrôlés ou des configurations de swap incorrectes, le tout à partir d'une seule interface.

Moniteur de disque dur (Santé du disque)

L'agent fait ici quelque chose de particulièrement astucieux : il détecte automatiquement le sous-système de disque utilisé et surveille son état :

• matrice RAID (mdadm) : État de la baie, disques actifs, disques dégradés/défaillants
• Piscine ZFS: état du pool, état du vdev, erreurs de lecture/écriture/somme de contrôle
• Disques simples: Informations SMART (si disponibles)

La page affiche le statut à l'aide de badges de couleur :

• Sain (vert) : tout va bien
• Dégradé (jaune) : attention requise
• Échoué (rouge) : intervention urgente

Pour chaque nœud, vous pouvez afficher les détails pour voir exactement quel disque ou quelle baie présente des problèmes.

Moniteur de disque (Espace disque)

En complément du moniteur de disque dur, le moniteur de disque affiche l'utilisation des partitions :

• Périphérique, point de montage, type de système de fichiers
• Espace total, utilisé, libre (en Mo/Go)
• Pourcentage d'utilisation avec barres de progression colorées
• Graphiques historiques permettant de suivre l'évolution de l'espace utilisé au fil du temps

Les données sont collectées par l'agent toutes les 10 minutes et permettent de prévoir quand l'espace disque sera saturé, avant que cela ne devienne une urgence.

Moniteur réseau (E/S réseau)

L'agent collecte des statistiques pour chaque interface réseau :

• Octets reçus (RX) et transmis (TX)
• Erreurs de réception et d'émission
• Delta entre les lectures successives

Les graphiques illustrent le débit au fil du temps pour chaque interface, ce qui vous permet d'identifier rapidement les saturations de bande passante, les pics anormaux ou les interfaces présentant des erreurs.

Trafic (Statistiques du pare-feu)

Il s'agit de la fonctionnalité qui relie la surveillance au pare-feu. L'agent collecte les compteurs iptables (iptables -L <chain> -v -n -x) pour toutes les chaînes CFM et calcule les deltas entre les lectures.

La page Trafic propose :

• Fiches récapitulativesNombre total de paquets et d'octets traités
• Tableau historique: délai allant de 1 heure à 7 jours
• Chignons hauts pour le trafic du pare-feu
• Détail par nœud avec un graphique à barres des chaînes individuelles

Cela vous indique non seulement le volume de trafic bloqué par vos règles, mais aussi quelles règles sont les plus sollicitées et sur quels nœuds. Les données de trafic sont conservées pendant 30 jours, ce qui est suffisant pour l'analyse des tendances.

La page Traffic Nodes offre les mêmes informations mais organisées par nœud, avec des graphiques extensibles pour chacun et les mêmes contrôles de plage de temps (1h, 3h, 6h, 12h, 24h, 3 jours, 7 jours) + bascule en direct.

Le système d'alerte

La surveillance est utile. Être alerté automatiquement en cas de problème est essentiel.

Le CFM comprend un système d'alerte avancé avec dispositif anti-tempête intégré :

Types d'alertes

• Nœud hors ligne: un nœud n'a pas communiqué depuis plus de X minutes
• Processeur haute performance: la charge moyenne dépasse un seuil pendant une période prolongée
• pic de trafic: pic anormal du trafic du pare-feu
• RAID dégradé: Une grappe RAID ou un pool ZFS n'est pas dans un état optimal

Configuration des règles

Pour chaque type d'alerte, vous pouvez configurer :

• Prénom descriptif
• Soglia (seuil) spécifique au type
• Durée (Combien de minutes consécutives la condition doit-elle être vraie avant de déclencher l'alerte ? – anti-battement)
• Refroidir (Combien de minutes faut-il attendre après une alerte avant d'en envoyer une autre — anti-tempête)
• Portée: tous les nœuds ou un nœud spécifique
• notification de récupération: optionnel, vous avertit lorsque la situation revient à la normale

Canaux de notification

Les notifications peuvent être envoyées via :

• TelegramLe canal préféré de l'équipe : instantané, avec prise en charge de la mise en forme et des émojis
• Email: pour les notifications officielles et la traçabilité
• Webhook: pour les intégrations avec des systèmes externes (Slack, Discord, PagerDuty ou tout point de terminaison HTTP personnalisé)

Chaque canal peut être configuré pour recevoir uniquement certains types d'événements.

L'icône de la cloche

Dans la barre supérieure du CFM, une icône de cloche affiche en temps réel le nombre d'alertes actives, accompagnée d'un badge rouge. En la survolant, une liste déroulante des dernières alertes apparaît, avec des icônes indiquant le type, le nom du nœud concerné et le temps écoulé. Cliquer sur « Tout afficher » permet d'accéder à la page complète de l'alerte, incluant l'historique et la chronologie.

La boîte à outils : la salle de crise de l'ingénieur système

La page « Boîte à outils » est la première que nous ouvrons lorsqu'un rapport arrive. C'est un véritable centre de renseignements opérationnels intégré directement à CFM.

Renseignements rapides

Saisissez une adresse IP et obtenez instantanément :

• DNS inverse (rDNS)
• GéoIP: pays avec drapeau, code ISO
• ASN: numéro et nom de l'organisation
• Préfixe IP di appartenenza
• Statut DNSBL: le nombre de listes noires contenant cette adresse IP (avec les couleurs : vert = propre, jaune = quelques signalements, rouge = très signalée)
• État CFML'adresse IP est-elle autorisée ? Est-elle bloquée ? Par quelle règle ? Est-elle bloquée pour un groupe spécifique ?

Outils d'analyse

Une série d'onglets fournit des outils d'investigation approfondie :

Actions rapides

Depuis cette même page, sans naviguer ailleurs, vous pouvez :

• Blocage rapide: ajouter l'adresse IP à la politique globale avec motif et durée
• Liste blanche rapide: ajouter l'adresse IP à la liste blanche globale
• Blocage rapide ASN: bloquer l'intégralité de l'ASN IP
• Liste blanche rapide ASN: autoriser l'ensemble de l'ASN

La boîte à outils prend également en charge les liens profonds : https://cfm.example.com/toolkit#192.168.1.1 Il ouvre directement la boîte à outils avec l'adresse IP pré-renseignée et l'analyse déjà lancée. Idéal pour l'intégration avec d'autres outils ou le partage de liens au sein de votre équipe.

Client Web SSH : Accès en un clic

Et nous en arrivons ici à l'une des fonctionnalités qui a changé notre quotidien.

Le problème

Lorsqu'une alerte est reçue, le premier réflexe est de se connecter au serveur pour enquêter. Or, cela implique d'ouvrir un terminal, de rechercher le nom d'hôte, de se souvenir (ou de rechercher) des identifiants, de saisir la commande SSH, d'entrer le mot de passe, et enfin de pouvoir commencer. Multipliez cela par les 10 à 15 serveurs à surveiller lors d'un incident, et vous obtenez un flux de travail qui ralentit considérablement la réactivité.

la solution

CFM intègre un client SSH web complet basé sur xterm.js . Depuis la page de détails de n'importe quel nœud, cliquer sur l'icône du terminal ouvre une fenêtre contextuelle avec un véritable terminal SSH dans votre navigateur.

Mais le plus intéressant, c'est le coffre-fort . Chaque nœud peut stocker ses identifiants SSH dans un coffre-fort protégé par une clé principale . Une fois le coffre-fort déverrouillé (il faut saisir la clé principale une seule fois par session), vous pouvez vous connecter à n'importe quel serveur en un seul clic : les identifiants sont automatiquement injectés et la connexion est établie instantanément.

Les identifiants ne transitent jamais en clair par le stockage local du navigateur : ils sont déchiffrés côté serveur et transmis via l’URL à la fenêtre contextuelle, où ils sont immédiatement supprimés de la barre d’adresse pour des raisons de sécurité.

Plusieurs séances

Vous pouvez ouvrir plusieurs terminaux SSH simultanément . Chaque session est représentée par une barre flottante en bas de la page, affichant le nom du nœud. Les barres sont alignées côte à côte et vous permettent de :

• Cliquez pour amener la fenêtre correspondante au premier plan.
• Fermez la session avec le bouton X
• Gardez votre session active pendant que vous naviguez entre les pages CFM

Le système utilise des pulsations via le stockage local avec une logique à deux niveaux : une référence à la fenêtre comme signal principal (insensible à la limitation de fréquence du navigateur) et un délai d’expiration de 30 secondes entre les pulsations comme sécurité. Ceci garantit la visibilité des barres flottantes même lorsque des popups sont en arrière-plan.

Les bons bots : le problème des « bons » bots

Tous les robots ne sont pas malveillants. Google, Bing, Cloudflare, UptimeRobot et de nombreux autres services légitimes utilisent des robots pour indexer, surveiller et diffuser le Web. Les bloquer reviendrait à disparaître des moteurs de recherche ou à perturber des services de surveillance essentiels.

CFM inclut une section « Good Bots » avec une liste présélectionnée de bots légitimes, organisés par catégorie :

• Moteur de rechercheGoogle, Bing, Yandex, DuckDuckGo, Baidu
• Réseaux sociauxFacebook, Twitter, LinkedIn, Pinterest
• CANCloudflare, Fastly, Akamai
• Le MonitoringUptimeRobot, Pingdom, StatusCake
• WebhookStripe, PayPal, GitHub
• AI (les « bonnes ») : OpenAI (pour les intégrations API, pas le robot d'exploration), Anthropic
• CloudAWS, Azure, Google Cloud (contrôles d'intégrité, équilibreur de charge)
• SécuritéLet's Encrypt, CertBot

Cette fonctionnalité vous permet de mettre en œuvre une stratégie de « blocage de tout sauf des éléments reconnus comme légitimes » avec la garantie de ne pas bloquer le trafic légitime essentiel.

La sécurité : pas une question secondaire

La sécurité de CFM a été intégrée dès sa conception, et non ajoutée ultérieurement.

Tourniquets Cloudflare

La page de connexion est protégée par Cloudflare Turnstile , successeur de reCAPTCHA. Contrairement à reCAPTCHA, Turnstile privilégie la confidentialité et ne demande pas aux utilisateurs de sélectionner des feux de circulation ou des bus. La vérification est transparente.

L'installation ne nécessite qu'une clé de site et une clé secrète (disponibles gratuitement depuis le panneau de contrôle Cloudflare). Le système est à continuité de service : même si Cloudflare est inaccessible, la connexion reste possible (mieux vaut se connecter sans CAPTCHA que de rencontrer des difficultés en cas d'urgence).

Authentification à deux facteurs (2FA/TOTP)

Chaque utilisateur peut (et devrait) activer l'authentification à deux facteurs basée sur le TOTP (mot de passe à usage unique basé sur le temps). La configuration est guidée :

1. Scannez le code QR avec votre application préférée (Google Authenticator, Authy, Microsoft Authenticator, 1Password, Bitwarden).
2. Saisissez le code de vérification pour confirmer
3. Téléchargez le codes de récupération (8 codes à usage unique, à conserver précieusement)

À partir de ce moment, chaque connexion nécessite un nom d'utilisateur, un mot de passe et un code TOTP.

Les codes de récupération peuvent être régénérés à tout moment et l'authentification à deux facteurs peut être désactivée (nécessite le code TOTP actuel + le mot de passe, pour empêcher toute désactivation non autorisée).

Rôles et permissions

CFM met en œuvre un système RBAC avec trois rôles :

• Administrateur: accès complet, gestion des utilisateurs, paramètres système
• Opérateur: gestion des politiques, nœuds, surveillance (tout sauf les paramètres système)
• Viewer: Accès en lecture seule à toutes les données (idéal pour la surveillance des équipes ou des clients)

Journal d'audit immuable

Chaque action est enregistrée dans un journal d'audit immuable (protégé par des déclencheurs PostgreSQL qui empêchent les opérations UPDATE et DELETE) :

• Qui a fait quoi ?
• Quand
• Depuis quelle adresse IP ?
• Avec quels paramètres ?

Le journal peut être filtré par type d'action, date, nœud et utilisateur. Il prend en charge la pagination et peut facilement gérer des millions d'enregistrements.

Communication sécurisée

• Toutes les communications agent-serveur se déroulent sur HTTPS
• Les jetons d'authentification sont stockés sous forme de Hachage SHA-256 dans la base de données (le jeton en clair n'est jamais stocké)
• Les mots de passe des utilisateurs sont utilisés Argon2id (le gagnant du concours de hachage de mots de passe)
• Les jetons d'inscription sont jetable (Une fois utilisées, elles deviennent caduques.)
• L'agent vérifie le certificat SSL du serveur (pas d'attaque de l'homme du milieu).

Protections des agents

L'agent lui-même met en œuvre plusieurs protections :

• Refus de 0.0.0.0/0: il est impossible de bloquer tout le trafic, même par erreur
• Liste blanche automatique du serveur CFM: l'agent ne peut jamais bloquer son propre serveur de gestion
• Auto-autorisation des interfaces locales: le nœud ne peut pas se bloquer lui-même
• Liste blanche automatique DNSLes serveurs de noms système et le DNS public (8.8.8.8, 1.1.1.1, 9.9.9.9, etc.) sont toujours accessibles sur le port 53.
• Restauration automatiqueSi l'application des règles échoue, les règles précédentes sont rétablies.
• Assainissement des entrées: protocoles validés, ports limités à 0-65535, commentaires nettoyés contre les injections

Mise à jour automatique de l'agent

Lors de la publication d'une nouvelle version de l'agent, il n'est pas nécessaire de se connecter à des centaines de serveurs pour effectuer la mise à jour. L'agent vérifie automatiquement la disponibilité d'une mise à jour toutes les heures, télécharge le nouveau fichier binaire, vérifie son intégrité grâce au hachage SHA-256 et redémarre avec la nouvelle version.

Depuis la console, vous pouvez :

• Consultez la version installée sur chaque nœud
• Vérifiez si une mise à jour est disponible.
• Forcer la mise à jour de tous les nœuds en un seul clic
• Surveillez les journaux de mise à jour pour chaque nœud

internationalisation

CFM est entièrement localisé en 5 langues :

• Italiano
• anglais
• espagnol
• français
• allemand

La langue est modifiée à la volée à partir du sélecteur situé dans la barre supérieure et est enregistrée dans un cookie + localStorage pour une utilisation persistante.

Statistiques et analyses

La page Statistiques propose des graphiques interactifs Chart.js :

• Nœuds pour l'état au fil du temps: chronologie du nombre de nœuds actifs, obsolètes et révoqués
• Développement des règlesComment votre police d'assurance a évolué au fil du temps
• Distribution de l'état de synchronisation: combien de nœuds sont synchronisés et combien sont désynchronisés
• CIDR principaux bloqués: classement des CIDR les plus présents dans la police d'assurance

Les pages que nous utilisons le plus (utilisation quotidienne réelle)

Après plusieurs mois d'utilisation quotidienne, voici notre flux de travail typique :

Le matin

1. Ouvrons le Tableau de bord pour un aperçu de la situation
2. Vérifions le Alerte (sonnerie dans la barre supérieure) pour tout problème nocturne
3. Un rapide coup d'œil sur le CPU Monitor e Moniteur de RAM pour les anomalies

Lorsqu'un rapport arrive

1. Boîte à outilsNous saisissons l'adresse IP signalée et, en deux secondes, nous savons tout : son origine, son propriétaire, si elle est sur liste noire et si nous l'avons déjà bloquée.
2. S'il faut le bloquer : Blocage rapide Depuis la boîte à outils → règle appliquée sur tous les serveurs en 30 secondes
3. Si vous devez enquêter : SSH en un clic depuis les détails du nœud

Lorsqu'une intervention à grande échelle est nécessaire

1. de confidentialité: ajoutez la plage d'adresses IP ou l'ASN
2. ou: Geo-blocage bloquer un pays entier
3. ou: Flux de menaces pour activer une liste de blocage automatique
4. La politique se propage automatiquement à tous les nœuds.

Pour une surveillance proactive

1. Uptime pour vérifier la disponibilité historique
2. Traffic pour vérifier s'il y a quelque chose d'anormal dans le trafic du pare-feu
3. Moniteur de disque dur pour prévenir les problèmes de disque avant qu'ils ne deviennent des urgences
4. Moniteur réseau pour vérifier la bande passante utilisée

Pile technologique complète

Pour ceux qui souhaitent connaître les détails techniques :

Résultat : des heures de travail réduites à quelques secondes.

Avant CFM, l'application d'une règle de pare-feu à l'ensemble du parc impliquait des heures de travail manuel avec un risque réel d'erreurs et d'oublis.

Aujourd'hui, la même opération nécessite secondes 30Nous saisissons l'adresse IP dans le formulaire, choisissons l'action et appuyons sur Entrée. La règle est automatiquement distribuée à tous les nœuds et appliquée. iptables-restore --noflush (sans perturber quoi que ce soit d'autre), et vérifié par l'agent qui signale le succès au serveur.

En cas de problème, la restauration est automatique. Si nous avons commis une erreur, le versionnage nous permet de la corriger en un clic. Si le client demande « Pourquoi mon adresse IP est-elle bloquée ? », l’outil de test de politiques et le journal d’audit nous fournissent la réponse en 5 secondes.

CFM a transformé la gestion des pare-feu, passant d'une opération manuelle, risquée et non évolutive à un processus centralisé et automatisé avec un réseau de sécurité intégré.

Et la surveillance intégrée a éliminé la nécessité de jongler entre 4 ou 5 outils différents : tout est centralisé, avec une seule interface et une seule connexion.

Ce qui nous attend

CFM est en constante évolution. Notre feuille de route comprend :

• Limitation du débitProtection contre les inondations SYN et limites de connexion directement depuis la console
• Différence visuelle des politiques: comparaison côte à côte des versions avec les différences mises en évidence
• Mise en œuvre de la Commercial GeoIP Max Mind
• Score de réputation IPscore agrégé provenant de plusieurs sources de renseignement
• Règles programmables: activation et désactivation automatiques en fonction de la durée
• API REST publique documentée: pour les intégrations avec des systèmes tiers
• Multi-locataire et contrôle d'accès basé sur les rôles (RBAC) granulaire: pour gérer les équipes et les clients avec des autorisations précises
• Tableau de bord personnalisable: widget glisser-déposer pour adapter l'affichage à vos besoins
• Intégration Fail2banSynchronisation bidirectionnelle avec les jails Fail2ban existantes

conclusion

CFM 4 Linux est né d'un besoin réel, de la frustration quotidienne d'une équipe d'administrateurs système gérant des centaines de serveurs à travers le monde. Il ne s'agit pas d'un projet académique ni d'une preuve de concept : c'est un outil que nous utilisons quotidiennement, sur des serveurs de production, avec de vrais clients.

Si vous gérez plusieurs serveurs Linux et que vous passez trop de temps à copier des règles iptables d'une machine à l'autre, ou si vous êtes fatigué de jongler entre cinq outils différents pour y voir plus clair, CFM pourrait bien être la solution que vous cherchiez.

Nous l'avons construit pour nous-mêmes. Et nous découvrons chaque jour que c'est exactement ce dont nous avions besoin.

Cet article a été rédigé par l'équipe technique de Managedserver.it. CFM 4 Linux est un projet interne développé pour répondre aux besoins opérationnels de notre équipe d'administration système.

Pour toute question, demande de renseignements ou pour savoir si CFM vous convient, contactez-nous à info@managedserver.it.