Operação Segura e Resposta

Duração: 75 minutos (explicação 20, prática guiada 45, verificação 10). Resultados dos TdR trabalhados: Monitorização, análise de tráfego e gestão; Incidentes: contenção, análise, recuperação e relatório.

Objectivos

• Reconhecer numa captura padrões de varrimento, volume anormal e resolução DNS invulgar.
• Separar facto observado de interpretação.
• Registar a análise de forma que outro técnico a possa repetir.

Padrões que merecem atenção

Varrimento: uma origem tenta muitas portas ou muitos endereços em pouco tempo, com muitas respostas RST ou sem resposta. Volume anormal: uma conversa muito acima da linha de base, sobretudo para fora da instituição. DNS invulgar: muitos nomes longos e aleatórios para o mesmo domínio.

Cada padrão tem explicações legítimas (inventário de rede autorizado, cópia de segurança, actualização). A análise separa: o que a captura mostra (facto), o que isso pode significar (hipóteses) e o que falta verificar.

Caso fictício

A linha de base da DPE (fictícia) não tem tráfego da delegação para muitas portas do srv. Hoje o técnico recebeu um ficheiro de captura com esse comportamento.

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).
• Rotas sede–delegação estáticas, como no módulo 3.

Passos

1. Prepare as rotas.

   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.1

2. Consola A: capture no r1 (esperar «listening»).

   sudo ip netns exec r1 tcpdump -ni r1-srv -w /tmp/anom.pcap 'tcp'

3. Consola B: gere um varrimento didáctico de 30 portas no srv de prática e termine a captura.

   sudo ip netns exec pc-del sh -c 'for p in $(seq 1 30); do timeout 1 bash -c "</dev/tcp/10.10.20.53/$p" 2>/dev/null; done'
   Ctrl+C na consola A.

4. Analise: número de SYN por origem, portas tentadas e respostas RST.

   tshark -r /tmp/anom.pcap -Y 'tcp.flags.syn==1 && tcp.flags.ack==0' -T fields -e ip.src | sort | uniq -c
   tshark -r /tmp/anom.pcap -Y 'tcp.flags.syn==1 && tcp.flags.ack==0' -T fields -e tcp.dstport | sort -n | uniq | wc -l
   tshark -r /tmp/anom.pcap -Y 'tcp.flags.reset==1' | wc -l

   Saída de exemplo (didáctica):

        30 10.20.10.10
   30
   30

Critérios de sucesso

• Relatório com três secções: factos (30 SYN de 10.20.10.10 para 30 portas, 30 RST), hipóteses (varrimento; inventário autorizado), verificações pendentes.
• Os comandos usados estão no relatório.

Como desfazer (reversão)

• 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 -f /tmp/anom.pcap

Alternativa em papel: tarefas e respostas esperadas

Separe em «facto» e «interpretação»: «O pc-del atacou o servidor às 10h05 com 30 tentativas».

Facto: às 10h05 houve 30 SYN de 10.20.10.10 para 30 portas do srv. Interpretação (a confirmar): tratar-se de ataque; pode ser inventário autorizado ou equipamento comprometido.

Que três verificações faria a seguir?

Perguntar à delegação se houve inventário autorizado; ver registos e processos do pc-del; comparar com alertas IDS e com a linha de base.

Verifique o que aprendeu

Questão 1

Muitos SYN para portas diferentes, respondidos com RST, indicam:

1. Uma cópia de segurança
2. Um possível varrimento de portas
3. Uma falha de DNS
4. Uma chamada de voz

Questão 2

Porque se incluem os comandos no relatório de análise?

1. Para ficar maior
2. Para que outro técnico possa repetir e verificar a análise
3. Porque é obrigatório por lei
4. Não se incluem

Em leitura fácil

• Procure o que foge ao normal.
• Escreva o que viu, separado do que acha.
• Confirme antes de acusar alguém.

Fontes

• Wireshark — User's Guide e referência de filtros de visualização (https://www.wireshark.org/docs/)
• tcpdump/libpcap — manual tcpdump(1) e pcap-filter(7) (https://www.tcpdump.org/manpages/)
• NIST SP 800-61 Rev. 3 — Incident Response Recommendations (https://csrc.nist.gov/pubs/sp/800/61/r3/final)