Linux-Server absichern mit dem ReportedIP Agent: Wie CMS ADMINS sein komplettes Server-Netzwerk schützt

Von Patrick Schlesinger · Aktualisiert am 30. Oktober 2026

Symbolbild (KI-generiert)

Veröffentlicht: 30.10.2026

Wer einen Linux-Server im Internet betreibt, kennt das Bild: Kaum ist die Maschine online, laufen in den Logs die ersten fehlgeschlagenen SSH-Logins auf. Wenig später folgen Anmeldeversuche auf WordPress, Passwort-Sprays gegen Postfächer, Scans auf FTP und Portscans auf alles, was antwortet. Für einen Hosting-Server ist das kein Ausnahmezustand, sondern Alltag.

Wir bei CMS ADMINS betreiben seit 2012 Server für WordPress- und Drupal-Websites. Genau deshalb haben wir uns intensiv mit der Frage beschäftigt, wie man einen Server nicht nur reaktiv, sondern vorausschauend schützt. Unsere Antwort: Wir sichern inzwischen alle Server in unserem Netzwerk mit dem ReportedIP Linux Agent ab. In diesem Artikel erklären wir, was der Agent macht, wie er technisch funktioniert, welche Dienste wir damit schützen und warum sich das für Admins, Hoster und Agenturen mit eigenen Servern lohnt.

Das Grundproblem: Jeder Server lernt allein

Ein klassischer Hosting-Server ist nicht ein Dienst, sondern viele. Webserver, Mailserver, FTP, DNS und ein Control Panel laufen auf derselben Maschine und schreiben gemeinsam Hunderte Log-Dateien. Jede Angriffsart landet in einer anderen Datei.

Bewährte Werkzeuge wie fail2ban lösen einen Teil davon: Sie lesen Logs, zählen Fehlversuche und sperren eine IP-Adresse, sobald ein Schwellenwert überschritten ist. Das hat aber eine eingebaute Grenze. Eine Sperrliste, die nur aus den eigenen Logs entsteht, enthält nur die Angreifer, die diesen Server bereits angegriffen haben. Jede Adresse bekommt ihre ersten Versuche frei, bevor sie gesperrt wird.

Das bedeutet in der Praxis:

• Eine Adresse, die heute Morgen vierzig andere Server angegriffen hat, darf bei Ihnen trotzdem erst einmal anklopfen.
• Ein neuer Server im Rack startet mit einer leeren Sperrliste und muss erst angegriffen werden, um zu lernen.
• Wechselt ein Angreifer von Server 1 auf Server 2, fängt Server 2 bei null an.
• Ein Brute-Force-Angriff, der sich auf 300 WordPress-Installationen verteilt, fällt pro Website kaum auf, weil jede einzelne nur wenige Versuche sieht.

Jeder Server im Internet bezahlt also dieselbe Lektion separat, mit der Rechenzeit und der Bandbreite seiner Kunden.

Was ist der ReportedIP Linux Agent?

Der ReportedIP Agent ist ein Sicherheitsprogramm für Linux-Server, entwickelt für Hoster, Rechenzentren und Admins, die Web, Mail, FTP und DNS auf denselben Maschinen betreiben. Er verbindet zwei Dinge, die bisher getrennt waren:

1. Lokale Erkennung: Der Agent liest die Logs aller relevanten Dienste, erkennt Angriffe und sperrt die Angreifer direkt im Kernel.
2. Gemeinsames Wissen: Jeder erkannte Angriff wird an das ReportedIP-Netzwerk gemeldet. Im Gegenzug lädt ein lizenzierter Server alle 15 Minuten eine Community-Blockliste mit Adressen, die andere Server bereits angegriffen haben.

Das Ergebnis: Bekannte Angreifer werden verworfen, bevor ihr erstes Paket den Dienst erreicht. Ein neuer Server hat schon nach der ersten Synchronisation tausende bekannte Angreifer in seiner Sperrliste.

Technische Basis

