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 ein Ignore-Muster verworfen hat, 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.

Bot-Fluten: was der Agent tut und was nicht

Eine Seite, die mit 200 beantwortet wird, ist nie ein Angriff. Eine Flut von Tausenden Adressen, die je ein- oder zweimal eine gewöhnliche Seite abrufen, ist Last, und eine Regel, die je Adresse zählt, sieht von jeder eine Anfrage und nichts, worauf sie reagieren könnte. Der Agent sperrt einen solchen Schwarm nicht und soll es auch nicht, denn dieselben Zeilen kommen von echten Besuchern. Er tut stattdessen zweierlei: Er sagt Ihnen, dass eine Website geflutet wird, und er zählt das eine Muster in der Flut, das Besucher nicht erzeugen. Der Rest gehört in den Webserver. Der Fachartikel zu Bot-Fluten geht einen Praxisfall mit gemessenen Zahlen durch.

Der Volumen-Alarm

Der Daemon zählt jede Zeile jedes Logs, das er liest, und führt für jedes eine Baseline der Zeilen je Stunde: in der ersten Woche einen laufenden Mittelwert über die vollen Stunden, danach ein Mittel mit einer Woche Gedächtnis. Liest die laufende Stunde eines Web-Logs, also einer der Quellen web und web-error, mindestens das Achtfache seiner Baseline und mindestens 20.000 Zeilen, öffnet sich der Zustand volume als Warnung. Sein Text nennt die lauteste Website, den Namen des Verzeichnisses, in dem das Log liegt, meist den virtuellen Host, und reportedip-agent status zeigt jedes laute Log. Der Zustand schließt sich nach einer vollen ruhigen Stunde.

Seit 0.3.52 sagt der Alarm auch, wer die Flut verursacht. Solange ein Log laut ist, zählt der Daemon dessen Clients, bis zu 20.000 Adressen, und ergänzt den Text um eine Einschätzung: ein Client hat die meisten Zeilen erzeugt, und ob eine Regel ihn zählt; wenige Clients haben die meisten erzeugt; oder die Zeilen verteilen sich auf viele Clients, dann passt eine Regel besser als Sperren. Die Mail enthält nur diese Einschätzung, nie eine Adresse. reportedip-agent status nennt unter dem Log die fünf lautesten Clients mit ihrem Anteil und ruled=, der Zahl ihrer Zeilen, die eine Regel gezählt hat. ruled=0 heißt, dass keine Regel sie zählt, und reportedip-agent ban add <address> sperrt einen davon. Die Liste bleibt nach der Flut stehen, bis die nächste beginnt. Die Entwarnungsmail wiederholt den letzten Stand des Alarms mit Beginn, Ende und Dauer.

Vor 24 vollen Stunden Baseline alarmiert nichts, eine frische Installation bleibt am ersten Tag also still. Der Alarm sperrt nichts und meldet nichts: Er macht die Flut sichtbar, und was dagegen zu tun ist, entscheiden Sie. Eine Flut, die über mehr als eine Woche langsam wächst, hebt die Baseline mit, der Faktor fängt also Sprünge und keine Rampen. Zwei Schlüssel in config.yaml setzen die Grenzen; unter Monitoring steht, wo laufende Stunde und Baseline in status erscheinen.

volume_factor: 8          # times the usual hour; 0 switches the alarm off, otherwise 2 to 1000
volume_min_lines: 20000   # lines in the running hour, at least; 0 to 100000000

Die Regel web-query-crawl

Das Muster, das Besucher nicht erzeugen: GET-Anfragen mit Query-String, beantwortet mit 200, ohne eigenen Referer (leer oder eine Suchmaschine wie Google oder Bing), 20 davon in 60 Minuten von einer Adresse. So sieht ein Client aus, der Kalenderfilter, Anhang-IDs oder facettierte Listen abgrast. Die Regel 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, GPTBot, Ahrefs, Semrush und andere). Sie zählt nur Clients, deren User-Agent mit Mozilla/ beginnt, was jeder Browser und jeder getarnte Crawler schickt, ein Werkzeug oder Crawler mit eigenem Namen wird also nie gezählt; die Namensliste deckt die Crawler ab, die ebenfalls mit Mozilla/ beginnen, etwa Googlebot.

