Agent ReportedIP pour Linux

L'agent est un unique binaire statique qui remplit deux tâches sur un serveur Linux : il maintient la Community Blacklist dans le pare-feu du noyau et il signale les attaquants qu'il trouve dans les journaux de ce serveur. En option, il bloque aussi lui-même ces découvertes locales. Il remplace le script de synchronisation écrit à la main que documente ce site, et il reprend le travail que faisait fail2ban.

Ce qu'il fait

Où aller ensuite

• Installation : les conditions d'utilisation, les vérifications, chaque question, les options et les variables d'un déploiement, un hôte sans systemd.
• Exemples d'installation : Ansible et cloud-init, une image de référence, les panneaux de contrôle, un hôte mail ou base de données, les conteneurs LXC et les pare-feu cloud.
• Configuration : chaque clé de config.yaml, les seuils, l'escalade des bannissements, le courrier, et quand un changement prend effet.
• Détection et règles : les types de source, les scans de ports depuis le journal du noyau, l'ajout d'un journal que l'installateur a manqué, ce qui quitte la machine, et les fichiers de règles.
• Blocage : les deux sortes d'ensembles, comment un bannissement commence et finit, la chaîne dans le noyau, et la levée d'un bannissement.
• Groupes : des bannissements partagés entre vos serveurs et vos sites WordPress, les limites par formule, la liste blanche et le webhook.
• Exploitation : les commandes, les codes de sortie, les unités, la supervision, la réputation de l'adresse de l'hôte, et le tableau de dépannage.
• Licences : une licence par serveur, le budget de signalements, les groupes à partir de Professional, et ce qui tourne sans licence.
• Remplacer fail2ban : la migration en trois étapes, et le chemin du retour.

Prérequis

Rien d'autre. Le binaire est lié statiquement et construit sans cgo : il n'apporte donc aucun interpréteur, aucune bibliothèque partagée, aucun dépôt de paquets et aucun assistant cron à lui. L'agent a été développé et mesuré sur Debian 12 (bookworm) en arm64 avec ISPConfig, nginx, Postfix, pure-ftpd et bind.

ipset ou nftables, et ce que décide auto

Les deux backends font le même travail. Ce qui compte, c'est celui que l'hôte utilise déjà, car deux filtres de paquets qui écrivent la même chaîne INPUT, c'est ainsi qu'un après-midi disparaît.

Seul un binaire qui existe compte, jamais une chaîne de version : iptables --version sur un hôte avec le backend nft dit quelque chose qui a l'air juste et ne veut rien dire. Dès qu'un hôte a synchronisé, le backend choisi est enregistré, et un changement ultérieur exige reportedip-agent sync --migrate-backend au lieu de construire en silence un second jeu de règles.

Vérifier l'hôte d'abord

doctor est la commande à lancer avant d'installer. Elle ne change absolument rien : aucun fichier, aucun répertoire, aucune règle, aucun ensemble. Tout ce qu'elle rapporte, elle l'a lu.

reportedip-agent doctor

Lire le verdict

Relancez doctor après l'installation. Avec une configuration en place, il rapporte les sources configurées au lieu des sources détectées, et il ajoute la dérive d'horloge par source que le démon a mesurée. Une source dont le journal horodate chaque ligne à plus d'une minute de l'horloge système a une fenêtre de comptage qui ne se remplit jamais, et c'est la seule panne qui ressemble exactement à « le détecteur ne marche pas ».

Installation rapide

Trois commandes sur un hôte qui n'a encore rien de tout cela. Lancez-les dans cet ordre et l'agent signale, les listes communautaires sont dans le noyau, et rien n'a été rejeté sans votre accord.

# 1. Install, as root. At a terminal it shows the terms of use and
#    takes a yes, then asks for your key, then three short questions;
#    an Enter answers drop and local bans on.
curl -fsSL https://reportedip.com/agent/install.sh | sh

#    For automation, and for fifty hosts, nothing is asked: the terms
#    are accepted up front and the key comes from the environment.
curl -fsSL https://reportedip.com/agent/install.sh | REPORTEDIP_ACCEPT_TERMS=1 REPORTEDIP_KEY="YOUR_API_KEY" sh

# 2. The first sync builds the chain and the sets. The installation
#    itself touches no firewall rule.
reportedip-agent sync

# 3. See that it ran, and read what would be dropped before it is.
reportedip-agent status
reportedip-agent doctor
reportedip-agent test /var/log/auth.log

Ce que chacune laisse derrière elle : la première pose le binaire dans /usr/local/bin, écrit /etc/reportedip-agent/config.yaml à partir de ce qu'elle a trouvé sur cet hôte et installe les trois unités systemd. La deuxième crée la chaîne de pare-feu et les ensembles, que l'installation ne touche volontairement pas, et les remplit. La troisième est la preuve : status affiche un nombre d'entrées par liste et l'état de licence de cet hôte, doctor nomme ce qui manque, et test rejoue votre propre journal pour montrer quelle adresse aurait franchi quel seuil. Les règles rejettent dès la première synchronisation, car c'est ce que l'installation écrit : la liste blanche est donc à faire avant cette synchronisation et pas deux jours après. Répondez plutôt log pour un hôte sur lequel vous voulez d'abord lire un journal. La page d'installation est la même installation expliquée en entier, et ce détail est sa raison d'être.

