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 den Wortlaut der Lizenz einhältst.

Installation

Von crates.io:``` cargo install stop-bots

Ein vorgefertigtes x86_64-Linux-Binary ist auf den GitHub-Releases verfügbar.

Abhängigkeiten

Erfordert Rust 1.88 oder neuer zum Bauen. In der Praxis nur unter Linux: Es ruft systemctl, nginx -t und nft/iptables auf, sodass es zwar anderswo kompiliert, dort aber kaum nützlich sein wird.

Verwendung

Führe das Binary ohne Argumente aus, um die TUI zu starten, stop-bots web für dieselben Ansichten in einem Browser (siehe Die Web-UI), oder siehe stop-bots --help für die vollständige Liste der CLI-Unterbefehle. TUI und CLI können zusammen verwendet werden. Konfiguriere alles in der TUI und verwende dann die CLI in einem Crontab, um die Regeln aktuell zu halten.

Du kannst die App mit 'q' oder Escape beenden oder aus einem Popup/Untermenü zurückgehen.

Theme

Du kannst mit 't' zwischen dem dunklen und dem hellen Theme wechseln. Die App versucht, das Theme automatisch zu erkennen, aber für einige Terminal- und Multiplexer-Kombinationen sind nicht genügend Informationen verfügbar, um die richtige Wahl zu treffen.

Bildschirme

1–4 (oder d/b/s/p) springen direkt zu einem Bildschirm; Links/Rechts oder ihre vim-Aliase h/l schalten durch sie; ? schaltet jederzeit eine vollständige Tastenbelegungsreferenz um, und : öffnet eine Befehlspalette, die jede Aktion namentlich auflistet. Tab / Shift+Tab wechseln immer zwischen den Panels des aktuellen Bildschirms, niemals zwischen Bildschirmen.

Das Dashboard besitzt alles, was im Firewall-Skript landet; die Site-Einstellungen besitzen alles, was in der NGINX-Konfiguration landet. Diese Aufteilung entscheidet, wo eine bestimmte Einstellung lebt.

• Dashboard (der Standardbildschirm): systemweite Kategorie-Standardwerte (Scanner / Such-Bots / KI-Bots — erlaubt oder blockiert); hostweites Geo-Blocking (Blockieren oder Allow-List bestimmter Länder); ein Panel „Automatisches Blockieren“ mit einem Ein-/Aus-Schalter für jeden Detektor und jede Drittanbieter-Blockliste; ein Panel „Firewall-Skript“ (wie viele Regeln ein Rendern schreiben würde, ob das Skript auf der Festplatte veraltet ist und aus welchen Sites und Bot-Listen es gerendert wird); ein Panel „Geplant“, das die Jobs des internen Cron und deren letzten Ausführungszeitpunkt anzeigt (mit einem Spinner neben jedem Job, der gerade im Hintergrund läuft); und ein Log dessen, was die App zuletzt getan hat. Ein Statusstreifen unter den Tabs zeigt die Gesundheitsprüfungen des Hosts auf jedem Bildschirm. Up/Down wechseln zwischen den drei Listen; m schaltet den Geo-Modus um. Drücke F, um die aktuellen Firewall-Regeln in ein Skript zu rendern — das Popup hat außerdem einen Schalter „nach dem Schreiben anwenden“ (Leertaste), um es tatsächlich sofort durchzusetzen, statt es danach von Hand anzuwenden. Drei weitere Tasten wirken auf den gesamten Host: u lädt jede Liste herunter, a wendet beide Ebenen an (NGINX, dann die Firewall), und w stellt diese Konsole hinter NGINX — dieselben drei, die der Browser als Buttons und ein Panel hat.
• Bot-Einstellungen: listet jede bekannte Bot-Listen-Quelle auf (mit einer Aktion zum Aktualisieren) und jeden einzelnen Bot, durchsuchbar nach Namen, mit einer Überschreibung pro Bot (Erlaubt / Blockiert / dem Kategorie-Standardwert folgen).
• Site-Einstellungen: ein Panel „NGINX-Einstellungen“ (Tab zum Fokussieren), das die hostweiten Auswahlmöglichkeiten enthält, die die generierte Konfiguration prägen — was eine blockierte Anfrage zurückbekommt (siehe unten), ob eine generierte robots.txt ausgeliefert werden soll und Rate Limiting — über jeder auf der Festplatte entdeckten NGINX-Site, jede mit einem Live-Status „aktuell / veraltet / nicht gefunden“ und Aktionen, um die aktuelle Richtlinie auf eine Site oder alle anzuwenden. Das Ändern einer dieser Einstellungen setzt jede angewendete Site auf STALE, was dein Signal zum erneuten Anwenden ist. Das Öffnen einer Site lässt dich ihre Kategorie-/Bot-Richtlinie überschreiben, eine der sechs Request-Shape-Regeln einschalten und Pfade auflisten, die vom Blockieren ausgenommen sind.
• Dynamischer Schutz: eine Live-, handlungsfähige Ansicht dessen, was gerade auf den Server trifft — „Top IPs, die eine SSH-Verbindung versuchen“ und „Top User Agents“, jeweils nach Anzahl sortiert und markiert NOT BLOCKED/BLOCKED (rot dargestellt). Tab/Shift+Tab wechseln, auf welches der beiden Panels Up/Down wirken; f durchläuft einen gemeinsamen Filter (alle / nur nicht blockierte / nur blockierte); Enter blockiert die ausgewählte NOT BLOCKED-Zeile oder hebt die Blockierung auf, wenn sie bereits BLOCKED ist. i untersucht die ausgewählte Adresse: welche der Reputations-Feeds sie auflisten, ob sie innerhalb eines veröffentlichten Crawler-Bereichs liegt (was einen echten Googlebot von einem User Agent unterscheidet, der es nur behauptet), zu welchem Land sie gehört und als welche Konten sie sich anzumelden versuchte. Alles aus Listen, die dieser Host bereits heruntergeladen hat — es gibt hier kein Reverse- DNS oder Whois-Lookup, weil ein PTR-Eintrag von demjenigen geschrieben wird, dem die Adresse gehört, und angreifergelieferter Text wäre, der als autoritativ gelesen wird.
• Hilfe: die vollständige Tastenbelegungsreferenz.

Bot-Einstellungen, wo jede Listen-Quelle und jeder einzelne Bot lebt:

Site-Einstellungen, wo die hostweiten NGINX-Auswahlmöglichkeiten über jeder auf der Festplatte gefundenen Site stehen:

Dynamischer Schutz, die Live-Ansicht dessen, was gerade jetzt auf den Server trifft:

Wogegen es tatsächlich 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 Site ein (apply-blocks / a/A in den Site-Einstellungen).

• Zu viele Anfragen, über NGINXs eigenes Rate Limiting. Anders als alles andere hier wird dies von NGINX zur Anfragezeit durchgesetzt, statt einen Log danach zu analysieren. Standardmäßig aus: ein für die falsche Site abgestimmtes Limit weist echte Besucher ab.

• Zuerst höflich — eine optionale generierte robots.txt, die jeden Bot auflistet, den du blockierst, für die Crawler, die sie respektieren, plus den Honeypot-Pfad unten. Standardmäßig aus, weil sie ersetzt, was deine Site heute unter /robots.txt ausliefert.

• Außer wo du etwas anderes sagst — Pfad-Ausnahmen pro Site, sodass du KI-Crawler überall außer /blog blockieren kannst.

• Anfragen, die nicht wie ein Browser aussehen, pro Site. Sechs unabhängige Regeln, jede mit eigenem Schalter und jede standardmäßig aus — ein Schalter pro Regel, damit du, wenn etwas von dir aufhört zu funktionieren, erkennen kannst, welche Regel es verursacht hat:

  Zwei Schutzmaßnahmen gelten für alle und werden durchgesetzt, statt dir überlassen zu werden:

  • Die beiden TLS-abhängigen Regeln werden nur in HTTPS-server-Blöcke geschrieben. Browser machen kein HTTP/2 ohne TLS, also ist auf einem einfachen listen 80-Block jede Anfrage HTTP/1.1 — einschließlich der Weiterleitung, die ein Browser auf dem Weg zu HTTPS macht. Deine Port-80- und Port-443- Blöcke teilen sich üblicherweise einen server_name, sodass die Einstellung beide erreicht; nur der TLS-Block bekommt diese Regeln. Die Header-Shape-Regeln funktionieren über einfaches HTTP und werden in beide geschrieben.
  • /.well-known/ ist immer ausgenommen, sobald eine Regel aktiv ist. Dort holt Let's Encrypt seine HTTP-01-Challenge, über HTTP/1.1 ohne Accept und oft ohne User-Agent — ohne die Ausnahme hört dein Zertifikat Wochen später auf, sich zu erneuern.

Was eine blockierte Anfrage tatsächlich bekommt

Eine hostweite Auswahl, in den Site-Einstellungen. Diese Statuscodes sind nicht austauschbar — jeder sagt etwas anderes, und der Unterschied zählt am meisten für die Clients, die du nicht treffen wolltest:

Der Tarpit ist die sanfteste Option bei einem Fehlalarm — ein fälschlich getroffener Client wird verlangsamt, nicht abgewiesen — und die härteste bei den Kosten für einen Bot, dessen Verbindung untätig bleibt. Zwei Dinge, die du vor der Wahl wissen solltest: Er hält auch für die Dauer eine deiner Worker-Verbindungen, sodass eine Flut getarpiteter Clients mit echten Besuchern um worker_connections konkurriert; und wie lange er tatsächlich dauert, hängt davon ab, wie NGINX einen kleinen Fehler-Body zu schreiben wählt, was in TODO.md als gegen einen echten Server zu prüfen vermerkt ist.

Aus deinen Logs, automatisch

Jede davon ist ein unabhängiger Schalter im Panel „Automatisches Blockieren“ des Dashboards, und jede fügt eine temporäre Firewall-Blockierung hinzu, die von selbst abläuft und erneut hinzugefügt wird, wenn das Verhalten anhält.

Sie laufen auf einem internen Timer, der deine SSH- und NGINX-Zugriffslogs jede Minute neu liest — aber nur, solange die TUI oder die Web-UI läuft. Beide halten denselben Zeitplan, in derselben Datenbank, sodass es reicht, die Web-UI laufen zu lassen; nichts wird erkannt, wenn keine von beiden läuft. Für einen Server ganz ohne stop-bots-Prozess siehe Unbeaufsichtigt, per Cron unten.

• SSH- und Web-Scanner: IPs mit einer Menge fehlgeschlagener SSH-Logins oder vielen verschiedenen 404-Pfaden. Niemals eine IP mit einem kürzlichen erfolgreichen SSH-Login oder eine innerhalb des veröffentlichten IP-Bereichs eines bekannten Crawlers.
• Gefälschte Crawler: alles, was sich als Googlebot, Bingbot oder GPTBot aus einer Adresse ausgibt, die der Betreiber dieses Crawlers selbst nicht veröffentlicht. Die billigste gängige Tarnung überhaupt, und die veröffentlichten CIDR-Listen entscheiden es. Inert, bis diese Listen tatsächlich abgerufen wurden.
• Sondieren nach exponierten Geheimnissen: eine einzelne Anfrage nach /.env, /.git/config, /wp-config.php und Ähnlichem ist für sich genommen schlüssig, also braucht dies keine Schwelle. Die eingebaute Liste lässt bewusst Pfade weg, die irgendwo legitim sind — /wp-login.php, /wp-admin/, /xmlrpc.php, /phpmyadmin — da das Aussperren deines eigenen Administrators schlimmer wäre als einen Scanner zu verpassen, den der 404-Detektor ohnehin fängt. Füge eigene mit set-probe-paths hinzu.
• Honeypot: ein Pfad, der nur als Disallow: in der generierten robots.txt veröffentlicht und nirgends verlinkt ist. Ihn zu erreichen bedeutet, robots.txt zu ignorieren, was nichts Legitimes versehentlich tut — das stärkste Signal hier und die längste Blockierung. Erfordert, dass die robots.txt-Generierung eingeschaltet ist, um überhaupt zu funktionieren.

Drei weitere betrachten, wie ein Client sich verhält, statt wonach er fragt. Alle drei sind standardmäßig aus, weil jeder einen Fehlalarm hat, den er nicht allein ausschließen kann — und alle drei nehmen verifizierte Suchmaschinen-Crawler aus, die sonst auf jeden von ihnen passen würden:

• Lädt keine Assets: viele verschiedene Seiten und kein einziges Stylesheet, Skript oder Bild. Browser laden, was zu einer Seite gehört. Fängt keinen API-Client (er zählt verschiedene Pfade, und ein API-Client trifft wenige) oder einen gut gecachten wiederkehrenden Besucher (ein 304 zählt als geladenes Asset). Kann dir auf einer Site nicht helfen, die überhaupt keine Assets ausliefert — eine reine JSON-API.
• Rotierender User Agent: mehrere Identitäten aus einer Adresse. Erheblich abgeschwächt durch NAT: ein Carrier-, Campus- oder Büro-Gateway präsentiert viele echte Browser auf einer IP, und ohne Zeitstempel-Analyse gibt es keine Möglichkeit, das von einem Scraper zu unterscheiden, der Agents durchwechselt.
• Crawlt ohne Referer: viele verschiedene tiefe Seiten, niemals ein Referer. Abgeschwächt durch Referrer-Policy: no-referrer und Datenschutz-Tools; die Schwelle für verschiedene Pfade ist das, was es überhaupt brauchbar macht.

Nach Adresse

• Ganze Länder, über IPdenys aggregierte CIDR-Listen — blockiere bestimmte Länder oder wechsle in den Allow-List-Modus und blockiere alles andere.
• Bekannt bösartige Adressen, über Drittanbieter-Listen: FireHOL Level 1, Tor-Exit-Nodes und blocklist.de. Alle standardmäßig aus.
• Ganze Hosting-Anbieter: AWS, Google Cloud und DigitalOcean veröffentlichen ihren Adressraum, und private Besucher browsen nicht von dort. Diese sind grobe Instrumente und als solche gekennzeichnet — sie blockieren jeden dort gehosteten Besucher, einschließlich VPN-Endpunkten, Unternehmens-Egress und API-Clients, nicht nur Bots. Standardmäßig aus, mit einer Warnung, wenn du einen einschaltest.
• Benachbarte Adressen, optional: wenn mehrere Adressen in einem IPv4-/24 im selben Durchlauf markiert werden, blockiere das /24. Standardmäßig aus — 256 Adressen zu blockieren, weil drei sich schlecht benommen haben, ist Kollateralschaden by design. (IPv6 ist anders und braucht keinen Schalter: Eine Erkennung blockiert immer das /64, weil ein /64 ein LAN ist, dasselbe, was eine einzelne IPv4-Adresse repräsentiert. Die einzelne Adresse zu blockieren, die ein IPv6-Angreifer zufällig benutzt hat, würde nichts stoppen — er hat 2^64 weitere.)
• Alles andere, von Hand — füge direkt eine IP/CIDR-Allow- oder -Block-Regel hinzu oder nutze den Dynamic- Protection-Bildschirm, um eine bestimmte IP oder einen User Agent dauerhaft zu blockieren, die du entdeckt hast, bevor sie jemals eine automatische Schwelle überschreitet.

Funktioniert es tatsächlich?

Alles oben ist generiert. Ob irgendetwas davon in Kraft ist, ist eine separate Frage, und stop-bots status ist diejenige, die sie beantwortet:``` stop-bots status

