Servercluster absichern: Agent, Gruppen, DNSBL

Um einen Servercluster mit ReportedIP abzusichern, betreiben Sie den ReportedIP Linux Agent auf jedem Linux-Knoten und legen deren API-Keys in eine Gruppe: Jeder Knoten hält dann die Community-Blacklist in seiner Kernel-Firewall und verwirft jede Adresse, die ein anderer Knoten gemeldet hat. Mailrelays können zusätzlich die DNS / RBL Zone im SMTP-Dialog nutzen, und Hosts, auf denen der Agent nicht läuft, holen dieselben Daten als Feed oder über die API.

Als dieser Beitrag im Mai 2026 erschien, war eine DNS-Zone die einzige gemeinsame Schicht für einen ganzen Cluster. Seit September 2026 decken der Agent und die Gruppen die meisten Knoten ab, und die Zone bleibt das richtige Werkzeug für Mailfilter und Appliances.

Welcher ReportedIP-Baustein passt zu welcher Ebene eines Clusters?

Ein Cluster besteht selten aus nur einer Art von Maschine. Die Tabelle ordnet den üblichen Ebenen den passenden Teil von ReportedIP zu. Alle lesen aus derselben Community-Datenbank bewerteter Angreiferadressen.

Cluster-Ebene	Was sie schützt	Wie sie die Daten liest
Linux-Hosts für Web, Anwendung und Datenbank	Linux Agent	Kernel-Sets
Mailrelays	Linux Agent und DNS / RBL Zone	Kernel-Sets und DNSBL-Abfragen
WordPress-Frontends	Hive-Plugin	Lokale Sperren und die Gruppenliste
Appliances und Cloud-Firewalls	Blacklist Feed	Geplanter Export
Anwendungs- und API-Backends	REST-API	Score-Abfrage pro Request
Köderknoten	Honeypot Server	Nur Meldungen

Weil jede Ebene dieselben Scores liest, wird ein Angreifer, den ein Honeypot oder eine WordPress-Website gemeldet hat, an Ihrer Edge und an Ihren Mailrelays verworfen, sobald sein Score dafür reicht. Dass Ihre eigenen Knoten zurückmelden, was sie sehen, hält diese gemeinsamen Daten für alle genau.

Wie schützt der Linux Agent jeden Knoten?

Der Agent ist ein einzelnes statisches Binary für linux/amd64 und linux/arm64, mit Stand vom 28. September 2026 in Version 0.3.38. Er erledigt auf jedem Host drei Aufgaben:

Er lädt die Community-Blacklist als fünf Listen in ipset oder nftables, eine je angebotenem Dienst: ssh, mail, web, ftp und edge. Jede Liste greift nur auf den Ports ihres Dienstes, ein Eintrag auf der Web-Liste berührt SSH also nie.
Er liest die Logs, die der Host ohnehin schreibt, vierzehn Quelltypen von sshd über Postfix und Dovecot bis zum Webserver, und meldet eine Adresse, sobald sie die Schwelle dieser Quelle überschreitet. Keine Logzeile, kein Benutzername und keine URL verlässt die Maschine.
Er sperrt, was er selbst gefunden hat, mit einer Sperrdauer, die bei Wiederholungstätern wächst. Ein Host, der nur melden soll, kann die lokale Sperre abschalten.

Auf einem lizenzierten Server wird der Feed ab Professional alle 15 Minuten aktualisiert. Ohne Lizenz pausiert nur der Feed-Download: Die Liste im Kernel bleibt, und Erkennung, lokale Sperren und Meldungen laufen weiter. Der Agent ersetzt das handgeschriebene Sync-Skript und übernimmt die Arbeit von fail2ban; Voraussetzungen und Schnellinstallation stehen in der Linux-Agent-Doku.

Jeder Server braucht eine Lizenz, gezählt pro Installation

Serverlizenzen sind ein eigener Pool und werden getrennt von den Hive-Domains gezählt. Ein Host wird über die zufällige Install-ID erkannt, die der Agent anlegt, nie über Hostname oder Key. Einen Key zu rotieren oder eine Maschine umzubenennen, kostet deshalb keine zweite Lizenz. Hat ein Konto mehr Agenten als Lizenzen, behalten die ältesten Hosts ihre.

