Como Confundir Scanners de Vulnerabilidade com Krawl

Se você abrir os logs de qualquer servidor web público, quase certamente encontrará um fluxo constante de lixo: buscas intermináveis por /wp-login.php, /.env, /.git/HEAD ou versões antigas do phpMyAdmin. Scanners e parsers caçam presas fáceis 24 horas por dia. Geralmente, apenas bloqueamos o acesso através do NGINX ou cortamos com regras de WAF. Mas existe outra abordagem: em vez de lutar de volta, alimente a automação do inimigo com desinformação de primeira enquanto esgota os recursos do atacante.

Recentemente encontrei o projeto Krawl. É um servidor de engano especializado que finge ser um aplicativo web vulnerável, alimenta bots com páginas-armadilha infinitas e pode até gerar HTML realista em tempo real usando modelos de linguagem.

O que essa armadilha pode fazer

O objetivo principal do Krawl é simples: parecer atraente para scanners automatizados, registrar seu comportamento e arrastá-los para um beco sem saída.

Aqui está o que ele usa internamente:

• Redes de links infinitos (Spider Traps). O projeto gera páginas com links aleatórios entre si, forçando parsers a caminhar em círculos e desperdiçar tráfego.
• Falsos painéis de administração e arquivos de configuração. Krawl responde a requisições para caminhos populares como WordPress, phpMyAdmin ou painéis de login, coletando senhas digitadas.
• Geração de páginas via redes neurais. Se um scanner atinge um endereço desconhecido, Krawl pode consultar OpenRouter ou OpenAI para renderizar rapidamente HTML contextual com uma vulnerabilidade.
• Armadilhas em robots.txt. O servidor declara caminhos proibidos que bots imediatamente começam a verificar primeiro, revelando suas intenções.

Além disso, o servidor pode injetar canary tokens do CanaryTokens. Se um atacante tentar usar uma falsa chave de API encontrada em um sistema externo, você receberá uma notificação imediatamente.

Como o Krawl calcula a reputação de IPs

Capturar bots não é suficiente—você precisa entender quem realmente está batendo na sua porta. O Krawl analisa a atividade de cada endereço IP recebido em segundo plano através de vários critérios.

O sistema avalia a frequência de métodos HTTP arriscados, visitas a caminhos do robots.txt, tempo das requisições e correspondências com assinaturas de SQLi ou XSS. No final, o endereço recebe um rótulo: atacante, rastreador ruim, mecanismo de busca legítimo ou usuário comum.

Se a exportação estiver ativada, você pode buscar os dados diretamente via API para seus filtros de rede:

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

O endpoint entrega regras prontas para iptables, nftables, RouterOS ou blocklists para OPNsense e pfSense.

Painel de monitoramento

Existe uma interface web para observar o que está acontecendo. Para evitar que bots encontrem acidentalmente o próprio painel de administração do honeypot, ele fica oculto atrás de um caminho secreto dinâmico (KRAWL_DASHBOARD_SECRET_PATH) e senha.

Lá dentro, você pode ver a geografia dos ataques, uma análise dos tipos de payload e um dossiê detalhado de cada endereço suspeito com histórico de requisições e linha do tempo.

Dois modos de operação

Os desenvolvedores criaram duas configurações:

1. Standalone. Executa em um único container, armazena dados em SQLite no modo WAL e mantém o cache diretamente na memória do processo Python. Uma boa opção para projetos pessoais e VPSs pequenos onde o tráfego não excede algumas centenas de milhares de requisições.
2. Scalable. Este traz PostgreSQL e Redis. Esse modo é necessário quando você deseja escalar horizontalmente instâncias do Krawl atrás de um load balancer ou implantar o projeto em Kubernetes via o Helm chart oficial.

O padrão típico de uso se resume a posicionar o Krawl ao lado do seu aplicativo principal atrás do NGINX ou Traefik. Todo tráfego suspeito ou requisições para caminhos de sistema inexistentes são direcionados para o honeypot.

Início rápido

A maneira mais simples de testar o projeto localmente é executar um container Docker no modo 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 você planeja configurar a geração de páginas alimentada por IA, basta adicionar variáveis de ambiente ao 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:

Para que isso será útil

O Krawl provavelmente não substituirá um WAF completo em um projeto de alto tráfego, mas ele tem um nicho diferente. É uma ferramenta excelente para blue teams, homelabs e quem deseja estudar padrões de ataque reais em seus serviços.

Em vez de rejeitar requisições cegamente com um 404, você transforma a varredura em uma armadilha, coleta um banco de dados de IPs maliciosos e alimenta seus firewalls. Você pode começar a experimentar com um container Docker comum em um subdomínio separado ou servidor de teste.