Eine Prüfung, die nicht ausgeführt werden konnte — nft list benötigt Root-Rechte — meldet UNKNOWN, niemals OK. Eine Zustandsprüfung, die meldet, dass alles in Ordnung sei, weil sie nicht nachsehen konnte, ist schlimmer als keine, denn ihr wird geglaubt.

Derselbe Bericht befindet sich im Dashboard sowohl in der Konsole als auch in der TUI, stündlich vom internen Cron erstellt statt bei jedem Rendern: nft list auf einem großen Regelwerk sind Megabytes an Text.

Nichts geschieht ohne dich

Jede Firewall-Entscheidung oben wird generiert, niemals automatisch angewendet: render-firewall (oder die f-Taste des Dashboards) schreibt ein iptables- oder nftables-Skript, das du selbst prüfen und anwenden kannst, und weigert sich, eines zu schreiben, das eine aktuell verbundene SSH-Sitzung aussperren würde.

Drei Dinge können es für dich anwenden, und alle drei erfordern, dass du danach fragst: das Render-Popup der TUI („nach dem Schreiben anwenden") oder ihre a-Taste, das Firewall-Panel der Web-Konsole („nach dem Schreiben ausführen") oder ihre Schaltfläche „Alles anwenden", und batch --apply aus einem von dir geschriebenen Crontab — siehe Unbeaufsichtigt, aus cron. Nichts davon ist ein Nebeneffekt von irgendetwas Automatischem: Der interne Cron rendert das Skript und führt es niemals aus.