La première heure, dans l'ordre

Chaque étape répond à une question dont dépend la suivante. Dans un autre ordre, une installation qui fonctionne a l'air cassée.

1. reportedip-agent doctor. Avant tout le reste, car c'est la seule commande qui ne change rien.
2. reportedip-agent sync. La première exécution construit la chaîne, crée les ensembles et télécharge les listes configurées, l'une après l'autre avec une courte pause entre elles.
3. reportedip-agent status. Vérifiez que chaque liste configurée a un nombre d'IPv4 plausible, que la chaîne dit ok, que la liste blanche contient les adresses attendues, et que account montre votre rôle et l'état de licence de cet hôte.
4. Corrigez la liste blanche. L'installateur y a mis l'adresse d'où venait votre session SSH, ce qui est une supposition. Remplacez-la par la plage depuis laquelle vous administrez vraiment, et ajoutez votre supervision, votre hôte de sauvegarde et la plage de votre bureau.
5. Relisez status après un jour. Les compteurs de paquets de la chaîne disent ce que les règles ont réellement arrêté, et ban list dit quelles adresses cet hôte a attrapées dans ses propres journaux.
6. Seulement sur un hôte pour lequel vous avez répondu log : les règles sont entièrement construites et correspondent, elles enregistrent seulement au lieu de rejeter, le journal du noyau montre donc exactement ce que drop aurait coupé. Lisez un journal, puis passez en mode: drop et lancez sync, qui reconstruit les règles.

reportedip-agent doctor
reportedip-agent sync
reportedip-agent status
reportedip-agent whitelist add 203.0.113.0/24 "management"
reportedip-agent whitelist add 198.51.100.7   "monitoring"
reportedip-agent whitelist list

Mises à jour et notes de version

L'agent cherche une nouvelle version toutes les six heures, pendant la synchronisation. Il vérifie le téléchargement contre une signature Ed25519 avec la clé publique intégrée au binaire, remet en place le binaire en cours d'exécution si le remplacement échoue et redémarre lui-même le service de surveillance. reportedip-agent update fait la même chose à la demande, et update --check ne rapporte que ce qui est publié.

Relancer la commande d'installation met également à jour un hôte. Un hôte sous la version minimale prise en charge par le service se met quand même à jour lui-même ; d'ici là, l'agent le signale dans son journal, dans status (exit 1) et dans update --check. Les retours à une version antérieure sont refusés en général, un hôte qui a récupéré une version plus récente ne revient donc pas en arrière de lui-même.

Ce que la version actuelle a changé est public et ne demande aucune clé :

curl -s https://reportedip.com/agent/whats-new
reportedip-agent update --check

Les modifications de la REST API elle-même, donc les champs de réponse et les codes de statut qui concernent une intégration, figurent plutôt dans le Changelog de l'API.

Dernières versions

