Sichern eines Serverclusters mit ReportedIP
Ein Servercluster vergrößert Ihre Angriffsfläche: Jeder Webknoten, jeder Mail-Relay-Server und jeder Edge-Proxy wird separat abgefragt, doch in den meisten Konfigurationen erhält jeder Knoten nur halb konfigurierte Blockierungsregeln. ReportedIP der gesamte Cluster einen gemeinsamen Community-Bedrohungsfeed 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 für die PRO-Version und höher. Abonnieren Sie diese über Ihr Dashboard und verweisen Sie anschließend jeden Knoten auf eine Zonenzeichenfolge.
Warum ein Cluster einen gemeinsamen Bedrohungsfeed benötigt
Wenn zehn Knoten jeweils ihre eigene Sperrliste 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 die Lücke. ReportedIP IP-Adressen aus einem Echtzeit-Community-Netzwerk (Vertrauenswürdigkeit ≥ 75 %, bevor eine Adresse gelistet wird, mit einer 48-stündigen Karenzzeit für Fehlalarme), und jeder Knoten in Ihrem Cluster erhält dieselbe Antwort. Ein neuer Angreifer, der irgendwo im Netzwerk gemeldet wird, wird innerhalb eines Cache-Zyklus überall in Ihrem Cluster blockiert.
Die Sperrliste über DNS von jedem Knoten abfragen
Die DNS-/RBL-Zone wandelt die Community-Blacklist in eine Standard-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 alle anderen DNSBLs verwenden, sodass jede RBL-fähige Software ohne eigenen Code funktioniert. Es folgt RFC 5782, deckt IPv4 und IPv6 gleichermaßen ab und gibt 127.0.0.x Codes:
| Antwort | Bedeutung | Aktion |
|---|---|---|
127.0.0.2 | Gelistet, hohe Zuverlässigkeit (≥ 90) | Ablehnen |
127.0.0.3 | Gelistet, mittleres Vertrauen (75–89) | Ablehnen oder bewerten |
NXDOMAIN | Sauber | Akzeptieren |
127.255.255.251 | Tageskontingent erreicht | Token hinzufügen |
127.255.255.252 | Token ungültig / inaktiv | Rechnung prüfen |
Ein Token für den gesamten Cluster – die Nutzung wird summiert, nicht doppelt gezählt
Sie benötigen nicht für jeden Knoten ein eigenes Token. Richten Sie jeden Mail-Relay auf denselben Zonenstrings aus. Jedes Token enthält 100.000 DNS-Abfragen pro Tag, und die Nutzung wird als Summe aller Knoten aggregiert – wenn Knoten A 40.000 Abfragen und Knoten B 35.000 Abfragen bedient, zählt dies als 75.000 gegenüber der täglichen Quote. Dank des Resolver-Cachings bleiben Sie in der Praxis deutlich darunter: Eine gelistete Antwort wird 30 Minuten lang zwischengespeichert und eine NXDOMAIN für 5, sodass die meisten wiederholten Abfragen Ihr Netzwerk nie verlassen.
Wenn ein stark ausgelasteter Cluster an seine Grenzen stößt, fügen Sie ein zweites Token hinzu und verteilen Sie es auf verschiedene Knotengruppen – die Kontingente sind voneinander unabhängig. Eine Ratenbegrenzung von etwa 50 Abfragen pro Sekunde pro Token schützt vor Lastspitzen; anhaltende Spitzenwerte, die darüber hinausgehen, 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_replyRspamd-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 Ablehnungsantwort, die verhindert, dass Ihr Token in SMTP-Bounce-Meldungen erscheint, finden Sie in der Dokumentation zur DNS-/RBL-Zone. Das Token ist ein vertrauliches Zugangsdaten – behandeln Sie es wie ein Passwort und ändern Sie es über das Dashboard, falls es in falsche Hände gerät.
Unterbereiche für die Filterung nach Diensten
Füge einen Kategorie-Slug hinzu, um nach Bedrohungsart zu filtern, sodass ein Knoten nur das blockiert, was für ihn relevant ist. Eine anmeldungsintensive Anwendungsschicht kann die Brute-Force-Liste abfragen; eine E-Mail-Schicht kann die Spam-Liste gewichten:
<reversed-ip>.<your-token>.brute-force.bl.reportedip.de
<reversed-ip>.<your-token>.spam.bl.reportedip.deZu 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 besser mit dem Feed der Community-Sperrliste — einen aktualisierten Text-/JSON-/CSV-Export, den Sie mit einem Cron-Job abrufen und in fail2ban, ein iptables ipset oder eine Nginx-Deny-Map. 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 Entscheidung benötigen, ist die REST-API gibt eine vollständige Aufschlüsselung der Konfidenzwerte pro IP zurück (hinzufügen verbose=true (um alle Bewertungskomponenten anzuzeigen). Ein kostenloses Konto umfasst 1.000 Überprüfungen und 50 Berichte pro Tag; Massenvorgänge sind ab der Pro-Version verfügbar.
Ein Referenzlayout für einen dreistufigen Cluster
| Cluster-Ebene | Wie der Feed gelesen wird | ReportedIP |
|---|---|---|
| MX / Postausgangs-Relays | DNSBL-Abfrage bei der SMTP-Verbindungsherstellung | DNS-/RBL-Zone |
| Reverse-Proxys / WAF / Edge | Export der Blockliste in Nginx / iptables / fail2ban | Blacklist-Feed |
| App- und API-Backends | Überprüfung der Punktzahl pro Anfrage | Öffentliche API |
| Köder-/Honeypot-Knoten | Die IP-Adressen der Angreifer an das Netzwerk melden | Honeypot-Server |
Jede Ebene bezieht ihre Daten aus einer gemeinsamen Datenbank, sodass ein Angreifer, der von einem Honeypot-Knoten abgefangen wurde, beim 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 – bleibt der gemeinsame Feed für alle Beteiligten korrekt.
Was Sie für den Einstieg benötigen
- Abonnieren Sie die DNS-/RBL-Zone über Ihr Dashboard und kopieren Sie den Token.
- Füge die einzeilige
reject_rbl_client(oder RspamdrblsBlock) an jeden Mail-Knoten – siehe die RBL-Dokumente. - Lade den Blacklist-Feed auf den Edge-Knoten; rufe die API vom App-Backend auf.
- Lesen Sie die Ankündigung zur Einführung der Zone unter „DNS RBL Zone: Abfrage unserer Sperrliste von Ihrem Mailserver aus“.
Häufig gestellte Fragen
Brauche ich für jeden Server einen eigenen Token?
Nein. Ein Token deckt den gesamten Cluster ab; die 100.000 täglichen Abfragen werden über alle Knoten hinweg summiert, die dieses Token nutzen. 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 verschiedene 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 einzige Anweisung deckt beide ab.
Was passiert, wenn ein Knoten die tägliche Quote erreicht?
Sobald die kumulierte Tagesgesamtzahl des Tokens ihr Limit erreicht hat, kehrt die Zone zurück 127.255.255.251 und wird erst beim nächsten Reset um Mitternacht (UTC) wieder freigegeben. Fügen Sie ein weiteres Token hinzu, um die Kapazität zu erhöhen. Da die Antworten bei jedem Resolver bis zu 30 Minuten lang zwischengespeichert werden, erreichen die meisten Cluster diese Grenze nie.