• Ein statisches Binary für linux/amd64 und linux/arm64. Kein cgo, kein Interpreter, keine Laufzeitumgebung, die gepatcht werden muss.
• ipset oder nftables, IPv4 und IPv6. Die Wahl trifft der Installer automatisch je nach System.
• Eigene Chain: Der Agent ändert nur Sets und Regeln, die er selbst angelegt hat. Eine bestehende Firewall läuft unverändert weiter.
• Atomarer Austausch: Die Blocklisten werden atomar ersetzt, mit einer Mindestgröße. Eine verdächtig kleine Liste geht nie live, und es gibt keinen Moment, in dem ein Set leer ist.
• Signierte Updates: Selbst-Updates und Regelpakete werden per Ed25519 auf dem Server geprüft. Ein Build, der nicht startet, wird verworfen.

So funktioniert der Agent im Detail

Die Community-Blocklist im Kernel

Das Herzstück ist die gemeinsame Sperrliste. Ein lizenzierter Server aktualisiert sie alle 15 Minuten. Hat sich nichts geändert, kostet die Abfrage nur eine kurze 304-Antwort ohne Datenübertragung.

Besonders durchdacht: Die Liste ist in fünf Sets nach Dienst aufgeteilt (ssh, mail, web, ftp und edge). Jedes Set wird nur auf den passenden Ports angewendet. Eine Adresse, die Postfächer angreift, wird auf den Mail-Ports gesperrt, kann aber weiterhin eine Website aufrufen. Das verhindert Kollateralschäden, etwa wenn sich hinter einer Adresse ein Firmennetz mit vielen Nutzern verbirgt.

Über einen Konfidenz-Schwellenwert legen Sie fest, wie sicher ein Eintrag sein muss, bevor er bei Ihnen blockiert wird. Läuft eine Lizenz aus, pausiert nur der Download. Die bereits geladene Liste blockiert weiter.

15 Log-Quellen, automatisch gefunden

Der Installer erkennt selbstständig, welche Dienste laufen und wo die jeweilige Distribution ihre Logs ablegt. Für Webserver liest er sogar die Server-Konfiguration aus und findet so jedes vHost-Log. Eine Website, die morgen dazukommt, ist ohne Konfigurationsänderung abgedeckt.

Unterstützt werden unter anderem:

• SSH: fehlgeschlagene Logins aus Journal, auth.log oder secure
• Web-Access-Logs: Login-Brute-Force und Scanner-Pfade in jedem vHost
• WordPress und Drupal: Applikationsangriffe, separat gezählt mit eigenem Schwellenwert
• Webserver-Error-Logs: nginx und Apache, inklusive ModSecurity-Meldungen
• ModSecurity-Audit-Log
• Postfix: SASL-Fehler, 5xx-Rejects und Amavis-Ergebnisse
• Dovecot und Exim: fehlgeschlagene IMAP-, POP3- und SMTP-Anmeldungen
• FTP: pure-ftpd, ProFTPD und vsftpd
• BIND: abgewiesene eingehende Anfragen
• ISPConfig: fehlgeschlagene Logins ins Control Panel
• CSF und Imunify360 als zusätzliche Quellen (Imunify360 experimentell)
• fail2ban optional als weitere Quelle, aber keine Voraussetzung
• Portscans aus dem Kernel: zehn Zugriffe auf geschlossene Ports in zehn Minuten gelten als Scan
• Query-String-Crawl-Erkennung (zunächst im Simulationsmodus)
• Volumen-Alarm pro Website: Warnung, wenn ein Log achtmal so viel schreibt wie üblich

Jede Quelle hat ihren eigenen Schwellenwert. Und der entscheidende Vorteil gegenüber Einzelsite-Lösungen: Ein verteilter WordPress-Angriff wird über alle vHosts hinweg gezählt und einmal gesperrt und gemeldet.

Was bei einem Treffer passiert

Überschreitet eine Adresse einen Schwellenwert, sperrt der Agent sie lokal im Kernel, mit Timeout pro Eintrag. Die Sperren überstehen einen Neustart. Wiederholungstäter werden eskaliert: 30 Minuten, dann 2, 8, 32 und 128 Stunden, gedeckelt bei sieben Tagen.

Gleichzeitig geht eine Meldung an das Netzwerk. Wichtig für Datenschutz und Vertrauen: Gemeldet werden nur die IP-Adresse, Kategorie-IDs und ein generierter Satz. Meldungen werden dedupliziert, in eine Warteschlange gelegt und gesendet, sobald die API erreichbar ist.