• 0.3.41 : --admin-ip accepte désormais vraiment une plage CIDR. Jusqu'à 0.3.40, une plage était réduite à son adresse réseau, et seule cette adresse arrivait dans la liste blanche automatique. Avec backend: auto, l'agent préfère ipset, et les indications de l'installateur le disent maintenant.
• 0.3.40 : status --json pour la supervision : un document au schéma 1, avec le même verdict et le même code de sortie que le texte, sans requête vers l'API, et une configuration cassée (exit 2) produit quand même un document. status signale désormais un démon watch arrêté par l'exit 1 : le démon laisse un signal de vie toutes les 30 secondes, et un signal de plus de deux minutes compte comme arrêté. La mise en place pour les systèmes de supervision courants se trouve sous Supervision.
• 0.3.39 : la règle de scan de ports ne bannit plus les clients FTP en mode passif. Chaque connexion de données va vers un port que le serveur ouvre pour ce seul transfert, la règle ne connaissait les ports en écoute que depuis la dernière synchronisation, et l'envoi d'un dossier ressemblait donc à un scan en quelques secondes. La règle demande désormais au noyau si une socket écoute sur le port à cet instant (-m socket --nowildcard avec iptables, socket transparent avec nftables), et la plage passive d'un pure-ftpd, proftpd ou vsftpd en cours d'exécution est lue dans sa configuration et exclue de la règle. Pour un serveur sans plage configurée, c'est la plage de ports éphémères du noyau qui est exclue. La chaîne est reconstruite une fois à la synchronisation suivante.
• 0.3.38 : install accepte le niveau de journalisation, par --log-level debug|info|warn|error ou par REPORTEDIP_LOG_LEVEL. La valeur par défaut reste warn. Un déploiement qui veut tout suivre sur chaque hôte dit info une seule fois au lieu de modifier ensuite la configuration de chaque hôte, et un niveau que l'analyseur refuserait est refusé avant que quoi que ce soit ne soit écrit.
• 0.3.37 : un service qui n'écoute que sur la boucle locale n'est plus considéré comme joignable. La sonde de ports comptait chaque écouteur de la table du noyau quelle que soit l'adresse à laquelle il était lié, si bien que le résolveur local qui tient 127.0.0.53:53 sur un hôte Debian ordinaire ressemblait à un serveur de noms, et un serveur de messagerie qui ne prend le courrier que depuis sa propre machine ressemblait à un serveur ouvert sur Internet. Un port qui a une socket de boucle locale à côté d'une vraie compte toujours. Cela décide aussi quels ports la règle de scan de ports traite comme ouverts.
• 0.3.35 : doctor nomme un journal que cet hôte écrit et que ne lit aucune source, et indique où ajouter la source. La détection ne s'exécute qu'une fois, à l'installation, et cela reste ainsi, car un service arrêté pour une maintenance ne doit jamais désactiver une source. L'autre direction n'avait personne pour la surveiller : un serveur de messagerie installé sur un hôte qui n'en avait pas jusque-là passait inaperçu, et l'hôte paraissait sain pendant que ce service restait sans surveillance. Le constat vaut un code de sortie 1.
• 0.3.34 : install lit les journaux web dans la configuration du serveur web lui-même, y compris les fichiers d'hôtes virtuels sous conf.d et sites-enabled, au lieu d'une liste de noms par défaut. Un vrai hébergement nomme ses journaux d'après le site, les chemins par défaut trouvaient donc le journal par défaut et manquaient le reste : sur un hôte mesuré, deux autres journaux, dont un journal d'accès avec de vraies adresses, seraient restés non lus. Un journal dont le format masque l'adresse du client est toujours laissé de côté, et chaque journal repris ainsi est nommé sur une ligne à l'installation.
• 0.3.32 : status ne qualifie plus un hôte de degraded parce que sa liste de groupe est vide, ce qui est l'état normal d'une clé qui n'est dans aucun groupe, et doctor n'affirme plus qu'il n'y a aucune source de journal sur un hôte dont le sshd écrit dans le journal de systemd au lieu d'un fichier.
• 0.3.29 : une installation neuve écrit log_level: warn au lieu de info, un nouvel hôte reste donc silencieux dans le journal de systemd jusqu'à ce que quelque chose réclame l'attention. Les lignes de routine, une liste mise à jour, un signalement mis en file, un bannissement local posé, sont inchangées et à un mot de distance. Un hôte déjà installé garde ce que dit son fichier de configuration.
• 0.3.27 : la liste blanche du groupe : les adresses et préfixes qu'un groupe de votre compte nomme ne sont jamais bloqués ni signalés par aucun membre. La synchronisation la lit avec la liste de groupe, l'écrit dans group-whitelist sous le répertoire d'état et l'applique dans le même passage à l'ensemble de liste blanche du noyau, au filtre des listes et au filtre de signalement ; whitelist list et status affichent les entrées avec leurs notes. La liste blanche de cet hôte, la liste blanche automatique et les couches intégrées restent telles quelles.
• 0.3.26 : un scan de ports rapide restait sous son propre seuil : la règle de scan journalisait dix SYN par minute avec la rafale par défaut du noyau de cinq, un scanner qui sonde mille ports en quelques secondes laissait donc cinq lignes, et la règle en demande dix. La règle admet désormais une rafale de vingt, les vingt premières sondes d'un scan sont journalisées d'un coup, et le débit garde ensuite le journal silencieux. La chaîne est reconstruite une fois.
• 0.3.25 : un hôte dont la clé n'est dans aucun groupe perdait sa chaîne avec 0.3.24, parce que l'ensemble de groupe n'est créé que par son premier flux et que la règle qui le nomme était refusée. Chaque ensemble de liste est désormais créé avant qu'une règle ne le nomme. 0.3.24 a été retirée.
• 0.3.24 : la liste de groupe group dans l'ensemble rip-group sur tous les ports ; la réputation de l'adresse depuis laquelle cet hôte signale, comme condition de santé reputation ; la détection de scans de ports depuis le journal du noyau avec la source scan. La chaîne est reconstruite une fois après cette mise à jour et ses compteurs de paquets repartent de zéro.

Consommation de ressources

Mesuré sur un hôte Debian 12 arm64 avec sept fichiers de journaux suivis par l'agent : 16,6 Mo de mémoire résidente. Il n'y a pas d'interpréteur à lancer, pas de base de données et pas de répertoire de cache à réchauffer, et c'est l'essentiel de l'explication de ce petit chiffre.

Ce que l'agent n'est pas

Ce n'est pas un antivirus, pas un pare-feu applicatif web et pas un remplacement d'Imunify360. Il ne lit pas vos fichiers, n'examine pas les corps de requête et ne met rien en quarantaine. Il bloque et signale des adresses, et il le fait sur une surface petite et vérifiable. Pour une protection au niveau d'une requête unique sur un site WordPress, prenez plutôt le plugin Hive. Les deux tournent sur la même machine sans se gêner.

Dernière mise à jour: 30. septembre 2026 · Maintenu par l’équipe ReportedIP