Sécuriser un cluster de serveurs à l'aide d'une liste DNSBL partagée

Un cluster de serveurs multiplie votre surface d’attaque : chaque nœud web, Mail Relay et proxy périphérique est sondé indépendamment, alors que la plupart des configurations attribuent à chaque nœud ses propres règles de blocage à moitié configurées. ReportedIP permet à l’ensemble du cluster de partager un seul Threat Feed sur les menaces de la communauté — et grâce à la DNS / RBL Zone, chaque nœud peut le consulter via un DNS standard, sans code d’intégration spécifique à chaque nœud.

La DNS / RBL Zone est un add-on payant disponible à partir de la formule PRO. Abonnez-vous depuis votre Dashboard, puis configurez chaque nœud pour qu’il pointe vers une chaîne de zone.

Pourquoi un cluster a besoin d’une Threat Feed commune

Lorsque dix nœuds gèrent chacun leur propre liste de blocage, une adresse IP bannie sur le nœud 1 continue d’atteindre les nœuds 2 à 10 jusqu’à ce que chacun d’entre eux en prenne connaissance de manière indépendante. C’est précisément dans cette faille que les attaques par « Credential Stuffing » et les campagnes de spam parviennent à s’infiltrer : elles se propagent d’un nœud à l’autre plus rapidement que n’importe quel nœud ne parvient à mettre à jour ses règles.

Un flux partagé comble cette lacune. ReportedIP attribue des scores aux adresses IP provenant d’un Community Network en temps réel (niveau de confiance ≥ 75 % avant qu’une adresse ne soit répertoriée, avec une période de suspension de 48 heures en cas de False Positive), et chaque nœud de votre cluster reçoit la même réponse. Tout nouvel attaquant signalé n’importe où sur le réseau est bloqué partout dans votre cluster en l’espace d’un cycle de cache.

Interroger la Blocklist via DNS depuis chaque nœud

La DNS / RBL Zone transforme la Community Blacklist en une DNSBL standard à l’adresse bl.reportedip.de. Un nœud recherche l’adresse IP inversée du client à partir de votre jeton et lit la réponse — selon la même convention que celle utilisée par Spamhaus et tous les autres DNSBL, ce qui permet à tout logiciel compatible RBL de fonctionner sans code personnalisé. Elle respecte la norme RFC 5782, prend en charge aussi bien IPv4 qu’IPv6 et renvoie des 127.0.0.x :

Réponse	Signification	Action
`127.0.0.2`	Répertorié, niveau de confiance élevé (≥ 90)	Refuser
`127.0.0.3`	Répertorié, niveau de confiance moyen (75–89)	Rejeter ou noter
`NXDOMAIN`	Nettoyer	Accepter
`127.255.255.251`	Quota journalier atteint	Ajouter un jeton
`127,255,255,252`	Jeton non valide / inactif	Vérifier la facturation

Un seul jeton pour l’ensemble du cluster — l’utilisation est cumulée, et non comptée plusieurs fois

Vous n’avez pas besoin d’un jeton par nœud. Configurez chaque Mail Relay pour qu’il pointe vers la même chaîne de zone. Chaque jeton donne droit à 100 000 requêtes DNS par jour, et l’utilisation est cumulée sur l’ensemble de vos nœuds : si le nœud A traite 40 000 requêtes et le nœud B 35 000, cela compte pour 75 000 dans le quota journalier. La mise en cache du résolveur vous permet en pratique de rester largement en dessous de ce quota : une réponse répertoriée est mise en cache pendant 30 minutes et un NXDOMAIN pour 5 minutes, de sorte que la plupart des requêtes répétées ne quittent jamais votre réseau.

Lorsqu’un cluster très sollicité approche de sa limite, ajoutez un deuxième jeton et répartissez-le entre les groupes de nœuds — les quotas sont indépendants. Une limite de débit par jeton d’environ 50 requêtes par seconde permet de se prémunir contre les pics de trafic ; les pics prolongés dépassant cette limite sont traités avec REFUSED.

Mail Relay : une ligne dans Postfix ou Rspamd

Sur chaque serveur MX et chaque relais sortant du cluster, ajoutez la zone à vos restrictions. Postfix génère automatiquement la requête inversée pour les expéditeurs IPv4 et IPv6 (à partir de la version 2.6) :

# 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

Les utilisateurs de Rspamd activent les deux familles d’adresses et associent les codes de retour à des symboles :

# local.d/rbl.conf
rbls {
  reportedip {
    rbl = "<your-token>.bl.reportedip.de";
    ipv4 = true;
    ipv6 = true;
    returncodes {
      REPORTEDIP_HIGH   = "127.0.0.2";
      REPORTEDIP_MEDIUM = "127.0.0.3";
    }
  }
}

