Stop Bots

Una TUI, una console web e una CLI che ti aiutano a configurare il tuo server per fermare i bot dannosi senza nasconderti dietro una CDN.

Funziona insieme a NGINX e al tuo firewall esistente (nftables o iptables):

• Configurazione NGINX. - Classifica i bot conosciuti per categoria (scanner, motori di ricerca, crawler AI) e li blocca o li consente iniettando una regola nelle configurazioni del tuo sito. Analizza il log di NGINX per rilevare i bot dinamicamente e bloccarli anche se nessun ruleset li traccia ancora.
• Uno script firewall. - Blocca interi paesi, intervalli IP di datacenter, intervalli IP di bot conosciuti o qualsiasi indirizzo IP che tenta ripetutamente di accedere al tuo server senza successo. Ogni blocco registra il motivo per cui esiste.

L'app fa del suo meglio per non bloccarti fuori dal server, ma la usi a tuo rischio. E nota che è distribuita sotto licenza AGPL, quindi se la usi commercialmente, assicurati di rispettare la licenza.

Avvio rapido

Installazione

Su Debian o Ubuntu, dal repository APT:

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

Il pacchetto include man stop-bots (e una pagina per verbo, come man stop-bots-batch) e i completamenti per bash, zsh e fish. Non installa alcun servizio e non avvia nulla.

Oppure da crates.io, con Rust 1.88 o versione successiva:

cargo install stop-bots

Oppure scarica un binario statico per Linux x86_64 o aarch64 dalle release su GitHub.

Piattaforme supportate

• Debian e Ubuntu, con systemd e NGINX. Questo è ciò che viene testato. install rifiuta un host che non sia Debian o un derivato.
• Non Apache o Caddy. I loro log di accesso potrebbero essere analizzati, ma tutto ciò che scrive la configurazione del web server è solo per NGINX.
• Dipendenze di runtime: nft, oppure iptables-restore e ip6tables-restore, per il firewall; nginx per il resto. Anche NGINX in un container funziona — vedi Eseguire NGINX in un container.

Nella TUI

1. sudo stop-bots avvia la TUI. Richiede root: riscrive /etc/nginx e carica le regole del firewall.
2. u scarica ogni lista: liste di bot, intervalli IP dei crawler e qualsiasi feed o paese che hai attivato.
3. Rivedi. La Dashboard (1) contiene la policy a livello di host: quali categorie di bot sono bloccate, i paesi e i rilevatori che leggono i tuoi log. Nella schermata NGINX (4), r trova i tuoi siti. La schermata Blocks (5) elenca ogni regola aggiunta dai rilevatori o da te, e il perché.
4. a applica tutto. Prima mostra cosa cambierebbe — i file, le regole aggiunte e rimosse e il verdetto del controllo di lockout (d per il diff) — e chiede conferma.
5. sudo stop-bots install firewall fa sì che le regole applicate sopravvivano a un riavvio. Senza di esso, un riavvio ritorna senza alcuna regola.
6. sudo stop-bots status controlla il kernel, le unit e i file, e dice cosa manca.

Lo stesso dalla CLI, per gli script

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 non scarica né analizza nulla: su un'installazione nuova mostra i blocchi NGINX dalla lista di bot integrata nel binario, e ancora nessuna regola del firewall, perché nulla è stato letto dai tuoi log. sudo stop-bots batch senza --apply esegue i download e le scansioni e scrive i file per la revisione senza applicarli. Vedi Unattended, from cron per ciò che fa batch.

Annulla

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

Le prime elencano ogni passaggio, le seconde li eseguono. Vedi Aggiornamento e disinstallazione.

Da cosa protegge

Usando la configurazione NGINX

• Bot noti, per categoria (scanner / motore di ricerca / crawler AI), provenienti dalle liste ArcJet's Well-Known Bots, ai.robots.txt e NGINX Ultimate Bad Bot Blocker. Bloccare una categoria inietta una regola if ($http_user_agent ...) nella configurazione NGINX di ogni sito.

• Troppe richieste, tramite il rate limiting di NGINX stesso.

• Con cortesia, prima — un robots.txt generato che elenca ogni bot che stai bloccando, per i crawler che lo rispettano, più il percorso honeypot di seguito.

• Tranne dove dici diversamente — esenzioni di percorso per sito, e indirizzi e user agent fidati (trust), a cui non si applica alcun blocco, lista o rate limit.

• Richieste che non sembrano provenire da un browser, per sito. Sei regole indipendenti, ciascuna con il proprio interruttore e ciascuna disattivata per impostazione predefinita — un interruttore per regola, così se qualcosa del tuo smette di funzionare, puoi capire quale regola lo ha causato:

  Regola	Respinge, oltre ai bot
  HTTP/1.0 e HTTP/1.1	crawler e client API che non parlano HTTP/2
  Nessun header Accept	alcuni client API non ne inviano nessuno
  Nessun Accept-Language	gli strumenti per la privacy lo rimuovono
  User-Agent vuoto/assente	script e health check spesso lo omettono
  Host è un IP nudo	impedisce di raggiungere il sito tramite IP
  TLS 1.0 / 1.1	solo client molto vecchi

Cosa riceve effettivamente una richiesta bloccata

Ci sono sette scelte:

Opzione	A cosa serve
403 Forbidden (predefinito)	dice che il blocco è stato deliberato; l'unico su cui un umano catturato per errore può agire
404 Not Found	nasconde che qualcosa sia stato bloccato
410 Gone	chiede ai crawler ben educati di eliminare l'URL per sempre — preferiscilo al 403 quando stai respingendo crawler anziché attaccanti
429 Too Many Requests	dice a un client educato di rallentare e riprovare
418 I'm a teapot	lo scherzo della RFC 2324. Funziona; semplicemente non è registrato IANA, e NGINX lo invia con un corpo vuoto
444 close connection	nessuna risposta; il più economico, ma indistinguibile dal server inattivo
Tarpit	risponde 403 ma trasmette il corpo a un byte al secondo, così il client aspetta invece di andare avanti

Il tarpit è l'opzione più delicata per un falso positivo — un client catturato per errore viene rallentato, non rifiutato — e la più dura in termini di costo per un bot, la cui connessione resta inattiva. Una cosa da sapere prima di sceglierlo: occupa anche una delle tue connessioni worker per tutta la durata, quindi un'ondata di client in tarpit compete con i visitatori reali per le worker_connections.

Dai tuoi log, automaticamente