Tarif	Enthaltene Server	Gruppen	Keys pro Gruppe
Professional	1	1	10
Business	3	3	50
Enterprise	Nach Vertrag	100	500

Jeder weitere Server kostet 4,90 € im Monat inkl. MwSt., ab 50 Lizenzen sinkt der Preis auf 1,40 €; die ganze Staffel steht auf der Seite zu Serverlizenzen. Konten mit Free und Contributor können den Agent als Melder mit voller lokaler Sperre betreiben, aber keine Lizenz buchen und keine Gruppe anlegen.

Wie teilen Sie eine Sperre über alle Knoten?

Legen Sie die API-Keys Ihrer Knoten in Ihrem Konto auf reportedip.com in eine Gruppe. Meldet ein Mitglied eine Adresse, sperrt jedes andere Mitglied sie für das Sperrfenster der Gruppe, standardmäßig 24 Stunden, auf jedem Port. Der Agent hält diese Liste in einem sechsten Kernel-Set namens group. WordPress-Websites mit Hive können derselben Gruppe beitreten und die Liste als eigene Sperrart spiegeln.

In einem Cluster zählen zwei Details. Die eigene Meldeadresse eines Mitglieds steht nie auf der Liste, die es erhält, eine Gruppe kann Ihre Knoten also nicht gegenseitig aussperren. Außerdem kann eine Gruppe eine Whitelist mit bis zu 200 Adressen und Präfixen führen, für Monitoring- und Verwaltungshosts, die nirgends gesperrt werden dürfen. Jede neue Sperre kann zusätzlich einen signierten Webhook an einen Chat oder ein Ticketsystem auslösen, beschrieben in der Gruppen-Doku. Die Einrichtung in vier Schritten mit Beispielausgabe steht in IP-Sperren zwischen Linux-Servern teilen.

Wann ist die DNS / RBL Zone die bessere Wahl?

Der Agent verwirft eine gelistete Adresse im Kernel, bevor sie Postfix erreicht. Viele Mail-Setups wollen die Entscheidung stattdessen im SMTP-Dialog treffen: mit Begründung abweisen oder in Rspamd einen Score vergeben und die Nachricht trotzdem annehmen. Genau das leistet die DNS / RBL Zone. Sie stellt die Community-Blacklist als DNSBL mit Schlüssel unter bl.reportedip.de bereit und folgt RFC 5782 für IPv4 und IPv6. Sie passt auch auf Maschinen, auf denen kein Root-Dienst laufen darf, etwa ein verwaltetes Mail-Gateway oder eine Spam-Appliance, die jede RBL akzeptiert.

Eine gelistete Adresse antwortet ab Confidence 90 mit 127.0.0.2 und zwischen 75 und 89 mit 127.0.0.3; eine saubere Adresse antwortet mit NXDOMAIN. In Postfix ist das eine einzige Restriktion, auf jedem Mailknoten gleich:

# 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

Die Antwortvorlage, die den Token aus SMTP-Bounces heraushält, ist in der Doku ausgeschrieben. Kategorie-Unterzonen wie brute-force oder spam beschränken die Antwort auf einen Bedrohungstyp, sodass eine Mail-Ebene Spam anders gewichten kann als Login-Angriffe.

Ein Zonen-Key für den Cluster oder einer pro Mailserver

Jeder Key enthält 100.000 Abfragen pro Tag, zurückgesetzt um 00:00 UTC, und ein Ratenlimit von etwa 50 Abfragen pro Sekunde. Gezählt wird pro Key, egal welcher Knoten fragt: Knoten A mit 40.000 Abfragen und Knoten B mit 35.000 ergeben 75.000. Das Caching im Resolver hält die meisten Wiederholungen in Ihrem Netz, 30 Minuten für einen Treffer und 5 Minuten für NXDOMAIN.

