Seus logs de 404 são um relatório de segurança que você está ignorando

A maioria dos devs WordPress instala um plugin de redirect, configura uns 301, e nunca mais olha pros logs de 404. Isso é um erro.

Seus logs de 404 são um mapa em tempo real de quem está sondando seu site e o que estão procurando. Bots escaneando arquivos de ambiente expostos, vazamento de credenciais, arquivos de configuração, tentativas de path traversal, tudo aparece como 404 antes de aparecer como uma brecha.

Puxei os logs de 404 de dois dos meus próprios sites na última semana. Aqui vai o que encontrei, e o que bloqueei no nível da CDN pra que esses requests nunca mais batam no meu servidor.

Os números

Dois sites WordPress. Uma semana de dados.

Site A: 1.388 requests 404 no total, 1.118 URLs únicas
Site B: 2.693 requests 404 no total, 1.877 URLs únicas

Mais de 4.000 requests que não são usuários reais, não são mecanismos de busca e não são links quebrados. São scans automatizados procurando vulnerabilidades.

Os padrões de ataque

Todo log de 404 conta uma história. Aqui vão as cinco categorias que encontrei nos meus.

1. Varredura de Arquivos de Ambiente (.env)

De longe o padrão mais comum. Bots varrem sistematicamente todo caminho possível onde um arquivo .env possa existir:

/.env                    → 49 hits
/staging/.env            → 20 hits
/backend/.env            → 20 hits
/react/.env              → 15 hits
/.env.local              → 15 hits
/shared/.env             → 13 hits
/api/.env                → 12 hits
/.env.production         → 12 hits
/app/.env                → 10 hits
/server/.env             → 10 hits

E não para aí. Encontrei requests pra .env.backup, .env.bak, .env.save, .env.old, .env_copy, .env_secret, .env~, .env.swp — mais de 80 variações diferentes de .env no total.

O que estão procurando: Credenciais de banco de dados, chaves de API, senhas SMTP, chaves do Stripe, secrets da AWS. Um arquivo .env exposto = acesso total à sua infraestrutura.

2. Coleta de credenciais cloud

/.aws/credentials        → 17 hits
/.aws/config             → 5 hits
/.AwS/CrEdEnTiAlS        → 5 hits (variação de case pra burlar regras)
/.terraform/terraform.tfstate → 6 hits
/serviceAccountKey.json   → 4 hits
/credentials.json         → 5 hits

Repara na variação de case .AwS/CrEdEnTiAlS — isso é projetado especificamente pra burlar regras de pattern matching ingênuas que só checam lowercase. Estão caçando chaves AWS, service accounts do GCP e arquivos de state do Terraform que possam conter secrets de infraestrutura.

3. Sondagem de arquivos de config e secrets

/config/initializers/secret_token.rb  → 7 hits (Rails)
/config/storage.yml                   → 6 hits (Rails)
/application.yml                      → 5 hits (Spring Boot)
/docker-compose.yml                   → 4 hits
/sftp-config.json                     → 5 hits (Sublime SFTP)
/.vscode/sftp.json                    → 3 hits (VS Code SFTP)
/config.php.bak                       → 5 hits
/secrets.json                         → 6 hits
/sendgrid.env                         → 7 hits

Os bots não se importam com qual framework você usa. Escaneiam pra Rails, Laravel, Spring Boot, Node.js, Django — tudo na mesma varredura. Se você acidentalmente fez deploy de um arquivo de config, eles vão encontrar.

4. Sondagem específica de WordPress

/wp-config               → 3 hits
/wp-config~              → 1 hit
/wp-config.production    → 1 hit
/wp-configbak            → 1 hit

Estão procurando cópias de backup do wp-config.php — o arquivo que contém suas credenciais de banco de dados. Arquivos temporários de editor (wp-config~), backups manuais (wp-configbak), cópias por ambiente. Um descuido de cp wp-config.php wp-config.bak e você expôs tudo.

5. Path traversal e tentativas de execução de código

/etc/passwd?raw??                               → 3 hits
/@fs/etc/passwd?import&raw??                     → 3 hits
/admin/config?cmd=cat /root/.aws/credentials     → 1 hit
/vendor/phpunit/phpunit/phpunit.xsd              → 2 hits
/pms?module=logging&file_name=../../~/.aws/credentials → 1 hit

