Stop Bots

Eine TUI, eine Web-Konsole und eine CLI, die dir helfen, deinen Server so zu konfigurieren, dass böse Bots gestoppt werden, ohne sich hinter einem CDN zu verstecken.

Es arbeitet zusammen mit NGINX und deiner bestehenden Firewall (nftables oder iptables):

• NGINX-Konfiguration. - Es klassifiziert bekannte Bots nach Kategorie (Scanner, Suchmaschinen, KI-Crawler) und blockiert oder erlaubt sie, indem eine Regel in deine Site-Konfigurationen eingefügt wird. Es scannt das NGINX-Log, um Bots dynamisch zu erkennen und sie zu blockieren, selbst wenn noch kein Regelsatz sie erfasst.
• Ein Firewall-Skript. - Blockiere ganze Länder, IP-Bereiche von Rechenzentren, bekannte Bot-IP-Bereiche oder jede IP-Adresse, die wiederholt erfolglos versucht, sich an deinem Server anzumelden. Jede Blockierung zeichnet auf, warum sie existiert.

Die App versucht ihr Bestes, um dich nicht vom Server auszusperren, aber du verwendest sie auf eigenes Risiko. Und beachte, dass sie unter AGPL lizenziert ist. Wenn du sie kommerziell nutzt, stelle sicher, dass du die Lizenz einhältst.

Schnellstart

Installation

Auf Debian oder Ubuntu aus dem APT-Repository:

curl -fsSL https://ivankovic.github.io/stop-bots/key.gpg \
  | sudo tee /usr/share/keyrings/stop-bots.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/stop-bots.gpg] \
https://ivankovic.github.io/stop-bots stable main" \
  | sudo tee /etc/apt/sources.list.d/stop-bots.list
sudo apt update && sudo apt install stop-bots

Das Paket bringt man stop-bots (und eine Seite pro Verb, wie man stop-bots-batch) sowie bash-, zsh- und fish-Vervollständigungen mit. Es installiert keinen Dienst und startet nichts.

Oder von crates.io, mit Rust 1.88 oder neuer:

cargo install stop-bots

Oder lade ein statisches Binary für x86_64 oder aarch64 Linux von den GitHub releases herunter.

Unterstützte Plattformen

• Debian und Ubuntu, mit systemd und NGINX. Das ist es, was getestet wird. install lehnt einen Host ab, der nicht Debian oder ein Derivat ist.
• Nicht Apache oder Caddy. Deren Access-Logs lassen sich möglicherweise parsen, aber alles, was Webserver- Konfiguration schreibt, ist nur für NGINX.
• Laufzeitabhängigkeiten: nft, oder iptables-restore und ip6tables-restore, für die Firewall; nginx für den Rest. NGINX in einem Container funktioniert ebenfalls — siehe Running NGINX in a container.

In der TUI

1. sudo stop-bots startet die TUI. Sie benötigt root: Sie schreibt /etc/nginx um und lädt Firewall- Regeln.
2. u lädt jede Liste herunter: Bot-Listen, Crawler-IP-Bereiche und jeden Feed oder jedes Land, das du aktiviert hast.
3. Überprüfen. Das Dashboard (1) enthält die hostweite Richtlinie: welche Bot-Kategorien blockiert werden, Länder und die Detektoren, die deine Logs lesen. Auf dem NGINX-Bildschirm (4) findet r deine Sites. Der Blocks-Bildschirm (5) listet jede Regel auf, die die Detektoren oder du hinzugefügt haben, und warum.
4. a wendet alles an. Es zeigt zuerst, was sich ändern würde — die Dateien, die hinzugefügten und entfernten Regeln und das Urteil der Lockout-Prüfung (d für den Diff) — und fragt nach.
5. sudo stop-bots install firewall sorgt dafür, dass die angewendeten Regeln einen Neustart überstehen. Ohne dies kommt ein Neustart ganz ohne Regeln zurück.
6. sudo stop-bots status prüft den Kernel, die Units und die Dateien und sagt, was fehlt.

