Come confondere i vulnerability scanner con Krawl

Se apri i log di qualsiasi server web pubblico, troverai quasi certamente un flusso costante di spazzatura: ricerche infinite di /wp-login.php, /.env, /.git/HEAD o vecchie versioni di phpMyAdmin. Scanner e parser cercano prede facili 24 ore su 24. Di solito, li blocchiamo tramite NGINX o li escludiamo con regole WAF. Ma c'è un altro approccio: invece di combatterli, fornisci alla loro automazione disinformazione di alta qualità mentre prosciughi le risorse dell'attaccante.

Recentemente mi sono imbattuto nel progetto Krawl. È un server di inganno specializzato che si finge un'applicazione web vulnerabile, fornisce ai bot pagine-trappola infinite e può persino generare HTML realistico al volo usando modelli linguistici.

Cosa può fare questa trappola

L'obiettivo principale di Krawl è semplice: apparire attraente per gli scanner automatizzati, registrare il loro comportamento e trascinarli in un vicolo cieco.

Ecco cosa usa internamente:

• Reti di link infinite (Spider Trap). Il progetto genera pagine con link casuali tra loro, costringendo i parser a camminare in cerchio e consumare traffico.
• Pannelli di amministrazione falsi e file di configurazione. Krawl risponde alle richieste di percorsi popolari come WordPress, phpMyAdmin o pannelli di login, raccogliendo le password inserite.
• Generazione di pagine tramite reti neurali. Se uno scanner raggiunge un indirizzo sconosciuto, Krawl può interrogare OpenRouter o OpenAI per generare rapidamente HTML contestuale con una vulnerabilità.
• Trappole nei robots.txt. Il server dichiara percorsi proibiti che i bot iniziano immediatamente a controllare per primi, rivelando le loro intenzioni.

Inoltre, il server può iniettare token canary da CanaryTokens. Se un attaccante tenta di usare una chiave API falsa trovata in un sistema esterno, riceverai immediatamente una notifica.

Come Krawl calcola la reputazione degli IP

Catturare i bot non basta—devi capire chi sta realmente bussando alla tua porta. Krawl analizza l'attività di ogni indirizzo IP in entrata in background secondo diversi criteri.

Il sistema valuta la frequenza dei metodi HTTP rischiosi, le visite ai percorsi da robots.txt, la tempistica delle richieste e le corrispondenze con firme SQLi o XSS. Alla fine, l'indirizzo riceve un'etichetta: attaccante, crawler malevolo, motore di ricerca legittimo o utente normale.

Se l'esportazione è abilitata, puoi recuperare i dati direttamente tramite API per i tuoi filtri di rete:

curl "https://krawl.local/<SECRET_PATH>/api/export-ips?categories=attacker&fwtype=iptables"

L'endpoint fornisce regole pronte all'uso per iptables, nftables, RouterOS o blocklist per OPNsense e pfSense.

Dashboard di monitoraggio

C'è un'interfaccia web per osservare cosa sta succedendo. Per impedire ai bot di trovare accidentalmente il pannello di amministrazione dell'honeypot stesso, è nascosto dietro un percorso segreto dinamico (KRAWL_DASHBOARD_SECRET_PATH) e una password.

All'interno, puoi vedere la geografia degli attacchi, una suddivisione dei tipi di payload e un dossier dettagliato su ogni indirizzo sospetto con cronologia delle richieste e timeline.

Due modalità operative

Gli sviluppatori hanno creato due configurazioni:

1. Standalone. Gira in un singolo container, memorizza i dati in SQLite in modalità WAL e mantiene la cache direttamente nella memoria del processo Python. Una buona opzione per progetti personali e piccoli VPS dove il traffico non supera qualche centinaio di migliaia di richieste.
2. Scalable. Questa porta con sé PostgreSQL e Redis. Questa modalità è necessaria quando vuoi scalare orizzontalmente le istanze di Krawl dietro un load balancer o distribuire il progetto in Kubernetes tramite la chart Helm ufficiale.

Il pattern d'uso tipico consiste nel posizionare Krawl accanto alla tua applicazione principale dietro NGINX o Traefik. Tutto il traffico sospetto o le richieste a percorsi di sistema inesistenti vengono instradate all'honeypot.

Avvio rapido

Il modo più semplice per provare il progetto localmente è eseguire un container Docker in modalità Standalone:

docker run -d \
  -p 5000:5000 \
  -e KRAWL_DASHBOARD_SECRET_PATH="/my-secret-dashboard" \
  -e KRAWL_DASHBOARD_PASSWORD="admin-secret-password" \
  -v krawl-data:/app/data \
  --name krawl \
  ghcr.io/blessedrebus/krawl:latest

Se stai pianificando di configurare la generazione di pagine alimentata da AI, basta aggiungere le variabili d'ambiente a docker-compose. yml:

services:
  krawl:
    image: ghcr.io/blessedrebus/krawl:latest
    container_name: krawl-server
    ports:
      - "5000:5000"
    environment:
      - KRAWL_MODE=standalone
      - KRAWL_DASHBOARD_SECRET_PATH=/secret-dashboard
      - KRAWL_DASHBOARD_PASSWORD=super-safe-password
      - KRAWL_AI_ENABLED=true
      - KRAWL_AI_PROVIDER=openrouter
      - KRAWL_AI_API_KEY=your_openrouter_key
      - KRAWL_AI_MODEL=nvidia/nemotron-3-super-120b-a12b:free
    volumes:
      - krawl-data:/app/data
    restart: unless-stopped

volumes:
  krawl-data:

A cosa servirà

Krawl difficilmente sostituirà un WAF completo su un progetto ad alto traffico, ma ha una nicchia diversa. È un ottimo strumento per i blue team, gli homelab e chi vuole studiare pattern di attacco reali sui propri servizi.

Invece di rifiutare ciecamente le richieste con un 404, trasformi lo scanning in una trappola, raccogli un database di IP malevoli e lo invii ai tuoi firewall. Puoi iniziare a sperimentare con un normale container Docker su un sottodominio separato o server di test.