Dasselbe gilt auf der NGINX-Seite: Eine Einstellung zu ändern ändert nur, was geschrieben würde. Die Site-Einstellungen zeigen jede Site als STALE, bis du sie anwendest.

Einen Detektor abzuschalten entfernt niemals bereits hinzugefügte Sperren — diese laufen von selbst ab. „Erkennung stoppen" und „rückgängig machen, was erkannt wurde" sind bewusst getrennt; Letzteres ist der Bildschirm „Dynamic Protection" oder remove-firewall-rule.

Es gibt außerdem eine einfache Zugriffsprotokoll-Zählung, unabhängig vom Blockieren: record-access-stats / list-access-stats zählen, wie oft jeder User-Agent in erfolgreichen (fehlerfreien) Anfragen auftaucht, sodass du sehen kannst, wer tatsächlich zu Besuch ist, zusätzlich dazu, wer blockiert wird.

Unbeaufsichtigt, aus cron

stop-bots batch ist ein Durchlauf über alles, was die TUI von Hand tut: jede Liste aktualisieren, die Logs scannen, die NGINX-Blockierungsregeln und das Firewall-Skript schreiben.```

One full pass a night. Refreshes the lists, scans the logs, applies both.

0 4 * * * root /usr/local/bin/stop-bots batch --apply --ssh-log /var/log/auth.log

And detection every ten minutes, without re-downloading lists that change weekly.

*/10 * * * * root /usr/local/bin/stop-bots batch --apply --no-fetch --ssh-log /var/log/auth.log

Es bindet 127.0.0.1:8787 — nur von dieser Maschine aus erreichbar — und gibt beim ersten Start einmalig ein generiertes Passwort aus. Erreiche es von deinem Laptop aus über einen SSH-Tunnel:``` ssh -L 8787:127.0.0.1:8787 your-server