La configuration complète, y compris la configuration permettant de contourner les réponses de rejet afin d’éviter que votre jeton ne soit concerné par les messages SMTP en échec, est disponible dans les Docs relatifs à la DNS / RBL Zone. Le jeton est un identifiant privé : traitez-le comme un mot de passe et modifiez-le depuis le Dashboard en cas de fuite.

Sous-zones de catégorie pour le filtrage par service

Ajoutez un slug de catégorie pour filtrer par type de menace, afin qu’un nœud ne bloque que ce qui le concerne. Une couche d’applications impliquant de nombreuses connexions peut interroger la liste des attaques Brute-Force ; une couche de messagerie peut privilégier la liste des spams :

<reversed-ip>.<your-token>.brute-force.bl.reportedip.de
<reversed-ip>.<your-token>.spam.bl.reportedip.de

Les limaces comprennent spam, brute-force, cms-login, web-attacks, malware, ddos, fraud, infrastructure, et apt. Une correspondance n’est renvoyée que si l’adresse IP figure dans cette catégorie.

Nœuds périphériques et nœuds Web : le flux et l’API

Toutes les couches ne prennent pas en charge les DNSBL. Pour les proxys inversés, les pare-feu et les serveurs web, il est préférable d’utiliser le Blacklist Feed — une exportation mise à jour au format texte/JSON/CSV que vous récupérez via une tâche cron et que vous chargez dans fail2ban, un iptables ipset ou une carte de blocage nginx. Chaque nœud périphérique du cluster exécute la même tâche cron et bloque les mêmes adresses.

Pour les applications et les backends API qui ont besoin d’un verdict au moment de la requête, la REST API renvoie une ventilation complète des niveaux de confiance par adresse IP (cliquez verbose=true pour voir tous les éléments pris en compte dans le calcul du score). Un compte Free donne droit à 1 000 vérifications et 50 rapports par jour ; les opérations en masse sont disponibles à partir de la formule PRO.

Une architecture de référence pour un cluster à trois niveaux

Niveau de cluster	Comment il lit le flux	Produit reportedIP
MX / Mail Relay sortant	Recherche DNSBL au moment de la connexion SMTP	DNS / RBL Zone
Proxys inversés / WAF / périphérie	Exportation de la Blocklist vers nginx / iptables / fail2ban	Blacklist Feed
Back-ends d’applications et d’API	Vérification du score pour chaque requête	Public API
Nœuds leurres / Honeypots	Signaler les adresses IP des attaquants au réseau	Honeypot Server

Chaque niveau puise ses informations dans une base de données communautaire ; ainsi, un attaquant détecté par un nœud « Honeypot » est bloqué au niveau de vos Mail Relays et de vos proxys périphériques dès le cycle de mise en cache suivant. C’est en bouclant la boucle — c’est-à-dire en transmettant les informations recueillies par vos propres nœuds — que l’on garantit l’exactitude du flux partagé pour tous.

Ce dont vous avez besoin pour Getting Started

Abonnez-vous à la DNS / RBL Zone depuis votre Dashboard et copiez le jeton.
Ajoutez la ligne suivante reject_rbl_client (ou le bloc Rspamd rbls ) à chaque nœud de messagerie — voir les Docs RBL.
Récupérer le Blacklist Feed sur les nœuds périphériques ; appeler l’API depuis les serveurs d’application.
Consultez l’annonce de lancement de la zone dans « DNS / RBL Zone : interrogez notre Blocklist depuis votre serveur de messagerie ».

Foire aux questions

Ai-je besoin d’un jeton distinct pour chaque serveur ?

Non. Un seul jeton couvre l’ensemble du cluster ; les 100 000 requêtes quotidiennes sont cumulées sur tous les nœuds qui l’utilisent. N’ajoutez un deuxième jeton que lorsqu’un grand cluster a besoin de plus de marge de manœuvre, puis répartissez-le entre les groupes de nœuds.

La DNS / RBL Zone fonctionne-t-elle avec les serveurs de messagerie IPv6 ?

Oui. La zone est conforme à la norme RFC 5782 et répond de la même manière aux requêtes IPv4 et IPv6. Postfix 2.6 et versions ultérieures, ainsi que Rspamd, génèrent automatiquement la requête inversée pour l’une ou l’autre des familles d’adresses — une seule et même directive couvre les deux.

Que se passe-t-il si un nœud atteint son quota quotidien ?

Dès que le total quotidien cumulé du jeton atteint sa limite, la zone revient 127.255.255.251 et cesse toute résolution jusqu’à la réinitialisation de minuit UTC suivante. Ajoutez un jeton supplémentaire pour augmenter la capacité. Les réponses étant mises en cache pendant 30 minutes maximum sur chaque résolveur, la plupart des clusters n’atteignent jamais cette limite.

Sécurisation d'un cluster de serveurs avec ReportedIP