Seit 0.3.50 lässt sie außerdem weg, was eine Messung über eine Woche und 36 Server unter ihren Treffern fand, jeweils nach Form und nicht nach Namen: einen User-Agent, der sich als (compatible; Name) nennt, einen Zusatz in der Browser-Klammer trägt (like Gecko; Name) oder eine Kontaktadresse; Links aus einer Mail wie Newsletter-Ansichten und Öffnungs- oder Klick-Tracking (noti, fluentcrm, mailpoet_*, mc_cid); Cache-Buster, also eine Zahl unter einem kurzen Schlüssel wie cb, nc, nocache oder *_check; einen Schalter ohne Wert als ersten Parameter wie ?start_customizing; und wp-cron hinter einem doppelten Schrägstrich.

Ein Crawler, der sagt, wer er ist, wird von dieser Regel nicht gesperrt. Er kann ein SEO-Dienst sein, den der Betreiber der Website gebucht hat, und bremsen lässt er sich im Webserver oder über robots.txt. Deshalb gibt es auch keine Allowlist von User-Agents, die Sie pflegen müssten: Die Regel zählt nur Clients, die sich als Browser ausgeben. Ein gefälschter Crawler-Name entkommt ihr mit Absicht; die Scanner- und Login-Regeln zählen einen solchen Client weiter. Die Regel meldet nichts, denn ein Crawl ist ein Ärgernis und keine Community-Daten.

Sie wird simuliert ausgeliefert: Sie schreibt eine Warnung simulated ban ins Log und sperrt nichts. Schalten Sie sie ab oder stellen Sie sie mit einer Überschreibungsdatei scharf. simulate betrifft nur das Verhalten, das Scharfstellen startet also keinen Beobachtungstag; der Daemon übernimmt die Datei innerhalb einer Minute.

# What the rule would have banned so far
journalctl -u reportedip-agent | grep "simulated ban"

# Switch it off
reportedip-agent rules disable web-query-crawl

# Arm it: real bans instead of simulated ones
cat > /etc/reportedip-agent/rules.d/50-web-query-crawl.yaml <<EOF
format: 1
rules:
  - id: web-query-crawl
    action: {simulate: false}
EOF
reportedip-agent rules check

Im Webserver

Alles, was Last begrenzt, egal wer sie schickt, gehört in den Webserver. Vier Maßnahmen, gezeigt für nginx; Pfad, Domain und Zahlen passen Sie an Ihre Website an.

• Eine limit_req-Zone mit festem Schlüssel für den Filterpfad. Eine Zone je Adresse bewirkt nichts gegen Tausende Adressen mit je einer Anfrage. Eine Zone mit dem Schlüssel $server_name begrenzt, wie viele Anfragen je Sekunde auf diesem Pfad PHP erreichen, egal wie viele Adressen sie schicken.
• Ein FastCGI-Cache mit dem Query-String im Schlüssel. Mit $request_uri in fastcgi_cache_key wird ein wiederholter Filteraufruf ohne PHP beantwortet. Weniger Filterkombinationen helfen ihm: rel="nofollow" an Filterlinks und der Filterpfad in robots.txt.
• Eine 429 für Anfragen ohne den eigenen Referer der Website, als Notbremse. Sie hält, bis der Bot den Referer fälscht.
• Eine Präfixsperre gemieteter Netze, nach einer whois-Prüfung. Ein Block eines Hosting-Anbieters darf als Ganzes weg. Bei einem Endkundenprovider geht das nicht, denn ein Präfix trägt dort viele Kunden hinter Carrier-NAT.

# http {}
limit_req_zone $server_name zone=filter_all:1m rate=10r/s;

map $http_referer $own_referer {
    default 0;
    "~^https://(www\.)?example\.org/" 1;
}

# server {}
location ^~ /events/ {
    limit_req zone=filter_all burst=20;
    limit_req_status 429;
    if ($own_referer = 0) { return 429; }   # emergency brake, only while it holds
    try_files $uri $uri/ /index.php?$args;
}

# server {}, only after whois names a hosting provider
deny 198.51.100.0/24;

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: 12. November 2026 · Betreut vom ReportedIP-Team