Bestimmte Adressen werden nie gesperrt, und das lässt sich auch nicht abschalten: private Netze, Loopback, die eigenen Interfaces, das Gateway und der SSH-Client, der die Installation durchgeführt hat. Dazu kommen eine eigene Whitelist und Ignore-Muster pro Quelle, damit Health-Checks und Monitoring nie in einer Sperre landen.

Regeln als lesbare Dateien

Kein Detektor ist im Binary versteckt. Jede Regel ist eine YAML-Datei mit Muster, Position der IP-Adresse und eigenen Testbeispielen. Eigene Regeln legen Sie unter /etc/reportedip-agent/rules.d/ ab, sie werden innerhalb einer Minute aktiv. Neue eigene Regeln sperren sofort, melden aber erst nach 24 Stunden ans Netzwerk. Unsichere Regeln lassen sich in den Simulationsmodus setzen: Sie protokollieren, was sie sperren würden, sperren aber nichts.

Gruppen-Sperren für ganze Flotten

Für Betreiber mehrerer Server ist die Gruppenfunktion besonders wertvoll. Was ein Mitglied der Gruppe meldet, wird auf allen anderen standardmäßig für 24 Stunden gesperrt, auf allen Ports. Ein Angreifer, der von Server 1 zu Server 2 wechselt, steht dort bereits vor verschlossener Tür. Ergänzt wird das durch eine zentrale Gruppen-Whitelist im Portal und signierte Webhooks für eigene Tools.

Monitoring und Betrieb

Ein Agent auf vielen Servern ist nur dann günstig, wenn er still läuft. Deshalb bringt er alles mit, was ein Admin erwartet:

• status mit Exit-Codes (0 gesund, 1 eingeschränkt, 2 Eingriff nötig), direkt nutzbar in Nagios, Icinga oder Checkmk
• status --json für Zabbix, Prometheus oder eigene Skripte
• ein offizielles Zabbix-7-Template mit fertigen Triggern
• doctor, das prüft, was der Host mitbringt, ohne etwas zu verändern
• einen Testlauf über echte Logs, auch gzip-komprimierte, der zeigt, wer wann gesperrt worden wäre
• eine Mail pro Zustandsänderung statt einer Mail pro Ereignis

Warum CMS ADMINS alle Server mit dem Agent absichert

Als Anbieter von WordPress-Wartung und Hosting tragen wir Verantwortung für die Websites unserer Kunden. Jeder Angriff, der unsere Server erreicht, kostet Ressourcen: CPU-Zeit für PHP-Prozesse, die Login-Versuche verarbeiten, Datenbankabfragen, Mail-Authentifizierungen und Log-Volumen. Diese Ressourcen fehlen dann den Websites, für die unsere Kunden eigentlich bezahlen.

Deshalb haben wir den ReportedIP Agent auf allen Servern in unserem Netzwerk ausgerollt.

Mehr Leistung für die eigentlichen Websites

Der größte Effekt war für uns nicht nur die Sicherheit, sondern die Performance. Bekannte Angreifer werden jetzt im Kernel verworfen, bevor sie nginx, PHP oder den Mailserver überhaupt erreichen. Ein verworfenes Paket kostet praktisch nichts. Ein Login-Versuch auf wp-login.php dagegen startet einen PHP-Prozess, lädt WordPress und fragt die Datenbank ab.

Seit dem Rollout beobachten wir:

• deutlich weniger Last durch Angriffsverkehr auf Web- und Mail-Diensten
• ruhigere Logs, in denen echte Probleme schneller auffallen
• mehr freie Ressourcen für die Websites unserer Kunden, was sich in stabileren Antwortzeiten zeigt
• massiv weniger erfolgreiche Erstkontakte durch bekannte Angreifer, weil diese gar nicht mehr bis zum Dienst durchkommen

Mehr Sicherheit durch Netzwerkeffekt

Der zweite Vorteil liegt im Gruppenprinzip. Greift eine Adresse einen unserer Server an, ist sie wenige Momente später auf allen anderen gesperrt. Ein neuer Server ist ab der ersten Synchronisation geschützt, statt erst durch Angriffe lernen zu müssen. Und weil wir unsere Funde ans Netzwerk melden, profitieren auch andere Betreiber davon.

