Releases

ReportedIP Linux Agent 0.3.48: Monitoring, Regelsteuerung und weniger Fehlsperren

9. Oktober 2026 · Patrick Schlesinger

Der ReportedIP Linux Agent 0.3.48 liefert Monitoring-Systemen einen Health-Check als JSON, lässt Betreiber eine Sperrdauer pro Regel setzen, eine Regel simulieren und bekannt harmlose Log-Zeilen verwerfen, und sperrt weder FTP-Kunden noch WordPress-Admins oder filternde Mail-Relays. Die Version schließt 21 Releases ab, die zwischen dem 28. September und dem 9. Oktober 2026 erschienen sind, die meisten ausgelöst durch Messungen auf Servern, auf denen der Agent bereits läuft.

Ein Server mit aktivierten automatischen Updates holt sich 0.3.48 bei der nächsten Update-Prüfung, die der Sync-Lauf alle sechs Stunden ausführt. Alles Weitere zum Agent finden Sie auf der Produktseite des Linux Agent und in der Dokumentation des Agent.

Was hat sich zwischen Linux Agent 0.3.27 und 0.3.48 geändert?

Bereich	Releases	Wichtigste Änderung
Monitoring	0.3.31, 0.3.32, 0.3.40	status --json, Heartbeat des Daemons, kein Fehlalarm auf Servern ohne Gruppe
Regelsteuerung	0.3.43, 0.3.45	Sperrdauer pro Regel, Simulation, Ignorier-Muster, eigene Regeln zuerst
Bot-Fluten	0.3.44, 0.3.46	Volumen-Alarm pro Web-Log, mitgelieferte Crawl-Regel im Simulationsmodus
Weniger Fehlsperren	0.3.39, 0.3.42, 0.3.47, 0.3.48	Passives FTP, abgewiesene Seitenressourcen, WordPress admin-ajax, filternde Mail-Relays
Installation und Diagnose	0.3.29, 0.3.30, 0.3.34 bis 0.3.38, 0.3.41	Web-Logs aus der Serverkonfiguration, Log-Level, doctor findet unbeobachtete Dienste

Gruppenliste und Gruppen-Whitelist kamen kurz vor dieser Reihe, mit 0.3.24 und 0.3.27; sie werden in IP-Sperren über Linux-Server teilen behandelt.

Wie überwache ich den Linux Agent mit Zabbix, Nagios oder Prometheus?

Seit 0.3.40 gibt reportedip-agent status --json ein JSON-Dokument mit demselben Urteil und demselben Exit-Code wie die Textausgabe aus: status ist ok, degraded oder error, und problems nennt jeden Grund hinter Exit 1. Dazu kommen die Werte, die sich als Graph lohnen: Listengrößen, Alter des letzten Syncs, aktive Sperren, Länge der Warteschlange und der Zustand jeder Log-Quelle.

• Keine API-Anfrage. Der Kontoteil ist die Antwort, die der letzte Sync zwischengespeichert hat, ein Check alle paar Minuten kostet also nichts.
• Ein stabiler Vertrag. Das Dokument trägt schema: 1, und unter dieser Nummer kommen Felder nur hinzu.
• Ein gestoppter Daemon ist ein Fehler. Der Watch-Daemon hinterlässt einen Heartbeat, und status endet mit Exit 1, wenn er fehlt oder älter als zwei Minuten ist. Vorher blieben die Listen im Kernel, und nichts sah falsch aus, während nichts mehr erkannt wurde.
• Keine Fehlalarme. Ein Server, dessen Key in keiner Gruppe ist, gilt nicht mehr als beeinträchtigt (0.3.32), und die Reputation der eigenen Adresse warnt erst ab Confidence 75, der niedrigsten Stufe, die ein Feed ausliefert (0.3.31).

Fertige Einrichtungen für Zabbix, Nagios und Icinga, Checkmk und Prometheus stehen auf der Monitoring-Seite; die Exit-Codes sind unter Betrieb aufgeführt.

Wie steuere ich eine einzelne Erkennungsregel?

0.3.43 brachte vier Stellschrauben, für die vorher ein Regel-Override oder eine Konfigurationsänderung für den ganzen Server nötig war:

Stellschraube	Wie	Was sie bewirkt
Sperrdauer pro Regel	action.time_minutes in einer Regeldatei	Legt die erste Sperre dieser Regel fest, von einer Minute bis zu einem Jahr
Simulation	reportedip-agent rules simulate <id>	Die Regel erkennt und meldet weiter, aus der Sperre wird eine Warnung simulated ban im Journal
Ignorier-Muster	/etc/reportedip-agent/ignore.d/<source>.conf	Verwirft passende Log-Zeilen, bevor ein Detektor sie sieht
Export der Sperren	ban list --json oder --plain	Übergibt die Sperren an nginx, HAProxy oder ein Skript

Ignorier-Muster sind für Health-Checks, Monitoring-Abfragen und ACME-Pfade gedacht. Ein Muster, das eine Zeile verschlucken würde, auf deren Erkennung die mitgelieferten Regeln getestet sind, wird abgewiesen, ebenso ein Muster, das auf den leeren String passt. Seit 0.3.45 laufen Ihre eigenen Regeln vor signierten Paketen und mitgelieferten Regeln, eine eigene Regel kann also nicht mehr von einer mitgelieferten verdeckt werden. Ein Policy-Override wie report: false stellt eine Regel nicht mehr einen Tag unter Beobachtung (0.3.43).

Das Format der Regeldateien und die Regel-Befehle beschreibt die Seite zur Erkennung; Sperrdauer, Simulation und Export stehen unter Blockieren.

Was tut der Agent gegen Bot-Fluten?

Seit 0.3.44 zählt der Daemon jede Zeile jedes Logs, das er liest, und führt für jedes Web-Log eine Grundlinie der Zeilen pro Stunde. Liegt die laufende Stunde weit über dieser Grundlinie, geht der Health-Zustand volume auf Warnung, einer von 13 Health-Zuständen. Der Alarm nennt die lauteste Website und sperrt und meldet nichts; eine Flut von Crawlern ist eine Frage der Kapazität, keine Community-Information. Er braucht 24 volle Stunden Grundlinie, bevor er auslösen kann, und volume_factor: 0 in config.yaml schaltet ihn ab.

Mit derselben Version kommt die Regel web-query-crawl im Simulationsmodus. Sie sucht Clients, die viele Seiten mit Query-String ohne eigenen Referer abrufen. Seit 0.3.46 zählt sie nur Clients, die sich als Browser ausgeben, ein Crawler, der sich mit Namen meldet, wird von ihr also nie gesperrt. Vor der Auslieferung wurde sie zwei Tage lang auf fünf Servern gemessen: kein Besucher und kein Monitoring kam darüber, nur Crawler und Bots. Der Leitfaden Bot-Fluten erkennen und abwehren zeigt, wann Sie sie scharf schalten.

Welche Fehlsperren hat der Agent abgestellt?

• FTP-Kunden im passiven Modus (0.3.39). Jede passive Datenverbindung sah aus wie die Abfrage eines geschlossenen Ports, und ein Kunde auf einem verwalteten Server wurde an einem Tag dreimal gesperrt. Die Portscan-Regel fragt jetzt den Kernel, ob in diesem Moment ein Socket lauscht, und der Passivbereich von pure-ftpd, proftpd und vsftpd wird aus deren Konfiguration gelesen.
• Besucher einer fehlerhaften Seite (0.3.42). Eine abgewiesene Schrift, ein Bild, ein Stylesheet oder Skript und alles unter /.well-known/ zählt nicht mehr als blockierte Anfrage. Abfragen nach /.env oder /.git/ zählen weiter.
• Angemeldete WordPress-Admins (0.3.47). admin-ajax.php antwortet auf jede Aktion ohne Handler mit 400, und ein aktives Dashboard erzeugt das viele Male pro Stunde. Diese Antwort zählt nicht mehr; jeder andere Pfad unter /wp-admin/ schon.
• Filternde Mail-Relays (0.3.48). Ein abgewiesener Umschlag-Absender wurde dem verbindenden Server angerechnet, und hinter einem filternden Relay ist das immer das Relay. Eine einzige Sperre stoppte den Mail-Eingang für zwölf Stunden. Über 20 Tage eines Mailservers der Flotte ändert sich damit nur das Urteil über das Relay.
• Adressen auf der Whitelist in test (0.3.33). Die Spalte mit dem Urteil sagt jetzt nein für eine Adresse, die die Whitelist schützt.

