ReportedIP-Agent für Linux

Der Agent ist eine einzelne statische Binärdatei und erledigt auf einem Linux-Server zwei Aufgaben: Er hält die Community-Blacklist in der Kernel-Firewall aktuell und meldet die Angreifer, die er in den Logs dieses Servers findet. Auf Wunsch blockiert er diese lokalen Funde auch selbst. Er ersetzt das handgeschriebene Sync-Skript aus dieser Dokumentation und übernimmt die Arbeit, die bisher fail2ban gemacht hat.

Funktionsweise

Wo es weitergeht

• Installation: die Nutzungsbedingungen, die Prüfungen, jede Frage, die Flags und Variablen eines Rollouts, ein Host ohne systemd.
• Installationsbeispiele: Ansible und cloud-init, ein Golden Image, Control Panels, ein Mail- oder Datenbank-Host, LXC-Container und Cloud-Firewalls.
• Konfiguration: jeder Schlüssel von config.yaml, die Schwellwerte, die Eskalationsleiter, die Mail, und wann eine Änderung greift.
• Erkennung und Regeln: die Quelltypen, Port-Scans aus dem Kernel-Log, eine Quelle nachtragen, die der Installer nicht fand, was die Maschine verlässt, und die Regeldateien.
• Blocken: die zwei Arten von Set, wie eine Sperre entsteht und endet, die Kette im Kernel, und wie eine Sperre aufgehoben wird.
• Gruppen: flottenweite Sperren über Ihre Server und WordPress-Websites, die Tarifgrenzen, die Whitelist und der Webhook.
• Betrieb: Befehle, Exit-Codes, die Units, Monitoring, die Reputation der eigenen Adresse und die Tabelle zur Problembehebung.
• Lizenzen: eine Lizenz pro Server, das Report-Budget, Gruppen ab Professional, und was ohne Lizenz läuft.
• fail2ban ersetzen: die Migration in drei Schritten, und der Weg zurück.

Voraussetzungen

Mehr nicht. Die Binärdatei ist statisch gelinkt und ohne cgo gebaut, bringt also keinen Interpreter, keine Shared Library, kein Paketrepository und keinen eigenen Cron-Helfer mit. Entwickelt und gemessen wurde der Agent auf Debian 12 (bookworm) auf arm64 mit ISPConfig, nginx, Postfix, pure-ftpd und bind.

ipset oder nftables, und was auto entscheidet

Beide Backends tun dasselbe. Entscheidend ist, welches der Host schon benutzt, denn zwei Paketfilter, die dieselbe INPUT-Kette beschreiben, sind die Art, wie ein Nachmittag verschwindet.

Es zählt nur ein Binary, das existiert, nie eine Versionsangabe: iptables --version sagt auf einem Host mit nft-Backend etwas, das richtig aussieht und nichts bedeutet. Hat ein Host einmal synchronisiert, ist das gewählte Backend festgehalten, und eine spätere Änderung braucht reportedip-agent sync --migrate-backend, statt still einen zweiten Satz Regeln zu bauen.

Zuerst den Host prüfen

doctor ist der Befehl, der vor der Installation läuft. Er ändert überhaupt nichts: keine Datei, kein Verzeichnis, keine Regel, kein Set. Alles, was er berichtet, hat er gelesen.

reportedip-agent doctor

Das Urteil lesen

Lassen Sie doctor nach der Installation noch einmal laufen. Mit einer Config berichtet er die konfigurierten statt der erkannten Quellen und ergänzt die Uhrenabweichung pro Quelle, die der Daemon gemessen hat. Eine Quelle, deren Log jede Zeile mehr als eine Minute neben der Systemuhr stempelt, hat ein Zählfenster, das sich nie füllt, und das ist der eine Fehler, der genau wie „der Detektor funktioniert nicht“ aussieht.

Schnellinstallation

Drei Befehle auf einem Host, der noch nichts davon hat. Führen Sie sie in dieser Reihenfolge aus, dann meldet der Agent, die Community-Listen stehen im Kernel, und verworfen wurde nichts, dem Sie nicht zugestimmt haben.

# 1. Install, as root. At a terminal it shows the terms of use and
#    takes a yes, then asks for your key, then three short questions;
#    an Enter answers drop and local bans on.
curl -fsSL https://reportedip.com/agent/install.sh | sh