Essas são tentativas ativas de exploração, não só varredura. Estão tentando ler arquivos do sistema, executar comandos e explorar vulnerabilidades conhecidas no PHPUnit e outros pacotes.

O que fazer: bloquear na CDN

O insight principal: cada um desses requests bateu no seu servidor. Sua instalação WordPress processou, seu PHP executou, seu banco de dados foi consultado pra gerar uma página 404 — tudo pra um bot que está tentando hackear você.

A solução é simples: bloqueie esses padrões no nível da CDN (Cloudflare, Fastly, CloudFront) pra que eles nunca cheguem no seu servidor. Zero carga na sua infra, zero execução de PHP, zero risco.

Regras WAF no Cloudflare

Aqui vão as regras que configurei baseado nos meus dados reais de 404:

Importante: use lower() aqui — atacantes usam variações de case como .AwS/CrEdEnTiAlS pra burlar regras ingênuas.

Regra 1: Bloquear acesso a arquivos .env

(lower(http.request.uri.path) contains ".env")
Action: Block

Regra 2: Bloquear acesso a arquivos de credenciais/config

(lower(http.request.uri.path) contains ".aws/credentials" or
 lower(http.request.uri.path) contains "terraform.tfstate" or
 lower(http.request.uri.path) contains "serviceaccountkey" or
 lower(http.request.uri.path) contains "docker-compose.yml" or
 lower(http.request.uri.path) contains "sftp-config" or
 lower(http.request.uri.path) contains "sftp.json" or
 lower(http.request.uri.path) contains "secrets.json" or
 lower(http.request.uri.path) contains "credentials.json" or
 lower(http.request.uri.path) contains "sendgrid" or
 lower(http.request.uri.path) contains "secret_token.rb" or
 lower(http.request.uri.path) contains "storage.yml" or
 lower(http.request.uri.path) contains "application.yml")
Action: Block

Regra 3: Bloquear sondagem de wp-config

(lower(http.request.uri.path) contains "wp-config" and
 not http.request.uri.path eq "/wp-admin/")
Action: Block

Regra 4: Bloquear tentativas de path traversal

(lower(http.request.uri.path) contains "etc/passwd" or
 lower(http.request.uri.path) contains "phpunit" or
 lower(http.request.uri.path) contains "update.cgi" or
 http.request.uri contains "cmd=")
Action: Block

Regra 5: Bloquear sondagem de diretórios comuns de backup/instalação

(lower(http.request.uri.path) eq "/old/" or
 lower(http.request.uri.path) eq "/new/" or
 lower(http.request.uri.path) eq "/backup/" or
 lower(http.request.uri.path) eq "/wordpress/" or
 lower(http.request.uri.path) eq "/wp/" or
 lower(http.request.uri.path) eq "/test/")
Action: Block

Comparação de strings no Cloudflare é case-sensitive por padrão. A função lower() converte o URI path pra lowercase antes de comparar, então /.AwS/CrEdEnTiAlS é capturado por uma regra que checa .aws/credentials. Sem lower(), esse request passa direto.

Por que bloquear na CDN importa

Quando você bloqueia na CDN:

O request nunca chega no seu servidor
Sem execução PHP, sem query no banco, sem uso de CPU
Os recursos do seu servidor vão pra usuários reais, não bots
Você reduz sua superfície de ataque a zero pra padrões conhecidos
Os logs ficam limpos, facilitando identificar padrões novos

Bloquear no nível da aplicação (plugins WordPress, .htaccess) ainda funciona, mas o request já consumiu recursos do servidor quando é bloqueado. Bloqueio na CDN é a diferença entre um segurança na porta e um segurança dentro do bar.

Faça disso um hábito

Puxe seus logs de 404 uma vez por mês. Procure padrões. Adicione novas regras no Cloudflare.

Os bots evoluem. Novos padrões de varredura aparecem. O truque de variação de case .AwS/CrEdEnTiAlS é um exemplo perfeito — alguém projetou isso especificamente pra burlar regras que só checam lowercase.

Seus logs de 404 não são só links quebrados. São uma auditoria de segurança gratuita. Leia eles.

Os dados nesse post vêm de logs reais de 404 coletados ao longo de uma semana de dois sites WordPress em produção. Nenhum IP ou informação identificável dos bots atacantes foi incluído.

EduardoVillão