Was ist neu bei Installation und Diagnose?

• Web-Logs aus der Konfiguration des Webservers (0.3.34). install liest die vhost-Dateien unter conf.d und sites-enabled, damit werden die Access-Logs einzelner Websites eines Hosting-Setups gefunden und nicht nur die Standardpfade.
• Log-Level (0.3.29, 0.3.38). log_level nimmt debug, info, warn oder error; eine neue Installation schreibt warn. install --log-level und REPORTEDIP_LOG_LEVEL setzen den Wert bei einem Rollout.
• fail2ban ablösen (0.3.30). REPORTEDIP_FAIL2BAN_SOURCE=0 lässt fail2ban als Quelle weg, wenn es auf dem Server ohnehin entfernt werden soll.
• Unbeobachtete Dienste (0.3.35 bis 0.3.37). doctor nennt einen Dienst, der auf einem Port lauscht oder ein Log schreibt, das keine Quelle beobachtet, beurteilt dabei das Log statt des Dienstnamens und ignoriert Sockets, die nur an Loopback gebunden sind.
• Admin-Bereiche (0.3.41). install --admin-ip übernimmt einen ganzen CIDR-Bereich in die automatische Whitelist statt nur seiner ersten Adresse.

Jedes Update, das der Agent selbst installiert, wird gegen eine Ed25519-Signatur (RFC 8032) über die veröffentlichten Prüfsummen geprüft und einmal gestartet, bevor es die laufende Binärdatei ersetzt. Die Variablen von install.sh stehen auf der Installationsseite, der Umstieg auf der Seite fail2ban ablösen.

Fragen zu Linux Agent 0.3.48

Muss ich nach dem Update meine config.yaml ändern?

Eine bestehende config.yaml funktioniert ohne Änderung weiter, und ein Server behält das Log-Level aus seiner Datei. Zwei Dinge ändern sich von selbst: Der Volumen-Alarm ist ab Werk aktiv und meldet eine Warnung, bei gesetztem notify.email auch eine Mail, wenn ein Web-Log überläuft; volume_factor: 0 schaltet ihn ab. Und seit 0.3.43 stellt ein Override, der nur die Aktion einer Regel ändert, etwa report: false, die Regel nicht mehr einen Tag unter Beobachtung. Ein Schritt ist nötig: Ein Server, der vor 0.3.41 mit einem CIDR-Bereich für --admin-ip installiert wurde, hat nur dessen erste Adresse und sollte den Bereich mit whitelist add ergänzen.

Sperrt der Volumen-Alarm etwas?

Der Volumen-Alarm sperrt nie und meldet nie. Er setzt den Health-Zustand volume auf Warnung, nennt die lauteste Website und verweist für die vollständige Liste auf reportedip-agent status. Nach einer vollen ruhigen Stunde erlischt er. Das Sperren einer Flut bleibt Sache der Erkennungsregeln, zum Beispiel von web-query-crawl, sobald Sie sie scharf schalten.

Welchen Tarif brauche ich für den Linux Agent?

Der Agent läuft in jedem Tarif, auch in Free: Lokale Erkennung, lokale Sperren und Meldungen funktionieren immer. Der Community-Feed braucht eine Serverlizenz: Professional enthält einen Server, Business drei, Enterprise nach Vertrag, und ab Professional lassen sich weitere Server pro Host dazubuchen. Einzelheiten stehen auf der Seite zu den Lizenzen.

Weiterlesen

• Linux Agent installieren
• Alle Schlüssel der config.yaml
• Beispiel-Setups
• Gruppen und Webhooks

Sie betreiben WordPress neben Ihren Servern? Das Release Hive 2.1.72 behandelt die WordPress-Seite derselben Gruppen. Wie Testlizenzen funktionieren, erklärt der Beitrag kostenlose Testlizenzen für den Linux Agent.