Laravel Threat Detection

Monitoramento de segurança e registro de ataques para Laravel. Detecte e registre injeção de SQL, XSS, RCE, directory traversal, scanners de bots e sondagens de reconhecimento no estilo /wp-admin — cada requisição hostil registrada no seu banco de dados com contexto completo da aplicação. É um IDS, não um WAF: ele nunca bloqueia, filtra ou modifica uma requisição.

Você está aqui porque viu algo parecido com isto?```

GET /wp-admin/setup-config.php 404 — on a site that isn't WordPress GET /.env 404 — someone wants your database password GET /?id=1' UNION SELECT password FROM 200 — SQL injection against a real route GET /phpmyadmin/index.php 404 — scanning for an admin panel

Essas requisições já estão chegando ao seu aplicativo Laravel. Seu log de acesso mostra a URL
e o código de status, e nada mais — nem o payload decodificado, nem qual das suas
rotas foi alvo, nem se o mesmo IP já tentou outras quarenta coisas nesta hora.

Este pacote responde a essas perguntas. Coloque-o em qualquer aplicativo Laravel 10–13 e ele começa
a escanear cada requisição HTTP em busca de mais de 150 padrões de ataque, pontuando cada correspondência por
confiança e gravando-a no seu banco de dados — com um dashboard integrado, alertas no Slack,
enriquecimento geográfico e exportações para fail2ban/blocklist. Nenhuma requisição é jamais bloqueada. Pense
em câmera de segurança, não em fechadura: ela mostra exatamente quem está sondando suas rotas, com que
frequência e com quais técnicas.

> Extraído de um aplicativo em produção e testado em batalha com tráfego real. 1.857 testes, sem dependências
> de runtime além do próprio Laravel, e nenhuma conexão com a internet necessária para detecção.
>
> Atualizando? Veja [UPGRADING.md](https://github.com/jay123anta/laravel-threat-detection/blob/main/UPGRADING.md). Contribuindo? Veja [CONTRIBUTING.md](https://github.com/jay123anta/laravel-threat-detection/blob/main/CONTRIBUTING.md).

## Comece em menos de um minuto```bash
composer require jayanta/laravel-threat-detection
php artisan vendor:publish --tag=threat-detection-migrations
php artisan migrate

Em seguida, adicione o middleware ao seu grupo web (uma linha em bootstrap/app.php no Laravel 11+, ou app/Http/Kernel.php no Laravel 10) — o snippet completo está em Quick Start abaixo. É isso; a detecção está ativa.```bash php artisan threat-detection:doctor # confirms it is actually recording

---

## Onde ele se encaixa: IDS vs WAF vs edge

Este pacote é um **IDS passivo, em nível de aplicação** — ele observa e registra, não
bloqueia. Ele foi feito para ficar *ao lado* de um WAF ou serviço de edge, não para substituí-los. Cada camada enxerga
algo que as outras não conseguem:

| | **Este pacote** (IDS de app) | **WAF** (mod_security, Cloudflare WAF) | **Edge / CDN** (Cloudflare) |
|---|:---:|:---:|:---:|
| Bloqueia requisições maliciosas | ❌ apenas registra | ✅ | ✅ |
| Contexto completo da aplicação (rota exata, payload decodificado, usuário autenticado) | ✅ | ⚠️ parcial | ❌ |
| Dashboard integrado + log de ameaças no seu banco de dados | ✅ | ⚠️ varia | ⚠️ apenas no edge |
| Detecções específicas da aplicação (ex.: PII de Aadhaar / PAN / IFSC) | ✅ padrões personalizados | ❌ | ❌ |
| Funciona offline / sem serviço externo | ✅ | ⚠️ depende | ❌ |
| Interrompe o tráfego antes de chegar à sua aplicação | ❌ | ✅ no edge | ✅ |
| Configuração | um `composer require` | média–alta | baixa–média |
| Custo | gratuito, MIT | varia | camada gratuita + pago |

**Resumindo:** um edge/WAF é a fechadura da sua porta; isto é a câmera de segurança
*do lado de dentro*, com o contexto da aplicação para lhe dizer exatamente o que está sendo tentado em qual rota, por
quem, e com que frequência. Use-o para alimentar decisões reais — banimentos via fail2ban, limites de taxa,
geo-bloqueio — com dados que sua camada de edge nunca vê.

### O que ele deliberadamente NÃO é

- **Não é um WAF.** Ele nunca bloqueia, filtra ou modifica uma requisição. Use Cloudflare,
  mod_security, ou um WAF de verdade para aplicação de políticas. (Sem camada de edge para delegar? Os
  [helpers do lado do operador](#acting-on-the-data-operator-side-blocking) expõem as
  decisões do pacote para que você possa escrever seu próprio middleware de bloqueio de cinco linhas —
  o código de aplicação de políticas continua sendo seu, não do pacote.)
- **Não substitui a codificação segura.** Consultas parametrizadas, validação de entrada e
  escape de saída são suas defesas reais. Este pacote assume que seu código já é
  seguro e lhe dá *visibilidade*, não proteção.
- **Não é um serviço de edge.** Se você puder colocar o Cloudflare na frente, faça isso — depois adicione isto para o
  detalhamento em nível de aplicação que os serviços de edge não conseguem ver.
- **Não é um detector completo, e não pode ser.** A correspondência de padrões captura ataques que
  *se parecem com* ataques conhecidos. Uma técnica nova, ou uma familiar reescrita o suficiente, vai
  passar sem ser registrada — e você não será avisado de que isso aconteceu. Silêncio aqui significa
  "nada correspondeu", nunca "nada aconteceu". Onde ele ganha seu lugar é no
  tráfego de alto volume e baixo esforço que compõe a maior parte do que realmente atinge uma aplicação
  Laravel pública: scanners, sondagens de reconhecimento, strings de injeção prontas, pulverização de credenciais. Trate um log silencioso como ausência de evidência, não como evidência de ausência.

### Espere que ele sinalize seu próprio conteúdo no primeiro dia

Uma instalação sem ajuste dispara em conteúdo legítimo, e você deveria saber disso antes
de instalar, não depois. Estes são medidos, não hipotéticos — a suíte fixa exatamente esta lista para que ela não possa mudar ([`LegitimateTrafficCorpusTest`](https://github.com/jay123anta/laravel-threat-detection/blob/main/tests/Feature/LegitimateTrafficCorpusTest.php)):