Versions

ReportedIP Linux Agent 0.3.48 : supervision, contrôle des règles et moins de blocages à tort

9 octobre 2026 · Patrick Schlesinger

ReportedIP Linux Agent 0.3.48 fournit aux systèmes de supervision un contrôle d’état en JSON, permet aux opérateurs de fixer une durée de blocage par règle, de simuler une règle et d’écarter des lignes de journal connues comme inoffensives, et ne bloque plus les clients FTP, les administrateurs WordPress ni les relais de messagerie filtrants. Elle clôt une série de 21 versions publiées entre le 28 septembre et le 9 octobre 2026, pour la plupart issues de mesures sur les serveurs où l’agent tourne déjà.

Un serveur dont les mises à jour automatiques sont actives récupère la 0.3.48 lors de sa prochaine vérification, que la synchronisation effectue toutes les six heures. Tout le reste sur l’agent se trouve sur la page produit du Linux Agent et dans la documentation de l’agent.

Qu’est-ce qui a changé entre Linux Agent 0.3.27 et 0.3.48 ?

Domaine	Versions	Changement principal
Supervision	0.3.31, 0.3.32, 0.3.40	status --json, signal de vie du démon, plus de fausse alerte sur les serveurs sans groupe
Contrôle des règles	0.3.43, 0.3.45	Durée de blocage par règle, simulation, motifs à ignorer, règles de l’opérateur en premier
Afflux de bots	0.3.44, 0.3.46	Alarme de volume par journal web, règle d’exploration livrée en simulation
Moins de blocages à tort	0.3.39, 0.3.42, 0.3.47, 0.3.48	FTP en mode passif, ressources de page refusées, admin-ajax de WordPress, relais de messagerie filtrants
Installation et diagnostic	0.3.29, 0.3.30, 0.3.34 à 0.3.38, 0.3.41	Journaux web lus dans la configuration du serveur, niveaux de journalisation, doctor trouve les services non surveillés

La liste de groupe et la liste blanche de groupe sont arrivées juste avant cette série, avec les versions 0.3.24 et 0.3.27 ; elles sont traitées dans Partager les blocages d’IP entre serveurs Linux.

Comment superviser le Linux Agent avec Zabbix, Nagios ou Prometheus ?

Depuis la 0.3.40, reportedip-agent status --json affiche un document JSON avec le même verdict et le même code de sortie que la sortie texte : status vaut ok, degraded ou error, et problems liste chaque raison derrière le code 1. Il contient aussi les valeurs utiles en graphique : taille des listes, âge de la dernière synchronisation, blocages actifs, longueur de la file d’attente et état de chaque source de journaux.

• Aucune requête API. La partie compte est la réponse mise en cache par la dernière synchronisation, une vérification toutes les quelques minutes ne coûte donc rien.
• Un contrat stable. Le document porte schema: 1, et sous ce numéro des champs sont uniquement ajoutés.
• Un démon arrêté est une erreur. Le démon de surveillance laisse un signal de vie, et status sort avec le code 1 s’il manque ou date de plus de deux minutes. Avant, les listes restaient dans le noyau et rien ne semblait anormal alors que plus rien n’était détecté.
• Plus de fausses alertes. Un serveur dont la clé n’appartient à aucun groupe n’est plus déclaré dégradé (0.3.32), et la réputation de l’adresse propre du serveur ne déclenche un avertissement qu’à partir d’une confiance de 75, le niveau le plus bas servi par un flux (0.3.31).

Des configurations prêtes à l’emploi pour Zabbix, Nagios et Icinga, Checkmk et Prometheus figurent sur la page supervision ; les codes de sortie sont listés dans exploitation.

Comment contrôler une seule règle de détection ?

La 0.3.43 a ajouté quatre réglages qui demandaient auparavant une surcharge de règle ou une modification de configuration pour tout le serveur :

Réglage	Comment	Effet
Durée de blocage par règle	action.time_minutes dans un fichier de règle	Fixe le premier blocage de cette règle, d’une minute à un an
Simulation	reportedip-agent rules simulate <id>	La règle continue de détecter et de signaler, le blocage devient un avertissement simulated ban dans le journal
Motifs à ignorer	/etc/reportedip-agent/ignore.d/<source>.conf	Écarte les lignes correspondantes avant qu’un détecteur ne les voie
Export des blocages	ban list --json ou --plain	Transmet les blocages à nginx, HAProxy ou un script

Les motifs à ignorer sont prévus pour les contrôles d’état, les sondes de supervision et les chemins ACME. Un motif qui avalerait une ligne que les règles livrées sont testées pour détecter est refusé, tout comme un motif qui correspond à la chaîne vide. Depuis la 0.3.45, vos propres règles passent avant les paquets signés et les règles livrées, une règle de l’opérateur ne peut donc plus être masquée par une règle livrée. Une surcharge de politique comme report: false ne place plus une règle sous observation pendant un jour (0.3.43).

Le format des fichiers de règles et les commandes de règles sont décrits sur la page détection ; durées de blocage, simulation et export se trouvent dans blocage.

Que fait l’agent contre les afflux de bots ?

Depuis la 0.3.44, le démon compte chaque ligne de chaque journal qu’il lit et tient pour chaque journal web une ligne de base des lignes par heure. Lorsque l’heure en cours dépasse nettement cette ligne de base, l’état volume passe en avertissement, l’un des 13 états de santé. L’alarme nomme le site le plus bruyant, ne bloque rien et ne signale rien ; un afflux de robots d’exploration relève de la capacité, pas des données communautaires. Elle a besoin de 24 heures complètes de ligne de base avant de pouvoir se déclencher, et volume_factor: 0 dans config.yaml la désactive.