#    For automation, and for fifty hosts, nothing is asked: the terms
#    are accepted up front and the key comes from the environment.
curl -fsSL https://reportedip.com/agent/install.sh | REPORTEDIP_ACCEPT_TERMS=1 REPORTEDIP_KEY="YOUR_API_KEY" sh

# 2. The first sync builds the chain and the sets. The installation
#    itself touches no firewall rule.
reportedip-agent sync

# 3. See that it ran, and read what would be dropped before it is.
reportedip-agent status
reportedip-agent doctor
reportedip-agent test /var/log/auth.log

Was jeder Befehl hinterlässt: der erste legt die Binärdatei nach /usr/local/bin, schreibt /etc/reportedip-agent/config.yaml aus dem, was er auf diesem Host gefunden hat, und installiert die drei systemd-Units. Der zweite legt die Firewall-Kette und die Sets an, die die Installation bewusst nicht anfasst, und füllt sie. Der dritte ist der Beweis: status zeigt eine Anzahl an Einträgen je Liste und den Lizenzzustand dieses Hosts, doctor nennt alles, was fehlt, und test spielt Ihr eigenes Log nach und zeigt, welche Adresse welche Schwelle überschritten hätte. Die Regeln verwerfen ab dem ersten Sync, denn genau das schreibt die Installation, die Whitelist gehört also vor diesen Sync und nicht zwei Tage danach. Antworten Sie stattdessen log für einen Host, auf dem Sie erst ein Journal lesen wollen. Die Installationsseite ist dieselbe Installation, vollständig erklärt, und diese Tiefe ist der Grund, warum es sie gibt.

Die erste Stunde, in der richtigen Reihenfolge

Jeder Schritt beantwortet eine Frage, von der der nächste abhängt. In einer anderen Reihenfolge sieht eine funktionierende Installation kaputt aus.

1. reportedip-agent doctor. Vor allem anderen, denn es ist der einzige Befehl, der nichts verändert.
2. reportedip-agent sync. Der erste Lauf baut die Kette, legt die Sets an und lädt die konfigurierten Listen, eine nach der anderen mit einer kurzen Pause dazwischen.
3. reportedip-agent status. Prüfen Sie, dass jede konfigurierte Liste eine plausible IPv4-Zahl hat, dass die Kette ok meldet, dass die Whitelist die erwarteten Adressen enthält, und dass account Ihre Rolle und den Lizenzstatus dieses Hosts zeigt.
4. Die Whitelist richten. Der Installer hat die Adresse Ihrer SSH-Sitzung aufgenommen, und das ist eine Vermutung. Ersetzen Sie sie durch den Bereich, aus dem Sie wirklich administrieren, und tragen Sie Monitoring, Backup-Host und Büro-Bereich gleich mit ein.
5. Nach einem Tag status noch einmal lesen. Die Paketzähler der Kette sagen, wie viel die Regeln wirklich gestoppt haben, und ban list sagt, welche Adressen dieser Host in seinen eigenen Logs erwischt hat.
6. Nur auf einem Host, für den Sie log geantwortet haben: die Regeln sind vollständig gebaut und greifen, sie loggen nur statt zu verwerfen, das Kernel-Log zeigt Ihnen also genau, was drop abgeschnitten hätte. Lesen Sie ein Journal, setzen Sie dann mode: drop und lassen Sie sync laufen, das baut die Regeln neu.

reportedip-agent doctor
reportedip-agent sync
reportedip-agent status
reportedip-agent whitelist add 203.0.113.0/24 "management"
reportedip-agent whitelist add 198.51.100.7   "monitoring"
reportedip-agent whitelist list

Upgrades und Release Notes

Der Agent sucht alle sechs Stunden nach einem neuen Release, innerhalb des Sync-Laufs. Er prüft den Download gegen eine Ed25519-Signatur mit dem in die Binärdatei eingebauten öffentlichen Schlüssel, holt die laufende Binärdatei zurück, falls der Tausch scheitert, und startet den Watch-Dienst selbst neu. reportedip-agent update macht dasselbe auf Wunsch, und update --check berichtet nur, was veröffentlicht ist.

