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

• Centralizar registos de vários equipamentos num servidor de prática.
• Filtrar registos por equipamento, gravidade e período.
• Relacionar eventos de fontes diferentes pela hora sincronizada.

Registos centralizados

Cada equipamento gera registos (syslog, RFC 5424) com data, anfitrião, aplicação, gravidade e mensagem. Guardados só no próprio equipamento, perdem-se se ele avariar ou for comprometido. Por isso enviam-se para um servidor central, com retenção definida, acesso restrito e hora sincronizada (NIST SP 800-92).

Os registos contêm dados pessoais (utilizadores, endereços). O acesso é limitado a quem precisa, o período de retenção é aprovado e o tratamento segue a política interna da instituição e a legislação aplicável, confirmada pelo jurista da instituição.

Caso fictício

Após uma queixa de acesso indevido fictícia, a DPE precisa de juntar os registos da firewall do r1 e do servidor srv para o mesmo intervalo de 10 minutos.

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).
• Servidor de registos: rsyslog no srv em 10.10.20.14/24, UDP 514 (como no módulo 5, lição 2).

Passos

1. Prepare o recetor (repetir a configuração do módulo 5) numa consola F aberta.

   sudo ip -n srv addr add 10.10.20.14/24 dev srv-r1
   sudo mkdir -p /tmp/registos
   sudo tee /tmp/rsyslog-srv.conf <<'EOF'
   module(load="imudp")
   input(type="imudp" address="10.10.20.14" port="514")
   template(name="PorAnfitriao" type="string" string="/tmp/registos/%HOSTNAME%.log")
   *.* action(type="omfile" dynaFile="PorAnfitriao")
   EOF
   Consola F: sudo ip netns exec srv rsyslogd -n -f /tmp/rsyslog-srv.conf -i /tmp/rsyslog-srv.pid

2. Envie eventos de teste de dois «equipamentos» com gravidades diferentes.

   sudo ip netns exec r1 logger -n 10.10.20.14 -P 514 -d --rfc5424 -t firewall -p local0.warning --hostname r1 'DPE-recusa: IN=r1-r2 SRC=10.20.10.10 DST=10.10.20.53 DPT=22'
   sudo ip netns exec srv logger -n 10.10.20.14 -P 514 -d --rfc5424 -t sshd -p auth.info --hostname srv 'Connection closed by 10.20.10.10 port 51544'

3. Filtre por equipamento e por endereço suspeito, e ordene pela hora.

   ls /tmp/registos
   grep -h 10.20.10.10 /tmp/registos/*.log | sort

   Saída de exemplo (didáctica):

   r1.log  srv.log
   2026-09-28T10:02:11+02:00 r1 firewall - DPE-recusa: IN=r1-r2 SRC=10.20.10.10 DST=10.10.20.53 DPT=22
   2026-09-28T10:02:14+02:00 srv sshd - Connection closed by 10.20.10.10 port 51544

Critérios de sucesso

• Há um ficheiro por equipamento.
• A linha do tempo junta os dois eventos na ordem certa.
• O formando explica porque a hora sincronizada é condição para esta análise.

Como desfazer (reversão)

• Ctrl+C na consola F
• sudo rm -rf /tmp/registos /tmp/rsyslog-srv.conf
• sudo ip -n srv addr del 10.10.20.14/24 dev srv-r1

Alternativa em papel: tarefas e respostas esperadas

Com as duas linhas de exemplo, escreva a linha do tempo e uma hipótese.

10:02:11 firewall recusa SSH de 10.20.10.10 para o srv; 10:02:14 o srv regista ligação fechada da mesma origem. Hipótese: tentativa de SSH vinda da delegação; confirmar com o responsável e ver se a regra está correcta.

Indique três regras de acesso ao servidor de registos.

Só a equipa de TI autorizada lê; ninguém apaga ou altera (só acrescentar); retenção definida e aprovada; cópia protegida.

Verifique o que aprendeu

Questão 1

Porque se enviam registos para um servidor central?

1. Para ocupar espaço
2. Para não os perder se o equipamento falhar ou for comprometido, e para os correlacionar
3. Porque o syslog o exige
4. Para os publicar

Questão 2

Dois registos de equipamentos diferentes têm horas que não batem certo por 7 minutos. Causa mais provável?

1. Ataque
2. Relógios não sincronizados
3. Cabo partido
4. Firewall

Em leitura fácil

• Todos os equipamentos enviam os registos para um só lugar.
• A hora tem de estar certa em todos.
• Só pessoas autorizadas lêem os registos.

Fontes

• IETF RFC 5424 — The Syslog Protocol (https://www.rfc-editor.org/rfc/rfc5424)
• rsyslog — documentação oficial (https://www.rsyslog.com/doc/)
• NIST SP 800-92 — Guide to Computer Security Log Management (https://csrc.nist.gov/pubs/sp/800/92/final)