Comment dérouter les scanners de vulnérabilités avec Krawl

Si vous ouvrez les logs de n'importe quel serveur web public, vous trouverez presque certainement un flux constant de déchets : des recherches infinies pour /wp-login.php, /.env, /.git/HEAD ou d'anciennes versions de phpMyAdmin. Les scanners et les parseurs chassent des proies faciles 24 heures sur 24. D'habitude, on bloque simplement l'accès via NGINX ou on les coupe avec des règles WAF. Mais il y a une autre approche : au lieu de riposter, alimentez l'automatisation ennemie en désinformation de premier ordre tout en épuisant les ressources de l'attaquant.

Récemment, je suis tombé sur le projet Krawl. C'est un serveur de leurre spécialisé qui se fait passer pour une application web vulnérable, alimente les bots en pages pièges infinies, et peut même générer du HTML réaliste à la volée en utilisant des modèles de langage.

Ce que ce piège peut faire

Le objectif principal de Krawl est simple : paraître attractif pour les scanners automatisés, enregistrer leur comportement, et les entraîner dans une impasse.

Voici ce qu'il utilise en interne :

• Des toiles de liens infinies (Spider Traps). Le projet génère des pages avec des liens aléatoires entre elles, forçant les parseurs à tourner en rond et à gaspiller du trafic.
• De faux panneaux d'administration et fichiers de configuration. Krawl répond aux requêtes pour des chemins populaires comme WordPress, phpMyAdmin ou les panneaux de connexion, collectant les mots de passe saisis.
• Génération de pages via des réseaux de neurones. Si un scanner tombe sur une adresse inconnue, Krawl peut interroger OpenRouter ou OpenAI pour générer rapidement du HTML contextuel avec une vulnérabilité.
• Des pièges dans robots.txt. Le serveur déclare des chemins interdits que les bots commencent immédiatement à vérifier en premier, révélant leurs intentions.

De plus, le serveur peut injecter des jetons canaris depuis CanaryTokens. Si un attaquant essaie d'utiliser une fausse clé API trouvée dans un système externe, vous recevrez immédiatement une notification.

Comment Krawl calcule la réputation des IP

Piéger les bots ne suffit pas — vous devez comprendre qui frappe réellement à votre porte. Krawl analyse en arrière-plan l'activité de chaque adresse IP entrante selon plusieurs critères.

Le système évalue la fréquence des méthodes HTTP risquées, les visites de chemins depuis robots.txt, le timing des requêtes et les correspondances avec des signatures SQLi ou XSS. À la fin, l'adresse reçoit une étiquette : attaquant, mauvais robot d'indexation, moteur de recherche légitime ou utilisateur ordinaire.

Si l'export est activé, vous pouvez récupérer les données directement via l'API pour vos filtres réseau :

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

Le point de terminaison fournit des règles prêtes à l'emploi pour iptables, nftables, RouterOS, ou des listes de blocage pour OPNsense et pfSense.

Tableau de bord de surveillance

Il y a une interface web pour observer ce qui se passe. Pour empêcher les bots de trouver accidentellement le panneau d'administration du honeypot, il est dissimulé derrière un chemin secret dynamique (KRAWL_DASHBOARD_SECRET_PATH) et un mot de passe.

À l'intérieur, vous pouvez voir la géographie des attaques, une répartition des types de payloads, et un dossier détaillé sur chaque adresse suspecte avec l'historique des requêtes et la chronologie.

Deux modes de fonctionnement

Les développeurs ont créé deux configurations :

1. Autonome. S'exécute dans un seul conteneur, stocke les données dans SQLite en mode WAL, et garde le cache directement en mémoire du processus Python. Une bonne option pour les projets personnels et les petits VPS où le trafic ne dépasse pas quelques centaines de milliers de requêtes.
2. Évolutif. Celui-ci fait appel à PostgreSQL et Redis. Ce mode est nécessaire lorsque vous souhaitez mettre à l'échelle horizontalement les instances Krawl derrière un load balancer ou déployer le projet dans Kubernetes via le chart Helm officiel.

Le schéma d'utilisation typique se résume à placer Krawl aux côtés de votre application principale derrière NGINX ou Traefik. Tout le trafic suspect ou les requêtes vers des chemins système inexistants sont proxés vers le honeypot.

Démarrage rapide

Le moyen le plus simple d'essayer le projet en local est d'exécuter un conteneur Docker en mode Autonome :

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

Si vous prévoyez de configurer la génération de pages alimentée par l'IA, ajoutez simplement des variables d'environnement à 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:

À quoi cela servira

Krawl ne remplacera probablement pas un WAF complet sur un projet à fort trafic, mais il a une niche différente. C'est un excellent outil pour les équipes bleues, les homelabs et ceux qui souhaitent étudier les véritables schémas d'attaque sur leurs services.

Au lieu de rejeter aveuglément les requêtes avec un 404, vous transformez le balayage en piège, constituez une base de données d'IP malveillantes et alimentez-la vers vos pare-feux. Vous pouvez commencer à expérimenter avec un simple conteneur Docker sur un sous-domaine séparé ou un serveur de test.