IDS/IPS • Detecção de Intrusão • Detection Engineering • Blue Team
Suricata 8.0.5 no Kali Linux com 50.000+ regras ativas, integrado ao Wazuh SIEM. Diagnóstico de sensor mal posicionado (interface errada), criação de regras customizadas para cobrir gap real do ET Open contra APIs JSON, e detecção validada de dois ataques reais — Metasploitable2 e OWASP Juice Shop.
Topologia
Este laboratório foi executado em ambiente local, controlado e autorizado. Endereços IP, hostnames, usuários, comandos e evidências exibidos pertencem ao ambiente de estudo ou foram anonimizados. Nenhuma credencial real, token, chave privada ou dado sensível deve ser publicado.
Índice
Sobre o laboratório
O Suricata é um motor open source de detecção e prevenção de intrusões em rede (IDS/IPS). Ele analisa tráfego em tempo real, aplica assinaturas de detecção e gera alertas estruturados em JSON — cobrindo uma camada que ferramentas de HIDS como o Wazuh Agent sozinhas não cobrem: o tráfego de rede entre os hosts.
Este laboratório foi além da instalação e configuração básica. Após integrar o Suricata ao Wazuh, dois problemas reais foram diagnosticados e corrigidos — interface de captura errada e gap de cobertura das regras ET Open contra APIs modernas. O resultado é um sensor de rede calibrado, com regras customizadas criadas, e detecção validada contra ataques reais executados do zero no ambiente do lab.
Especificações
Suricata instalado no Kali Linux rodando como VM no VMware Workstation. Interface de captura eth0 na LAN do pfSense (10.10.10.20), atrás do gateway.
Versão mais recente em modo AF-PACKET. Após correção da interface (eth1 → eth0), o sensor passou a capturar todo o tráfego da LAN do lab. 272MB+ de eventos no eve.json, 50.000+ regras carregadas.
Ubuntu Server com Wazuh Manager (10.10.10.10) coletando eventos do Suricata via Logcollector. Decoders nativos para eve.json processam campos como alert.signature, src_ip e dest_port.
Regras carregadas via suricata-update de múltiplas fontes open source. Duas regras customizadas criadas localmente (SID 9000001 e 9000002) para cobrir gap real de cobertura contra APIs JSON modernas.
Processo de implementação
Cada etapa foi executada em sequência, validada e documentada antes de avançar. O fluxo seguiu a mesma metodologia aplicada nos outros laboratórios: leitura, planejamento, alteração, teste e validação.
Instalação do Suricata 8.0.5 no Kali Linux via repositório oficial. Verificação do serviço com systemctl status suricata confirmando modo AF-PACKET ativo.
Execução do suricata-update para carregar o índice de fontes. Listagem de todas as fontes disponíveis incluindo Emerging Threats, Abuse.ch, OISF, Stamus Networks e outras. 50.000+ regras carregadas.
Ativação da fonte especializada em detecção de scans Nmap — regras que identificam -sS (SYN scan), -sX (Xmas scan) e outras técnicas de reconhecimento.
Configuração do ossec.conf no agente Kali para monitorar o eve.json via Logcollector. Confirmação nos logs do agente e no dashboard Wazuh com 710+ eventos nas primeiras 24h.
Diagnóstico de gap de visibilidade: sensor configurado na interface eth1 (rede errada) em vez de eth0 (LAN do lab). Ataques não apareciam no SIEM. Corrigido no suricata.yaml e revalidado com reteste.
ET Open tem 7104 regras de web-application-attack, mas nenhuma para APIs REST/JSON modernas. Duas regras criadas em local.rules usando http.request_body e pcre para cobrir SQLi em POST e XSS em URI.
Regras de detecção
O Suricata funciona com base em assinaturas — regras que definem padrões de tráfego suspeito. Quanto mais regras calibradas para o ambiente, maior a cobertura real de detecção. Neste lab, além das fontes externas, foram criadas regras próprias para cobrir gaps identificados.
Conjunto open source mantido pela Proofpoint. Cobre ameaças como malware, exploits, C2, botnets e tráfego suspeito em geral. 7104 regras de web-application-attack incluídas, mas com cobertura limitada para APIs JSON modernas.
Quatro feeds especializados: Feodo Tracker (botnets C2), SSL Blacklist, JA3 Fingerprints e URLhaus. Foco em infraestrutura maliciosa conhecida e certificados TLS suspeitos.
Regras específicas para detecção de scans com Nmap — SYN scan, Xmas scan e outras técnicas de reconhecimento. Usadas nos testes do laboratório e responsáveis pelas primeiras detecções reais.
Duas regras criadas para cobrir gap real identificado durante o Red Team vs Blue Team. A keyword http.request_body inspeciona o corpo de requisições POST — o que as regras ET Open não faziam.
Troubleshooting
Após configurar a integração com o Wazuh, os ataques executados contra o Metasploitable2 simplesmente não apareciam no dashboard. O pipeline estava funcionando (outros alertas chegavam), mas nenhum evento relacionado ao IP do alvo era encontrado — mesmo com o ataque confirmado na shell reversa.
Busca data.dest_ip: 10.10.10.30 no Wazuh retornando zero resultados, mesmo com o exploit Metasploit confirmado e shell reversa ativa na porta 4444.
Comando grep -A 5 "af-packet:" /etc/suricata/suricata.yaml revelou interface: eth1 — a interface secundária do Kali (rede 10.10.20.0/24), não a LAN do lab (eth0, 10.10.10.0/24).
Edição do suricata.yaml: af-packet: interface: eth1 → interface: eth0. Restart do serviço e reteste do ataque.
Após a correção, alertas apareceram no eve.json e no dashboard do Wazuh — incluindo a detecção da shell reversa do Metasploit (SID 3400020, severity 1, "A Network Trojan was detected").
Lição aprendida
Sensor de rede mal posicionado é uma das causas mais comuns de gap de visibilidade em SOCs reais. A configuração parecia correta, o serviço estava ativo e eventos chegavam ao SIEM — mas o sensor simplesmente não via o tráfego certo. Configuração não validada com tráfego real é configuração não confirmada.
Integração com Wazuh
O Suricata analisa todo o tráfego na interface eth0 do Kali em tempo real, aplicando as 50.000+ regras carregadas via suricata-update.
Cada evento detectado é gravado em formato JSON estruturado em /var/log/suricata/eve.json — alertas, flows, DNS, HTTP, TLS e SMB.
O bloco <localfile><log_format>json</log_format> no ossec.conf instrui o agente a ler o eve.json e enviar os eventos ao Manager.
O Manager aplica decoders nativos de Suricata (regra 86601) e exibe os alertas no dashboard com campos como data.alert.signature, data.src_ip e data.dest_port.
710+ eventos nas primeiras 24h após a correção da interface. Buscas por rule.groups: suricata retornando alertas reais com assinaturas identificadas.
Red Team vs Blue Team
O objetivo foi validar o pipeline completo: configurar o sensor, atacar de propósito, e confirmar (ou identificar a ausência de) detecção real no Wazuh. Dois alvos diferentes, cada um expondo uma camada diferente da cobertura do Suricata.
Ataque 1
nmap -sV -p- contra 10.10.10.30. 29 serviços identificados incluindo Samba 3.X nas portas 139/445, vsftpd 2.3.4 e UnrealIRCd.
Módulo Metasploit exploit/multi/samba/usermap_script. Shell reversa porta 4444. Confirmado: whoami → root, uid=0(root).
Suricata detectou reconhecimento (POSSBL PORT SCAN NMAP -sA) e exploração (POSSBL SCAN SHELL M-SPLOIT TCP, severity 1, "Network Trojan detected"). Ambos visíveis no Wazuh.
Alerta real — eve.json
{
"event_type": "alert",
"src_ip": "10.10.10.30",
"dest_ip": "10.10.10.20",
"dest_port": 4444,
"alert": {
"signature": "POSSBL SCAN SHELL M-SPLOIT TCP",
"category": "A Network Trojan was detected",
"severity": 1,
"signature_id": 3400020
}
}
Ataque 2
Payload ' OR 1=1-- no POST /rest/user/login. Bypass de autenticação — acesso ao admin sem senha. Detectado pela regra customizada SID 9000001.
Payload <img src=x onerror="alert('XSS')">. Ataque executado com sucesso, mas não detectável via rede — parâmetro processado inteiramente no frontend (Angular hash routing), nunca trafegou como requisição HTTP.
ET Open tem 7104 regras de web-application-attack, mas escritas para stacks PHP/GET — não para APIs JSON modernas. SQLi em body de POST não era coberto por nenhuma regra existente até a criação da regra customizada.
Detection Engineering
Identificado o gap de cobertura, a solução foi criar regras próprias em
/var/lib/suricata/rules/local.rules
e referenciar o arquivo no suricata.yaml.
A keyword http.request_body
foi o elemento-chave — ela instrui o Suricata a inspecionar o corpo da requisição HTTP,
não apenas a URL.
local.rules — SID 9000001 (SQLi)
alert http any any -> any 3000 ( msg:"LOCAL SQLi Attempt - OR 1=1 in HTTP Body"; flow:to_server,established; http.request_body; content:"OR 1"; nocase; classtype:web-application-attack; sid:9000001; rev:1; )
local.rules — SID 9000002 (XSS)
alert http any any -> any 3000 ( msg:"LOCAL XSS Attempt - script/onerror in URI"; flow:to_server,established; http.uri; pcre:"/(script|onerror|onload)/i"; classtype:web-application-attack; sid:9000002; rev:2; )
Gap analysis — visibilidade por tipo de ataque
| Tipo de ataque | Trafega pela rede? | ET Open detecta? | Regra customizada? |
|---|---|---|---|
| Port scan (nmap) | ✅ Sim | ✅ Sim | — |
| Shell reversa Metasploit | ✅ Sim | ✅ Sim (SID 3400020) | — |
| SQLi em body JSON (POST API) | ✅ Sim | ❌ Não (gap real) | ✅ SID 9000001 |
| XSS Refletido/Armazenado | ✅ Sim | ⚠️ Parcial | ✅ SID 9000002 |
| DOM XSS puro (client-side) | ❌ Não | ❌ Impossível | ❌ Impossível por design |
Competências desenvolvidas
Configuração e operação do Suricata como IDS em modo AF-PACKET, monitorando tráfego de rede em tempo real. Diagnóstico e correção de sensor mal posicionado com revalidação ativa.
Criação de regras Suricata customizadas para cobrir gap real do ET Open. Uso de http.request_body e pcre para inspecionar corpo de POST e URI — o que as regras genéricas não faziam.
Identificação de limitações estruturais do NIDS: ET Open vs APIs JSON modernas, e DOM XSS client-side invisível a qualquer sensor de rede. Documentação de causas raiz e controles adequados por camada.
Pipeline completo Suricata → eve.json → Wazuh Logcollector → Manager → Dashboard. Decoders nativos processando campos estruturados de alerta, com busca por rule.groups: suricata e data.alert.signature_id.
Reconhecimento com nmap, exploração de CVE via Metasploit, SQL Injection em API REST e DOM XSS em SPA moderna. Cada ataque executado e correlacionado com alertas de rede no SIEM.
Diagnóstico de visibilidade zero no SIEM com pipeline funcionando. Causa raiz identificada via suricata.yaml, corrigida e revalidada com reteste real — não com simulação.
Resultados
Evidências
Fluxo da detecção
Neste laboratório, o Suricata foi utilizado para identificar uma tentativa de SQL Injection em uma requisição HTTP.
A partir dessa atividade suspeita, o IDS gerou um alerta, registrou o evento no arquivo eve.json e permitiu
que a evidência fosse analisada dentro do fluxo de monitoramento de segurança.
Uma tentativa de SQL Injection foi simulada contra uma aplicação web, gerando tráfego malicioso na rede.
O Suricata inspecionou o tráfego em tempo real e comparou o comportamento observado com regras de detecção.
Ao identificar o padrão suspeito, o Suricata gerou um alerta contendo assinatura, severidade, origem, destino e contexto.
O evento foi registrado em formato JSON, permitindo análise estruturada, correlação e integração com outras ferramentas.
O alerta pôde ser utilizado como evidência para investigação, documentação e entendimento do fluxo de detecção.
O Suricata está disponível nos repositórios oficiais do Kali Linux. Instalação direta via apt:
sudo apt update sudo apt install suricata -y suricata --version # Suricata version 8.0.5 RELEASE
Validação do serviço:
sudo systemctl status suricata --no-pager # Active: active (running) # /usr/bin/suricata -D --af-packet -c /etc/suricata/suricata.yaml
O modo AF-PACKET captura pacotes diretamente via kernel, sem libpcap — mais eficiente para ambientes de alta velocidade.
O suricata-update é a ferramenta oficial para gerenciar fontes de regras:
sudo suricata-update update-sources sudo suricata-update list-sources sudo suricata-update sudo systemctl restart suricata
Após o update, 50.517 regras foram carregadas de 2 arquivos (suricata.rules + local.rules). As regras ficam em /var/lib/suricata/rules/suricata.rules.
Fontes habilitadas: et/open (Emerging Threats), abuse.ch (4 feeds), oisf/trafficid, aleksibovellan/nmap.
sudo suricata-update enable-source aleksibovellan/nmap sudo suricata-update sudo systemctl restart suricata
Regras incluídas nessa fonte:
Todos classificados como Attempted Information Leak, prioridade 2.
Bloco adicionado ao /var/ossec/etc/ossec.conf do agente Kali:
<localfile> <location>/var/log/suricata/eve.json</location> <log_format>json</log_format> </localfile>
Após reiniciar o agente, confirmação nos logs:
sudo tail -50 /var/ossec/logs/ossec.log | grep -i suricata # wazuh-logcollector: INFO: (1950): Analyzing file: '/var/log/suricata/eve.json'
⚠️ Atenção: se aparecer "Log file is duplicated", o bloco foi adicionado duas vezes no ossec.conf. Remover a entrada duplicada e reiniciar o agente.
Diagnóstico: sensor estava em eth1 (10.10.20.0/24), não em eth0 (10.10.10.0/24 — LAN do lab).
grep -A 5 "af-packet:" /etc/suricata/suricata.yaml # af-packet: # - interface: eth1 ← errado
Correção no suricata.yaml:
af-packet: - interface: eth0 # ← correto: LAN do lab sudo systemctl restart suricata
Validação: reteste do ataque nmap e confirmação do alerta no eve.json com in_iface: "eth0".
Arquivo criado em /var/lib/suricata/rules/local.rules e referenciado no suricata.yaml:
rule-files: - suricata.rules - local.rules
Validação de sintaxe antes de aplicar:
sudo suricata -T -c /etc/suricata/suricata.yaml -v 2>&1 | tail -5 # 2 rule files processed. 50517 rules successfully loaded, 0 failed # Configuration provided was successfully loaded.
Resultado após reteste do SQLi no Juice Shop:
{
"alert": {
"signature": "LOCAL SQLi Attempt - OR 1=1 in HTTP Body",
"category": "Web Application Attack",
"signature_id": 9000001
},
"http": { "url": "/rest/user/login", "http_method": "POST" }
}