Sécuriser un cluster : agent, groupes, DNSBL

Pour sécuriser un cluster de serveurs avec ReportedIP, faites tourner le ReportedIP Linux Agent sur chaque nœud Linux et placez leurs clés API dans un groupe : chaque nœud garde alors la blacklist communautaire dans son pare-feu noyau et rejette toute adresse signalée par un autre nœud. Les relais mail peuvent ajouter la DNS / RBL Zone dans le dialogue SMTP, et les hôtes qui ne peuvent pas faire tourner l’agent récupèrent les mêmes données sous forme de flux ou via l’API.

À la parution de cet article en mai 2026, une zone DNS était la seule couche partagée pour tout un cluster. Depuis septembre 2026, l’agent et les groupes couvrent la plupart des nœuds, et la zone reste le bon outil pour les filtres mail et les appliances.

Quelle brique ReportedIP convient à chaque niveau d’un cluster ?

Un cluster se compose rarement d’un seul type de machine. Le tableau associe les niveaux habituels à la partie de ReportedIP qui leur convient. Tous lisent la même base communautaire d’adresses d’attaquants notées.

Niveau du cluster	Ce qui le protège	Comment il lit les données
Hôtes Linux web, applicatifs et bases de données	Linux Agent	Sets noyau
Relais mail	Linux Agent et DNS / RBL Zone	Sets noyau et requêtes DNSBL
Frontaux WordPress	Plugin Hive	Blocages locaux et liste du groupe
Appliances et pare-feu cloud	Blacklist Feed	Export planifié
Backends applicatifs et API	API REST	Vérification du score par requête
Nœuds leurres	Honeypot Server	Signalements uniquement

Comme chaque niveau lit les mêmes scores, un attaquant signalé par un honeypot ou un site WordPress est rejeté en bordure et sur vos relais mail dès que son score le permet. Signaler en retour ce que voient vos propres nœuds, c’est ce qui garde ces données partagées exactes pour tout le monde.

Comment le Linux Agent protège-t-il chaque nœud ?

L’agent est un binaire statique unique pour linux/amd64 et linux/arm64, en version 0.3.38 au 28 septembre 2026. Il assure trois tâches sur chaque hôte :

Il charge la blacklist communautaire dans ipset ou nftables sous forme de cinq listes, une par service exposé : ssh, mail, web, ftp et edge. Chaque liste ne s’applique qu’aux ports de son service, une entrée de la liste web ne touche donc jamais SSH.
Il lit les journaux que l’hôte écrit déjà, quatorze types de sources de sshd à Postfix, Dovecot et le serveur web, et signale une adresse dès qu’elle dépasse le seuil de cette source. Aucune ligne de journal, aucun nom d’utilisateur et aucune URL ne quitte la machine.
Il bloque ce qu’il a trouvé lui-même, avec une durée qui augmente pour les récidivistes. Un hôte qui doit seulement signaler peut désactiver le blocage local.

Sur un serveur sous licence, le flux est actualisé toutes les 15 minutes à partir de Professional. Sans licence, seul le téléchargement du flux s’interrompt : la liste déjà dans le noyau reste, et la détection, le blocage local et les signalements continuent. L’agent remplace le script de synchronisation écrit à la main et prend le relais de fail2ban ; les prérequis et l’installation rapide figurent dans la documentation du Linux Agent.

Chaque serveur a besoin d’une licence, comptée par installation

Les licences serveur forment un pool à part, compté séparément des domaines Hive. Un hôte est identifié par l’ID d’installation aléatoire que crée l’agent, jamais par son nom d’hôte ni par sa clé. Faire tourner une clé ou renommer une machine ne consomme donc pas de seconde licence. Quand un compte a plus d’agents que de licences, les hôtes les plus anciens gardent la leur.

Formule	Serveurs inclus	Groupes	Clés par groupe
Professional	1	1	10
Business	3	3	50
Enterprise	Selon contrat	100	500

Chaque serveur supplémentaire coûte 4,90 € par mois TTC, puis descend à 1,40 € à partir de 50 licences ; la grille complète est sur la page des licences serveur. Les comptes Free et Contributor peuvent faire tourner l’agent comme simple rapporteur avec le blocage local complet, mais ne peuvent ni réserver de licence ni créer de groupe.

Comment partager un bannissement sur tous les nœuds ?

Placez les clés API de vos nœuds dans un groupe de votre compte reportedip.com. Quand un membre signale une adresse, chaque autre membre la bloque pendant la fenêtre de bannissement du groupe, 24 heures par défaut, sur tous les ports. L’agent garde cette liste dans un sixième set noyau nommé group. Les sites WordPress équipés de Hive peuvent rejoindre le même groupe et reprendre la liste comme type de blocage à part.

Deux détails comptent dans un cluster. L’adresse de signalement d’un membre ne figure jamais sur la liste qu’il reçoit, un groupe ne peut donc pas isoler vos nœuds les uns des autres. Un groupe peut aussi porter une liste blanche de 200 adresses et préfixes au plus, pour les hôtes de supervision et d’administration qui ne doivent être bloqués nulle part. Chaque nouveau bannissement peut en outre déclencher un webhook signé vers un chat ou un outil de tickets, décrit dans la documentation des groupes. La mise en place en quatre étapes, avec un exemple de sortie, se trouve dans Partager des bannissements Linux.

Quand la DNS / RBL Zone est-elle le meilleur choix ?