Den Install-Befehl erneut auszuführen aktualisiert einen Host ebenfalls. Ein Host unter der Mindestversion, die der Dienst unterstützt, aktualisiert sich trotzdem selbst; bis dahin warnt der Agent davor in seinem Log, in status (Exit 1) und in update --check. Downgrades werden generell abgelehnt, ein Host, der eine neuere Version geholt hat, geht also nicht von allein zurück.

Was das aktuelle Release geändert hat, ist öffentlich und braucht keinen Key:

curl -s https://reportedip.com/agent/whats-new
reportedip-agent update --check

Änderungen an der REST-API selbst, also Response-Felder und Statuscodes, die eine Integration betreffen, stehen stattdessen im API-Changelog.

Letzte Releases

• 0.3.41: --admin-ip nimmt jetzt wirklich einen CIDR-Bereich. Bis 0.3.40 wurde ein Bereich auf seine Netzadresse gekürzt, in der Auto-Whitelist landete also nur diese eine Adresse. Mit backend: auto bevorzugt der Agent ipset, und die Hinweise des Installers sagen das jetzt auch.
• 0.3.40: status --json für das Monitoring: ein Dokument mit Schema 1 und demselben Urteil und Exit-Code wie der Text, ohne Anfrage an die API, und auch eine kaputte Konfiguration (Exit 2) liefert noch ein Dokument. status meldet einen gestoppten watch-Daemon jetzt mit Exit 1: der Daemon hinterlässt alle 30 Sekunden einen Heartbeat, und einer, der älter als zwei Minuten ist, gilt als gestoppt. Die Einrichtung für gängige Monitoring-Systeme steht unter Monitoring.
• 0.3.39: Die Port-Scan-Regel bannt keine FTP-Clients im Passivmodus mehr. Jede Datenverbindung geht auf einen Port, den der Server nur für diese eine Übertragung öffnet, die Regel kannte die lauschenden Ports aber nur aus dem letzten Sync, und so sah der Upload eines Ordners nach wenigen Sekunden wie ein Scan aus. Die Regel fragt jetzt den Kernel, ob in diesem Moment ein Socket auf dem Port lauscht (-m socket --nowildcard bei iptables, socket transparent bei nftables), und der Passivbereich eines laufenden pure-ftpd, proftpd oder vsftpd wird aus dessen Konfiguration gelesen und aus der Regel ausgenommen. Bei einem Server ohne konfigurierten Bereich bleibt stattdessen der ephemere Portbereich des Kernels außen vor. Die Kette wird beim nächsten Sync einmal neu gebaut.
• 0.3.38: install nimmt das Log-Level, als --log-level debug|info|warn|error oder als REPORTEDIP_LOG_LEVEL. Der Default bleibt unverändert bei warn. Ein Rollout, der auf jedem Host mitlesen will, sagt einmal info, statt hinterher die Config jedes Hosts zu bearbeiten, und ein Level, das der Parser ablehnen würde, wird abgelehnt, bevor etwas geschrieben ist.
• 0.3.37: ein Dienst, der nur auf Loopback lauscht, gilt nicht mehr als erreichbar. Die Portprüfung zählte jeden Listener in der Kernel-Tabelle, ganz gleich an welche Adresse er gebunden war, also sah der Stub-Resolver, der auf einem gewöhnlichen Debian-Host 127.0.0.53:53 hält, wie ein Nameserver aus, und ein Mailserver, der Mail nur von der eigenen Maschine annimmt, wie einer, der sie aus dem Internet annimmt. Ein Port, der neben einem echten Socket auch einen Loopback-Socket hat, zählt weiter. Das entscheidet auch, welche Ports die Port-Scan-Regel als offen behandelt.
• 0.3.35: doctor nennt ein Log, das dieser Host schreibt und das keine Quelle liest, und sagt, wo die Quelle hingehört. Die Erkennung läuft einmal, bei der Installation, und das bleibt so, denn ein Dienst, der für eine Wartung gestoppt ist, darf nie eine Quelle abschalten. Die andere Richtung hatte niemanden, der sie beobachtet: ein Mailserver, der auf einem Host installiert wird, der vorher keinen hatte, wurde nicht erfasst, und der Host sah gesund aus, während dieser Dienst unbeobachtet blieb. Der Fund ist Exit 1 wert.
• 0.3.34: install liest die Weblogs aus der Konfiguration des Webservers selbst, samt der Vhost-Dateien unter conf.d und sites-enabled, statt aus einer Liste von Standardnamen. Ein echtes Hosting-Setup benennt seine Logs nach der Site, die Standardpfade fanden also das Standardlog und übersahen den Rest: auf einem gemessenen Host wären zwei weitere Logs ungelesen geblieben, eines davon ein Access-Log mit echten Adressen. Ein Log, dessen Format die Client-Adresse verdeckt, bleibt weiterhin außen vor, und jedes so übernommene Log wird bei der Installation in einer Zeile genannt.
• 0.3.32: status nennt einen Host nicht mehr degraded, weil seine Gruppenliste leer ist, was der normale Zustand eines Keys ist, der in keiner Gruppe ist, und doctor behauptet nicht mehr, es gebe keine Log-Quelle auf einem Host, dessen sshd ins Journal schreibt statt in eine Datei.
• 0.3.29: eine frische Installation schreibt log_level: warn statt info, ein neuer Host bleibt im Journal also still, bis etwas Aufmerksamkeit braucht. Die Routinezeilen, eine aktualisierte Liste, ein eingereihter Report, ein gesetzter lokaler Bann, sind unverändert und ein Wort entfernt. Ein Host, der schon installiert ist, behält, was in seiner Config-Datei steht.
• 0.3.27: die Whitelist der Gruppe: Adressen und Präfixe, die eine Gruppe in Ihrem Konto nennt, werden von keinem Mitglied gesperrt oder gemeldet. Der Sync liest sie mit der Gruppenliste, schreibt sie als group-whitelist unter das State-Verzeichnis und wendet sie im selben Lauf auf das Kernel-Whitelist-Set, den Listenfilter und das Report-Gate an; whitelist list und status zeigen die Einträge mit Notiz. Die Whitelist dieses Hosts, die Auto-Whitelist und die eingebauten Ebenen bleiben unverändert.
• 0.3.26: ein schneller Port-Scan blieb unter seiner eigenen Schwelle: die Scan-Regel protokollierte zehn SYNs je Minute mit dem Standard-Burst des Kernels von fünf, ein Scanner, der tausend Ports in wenigen Sekunden anfragt, hinterließ also fünf Zeilen, und die Regel braucht zehn. Die Regel hat jetzt einen Burst von zwanzig, die ersten zwanzig Anfragen eines Scans werden sofort protokolliert, danach hält die Rate das Log ruhig. Die Kette wird einmal neu gebaut.
• 0.3.25: ein Host, dessen Key in keiner Gruppe ist, verlor mit 0.3.24 seine Kette, weil das Gruppen-Set erst der erste Feed anlegt und die Regel, die es nennt, abgelehnt wurde. Jedes Listen-Set wird jetzt angelegt, bevor eine Regel es nennt. 0.3.24 wurde zurückgezogen.
• 0.3.24: die Gruppenliste group im Set rip-group auf jedem Port; die Reputation der Adresse, von der dieser Host meldet, als Zustand reputation; Port-Scan-Erkennung aus dem Kernel-Log mit der Quelle scan. Die Kette wird nach diesem Update einmal neu gebaut, und ihre Paketzähler beginnen von vorn.

Ressourcenverbrauch

Gemessen auf einem Debian-12-arm64-Host mit sieben Logdateien unter dem Agenten: 16,6 MB resident belegter Speicher. Es gibt keinen Interpreter zu starten, keine Datenbank und kein Cache-Verzeichnis, das erst warm werden muss, und das ist der größte Teil der Erklärung für diese kleine Zahl.

Was der Agent nicht ist

Er ist kein Malware-Scanner, keine Web Application Firewall und kein Ersatz für Imunify360. Er liest Ihre Dateien nicht, untersucht keine Request-Bodies und stellt nichts in Quarantäne. Er blockt und meldet Adressen, und das tut er auf einer kleinen, prüfbaren Oberfläche. Für Schutz auf der Ebene einer einzelnen Anfrage auf einer WordPress-Site nehmen Sie stattdessen das Hive-Plugin. Die beiden laufen auf derselben Maschine, ohne sich zu stören.

Zuletzt aktualisiert: 30. September 2026 · Betreut vom ReportedIP-Team