Sichern Sie einen Servercluster mit einer gemeinsamen DNSBL

Ein Servercluster vergrößert Ihre Angriffsfläche: Jeder Webknoten, jeder Mail Relay-Server und jeder Edge-Proxy wird unabhängig voneinander auf Schwachstellen geprüft, doch in den meisten Konfigurationen erhält jeder Knoten eigene, nur teilweise konfigurierte Blockierungsregeln. Mit ReportedIP kann der gesamte Cluster einen gemeinsamen Threat Feed nutzen – und dank der DNS / RBL Zone kann jeder Knoten diesen über normales DNS abrufen, ohne dass pro Knoten Integrationscode erforderlich ist.

Die DNS / RBL Zone ist ein kostenpflichtiges Add-on ab der PRO-Stufe. Abonnieren Sie diese über Ihr Dashboard und richten Sie anschließend jeden Knoten auf eine Zonenstringe aus.

Warum ein Cluster einen gemeinsamen Threat Feed benötigt

Wenn zehn Knoten jeweils ihre eigene Blockliste führen, erreicht eine auf Knoten 1 gesperrte IP-Adresse weiterhin die Knoten 2 bis 10, bis jeder einzelne davon unabhängig Kenntnis erlangt. Genau in dieser Lücke liegen die Erfolgschancen von Credential Stuffing- und Spam-Angriffen – sie durchlaufen Ihre Knoten schneller, als ein einzelner Knoten seine Regeln aktualisieren kann.

Ein gemeinsamer Feed schließt diese Lücke. ReportedIP bewertet IP-Adressen aus einem Echtzeit-Community Network (Vertrauensgrad ≥ 75 %, bevor eine Adresse gelistet wird, mit einer 48-stündigen Abkühlphase für False Positives), und jeder Knoten in Ihrem Cluster erhält dieselbe Antwort. Ein neuer Angreifer, der an einer beliebigen Stelle im Netzwerk gemeldet wird, wird innerhalb eines Cache-Zyklus überall in Ihrem Cluster blockiert.

Abfrage der Blocklist über DNS von jedem Knoten aus

Die DNS / RBL Zone wandelt die Community Blacklist in eine standardmäßige DNSBL um unter bl.reportedip.de. Ein Knoten sucht die umgekehrte Client-IP unter Ihrem Token und liest die Antwort – dieselbe Konvention, die Spamhaus und jede andere DNSBL verwenden, sodass jede RBL-fähige Software ohne benutzerdefinierten Code funktioniert. Sie entspricht dem RFC 5782, deckt IPv4 und IPv6 gleichermaßen ab und gibt 127.0.0.x Codes zurück:

Antwort	Bedeutung	Aktion
`127.0.0.2`	Aufgeführt, hohe Zuverlässigkeit (≥ 90)	Ablehnen
`127.0.0.3`	Aufgeführt, mittleres Konfidenzniveau (75–89)	Ablehnen oder bewerten
`NXDOMAIN`	Sauber	Akzeptieren
`127.255.255.251`	Tageskontingent erreicht	Ein Token hinzufügen
`127.255.255.252`	Token ungültig / inaktiv	Rechnungsdaten prüfen

Ein Token für den gesamten Cluster – die Nutzung wird summiert und nicht doppelt gezählt

Sie benötigen nicht für jeden Knoten ein eigenes Token. Richten Sie jeden Mail Relay auf dieselbe Zonenkette aus. Jedes Token umfasst 100.000 DNS-Abfragen pro Tag, und die Nutzung wird als Summe über alle Ihre Knoten hinweg berechnet – wenn Knoten A 40.000 Abfragen und Knoten B 35.000 Abfragen bedient, werden diese zusammen als 75.000 auf das tägliche Kontingent angerechnet. Dank des Resolver-Cachings bleiben Sie in der Praxis deutlich unter diesem Wert: Eine gelistete Antwort wird 30 Minuten lang zwischengespeichert, und ein NXDOMAIN für 5 Minuten zwischengespeichert, sodass die meisten wiederholten Abfragen Ihr Netzwerk gar nicht erst verlassen.

Wenn sich ein stark ausgelasteter Cluster der Grenze nähert, fügen Sie ein zweites Token hinzu und verteilen Sie es auf verschiedene Knotengruppen – die Kontingente sind voneinander unabhängig. Ein Rate Limit von etwa 50 Abfragen pro Sekunde pro Token schützt vor Spitzenbelastungen; anhaltende Spitzenwerte, die darüber liegen, werden mit REFUSED.

Mail Relays: eine Zeile in Postfix oder Rspamd

Fügen Sie die Zone auf jedem MX- und Outbound-Relay im Cluster zu Ihren Einschränkungen hinzu. Postfix erstellt die umgekehrte Abfrage für IPv4- und IPv6-Absender automatisch (ab 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

Rspamd-Benutzer aktivieren beide Adressfamilien und ordnen die Rückgabecodes Symbolen zu:

# 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";
    }
  }
}

