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 Pro, 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.52: Die Entwarnungsmail sagt, was vorbei ist: den letzten Stand des Zustands, Beginn, Ende und Dauer. Der Volumen-Alarm sagt, wer die Flut verursacht: ein Client, wenige oder viele, und ob eine Regel den lautesten zählt. Die Mail enthält nur diese Einschätzung, status nennt die fünf lautesten Clients mit ihrem Anteil.
• 0.3.51: Eine Regel erscheint nach einem Neustart nicht mehr als abgeschaltet, wenn sie voll läuft. Ein Schutzmechanismus hält seine Abschaltung nur im laufenden Daemon; nach einem Update war sie weg, aber status, rules status, die Statusmail und das Monitoring nannten die Regel weiter als abgeschaltet. Der Daemon meldet jetzt beim Start, dass keine Abschaltung aktiv ist.
• 0.3.50: Die simulierte Regel web-query-crawl zählt nicht mehr, was eine Messwoche auf 36 Servern unter ihren Treffern fand: Crawler, die sich ohne das Wort bot nennen, Links aus einem Newsletter, Cache-Buster, einen Schalter ohne Wert als ersten Parameter und wp-cron hinter einem doppelten Schrägstrich. Unter 100 Adressen waren drei Menschen, 30 erklärte Crawler und fünf Werkzeuge; mit der Änderung nachgespielt bleibt kein Mensch übrig. Die Regel bleibt eine weitere Woche simuliert.
• 0.3.49: Ein Client, der in einer Verzeichnisliste im Kreis läuft, wird gesperrt und gemeldet. Die neue mitgelieferte Regel web-listing-loop zählt Anfragen mit einem zweiten Sortierparameter hinter dem ersten, etwa /uploads/?C=N;O=D?C=N;O=D, was kein Browser schickt; 10 in 10 Minuten führen zur Sperre. Die Statusmail sagt jetzt zu jedem Problem, was es bedeutet, welche Befehle weiterhelfen und wo in dieser Dokumentation es weitergeht, und die Mails zu Regeldateien, Ignore-Dateien und zur Reputation des Hosts kommen nicht mehr als text withheld an.
• 0.3.48: Ein filterndes Mail-Relay vor Ihrem Server wird nicht mehr für die Absender gesperrt, die es weiterleitet. postfix-reject zählte einen abgelehnten Umschlag-Absender (Sender address rejected) gegen den einliefernden Server, und hinter einem filternden Relay ist das immer das Relay. Fünf Nachrichten von Absendern ohne Postfach in einer Stunde reichten, um es zu sperren und zu melden, und bis zum Ablauf der Sperre kam keine Mail mehr an. Ein abgelehnter Absender zählt nicht mehr. Gemessen über 20 Tage eines Mailservers änderte das nur das Urteil über eine Adresse, das Relay.
• 0.3.47: Ein eingeloggter WordPress-Admin wird nicht mehr gesperrt, weil er das Dashboard benutzt. admin-ajax.php antwortet mit 400 auf jede Aktion ohne Handler, und das Dashboard eines eingeloggten Admins erzeugt das dutzendfach pro Stunde. Der Erkenner web-app zählte das wie jedes andere 400 unter /wp-admin/, ein Admin konnte so die Schwelle erreichen. admin-ajax.php zählt nicht mehr, jeder andere Pfad unter /wp-admin/ weiterhin.
• 0.3.46: web-query-crawl zählt nur Clients, die sich als Browser ausgeben. Ein Crawler, der sich ohne ein Wort wie bot im Namen zu erkennen gibt, live gemessen mit einem Forschungs-Crawler, konnte die Schwelle erreichen. Die Regel zählt jetzt nur Zeilen, deren User-Agent mit Mozilla/ beginnt, was jeder Browser und jeder getarnte Crawler schickt; ein Werkzeug oder Crawler mit eigenem Namen wird nie gezählt. Die Liste der Crawler-Namen bleibt für die, die ebenfalls mit Mozilla/ beginnen.
• 0.3.45: Eine Betreiberregel wird nicht mehr von einer mitgelieferten Regel verdeckt. Eine Logzeile zählt nur für eine Regel. Bis 0.3.44 liefen die mitgelieferten Regex-Regeln zuerst, die mitgelieferte web-query-crawl, die nur simuliert, nahm also jede Query-String-Zeile mit Status 200, bevor eine Betreiberregel für dieselben Anfragen sie sehen konnte, und die Betreiberregel konnte nicht sperren. Die Regex-Regeln einer Quelle laufen jetzt in der Reihenfolge Betreiber, signiertes Paket, mitgeliefert; die kompilierten Detektoren laufen weiterhin vor allen. Eine junge Betreiberregel nimmt ihre Zeilen darum einer mitgelieferten Regel weg, die sie melden würde, und meldet an ihrem ersten Tag selbst nichts. Eine ausgesetzte Regel gibt ihre Zeilen weiter. Eine Regel, die der Ansturm-Wächter ganz ausgesetzt hatte, behielt bisher jede Zeile, die sie traf, und ihre Ereignisse wurden verworfen. Seit Betreiberregeln zuerst laufen, hätte das die mitgelieferten Regeln derselben Quelle stummgeschaltet, bis die Datei repariert ist; stattdessen zählt die nächste Regel der Kette die Zeile.
• 0.3.44: Ein Volumen-Alarm je Web-Log. Der Daemon zählt jede Zeile jedes Logs, das er liest, und führt eine geglättete Baseline der Zeilen je Stunde: in der ersten Woche voller Stunden einen einfachen laufenden Mittelwert, danach ein exponentielles Mittel mit einer Woche Gedächtnis. Liest die laufende Stunde eines Web-Logs (Quellen web und web-error) mindestens das volume_factor-Fache dieser Baseline und mindestens volume_min_lines Zeilen, geht der Zustand volume auf Warnung, es sind jetzt dreizehn Zustände. Die Defaults sind 8 und 20000; volume_factor: 0 schaltet den Alarm ab, sonst nimmt der Schlüssel 2 bis 1000, volume_min_lines nimmt 0 bis 100000000. Vor 24 vollen Stunden Baseline alarmiert nichts. Der Alarm sperrt und meldet nichts: Sein Text nennt die lauteste Website (den Namen des Verzeichnisses des Logs, meist der Vhost) und verweist für die vollständige Liste auf reportedip-agent status, und er schließt sich nach einer vollen ruhigen Stunde. status zeigt je Quelle lines= und hour=<running>/<baseline>, mit LOUD während des Alarms, /-, solange die Baseline jünger als ein Tag ist, und /off für ein Log, das der Alarm nicht beachtet. status --json (Schema 1, nur ergänzt) bekommt je Quelle lines, hour_lines, baseline_hour und volume_alarm. Die Baseline übersteht einen Neustart innerhalb einer Stunde; ein Daemon, der länger stand, beginnt die Woche neu. Eine gelieferte Regel, web-query-crawl, in der Simulation. Sie zählt GET-Anfragen mit Query-String, Status 200 und ohne eigenen Referer (leer oder eine Suchmaschine wie Google oder Bing), 20 in 60 Minuten je Adresse, Kategorie 19. Sie ignoriert statische Assets, Pfade unter /wp-json/ und /wp-admin/, wp-cron, die gewöhnlichen Query-Schlüssel von WordPress, WooCommerce und Tracking (p, s, wc-ajax, utm_*, fbclid, gclid und ähnliche) und jede Zeile, deren User-Agent einen Crawler erklärt (bot, crawler, spider, Barkrowler, Turnitin, GPTBot, Ahrefs, Semrush und andere): Ein Crawler, der sagt, wer er ist, wird von dieser Regel nicht gesperrt. Ein gefälschter Crawler-Name entkommt ihr mit Absicht; die Scanner- und Login-Regeln zählen ihn weiter. Sie meldet nichts, ein Crawl ist ein Ärgernis und keine Community-Daten. Sie wird mit simulate: true ausgeliefert, protokolliert also Warnungen simulated ban und sperrt nichts. Abschalten mit reportedip-agent rules disable web-query-crawl; scharf stellen mit einer Überschreibungsdatei unter /etc/reportedip-agent/rules.d/ mit format: 1 und, unter rules:, - id: web-query-crawl und action: {simulate: false}, einem Feld, das nur das Verhalten betrifft, es folgt also kein Beobachtungstag. Vor der Auslieferung auf fünf Servern über zwei Tage gemessen: kein Besucher und kein Monitoring über der Schwelle, nur Crawler und Bots.
• 0.3.43: Eine Sperrzeit je Regel. action.time_minutes in einer Regeldatei setzt die erste Sperrzeit dieser Regel, von einer Minute bis zu einem Jahr; Eskalation und max_time_minutes der Config gelten wie bisher, und eine Wiederholung eskaliert ab der ersten Zeit der Regel, die sie auslöst. Die gelieferten Regeln setzen keinen Wert, ein Host ändert durch das Update also nichts. rules list zeigt ban 120 min. Simulation je Regel. reportedip-agent rules simulate <id> lässt die Regel weiter erkennen und melden und macht aus ihrer Sperre eine Warnung, simulated ban, einmal je Regel und Adresse für die erste Sperrzeit der Regel, gedeckelt durch max_time_minutes, mit der Adresse, der Regel und dem Weg, das zu beenden. Zu finden mit journalctl -u reportedip-agent | grep "simulated ban". rules enable <id> beendet es. Eine Regel, die nicht sperrt, lässt sich nicht simulieren. Ignore-Muster je Quelle. /etc/reportedip-agent/ignore.d/<source>.conf enthält einen regulären Ausdruck je Zeile; eine passende Zeile wird verworfen, bevor ein Erkenner sie sieht. Ein Healthcheck, eine Monitoring-Probe oder ein ACME-Pfad braucht keine Überschreibung einer Regel mehr, und nichts kommt unter Beobachtung. Ein Muster, das eine Zeile verschlucken würde, die die gelieferten Regeln laut ihren Tests erkennen, wird abgewiesen, ebenso Muster unter vier Bytes und Muster, die den leeren String treffen; eine fehlerhafte Datei fällt allein weg, die Regeln laufen weiter, und rules check, status und doctor nennen die Datei. Der Daemon meldet das unter dem neuen Health-Zustand ignore. Ein Muster gilt für jede Quelle, die dasselbe Log liest. status zählt ignored= je Quelle, test gibt ignored: aus. ban list --json und ban list --plain. Das JSON (Schema 1) enthält jeden Eintrag mit Kernel-Zustand, Anzahl, Quelle und Kategorien, dazu die Einträge, die nur im Kernel stehen. --plain gibt die wirksamen Adressen aus, eine je Zeile, für ein nginx-deny-Include oder eine HAProxy-ACL-Datei, in jedem Modus. Kann das Kernel-Set nicht gelesen werden, endet der Export mit Exit 1 und gibt keine Liste aus, damit ein Skript nie eine verkürzte Deny-Datei nachlädt. Eine Überschreibung des Verhaltens macht eine Regel nicht mehr jung. Bis 0.3.42 stellte jede Überschreibung einer gelieferten Regel, sogar action: {report: false} allein, die Regel für einen Tag unter Beobachtung: sie sperrte und meldete nicht. Jetzt tut das nur noch eine Überschreibung von source, event, match, addr, threshold oder examples. Ein Host, dessen Betreiber eine Sperre auf diesem Weg stummgeschaltet hat, meldet nach diesem Update wieder; der Schutz gegen Bursts und das Whitelist-Gitter bleiben bestehen. Eine falsche categories-Überschreibung erreicht den Feed jetzt ebenfalls ohne den Beobachtungstag: falsche Labels, nie falsche Adressen, und dieser Kompromiss ist gewollt.
• 0.3.42: Eine abgewiesene Seitenressource zählt nicht mehr als blockierte Anfrage. Die Quelle web-error zählte jede Zeile access forbidden by rule und client denied by server configuration, ganz gleich, was angefragt wurde. Ein Stylesheet mit einem vertippten Font-Pfad unter einer deny all-Regel für Punktdateien ließ einen Host vier Abweisungszeilen je Seitenaufruf schreiben und an einem Tag fünfzig Besucher eines Kundenportals sperren, keiner davon ein Scanner. Die Abweisung eines Fonts, Bildes, Stylesheets oder Skripts oder von allem unter /.well-known/, das Browser und Passwortmanager von sich aus abfragen, wird jetzt ignoriert. Proben auf /.env, /.git/ und Ähnliches zählen weiter. Die Font-Endungen .ttf, .otf und .eot kommen auch in die Asset-Liste der Accesslog-Quelle. Ein Host mit so einer Site sollte trotzdem in sein Error-Log sehen: die Seite ist kaputt, der Agent hört nur auf, ihre Besucher dafür zu bestrafen.
• 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: 12. November 2026 · Betreut vom ReportedIP-Team