Den Linux-Agenten betreiben

Die Befehle und ihre Exit-Codes, was die drei systemd-Units tun, wie status und doctor ins Monitoring passen, test statt fail2ban-regex, und die Tabelle zur Problembehebung: Symptom, Ursache, Befehl.

Befehle

test, statt fail2ban-regex

test lässt die Detektorkette über eine Logdatei laufen, die Sie schon haben, mit den Schwellwerten und der Whitelist dieses Hosts, und gibt aus, welche Adressen einen Schwellwert überschritten hätten und an welcher Stelle der Datei. Es meldet nichts, blockt nichts und schreibt nichts, es ist also auf einem Produktionshost gefahrlos und die ehrliche Antwort auf die Frage, ob das den Angriff von letzter Woche erwischt hätte.

# A configured source: the type is taken from the config
reportedip-agent test /var/log/auth.log

# Any other file: name the type yourself
reportedip-agent test --type postfix /var/log/mail.log.1

# A rotated log and its successor as one stream, in this order,
# so a window that spans the rotation counts like the daemon saw it.
# A .gz is read inflated.
reportedip-agent test /var/log/mail.log.2.gz /var/log/mail.log.1 /var/log/mail.log

# Every single hit, with line number, address and timestamp
reportedip-agent test --lines /var/log/auth.log

Die Zusammenfassungszeile nennt die gelesenen Zeilen, wie viele passten, wie viele keinen brauchbaren Zeitstempel trugen und wie viele als überlang übersprungen wurden. Danach eine Zeile pro Adresse mit ihren Treffern, ihren Zurücksetzungen, ob sie gesperrt worden wäre und wie oft, dem Zeitpunkt des ersten Treffers und dem angewendeten Schwellwert. Eine Adresse auf Ihrer Whitelist wird mit der Schicht gezeigt, die gegriffen hat, und als nie gesperrt und nie gemeldet markiert. Das macht diesen Befehl zum schnellsten Weg, einen Whitelist-Eintrag tatsächlich nachzuweisen.

Zwei Dinge macht test nicht. Es rät kein Format: ohne --type muss die Datei einer der konfigurierten Quellpfade sein, sonst sagt es das und zählt die gültigen Typen auf. Und es wendet die Gewichtung aus der Bann-Historie nicht an, der Daemon braucht für eine Adresse mit früheren Sperren also weniger Treffer, als diese Wiederholung vermuten lässt.

Betrieb

Drei systemd-Units, von install geschrieben und aktiviert und von jedem Sync auf den Stand der laufenden Version gebracht. Eigene Änderungen gehören in ein Drop-in unter /etc/systemd/system/<unit>.d/, dort überleben sie ein Update. Eine Unit, die Sie direkt bearbeitet haben, wird ersetzt, die vorherige Fassung bleibt als <unit>.bak daneben liegen, und das Journal nennt beide.

Beide Dienste laufen mit NoNewPrivileges, ProtectHome, PrivateTmp, gesperrter Personality und einem eingeschränkten Satz an Adressfamilien.

systemctl list-timers reportedip-agent-sync.timer
systemctl status reportedip-agent.service --no-pager
journalctl -u reportedip-agent.service -n 50 --no-pager
journalctl -u reportedip-agent-sync.service -n 50 --no-pager
tail -n 100 /var/log/reportedip-agent.log

Exit-Codes

Damit ist reportedip-agent status direkt als Monitoring-Prüfung verwendbar, ohne Wrapper-Skript und ohne Ausgabe zu parsen. status --json gibt dasselbe Ergebnis als JSON-Dokument aus; die Einrichtung für Zabbix, Nagios, Icinga, Checkmk und Prometheus steht unter Monitoring.

Die Reputation der eigenen Adresse dieses Hosts

Der Sync-Lauf fragt den Server mindestens einmal am Tag, und bei offenem Zustand in jedem Lauf, was er von der Adresse hält, von der dieser Host meldet. Steht diese Adresse selbst in der Community-Datenbank, warnt status und endet mit Exit 1. Ab einer Confidence von 75 ist zusätzlich der Zustand reputation offen, mit der Confidence, der Anzahl der Reports und dem Link auf die Delisting-Seite im Text. Es ist eine Warnung und kein Fehler, denn eine gelistete Adresse ist eine Aussage über das Netz, in dem der Host steht, und nicht zwingend über den Host: eine geteilte Adresse, ein Carrier-NAT oder ein Nachbar hinter demselben Proxy können sie dorthin bringen. Einen Blick ist es trotzdem wert, denn ein Host, der von einer gelisteten Adresse meldet, sieht von außen so aus wie ein übernommener Host. Prüfen Sie, was die Maschine verlässt, beantragen Sie das Delisting, sobald sie sauber ist, und der Zustand verschwindet mit dem nächsten Sync nach dem Delisting; auf dem Host ist nichts zurückzusetzen. Unter 75 entsteht kein Zustand: eine Handvoll alter Reports ist ehrliche Datenlage und nichts, worauf ein Betreiber reagieren kann, und kein Feed liefert eine Adresse mit diesem Wert aus.

Problembehebung

Ein Symptom, eine wahrscheinliche Ursache, ein Befehl. reportedip-agent doctor und reportedip-agent status beantworten gemeinsam die meisten dieser Fälle, und es sind die zwei Dinge, nach denen der Support zuerst fragt.

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