Defesa de Redes

Duração: 75 minutos (explicação 20, prática guiada 45, verificação 10). Resultados dos TdR trabalhados: Configurar routers, switches, pontos de acesso e firewalls; IDS/IPS, ACL e segmentação.

Objectivos

• Distinguir filtragem sem estado e com estado.
• Escrever uma política nftables com recusa por omissão e excepções justificadas.
• Aplicar e reverter a política sem perder o acesso de gestão.

Filtragem com estado

Uma firewall com estado acompanha as ligações: se o pedido saiu autorizado, a resposta é aceite porque pertence a uma ligação «established». Assim não é preciso abrir portas altas para as respostas. No nftables usa-se «ct state established,related accept».

Ordem habitual: aceitar ligações estabelecidas; descartar pacotes inválidos; aceitar as excepções da matriz; registar e recusar o resto. Uma política é revista como código: comentário por regra, número do pedido e responsável (NIST SP 800-41).

Não se trancar fora

Ao alterar a firewall de um equipamento remoto, o risco é cortar a própria sessão. Boas práticas: aplicar o ficheiro inteiro de uma vez (nft -f é atómico: ou aplica tudo ou nada), ter consola alternativa e um temporizador que repõe a versão anterior se não houver confirmação.

Caso fictício

A DPE (fictícia) quer que o servidor srv aceite apenas HTTP da Administração e SSH da Gestão, recusando o resto e registando tentativas.

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

Passos

1. Consola C (deixar aberta): sirva a página de teste no srv e espere «Serving HTTP».

   sudo ip netns exec srv python3 -m http.server 80 --bind 10.10.20.53

2. Acrescente as rotas sede–delegação (como no módulo 3), para o teste de recusa ser real.

   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
   sudo ip netns exec pc-del ping -c 1 -W 1 10.10.20.53

   Saída de exemplo (didáctica):

   1 packets transmitted, 1 received

3. Escreva a política no ficheiro /tmp/r1-politica.nft.

   sudo tee /tmp/r1-politica.nft <<'EOF'
   flush ruleset
   table inet filtro {
     chain forward {
       type filter hook forward priority 0; policy drop;
       ct state established,related accept comment "respostas"
       ct state invalid drop
       ip saddr 10.10.10.0/24 ip daddr 10.10.20.53 tcp dport 80 accept comment "Adm->portal, pedido 101"
       ip saddr 10.10.99.0/24 ip daddr 10.10.20.53 tcp dport 22 accept comment "Gestao->SSH, pedido 102"
       log prefix "DPE-recusa: " limit rate 5/minute counter drop
     }
   }
   EOF
   sudo ip netns exec r1 nft -c -f /tmp/r1-politica.nft && echo sintaxe-ok

   Saída de exemplo (didáctica):

   sintaxe-ok

4. Guarde a política actual e aplique a nova com reposição automática em 120 s (consola B).

   sudo ip netns exec r1 nft list ruleset > /tmp/r1-anterior.nft
   sudo ip netns exec r1 nft -f /tmp/r1-politica.nft
   Consola B: sleep 120 && sudo ip netns exec r1 sh -c 'nft flush ruleset; nft -f /tmp/r1-anterior.nft'
   (se tudo estiver bem, cancele o temporizador com Ctrl+C na consola B antes dos 120 s)

5. Teste os fluxos permitidos e recusados.

   sudo ip netns exec pc-adm python3 -c "import urllib.request as u; print(u.urlopen('http://10.10.20.53/', timeout=3).status)"
   sudo ip netns exec pc-del ping -c 1 -W 1 10.10.20.53
   sudo ip netns exec r1 nft list chain inet filtro forward

   Saída de exemplo (didáctica):

   200
   1 packets transmitted, 0 received
   log prefix "DPE-recusa: " limit rate 5/minute counter packets 1 bytes 84 drop

Critérios de sucesso

• HTTP da Administração funciona; o ping da delegação é recusado e contado.
• Cada regra tem comentário com o pedido.
• O formando explica porque nft -f é aplicado de uma vez.

Como desfazer (reversão)

• sudo ip netns exec r1 sh -c 'nft flush ruleset; nft -f /tmp/r1-anterior.nft'
• Ctrl+C na consola C
• 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/r1-politica.nft /tmp/r1-anterior.nft

Alternativa em papel: tarefas e respostas esperadas

Porque é que, com «policy drop», o pc-adm continua a receber a página, se nenhuma regra aceita tráfego do srv para o pc-adm?

A resposta pertence a uma ligação já aceite; a regra «ct state established,related accept» deixa-a passar.

Reescreva a regra de SSH para aceitar só o posto 10.10.99.21.

ip saddr 10.10.99.21 ip daddr 10.10.20.53 tcp dport 22 accept comment "..."

Verifique o que aprendeu

Questão 1

Porque se limita a taxa da regra de registo?

1. Para poupar electricidade
2. Para que um ataque não encha os registos e o disco
3. Porque a lei proíbe registos
4. Para acelerar o ping

Questão 2

Qual é a vantagem de aplicar a política com nft -f de um ficheiro?

1. Fica mais bonita
2. A aplicação é atómica: ou entra tudo ou nada
3. Desliga o registo
4. Não precisa de privilégios

Em leitura fácil

• A firewall deixa passar só o que foi autorizado.
• As respostas a pedidos autorizados passam sozinhas.
• Guarde sempre a versão anterior antes de mudar.

Fontes

• NIST SP 800-41 Rev. 1 — Guidelines on Firewalls and Firewall Policy (https://csrc.nist.gov/pubs/sp/800/41/r1/final)
• Projecto nftables — wiki oficial (https://wiki.nftables.org/)
• 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)