Dasselbe von der CLI, für Skripte

sudo stop-bots status
sudo stop-bots batch --dry-run --diff
sudo stop-bots batch --apply
sudo stop-bots install firewall
sudo stop-bots status

batch --dry-run lädt und scannt nichts: Bei einer brandneuen Installation zeigt es die NGINX- Blöcke aus der in die Binärdatei eingebauten Bot-Liste und noch keine Firewall-Regeln, da nichts aus Ihren Logs gelesen wurde. sudo stop-bots batch ohne --apply führt die Downloads und Scans durch und schreibt die Dateien zur Überprüfung, ohne sie durchzusetzen. Siehe Unbeaufsichtigt, aus cron für das, was batch tut.

Rückgängig machen

sudo stop-bots uninstall all --dry-run
sudo stop-bots uninstall all

Die erste listet jeden Schritt auf, die zweite führt sie aus. Siehe Aktualisieren und Deinstallieren.

Wogegen es schützt

Verwendung der NGINX-Konfiguration

• Bekannte Bots, nach Kategorie (Scanner / Suchmaschine / KI-Crawler), bezogen aus ArcJet's Well-Known Bots, ai.robots.txt und der NGINX Ultimate Bad Bot Blocker Liste. Das Blockieren einer Kategorie fügt eine if ($http_user_agent ...)-Regel in die NGINX- Konfiguration jeder Website ein.

• Zu viele Anfragen, über NGINX' eigene Ratenbegrenzung.

• Zuerst höflich — eine generierte robots.txt, die jeden Bot auflistet, den Sie blockieren, für die Crawler, die sie respektieren, plus den Honeypot-Pfad unten.

• Außer wo Sie etwas anderes sagen — pfadbezogene Ausnahmen pro Website sowie vertrauenswürdige Adressen und User Agents (trust), für die keine Sperre, Liste oder Ratenbegrenzung gilt.

• Anfragen, die nicht wie ein Browser aussehen, pro Website. Sechs unabhängige Regeln, jede mit eigenem Schalter und standardmäßig deaktiviert — ein Schalter pro Regel, damit Sie, wenn etwas von Ihnen nicht mehr funktioniert, erkennen können, welche Regel dafür verantwortlich ist:

  Regel	Weist ab, außer Bots
  HTTP/1.0 und HTTP/1.1	Crawler und API-Clients, die kein HTTP/2 sprechen
  Kein Accept-Header	einige API-Clients senden keinen
  Kein Accept-Language	Datenschutz-Tools entfernen ihn
  Leerer/fehlender User-Agent	Skripte und Health-Checks lassen ihn oft weg
  Host ist eine bloße IP	verhindert das Erreichen der Website per IP
  TLS 1.0 / 1.1	nur sehr alte Clients

Was eine blockierte Anfrage tatsächlich erhält

Es gibt sieben Möglichkeiten:

Option	Wofür sie gedacht ist
403 Forbidden (Standard)	sagt, dass die Sperre absichtlich erfolgte; die einzige, auf die ein fälschlich erfasster Mensch reagieren kann
404 Not Found	verbirgt, dass überhaupt etwas blockiert wurde
410 Gone	bittet wohlerzogene Crawler, die URL endgültig zu verwerfen — bevorzugen Sie dies gegenüber 403, wenn Sie Crawler statt Angreifer abweisen
429 Too Many Requests	teilt einem höflichen Client mit, sich zurückzuziehen und es erneut zu versuchen
418 I'm a teapot	der Scherz aus RFC 2324. Er funktioniert; er ist nur nicht bei der IANA registriert, und NGINX sendet ihn mit leerem Body
444 close connection	überhaupt keine Antwort; am günstigsten, aber nicht von einem ausgefallenen Server zu unterscheiden
Tarpit	antwortet mit 403, tröpfelt den Body aber mit einem Byte pro Sekunde, sodass der Client wartet, statt weiterzuziehen