Die vollständige Konfiguration, einschließlich der Übersteuerung der „Reject-Reply“-Antwort, die verhindert, dass Ihr Token in SMTP-Bounce-Meldungen erscheint, finden Sie in den Docs zur DNS / RBL Zone. Das Token ist ein vertrauliches Zugangsdatenelement – behandeln Sie es wie ein Passwort und ändern Sie es über das Dashboard, falls es in falsche Hände gerät.

Kategorie-Unterbereiche für die Filterung nach Diensten

Fügen Sie einen Kategorie-Slug hinzu, um nach Bedrohungsart zu filtern, sodass ein Knoten nur das blockiert, was für ihn relevant ist. Eine App-Ebene mit hohem Login-Aufkommen kann die Brute-Force-Liste abfragen; eine E-Mail-Ebene kann die Spam-Liste gewichtet berücksichtigen:

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

Zu den Schnecken gehören spam, brute-force, cms-login, web-attacks, malware, ddos, fraud, infrastructureund apt. Ein Treffer wird nur zurückgegeben, wenn die IP-Adresse in dieser Kategorie aufgeführt ist.

Edge- und Web-Knoten: der Feed und die API

Nicht jede Ebene unterstützt DNSBL. Reverse-Proxys, Firewalls und Webserver sind mit dem Community Blacklist Feed besser bedient – einem aktualisierten Text-/JSON-/CSV-Export, den Sie mit einem Cron-Job abrufen und in fail2ban, ein iptables ipset oder eine Nginx-Deny-Map laden können. Jeder Edge-Knoten im Cluster führt denselben Cron-Job aus und blockiert dieselben Adressen.

Für Anwendungs- und API-Backends, die zum Zeitpunkt der Anfrage eine Bewertung benötigen, gibt die REST API eine vollständige Aufschlüsselung der Konfidenzwerte pro IP-Adresse zurück (klicken Sie verbose=true , um alle Bewertungskomponenten anzuzeigen). Ein Free-Konto umfasst 1.000 Überprüfungen und 50 Reports pro Tag; Massenvorgänge sind ab der PRO-Stufe verfügbar.

Ein Referenzlayout für einen dreistufigen Cluster

Cluster-Ebene	Wie der Feed gelesen wird	ReportedIP-Produkt
MX / Mail Relays für ausgehende E-Mails	DNSBL-Abfrage zum Zeitpunkt der SMTP-Verbindungsherstellung	DNS / RBL Zone
Reverse-Proxys / WAF / Edge	Export der Blocklist in nginx / iptables / fail2ban	Blacklist Feed
App- und API-Backends	Überprüfung der Punktzahl pro Anfrage	Public API
Köder- bzw. Honeypot-Knoten	Melden Sie die IP-Adressen der Angreifer an das Netzwerk zurück	Honeypot Server

Jede Ebene greift auf eine gemeinsame Datenbank zu, sodass ein Angreifer, der von einem Honeypot-Knoten erfasst wurde, im nächsten Cache-Zyklus an Ihren Mail Relays und Edge-Proxys blockiert wird. Durch das Schließen des Kreislaufs – also die Rückmeldung dessen, was Ihre eigenen Knoten erkennen – wird sichergestellt, dass der gemeinsame Feed für alle Beteiligten korrekt bleibt.

Was Sie für Getting Started benötigen

Abonnieren Sie die DNS / RBL Zone über Ihr Dashboard und kopieren Sie das Token.
Fügen Sie die folgende einzeilige Anweisung hinzu reject_rbl_client (oder den Rspamd-Block rbls ) zu jedem Mail-Knoten hinzu – siehe die RBL-Docs.
Rufen Sie den Blacklist Feed auf den Edge-Knoten ab; rufen Sie die API von den App-Backends aus auf.
Lesen Sie die Ankündigung zur Einführung der Zone unter „DNS / RBL Zone: Abfrage unserer Blocklist von Ihrem Mailserver aus“.

Häufig gestellte Fragen

Benötige ich für jeden Server ein eigenes Token?

Nein. Ein Token deckt den gesamten Cluster ab; die 100.000 täglichen Abfragen werden über alle Knoten, die dieses Token nutzen, summiert. Fügen Sie ein zweites Token erst dann hinzu, wenn ein großer Cluster mehr Spielraum benötigt, und verteilen Sie es anschließend auf die Knotengruppen.

Funktioniert die DNS / RBL Zone mit IPv6-Mailservern?

Ja. Die Zone entspricht RFC 5782 und beantwortet IPv4- und IPv6-Abfragen gleichermaßen. Postfix 2.6+ und Rspamd erstellen die umgekehrte Abfrage für beide Adressfamilien automatisch – dieselbe einzelne Anweisung deckt beide ab.

Was geschieht, wenn ein Knoten die tägliche Quote erreicht?

Sobald die kumulierte Tagesgesamtzahl des Tokens ihr Limit erreicht hat, kehrt die Zone 127.255.255.251 und stellt die Auswertung bis zum nächsten Reset um Mitternacht (UTC) ein. Fügen Sie ein weiteres Token hinzu, um die Kapazität zu erhöhen. Da Antworten bei jedem Resolver bis zu 30 Minuten lang zwischengespeichert werden, erreichen die meisten Cluster das Limit so gut wie nie.

Sicherung eines Serverclusters mit ReportedIP