Welche Dienste wir schützen

Auf unseren Servern überwacht und schützt der Agent unter anderem:

• SSH-Zugänge gegen Brute-Force und Credential-Stuffing
• nginx-Webserver mit allen vHost-Logs unserer Kunden-Websites
• WordPress- und Drupal-Installationen gegen Login-Brute-Force, xmlrpc.php-Missbrauch und Scanner auf bekannte Schwachstellen
• Mailserver (Postfix und Dovecot) gegen Passwort-Sprays auf Postfächer und SMTP-Authentifizierung
• FTP/SFTP-Zugänge gegen automatisierte Login-Versuche
• DNS (BIND) gegen unerwünschte Anfragen von außen
• ISPConfig-Control-Panel gegen Angriffe auf die Verwaltungsoberfläche
• den gesamten Server gegen Portscans aus dem Kernel heraus

Zwei Schutzschichten: Agent auf dem Server, Hive in WordPress

Der Linux Agent schützt den gesamten Server auf Kernel-Ebene. Für WordPress-Websites gibt es von ReportedIP zusätzlich das Plugin ReportedIP Hive, das direkt in der Anwendung arbeitet. Beide nutzen dasselbe ReportedIP-Netzwerk, werden aber getrennt lizenziert: Server zählen als eigener Pool, unabhängig von den Domains des Hive-Plugins. Zusammen ergeben sie zwei Schutzschichten, eine für den Server und eine für die einzelne Website.

Zusammen mit unseren bestehenden Maßnahmen wie täglichen Updates, Echtzeit-Backups und Serverstandort Deutschland entsteht so ein mehrschichtiger Schutz.

Datenschutz: Was den Server verlässt und was nicht

Für Hoster ist das die entscheidende Frage, denn sie verantworten den Traffic aller Kunden. Der Agent ist bewusst sparsam gebaut:

• Keine Log-Zeilen, Payloads, User-Agents, URLs oder Benutzernamen verlassen den Server.
• Eine Meldung besteht nur aus IP-Adresse, Kategorie-IDs und einem generierten Satz.
• Access-Logs mit anonymisierten Adressen werden übersprungen, damit nie ein ganzes Netz gemeldet wird.
• API und Feed laufen in der EU und werden aus Deutschland betrieben.
• Die Dienste laufen mit systemd-Sandboxing.
• Bei Deinstallation bleibt nichts gesperrt, weil jede Sperre einen Kernel-Timeout hat.

Für wen sich der ReportedIP Agent lohnt

Server-Admins mit einem einzelnen Server: Installation, erste Synchronisation, Status prüfen. Nach wenigen Minuten ist der Server im Netzwerk. Der Testlauf über die echten Logs zeigt vorab, was gesperrt worden wäre.

Hoster und Reseller mit Shared Hosting: Web, Mail, FTP, DNS und Panel auf einer Maschine, Hunderte Websites, alle vHost-Logs automatisch erkannt. Neue Kunden-Websites sind ohne Konfiguration abgedeckt.

Rechenzentren und Managed-Server-Betreiber: Unbeaufsichtigte Installation per Ansible oder cloud-init, signierte Selbst-Updates, Gruppen-Sperren und Zabbix-Anbindung für das NOC.

Agenturen mit eigenen Servern: Wer die Websites seiner Kunden selbst hostet, schützt mit einem Werkzeug alle Dienste gleichzeitig, statt auf jeder Website ein eigenes Sicherheits-Plugin zu pflegen.

Installation in wenigen Minuten

Die Installation erfolgt mit einem Befehl als root:

curl -fsSL https://reportedip.com/agent/install.sh | sh

Das Skript zeigt zuerst die Nutzungsbedingungen, fragt nach dem API-Schlüssel und stellt drei kurze Fragen, bei denen Enter jeweils die sichere Antwort wählt. Es prüft Root-Rechte, Plattform und Architektur, lädt das passende Binary, verifiziert es gegen SHA256SUMS und schreibt die Konfiguration selbst. Für automatisierte Rollouts gibt es eine Variante ganz ohne Rückfragen über Umgebungsvariablen. Alle Optionen beschreibt die offizielle Installationsanleitung von ReportedIP.

