Duração: 80 minutos (explicação 20, prática guiada 50, verificação 10). Resultados dos TdR trabalhados: IDS/IPS, ACL e segmentação; Monitorização, análise de tráfego e gestão.
Objectivos
- Distinguir IDS e IPS, detecção por assinatura e por anomalia.
- Escrever e testar uma regra local Suricata na rede de prática.
- Interpretar um alerta e decidir o passo seguinte sem conclusões precipitadas.
Detectar e prevenir
Um IDS observa uma cópia do tráfego e gera alertas; um IPS está no caminho e pode descartar pacotes. Detecção por assinatura procura padrões conhecidos; por anomalia compara com o comportamento normal (a linha de base do módulo 8).
Um alerta é um indício, não uma prova. Pode ser falso positivo (tráfego legítimo parecido) e a ausência de alerta não prova ausência de ataque (falso negativo). Cada alerta é confirmado com outras fontes: registos, captura, dono do equipamento.
Regras Suricata
Formato: acção protocolo origem porta -> destino porta (opções). Exemplo: alert icmp any any -> 10.10.20.53 any (msg:"..."; itype:8; sid:1000001; rev:1;). Os sid de 1000000 a 1999999 são reservados a regras locais. Regras de terceiros devem vir de fontes oficiais e ser testadas antes de ligar o modo IPS.
Caso fictício
Na DPE (fictícia) suspeita-se de varrimentos vindos da delegação. Antes de bloquear, o técnico quer um alerta fiável.
Prática guiada em rede isolada
Rede de prática fictícia, criada dentro de um computador de prática com o script base (módulo 1, lição 1). Nunca use estes passos na rede de produção nem contra endereços reais. As saídas mostradas são exemplos didácticos, não resultados de uma execução.
Topologia (descrição em texto)
- pc-adm (10.10.10.10) — ligado a r1 pela VLAN 10.
- srv (10.10.20.53) — ligado a r1 pela VLAN 20.
- r1 (encaminhador da sede) — ligado a pc-adm, srv, r2 e isp.
- r2 (encaminhador da delegação) — ligado a r1 e a pc-del (10.20.10.10).
- isp (operador simulado) — ligado a r1 e ao servidor externo 198.51.100.10 (endereço dentro de isp).
- Suricata em modo IDS no r1, a observar a interface r1-r2 (tráfego vindo da delegação).
Passos
Crie rotas estáticas para haver tráfego sede–delegação (como no módulo 3).
sudo ip -n r1 route add 10.20.10.0/24 via 10.255.0.2 sudo ip -n r2 route add default via 10.255.0.1Escreva as regras locais.
mkdir -p /tmp/suri cat > /tmp/suri/local.rules <<'EOF' alert icmp 10.20.10.0/24 any -> 10.10.20.53 any (msg:"DPE pratica: eco ICMP da delegacao ao srv"; itype:8; sid:1000001; rev:1;) alert tcp 10.20.10.0/24 any -> 10.10.20.0/24 any (msg:"DPE pratica: muitos SYN da delegacao"; flags:S,12; threshold: type both, track by_src, count 10, seconds 10; sid:1000002; rev:1;) EOFConsola A: arranque o Suricata só com estas regras e espere a mensagem de motor iniciado.
sudo ip netns exec r1 suricata -i r1-r2 -S /tmp/suri/local.rules -l /tmp/suriSaída de exemplo (didáctica):
... Engine started.Consola B: gere tráfego e leia os alertas.
sudo ip netns exec pc-del ping -c 1 10.10.20.53 sudo ip netns exec pc-del sh -c 'for p in $(seq 20 40); do timeout 1 bash -c "</dev/tcp/10.10.20.53/$p" 2>/dev/null; done' cat /tmp/suri/fast.logSaída de exemplo (didáctica):
[1:1000001:1] DPE pratica: eco ICMP da delegacao ao srv [Classification: (null)] [Priority: 3] {ICMP} 10.20.10.10:8 -> 10.10.20.53:0 [1:1000002:1] DPE pratica: muitos SYN da delegacao [Priority: 3] {TCP} 10.20.10.10:41822 -> 10.10.20.53:29
Critérios de sucesso
- fast.log contém os dois alertas com sid locais.
- O formando escreve em duas linhas o que o alerta prova e o que não prova.
Como desfazer (reversão)
- Ctrl+C na consola A
- sudo ip -n r1 route del 10.20.10.0/24 via 10.255.0.2; sudo ip -n r2 route del default via 10.255.0.1
- rm -rf /tmp/suri
Alternativa em papel: tarefas e respostas esperadas
- O alerta 1000002 apareceu. Liste três verificações antes de bloquear 10.20.10.10.
- Confirmar com o responsável da delegação se há inventário ou teste autorizado; ver registos do srv e captura; verificar se o equipamento é conhecido e se o comportamento se repete.
- Porque é que a regra 1000002 usa threshold?
- Para alertar só quando há 10 SYN em 10 s da mesma origem, evitando um alerta por cada ligação normal.
Verifique o que aprendeu
Questão 1
Um IDS não gerou alertas durante uma semana. O que se pode concluir?
- Não houve ataques
- Nada de definitivo: pode haver falsos negativos ou regras em falta
- O IDS está avariado de certeza
- A rede é segura
Ver resposta comentada
Resposta: Nada de definitivo: pode haver falsos negativos ou regras em falta
A ausência de alerta não prova ausência de ataque; revê-se cobertura das regras e visibilidade.
Questão 2
Diferença essencial entre IDS e IPS:
- O IPS só funciona em Wi-Fi
- O IPS está no caminho e pode descartar; o IDS observa e alerta
- O IDS é sempre mais caro
- Não há diferença
Ver resposta comentada
Resposta: O IPS está no caminho e pode descartar; o IDS observa e alerta
Por estar no caminho, um IPS mal afinado pode bloquear tráfego legítimo; começa-se em modo de detecção.
Em leitura fácil
- O IDS observa e avisa.
- O IPS pode bloquear.
- Um aviso tem de ser confirmado antes de agir.
Fontes
- Suricata — User Guide (OISF) (https://docs.suricata.io/)
- NIST SP 800-61 Rev. 3 — Incident Response Recommendations (https://csrc.nist.gov/pubs/sp/800/61/r3/final)
- Linux iproute2 — páginas de manual ip(8), ip-netns(8), bridge(8), tc(8) (https://man7.org/linux/man-pages/man8/ip.8.html)