Schreibt /etc/systemd/system/stop-bots-web.service, erstellt /var/lib/stop-bots (0700 — es enthält den Passwort-Hash der Konsole) und /etc/stop-bots, generiert ein Passwort, falls noch keines existiert, und aktiviert und startet die Unit.

--dry-run gibt den gesamten Plan aus und ändert nichts. Dies ist der einzige Befehl im Projekt, der einen Daemon startet, also fange dort an. --prefix <dir> schreibt denselben Baum an einen Ort, den du ohne Root lesen kannst. Wenn die Unit bereits existiert und du sie bearbeitet hast, stoppt der Installer und teilt dies mit, anstatt deine Änderung zu überschreiben; --force, wenn du es ernst meinst.

Der Dienst läuft als root, weil die Konsole /etc/nginx umschreibt, das Firewall-Skript schreibt und nginx -t sowie systemctl reload nginx ausführt. Es gibt keine unprivilegierte Aufteilung, die den Funktionsumfang intakt lässt. Die Unit trägt die Härtung, die diese Anforderung übersteht, sowie einen Kommentar, der angibt, welche Härtung weggelassen wurde und warum.

Die Bind-Adresse, die Host-Allowlist und das Pfad-Präfix sind bewusst nicht in der Unit — der laufende Server liest sie erneut aus der Datenbank, sodass sie in ExecStart zwei Quellen der Wahrheit hätten. Ändere sie mit stop-bots web --save ... und starte neu.