La même version livre la règle web-query-crawl en simulation. Elle cherche les clients qui demandent beaucoup de pages avec une chaîne de requête sans référent propre. Depuis la 0.3.46, elle ne compte que les clients qui se font passer pour un navigateur, un robot qui se présente par son nom n’est donc jamais bloqué par elle. Avant sa livraison, elle a été mesurée sur cinq serveurs pendant deux jours : aucun visiteur ni aucune supervision ne l’a franchie, seulement des robots d’exploration et des bots. Le guide Détecter et contrer les afflux de bots indique quand l’activer.

Quels blocages à tort l’agent a-t-il supprimés ?

• Clients FTP en mode passif (0.3.39). Chaque connexion de données passive ressemblait à une sonde sur un port fermé, et un client d’un serveur infogéré a été bloqué trois fois en une journée. La règle de scan de ports demande désormais au noyau si un socket écoute à cet instant, et la plage passive de pure-ftpd, proftpd et vsftpd est lue dans leur configuration.
• Visiteurs d’une page défectueuse (0.3.42). Une police, une image, une feuille de style ou un script refusé, ainsi que tout ce qui se trouve sous /.well-known/, ne compte plus comme requête bloquée. Les sondes vers /.env ou /.git/ comptent toujours.
• Administrateurs WordPress connectés (0.3.47). admin-ajax.php répond 400 à chaque action sans gestionnaire, et un tableau de bord actif en produit de nombreuses fois par heure. Cette réponse n’est plus comptée ; tous les autres chemins sous /wp-admin/ le sont.
• Relais de messagerie filtrants (0.3.48). Un expéditeur d’enveloppe refusé était compté contre le serveur qui se connecte, et derrière un relais filtrant c’est toujours le relais. Un seul blocage a interrompu la réception du courrier pendant douze heures. Sur 20 jours d’un serveur de messagerie de la flotte, seul le verdict sur le relais change.
• Adresses en liste blanche dans test (0.3.33). La colonne du verdict indique désormais non pour une adresse protégée par la liste blanche.

Quoi de neuf pour l’installation et le diagnostic ?

• Journaux web lus dans la configuration du serveur web (0.3.34). install lit les fichiers vhost sous conf.d et sites-enabled, ce qui trouve les journaux d’accès par site d’un hébergement, et pas seulement les chemins par défaut.
• Niveaux de journalisation (0.3.29, 0.3.38). log_level accepte debug, info, warn ou error ; une nouvelle installation écrit warn. install --log-level et REPORTEDIP_LOG_LEVEL le fixent lors d’un déploiement.
• Remplacer fail2ban (0.3.30). REPORTEDIP_FAIL2BAN_SOURCE=0 écarte fail2ban comme source sur un serveur où il va être retiré.
• Services non surveillés (0.3.35 à 0.3.37). doctor nomme un service qui écoute sur un port ou écrit un journal qu’aucune source ne surveille, juge le journal plutôt que le nom du service et ignore les sockets liés uniquement au loopback.
• Plages d’administration (0.3.41). install --admin-ip conserve une plage CIDR entière dans la liste blanche automatique au lieu de sa seule première adresse.

Chaque mise à jour que l’agent installe lui-même est vérifiée par une signature Ed25519 (RFC 8032) sur les sommes de contrôle publiées, puis lancée une fois avant de remplacer le binaire en cours. Les variables de install.sh sont listées sur la page d’installation, la migration sur remplacer fail2ban.

Questions sur Linux Agent 0.3.48

Dois-je modifier mon config.yaml après la mise à jour ?

Un config.yaml existant continue de fonctionner sans modification, et un serveur garde le niveau de journalisation indiqué dans son fichier. Deux choses changent d’elles-mêmes : l’alarme de volume est active par défaut et émet un avertissement, plus un e-mail si notify.email est renseigné, quand un journal web déborde ; volume_factor: 0 la désactive. Et depuis la 0.3.43, une surcharge qui ne modifie que l’action d’une règle, comme report: false, ne place plus la règle sous observation pendant un jour. Une étape est nécessaire : un serveur installé avant la 0.3.41 avec une plage CIDR pour --admin-ip n’en a que la première adresse et doit ajouter la plage avec whitelist add.

L’alarme de volume bloque-t-elle quelque chose ?

L’alarme de volume ne bloque jamais et ne signale jamais. Elle fait passer l’état volume en avertissement, nomme le site le plus bruyant et renvoie à reportedip-agent status pour la liste complète. Elle s’éteint après une heure calme complète. Bloquer un afflux reste le rôle des règles de détection, par exemple web-query-crawl une fois que vous l’activez.

De quelle offre ai-je besoin pour le Linux Agent ?

L’agent fonctionne avec toutes les offres, Free compris : la détection locale, les blocages locaux et les signalements marchent toujours. Le flux communautaire exige une licence serveur : Professional inclut un serveur, Business trois, Enterprise selon contrat, et à partir de Professional d’autres serveurs peuvent être ajoutés par hôte. Les détails sont sur la page des licences.

Pour aller plus loin

• Installer le Linux Agent
• Toutes les clés de config.yaml
• Exemples de configuration
• Groupes et webhooks

Vous faites tourner WordPress à côté de vos serveurs ? La version Hive 2.1.72 couvre le côté WordPress des mêmes groupes. Le fonctionnement des licences de test est expliqué dans licences de test gratuites pour le Linux Agent.