Keine Zeit für die Einrichtung? Wir installieren den Agent für Sie

Den Agent auf einem Testserver zu starten, dauert wenige Minuten. Ihn auf produktiven Hosting-Servern sauber einzurichten, ist eine andere Aufgabe: Schwellenwerte pro Dienst, Whitelists für Monitoring und Kundennetze, eigene Regeln, Gruppen-Sperren über mehrere Server und die Anbindung an Ihr Monitoring.

Genau das übernehmen wir. Weil wir den ReportedIP Agent auf unserem eigenen Server-Netzwerk betreiben, kennen wir die Stolpersteine aus der Praxis. Wir bieten Ihnen:

• Installation und Ersteinrichtung auf Ihren Linux-Servern, inklusive Testlauf über Ihre echten Logs, bevor die erste Sperre aktiv wird
• Abstimmung auf Ihren Stack, etwa ISPConfig, nginx, Postfix und Dovecot, mit passenden Schwellenwerten und Ausnahmen
• Flotten-Rollout für mehrere Server mit Gruppen-Sperren und zentraler Whitelist
• Monitoring-Anbindung an Zabbix, Icinga, Checkmk oder Nagios
• laufende Betreuung im Rahmen unserer Server- und Wartungsleistungen

Schreiben Sie uns an support@cms-admins.de oder rufen Sie an unter +49 89 21550588-8. Wir prüfen Ihre Server und sagen Ihnen, was die Einrichtung bei Ihnen umfasst.

Kosten

Erkennung, lokale Sperren und Meldungen funktionieren auf jedem Tarif, auch mit einem kostenlosen Schlüssel. Die Server-Lizenz schaltet die Community-Blocklist frei. Im Professional-Tarif ist ein Server enthalten, im Business-Tarif drei. Weitere Server kosten ab 4,90 € im Monat, bei größeren Flotten sinkt der Preis gestaffelt bis 1,40 € pro Server (jeweils inkl. MwSt., Stand der Herstellerseite).

Häufige Fragen

Ersetzt der ReportedIP Agent fail2ban?

Der Agent übernimmt die Aufgaben von fail2ban und ergänzt sie um eine gemeinsame Blockliste und Gruppen-Sperren. Eine vorhandene fail2ban-Installation kann als zusätzliche Quelle weiterlaufen, sie ist aber nicht nötig.

Verändert der Agent meine bestehende Firewall?

Nein. Er arbeitet in einer eigenen Chain und ändert nur Sets und Regeln, die er selbst angelegt hat.

Kann ich mich selbst aussperren?

Der SSH-Client, der die Installation durchführt, das Gateway, die eigenen Interfaces und private Netze werden nie gesperrt. Zusätzlich gibt es eine eigene Whitelist.

Welche Daten werden übertragen?

Nur IP-Adresse, Kategorie-IDs und ein generierter Satz. Keine Log-Zeilen, URLs, User-Agents oder Benutzernamen.

Was passiert, wenn die Lizenz ausläuft?

Nur der Download der Community-Liste pausiert. Erkennung, lokale Sperren und die bereits geladene Liste bleiben aktiv.

Läuft der Agent mit ISPConfig?

Ja. Fehlgeschlagene Logins ins ISPConfig-Panel sind eine eigene Log-Quelle, und Web-, Mail- und FTP-Logs eines ISPConfig-Servers werden automatisch erkannt.

Fazit

Ein Server, der nur aus seinen eigenen Logs lernt, zahlt jede Lektion selbst. Der ReportedIP Linux Agent dreht das um: Bekannte Angreifer werden im Kernel verworfen, bevor sie einen Dienst erreichen, und jeder eigene Fund schützt alle anderen Server mit. Für uns bei CMS ADMINS hat sich das doppelt gelohnt, mit mehr Sicherheit und mit spürbar mehr Leistung für die Websites unserer Kunden.

Sie möchten Ihre WordPress-Website auf einer so abgesicherten Infrastruktur betreiben oder Ihre eigenen Server professionell betreuen lassen? Oder Sie möchten den ReportedIP Agent auf Ihren eigenen Servern einsetzen und die Einrichtung in erfahrene Hände geben? Sprechen Sie uns an: support@cms-admins.de oder +49 89 21550588-8.