Eine Sache ändert sich, sobald dies als root läuft: Der tägliche RenderFirewall-Job des internen Cron kann nun /etc/stop-bots/firewall.nft schreiben, was nicht möglich war, als du die Konsole manuell als du selbst ausgeführt hast. Nichts wendet dieses Skript an — es auszuführen bleibt weiterhin dir überlassen.

Es wird nur auf Debian geprüft, weil das getestet wurde; die Unit ist sehr wahrscheinlich auf jeder systemd-Distribution korrekt, aber der angenommene SSH-Log-Pfad ist der von Debian.

Exponieren

Etwas anderes als Loopback zu binden, erfordert ein zweites, bewusstes Flag, weil diese Konsole die Firewall und die NGINX-Konfiguration des Hosts, auf dem sie läuft, umschreiben kann:``` stop-bots web --bind 0.0.0.0:8787 --expose --allowed-hosts admin.example.com --save

Hinter TLS setzen Sie außerdem web:secure_cookie. Ohne dies sendet ein Browser das Session- Cookie auch an eine http://-URL für denselben Host.

web:trust_forwarded_for ist wichtiger, als es aussieht. Ohne dies kommt jede Anfrage hinter einem Proxy von 127.0.0.1 an, sodass die Konsole einen Client nicht von einem anderen unterscheiden kann — was bedeutet, dass eine Flut von Login-Versuchen denselben Throttle-Bucket wie Sie teilt und der Guard, der Sie daran hindert, Ihre eigene Adresse zu blockieren, nichts zum Vergleichen hat. Mit dieser Option funktionieren beide pro Client.

Hinter NGINX: eine Subdomain oder ein Pfadpräfix

Die Konsole kann dies für Sie einrichten, und die TUI kann das auch (w auf dem Dashboard). Beide schreiben die NGINX-Konfiguration, zeichnen das Pfadpräfix auf und fügen den Hostnamen zur Allowlist hinzu — die drei Dinge, die übereinstimmen müssen, denn ein fehlendes Präfix lässt jeden Link den location-Block verlassen und ein fehlender Hostname macht jede Anfrage zu einem 403. Beide validieren mit nginx -t, bevor die Konfiguration wirksam werden kann, machen sie rückgängig, wenn dies fehlschlägt, und zeichnen die neue Adresse erst auf, nachdem sie validiert wurde.

Zwei Modi, und Pfad ist aus einem Grund die Standardeinstellung: Er fügt einen location-Block zu einer Site hinzu, die Sie bereits haben, sodass die Konsole das Zertifikat dieser Site erbt. Eine Subdomain benötigt ein eigenes, und bis certbot --nginx -d <host> ausgeführt wurde, übertragen das Passwortformular und das Session- Cookie dieser Konsole Daten unverschlüsselt über das Netzwerk.

Der Rest dieses Abschnitts behandelt dasselbe manuell, was es wert ist, einmal gelesen zu werden, selbst wenn Sie das Panel verwenden — die unten beschriebene Trailing-Slash-Falle ist der Fehler, den es zu verhindern gilt.

Eine Subdomain ist die einfachere Bereitstellung, und die, die Sie wählen sollten, wenn Sie können:```nginx server { server_name stopbots.example.com; location / { proxy_pass http://127.0.0.1:8787; proxy_set_header Host $host; } }

Konfigurationsdatei

Die CLI unterstützt eine Konfigurationsdatei unter ~/.kitploit/config.yaml:

Umgebungsvariablen

Verwendung der API

Authentifizierung

Alle API-Anfragen erfordern einen gültigen API-Token im Authorization-Header:

Endpunkte

Beispielanfragen

Fehlerbehebung

Verbindung zum Server nicht möglich

1. Stellen Sie sicher, dass der Server läuft:

   root@kitploit:~

   curl http://localhost:8080/api/v1/health
   

2. Überprüfen Sie die Firewall-Einstellungen und stellen Sie sicher, dass der Port nicht blockiert ist.

3. Überprüfen Sie die Server-URL in Ihrer Konfigurationsdatei oder den Umgebungsvariablen.

Authentifizierungsfehler

1. Überprüfen Sie, ob Ihr API-Token gültig und nicht abgelaufen ist.

2. Stellen Sie sicher, dass der Authorization-Header korrekt formatiert ist.

3. Überprüfen Sie, ob Ihr Konto über die erforderlichen Berechtigungen verfügt.

Scan schlägt fehl oder bleibt hängen

1. Überprüfen Sie die Serverprotokolle auf Fehlermeldungen:

   root@kitploit:~

   docker logs kitploit-server
   

2. Erhöhen Sie den Timeout-Wert in Ihrer Konfiguration.

3. Stellen Sie sicher, dass das Ziel erreichbar ist und nicht durch eine Firewall blockiert wird.

Hohe Speicherauslastung

1. Reduzieren Sie die Anzahl gleichzeitiger Scans.

2. Erhöhen Sie die Speichergrenzen in Ihrer Docker-Konfiguration.

3. Überprüfen Sie die Datenbankgröße und bereinigen Sie alte Scan-Ergebnisse.``` stop-bots web --allowed-hosts stopbots.example.com --save

| -s | --server | Server-Modus aktivieren (erfordert --port) | | -p | --port | Port für den Server-Modus (Standard: 8080) | | -c | --config | Pfad zur Konfigurationsdatei | | -v | --verbose | Ausführliche Ausgabe aktivieren | | -h | --help | Hilfemeldung anzeigen | | -V | --version | Versionsinformationen anzeigen |

Beispiele

Konfiguration

Die Anwendung kann über eine YAML-Konfigurationsdatei konfiguriert werden:

Entwicklung

Projektstruktur

Tests ausführen

Beitragen

1. Repository forken
2. Feature-Branch erstellen (git checkout -b feature/amazing-feature)
3. Änderungen committen (git commit -m 'Add amazing feature')
4. Branch pushen (git push origin feature/amazing-feature)
5. Pull Request öffnen

Lizenz

Dieses Projekt ist unter der MIT-Lizenz lizenziert – siehe die Datei LICENSE für Details.

Danksagungen

• Besonderer Dank an alle Mitwirkenden
• Inspiration durch ähnliche Open-Source-Projekte
• Community-Feedback und Unterstützung```nginx location /stop-bots/ { proxy_pass http://127.0.0.1:8787; # NO trailing slash proxy_set_header Host $host; }

Der Befehl wird in Wörter aufgeteilt und direkt ausgeführt. Er durchläuft niemals eine Shell, daher sind ;, | und $VAR gewöhnliche Zeichen und keine Syntax.

Mitwirken

Wie der Code aufgebaut ist, wie er getestet wird und nach welchen Regeln er geschrieben wird, steht in CONTRIBUTING.md. Der Release-Prozess steht in RELEASING.md.

Kontakt

Du kannst mich unter [email protected] erreichen.

Lizenz

Copyright (C) 2026 Marko Ivankovic

Dieses Programm ist freie Software: Du kannst es unter den Bedingungen der GNU Affero General Public License, wie von der Free Software Foundation veröffentlicht, weitergeben und/oder modifizieren, entweder gemäß Version 3 der Lizenz oder (nach deiner Wahl) jeder späteren Version.

Siehe die Datei LICENSE für den vollständigen Text der Lizenz.

Du kannst AGPL-Software nicht verwenden?

Eine alternative Lizenzierung ist NICHT verfügbar.