Sécurisation d'un cluster de serveurs avec ReportedIP
Un cluster de serveurs multiplie votre surface d'attaque : chaque nœud web, relais de messagerie 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 l'ensemble du cluster ReportedIP partager un seul flux de menaces communautaire — et grâce à la zone DNS / RBL, chaque nœud peut y accéder via un DNS standard, sans nécessiter de code d'intégration spécifique à chaque nœud.
La zone DNS / RBL est une option payante disponible à partir de la formule PRO. Abonnez-vous depuis votre tableau de bord, puis configurez chaque nœud pour qu'il pointe vers une seule chaîne de zone.
Pourquoi un cluster a besoin d'un flux de menaces partagé
Lorsque dix nœuds gèrent chacun leur propre liste noire, une adresse IP bannie sur le nœud 1 continue d'atteindre les nœuds 2 à 10 jusqu’à ce que chacun en prenne connaissance de son côté. C’est précisément dans cette faille que les attaques par force brute 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 aux adresses IP issues d'un réseau communautaire en temps réel (niveau de confiance ≥ 75 % avant qu'une adresse ne soit répertoriée, avec une période de sécurité de 48 heures pour les faux positifs), et chaque nœud de votre cluster reçoit la même réponse. Un nouvel attaquant signalé n'importe où sur le réseau est bloqué partout dans votre cluster en l'espace d'un cycle de mise en cache.
Interroger la liste noire via DNS depuis chaque nœud
La zone DNS / RBL transforme la liste noire de la communauté en une liste noire DNSBL standard à l'adresse bl.reportedip.de. Un nœud recherche l'adresse IP du client (inversée) associée à votre jeton et lit la réponse — il s'agit de la même convention que celle utilisée par Spamhaus et toutes les autres listes noires DNS (DNSBL) ; ainsi, tout logiciel compatible RBL fonctionne sans nécessiter de code personnalisé. Il s'ensuit que RFC 5782, prend en charge à la fois IPv4 et IPv6, et renvoie 127.0.0.x codes :
| 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) | Refuser ou noter |
NXDOMAIN | Nettoyer | Accepter |
127.255.255.251 | Le quota quotidien a été 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 en double
Vous n'avez pas besoin d'un jeton par nœud. Configurez chaque relais de messagerie pour qu'il pointe vers la même chaîne de zone. Chaque jeton comprend 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. En pratique, la mise en cache du résolveur vous permet de rester largement en dessous de cette limite : une réponse trouvée est mise en cache pendant 30 minutes et une NXDOMAIN pour 5, 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.
Relais de messagerie : 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 (version 2.6 et plus) :
# 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_replyLes 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 de contournement des réponses de rejet qui empêche votre jeton d'apparaître dans les messages d'erreur SMTP, est disponible dans la documentation relative à la zone DNS / RBL. Le jeton est un identifiant privé : traitez-le comme un mot de passe et modifiez-le depuis le tableau de bord 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 par force brute ; 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.deLes 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. Les proxys inversés, les pare-feu et les serveurs web sont mieux pris en charge par le flux de la liste noire de la communauté — une exportation actualisée au format texte/JSON/CSV que vous récupérez via une tâche cron et que vous chargez dans fail2ban, un iptables un ipset ou une carte de refus nginx. Chaque nœud périphérique du cluster exécute le même cron et bloque les mêmes adresses.
Pour les applications et les backends API qui ont besoin d'une décision au moment de la requête, le API REST renvoie une ventilation complète des niveaux de confiance par adresse IP (ajouter verbose=true (pour consulter tous les critères de notation). Un compte gratuit donne droit à 1 000 vérifications et 50 rapports par jour ; les opérations groupées 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 | ReportedIP |
|---|---|---|
| MX / relais de courrier sortant | Recherche DNSBL au moment de la connexion SMTP | Zone DNS / RBL |
| Proxys inversés / WAF / périphérie | Exportation de la liste noire vers nginx / iptables / fail2ban | Flux de la liste noire |
| Backends d'applications et d'API | Vérification du score pour chaque requête | API publique |
| Nœuds leurres / nœuds leurres | Signaler les adresses IP des attaquants au réseau | Serveur honeypot |
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 relais de messagerie et de vos proxys périphériques dès le cycle de mise à jour 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 commencer
- Abonnez-vous à la zone DNS / RBL depuis votre tableau de bord et copiez le jeton.
- Ajoutez la ligne
reject_rbl_client(ou Rspamdrbls(bloc) à chaque nœud de messagerie — voir le Documentation RBL. - Récupérer le flux de la liste noire sur les nœuds périphériques ; appeler l'API depuis les serveurs d'application.
- Consultez l'annonce de lancement de la zone dans la section « DNS RBL Zone » : interrogez notre liste noire 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 zone DNS / RBL fonctionne-t-elle avec les serveurs de messagerie IPv6 ?
Oui. La zone est conforme à la 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 ?
Une fois que le total quotidien cumulé du jeton atteint sa limite, la zone revient 127.255.255.251 et cesse de traiter les requêtes jusqu'à la réinitialisation de minuit UTC suivante. Ajoutez un autre nœud pour augmenter la capacité. Étant donné que les réponses sont mises en cache pendant 30 minutes maximum sur chaque résolveur, la plupart des clusters n'atteignent jamais cette limite.