Ein kleiner Cluster kann sich einen Key teilen. Bei stark belasteten Relays ist ein Key pro Mailserver die sauberere Aufteilung: Ein Knoten kann die anderen nicht ausbremsen, und ein geleakter Key wird rotiert, ohne den Rest anzufassen. Jeder Key ist ein eigenes Abo zu 7,90 € im Monat oder 79 € im Jahr inkl. MwSt., buchbar ab Professional.

Was ist mit Hosts, auf denen der Agent nicht laufen kann?

Cloud-Firewalls, Load Balancer und Maschinen ohne Linux nehmen den Blacklist Feed: dieselben Daten als Text-, JSON- oder CSV-Export, gefiltert nach Confidence und Kategorie und nach Zeitplan abgeholt. Der Zugang beginnt beim kostenlosen Contributor-Tarif und zählt gegen kein Tageskontingent. Den Weg in Eigenregie mit ipset-Skripten und fail2ban-Meldungen beschreibt Webserver mit Blacklist schützen; auf einem Linux-Host erledigt der Agent dieselbe Arbeit mit weniger Pflege.

Anwendungs- und API-Backends, die zum Zeitpunkt des Requests ein Urteil brauchen, fragen die REST-API. Ein kostenloses Konto umfasst 1.000 Checks und 50 Reports pro Tag, Bulk-Checks gibt es ab Professional.

Wie rollen Sie ReportedIP in einem Cluster aus?

Führen Sie reportedip-agent doctor auf je einem Host jeder Art aus. Der Befehl ändert nichts und nennt alles, was fehlt, etwa ein Firewall-Backend oder ein ungelesenes Log.
Setzen Sie Ihre Verwaltungs- und Monitoring-Adressen vor dem ersten Sync auf die Whitelist, denn ab diesem Sync verwerfen die Regeln Verkehr.
Installieren Sie unbeaufsichtigt mit REPORTEDIP_ACCEPT_TERMS=1 und REPORTEDIP_KEY aus Ansible, cloud-init oder einem Golden Image, wie in den Installationsbeispielen gezeigt.
Legen Sie eine Gruppe an, fügen Sie die Keys aller Knoten und aller Hive-Websites hinzu und verschieben Sie gemeinsame Ausnahmen in die Gruppen-Whitelist.
Buchen Sie die DNS / RBL Zone für Mailrelays und Appliances, die im SMTP-Dialog entscheiden sollen, und tragen Sie die Restriktion auf jedem ein.
Stellen Sie ein oder zwei Köderknoten mit dem Honeypot Server auf ungenutzte Adressen. Ihre Meldungen erhöhen den Score jedes gefangenen Angreifers im ganzen Netzwerk.

Fragen zur Absicherung eines Serverclusters

Braucht jeder Server im Cluster eine eigene Lizenz?

Jeder Server, der den Community-Feed und die Gruppenliste erhalten soll, braucht eine Lizenz. Professional enthält eine, Business drei, weitere kosten zwischen 4,90 € und 1,40 € pro Server und Monat. Ein Server ohne Lizenz erkennt, sperrt lokal und meldet weiter, er trägt also weiterhin zum Cluster bei.

Kann ein Key der DNS / RBL Zone alle Mailserver bedienen?

Ein Key kann alle Mailserver eines kleinen Clusters bedienen, weil seine 100.000 Tagesabfragen pro Key zählen, egal welcher Knoten sie stellt. Stark belastete Relays teilen Sie besser auf einen Key pro Server auf, damit ein einzelner Knoten nicht das Kontingent der anderen aufbraucht und ein geleakter Key allein rotiert werden kann.

Sollte fail2ban neben dem Agent weiterlaufen?

Nur für den Umstieg. Der Agent übernimmt die Arbeit von fail2ban: Prüfen Sie zuerst, welches Werkzeug die Namen der Firewall-Sets belegt, lassen Sie beide eine Weile laufen und schalten Sie fail2ban dann endgültig ab. Ein Host, der fail2ban behält, meldet dessen Sperren trotzdem, weil der Agent fail2ban als eine seiner Quellen liest.

Servercluster mit ReportedIP absichern: Agent, Gruppen und DNSBL