L’agent rejette une adresse listée dans le noyau avant qu’elle n’atteigne Postfix. Beaucoup de configurations mail préfèrent décider dans le dialogue SMTP : refuser avec un motif, ou ajouter un score dans Rspamd tout en acceptant le message. C’est le rôle de la DNS / RBL Zone. Elle sert la blacklist communautaire comme DNSBL à clé sous bl.reportedip.de et suit la RFC 5782 pour IPv4 et IPv6. Elle convient aussi aux machines où aucun service root ne peut tourner, comme une passerelle mail gérée ou une appliance antispam qui accepte n’importe quelle RBL.

Une adresse listée répond 127.0.0.2 à partir d’une confiance de 90 et 127.0.0.3 entre 75 et 89 ; une adresse propre répond NXDOMAIN. Dans Postfix, c’est une seule restriction, identique sur chaque nœud mail :

# main.cf (same on every mail node)
smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_rbl_client <your-token>.bl.reportedip.de=127.0.0.[2..3]

# keep the token out of bounces and logs:
rbl_reply_maps = texthash:/etc/postfix/rbl_reply

Le modèle de réponse qui garde le jeton hors des rebonds SMTP est détaillé dans la documentation. Les sous-zones par catégorie comme brute-force ou spam limitent la réponse à un type de menace, si bien qu’un niveau mail peut pondérer le spam autrement que les attaques de connexion.

Une clé de zone pour le cluster, ou une par serveur mail

Chaque clé comprend 100 000 requêtes par jour, remises à zéro à 00:00 UTC, et une limite d’environ 50 requêtes par seconde. Le décompte se fait par clé, quel que soit le nœud qui interroge : le nœud A avec 40 000 requêtes et le nœud B avec 35 000 comptent pour 75 000. Le cache du résolveur garde la plupart des requêtes répétées dans votre réseau, 30 minutes pour une adresse listée et 5 minutes pour NXDOMAIN.

Un petit cluster peut partager une clé. Pour des relais très sollicités, une clé par serveur mail est le découpage le plus propre : un nœud ne peut pas épuiser les autres, et une clé divulguée se remplace sans toucher au reste. Chaque clé est un abonnement distinct à 7,90 € par mois ou 79 € par an TTC, disponible à partir de Professional.

Et les hôtes qui ne peuvent pas faire tourner l’agent ?

Les pare-feu cloud, les répartiteurs de charge et les machines sans Linux utilisent le Blacklist Feed : les mêmes données en export texte, JSON ou CSV, filtrées par confiance et par catégorie et récupérées selon un planning. L’accès commence avec la formule gratuite Contributor et ne compte dans aucun quota journalier. La méthode manuelle avec des scripts ipset et des signalements fail2ban est décrite dans Protéger votre serveur web ; sur un hôte Linux, l’agent fait le même travail avec moins d’entretien.

Les backends applicatifs et API qui ont besoin d’un verdict au moment de la requête interrogent l’API REST. Un compte gratuit couvre 1 000 vérifications et 50 signalements par jour, et les vérifications en masse commencent à Professional.

Comment déployer ReportedIP sur un cluster ?

Lancez reportedip-agent doctor sur un hôte de chaque type. La commande ne modifie rien et nomme tout ce qui manque, comme un backend de pare-feu ou un journal non lu.
Mettez vos adresses d’administration et de supervision en liste blanche avant la première synchronisation, car les règles rejettent le trafic dès cette synchronisation.
Installez sans interaction avec REPORTEDIP_ACCEPT_TERMS=1 et REPORTEDIP_KEY depuis Ansible, cloud-init ou une image de référence, comme dans les exemples d’installation.
Créez un groupe, ajoutez les clés de tous les nœuds et de chaque site Hive, et déplacez les exceptions communes dans la liste blanche du groupe.
Réservez la DNS / RBL Zone pour les relais mail et les appliances qui doivent décider dans le dialogue SMTP, et ajoutez la restriction sur chacun.
Placez un ou deux nœuds leurres sur des adresses inutilisées avec le Honeypot Server. Leurs signalements augmentent le score de chaque attaquant capturé dans tout le réseau.

Questions sur la sécurisation d’un cluster de serveurs

Chaque serveur du cluster a-t-il besoin de sa propre licence ?

Chaque serveur qui doit recevoir le flux communautaire et la liste du groupe a besoin d’une licence. Professional en inclut une et Business trois, les suivantes coûtent de 4,90 € à 1,40 € par serveur et par mois. Un serveur sans licence continue de détecter, de bloquer localement et de signaler, il contribue donc toujours au cluster.

Une clé de la DNS / RBL Zone peut-elle servir tous les serveurs mail ?

Une clé peut servir tous les serveurs mail d’un petit cluster, car ses 100 000 requêtes quotidiennes se comptent par clé, quel que soit le nœud qui les envoie. Pour des relais très sollicités, mieux vaut une clé par serveur, afin qu’un seul nœud n’épuise pas le quota des autres et qu’une clé divulguée se remplace seule.

Faut-il garder fail2ban à côté de l’agent ?

Seulement pendant la transition. L’agent prend le relais de fail2ban : vérifiez d’abord quel outil occupe les noms des sets du pare-feu, faites tourner les deux un moment, puis désactivez fail2ban pour de bon. Un hôte qui garde fail2ban voit quand même ses bannissements signalés, car l’agent lit fail2ban comme l’une de ses sources.

Sécuriser un cluster de serveurs avec ReportedIP : agent, groupes et DNSBL