Redes Avançadas e Introdução à Segurança Cibernética

Duração: 70 minutos (explicação 20, prática guiada 40, verificação 10). Resultados dos TdR trabalhados: Conceber, configurar e administrar redes pequenas, médias e grandes; Competências profissionais e de formador replicador.

Objectivos

• Explicar as camadas do modelo TCP/IP e a sua correspondência com o modelo OSI.
• Identificar, numa captura, cabeçalhos Ethernet, IP e TCP/UDP de um mesmo pacote.
• Criar e desfazer a rede de prática isolada usada em todo o curso.

Porque se fala em camadas

Uma comunicação em rede é dividida em funções independentes. Cada camada resolve um problema e entrega o resultado à camada seguinte: a aplicação produz dados; o transporte (TCP ou UDP) separa conversas por portas; a rede (IP) leva o pacote de um endereço a outro, atravessando encaminhadores; a ligação (Ethernet, Wi-Fi) leva a trama ao vizinho seguinte; a camada física transforma bits em sinal eléctrico, luz ou rádio.

O modelo OSI tem sete camadas (física, ligação de dados, rede, transporte, sessão, apresentação, aplicação); o modelo TCP/IP, usado na prática, junta as três superiores numa camada de aplicação. O OSI continua útil como vocabulário de diagnóstico: dizer «o problema é de camada 2» significa que a trama não chega ao vizinho, mesmo que o endereço IP esteja certo.

Encapsulamento

Quando o pc-adm pede uma página ao servidor, o pedido HTTP é colocado num segmento TCP (porta de destino 80), este num pacote IP (origem 10.10.10.10, destino 10.10.20.53) e este numa trama Ethernet (endereços MAC do pc-adm e do r1). Em cada encaminhador a trama é substituída por outra; o pacote IP mantém origem e destino (salvo NAT, módulo 3).

Esta ideia explica porque é que o endereço MAC muda em cada troço e o IP não, e porque é que um filtro de firewall pode decidir por endereço IP (camada 3) ou por porta (camada 4).

Caso fictício

Na DPE (fictícia), o técnico Manuel recebe a queixa «a internet não funciona» vinda da Administração. Sem método, reinicia o encaminhador e interrompe toda a sede. Nesta lição a turma aprende a descrever o problema por camadas antes de agir.

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. Numa máquina virtual Debian 12 descartável e isolada, guarde e corra primeiro a pré-verificação lab-verificar.sh. Só avance se terminar com «Pré-verificação OK» (sem colisões de nomes nem dependências em falta).

   #!/bin/sh
   # lab-verificar.sh — pré-verificação da rede de prática DPE (fictícia).
   # Não cria nem apaga nada. Termina com código 1 se houver colisão ou dependência em falta.
   erro=0
   [ "$(id -u)" = 0 ] || { echo 'Executar como root na VM de prática.'; exit 1; }
   if systemd-detect-virt -q 2>/dev/null; then echo "Virtualização: $(systemd-detect-virt)"; else echo 'AVISO: não parece ser uma máquina virtual. Use uma VM descartável.'; erro=1; fi
   for n in pc-adm srv r1 r2 pc-del isp; do
     if ip netns list | awk '{print $1}' | grep -qx "$n"; then echo "Colisão: espaço de nomes $n já existe."; erro=1; fi
   done
   for d in ip tcpdump tshark python3 nft; do command -v $d >/dev/null || { echo "Em falta: $d"; erro=1; }; done
   echo 'Pacotes Debian 12 necessários (instalar a partir de espelho/cópia local aprovada, antes da aula): iproute2 tcpdump tshark python3 nftables. Opcionais por lição: frr kea-dhcp4-server bind9 rsyslog chrony wireguard-tools suricata iperf3 snmp arping traceroute.'
   [ $erro = 0 ] && echo 'Pré-verificação OK.' || echo 'Pré-verificação FALHOU: corrigir antes de criar a rede.'
   exit $erro

2. Guarde o script base num ficheiro lab-base.sh, torne-o executável e corra-o como administrador do computador de prática.

   #!/bin/sh
   # lab-base.sh — rede de prática isolada DPE (fictícia). Só em computador de prática.
   set -e
   for n in pc-adm srv r1 r2 pc-del isp; do ip netns add $n; done
   ligar() { ip link add $1-$2 type veth peer name $2-$1; ip link set $1-$2 netns $1; ip link set $2-$1 netns $2; }
   ligar pc-adm r1; ligar srv r1; ligar r1 r2; ligar r2 pc-del; ligar r1 isp
   ip -n pc-adm addr add 10.10.10.10/24 dev pc-adm-r1
   ip -n r1 addr add 10.10.10.1/24 dev r1-pc-adm
   ip -n srv addr add 10.10.20.53/24 dev srv-r1
   ip -n r1 addr add 10.10.20.1/24 dev r1-srv
   ip -n r1 addr add 10.255.0.1/30 dev r1-r2
   ip -n r2 addr add 10.255.0.2/30 dev r2-r1
   ip -n r2 addr add 10.20.10.1/24 dev r2-pc-del
   ip -n pc-del addr add 10.20.10.10/24 dev pc-del-r2
   ip -n r1 addr add 203.0.113.2/24 dev r1-isp
   ip -n isp addr add 203.0.113.1/24 dev isp-r1
   ip -n isp addr add 198.51.100.10/32 dev lo
   for n in pc-adm srv r1 r2 pc-del isp; do ip -n $n link set lo up; for i in $(ip -n $n -o link show | awk -F': ' '{print $2}' | cut -d@ -f1 | grep -v '^lo$'); do ip -n $n link set $i up; done; done
   ip netns exec r1 sysctl -qw net.ipv4.ip_forward=1
   ip netns exec r2 sysctl -qw net.ipv4.ip_forward=1
   ip -n pc-adm route add default via 10.10.10.1
   ip -n srv route add default via 10.10.20.1
   ip -n pc-del route add default via 10.20.10.1
   echo 'Rede DPE criada (sem rotas entre sede e delegação: ver módulo 3).'
   
   # depois de guardar:
   chmod +x lab-base.sh && sudo ./lab-base.sh

3. Guarde também o script de reversão lab-remover.sh.

   #!/bin/sh
   # lab-remover.sh — limpa apenas os espaços de nomes da rede de prática DPE.
   for n in pc-adm srv r1 r2 pc-del isp; do
     ip netns list | awk '{print $1}' | grep -qx "$n" || continue
     for p in $(ip netns pids $n); do echo "$n: a terminar PID $p ($(cat /proc/$p/comm 2>/dev/null))"; kill -TERM $p; done
     sleep 2
     resto=$(ip netns pids $n)
     if [ -n "$resto" ]; then echo "$n: ainda activos: $resto — verifique manualmente (kill -KILL <PID>) e volte a correr."; continue; fi
     ip netns del $n && echo "$n: apagado"
   done
   echo 'Espaços de nomes extra criados em lições (t1..t3, sw, rt, a1, s1, vis, casa, sa..sc) têm reversão própria em cada lição.'
   echo 'NÃO é reversão total: ficheiros em /tmp criados pelas lições e pacotes instalados na VM não são removidos por este script; confira a secção «Reverter» de cada lição. A forma segura de repor tudo é descartar a VM.'

4. Confirme os espaços de nomes criados e o endereço do pc-adm.

   sudo ip netns list
   sudo ip -n pc-adm -brief addr

   Saída de exemplo (didáctica):

   pc-adm-r1@if5   UP   10.10.10.10/24
   lo              UNKNOWN 127.0.0.1/8 ::1/128

5. Numa segunda consola, capture no r1 enquanto o pc-adm envia um ping ao servidor.

   sudo ip netns exec r1 tcpdump -ni r1-pc-adm -e -c 2 icmp
   sudo ip netns exec pc-adm ping -c 1 10.10.20.53

   Saída de exemplo (didáctica):

   aa:aa:aa:00:00:10 > aa:aa:aa:00:00:01, ethertype IPv4 (0x0800), length 98: 10.10.10.10 > 10.10.20.53: ICMP echo request
   aa:aa:aa:00:00:01 > aa:aa:aa:00:00:10, ethertype IPv4 (0x0800), length 98: 10.10.20.53 > 10.10.10.10: ICMP echo reply

6. Identifique na saída o que pertence à camada 2 (endereços MAC, ethertype) e à camada 3 (endereços IP). Os MAC reais do seu computador serão diferentes dos do exemplo.

Critérios de sucesso

• O comando ip netns list mostra os seis espaços de nomes.
• O ping do pc-adm ao srv recebe resposta (o r1 encaminha entre as duas redes).
• O formando aponta correctamente, na captura, os campos de camada 2 e de camada 3.

Como desfazer (reversão)

• sudo ./lab-remover.sh termina os processos de cada espaço de nomes do laboratório (PID a PID) e só depois apaga esses espaços de nomes; se algum processo resistir, o script avisa e não apaga.
• Não é reversão total: ficheiros em /tmp e pacotes instalados ficam; a forma segura de repor tudo é descartar a máquina virtual.

Alternativa em papel: tarefas e respostas esperadas

Ordene de cima para baixo as camadas TCP/IP e diga a unidade de dados de cada uma.

Aplicação (dados/mensagem); transporte (segmento TCP ou datagrama UDP); rede/Internet (pacote); ligação (trama); física (bits).

Na saída de exemplo do passo 4, que campo muda quando o pacote passa do r1 para o srv?

Os endereços MAC (nova trama no troço r1–srv). Os endereços IP 10.10.10.10 e 10.10.20.53 mantêm-se.

Reescreva a queixa «a internet não funciona» em três perguntas por camadas.

Física/ligação: o cabo ou o Wi-Fi está ligado e com ligação? Rede: o computador tem endereço e alcança a porta 10.10.10.1? Aplicação: o nome do sítio resolve (DNS) e o serviço responde?

Verifique o que aprendeu

Questão 1

Um pacote vai do pc-adm (10.10.10.10) ao srv (10.10.20.53) passando pelo r1. O que se mantém de ponta a ponta?

1. Os endereços MAC de origem e destino
2. Os endereços IP de origem e destino
3. O número da VLAN
4. Nada se mantém

Questão 2

Um utilizador tem endereço IP correcto mas o cabo está partido. Em que camada está o problema?

1. Aplicação
2. Transporte
3. Física
4. Rede

Em leitura fácil

• A rede funciona por andares, chamados camadas.
• Cada andar faz um trabalho: o cabo leva sinal, o IP leva o pacote ao destino, a aplicação mostra a página.
• Quando algo falha, veja primeiro o andar de baixo.

Fontes

• IETF RFC 791 — Internet Protocol (https://www.rfc-editor.org/rfc/rfc791)
• IETF RFC 1918 — Address Allocation for Private Internets (https://www.rfc-editor.org/rfc/rfc1918)
• IETF RFC 5737 — IPv4 Address Blocks Reserved for Documentation (https://www.rfc-editor.org/rfc/rfc5737)
• 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)
• tcpdump/libpcap — manual tcpdump(1) e pcap-filter(7) (https://www.tcpdump.org/manpages/)

Duração: 75 minutos (explicação 20, prática guiada 45, verificação 10). Resultados dos TdR trabalhados: Conceber, configurar e administrar redes pequenas, médias e grandes; Documentação: diagramas, procedimentos (SOP) e contingência.

Objectivos

• Calcular rede, difusão, primeiro e último endereço úteis de um prefixo IPv4.
• Dividir um bloco em sub-redes de tamanhos diferentes (VLSM) sem sobreposição.
• Ler um endereço IPv6 abreviado e o prefixo /64 habitual numa rede local.

Prefixo e máscara

Um endereço IPv4 tem 32 bits. O prefixo /24 diz que os primeiros 24 bits identificam a rede e os 8 restantes os equipamentos: 2^8 = 256 endereços, dos quais 254 úteis (retira-se o endereço de rede e o de difusão). A máscara equivalente é 255.255.255.0.

Para /26 sobram 6 bits: 64 endereços, 62 úteis. Os blocos /26 começam de 64 em 64: .0, .64, .128, .192. Em /30 há 4 endereços e 2 úteis — usado em ligações ponto a ponto como a 10.255.0.0/30 entre r1 e r2.

Planear sem sobreposição

Ordena-se as necessidades da maior para a menor e reserva-se cada bloco no próximo limite livre. Deixar espaço para crescer é decisão de concepção: uma VLAN com 50 pessoas hoje merece /25 ou /24 se a instituição vai crescer.

IPv6 tem 128 bits. Numa rede local o prefixo recomendado e habitual é /64 (RFC 7421), exigido pela autoconfiguração SLAAC (RFC 4862); ligações ponto-a-ponto podem usar /127 (RFC 6164). O endereço 2001:db8:10:10::1 abrevia 2001:0db8:0010:0010:0000:0000:0000:0001: zeros à esquerda caem e uma sequência de grupos a zero passa a «::» uma única vez.

Caso fictício

A delegação da DPE (fictícia) vai abrir uma sala de formação com 40 computadores, um balcão com 12 postos e 6 câmaras. O técnico recebe o bloco 10.20.0.0/22 e deve propor um plano sem sobreposições, com margem.

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-del (10.20.10.10/24) ligado a r2 (10.20.10.1/24). Nesta prática acrescentam-se endereços secundários a r2 para testar os cálculos.

Passos

1. Com o script base activo, use o módulo ipaddress do Python para conferir o seu cálculo de 10.20.10.64/26.

   python3 -c "import ipaddress as i; n=i.ip_network('10.20.10.64/26'); print(n.network_address, n.broadcast_address, list(n.hosts())[0], list(n.hosts())[-1], n.num_addresses)"

   Saída de exemplo (didáctica):

   10.20.10.64 10.20.10.127 10.20.10.65 10.20.10.126 64

2. Verifique se dois blocos se sobrepõem antes de os atribuir.

   python3 -c "import ipaddress as i; print(i.ip_network('10.20.0.0/26').overlaps(i.ip_network('10.20.0.32/27')))"

   Saída de exemplo (didáctica):

   True

3. Atribua ao r2 um endereço de teste numa nova sub-rede e confirme a rota ligada que o sistema cria.

   sudo ip -n r2 addr add 10.20.12.1/26 dev r2-pc-del
   sudo ip -n r2 route show 10.20.12.0/26

   Saída de exemplo (didáctica):

   10.20.12.0/26 dev r2-pc-del proto kernel scope link src 10.20.12.1

4. Acrescente um endereço IPv6 de documentação ao pc-adm e leia-o na forma abreviada.

   sudo ip -n pc-adm -6 addr add 2001:db8:10:10::10/64 dev pc-adm-r1
   sudo ip -n pc-adm -6 -brief addr

   Saída de exemplo (didáctica):

   pc-adm-r1@if5  UP  2001:db8:10:10::10/64 fe80::a8aa:aaff:fe00:10/64

Critérios de sucesso

• O plano do caso usa 10.20.0.0/26 (sala, 62 úteis), 10.20.0.64/27 (balcão, 30 úteis) e 10.20.0.96/28 (câmaras, 14 úteis), ou outra solução sem sobreposição e com margem justificada.
• Os cálculos manuais coincidem com a verificação em Python.

Como desfazer (reversão)

• sudo ip -n r2 addr del 10.20.12.1/26 dev r2-pc-del
• sudo ip -n pc-adm -6 addr del 2001:db8:10:10::10/64 dev pc-adm-r1

Alternativa em papel: tarefas e respostas esperadas

Para 10.10.30.128/25 indique rede, difusão, primeiro e último úteis.

Rede 10.10.30.128; difusão 10.10.30.255; primeiro útil 10.10.30.129; último útil 10.10.30.254; 126 úteis.

Proponha o plano do caso a partir de 10.20.0.0/22.

Sala 40 → /26 (10.20.0.0/26); balcão 12 → /28 dá só 14 úteis, sem margem, por isso /27 (10.20.0.64/27); câmaras 6 → /28 (10.20.0.96/28); resto do /22 reservado para crescimento. Aceitar alternativas sem sobreposição e justificadas.

Escreva por extenso 2001:db8:10:10::1.

2001:0db8:0010:0010:0000:0000:0000:0001.

Verifique o que aprendeu

Questão 1

Quantos endereços úteis tem uma rede /27?

1. 32
2. 30
3. 62
4. 14

Questão 2

O técnico quer dar 10.20.0.32/27 ao balcão, mas a sala já tem 10.20.0.0/26. O que acontece?

1. Nada, são redes diferentes
2. Há sobreposição: 10.20.0.32–63 pertence às duas
3. Só há problema em IPv6
4. O encaminhador escolhe automaticamente

Em leitura fácil

• O número depois da barra (/24, /26) diz o tamanho da rede.
• Quanto maior o número, mais pequena a rede.
• Duas redes não podem usar os mesmos endereços.

Fontes

• IETF RFC 4632 — Classless Inter-domain Routing (CIDR) (https://www.rfc-editor.org/rfc/rfc4632)
• IETF RFC 1918 — Address Allocation for Private Internets (https://www.rfc-editor.org/rfc/rfc1918)
• IETF RFC 3849 — IPv6 Address Prefix Reserved for Documentation (https://www.rfc-editor.org/rfc/rfc3849)
• IETF RFC 8200 — Internet Protocol, Version 6 (IPv6) (https://www.rfc-editor.org/rfc/rfc8200)
• Python 3 — módulo ipaddress e subprocess (documentação oficial) (https://docs.python.org/3/library/ipaddress.html)
• 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)
• IETF RFC 7421 — Analysis of the 64-bit Boundary in IPv6 Addressing (https://www.rfc-editor.org/rfc/rfc7421)
• IETF RFC 4862 — IPv6 Stateless Address Autoconfiguration (https://www.rfc-editor.org/rfc/rfc4862)
• IETF RFC 6164 — Using 127-Bit IPv6 Prefixes on Inter-Router Links (https://www.rfc-editor.org/rfc/rfc6164)

Duração: 75 minutos (explicação 20, prática guiada 45, verificação 10). Resultados dos TdR trabalhados: Conceber, configurar e administrar redes pequenas, médias e grandes; Configurar routers, switches, pontos de acesso e firewalls; LAN, WAN, WLAN, virtualização e nuvem.

Objectivos

• Distinguir cabo de cobre, fibra óptica e rádio pelas distâncias e usos.
• Explicar a função de comutador, encaminhador, ponto de acesso e firewall.
• Ler o estado físico de uma interface e o seu débito negociado.

Meios físicos

O cabo de par entrançado de cobre (categorias 5e, 6, 6A) serve ligações Ethernet até 100 metros por troço; a fibra multimodo serve centenas de metros dentro de um edifício ou campus; a fibra monomodo serve quilómetros, entre edifícios ou até ao operador. O rádio (Wi-Fi) liberta do cabo mas partilha o meio e sofre interferência (módulo 4).

Na escolha pesam distância, interferência eléctrica (a fibra não a sofre), custo, protecção contra raios entre edifícios e manutenção disponível no distrito.

Equipamentos e as suas camadas

Comutador (switch): liga equipamentos da mesma rede local e decide por endereço MAC (camada 2); os comutadores geridos permitem VLAN. Encaminhador (router): liga redes diferentes e decide por endereço IP (camada 3). Ponto de acesso: ponte entre rádio e cabo. Firewall: decide que tráfego passa entre zonas, por endereços, portas e estado das ligações.

Cada fabricante tem a sua linguagem de configuração; os conceitos são os mesmos. Neste curso usa-se Linux, que faz de comutador (bridge), encaminhador e firewall (nftables), porque é gratuito e as ideias transferem-se para qualquer equipamento.

Caso fictício

A DPE (fictícia) vai ligar um novo armazém a 350 metros da sede. Um fornecedor propõe cabo de cobre entre os edifícios. O técnico deve responder com uma alternativa fundamentada.

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)

• Rede base. Nesta prática cria-se uma ponte Linux (comutador virtual) br-lab no r1 e ligam-se dois postos de teste.

Passos

1. Veja o estado de uma interface: estado da ligação e tipo.

   sudo ip -n r1 -details link show r1-pc-adm

   Saída de exemplo (didáctica):

   3: r1-pc-adm@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
       link/ether aa:aa:aa:00:00:01 brd ff:ff:ff:ff:ff:ff link-netns pc-adm
       veth

2. Num computador físico com placa Ethernet (não na rede de prática), o débito negociado lê-se com ethtool. Aqui só se mostra o exemplo.

   Saída de exemplo (didáctica):

   Speed: 1000Mb/s
   Duplex: Full
   Link detected: yes

3. Crie um comutador virtual no r1 e dois postos de teste ligados a ele.

   sudo ip netns add t1; sudo ip netns add t2
   sudo ip -n r1 link add br-lab type bridge
   for t in t1 t2; do sudo ip link add $t-br type veth peer name br-$t; sudo ip link set $t-br netns $t; sudo ip link set br-$t netns r1; sudo ip -n r1 link set br-$t master br-lab up; done
   sudo ip -n r1 link set br-lab up
   sudo ip -n t1 addr add 192.168.50.1/24 dev t1-br; sudo ip -n t1 link set t1-br up
   sudo ip -n t2 addr add 192.168.50.2/24 dev t2-br; sudo ip -n t2 link set t2-br up
   sudo ip netns exec t1 ping -c 2 192.168.50.2

4. Veja a tabela de endereços MAC que o comutador aprendeu.

   sudo ip netns exec r1 bridge fdb show br br-lab | grep -v permanent

   Saída de exemplo (didáctica):

   aa:bb:cc:00:00:01 dev br-t1 master br-lab
   aa:bb:cc:00:00:02 dev br-t2 master br-lab

Critérios de sucesso

• t1 e t2 comunicam através de br-lab sem nenhum encaminhamento IP.
• A tabela fdb mostra um MAC aprendido em cada porta.

Como desfazer (reversão)

• sudo ip netns del t1; sudo ip netns del t2; sudo ip -n r1 link del br-lab

Alternativa em papel: tarefas e respostas esperadas

Responda ao fornecedor do caso.

350 m excede os 100 m do cobre Ethernet por troço; entre edifícios o cobre também conduz sobretensões. Propor fibra (multimodo serve a distância com os débitos habituais; monomodo se houver previsão de maior distância), com conversores ou portas ópticas nos comutadores.

Classifique: switch, router, ponto de acesso, firewall — que endereço usa cada um para decidir?

Switch: MAC (camada 2). Router: IP (camada 3). Ponto de acesso: ponte rádio–cabo (camada 2). Firewall: IP, portas e estado (camadas 3–4, às vezes 7).

Na saída do passo 1, o que indica LOWER_UP?

Que a camada física/ligação está activa (há portadora). UP sozinho indica só que a interface foi activada administrativamente.

Verifique o que aprendeu

Questão 1

Qual o meio mais adequado para ligar dois edifícios a 2 km?

1. Cabo categoria 6
2. Fibra monomodo
3. Cabo telefónico
4. Wi-Fi doméstico

Questão 2

Dois computadores na mesma rede comunicam através de um comutador. O comutador precisa de rota IP?

1. Sim, sempre
2. Não, decide por endereço MAC
3. Só em IPv6
4. Só se tiver firewall

Em leitura fácil

• Cabo de cobre: curto, até 100 metros.
• Fibra: longe e sem interferência.
• Comutador liga computadores; encaminhador liga redes.

Fontes

• 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)
• IEEE 802.1Q — Bridges and Bridged Networks (VLAN, STP/RSTP) (https://standards.ieee.org/ieee/802.1Q/)
• IEEE 802.11 — Wireless LAN (https://standards.ieee.org/ieee/802.11/)

Duração: 80 minutos (explicação 20, prática guiada 50, verificação 10). Resultados dos TdR trabalhados: Serviços de rede: DHCP, DNS, VPN, NAT, VLAN e autenticação; Monitorização, análise de tráfego e gestão.

Objectivos

• Explicar ARP, ICMP, TCP, UDP, DNS e DHCP e em que momento cada um aparece.
• Reconhecer numa captura o aperto de mão TCP (SYN, SYN-ACK, ACK).
• Aplicar filtros de captura e de visualização simples.

Os protocolos de todos os dias

ARP descobre o MAC correspondente a um IP na mesma rede. ICMP transporta mensagens de controlo (eco para o ping, «destino inalcançável», «tempo excedido» usado pelo traceroute). TCP garante entrega ordenada e fiável, com ligação estabelecida por três mensagens (RFC 9293); UDP envia sem ligação, sem confirmação nem retransmissão (RFC 768). Por não esperar confirmações, UDP tem menos atraso de arranque e é adequado a consultas curtas (DNS) e a voz e vídeo em tempo real; não é, por si, «mais rápido» em débito — a fiabilidade, se necessária, passa para a aplicação.

DNS traduz nomes em endereços (porta 53). DHCP entrega automaticamente endereço, máscara, porta de ligação e servidores DNS (portas 67/68). Serão configurados no módulo 5.

Ver para perceber

tcpdump e Wireshark/tshark mostram os pacotes. Filtro de captura (sintaxe pcap) reduz o que se grava: «tcp port 80». Filtro de visualização (Wireshark) escolhe o que se mostra: «tcp.flags.syn == 1». Capturas podem conter dados pessoais: só em rede de prática ou com autorização.

Caso fictício

O pc-adm da DPE (fictícia) demora a abrir a intranet. O técnico quer saber se o atraso está na resolução do nome ou na ligação TCP.

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. Ponha um serviço web simples no srv (servidor de teste do Python, só para a prática).

   Consola C (deixar aberta): sudo ip netns exec srv python3 -m http.server 80 --bind 10.10.20.53
   Esperar a linha «Serving HTTP on 10.10.20.53 port 80» antes do passo seguinte.

2. Limpe a cache ARP do pc-adm e capture ARP e TCP no r1 durante um pedido.

   Consola B: sudo ip -n pc-adm neigh flush all
   Consola A: sudo ip netns exec r1 tcpdump -ni r1-pc-adm -w /tmp/m1l4.pcap 'arp or tcp port 80'
   Esperar na consola A a linha «tcpdump: listening on r1-pc-adm» antes de continuar.
   Consola B: sudo ip netns exec pc-adm python3 -c "import urllib.request as u; print(u.urlopen('http://10.10.20.53/').status)"
   Consola A: terminar a captura com Ctrl+C (termina apenas este tcpdump e fecha o ficheiro).

   Saída de exemplo (didáctica):

   Consola A: tcpdump: listening on r1-pc-adm, link-type EN10MB (Ethernet), snapshot length 262144 bytes
   Consola B: 200

3. Leia a captura com tshark.

   tshark -r /tmp/m1l4.pcap -Y 'arp || tcp.flags.syn==1 || (tcp.flags==0x010 && tcp.seq==1 && tcp.ack==1 && tcp.len==0)' -T fields -e frame.number -e _ws.col.Info

   Saída de exemplo (didáctica):

   1  Who has 10.10.10.1? Tell 10.10.10.10
   2  10.10.10.1 is at aa:aa:aa:00:00:01
   3  50412 → 80 [SYN] Seq=0
   4  80 → 50412 [SYN, ACK] Seq=0 Ack=1
   5  50412 → 80 [ACK] Seq=1 Ack=1 Len=0

4. Nota sobre o filtro: tcp.flags.syn==1 sozinho mostra só SYN e SYN-ACK; o ACK final do aperto de mão não tem SYN, por isso acrescenta-se a condição «só ACK, números relativos 1/1, sem dados». Números de sequência relativos são o comportamento por omissão do Wireshark/tshark.

5. Compare com um pedido DNS em UDP (será configurado no módulo 5): identifique na tabela do papel as diferenças TCP/UDP.

Critérios de sucesso

• O formando identifica ARP antes do TCP e o aperto de mão SYN, SYN-ACK, ACK.
• O ficheiro de captura é apagado no fim.

Como desfazer (reversão)

• Na consola C, terminar o servidor de teste com Ctrl+C (termina só esse processo).
• rm -f /tmp/m1l4.pcap

Alternativa em papel: tarefas e respostas esperadas

Porque aparece ARP antes do TCP na captura?

O pc-adm precisa do MAC da porta de ligação 10.10.10.1 para construir a trama; o destino 10.10.20.53 está noutra rede, por isso pergunta pelo MAC do r1, não do srv.

Complete: DNS usa ___ porta ___; DHCP usa ___ portas ___.

DNS: porta 53, normalmente UDP para consultas; TCP é também obrigatório de suportar (RFC 7766) e usa-se, por exemplo, quando a resposta é truncada, em transferências de zona e com DNS sobre TLS (porta 853). DHCP: UDP portas 67 (servidor) e 68 (cliente).

Escreva um filtro de captura para apanhar só tráfego do pc-adm para a porta 443.

src host 10.10.10.10 and tcp dst port 443

Verifique o que aprendeu

Questão 1

O traceroute mostra os saltos porque os encaminhadores devolvem:

1. TCP RST
2. ICMP «tempo excedido»
3. ARP reply
4. DHCP ACK

Questão 2

Qual protocolo é mais indicado para uma chamada de voz?

1. TCP, porque garante entrega
2. UDP, porque um atraso de retransmissão é pior que uma pequena perda
3. ARP
4. ICMP

Em leitura fácil

• ARP pergunta: quem tem este endereço?
• TCP confirma que os dados chegaram.
• UDP não confirma: serve para mensagens curtas e para voz ou vídeo ao vivo.
• DNS troca nomes por números.

Fontes

• IETF RFC 826 — An Ethernet Address Resolution Protocol (https://www.rfc-editor.org/rfc/rfc826)
• IETF RFC 792 — Internet Control Message Protocol (https://www.rfc-editor.org/rfc/rfc792)
• IETF RFC 9293 — Transmission Control Protocol (https://www.rfc-editor.org/rfc/rfc9293)
• IETF RFC 768 — User Datagram Protocol (https://www.rfc-editor.org/rfc/rfc768)
• IETF RFC 1034/1035 — Domain Names (https://www.rfc-editor.org/rfc/rfc1034)
• IETF RFC 7766 — DNS Transport over TCP (https://www.rfc-editor.org/rfc/rfc7766)
• IETF RFC 2131 — Dynamic Host Configuration Protocol (https://www.rfc-editor.org/rfc/rfc2131)
• tcpdump/libpcap — manual tcpdump(1) e pcap-filter(7) (https://www.tcpdump.org/manpages/)
• Wireshark — User's Guide e referência de filtros de visualização (https://www.wireshark.org/docs/)

Duração: 80 minutos (explicação 20, prática guiada 50, verificação 10). Resultados dos TdR trabalhados: Diagnóstico, desempenho e disponibilidade; Documentação: diagramas, procedimentos (SOP) e contingência.

Objectivos

• Aplicar um método de diagnóstico de baixo para cima, com hipótese e prova.
• Usar ip, ping, traceroute e ss para localizar a falha.
• Registar o diagnóstico numa ficha curta reutilizável.

Método antes de ferramenta

1) Descrever o sintoma com factos (quem, onde, desde quando, o que funciona). 2) Verificar camada física/ligação (estado da interface). 3) Verificar configuração IP (endereço, máscara, porta de ligação). 4) Alcançar a porta de ligação, depois o destino, depois o nome. 5) Verificar o serviço (porta aberta). 6) Mudar uma coisa de cada vez, provar, registar.

Mudar várias coisas ao mesmo tempo esconde a causa e pode criar novas falhas. Reiniciar sem diagnóstico pode apagar a evidência.

Caso fictício

Três queixas na DPE (fictícia): o pc-adm «não chega a nada», a delegação não chega à sede e o servidor web «está em baixo». O formador provoca as três avarias na rede de prática e as duplas encontram-nas.

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. Formador: provoque a avaria 1 (porta de ligação errada no pc-adm).

   sudo ip -n pc-adm route replace default via 10.10.10.254

2. Duplas: diagnostique de baixo para cima.

   sudo ip -n pc-adm -brief link
   sudo ip -n pc-adm -brief addr
   sudo ip -n pc-adm route
   sudo ip netns exec pc-adm ping -c 2 10.10.10.1
   sudo ip netns exec pc-adm ping -c 2 10.10.20.53

   Saída de exemplo (didáctica):

   default via 10.10.10.254 dev pc-adm-r1
   ... 10.10.10.1: 2 packets transmitted, 2 received
   ... 10.10.20.53: From 10.10.10.10 icmp_seq=1 Destination Host Unreachable

3. Avaria 2: não há rotas entre sede e delegação (estado do script base). Confirme com traceroute a partir do pc-del.

   sudo ip netns exec pc-del traceroute -n 10.10.20.53

   Saída de exemplo (didáctica):

    1  10.20.10.1  0.05 ms
    2  * * *

4. Avaria 3: o serviço web não está a escutar. Verifique as portas abertas no srv.

   sudo ip netns exec srv ss -ltn

   Saída de exemplo (didáctica):

   State  Recv-Q Send-Q Local Address:Port Peer Address:Port

5. Corrija só a avaria 1 e prove; a avaria 2 resolve-se no módulo 3.

   sudo ip -n pc-adm route replace default via 10.10.10.1
   sudo ip netns exec pc-adm ping -c 2 10.10.20.53

Critérios de sucesso

• Cada dupla escreve, para cada avaria, a camada, a prova e a correcção proposta.
• Nenhuma correcção é feita sem hipótese escrita.

Como desfazer (reversão)

• sudo ip -n pc-adm route replace default via 10.10.10.1
• Ou reconstruir tudo: sudo ./lab-remover.sh && sudo ./lab-base.sh

Alternativa em papel: tarefas e respostas esperadas

Avaria 1: que prova mostra que o problema é a porta de ligação?

A rota por omissão aponta para 10.10.10.254 (inexistente), o ping a 10.10.10.1 funciona (ligação e endereço correctos) e o ping para outra rede falha com «Destination Host Unreachable».

Avaria 2: o que significa «* * *» no segundo salto?

O r2 recebe o pacote mas não tem rota para 10.10.20.0/24 (ou as respostas não voltam); o problema é de encaminhamento entre r2 e r1.

Preencha a ficha: sintoma / camada / prova / correcção / verificação / quem e quando.

Ex.: «pc-adm sem acesso a outras redes» / 3 / rota por omissão 10.10.10.254 / corrigir para 10.10.10.1 / ping 10.10.20.53 com resposta / nome do técnico, data e hora.

Verifique o que aprendeu

Questão 1

O ping à porta de ligação funciona, mas o ping a outra rede não. O que se verifica a seguir?

1. O cabo
2. A rota por omissão e o encaminhamento
3. O navegador
4. A palavra-passe do utilizador

Questão 2

Qual é a atitude certa perante várias hipóteses?

1. Mudar tudo de uma vez para ganhar tempo
2. Testar uma hipótese de cada vez e registar
3. Reiniciar o encaminhador principal
4. Esperar que resolva sozinho

Em leitura fácil

• Comece pelo cabo, depois o endereço, depois o destino.
• Mude uma coisa de cada vez.
• Escreva o que fez.

Fontes

• 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)
• IETF RFC 792 — Internet Control Message Protocol (https://www.rfc-editor.org/rfc/rfc792)
• NIST SP 800-61 Rev. 3 — Incident Response Recommendations (https://csrc.nist.gov/pubs/sp/800/61/r3/final)

Duração: 70 minutos (explicação 20, prática guiada 40, verificação 10). Resultados dos TdR trabalhados: Configurar routers, switches, pontos de acesso e firewalls; LAN, WAN, WLAN, virtualização e nuvem.

Objectivos

• Explicar como um comutador aprende endereços MAC e decide o reencaminhamento.
• Distinguir domínio de colisão e domínio de difusão.
• Ler e limpar a tabela de endereços de um comutador.

Aprender, reencaminhar, inundar

Quando chega uma trama, o comutador regista o MAC de origem e a porta por onde entrou (aprendizagem). Se conhece o MAC de destino, envia só por essa porta; se não conhece, ou se é difusão (ff:ff:ff:ff:ff:ff), envia por todas as outras portas da mesma rede (inundação). As entradas envelhecem (tipicamente 300 segundos) e desaparecem se o equipamento se calar.

Cada porta de um comutador é um domínio de colisão separado; toda a rede local (a VLAN) é um domínio de difusão. Redes locais muito grandes sofrem com excesso de difusão: é uma das razões para segmentar em VLAN.

Caso fictício

Na DPE (fictícia), um portátil ligado ora à sala 1 ora à sala 2 perde a ligação durante uns segundos ao mudar. O técnico explica porquê com a tabela MAC.

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)

• No r1, ponte br-lab com três portas (t1, t2, t3), rede 192.168.50.0/24 de teste (igual à lição 3 do módulo 1, com um terceiro posto).

Passos

1. Recrie a ponte da lição anterior com três postos.

   sudo ip -n r1 link add br-lab type bridge && sudo ip -n r1 link set br-lab up
   for i in 1 2 3; do sudo ip netns add t$i; sudo ip link add t$i-br type veth peer name br-t$i; sudo ip link set t$i-br netns t$i; sudo ip link set br-t$i netns r1; sudo ip -n r1 link set br-t$i master br-lab up; sudo ip -n t$i addr add 192.168.50.$i/24 dev t$i-br; sudo ip -n t$i link set t$i-br up; done

2. Veja o tempo de envelhecimento e a tabela antes e depois de tráfego.

   sudo ip -n r1 -d link show br-lab | grep -o 'ageing_time [0-9]*'
   sudo ip netns exec r1 bridge fdb show br br-lab dynamic
   sudo ip netns exec t1 ping -c 1 192.168.50.3
   sudo ip netns exec r1 bridge fdb show br br-lab dynamic

   Saída de exemplo (didáctica):

   ageing_time 30000
   (vazio antes do tráfego)
   aa:bb:cc:00:00:01 dev br-t1 master br-lab
   aa:bb:cc:00:00:03 dev br-t3 master br-lab

3. Observe a inundação: capture no t2 enquanto t1 fala com t3 pela primeira vez (depois de limpar a tabela).

   sudo ip netns exec r1 bridge fdb flush dev br-lab
   Consola A: sudo ip netns exec t2 tcpdump -ni t2-br -c 1 arp
   Esperar na consola A a linha «listening on t2-br»; o tcpdump termina sozinho após 1 pacote (-c 1).
   Consola B: sudo ip netns exec t1 arping -c 1 -I t1-br 192.168.50.3 || sudo ip netns exec t1 ping -c 1 192.168.50.3

   Saída de exemplo (didáctica):

   ARP, Request who-has 192.168.50.3 tell 192.168.50.1

Critérios de sucesso

• O formando explica porque o t2 viu o pedido ARP (difusão) mas não o eco ICMP seguinte (unicast já aprendido).
• ageing_time 30000 é lido como 300,00 segundos (centésimos).

Como desfazer (reversão)

• for i in 1 2 3; do sudo ip netns del t$i; done; sudo ip -n r1 link del br-lab

Alternativa em papel: tarefas e respostas esperadas

Explique o caso do portátil que muda de sala.

O comutador ainda associa o MAC do portátil à porta antiga; as tramas vão para lá até o portátil transmitir na nova porta (a entrada é actualizada) ou até a entrada envelhecer. Normalmente resolve-se logo que o portátil envia tráfego.

Uma rede com 800 postos numa só VLAN: que problema de difusão prever?

Cada difusão (ARP, DHCP, descobertas) chega aos 800 postos, consumindo largura de banda e processamento; uma falha ou ciclo afecta todos. Propor segmentação em VLAN.

Um comutador com 24 portas tem quantos domínios de colisão e de difusão (sem VLAN)?

24 domínios de colisão e 1 domínio de difusão.

Verifique o que aprendeu

Questão 1

Um comutador recebe uma trama para um MAC que não conhece. O que faz?

1. Descarta
2. Envia por todas as outras portas da VLAN
3. Envia ao encaminhador
4. Pede o MAC por DNS

Questão 2

Qual o efeito de dividir uma rede grande em várias VLAN?

1. Aumenta o domínio de difusão
2. Reduz cada domínio de difusão
3. Elimina a necessidade de encaminhador
4. Desliga o ARP

Em leitura fácil

• O comutador aprende onde está cada computador.
• Se não sabe, envia para todos.
• Redes muito grandes ficam lentas com mensagens para todos.

Fontes

• IEEE 802.1Q — Bridges and Bridged Networks (VLAN, STP/RSTP) (https://standards.ieee.org/ieee/802.1Q/)
• 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)

Duração: 75 minutos (explicação 20, prática guiada 45, verificação 10). Resultados dos TdR trabalhados: Serviços de rede: DHCP, DNS, VPN, NAT, VLAN e autenticação; IDS/IPS, ACL e segmentação.

Objectivos

• Explicar o que é uma VLAN e a etiqueta 802.1Q.
• Configurar portas de acesso e portas tronco num comutador virtual.
• Provar que duas VLAN não comunicam sem encaminhamento.

Uma rede física, várias redes lógicas

Uma VLAN separa, no mesmo comutador, grupos de portas em domínios de difusão diferentes. Uma porta de acesso pertence a uma VLAN e envia tramas sem etiqueta ao posto. Uma porta tronco transporta várias VLAN entre comutadores ou até ao encaminhador, com a etiqueta 802.1Q (4 bytes, com o número da VLAN de 1 a 4094).

Na DPE: VLAN 10 Administração, 20 Servidores, 30 Visitantes, 99 Gestão. Boa prática: não usar a VLAN 1 para utilizadores nem para gestão, e deixar portas não usadas numa VLAN sem saída.

Caso fictício

Os visitantes ligados à tomada da recepção da DPE (fictícia) conseguem ver as impressoras da Administração. O técnico propõe separar a recepção em VLAN 30.

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)

• No r1, ponte br-vlan com filtragem de VLAN activa. Postos: a1 (VLAN 10, 10.10.10.21), a2 (VLAN 10, 10.10.10.22), v1 (VLAN 30, 10.10.30.21).

Passos

1. Crie o comutador com VLAN e três portas.

   sudo ip -n r1 link add br-vlan type bridge vlan_filtering 1 && sudo ip -n r1 link set br-vlan up
   for p in a1 a2 v1; do sudo ip netns add $p; sudo ip link add $p-sw type veth peer name sw-$p; sudo ip link set $p-sw netns $p; sudo ip link set sw-$p netns r1; sudo ip -n r1 link set sw-$p master br-vlan up; sudo ip -n $p link set $p-sw up; done
   sudo ip -n a1 addr add 10.10.10.21/24 dev a1-sw; sudo ip -n a2 addr add 10.10.10.22/24 dev a2-sw; sudo ip -n v1 addr add 10.10.10.23/24 dev v1-sw

2. Defina portas de acesso: a1 e a2 na VLAN 10, v1 na VLAN 30 (retirando a VLAN 1 por omissão).

   for p in a1 a2; do sudo ip netns exec r1 bridge vlan del dev sw-$p vid 1; sudo ip netns exec r1 bridge vlan add dev sw-$p vid 10 pvid untagged; done
   sudo ip netns exec r1 bridge vlan del dev sw-v1 vid 1; sudo ip netns exec r1 bridge vlan add dev sw-v1 vid 30 pvid untagged
   sudo ip netns exec r1 bridge vlan show

   Saída de exemplo (didáctica):

   port    vlan-id
   sw-a1   10 PVID Egress Untagged
   sw-a2   10 PVID Egress Untagged
   sw-v1   30 PVID Egress Untagged
   br-vlan 1 PVID Egress Untagged

3. Prove a separação. Repare que v1 foi configurado de propósito com um endereço da VLAN 10 para mostrar que a separação é de camada 2, não de endereço.

   sudo ip netns exec a1 ping -c 2 10.10.10.22
   sudo ip netns exec a1 ping -c 2 10.10.10.23

   Saída de exemplo (didáctica):

   2 packets transmitted, 2 received
   2 packets transmitted, 0 received, +2 errors (Destination Host Unreachable)

4. Corrija o endereço do v1 para a VLAN 30.

   sudo ip -n v1 addr flush dev v1-sw && sudo ip -n v1 addr add 10.10.30.21/24 dev v1-sw

Critérios de sucesso

• a1 fala com a2 (mesma VLAN); a1 não fala com v1 mesmo com endereço da mesma rede.
• bridge vlan show corresponde ao plano.

Como desfazer (reversão)

• for p in a1 a2 v1; do sudo ip netns del $p; done; sudo ip -n r1 link del br-vlan

Alternativa em papel: tarefas e respostas esperadas

Desenhe em texto a configuração de portas para a recepção (2 tomadas) e a Administração (4 tomadas) num comutador de 8 portas com tronco na porta 8.

Portas 1–4: acesso VLAN 10; portas 5–6: acesso VLAN 30; porta 7: não usada, desactivada ou numa VLAN sem saída; porta 8: tronco com VLAN 10, 20, 30 e 99 etiquetadas.

Porque é que o v1 não alcança o a1 mesmo com endereço 10.10.10.23?

As tramas do v1 entram na VLAN 30 e o comutador só as reencaminha para portas da VLAN 30; o pedido ARP nunca chega ao a1.

Que valor tem a VLAN na etiqueta 802.1Q e quantos bits usa?

Campo VID de 12 bits; valores úteis 1 a 4094.

Verifique o que aprendeu

Questão 1

Uma porta tronco serve para:

1. Ligar um só computador
2. Transportar várias VLAN etiquetadas entre equipamentos
3. Dar acesso à internet
4. Desligar a VLAN 1

Questão 2

Qual é uma boa prática com portas não usadas?

1. Deixá-las na VLAN de gestão
2. Desactivá-las ou colocá-las numa VLAN sem saída
3. Configurá-las como tronco
4. Deixá-las na VLAN 1

Em leitura fácil

• VLAN separa grupos no mesmo comutador.
• Visitantes numa VLAN, funcionários noutra.
• Para falarem entre si é preciso um encaminhador.

Fontes

• IEEE 802.1Q — Bridges and Bridged Networks (VLAN, STP/RSTP) (https://standards.ieee.org/ieee/802.1Q/)
• 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)

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; Serviços de rede: DHCP, DNS, VPN, NAT, VLAN e autenticação.

Objectivos

• Configurar encaminhamento entre VLAN com subinterfaces (router-on-a-stick).
• Explicar a diferença para um comutador de camada 3.
• Verificar que o tráfego entre VLAN passa pelo encaminhador.

Uma porta, várias redes

Para que a VLAN 10 fale com a VLAN 20 é preciso encaminhamento IP. A forma mais simples: uma porta tronco do comutador ao encaminhador, que cria uma subinterface por VLAN (por exemplo eth0.10 com 10.10.10.1/24 e eth0.20 com 10.10.20.1/24). Cada posto usa a subinterface da sua VLAN como porta de ligação.

Um comutador de camada 3 faz o mesmo internamente (interfaces virtuais por VLAN) com mais débito. O ponto de passagem entre VLAN é também o sítio natural para filtrar tráfego (módulo 7).

Caso fictício

Na DPE (fictícia), a Administração (VLAN 10) precisa de chegar ao servidor de ficheiros (VLAN 20), mas os visitantes (VLAN 30) não devem. Nesta lição liga-se o encaminhamento; a filtragem vem no módulo 7.

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)

• Espaço sw (comutador) com br0 com VLAN; porta tronco sw-rt ligada a rt (encaminhador) com subinterfaces rt-sw.10 e rt-sw.20; postos a1 (VLAN 10, 10.10.10.21) e s1 (VLAN 20, 10.10.20.21).

Passos

1. Crie comutador, encaminhador e postos.

   for n in sw rt a1 s1; do sudo ip netns add $n; done
   sudo ip -n sw link add br0 type bridge vlan_filtering 1 && sudo ip -n sw link set br0 up
   lig() { sudo ip link add $1-$2 type veth peer name $2-$1; sudo ip link set $1-$2 netns $1; sudo ip link set $2-$1 netns $2; sudo ip -n $1 link set $1-$2 up; sudo ip -n $2 link set $2-$1 up; }
   lig a1 sw; lig s1 sw; lig rt sw
   for p in sw-a1 sw-s1 sw-rt; do sudo ip -n sw link set $p master br0; sudo ip netns exec sw bridge vlan del dev $p vid 1; done
   sudo ip netns exec sw bridge vlan add dev sw-a1 vid 10 pvid untagged
   sudo ip netns exec sw bridge vlan add dev sw-s1 vid 20 pvid untagged
   sudo ip netns exec sw bridge vlan add dev sw-rt vid 10; sudo ip netns exec sw bridge vlan add dev sw-rt vid 20

2. No encaminhador, crie as subinterfaces etiquetadas e active o encaminhamento.

   sudo ip -n rt link add link rt-sw name rt-sw.10 type vlan id 10
   sudo ip -n rt link add link rt-sw name rt-sw.20 type vlan id 20
   sudo ip -n rt addr add 10.10.10.1/24 dev rt-sw.10; sudo ip -n rt addr add 10.10.20.1/24 dev rt-sw.20
   sudo ip -n rt link set rt-sw.10 up; sudo ip -n rt link set rt-sw.20 up
   sudo ip netns exec rt sysctl -qw net.ipv4.ip_forward=1

3. Configure os postos e teste.

   sudo ip -n a1 addr add 10.10.10.21/24 dev a1-sw; sudo ip -n a1 route add default via 10.10.10.1
   sudo ip -n s1 addr add 10.10.20.21/24 dev s1-sw; sudo ip -n s1 route add default via 10.10.20.1
   sudo ip netns exec a1 traceroute -n 10.10.20.21

   Saída de exemplo (didáctica):

    1  10.10.10.1  0.06 ms
    2  10.10.20.21  0.08 ms

4. Veja as etiquetas na porta tronco.

   Consola A: sudo ip netns exec rt tcpdump -eni rt-sw -c 2 'vlan and icmp[icmptype] == icmp-echo'
   Esperar na consola A a linha «listening on rt-sw»; termina sozinho após 2 pacotes.
   Consola B: sudo ip netns exec a1 ping -c 1 10.10.20.21
   Nota: na interface tronco as tramas levam etiqueta 802.1Q; o filtro precisa de «vlan and …», porque «icmp» sozinho procura IPv4 logo após o cabeçalho Ethernet e não apanha tramas etiquetadas.

   Saída de exemplo (didáctica):

   ... ethertype 802.1Q (0x8100), length 102: vlan 10, p 0, ethertype IPv4, 10.10.10.21 > 10.10.20.21: ICMP echo request
   ... ethertype 802.1Q (0x8100), length 102: vlan 20, p 0, ethertype IPv4, 10.10.10.21 > 10.10.20.21: ICMP echo request

Critérios de sucesso

• traceroute mostra o salto pelo encaminhador.
• A captura mostra o mesmo pacote a entrar na VLAN 10 e a sair na VLAN 20.

Como desfazer (reversão)

• for n in sw rt a1 s1; do sudo ip netns del $n; done

Alternativa em papel: tarefas e respostas esperadas

Que porta de ligação configura um posto da VLAN 30?

10.10.30.1, endereço da subinterface VLAN 30 do encaminhador.

Na captura, porque o mesmo pacote aparece duas vezes com VLAN diferente?

Entra pela subinterface .10 (VLAN 10) e sai, encaminhado, pela subinterface .20 (VLAN 20), na mesma porta física tronco.

Vantagem e limite do router-on-a-stick.

Vantagem: uma só porta física, barato. Limite: todo o tráfego entre VLAN partilha essa porta (gargalo); em redes maiores usa-se comutador de camada 3.

Verifique o que aprendeu

Questão 1

Sem encaminhador, um posto da VLAN 10 consegue falar com um da VLAN 20?

1. Sim, se estiverem no mesmo comutador
2. Não, é preciso encaminhamento IP
3. Sim, com o mesmo cabo
4. Só por Wi-Fi

Questão 2

Onde é mais natural aplicar a regra «visitantes não chegam aos servidores»?

1. Em cada posto
2. No ponto que encaminha entre VLAN
3. No DNS
4. No cabo

Em leitura fácil

• Cada VLAN precisa de uma porta de saída no encaminhador.
• Uma só ligação pode levar várias VLAN.
• É aí que se decide quem pode falar com quem.

Fontes

• IEEE 802.1Q — Bridges and Bridged Networks (VLAN, STP/RSTP) (https://standards.ieee.org/ieee/802.1Q/)
• 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)

Duração: 80 minutos (explicação 20, prática guiada 50, verificação 10). Resultados dos TdR trabalhados: Diagnóstico, desempenho e disponibilidade; Continuidade e protecção de activos digitais.

Objectivos

• Explicar porque um ciclo na camada 2 derruba uma rede.
• Descrever STP/RSTP: raiz, portas bloqueadas e convergência.
• Activar STP num comutador virtual e observar a porta bloqueada.

Redundância sem ciclos

Ligar dois comutadores por dois cabos dá redundância, mas cria um ciclo: as difusões circulam para sempre (tempestade de difusão) e a tabela MAC oscila. O protocolo Spanning Tree (802.1D, e a versão rápida RSTP em 802.1Q) elege um comutador raiz e bloqueia portas até restar uma árvore sem ciclos. Se uma ligação falha, uma porta bloqueada passa a reencaminhar.

Boas práticas: escolher a raiz de propósito (prioridade mais baixa no comutador central), proteger portas de acesso para que um posto não se anuncie como comutador, e documentar as ligações redundantes. A agregação de ligações (LACP) é outra forma de redundância, somando cabos numa só ligação lógica.

Caso fictício

Um funcionário da DPE (fictícia) liga as duas pontas de um cabo a duas tomadas da mesma sala. Metade da sede fica sem rede. O técnico explica o sucedido e propõe protecção.

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)

• Três comutadores virtuais sa, sb e sc ligados em triângulo (sa–sb, sb–sc, sc–sa), cada um uma ponte br0 num espaço de nomes próprio.

Passos

1. Crie o triângulo com STP activo desde o início (nunca sem STP, para não criar uma tempestade no seu computador).

   for s in sa sb sc; do sudo ip netns add $s; sudo ip -n $s link add br0 type bridge stp_state 1; done
   sudo ip -n sa link set br0 type bridge priority 4096
   lig() { sudo ip link add $1-$2 type veth peer name $2-$1; sudo ip link set $1-$2 netns $1; sudo ip link set $2-$1 netns $2; sudo ip -n $1 link set $1-$2 master br0 up; sudo ip -n $2 link set $2-$1 master br0 up; }
   lig sa sb; lig sb sc; lig sc sa
   for s in sa sb sc; do sudo ip -n $s link set br0 up; done
   sleep 35

2. Veja o estado das portas; uma delas deve estar bloqueada.

   for s in sa sb sc; do echo $s; sudo ip netns exec $s bridge link; done

   Saída de exemplo (didáctica):

   sa
   ... sa-sb master br0 state forwarding priority 32 cost 2
   ... sa-sc master br0 state forwarding priority 32 cost 2
   sb
   ... sb-sa master br0 state forwarding ...
   ... sb-sc master br0 state forwarding ...
   sc
   ... sc-sb master br0 state blocking ...
   ... sc-sa master br0 state forwarding ...

3. Simule a falha da ligação sa–sc e observe a porta bloqueada a passar a reencaminhar (o STP clássico do Linux demora cerca de 30 segundos).

   sudo ip -n sa link set sa-sc down
   sleep 35; sudo ip netns exec sc bridge link

   Saída de exemplo (didáctica):

   ... sc-sb master br0 state forwarding ...
   ... sc-sa master br0 state disabled ...

Critérios de sucesso

• Com as três ligações activas, há exactamente uma porta bloqueada.
• sa é a raiz (prioridade 4096).
• Após a falha, a rede continua ligada pela porta antes bloqueada.

Como desfazer (reversão)

• for s in sa sb sc; do sudo ip netns del $s; done

Alternativa em papel: tarefas e respostas esperadas

Explique o caso do cabo ligado a duas tomadas.

Criou-se um ciclo de camada 2; sem STP (ou com portas de acesso sem protecção) as difusões multiplicaram-se e saturaram os comutadores. Protecção: STP/RSTP activo, protecção BPDU nas portas de acesso e controlo de tempestades.

Porque escolher manualmente a raiz?

Para que a árvore passe pelo comutador central e mais capaz; se ficar a eleição por omissão, pode ganhar um comutador pequeno de canto, com caminhos maus.

Diferença entre STP e agregação de ligações.

STP bloqueia caminhos redundantes (uma só ligação activa); a agregação junta várias ligações paralelas numa lógica, activas ao mesmo tempo.

Verifique o que aprendeu

Questão 1

O que faz o STP perante um ciclo?

1. Desliga um comutador
2. Bloqueia portas até não haver ciclos
3. Aumenta a velocidade
4. Cria VLAN

Questão 2

Qual a diferença prática entre STP clássico e RSTP?

1. RSTP converge muito mais depressa
2. RSTP não bloqueia portas
3. STP só funciona em Wi-Fi
4. Não há diferença

Em leitura fácil

• Dois caminhos entre comutadores fazem um círculo.
• O círculo pode parar a rede toda.
• O STP fecha um caminho e abre-o se o outro cair.

Fontes

• IEEE 802.1Q — Bridges and Bridged Networks (VLAN, STP/RSTP) (https://standards.ieee.org/ieee/802.1Q/)
• 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)

Duração: 80 minutos (explicação 20, prática guiada 50, verificação 10). Resultados dos TdR trabalhados: Segurança desde a concepção; IDS/IPS, ACL e segmentação; Documentação: diagramas, procedimentos (SOP) e contingência.

Objectivos

• Verificar que a segmentação corresponde ao desenho documentado.
• Detectar portas mal atribuídas e VLAN em falta no tronco.
• Produzir uma tabela de verificação de segmentação.

Desenho, configuração, prova

Segmentar é uma decisão de segurança desde a concepção: separar Administração, Servidores, Visitantes e Gestão reduz o alcance de uma infecção e protege a gestão dos equipamentos. Mas uma configuração errada dá falsa segurança. Verifica-se em três planos: a configuração (que VLAN tem cada porta), o comportamento (quem alcança quem) e o documento (a tabela do desenho).

Qualquer diferença entre os três é um achado: ou a configuração está errada, ou o documento está desactualizado. Ambos se corrigem, com registo.

Caso fictício

O documento da DPE (fictícia) diz que a porta 5 é da VLAN 30 (Visitantes). Um visitante, na porta 5, abre a página de gestão de um comutador. O técnico verifica.

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)

• Comutador br-vlan com portas sw-a1 (plano: VLAN 10), sw-v1 (plano: VLAN 30), sw-g1 (plano: VLAN 99). O formador introduz um erro.

Passos

1. Construa a rede (igual à lição 2, acrescentando g1 com 10.10.99.21) e aplique o plano.

   sudo ip -n r1 link add br-vlan type bridge vlan_filtering 1 && sudo ip -n r1 link set br-vlan up
   for p in a1 v1 g1; do sudo ip netns add $p; sudo ip link add $p-sw type veth peer name sw-$p; sudo ip link set $p-sw netns $p; sudo ip link set sw-$p netns r1; sudo ip -n r1 link set sw-$p master br-vlan up; sudo ip -n $p link set $p-sw up; sudo ip netns exec r1 bridge vlan del dev sw-$p vid 1; done
   sudo ip netns exec r1 bridge vlan add dev sw-a1 vid 10 pvid untagged
   sudo ip netns exec r1 bridge vlan add dev sw-g1 vid 99 pvid untagged
   sudo ip -n a1 addr add 10.10.10.21/24 dev a1-sw; sudo ip -n v1 addr add 10.10.99.30/24 dev v1-sw; sudo ip -n g1 addr add 10.10.99.21/24 dev g1-sw

2. Formador: introduza o erro — a porta do visitante fica na VLAN 99.

   sudo ip netns exec r1 bridge vlan add dev sw-v1 vid 99 pvid untagged

3. Duplas: compare configuração com o plano e teste o comportamento.

   sudo ip netns exec r1 bridge vlan show
   sudo ip netns exec v1 ping -c 1 10.10.99.21

   Saída de exemplo (didáctica):

   sw-a1  10 PVID Egress Untagged
   sw-v1  99 PVID Egress Untagged
   sw-g1  99 PVID Egress Untagged
   1 packets transmitted, 1 received

4. Corrija e prove.

   sudo ip netns exec r1 bridge vlan del dev sw-v1 vid 99
   sudo ip netns exec r1 bridge vlan add dev sw-v1 vid 30 pvid untagged
   sudo ip -n v1 addr flush dev v1-sw; sudo ip -n v1 addr add 10.10.30.21/24 dev v1-sw
   sudo ip netns exec v1 ping -c 1 -W 1 10.10.99.21

   Saída de exemplo (didáctica):

   1 packets transmitted, 0 received

Critérios de sucesso

• A tabela de verificação tem uma linha por porta: VLAN planeada, VLAN configurada, teste feito, resultado, acção.
• Depois da correcção, v1 não alcança a VLAN 99.

Como desfazer (reversão)

• for p in a1 v1 g1; do sudo ip netns del $p; done; sudo ip -n r1 link del br-vlan

Alternativa em papel: tarefas e respostas esperadas

Preencha a tabela de verificação para as três portas, antes da correcção.

sw-a1: plano 10 / configurada 10 / conforme. sw-v1: plano 30 / configurada 99 / NÃO conforme — visitante alcança gestão / corrigir para 30. sw-g1: plano 99 / configurada 99 / conforme.

Que risco concreto criava o erro?

Um visitante na rede de gestão pode tentar aceder às interfaces de administração dos equipamentos; se houver palavras-passe fracas ou falhas, compromete toda a rede.

Além de corrigir a porta, o que se deve fazer?

Registar o achado, verificar se houve acessos indevidos (registos dos equipamentos), actualizar o documento e rever as outras portas do mesmo comutador.

Verifique o que aprendeu

Questão 1

A configuração diz VLAN 99, o documento diz VLAN 30. Qual é a acção correcta?

1. Mudar o documento para 99
2. Confirmar a intenção, corrigir a configuração e registar
3. Ignorar
4. Desligar o comutador

Questão 2

Para provar a segmentação, basta ler a configuração?

1. Sim
2. Não, é preciso também testar o comportamento
3. Só em IPv6
4. Só com firewall

Em leitura fácil

• Compare o papel com o que está configurado.
• Teste quem chega a quem.
• Se não bater certo, corrija e escreva.

Fontes

• IEEE 802.1Q — Bridges and Bridged Networks (VLAN, STP/RSTP) (https://standards.ieee.org/ieee/802.1Q/)
• 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)
• NIST SP 800-207 — Zero Trust Architecture (https://csrc.nist.gov/pubs/sp/800/207/final)

Duração: 70 minutos (explicação 20, prática guiada 40, verificação 10). Resultados dos TdR trabalhados: Conceber, configurar e administrar redes pequenas, médias e grandes; Configurar routers, switches, pontos de acesso e firewalls.

Objectivos

• Ler uma tabela de encaminhamento e aplicar a regra do prefixo mais longo.
• Distinguir rota ligada, estática e por omissão.
• Prever o caminho de um pacote antes de o testar.

Como o encaminhador decide

Para cada pacote, o encaminhador procura na tabela a rota com o prefixo mais longo que contém o destino. Se há 10.0.0.0/8 e 10.20.10.0/24, um pacote para 10.20.10.10 segue a /24. A rota 0.0.0.0/0 (por omissão) apanha tudo o que não tem rota mais específica.

Rotas ligadas aparecem sozinhas quando se atribui um endereço a uma interface. As restantes são estáticas (escritas pelo técnico) ou dinâmicas (aprendidas por protocolo, lição 3). Cada decisão é local: cada encaminhador do caminho precisa de saber o próximo salto, e o caminho de volta também.

Caso fictício

Na DPE (fictícia), a delegação chega à sede mas as respostas não voltam. O técnico lembra que o encaminhamento é de ida e de volta.

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. Leia a tabela do r1 e identifique as rotas ligadas.

   sudo ip -n r1 route

   Saída de exemplo (didáctica):

   10.10.10.0/24 dev r1-pc-adm proto kernel scope link src 10.10.10.1
   10.10.20.0/24 dev r1-srv proto kernel scope link src 10.10.20.1
   10.255.0.0/30 dev r1-r2 proto kernel scope link src 10.255.0.1
   203.0.113.0/24 dev r1-isp proto kernel scope link src 203.0.113.2

2. Pergunte ao núcleo que rota usaria para vários destinos.

   sudo ip -n r1 route get 10.20.10.10
   sudo ip -n r1 route get 10.10.20.53

   Saída de exemplo (didáctica):

   RTNETLINK answers: Network is unreachable
   10.10.20.53 dev r1-srv src 10.10.20.1

3. Acrescente só a ida (r1 → delegação) e teste do srv para o pc-del.

   sudo ip -n r1 route add 10.20.10.0/24 via 10.255.0.2
   sudo ip netns exec srv ping -c 2 -W 1 10.20.10.10

   Saída de exemplo (didáctica):

   2 packets transmitted, 0 received

4. Acrescente a volta no r2 e teste de novo.

   sudo ip -n r2 route add 10.10.0.0/16 via 10.255.0.1
   sudo ip netns exec srv ping -c 2 10.20.10.10

   Saída de exemplo (didáctica):

   2 packets transmitted, 2 received

5. Demonstre o prefixo mais longo: rota /16 e /24 para destinos diferentes.

   sudo ip -n r2 route get 10.10.20.53
   sudo ip -n r2 route get 10.20.10.10

   Saída de exemplo (didáctica):

   10.10.20.53 via 10.255.0.1 dev r2-r1 src 10.255.0.2
   10.20.10.10 dev r2-pc-del src 10.20.10.1

Critérios de sucesso

• O formando prevê por escrito que o primeiro ping falha (sem volta) e o segundo funciona.
• Explica porque 10.20.10.10 usa a rota ligada /24 e não a /16.

Como desfazer (reversão)

• sudo ip -n r1 route del 10.20.10.0/24
• sudo ip -n r2 route del 10.10.0.0/16

Alternativa em papel: tarefas e respostas esperadas

Tabela: 0.0.0.0/0 via A; 10.0.0.0/8 via B; 10.20.0.0/16 via C; 10.20.10.0/24 via D. Qual o próximo salto para 10.20.10.5, 10.20.99.1, 10.1.1.1 e 8.8.8.8?

D, C, B, A (prefixo mais longo que contém cada destino).

Explique o caso da delegação.

Existe rota de ida mas o encaminhador do outro lado não tem rota de volta para a rede de origem; as respostas perdem-se ou vão pela rota por omissão.

Porque o r2 usa 10.10.0.0/16 e não duas /24?

Sumarização: uma rota cobre 10.10.10.0/24, 10.10.20.0/24, 10.10.30.0/24 e 10.10.99.0/24 da sede, simplificando a tabela, desde que nenhuma parte de 10.10.0.0/16 esteja noutro sítio.

Verifique o que aprendeu

Questão 1

Com rotas 10.0.0.0/8 e 10.10.20.0/24, para onde vai um pacote para 10.10.20.53?

1. Pela /8
2. Pela /24
3. Pela rota por omissão
4. É descartado

Questão 2

Um ping só funciona se existir:

1. Rota de ida
2. Rota de ida e de volta
3. Rota por omissão em todos
4. DNS

Em leitura fácil

• O encaminhador escolhe a rota mais exacta.
• É preciso caminho de ida e de volta.
• A rota por omissão serve para tudo o resto.

Fontes

• IETF RFC 4632 — Classless Inter-domain Routing (CIDR) (https://www.rfc-editor.org/rfc/rfc4632)
• IETF RFC 791 — Internet Protocol (https://www.rfc-editor.org/rfc/rfc791)
• 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)

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; LAN, WAN, WLAN, virtualização e nuvem.

Objectivos

• Configurar rotas estáticas e por omissão de forma persistente com FRRouting.
• Comparar vantagens de rotas estáticas e dinâmicas.
• Configurar uma rota flutuante de reserva.

Estáticas: simples e previsíveis

Rotas estáticas não geram tráfego de protocolo e são previsíveis, mas não se adaptam a falhas e crescem mal. São adequadas em redes pequenas, em ramos com uma só saída (a delegação que só tem o r1) e como rota por omissão para o operador.

A distância administrativa indica a preferência entre fontes de rota. Uma rota estática com distância maior (rota flutuante) só entra na tabela quando a principal desaparece. No FRRouting escreve-se com o valor no fim da linha ip route.

Porquê FRRouting

Os comandos ip route perdem-se ao reiniciar. O FRRouting (pacote frr no Debian) guarda a configuração e fala a linguagem de vários protocolos, com a consola vtysh, semelhante à de muitos equipamentos comerciais; a sintaxe exacta de cada fabricante difere e deve ser confirmada no manual dele.

Caso fictício

A delegação da DPE (fictícia) tem uma ligação principal à sede e um acesso de reserva ao operador. Quer que a reserva só seja usada quando a principal cair.

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).
• Nesta lição acrescenta-se uma ligação de reserva r2–isp na rede 10.255.1.0/30: r2 = 10.255.1.2, isp = 10.255.1.1.

Passos

1. O FRR pode correr uma instância por espaço de nomes (opção de «pathspace» do frrinit.sh, conforme a documentação FRR). Se não funcionar na sua versão, use as linhas ip route equivalentes indicadas no fim.

   sudo mkdir -p /etc/frr/r2 && sudo cp /etc/frr/daemons /etc/frr/r2/ && sudo touch /etc/frr/r2/frr.conf /etc/frr/r2/vtysh.conf
   sudo chown -R frr:frr /etc/frr/r2
   sudo /usr/lib/frr/frrinit.sh start r2

2. Crie a ligação de reserva.

   sudo ip link add r2-isp type veth peer name isp-r2; sudo ip link set r2-isp netns r2; sudo ip link set isp-r2 netns isp
   sudo ip -n r2 addr add 10.255.1.2/30 dev r2-isp; sudo ip -n isp addr add 10.255.1.1/30 dev isp-r2
   sudo ip -n r2 link set r2-isp up; sudo ip -n isp link set isp-r2 up

3. No vtysh do r2, configure rota por omissão principal pela sede e flutuante pelo operador (distância 200).

   sudo vtysh -N r2
   configure terminal
    ip route 0.0.0.0/0 10.255.0.1
    ip route 0.0.0.0/0 10.255.1.1 200
   end
   write memory
   show ip route 0.0.0.0/0

   Saída de exemplo (didáctica):

   Routing entry for 0.0.0.0/0
     Known via "static", distance 1, metric 0, best
     * 10.255.0.1, via r2-r1
   Routing entry for 0.0.0.0/0
     Known via "static", distance 200, metric 0
       10.255.1.1 inactive

4. Simule a falha da ligação principal e veja a reserva entrar.

   sudo ip -n r2 link set r2-r1 down
   sudo ip -n r2 route show default

   Saída de exemplo (didáctica):

   default via 10.255.1.1 dev r2-isp proto static metric 20

5. Equivalente sem FRR (não persistente), para quem não conseguir o passo 1.

   sudo ip -n r2 route add default via 10.255.0.1 metric 1
   sudo ip -n r2 route add default via 10.255.1.1 metric 200

Critérios de sucesso

• Com a principal activa, a rota por omissão usa 10.255.0.1.
• Com a principal em baixo, a rota passa a 10.255.1.1.
• Ao repor a principal, volta a ser preferida.

Como desfazer (reversão)

• sudo ip -n r2 link set r2-r1 up
• No vtysh: configure terminal / no ip route 0.0.0.0/0 10.255.1.1 200 / no ip route 0.0.0.0/0 10.255.0.1 / write memory
• sudo /usr/lib/frr/frrinit.sh stop r2; sudo ip -n r2 link del r2-isp

Alternativa em papel: tarefas e respostas esperadas

Escreva as duas linhas de rota por omissão do r2 (principal e reserva) em sintaxe FRR.

ip route 0.0.0.0/0 10.255.0.1 / ip route 0.0.0.0/0 10.255.1.1 200

Porque a rota flutuante não aparece activa enquanto a principal funciona?

Tem distância administrativa 200, pior que 1; só é instalada quando a de distância 1 desaparece.

Quando preferir estáticas a dinâmicas?

Redes pequenas, ramos com uma só saída, rota para o operador, ou quando se quer controlo total. Dinâmicas quando há vários caminhos e mudanças frequentes.

Verifique o que aprendeu

Questão 1

Uma rota flutuante é:

1. Uma rota que muda de destino
2. Uma rota estática de reserva com distância maior
3. Uma rota OSPF
4. Uma rota IPv6

Questão 2

Qual é um limite das rotas estáticas?

1. Não funcionam em Linux
2. Não se adaptam sozinhas a falhas intermédias
3. Usam muita largura de banda
4. Só servem para IPv6

Em leitura fácil

• Rota estática é escrita à mão.
• A rota de reserva só entra quando a principal cai.
• O FRR guarda a configuração.

Fontes

• FRRouting — documentação oficial (zebra, staticd, ospfd, vrrpd, vtysh) (https://docs.frrouting.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)
• IETF RFC 5880 — Bidirectional Forwarding Detection (https://www.rfc-editor.org/rfc/rfc5880)

Duração: 75 minutos (explicação 20, prática guiada 45, verificação 10). Resultados dos TdR trabalhados: Conceber, configurar e administrar redes pequenas, médias e grandes; Configurar routers, switches, pontos de acesso e firewalls.

Objectivos

• Explicar o funcionamento de OSPF: vizinhos, estado de ligação, custo, áreas.
• Configurar OSPF entre r1 e r2 com FRRouting.
• Verificar vizinhança e rotas aprendidas.

Protocolos de encaminhamento

Protocolos de vector de distância (como RIP) trocam tabelas com os vizinhos; protocolos de estado de ligação (como OSPF) trocam descrições das ligações e cada encaminhador calcula o caminho mais curto. Entre organizações usa-se BGP, que decide por políticas. Dentro de uma instituição, OSPF é um padrão aberto (RFC 2328) suportado por muitos fabricantes.

No OSPF, os encaminhadores tornam-se vizinhos se concordarem em parâmetros (área, temporizadores, rede). O custo de cada ligação soma-se no caminho; escolhe-se o menor. Áreas limitam o tamanho da base de dados em redes grandes; redes pequenas e médias usam só a área 0. Boa prática de segurança: autenticação entre vizinhos e interfaces passivas onde não há encaminhadores.

Caso fictício

A DPE (fictícia) vai abrir mais três delegações. Manter rotas estáticas em todos os encaminhadores tornou-se propenso a erros. O técnico propõe OSPF na área 0.

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).
• Instâncias FRR r1 e r2 (ver lição 2). As rotas estáticas entre sede e delegação devem ser retiradas antes.

Passos

1. Active o ospfd nas duas instâncias e arranque o FRR.

   for r in r1 r2; do sudo mkdir -p /etc/frr/$r; sudo cp /etc/frr/daemons /etc/frr/$r/; sudo sed -i 's/^ospfd=no/ospfd=yes/' /etc/frr/$r/daemons; sudo touch /etc/frr/$r/frr.conf /etc/frr/$r/vtysh.conf; sudo chown -R frr:frr /etc/frr/$r; sudo /usr/lib/frr/frrinit.sh restart $r; done

2. Configure o OSPF no r1 (a ligação para o isp não entra no OSPF; LAN passivas).

   sudo vtysh -N r1
   configure terminal
   router ospf
    ospf router-id 10.255.0.1
    network 10.255.0.0/30 area 0
    network 10.10.10.0/24 area 0
    network 10.10.20.0/24 area 0
    passive-interface r1-pc-adm
    passive-interface r1-srv
   exit
   interface r1-r2
    ip ospf authentication message-digest
    ip ospf message-digest-key 1 md5 ChaveDeTreinoDPE
   end
   write memory

3. Configure o r2 de forma simétrica.

   sudo vtysh -N r2
   configure terminal
   router ospf
    ospf router-id 10.255.0.2
    network 10.255.0.0/30 area 0
    network 10.20.10.0/24 area 0
    passive-interface r2-pc-del
   exit
   interface r2-r1
    ip ospf authentication message-digest
    ip ospf message-digest-key 1 md5 ChaveDeTreinoDPE
   end
   write memory

4. Verifique vizinhança e rotas.

   sudo vtysh -N r1 -c 'show ip ospf neighbor'
   sudo vtysh -N r2 -c 'show ip route ospf'

   Saída de exemplo (didáctica):

   Neighbor ID     Pri State           Up Time  Dead Time Address         Interface
   10.255.0.2        1 Full/DR         00:01:10   35.123s 10.255.0.2      r1-r2:10.255.0.1
   O>* 10.10.10.0/24 [110/20] via 10.255.0.1, r2-r1, weight 1, 00:00:58
   O>* 10.10.20.0/24 [110/20] via 10.255.0.1, r2-r1, weight 1, 00:00:58

5. Prove de ponta a ponta.

   sudo ip netns exec pc-del ping -c 2 10.10.20.53

Critérios de sucesso

• Vizinhança em estado Full.
• r2 aprende 10.10.10.0/24 e 10.10.20.0/24 com código O.
• pc-del alcança srv sem rotas estáticas.

Como desfazer (reversão)

• for r in r1 r2; do sudo /usr/lib/frr/frrinit.sh stop $r; sudo rm -rf /etc/frr/$r; done
• A chave «ChaveDeTreinoDPE» é só de prática; numa rede real usar chave própria guardada em cofre.

Alternativa em papel: tarefas e respostas esperadas

Porque a ligação ao isp não entra no OSPF?

Não se trocam rotas internas com o operador por OSPF; para a internet usa-se rota por omissão (ou BGP com política). Anunciar a rede interna ao exterior seria uma fuga de informação e um risco.

O que significa [110/20] na rota do r2?

110 é a distância administrativa do OSPF; 20 é o custo total do caminho (custo da ligação r2–r1 mais o da LAN).

A vizinhança não sobe. Liste três verificações.

Mesma área e mesma rede na ligação; mesma chave e tipo de autenticação; interface não passiva; temporizadores iguais; conectividade IP na ligação (ping 10.255.0.2).

Verifique o que aprendeu

Questão 1

O que faz passive-interface numa LAN de utilizadores?

1. Desliga a LAN
2. Anuncia a rede mas não envia mensagens OSPF para essa LAN
3. Bloqueia o tráfego dos utilizadores
4. Muda a área

Questão 2

Porque autenticar o OSPF?

1. Para ir mais depressa
2. Para impedir que um equipamento não autorizado injecte rotas
3. Para cifrar os dados dos utilizadores
4. É obrigatório em IPv4

Em leitura fácil

• Com OSPF os encaminhadores contam uns aos outros as redes que têm.
• Escolhem o caminho mais barato.
• Só se fala OSPF com encaminhadores de confiança.

Fontes

• IETF RFC 2328 — OSPF Version 2 (https://www.rfc-editor.org/rfc/rfc2328)
• FRRouting — documentação oficial (zebra, staticd, ospfd, vrrpd, vtysh) (https://docs.frrouting.org/)

Duração: 80 minutos (explicação 20, prática guiada 50, verificação 10). Resultados dos TdR trabalhados: Serviços de rede: DHCP, DNS, VPN, NAT, VLAN e autenticação; Segurança desde a concepção.

Objectivos

• Explicar NAT de origem (mascaramento) e de destino (reencaminhamento de porta).
• Configurar NAT no r1 com nftables.
• Reconhecer que NAT não substitui firewall.

Tradução de endereços

Os endereços privados (RFC 1918) não são encaminhados na internet. O NAT de origem troca o endereço privado pelo endereço público do encaminhador e guarda a correspondência numa tabela de estado, para que as respostas voltem ao posto certo. Muitos postos partilham um só endereço público, distinguidos pela porta (PAT).

O NAT de destino publica um serviço interno: pedidos que chegam ao endereço público numa porta são enviados a um servidor interno. É uma decisão de exposição: só se publica o que é necessário, com firewall e actualizações. O NAT esconde endereços mas não é, por si, controlo de segurança.

Caso fictício

A DPE (fictícia) quer que a sede navegue através do único endereço fornecido pelo operador (203.0.113.2) e publicar o portal interno do srv na porta 80.

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. Confirme que, sem NAT, o servidor externo não sabe responder à rede privada.

   sudo ip -n r1 route add default via 203.0.113.1
   sudo ip netns exec pc-adm ping -c 1 -W 1 198.51.100.10

   Saída de exemplo (didáctica):

   1 packets transmitted, 0 received

2. Crie a tabela NAT no r1 com mascaramento de saída pela interface do operador.

   sudo ip netns exec r1 nft add table ip nat
   sudo ip netns exec r1 nft 'add chain ip nat postrouting { type nat hook postrouting priority srcnat; }'
   sudo ip netns exec r1 nft add rule ip nat postrouting oifname "r1-isp" ip saddr 10.10.0.0/16 masquerade
   sudo ip netns exec pc-adm ping -c 1 198.51.100.10

   Saída de exemplo (didáctica):

   1 packets transmitted, 1 received

3. Veja, no isp, que a origem aparece como 203.0.113.2.

   Consola A: sudo ip netns exec isp tcpdump -ni isp-r1 -c 1 'icmp[icmptype] == icmp-echo'
   Esperar na consola A a linha «listening on isp-r1»; termina sozinho após 1 pacote.
   Consola B: sudo ip netns exec pc-adm ping -c 1 198.51.100.10

   Saída de exemplo (didáctica):

   IP 203.0.113.2 > 198.51.100.10: ICMP echo request

4. Publique o portal do srv na porta 80 (NAT de destino) e teste a partir do isp.

   Consola C (deixar aberta): sudo ip netns exec srv python3 -m http.server 80 --bind 10.10.20.53
   Esperar a linha «Serving HTTP on 10.10.20.53 port 80» antes do passo seguinte.
   sudo ip netns exec r1 nft 'add chain ip nat prerouting { type nat hook prerouting priority dstnat; }'
   sudo ip netns exec r1 nft add rule ip nat prerouting iifname "r1-isp" tcp dport 80 dnat to 10.10.20.53
   sudo ip netns exec isp python3 -c "import urllib.request as u; print(u.urlopen('http://203.0.113.2/').status)"
   sudo ip netns exec r1 nft list table ip nat

   Saída de exemplo (didáctica):

   200
   table ip nat {
     chain postrouting { type nat hook postrouting priority srcnat; policy accept;
       oifname "r1-isp" ip saddr 10.10.0.0/16 masquerade }
     chain prerouting { type nat hook prerouting priority dstnat; policy accept;
       iifname "r1-isp" tcp dport 80 dnat to 10.10.20.53 }
   }

Critérios de sucesso

• pc-adm alcança 198.51.100.10 apenas com NAT activo.
• O isp vê a origem 203.0.113.2.
• O portal responde no endereço público só na porta 80.

Como desfazer (reversão)

• sudo ip netns exec r1 nft delete table ip nat
• sudo ip -n r1 route del default via 203.0.113.1
• Na consola C, terminar o servidor de teste com Ctrl+C (termina só esse processo).

Alternativa em papel: tarefas e respostas esperadas

Porque o ping falhou antes do NAT?

O servidor externo recebeu o pedido com origem 10.10.10.10 (privada); não tem rota para ela, por isso a resposta não volta.

Escreva a regra de NAT de destino para publicar SSH do srv na porta 2222 externa.

iifname "r1-isp" tcp dport 2222 dnat to 10.10.20.53:22 — e justificar se é mesmo necessário; preferir VPN (módulo 7) a publicar SSH.

O NAT protege o portal publicado?

Não. Quem chega à porta 80 pública chega ao portal. A protecção vem de firewall, actualizações, configuração segura e monitorização.

Verifique o que aprendeu

Questão 1

O mascaramento permite que muitos postos partilhem um endereço público porque:

1. Usam MAC diferentes
2. O encaminhador distingue as ligações pelas portas e guarda estado
3. O operador atribui mais endereços
4. Usa DNS

Questão 2

Qual afirmação é correcta?

1. NAT é uma firewall completa
2. NAT de destino expõe um serviço interno e exige protecção adicional
3. NAT cifra o tráfego
4. NAT elimina a necessidade de rotas

Em leitura fácil

• Endereços internos não vão para a internet.
• O NAT troca-os pelo endereço da instituição.
• Publicar um serviço abre uma porta: proteja-a.

Fontes

• IETF RFC 3022 — Traditional IP Network Address Translator (https://www.rfc-editor.org/rfc/rfc3022)
• IETF RFC 1918 — Address Allocation for Private Internets (https://www.rfc-editor.org/rfc/rfc1918)
• Projecto nftables — wiki oficial (https://wiki.nftables.org/)

Duração: 80 minutos (explicação 20, prática guiada 50, verificação 10). Resultados dos TdR trabalhados: Diagnóstico, desempenho e disponibilidade; Documentação: diagramas, procedimentos (SOP) e contingência.

Objectivos

• Diagnosticar ausência de rota, rota assimétrica, ciclo de encaminhamento e NAT em falta.
• Usar traceroute, ip route get, tcpdump e vtysh em sequência.
• Registar causa raiz e prevenção.

Quatro avarias típicas

Sem rota: o encaminhador responde «rede inalcançável» ou descarta. Rota assimétrica: a ida vai por um caminho e a volta por outro, e uma firewall com estado descarta a resposta. Ciclo: dois encaminhadores apontam um para o outro; o traceroute mostra endereços a repetir até o TTL acabar. NAT em falta: o pacote sai com origem privada e a resposta nunca volta.

Em cada caso a prova é diferente: ip route get mostra a decisão; traceroute mostra o caminho; tcpdump nos dois lados mostra onde o pacote desaparece; show ip ospf neighbor mostra se o protocolo está de pé.

Caso fictício

Segunda-feira de manhã na DPE (fictícia): após uma alteração nocturna não documentada, a delegação não chega ao servidor. O formador provoca a avaria; as duplas encontram-na.

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. Prepare rotas estáticas correctas (sem FRR) e confirme que funcionam.

   sudo ip -n r1 route add 10.20.10.0/24 via 10.255.0.2
   sudo ip -n r2 route add 10.10.0.0/16 via 10.255.0.1
   sudo ip netns exec pc-del ping -c 1 10.10.20.53

2. Formador: provoque um ciclo com duas rotas específicas erradas: o r2 envia 10.10.20.0/24 para o r1 (correcto) e o r1 recebe uma rota /32 que devolve 10.10.20.53 ao r2.

   sudo ip -n r2 route add 10.10.20.0/24 via 10.255.0.1
   sudo ip -n r1 route add 10.10.20.53/32 via 10.255.0.2

3. Duplas: diagnostique.

   sudo ip netns exec pc-del traceroute -n -m 6 10.10.20.53
   sudo ip -n r1 route get 10.10.20.53

   Saída de exemplo (didáctica):

    1  10.20.10.1
    2  10.255.0.1
    3  10.255.0.2
    4  10.255.0.1
    5  10.255.0.2
    6  10.255.0.1
   10.10.20.53 via 10.255.0.2 dev r1-r2 src 10.255.0.1

4. Corrija retirando a rota /32 indevida e prove.

   sudo ip -n r1 route del 10.10.20.53/32
   sudo ip netns exec pc-del traceroute -n 10.10.20.53

   Saída de exemplo (didáctica):

    1  10.20.10.1
    2  10.255.0.1
    3  10.10.20.53

Critérios de sucesso

• O formando reconhece o ciclo pelos endereços alternados no traceroute.
• Usa ip route get para encontrar a rota /32 responsável.
• Entrega ficha com causa raiz e prevenção.

Como desfazer (reversão)

• sudo ip -n r2 route del 10.10.20.0/24 via 10.255.0.1
• sudo ip -n r1 route del 10.20.10.0/24; sudo ip -n r2 route del 10.10.0.0/16
• Ou reconstruir: sudo ./lab-remover.sh && sudo ./lab-base.sh

Alternativa em papel: tarefas e respostas esperadas

Como se reconhece um ciclo num traceroute?

Os mesmos endereços repetem-se alternadamente (10.255.0.1, 10.255.0.2, …) até ao limite de saltos.

Porque a rota /32 venceu a rota ligada /24?

Prefixo mais longo: /32 é mais específico que 10.10.20.0/24, mesmo sendo errado.

Proponha duas medidas de prevenção para o caso de segunda-feira.

Alterações só com pedido aprovado e janela registada; cópia da configuração antes e depois (módulo 5 e 11); teste de verificação no fim da alteração; plano de reversão.

Verifique o que aprendeu

Questão 1

O pacote sai com origem 10.10.10.10 para a internet e nunca volta. Suspeito principal?

1. Cabo
2. NAT de origem em falta
3. DNS
4. VLAN

Questão 2

Numa rota assimétrica com firewall com estado, o que costuma acontecer?

1. Funciona melhor
2. A firewall descarta respostas porque não viu o início da ligação
3. O DNS falha
4. O STP bloqueia

Em leitura fácil

• Se os mesmos endereços se repetem, há um círculo.
• A rota mais exacta ganha, mesmo errada.
• Registe o que causou o problema.

Fontes

• 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)
• FRRouting — documentação oficial (zebra, staticd, ospfd, vrrpd, vtysh) (https://docs.frrouting.org/)
• IETF RFC 792 — Internet Control Message Protocol (https://www.rfc-editor.org/rfc/rfc792)

Duração: 70 minutos (explicação 20, prática guiada 40, verificação 10). Resultados dos TdR trabalhados: LAN, WAN, WLAN, virtualização e nuvem; Configurar routers, switches, pontos de acesso e firewalls.

Objectivos

• Explicar bandas (2,4, 5 e 6 GHz), canais, largura de canal e SSID.
• Distinguir as gerações 802.11 pelo que mudam na prática, sem decorar números de marketing.
• Ler uma lista de redes vizinhas e identificar sobreposição de canais.

Rádio é um meio partilhado

No Wi-Fi todos os equipamentos no mesmo canal partilham o mesmo ar: só um transmite de cada vez. A banda de 2,4 GHz alcança mais longe e atravessa melhor paredes, mas tem só três canais sem sobreposição (1, 6 e 11) e muita interferência (micro-ondas, Bluetooth). A banda de 5 GHz tem muitos mais canais e menos interferência, com menor alcance. A de 6 GHz, quando permitida pela regulação nacional e suportada pelos equipamentos, acrescenta canais limpos.

SSID é o nome da rede; BSSID é o endereço do ponto de acesso que o anuncia. Canais mais largos (40, 80 MHz) dão mais débito a um cliente, mas consomem mais espectro e aumentam a interferência entre pontos de acesso vizinhos. As gerações 802.11n/ac/ax (Wi-Fi 4/5/6) melhoram eficiência e débito; o débito real é normalmente bem inferior ao máximo teórico anunciado.

Regulação

A potência e os canais permitidos dependem do regulador nacional; o equipamento deve estar configurado com o código de país correcto. Confirme com a entidade reguladora das comunicações antes de usar canais ou potências fora do habitual.

Caso fictício

Na sala de reuniões da DPE (fictícia), o Wi-Fi fica lento quando há reunião. O técnico faz um levantamento e descobre cinco redes vizinhas na banda de 2,4 GHz.

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)

• Um portátil Linux de prática com placa Wi-Fi (só leitura, sem se ligar a nenhuma rede) ou, na falta dele, a saída de exemplo abaixo.

Passos

1. Liste as redes vizinhas apenas em modo de leitura (não se liga a nenhuma).

   nmcli -f SSID,BSSID,CHAN,FREQ,SIGNAL,SECURITY device wifi list

   Saída de exemplo (didáctica):

   SSID          BSSID              CHAN  FREQ      SIGNAL  SECURITY
   DPE-Func      02:00:00:00:10:01  6     2437 MHz  78      WPA2 WPA3
   DPE-Visit     02:00:00:00:10:02  6     2437 MHz  77      WPA2
   Loja-Vizinha  02:00:00:00:99:01  4     2427 MHz  60      WPA2
   Casa-12       02:00:00:00:99:02  9     2452 MHz  45      WPA2
   DPE-Func      02:00:00:00:20:01  36    5180 MHz  52      WPA2 WPA3

2. Se a sala não tiver um ponto de acesso de prática desligado da rede institucional, faça os passos em papel: as saídas de exemplo e as respostas esperadas estão abaixo.

3. Registe numa tabela: SSID, canal, banda, sinal, segurança. Marque as sobreposições (canais a menos de 5 de distância em 2,4 GHz sobrepõem-se).

Critérios de sucesso

• O formando identifica que os canais 4 e 9 sobrepõem-se ao canal 6 da DPE.
• Propõe mover os clientes para 5 GHz e manter 2,4 GHz em 1, 6 ou 11.

Como desfazer (reversão)

• Nenhuma: a prática é só de leitura. Não se alteram redes de terceiros.

Alternativa em papel: tarefas e respostas esperadas

Com a saída de exemplo, que redes interferem com DPE-Func em 2,4 GHz?

Loja-Vizinha (canal 4) e Casa-12 (canal 9) sobrepõem-se parcialmente ao canal 6; DPE-Visit está no mesmo canal 6 (partilha o tempo de ar).

Proponha uma melhoria sem comprar equipamento.

Anunciar DPE-Func também e preferencialmente em 5 GHz (canal 36 já existe), usar canal de 20 MHz em 2,4 GHz, manter visitantes e funcionários no mesmo ponto mas limitar o débito de visitantes (módulo 10).

SSID vs BSSID: qual identifica o aparelho?

O BSSID (endereço do rádio). Vários pontos de acesso podem anunciar o mesmo SSID.

Verifique o que aprendeu

Questão 1

Quais são os canais de 2,4 GHz sem sobreposição habitualmente usados?

1. 1, 2 e 3
2. 1, 6 e 11
3. 36, 40 e 44
4. Todos

Questão 2

Porque é que um canal de 80 MHz nem sempre é melhor?

1. É ilegal
2. Ocupa mais espectro e aumenta a interferência entre vizinhos
3. Não funciona em 5 GHz
4. Reduz a segurança

Em leitura fácil

• O Wi-Fi usa rádio, partilhado por todos.
• 2,4 GHz costuma chegar mais longe.
• 5 GHz tem mais canais e, perto do ponto de acesso, costuma dar mais débito.
• Evite redes vizinhas no mesmo canal.

Fontes

• IEEE 802.11 — Wireless LAN (https://standards.ieee.org/ieee/802.11/)
• NIST SP 800-153 — Guidelines for Securing WLANs (https://csrc.nist.gov/pubs/sp/800/153/final)

Duração: 75 minutos (explicação 20, prática guiada 45, verificação 10). Resultados dos TdR trabalhados: Conceber, configurar e administrar redes pequenas, médias e grandes; LAN, WAN, WLAN, virtualização e nuvem.

Objectivos

• Planear cobertura e capacidade para uma sala ou piso.
• Estimar número de pontos de acesso pela capacidade e não só pela área.
• Documentar o plano com mapa textual e tabela de canais.

Cobertura não é capacidade

Cobertura: o sinal chega com qualidade suficiente (referência prática de –67 dBm ou melhor para dados e voz). Capacidade: o ponto de acesso aguenta o número de utilizadores e o tipo de uso. Uma sala de formação com 40 portáteis precisa de capacidade, mesmo que um só ponto a cubra.

Método: 1) listar zonas e uso (formação, escritórios, recepção); 2) estimar clientes simultâneos e débito por cliente; 3) dividir pela capacidade útil prudente de cada rádio (confirmar na ficha técnica e testar no local); 4) posicionar com sobreposição de 15–20% entre células; 5) atribuir canais alternados; 6) validar com levantamento no local.

Caso fictício

A DPE (fictícia) vai equipar o primeiro piso: sala de formação (40 formandos), três escritórios (12 pessoas), recepção (visitantes, até 15). Pede-se o plano.

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)

• Planta textual do piso: corredor de 30 m no sentido este–oeste; a norte, sala de formação (12 × 8 m) a oeste e três escritórios (4 × 4 m) a leste; a sul, recepção (8 × 6 m) ao centro. Paredes de alvenaria entre salas.

Passos

1. Faça a folha de capacidade em Python (sem instalar nada) e ajuste os números.

   cat > /tmp/capacidade.py <<'EOF'
   zonas = {'formacao': (40, 2.0), 'escritorios': (12, 3.0), 'recepcao': (15, 1.0)}  # clientes, Mbit/s por cliente
   capacidade_util_por_radio = 60  # Mbit/s, valor prudente a confirmar no local
   for z, (n, d) in zonas.items():
       total = n * d
       radios = -(-total // capacidade_util_por_radio)
       print(f'{z}: {total:.0f} Mbit/s -> {radios:.0f} rádio(s)')
   EOF
   python3 /tmp/capacidade.py

   Saída de exemplo (didáctica):

   formacao: 80 Mbit/s -> 2 rádio(s)
   escritorios: 36 Mbit/s -> 1 rádio(s)
   recepcao: 15 Mbit/s -> 1 rádio(s)

2. Transforme o resultado num plano: posições, bandas e canais. Use a tabela do papel como modelo.

Critérios de sucesso

• O plano indica 3 pontos de acesso (2 rádios de 5 GHz na formação podem ser 1 ponto com dois rádios ou 2 pontos), canais alternados e justificação.
• Assume que os valores de capacidade são estimativas a validar no local.

Como desfazer (reversão)

• rm -f /tmp/capacidade.py

Alternativa em papel: tarefas e respostas esperadas

Proponha posições e canais.

PA1 no tecto da sala de formação, 5 GHz canal 36 e 2,4 GHz canal 1; PA2 na mesma sala, extremidade oposta, 5 GHz canal 44 (se a capacidade exigir); PA3 no corredor junto aos escritórios, 5 GHz canal 52 (ou 149 conforme regulação) e 2,4 GHz canal 6; recepção servida por PA3 ou PA4 com 2,4 GHz canal 11 e SSID de visitantes.

Porque não pôr um único ponto de acesso potente no corredor?

Paredes de alvenaria atenuam; e um só rádio divide o tempo por todos os clientes: 67 clientes num rádio dão mau desempenho, mesmo com bom sinal.

Como validar o plano depois da instalação?

Levantamento de sinal em cada sala (nível e canal), teste de débito com vários clientes, registo em tabela e ajuste de potência/canais.

Verifique o que aprendeu

Questão 1

Uma sala com 40 portáteis tem bom sinal mas é lenta. A causa mais provável é:

1. Cobertura insuficiente
2. Capacidade insuficiente
3. DNS
4. Cabo

Questão 2

Porque aumentar a potência ao máximo é má prática?

1. Gasta electricidade
2. Cria células enormes que interferem com vizinhos e clientes ficam presos a pontos distantes
3. É proibido sempre
4. Desliga o 5 GHz

Em leitura fácil

• Contar quantas pessoas vão usar o Wi-Fi.
• Muitas pessoas precisam de mais pontos de acesso.
• Testar no local depois de instalar.

Fontes

• IEEE 802.11 — Wireless LAN (https://standards.ieee.org/ieee/802.11/)
• NIST SP 800-153 — Guidelines for Securing WLANs (https://csrc.nist.gov/pubs/sp/800/153/final)
• Python 3 — módulo ipaddress e subprocess (documentação oficial) (https://docs.python.org/3/library/ipaddress.html)

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; Segurança desde a concepção; Protecção de dados e identidades: MFA e cifra.

Objectivos

• Configurar uma rede sem fios com WPA3-Personal (SAE) e modo de transição WPA2/WPA3.
• Separar funcionários e visitantes por SSID e VLAN.
• Aplicar boas práticas: gestão desligada da rede de visitantes, WPS desligado, firmware actualizado.

Protecções de uma rede sem fios

WEP e WPA (TKIP) estão quebrados e não devem ser usados. WPA2 com AES/CCMP é o mínimo; WPA3 substitui a troca de chave partilhada por SAE, resistente a ataques de dicionário fora de linha, e exige protecção de tramas de gestão (PMF). O modo de transição permite clientes antigos WPA2 ao lado de WPA3, com menor protecção para esses.

Boas práticas: SSID de visitantes numa VLAN própria (30) só com saída para a internet; isolamento de clientes nos visitantes; frase-passe longa e mudada periodicamente para visitantes; WPS desligado; interface de gestão do ponto de acesso só na VLAN 99; firmware actualizado.

Caso fictício

O ponto de acesso da recepção da DPE (fictícia) usa WPA2 com a frase-passe «dpe2020» há quatro anos, partilhada com todos os visitantes e funcionários. Pede-se uma configuração nova.

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)

• Ponto de acesso de prática com hostapd num computador Linux com placa Wi-Fi compatível com modo AP, ligado por cabo apenas à rede de prática. VLAN 10 (funcionários) e 30 (visitantes).

Passos

1. Se a sala não tiver um ponto de acesso de prática desligado da rede institucional, faça os passos em papel: as saídas de exemplo e as respostas esperadas estão abaixo.

2. Ficheiro hostapd para funcionários (WPA2/WPA3 transição, PMF). Substitua wlan0 pelo nome da sua placa. A frase-passe é só de prática.

   # /etc/hostapd/dpe-func.conf
   interface=wlan0
   bridge=br-func
   driver=nl80211
   country_code=MZ
   ssid=DPE-Func-Pratica
   hw_mode=a
   channel=36
   ieee80211n=1
   ieee80211ac=1
   wpa=2
   wpa_key_mgmt=WPA-PSK SAE
   rsn_pairwise=CCMP
   ieee80211w=1
   sae_require_mfp=1
   wpa_passphrase=Pratica-Frase-Longa-Nao-Real-2026
   wps_state=0

3. Visitantes: SSID próprio, isolamento de clientes, ligação à VLAN 30.

   # /etc/hostapd/dpe-visit.conf (excerto)
   ssid=DPE-Visit-Pratica
   bridge=br-visit
   ap_isolate=1
   wpa=2
   wpa_key_mgmt=SAE
   ieee80211w=2
   wpa_passphrase=Visitas-Semana-40-Pratica

4. Arranque em primeiro plano para ver erros e confirme os clientes associados.

   sudo hostapd -d /etc/hostapd/dpe-func.conf
   sudo hostapd_cli -i wlan0 all_sta

   Saída de exemplo (didáctica):

   wlan0: AP-ENABLED
   wlan0: STA 02:00:00:00:aa:01 IEEE 802.11: associated
   wlan0: AP-STA-CONNECTED 02:00:00:00:aa:01

Critérios de sucesso

• Cliente WPA3 associa-se com PMF.
• Cliente de visitantes não alcança outro cliente de visitantes (isolamento) nem a VLAN 10.
• A gestão do ponto de acesso não é acessível a partir da VLAN 30.

Como desfazer (reversão)

• Parar o hostapd (Ctrl+C) e apagar os ficheiros de prática em /etc/hostapd/.
• Nunca reutilizar as frases-passe de prática em redes reais.

Alternativa em papel: tarefas e respostas esperadas

Liste quatro problemas da configuração do caso.

Frase curta e previsível; partilhada entre visitantes e funcionários (mesma rede); não mudada há anos; WPA2 sem PMF; provavelmente sem separação de VLAN nem isolamento.

O que muda o SAE em relação à chave partilhada do WPA2?

Com WPA2-PSK, quem captura o aperto de mão pode testar palavras fora de linha; com SAE cada tentativa exige interacção com o ponto de acesso, travando ataques de dicionário fora de linha.

Porque ap_isolate=1 nos visitantes?

Impede que um visitante ataque ou veja os dispositivos de outro visitante na mesma rede.

Verifique o que aprendeu

Questão 1

Qual é o mínimo aceitável hoje para uma rede de funcionários?

1. WEP
2. WPA com TKIP
3. WPA2 com AES, preferindo WPA3
4. Rede aberta com portal

Questão 2

Onde deve estar a interface de gestão do ponto de acesso?

1. Na rede de visitantes
2. Numa VLAN de gestão restrita
3. Aberta à internet
4. Em qualquer rede

Em leitura fácil

• Use WPA3 ou pelo menos WPA2.
• Visitantes numa rede separada.
• Frase-passe longa e mudada com frequência.

Fontes

• Wi-Fi Alliance — WPA3 Specification (https://www.wi-fi.org/discover-wi-fi/security)
• IEEE 802.11 — Wireless LAN (https://standards.ieee.org/ieee/802.11/)
• NIST SP 800-153 — Guidelines for Securing WLANs (https://csrc.nist.gov/pubs/sp/800/153/final)

Duração: 80 minutos (explicação 20, prática guiada 50, verificação 10). Resultados dos TdR trabalhados: Serviços de rede: DHCP, DNS, VPN, NAT, VLAN e autenticação; Protecção de dados e identidades: MFA e cifra.

Objectivos

• Explicar 802.1X com EAP e RADIUS: suplicante, autenticador, servidor.
• Configurar um servidor FreeRADIUS de prática e testar com radtest.
• Comparar chave partilhada, 802.1X e autenticação por certificado.

Cada pessoa com a sua credencial

Com uma chave partilhada, quando alguém sai da instituição é preciso mudar a chave de todos. Com 802.1X cada utilizador (ou dispositivo) autentica-se individualmente: o cliente (suplicante) fala EAP com o ponto de acesso ou comutador (autenticador), que pergunta ao servidor RADIUS se aceita. Pode-se desactivar uma conta sem afectar as outras e atribuir VLAN por perfil.

Os métodos mais usados são EAP-TLS (certificado em cada dispositivo, mais forte) e PEAP ou EAP-TTLS (palavra-passe dentro de um túnel TLS; o cliente tem de validar o certificado do servidor, senão uma rede falsa recolhe credenciais). O RADIUS deve ficar na VLAN de servidores, com segredo partilhado forte entre autenticador e servidor.

Caso fictício

A DPE (fictícia) quer que o acesso sem fios dos funcionários seja individual e que as contas de quem sai sejam desactivadas no mesmo dia.

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)

• srv (10.10.20.53) com FreeRADIUS de prática; r1 faz de «autenticador» e envia pedidos de teste com radtest. Pacotes adicionais: freeradius e freeradius-utils (repositório Debian).

Passos

1. Declare o cliente RADIUS (o autenticador r1) com um segredo de prática.

   sudo tee -a /etc/freeradius/3.0/clients.conf <<'EOF'
   client r1-pratica {
       ipaddr = 10.10.20.1
       secret = SegredoRadiusDePratica-Longo-2026
   }
   EOF

2. Crie dois utilizadores de prática (fictícios).

   sudo tee -a /etc/freeradius/3.0/mods-config/files/authorize <<'EOF'
   ana.pratica  Cleartext-Password := "Senha-Pratica-Ana-1"
                Tunnel-Type = VLAN, Tunnel-Medium-Type = IEEE-802, Tunnel-Private-Group-Id = 10
   EOF

3. Arranque o servidor em modo de depuração dentro do srv.

   sudo ip netns exec srv freeradius -X

   Saída de exemplo (didáctica):

   Listening on auth address 10.10.20.53 port 1812 bound to server default
   Ready to process requests

4. Noutra consola, teste a partir do r1.

   sudo ip netns exec r1 radtest ana.pratica Senha-Pratica-Ana-1 10.10.20.53 0 SegredoRadiusDePratica-Longo-2026
   sudo ip netns exec r1 radtest ana.pratica errada 10.10.20.53 0 SegredoRadiusDePratica-Longo-2026

   Saída de exemplo (didáctica):

   Received Access-Accept Id 12 from 10.10.20.53:1812 to 10.10.20.1:40001 length 38
           Tunnel-Private-Group-Id:0 = "10"
   Received Access-Reject Id 13 from 10.10.20.53:1812 to 10.10.20.1:40002 length 20

Critérios de sucesso

• Credencial correcta → Access-Accept com VLAN 10; errada → Access-Reject.
• O formando explica onde, numa rede real, ficariam suplicante, autenticador e servidor.

Como desfazer (reversão)

• Retirar as linhas acrescentadas a clients.conf e authorize; parar o freeradius (Ctrl+C).
• As senhas em texto claro servem só para a prática; em produção usar directório de utilizadores e EAP-TLS ou PEAP com validação de certificado.

Alternativa em papel: tarefas e respostas esperadas

Identifique suplicante, autenticador e servidor no Wi-Fi da DPE.

Suplicante: portátil ou telemóvel do funcionário. Autenticador: ponto de acesso. Servidor: RADIUS na VLAN 20 (10.10.20.53).

Porque é perigoso não validar o certificado do servidor em PEAP?

Um ponto de acesso falso com o mesmo SSID pode apresentar outro certificado e recolher as credenciais dos funcionários.

O que acontece à rede quando a Ana sai da instituição?

Desactiva-se só a conta dela; ninguém mais muda de credencial.

Verifique o que aprendeu

Questão 1

Em 802.1X, quem decide se o utilizador entra?

1. O ponto de acesso sozinho
2. O servidor de autenticação (RADIUS)
3. O DNS
4. O cliente

Questão 2

Qual método é mais forte?

1. Chave partilhada
2. EAP-TLS com certificados por dispositivo
3. Rede aberta
4. Filtragem por MAC

Em leitura fácil

• Cada pessoa entra com o seu nome e senha.
• Quem sai, perde só o seu acesso.
• Confirme que a rede é mesmo da instituição.

Fontes

• IEEE 802.1X — Port-Based Network Access Control (https://standards.ieee.org/ieee/802.1X/)
• IETF RFC 2865 — RADIUS (https://www.rfc-editor.org/rfc/rfc2865)
• NIST SP 800-153 — Guidelines for Securing WLANs (https://csrc.nist.gov/pubs/sp/800/153/final)

Duração: 80 minutos (explicação 20, prática guiada 50, verificação 10). Resultados dos TdR trabalhados: Diagnóstico, desempenho e disponibilidade.

Objectivos

• Diagnosticar falhas de associação, autenticação e endereçamento em Wi-Fi.
• Distinguir interferência, sinal fraco e falta de capacidade pelas evidências.
• Registar o diagnóstico com recomendações.

Em que fase falha?

Uma ligação sem fios passa por: descoberta (o cliente vê o SSID), associação, autenticação (chave ou 802.1X), obtenção de endereço (DHCP) e tráfego. Cada fase tem evidências próprias nos registos do cliente e do ponto de acesso. «Não liga» pode ser frase-passe errada, servidor RADIUS inalcançável, âmbito DHCP esgotado ou canal saturado.

Sinais: sinal abaixo de cerca de –75 dBm → cobertura; muitas retransmissões e ruído alto com sinal bom → interferência; muitos clientes e tempo de ar ocupado → capacidade.

Caso fictício

Três queixas na DPE (fictícia): (a) um visitante não consegue ligar; (b) funcionários na sala de formação ligam mas não navegam; (c) no escritório do fundo a ligação cai.

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)

• Registos de exemplo de um cliente Linux (wpa_supplicant/NetworkManager) e de um ponto de acesso hostapd, fornecidos abaixo.

Passos

1. Leia o registo (a).

   Saída de exemplo (didáctica):

   wlan0: SME: Trying to authenticate with 02:00:00:00:10:02 (SSID='DPE-Visit')
   wlan0: Trying to associate with 02:00:00:00:10:02
   wlan0: Associated with 02:00:00:00:10:02
   wlan0: WPA: 4-Way Handshake failed - pre-shared key may be incorrect
   wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="DPE-Visit" auth_failures=1

2. Leia o registo (b).

   Saída de exemplo (didáctica):

   wlan0: CTRL-EVENT-CONNECTED - Connection to 02:00:00:00:10:01 completed
   NetworkManager: dhcp4 (wlan0): activation: beginning transaction (timeout in 45 seconds)
   NetworkManager: dhcp4 (wlan0): state changed timeout
   kea-dhcp4: ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 02:00:00:00:aa:37] failed to allocate an IPv4 address after 64 attempt(s)

3. Leia o registo (c).

   iw dev wlan0 link

   Saída de exemplo (didáctica):

   Connected to 02:00:00:00:20:01 (on wlan0)
           SSID: DPE-Func
           freq: 5260
           signal: -81 dBm
           tx bitrate: 6.5 MBit/s

4. Para cada caso escreva: fase que falha, evidência, causa provável, acção, verificação.

Critérios de sucesso

• (a) autenticação — frase-passe; (b) endereçamento — âmbito DHCP esgotado; (c) cobertura — sinal fraco.
• Cada acção proposta tem verificação.

Como desfazer (reversão)

• Nenhuma: análise de registos de exemplo.

Alternativa em papel: tarefas e respostas esperadas

Caso (a).

Fase: autenticação (aperto de mão de 4 vias falhou). Causa provável: frase-passe errada ou mudada. Acção: confirmar a frase-passe da semana com o visitante. Verificação: CTRL-EVENT-CONNECTED.

Caso (b).

Fase: endereçamento. Evidência: DHCP expira e o Kea não consegue atribuir endereço. Causa: âmbito esgotado (40 portáteis + telemóveis). Acção: alargar o âmbito ou reduzir o tempo de concessão para a sala de formação (módulo 5). Verificação: cliente recebe endereço e navega.

Caso (c).

Fase: tráfego/cobertura. Evidência: sinal –81 dBm e débito 6,5 Mbit/s. Causa: fora da célula útil. Acção: acrescentar ou reposicionar ponto de acesso; verificar paredes. Verificação: novo levantamento com sinal ≥ –67 dBm.

Verifique o que aprendeu

Questão 1

O cliente associa-se mas o aperto de mão de 4 vias falha. Causa mais provável?

1. DNS
2. Frase-passe errada
3. Cabo
4. Rota por omissão

Questão 2

Sinal –55 dBm, mas muitas retransmissões e lentidão. Suspeito?

1. Cobertura
2. Interferência ou saturação do canal
3. Frase-passe
4. Certificado

Em leitura fácil

• Primeiro veja em que passo falha.
• Senha errada, falta de endereço ou sinal fraco são coisas diferentes.
• Escreva a prova de cada conclusão.

Fontes

• IEEE 802.11 — Wireless LAN (https://standards.ieee.org/ieee/802.11/)
• ISC Kea DHCP — Administrator Reference Manual (https://kea.readthedocs.io/)
• NIST SP 800-153 — Guidelines for Securing WLANs (https://csrc.nist.gov/pubs/sp/800/153/final)

Duração: 70 minutos (explicação 20, prática guiada 40, verificação 10). Resultados dos TdR trabalhados: Serviços de rede: DHCP, DNS, VPN, NAT, VLAN e autenticação.

Objectivos

• Configurar uma zona DNS autoritativa com BIND e um âmbito DHCP com Kea.
• Explicar o processo DHCP (DORA) e os registos DNS A, AAAA, PTR, CNAME, MX.
• Verificar os dois serviços com dig e com um cliente DHCP.

DHCP

O cliente envia DHCPDISCOVER em difusão, o servidor responde DHCPOFFER, o cliente pede com DHCPREQUEST e o servidor confirma com DHCPACK (DORA). A concessão tem tempo limitado. Como a difusão não atravessa encaminhadores, um servidor central precisa de agentes de reencaminhamento (DHCP relay) em cada VLAN. Endereços de servidores e equipamentos de rede são fixos ou reservados.

DNS

Um servidor autoritativo responde pela sua zona (dpe.example); um resolvedor recursivo procura respostas para os clientes. Registos: A (nome → IPv4), AAAA (→ IPv6), PTR (IP → nome), CNAME (sinónimo), MX (correio). O número de série da zona deve aumentar em cada alteração. Não se deve deixar um resolvedor recursivo aberto à internet.

Caso fictício

Na DPE (fictícia), os postos da Administração têm endereços escritos à mão e colisões frequentes; os utilizadores decoram endereços IP. Pede-se DHCP para a VLAN 10 e DNS interno.

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).
• Kea corre no r1 (serve a VLAN 10 directamente, sem relay nesta prática); BIND corre no srv. Pacotes: kea-dhcp4-server, bind9, dnsutils, isc-dhcp-client.

Passos

1. Configuração Kea de prática para a VLAN 10.

   sudo tee /tmp/kea-dpe.json <<'EOF'
   { "Dhcp4": {
     "interfaces-config": { "interfaces": [ "r1-pc-adm" ] },
     "lease-database": { "type": "memfile", "name": "/tmp/kea-leases4.csv" },
     "valid-lifetime": 3600,
     "subnet4": [ { "id": 10, "subnet": "10.10.10.0/24",
        "pools": [ { "pool": "10.10.10.100 - 10.10.10.199" } ],
        "option-data": [
          { "name": "routers", "data": "10.10.10.1" },
          { "name": "domain-name-servers", "data": "10.10.20.53" },
          { "name": "domain-name", "data": "dpe.example" } ] } ] } }
   EOF
   sudo ip netns exec r1 kea-dhcp4 -t /tmp/kea-dpe.json
   Consola D (deixar aberta): sudo ip netns exec r1 kea-dhcp4 -c /tmp/kea-dpe.json
   Esperar no registo da consola D a mensagem de arranque do servidor DHCPv4 antes de pedir endereço.

2. No pc-adm, retire o endereço fixo e peça um por DHCP.

   sudo ip -n pc-adm addr flush dev pc-adm-r1
   sudo ip netns exec pc-adm dhclient -v pc-adm-r1
   sudo ip -n pc-adm -brief addr

   Saída de exemplo (didáctica):

   DHCPDISCOVER on pc-adm-r1 to 255.255.255.255 port 67
   DHCPOFFER of 10.10.10.100 from 10.10.10.1
   DHCPREQUEST for 10.10.10.100 on pc-adm-r1 to 255.255.255.255 port 67
   DHCPACK of 10.10.10.100 from 10.10.10.1
   pc-adm-r1@if5  UP  10.10.10.100/24

3. Zona DNS de prática no srv.

   sudo mkdir -p /tmp/bind && sudo tee /tmp/bind/named.conf <<'EOF'
   options { directory "/tmp/bind"; listen-on { 10.10.20.53; }; recursion no; allow-transfer { none; }; pid-file "/tmp/bind/named.pid"; };
   zone "dpe.example" { type primary; file "db.dpe.example"; };
   EOF
   sudo tee /tmp/bind/db.dpe.example <<'EOF'
   $TTL 3600
   @   IN SOA ns1.dpe.example. ti.dpe.example. ( 2026092701 3600 900 604800 300 )
       IN NS  ns1.dpe.example.
   ns1 IN A   10.10.20.53
   srv IN A   10.10.20.53
   intranet IN CNAME srv
   r1  IN A   10.10.99.1
   EOF
   sudo named-checkconf /tmp/bind/named.conf && sudo named-checkzone dpe.example /tmp/bind/db.dpe.example
   Consola E (deixar aberta): sudo ip netns exec srv named -u bind -c /tmp/bind/named.conf -g
   Esperar na consola E a linha «running» antes de consultar.

   Saída de exemplo (didáctica):

   zone dpe.example/IN: loaded serial 2026092701
   OK

4. Teste a resolução a partir do pc-adm.

   sudo ip netns exec pc-adm dig @10.10.20.53 intranet.dpe.example +short

   Saída de exemplo (didáctica):

   srv.dpe.example.
   10.10.20.53

Critérios de sucesso

• pc-adm recebe endereço do âmbito 10.10.10.100–199, porta 10.10.10.1 e DNS 10.10.20.53.
• intranet.dpe.example resolve para 10.10.20.53.
• named-checkzone devolve OK.

Como desfazer (reversão)

• Terminar com Ctrl+C o kea-dhcp4 (consola D) e o named (consola E) — termina só esses processos, sem pkill genérico.
• rm -rf /tmp/bind /tmp/kea-dpe.json /tmp/kea-leases4.csv
• sudo ip netns exec pc-adm dhclient -r pc-adm-r1; sudo ip -n pc-adm addr add 10.10.10.10/24 dev pc-adm-r1; sudo ip -n pc-adm route replace default via 10.10.10.1

Alternativa em papel: tarefas e respostas esperadas

Ordene e explique as mensagens DORA.

DISCOVER (cliente procura servidor, difusão), OFFER (servidor propõe endereço), REQUEST (cliente aceita), ACK (servidor confirma a concessão).

Porque o âmbito começa em .100 e não em .2?

Reserva .1–.99 para porta de ligação, impressoras e equipamentos com endereço fixo ou reservado, evitando colisões.

Alterou-se a zona mas os clientes não vêem o novo registo. O que verificar?

Se o número de série aumentou; se a zona foi recarregada (rndc reload ou reinício); se as caches ainda têm o valor antigo (TTL).

Verifique o que aprendeu

Questão 1

Porque um servidor DHCP central precisa de relay nas outras VLAN?

1. Por causa do DNS
2. Porque a difusão DHCPDISCOVER não atravessa encaminhadores
3. Porque o DHCP usa TCP
4. Não precisa

Questão 2

Qual o risco de um servidor DNS recursivo aberto à internet?

1. Nenhum
2. Pode ser usado em ataques de amplificação e envenenamento de cache
3. Fica mais lento
4. Apaga a zona

Em leitura fácil

• O DHCP dá endereços automaticamente.
• O DNS troca nomes por números.
• Servidores e impressoras têm endereço fixo.

Fontes

• IETF RFC 2131 — Dynamic Host Configuration Protocol (https://www.rfc-editor.org/rfc/rfc2131)
• IETF RFC 1034/1035 — Domain Names (https://www.rfc-editor.org/rfc/rfc1034)
• ISC Kea DHCP — Administrator Reference Manual (https://kea.readthedocs.io/)
• ISC BIND 9 — Administrator Reference Manual (https://bind9.readthedocs.io/)

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

• Configurar sincronização de tempo com chrony e explicar porque importa.
• Centralizar registos com rsyslog num servidor.
• Reconhecer os campos de um registo syslog (facilidade, gravidade, hora, anfitrião).

Sem hora certa não há investigação

Para reconstruir um incidente é preciso ordenar acontecimentos de vários equipamentos. Se os relógios diferem minutos, a sequência fica errada. Também certificados, autenticação por códigos temporários (TOTP) e Kerberos dependem da hora. Usa-se NTP: um ou dois servidores internos sincronizam com fontes fiáveis e todos os equipamentos sincronizam com eles.

Registos locais perdem-se se o equipamento avariar ou for comprometido. Centralizá-los (syslog para 10.10.20.14) protege a evidência e facilita a análise. A retenção deve seguir a política da instituição e a legislação aplicável; registos podem conter dados pessoais e têm acesso restrito.

Caso fictício

Na análise de um acesso suspeito na DPE (fictícia), o registo do encaminhador diz 09:02 e o do servidor 08:47. Ninguém sabe o que aconteceu primeiro.

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: acrescentar endereço 10.10.20.14/24 ao srv.

Passos

1. Veja o estado de sincronização do computador de prática (o chrony corre no sistema, não no espaço de nomes).

   chronyc tracking
   chronyc sources -v

   Saída de exemplo (didáctica):

   Reference ID    : C0000201 (ntp1.exemplo)
   Stratum         : 3
   System time     : 0.000021 seconds fast of NTP time
   Leap status     : Normal

2. Configuração de um servidor NTP interno (excerto de /etc/chrony/chrony.conf para um servidor da DPE — só leitura nesta prática).

   pool pool.ntp.org iburst maxsources 4
   allow 10.10.0.0/16
   local stratum 10
   makestep 1 3

3. Servidor de registos: rsyslog a receber em UDP 514 dentro do srv.

   sudo ip -n srv addr add 10.10.20.14/24 dev srv-r1
   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
   sudo mkdir -p /tmp/registos
   Consola F (deixar aberta): sudo ip netns exec srv rsyslogd -n -f /tmp/rsyslog-srv.conf -i /tmp/rsyslog-srv.pid

4. Envie um registo de teste a partir do r1 e confirme a chegada.

   sudo ip netns exec r1 logger -n 10.10.20.14 -P 514 -d -t teste-dpe -p local0.warning 'Teste de registo centralizado'
   sudo cat /tmp/registos/*.log

   Saída de exemplo (didáctica):

   2026-09-28T09:00:01+02:00 r1 teste-dpe: Teste de registo centralizado

Critérios de sucesso

• chronyc tracking mostra Leap status Normal.
• O registo de teste chega ao servidor com hora e origem.

Como desfazer (reversão)

• Terminar o rsyslogd com 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

Explique porque o caso não se resolve sem NTP.

Com 15 minutos de diferença não se sabe se o acesso ao servidor foi antes ou depois do evento no encaminhador; a sequência causal fica incerta.

Decomponha <180>: facilidade e gravidade.

180 = 22 × 8 + 4: facilidade 22 (local6), gravidade 4 (warning).

Duas regras de protecção dos registos centralizados.

Acesso restrito a quem precisa e registado; retenção definida pela política e pela lei; integridade (cópias, envio em TLS quando disponível); hora sincronizada.

Verifique o que aprendeu

Questão 1

Porque se usam dois servidores NTP internos?

1. Para ir mais rápido
2. Para redundância e comparação de fontes
3. Porque a lei obriga
4. Para o DNS

Questão 2

Um atacante que entra num servidor apaga os registos locais. O que preserva a evidência?

1. Reiniciar o servidor
2. Registos enviados em tempo real para um servidor central protegido
3. Mudar a senha
4. Desligar o NTP

Em leitura fácil

• Todos os equipamentos devem ter a mesma hora.
• Os registos vão para um servidor central.
• Os registos são confidenciais.

Fontes

• IETF RFC 5905 — Network Time Protocol Version 4 (https://www.rfc-editor.org/rfc/rfc5905)
• IETF RFC 5424 — The Syslog Protocol (https://www.rfc-editor.org/rfc/rfc5424)
• chrony — documentação oficial (https://chrony-project.org/documentation.html)
• 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)

Duração: 75 minutos (explicação 20, prática guiada 45, verificação 10). Resultados dos TdR trabalhados: Diagnóstico, desempenho e disponibilidade.

Objectivos

• Explicar latência, variação de latência (jitter), perda e débito.
• Relacionar os requisitos de voz, vídeo e dados com esses indicadores.
• Observar o efeito de atraso e perda simulados com tc netem.

O que é qualidade para cada aplicação

Latência é o tempo de ida; jitter é a variação desse tempo; perda é a percentagem de pacotes que não chega; débito é a quantidade de dados por segundo. Transferências de ficheiros toleram latência mas querem débito. Voz tolera pouco débito mas é sensível a latência, jitter e perda: referências práticas usadas na indústria apontam para latência de ida até cerca de 150 ms e perda inferior a 1% para boa qualidade.

Qualidade de serviço (QoS) é o conjunto de técnicas para dar tratamento diferente a tráfego diferente quando há congestionamento: classificar, marcar, pôr em filas com prioridade e limitar. Não cria largura de banda: só decide quem espera. O módulo 10 aprofunda a marcação e o controlo de débito.

Caso fictício

Na delegação da DPE (fictícia), as videochamadas com a sede cortam à tarde, quando se enviam relatórios grandes.

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 estáticas entre sede e delegação (módulo 3, lição 1).

Passos

1. Ponha as rotas e meça a latência de base.

   sudo ip -n r1 route add 10.20.10.0/24 via 10.255.0.2; sudo ip -n r2 route add 10.10.0.0/16 via 10.255.0.1
   sudo ip netns exec pc-del ping -c 10 -q 10.10.20.53

   Saída de exemplo (didáctica):

   10 packets transmitted, 10 received, 0% packet loss
   rtt min/avg/max/mdev = 0.041/0.060/0.090/0.014 ms

2. Simule a ligação da delegação: 80 ms de atraso com 20 ms de variação e 2% de perda.

   sudo ip netns exec r2 tc qdisc add dev r2-r1 root netem delay 80ms 20ms loss 2%
   sudo ip netns exec pc-del ping -c 50 -q 10.10.20.53

   Saída de exemplo (didáctica):

   50 packets transmitted, 49 received, 2% packet loss
   rtt min/avg/max/mdev = 61.2/80.9/101.7/11.4 ms

3. Interprete: com esta ligação, uma chamada de voz tem qualidade aceitável? Justifique com os três indicadores.

Critérios de sucesso

• O formando lê latência média, variação (mdev) e perda.
• Relaciona com os requisitos de voz e propõe QoS ou mais capacidade.

Como desfazer (reversão)

• sudo ip netns exec r2 tc qdisc del dev r2-r1 root
• sudo ip -n r1 route del 10.20.10.0/24; sudo ip -n r2 route del 10.10.0.0/16

Alternativa em papel: tarefas e respostas esperadas

Com a saída do passo 2, avalie a voz.

Latência de ida ~40 ms (metade de 80,9 ms de ida e volta), variação ~11 ms e 2% de perda: latência e variação razoáveis, perda acima do desejável. Qualidade degradada; tratar perda (congestionamento) e dar prioridade à voz.

Explique o caso da tarde.

Os relatórios enchem a ligação; as filas crescem, aumentando latência, jitter e perda para a videochamada. Solução: QoS (prioridade à voz/vídeo, limite às transferências) e/ou agendar envios.

QoS aumenta a largura de banda?

Não. Só reparte a existente quando há congestionamento.

Verifique o que aprendeu

Questão 1

Qual indicador é mais crítico para uma chamada de voz?

1. Débito máximo
2. Latência, jitter e perda
3. Tamanho do disco
4. Número de VLAN

Questão 2

O mdev no resultado do ping indica:

1. A perda
2. A variação da latência
3. O débito
4. O TTL

Em leitura fácil

• Atraso, variação e perda estragam as chamadas.
• Ficheiros grandes podem encher a ligação.
• QoS dá prioridade, não dá mais velocidade.

Fontes

• 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)
• IETF RFC 4594 — Configuration Guidelines for DiffServ Service Classes (https://www.rfc-editor.org/rfc/rfc4594)
• IETF RFC 3550 — RTP: A Transport Protocol for Real-Time Applications (https://www.rfc-editor.org/rfc/rfc3550)

Duração: 80 minutos (explicação 20, prática guiada 50, verificação 10). Resultados dos TdR trabalhados: Diagnóstico, desempenho e disponibilidade; Monitorização, análise de tráfego e gestão.

Objectivos

• Definir disponibilidade e calcular percentagens em tempo de indisponibilidade.
• Montar uma verificação periódica simples de serviços com script.
• Distinguir monitoria activa (sondas) de passiva (registos, contadores).

Medir para gerir

Disponibilidade = tempo em funcionamento / tempo total. 99% ao ano são cerca de 3 dias e 15 horas de paragem; 99,9% cerca de 8 horas e 46 minutos. Um objectivo só faz sentido se for medido da mesma maneira todos os meses e se houver definição do que conta como «indisponível».

Monitoria activa envia sondas (ping, pedido HTTP, consulta DNS) e mede a resposta. Monitoria passiva recolhe contadores (SNMP, módulo 11) e registos. Ferramentas completas existem (várias gratuitas); aqui faz-se uma sonda mínima para perceber o princípio.

Caso fictício

A direcção da DPE (fictícia) pergunta «quanto tempo o portal esteve em baixo no mês passado?» e ninguém sabe responder.

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 web de teste no srv; sonda corre no pc-adm (futuro servidor de monitorização 10.10.20.16).

Passos

1. Ponha o serviço e a sonda.

   Consola C (deixar aberta): sudo ip netns exec srv python3 -m http.server 80 --bind 10.10.20.53
   cat > /tmp/sonda.sh <<'EOF'
   #!/bin/sh
   # sonda.sh — regista uma linha por minuto: data;alvo;estado;ms
   alvo=http://10.10.20.53/
   while true; do
     t0=$(date +%s%3N)
     if python3 -c "import urllib.request as u; u.urlopen('$alvo', timeout=3)" 2>/dev/null; then e=OK; else e=FALHA; fi
     echo "$(date -Is);$alvo;$e;$(( $(date +%s%3N) - t0 ))" >> /tmp/sonda.csv
     sleep 60
   done
   EOF
   chmod +x /tmp/sonda.sh
   Consola S (deixar aberta): sudo ip netns exec pc-adm /tmp/sonda.sh

2. Provoque uma paragem de 3 minutos e reponha.

   Na consola C, Ctrl+C para parar o servidor de teste; aguardar 3 minutos (as linhas FALHA acumulam-se).
   Na consola C: sudo ip netns exec srv python3 -m http.server 80 --bind 10.10.20.53

3. Calcule a disponibilidade do período.

   awk -F';' '{t++; if($3=="OK") ok++} END {printf "%d amostras, %.1f%% disponível\n", t, 100*ok/t}' /tmp/sonda.csv

   Saída de exemplo (didáctica):

   10 amostras, 70.0% disponível

Critérios de sucesso

• A sonda regista FALHA durante a paragem e OK depois.
• O formando calcula a disponibilidade e explica o limite da amostragem por minuto.

Como desfazer (reversão)

• Ctrl+C na consola S (sonda) e na consola C (servidor de teste).
• rm -f /tmp/sonda.sh /tmp/sonda.csv

Alternativa em papel: tarefas e respostas esperadas

Quanto tempo de paragem permite 99,5% num mês de 30 dias?

0,5% de 43 200 minutos = 216 minutos (3 h 36 min).

Porque a sonda por minuto não vê uma falha de 20 segundos?

Amostragem: entre duas sondas a falha pode começar e acabar sem ser observada. Mais frequência dá mais precisão e mais carga.

Defina «indisponível» para o portal da DPE.

Ex.: a página inicial não responde com código 200 em menos de 3 segundos a partir da rede interna, em duas sondas seguidas.

Verifique o que aprendeu

Questão 1

99,9% de disponibilidade anual corresponde a cerca de:

1. 8 horas e 46 minutos de paragem
2. 3 dias
3. 1 minuto
4. 36 horas

Questão 2

Qual é monitoria passiva?

1. Enviar ping
2. Ler contadores SNMP e registos
3. Pedir uma página
4. Consultar DNS

Em leitura fácil

• Disponível quer dizer: está a funcionar.
• Uma sonda testa o serviço de minuto a minuto.
• Assim sabemos quanto tempo esteve parado.

Fontes

• 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)
• NIST Cybersecurity Framework 2.0 (https://www.nist.gov/cyberframework)

Duração: 80 minutos (explicação 20, prática guiada 50, verificação 10). Resultados dos TdR trabalhados: Continuidade e protecção de activos digitais; Documentação: diagramas, procedimentos (SOP) e contingência; Automação com scripts básicos.

Objectivos

• Guardar configurações de equipamentos com data e controlo de versões (git).
• Restaurar uma configuração conhecida e verificar o resultado.
• Escrever um procedimento curto de recuperação.

Uma avaria de configuração recupera-se com a última cópia boa

Cada equipamento tem uma configuração que representa horas de trabalho. Deve haver cópia depois de cada alteração, guardada fora do equipamento, com data, autor e motivo. O git regista versões e permite ver diferenças (git diff) e voltar atrás. As cópias contêm segredos (chaves, senhas cifradas): guardam-se em repositório interno com acesso restrito, nunca em serviços públicos.

Recuperação: 1) identificar a última versão boa; 2) comparar com a actual; 3) aplicar em janela aprovada; 4) verificar; 5) registar. Testar a recuperação periodicamente: uma cópia nunca restaurada é uma esperança, não uma garantia.

Caso fictício

Depois de uma alteração de firewall no r1 da DPE (fictícia), a delegação deixou de chegar ao servidor. Não havia cópia da configuração anterior.

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).
• Configuração nftables simples no r1 (tabela filter) guardada num repositório git local /tmp/configs.

Passos

1. Aplique uma configuração inicial e guarde-a no git.

   mkdir -p /tmp/configs && cd /tmp/configs && git init -q && git config user.name 'Tecnico Pratica' && git config user.email 'ti@dpe.example'
   sudo ip netns exec r1 nft add table inet filter
   sudo ip netns exec r1 nft 'add chain inet filter forward { type filter hook forward priority 0; policy accept; }'
   sudo ip netns exec r1 nft list ruleset > /tmp/configs/r1.nft && git add r1.nft && git commit -qm 'r1: configuração inicial aprovada'

2. Faça uma alteração «infeliz» e guarde-a.

   sudo ip netns exec r1 nft add rule inet filter forward ip saddr 10.20.10.0/24 drop
   sudo ip netns exec r1 nft list ruleset > /tmp/configs/r1.nft && git commit -qam 'r1: regra nova (pedido 123)'
   git diff HEAD~1 HEAD

   Saída de exemplo (didáctica):

   +		ip saddr 10.20.10.0/24 drop

3. Restaure a versão anterior e aplique.

   git show HEAD~1:r1.nft > /tmp/r1-bom.nft
   sudo ip netns exec r1 nft flush ruleset && sudo ip netns exec r1 nft -f /tmp/r1-bom.nft
   sudo ip netns exec r1 nft list ruleset | grep -c drop

   Saída de exemplo (didáctica):

   0

4. Guarde a reposição como nova versão (não se apaga o histórico).

   sudo ip netns exec r1 nft list ruleset > /tmp/configs/r1.nft && git commit -qam 'r1: reposição da versão aprovada (incidente 7)' && git log --oneline

   Saída de exemplo (didáctica):

   c3 r1: reposição da versão aprovada (incidente 7)
   b2 r1: regra nova (pedido 123)
   a1 r1: configuração inicial aprovada

Critérios de sucesso

• O histórico mostra as três versões com motivo.
• Depois da reposição não existe a regra drop e a delegação volta a comunicar (quando houver rotas).

Como desfazer (reversão)

• sudo ip netns exec r1 nft flush ruleset; rm -rf /tmp/configs /tmp/r1-bom.nft

Alternativa em papel: tarefas e respostas esperadas

Escreva o procedimento de recuperação em 5 passos para o caso.

1) Confirmar sintoma e hora da alteração; 2) obter a última versão aprovada do repositório; 3) comparar com a actual (diff); 4) aplicar a versão aprovada em janela autorizada; 5) verificar conectividade e registar no histórico e no relatório.

Porque não se apaga a versão errada do histórico?

O histórico é evidência do que aconteceu e ajuda a análise; a correcção é uma nova versão.

Onde não guardar as cópias?

Em repositórios públicos, em correio pessoal ou em pens sem cifra: contêm segredos e desenho da rede.

Verifique o que aprendeu

Questão 1

O que prova que uma cópia de configuração serve?

1. Existir o ficheiro
2. Ter sido restaurada e verificada em teste
3. Ter data recente
4. Ser grande

Questão 2

Qual a vantagem do git para configurações?

1. Cifra automaticamente
2. Regista versões, autores e diferenças
3. Substitui o firewall
4. Faz cópias para a internet

Em leitura fácil

• Guarde a configuração depois de cada mudança.
• Escreva quem mudou e porquê.
• Teste se consegue repor.

Fontes

• Git — documentação oficial (https://git-scm.com/doc)
• Projecto nftables — wiki oficial (https://wiki.nftables.org/)
• NIST SP 800-34 Rev. 1 — Contingency Planning Guide (https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final)

Duração: 70 minutos (explicação 20, prática guiada 40, verificação 10). Resultados dos TdR trabalhados: Identificar vulnerabilidades e aplicar mitigação; Políticas, normas e boas práticas.

Objectivos

• Distinguir activo, ameaça, vulnerabilidade, impacto e risco.
• Classificar riscos com uma matriz de probabilidade × impacto.
• Propor controlos proporcionais e registar o risco residual.

Vocabulário

Activo é o que tem valor (servidor de processos, base de dados de funcionários, a própria ligação à internet). Ameaça é o que pode causar dano (pessoa mal-intencionada, falha eléctrica, erro humano). Vulnerabilidade é a fraqueza que a ameaça aproveita (serviço desactualizado, senha fraca, falta de UPS). Risco combina a probabilidade de a ameaça explorar a vulnerabilidade e o impacto se isso acontecer.

Tratar o risco: reduzir (controlos), transferir (contrato, seguro), evitar (não fazer a actividade) ou aceitar formalmente. O risco que sobra depois dos controlos é o residual e deve ser aceite por quem tem autoridade, não pelo técnico sozinho. Guias como NIST SP 800-30 e o NIST CSF 2.0 dão estrutura a este trabalho.

Caso fictício

Inventário parcial da DPE (fictícia): servidor de ficheiros com sistema sem actualizações há 18 meses; comutador central sem UPS; portal publicado na internet; senhas de administração iguais em todos os equipamentos.

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)

• Exercício de análise (sem rede). Uma folha de cálculo ou papel com a matriz 3 × 3 (baixo/médio/alto).

Passos

1. Construa o registo de riscos em CSV (abre em qualquer folha de cálculo).

   cat > /tmp/riscos.csv <<'EOF'
   id;activo;ameaca;vulnerabilidade;prob(1-3);impacto(1-3);risco;controlo;dono;residual
   R1;servidor de ficheiros;código malicioso;sistema sem actualizações;3;3;9;actualizar e segmentar;chefe TI;
   R2;comutador central;corte de energia;sem UPS;2;3;6;UPS e procedimento;chefe TI;
   EOF
   column -s';' -t /tmp/riscos.csv

2. Complete R3 (portal) e R4 (senhas iguais), calcule o risco (prob × impacto) e ordene do maior para o menor.

Critérios de sucesso

• Quatro riscos completos, ordenados, cada um com controlo proporcional e dono.
• Pelo menos um risco com proposta de aceitação formal do residual.

Como desfazer (reversão)

• rm -f /tmp/riscos.csv

Alternativa em papel: tarefas e respostas esperadas

Complete R3 e R4.

R3: portal / exploração de falha web / exposição à internet e possível desactualização / prob 2–3 / impacto 3 / risco 6–9 / actualizações, firewall, monitorização, cópias. R4: todos os equipamentos / roubo de uma senha / senha reutilizada / prob 2 / impacto 3 / risco 6 / senhas únicas em cofre, MFA onde possível, contas nominais.

Classifique: «sistema sem actualizações» é ameaça ou vulnerabilidade?

Vulnerabilidade. A ameaça é quem ou o que a pode explorar.

Quem aceita o risco residual?

O responsável do activo com autoridade (por exemplo, a direcção), com registo; o técnico propõe e informa.

Verifique o que aprendeu

Questão 1

O risco depende de:

1. Só da ameaça
2. Probabilidade e impacto
3. Só do custo do equipamento
4. Do número de VLAN

Questão 2

Qual é uma forma de tratar risco?

1. Esconder
2. Reduzir, transferir, evitar ou aceitar formalmente
3. Ignorar sempre
4. Apagar os registos

Em leitura fácil

• Activo: o que tem valor.
• Vulnerabilidade: o ponto fraco.
• Risco: a chance de dano e o tamanho do dano.

Fontes

• NIST SP 800-30 Rev. 1 — Guide for Conducting Risk Assessments (https://csrc.nist.gov/pubs/sp/800/30/r1/final)
• NIST Cybersecurity Framework 2.0 (https://www.nist.gov/cyberframework)

Duração: 75 minutos (explicação 20, prática guiada 45, verificação 10). Resultados dos TdR trabalhados: Políticas, normas e boas práticas; Trabalho em equipa, projectos, ética e confidencialidade.

Objectivos

• Reconhecer sinais de engenharia social por correio, telefone e presencial.
• Analisar cabeçalhos de uma mensagem suspeita (fictícia).
• Aplicar o procedimento de reporte sem clicar nem reencaminhar a colegas.

O alvo é a pessoa

A engenharia social explora confiança, urgência, medo ou autoridade: «sou do departamento de TI, preciso da sua senha agora», «a sua conta será suspensa hoje». Formas comuns: correio de phishing, mensagens em aplicações, chamadas telefónicas, pens deixadas à porta, alguém que entra atrás de um funcionário numa porta com cartão.

Defesas: nenhuma equipa de TI pede senhas; confirmar pedidos invulgares por outro canal conhecido; não abrir anexos inesperados; reportar em vez de apagar. O técnico de redes contribui com filtros de correio, DNS e formação, mas a decisão final é da pessoa que recebe.

Caso fictício

Uma funcionária da DPE (fictícia) recebe mensagem «Tesouraria — pagamento de subsídio pendente» com ligação para confirmar dados bancários até às 12h.

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)

• Mensagem fictícia em texto (formato .eml) para análise num editor de texto; não se abre em programa de correio nem se seguem ligações.

Passos

1. Guarde e leia a mensagem fictícia só como texto.

   cat > /tmp/suspeita.eml <<'EOF'
   Return-Path: <aviso@tesouraria-dpe-pagamentos.example>
   Received: from mail.envio-massivo.example (198.51.100.77) by mx.dpe.example
   From: "Tesouraria DPE" <tesouraria@dpe.example>
   Reply-To: pagamentos.urgente@correio-gratis.example
   Subject: URGENTE: subsídio pendente - confirme até às 12h
   Authentication-Results: mx.dpe.example; spf=fail smtp.mailfrom=tesouraria-dpe-pagamentos.example; dkim=none; dmarc=fail header.from=dpe.example
   
   Caro funcionário, confirme os seus dados bancários em http://dpe-pagamentos.example/login até às 12h ou perderá o subsídio.
   EOF
   grep -iE '^(From|Reply-To|Return-Path|Received|Authentication-Results):' /tmp/suspeita.eml

2. Liste as incoerências entre os campos e escreva o reporte para a equipa de TI (modelo no papel).

Critérios de sucesso

• Identificadas pelo menos cinco incoerências.
• O reporte não contém a ligação clicável (escrita com [.] em vez de ponto) e não é reencaminhado a colegas.

Como desfazer (reversão)

• rm -f /tmp/suspeita.eml

Alternativa em papel: tarefas e respostas esperadas

Liste os sinais de fraude.

Urgência e ameaça; pedido de dados bancários; Reply-To para domínio de correio gratuito; Return-Path e servidor de envio diferentes do domínio da DPE; SPF e DMARC falhados; ligação para domínio que não é dpe.example.

Escreva o reporte.

«Recebi às 09:40 mensagem com assunto “URGENTE: subsídio pendente”, remetente aparente tesouraria@dpe.example, que pede dados bancários em dpe-pagamentos[.]example. Não cliquei nem respondi. Anexo a mensagem como ficheiro.» Enviado ao endereço de reporte de TI, sem reencaminhar a colegas.

Um «técnico» telefona e pede a senha para «actualizar a conta». O que responder?

Recusar; a TI nunca pede senhas; desligar e ligar para o número conhecido da TI para confirmar; reportar.

Verifique o que aprendeu

Questão 1

O «From» mostra tesouraria@dpe.example. Isso prova que é legítima?

1. Sim
2. Não, o campo pode ser falsificado; ver autenticação e outros cabeçalhos
3. Só se tiver logótipo
4. Sim, se vier de manhã

Questão 2

Clicou por engano numa ligação suspeita. O que fazer primeiro?

1. Esconder
2. Reportar de imediato à TI e, se introduziu a senha, mudá-la a partir de um canal seguro
3. Apagar a mensagem
4. Desligar a internet do edifício

Em leitura fácil

• Desconfie de pressa e ameaças.
• A TI nunca pede a sua senha.
• Reporte sem clicar.

Fontes

• NIST SP 800-61 Rev. 3 — Incident Response Recommendations (https://csrc.nist.gov/pubs/sp/800/61/r3/final)
• NIST Cybersecurity Framework 2.0 (https://www.nist.gov/cyberframework)

Duração: 75 minutos (explicação 20, prática guiada 45, verificação 10). Resultados dos TdR trabalhados: Protecção de dados e identidades: MFA e cifra; Serviços de rede: DHCP, DNS, VPN, NAT, VLAN e autenticação.

Objectivos

• Aplicar boas práticas de palavras-passe segundo NIST SP 800-63B.
• Explicar autenticação multifactor e o funcionamento de TOTP.
• Separar contas de uso diário das contas de administração.

Senhas que resistem

Orientações actuais (NIST SP 800-63B): preferir frases longas a regras de complexidade arbitrárias; comparar com listas de senhas comprometidas; não obrigar a mudanças periódicas sem motivo, mas mudar logo que haja suspeita; limitar tentativas; nunca guardar em texto claro. Um gestor de senhas aprovado pela instituição ajuda a ter senhas únicas.

MFA combina algo que se sabe (senha), algo que se tem (telemóvel, chave física) e algo que se é (biometria). TOTP (RFC 6238) gera um código de 6 dígitos a partir de um segredo partilhado e da hora actual, mudando a cada 30 segundos. Chaves físicas resistem melhor ao phishing que códigos. Administradores usam conta nominal separada, com MFA, só para administração.

Caso fictício

Na DPE (fictícia), todos os técnicos entram nos equipamentos com a conta «admin» e a mesma senha, que está num papel colado ao monitor.

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)

• Só o computador de prática, sem rede. Implementação TOTP didáctica com a biblioteca padrão do Python (não é para uso em produção).

Passos

1. Crie o gerador TOTP didáctico conforme a RFC 6238 (HMAC-SHA1, 30 s, 6 dígitos).

   cat > /tmp/totp.py <<'EOF'
   import base64, hmac, hashlib, struct, time, sys
   def totp(segredo_b32, t=None, passo=30, digitos=6):
       k = base64.b32decode(segredo_b32)
       c = int((time.time() if t is None else t) // passo)
       h = hmac.new(k, struct.pack('>Q', c), hashlib.sha1).digest()
       o = h[-1] & 0x0F
       n = (struct.unpack('>I', h[o:o+4])[0] & 0x7FFFFFFF) % 10**digitos
       return str(n).zfill(digitos)
   # Vector de teste da RFC 6238 (segredo ASCII '12345678901234567890', t=59) deve dar 287082
   print(totp(base64.b32encode(b'12345678901234567890').decode(), t=59))
   print(totp('JBSWY3DPEHPK3PXP'))  # segredo de prática, fictício
   EOF
   python3 /tmp/totp.py

   Saída de exemplo (didáctica):

   287082
   (um código de 6 dígitos que muda a cada 30 segundos)

2. Verifique a força relativa de duas senhas pelo número de combinações (cálculo, não medição).

   python3 -c "import math; print(round(8*math.log2(94)), 'bits para 8 caracteres aleatórios'); print(round(5*math.log2(7776)), 'bits para 5 palavras aleatórias de uma lista de 7776')"

   Saída de exemplo (didáctica):

   52 bits para 8 caracteres aleatórios
   65 bits para 5 palavras aleatórias de uma lista de 7776

Critérios de sucesso

• O vector da RFC dá 287082 (prova de que a implementação está conforme).
• O formando explica porque o código muda e porque depende da hora certa (módulo 5).

Como desfazer (reversão)

• rm -f /tmp/totp.py

Alternativa em papel: tarefas e respostas esperadas

Proponha a correcção do caso.

Contas nominais por técnico; senhas únicas e longas guardadas em cofre/gestor aprovado; MFA para administração; desactivar ou renomear a conta genérica «admin»; retirar o papel; registo de quem acede.

Porque o TOTP falha se o relógio do telemóvel estiver 2 minutos atrasado?

O código depende do intervalo de 30 s actual; com 2 minutos de diferença cliente e servidor calculam intervalos diferentes (os servidores só toleram pequena margem).

Frase-passe ou senha curta complexa: qual e porquê?

Frase longa com palavras aleatórias: mais combinações e mais fácil de lembrar, se não for uma frase conhecida.

Verifique o que aprendeu

Questão 1

Segundo o NIST SP 800-63B, forçar mudança de senha a cada 30 dias sem motivo é:

1. Recomendado
2. Desaconselhado; mudar quando há indício de comprometimento
3. Obrigatório
4. Irrelevante

Questão 2

Qual factor resiste melhor ao phishing?

1. Código por SMS
2. Chave física FIDO2 ligada ao domínio
3. Pergunta secreta
4. Senha longa

Em leitura fácil

• Use frases longas e diferentes em cada sítio.
• Use um segundo factor, como um código no telemóvel.
• Cada técnico tem a sua conta.

Fontes

• NIST SP 800-63B — Digital Identity Guidelines: Authentication (https://pages.nist.gov/800-63-4/sp800-63b.html)
• IETF RFC 6238 — TOTP: Time-Based One-Time Password (https://www.rfc-editor.org/rfc/rfc6238)
• Python 3 — módulo ipaddress e subprocess (documentação oficial) (https://docs.python.org/3/library/ipaddress.html)

Duração: 80 minutos (explicação 20, prática guiada 50, verificação 10). Resultados dos TdR trabalhados: Identificar vulnerabilidades e aplicar mitigação; Continuidade e protecção de activos digitais.

Objectivos

• Organizar a gestão de actualizações: inventário, prioridade, teste, aplicação, verificação.
• Verificar actualizações pendentes num sistema Debian.
• Proteger equipamentos: serviços mínimos, cópias antes de actualizar, plano de reversão.

Actualizar é gerir risco

Muitos ataques exploram falhas já corrigidas pelos fabricantes. Gerir actualizações (NIST SP 800-40) começa pelo inventário (o que existe e que versão tem), segue para a prioridade (falha explorada activamente? equipamento exposto?), o teste num equipamento representativo, a aplicação numa janela combinada, a verificação e o registo.

Equipamentos de rede também têm firmware com falhas. Antes de actualizar, guarda-se a configuração (módulo 5) e define-se como voltar atrás. Equipamentos sem suporte do fabricante (fim de vida) tornam-se um risco a registar e substituir.

Caso fictício

A DPE (fictícia) tem 3 servidores Debian, 12 comutadores de duas gerações e um encaminhador cujo fabricante anunciou fim de suporte. Pede-se um plano mensal.

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)

• O próprio computador de prática Debian 12 (comandos só de leitura, excepto se o formador autorizar a actualização).

Passos

1. Actualize a lista de pacotes e veja o que está pendente.

   sudo apt update
   apt list --upgradable 2>/dev/null | head

   Saída de exemplo (didáctica):

   Listing...
   openssl/stable-security 3.0.x-deb12uY amd64 [upgradable from: 3.0.x-deb12uX]
   (versões ilustrativas)

2. Veja a origem de uma actualização e o registo de alterações (changelog) antes de decidir.

   apt-cache policy openssl
   apt changelog openssl | head -n 20

3. Liste serviços à escuta e identifique os desnecessários.

   sudo ss -ltnup

4. Registe no plano: data, pacote, motivo, teste feito, janela, resultado, reversão.

Critérios de sucesso

• Lista de pendentes lida e classificada (segurança ou não).
• Plano mensal com as cinco etapas e o encaminhador em fim de vida registado como risco.

Como desfazer (reversão)

• Não houve alteração (só leitura). Se o formador autorizou actualizar: o registo de /var/log/apt/history.log mostra o que mudou.

Alternativa em papel: tarefas e respostas esperadas

Escreva o plano mensal do caso.

Semana 1: inventário e leitura dos avisos de segurança; semana 2: teste num servidor e num comutador de cada geração; semana 3: aplicação em janela aprovada, com cópia de configuração antes; semana 4: verificação e relatório. Encaminhador em fim de vida: registo de risco, controlos compensatórios (acesso de gestão restrito) e proposta de substituição.

Uma falha crítica está a ser explorada activamente e afecta o portal publicado. Espera-se pela janela mensal?

Não. Aplica-se o procedimento de urgência: mitigar ou actualizar logo, com aprovação rápida e registo.

Porque desligar serviços não usados?

Cada serviço à escuta é superfície de ataque e precisa de actualizações; menos serviços, menos risco.

Verifique o que aprendeu

Questão 1

Qual o primeiro passo da gestão de actualizações?

1. Actualizar tudo já
2. Inventário do que existe e das versões
3. Comprar equipamento novo
4. Desligar a internet

Questão 2

Um equipamento sem suporte do fabricante deve ser:

1. Ignorado
2. Registado como risco, isolado e com plano de substituição
3. Exposto à internet
4. Reiniciado todos os dias

Em leitura fácil

• Saber o que temos.
• Testar antes de actualizar.
• Guardar a configuração e saber voltar atrás.

Fontes

• NIST SP 800-40 Rev. 4 — Enterprise Patch Management Planning (https://csrc.nist.gov/pubs/sp/800/40/r4/final)
• Debian 12 «bookworm» — Manual de Segurança e pacotes oficiais (https://www.debian.org/doc/manuals/securing-debian-manual/)

Duração: 80 minutos (explicação 20, prática guiada 50, verificação 10). Resultados dos TdR trabalhados: Incidentes: contenção, análise, recuperação e relatório; Trabalho em equipa, projectos, ética e confidencialidade.

Objectivos

• Reconhecer o que é um incidente de segurança e o que não é.
• Fazer o reporte inicial com os factos mínimos e preservar evidências.
• Conhecer os primeiros passos de contenção sem destruir provas.

Os primeiros minutos contam

Incidente é um acontecimento que compromete, ou pode comprometer, a confidencialidade, integridade ou disponibilidade de informação ou serviços: conta usada por terceiros, código malicioso, fuga de dados, indisponibilidade provocada. O reporte inicial deve dizer: quem reporta, quando se detectou, o que se observou, que sistemas, o que já se fez. Não se especula; separa-se facto de hipótese.

Preservar evidências: não desligar a correr um equipamento suspeito sem orientação (a memória perde-se); anotar horas; fotografar ecrãs; não apagar ficheiros nem mensagens. A contenção inicial pode ser isolar da rede (desligar o cabo ou mudar a porta para uma VLAN de quarentena), mantendo o equipamento ligado. O módulo 8 desenvolve a resposta completa.

Caso fictício

Às 10h15, o computador de um funcionário da DPE (fictícia) mostra uma mensagem a pedir pagamento para recuperar ficheiros. O funcionário liga ao técnico.

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).
• pc-adm faz de computador afectado; VLAN de quarentena simulada retirando a rota por omissão e o endereço.

Passos

1. Registe a hora de início e o estado de rede do equipamento antes de mexer.

   date -Is | tee /tmp/incidente.txt
   sudo ip -n pc-adm -brief addr | tee -a /tmp/incidente.txt
   sudo ip netns exec pc-adm ss -tunp | tee -a /tmp/incidente.txt

2. Isole da rede sem desligar o equipamento (simulação: interface desactivada).

   sudo ip -n pc-adm link set pc-adm-r1 down
   echo "$(date -Is) isolado da rede por (nome do técnico)" | tee -a /tmp/incidente.txt

3. Preencha o reporte inicial com factos (modelo no papel) e envie à equipa/coordenação de resposta conforme o procedimento da instituição.

Critérios de sucesso

• Evidências de estado recolhidas antes do isolamento.
• Equipamento isolado mas ligado.
• Reporte com factos, sem especulação.

Como desfazer (reversão)

• sudo ip -n pc-adm link set pc-adm-r1 up
• rm -f /tmp/incidente.txt (na prática; num caso real o ficheiro é evidência e guarda-se)

Alternativa em papel: tarefas e respostas esperadas

Preencha o reporte inicial do caso.

Reporta: técnico X, 10h20. Detecção: 10h15 pelo utilizador. Observado: mensagem a pedir pagamento para recuperar ficheiros; ficheiros com extensão alterada. Sistemas: posto da Administração (nome/endereço). Acções: posto isolado da rede às 10h22, mantido ligado; nada apagado. Hipótese (a confirmar): código de sequestro de dados. Próximos passos: aguardar orientação da equipa de resposta.

Porque não desligar logo o computador?

Perdem-se evidências em memória (processos, ligações, possivelmente chaves); isolar da rede trava a propagação sem destruir provas.

Isto é incidente? «O portal esteve lento 5 minutos durante uma actualização planeada.»

Normalmente não é incidente de segurança (evento planeado); regista-se como evento operacional.

Verifique o que aprendeu

Questão 1

Qual é uma boa acção de contenção inicial?

1. Formatar o disco
2. Isolar o equipamento da rede mantendo-o ligado
3. Pagar o resgate
4. Apagar a mensagem

Questão 2

O reporte inicial deve:

1. Culpar alguém
2. Descrever factos, horas, sistemas e acções já feitas
3. Esperar ter todas as respostas
4. Ser feito só no fim do dia

Em leitura fácil

• Se algo estranho acontecer, avise logo.
• Tire o cabo de rede, não desligue o computador.
• Escreva o que viu e a que horas.

Fontes

• NIST SP 800-61 Rev. 3 — Incident Response Recommendations (https://csrc.nist.gov/pubs/sp/800/61/r3/final)
• NIST Cybersecurity Framework 2.0 (https://www.nist.gov/cyberframework)

Duração: 70 minutos (explicação 20, prática guiada 40, verificação 10). Resultados dos TdR trabalhados: Segurança desde a concepção; IDS/IPS, ACL e segmentação.

Objectivos

• Explicar como a segmentação por zonas limita a propagação de um incidente.
• Desenhar uma matriz de fluxos permitidos entre zonas da rede da DPE.
• Verificar, com testes antes/depois, que só os fluxos aprovados passam.

Zonas e confiança

Uma zona é um conjunto de equipamentos com a mesma função e o mesmo nível de exposição: postos da Administração, servidores, visitantes, gestão dos equipamentos, ligação ao operador. Entre zonas, o tráfego passa por um ponto de controlo (encaminhador com firewall) onde se aplica uma regra explícita.

O objectivo não é impedir todo o erro, mas reduzir o alcance: se um posto de visitante for comprometido, não deve conseguir chegar à rede de gestão nem aos servidores internos. É a mesma ideia do NIST SP 800-207 (confiança zero): a localização na rede, só por si, não dá confiança.

Matriz de fluxos

Antes de escrever regras, escreve-se uma tabela: origem, destino, serviço (protocolo e porta), justificação, responsável. Tudo o que não está na tabela fica recusado por omissão. A tabela é aprovada pela direcção de TI e revista quando surgem serviços novos.

Exemplo na DPE (fictícia): Administração → Servidores em TCP 80/443 e UDP/TCP 53; Visitantes → Internet em TCP 80/443 e DNS; Gestão → equipamentos em SSH (TCP 22) só a partir de 10.10.99.0/24; Visitantes → qualquer rede interna: recusado.

Caso fictício

Um portátil de visitante na DPE (fictícia) foi infectado e começou a procurar serviços na rede. A direcção pede prova de que ele não alcança os servidores nem a gestão.

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).
• Acrescenta-se ao r1 um posto de visitante vis (10.10.30.30/24, porta 10.10.30.1) e um endereço de gestão 10.10.99.1/24 no lo do r1.

Passos

1. Crie o posto de visitante e o endereço de gestão.

   sudo ip netns add vis
   sudo ip link add vis-r1 type veth peer name r1-vis
   sudo ip link set vis-r1 netns vis; sudo ip link set r1-vis netns r1
   sudo ip -n vis addr add 10.10.30.30/24 dev vis-r1; sudo ip -n vis link set vis-r1 up; sudo ip -n vis link set lo up
   sudo ip -n r1 addr add 10.10.30.1/24 dev r1-vis; sudo ip -n r1 link set r1-vis up
   sudo ip -n vis route add default via 10.10.30.1
   sudo ip -n r1 addr add 10.10.99.1/24 dev lo

2. Teste ANTES das regras: registe na folha o que passa.

   sudo ip netns exec vis ping -c 1 -W 1 10.10.20.53
   sudo ip netns exec vis ping -c 1 -W 1 10.10.99.1

   Saída de exemplo (didáctica):

   1 packets transmitted, 1 received
   1 packets transmitted, 1 received

3. Aplique a regra de zona: visitantes não entram em redes internas.

   sudo ip netns exec r1 nft add table inet zonas
   sudo ip netns exec r1 nft 'add chain inet zonas forward { type filter hook forward priority 0; policy accept; }'
   sudo ip netns exec r1 nft 'add chain inet zonas input { type filter hook input priority 0; policy accept; }'
   sudo ip netns exec r1 nft add rule inet zonas forward iifname "r1-vis" ip daddr 10.0.0.0/8 counter drop
   sudo ip netns exec r1 nft add rule inet zonas input iifname "r1-vis" ip daddr 10.10.99.0/24 counter drop

4. Teste DEPOIS e leia os contadores.

   sudo ip netns exec vis ping -c 1 -W 1 10.10.20.53
   sudo ip netns exec vis ping -c 1 -W 1 10.10.99.1
   sudo ip netns exec pc-adm ping -c 1 -W 1 10.10.20.53
   sudo ip netns exec r1 nft list table inet zonas

   Saída de exemplo (didáctica):

   1 packets transmitted, 0 received
   1 packets transmitted, 0 received
   1 packets transmitted, 1 received
   iifname "r1-vis" ip daddr 10.0.0.0/8 counter packets 1 bytes 84 drop

Critérios de sucesso

• Visitante deixa de alcançar servidores e gestão; a Administração continua a alcançar o servidor.
• A folha tem a tabela antes/depois assinada pela dupla.

Como desfazer (reversão)

• sudo ip netns exec r1 nft delete table inet zonas
• sudo ip -n r1 addr del 10.10.99.1/24 dev lo
• sudo ip netns del vis

Alternativa em papel: tarefas e respostas esperadas

Preencha a matriz de fluxos para quatro zonas (Administração, Servidores, Visitantes, Gestão) com pelo menos seis linhas.

Cada linha tem origem, destino, serviço e justificação; Visitantes → redes internas aparece como recusado; Gestão só a partir de 10.10.99.0/24; tudo o resto recusado por omissão.

Na saída do passo 4, quantos pacotes do visitante foram bloqueados pela regra forward?

1 pacote (84 bytes), o eco ICMP do teste ao servidor.

Verifique o que aprendeu

Questão 1

Qual é o principal benefício da segmentação por zonas?

1. Aumenta a velocidade da rede
2. Limita o alcance de um equipamento comprometido
3. Dispensa actualizações
4. Elimina a necessidade de palavras-passe

Questão 2

Numa matriz de fluxos, o que acontece a um fluxo não listado?

1. Passa, porque ninguém o proibiu
2. Fica recusado por omissão
3. Passa só de noite
4. Depende do utilizador

Em leitura fácil

• A rede divide-se em zonas.
• Entre zonas, só passa o que está autorizado.
• Se um computador for atacado, o problema fica na zona dele.

Fontes

• NIST SP 800-207 — Zero Trust Architecture (https://csrc.nist.gov/pubs/sp/800/207/final)
• 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)

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)

Duração: 75 minutos (explicação 20, prática guiada 45, verificação 10). Resultados dos TdR trabalhados: Serviços de rede: DHCP, DNS, VPN, NAT, VLAN e autenticação; Protecção de dados e identidades: MFA e cifra.

Objectivos

• Explicar porque o acesso remoto deve passar por um canal cifrado e autenticado.
• Configurar um túnel WireGuard de prática entre um posto remoto e a rede de gestão.
• Endurecer o SSH com chaves e restrições no servidor.

VPN e SSH

Uma VPN cria um canal cifrado entre dois pontos através de uma rede não confiável. O WireGuard usa pares de chaves públicas: cada lado conhece a chave pública do outro e a lista de endereços que pode usar dentro do túnel (AllowedIPs). O SSH (RFC 4253) cifra uma sessão de administração num único servidor.

Regras práticas: autenticação por chave em vez de palavra-passe; desactivar entrada directa como root; limitar quem pode entrar (AllowUsers); expor a gestão só dentro da VPN; registar ligações. As chaves privadas nunca saem do equipamento onde foram geradas.

Caso fictício

O técnico de piquete da DPE (fictícia) precisa de administrar o srv a partir de casa. A direcção só aceita se a gestão não ficar exposta na «Internet».

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).
• Posto remoto «casa» ligado ao isp (203.0.113.50/24). Túnel WireGuard 10.10.98.0/24: r1 = 10.10.98.1, casa = 10.10.98.2, porta UDP 51820 no r1.

Passos

1. Crie o posto remoto.

   sudo ip netns add casa
   sudo ip link add casa-isp type veth peer name isp-casa
   sudo ip link set casa-isp netns casa; sudo ip link set isp-casa netns isp
   sudo ip -n casa addr add 203.0.113.50/24 dev casa-isp; sudo ip -n casa link set casa-isp up; sudo ip -n casa link set lo up
   sudo ip -n isp link add br-isp type bridge; sudo ip -n isp link set isp-r1 master br-isp; sudo ip -n isp link set isp-casa master br-isp
   sudo ip -n isp addr flush dev isp-r1; sudo ip -n isp addr add 203.0.113.1/24 dev br-isp; sudo ip -n isp link set br-isp up; sudo ip -n isp link set isp-casa up

2. Gere as chaves em cada lado (ficam em /tmp da prática; não as copie para fora).

   umask 077; wg genkey | tee /tmp/r1.key | wg pubkey > /tmp/r1.pub
   umask 077; wg genkey | tee /tmp/casa.key | wg pubkey > /tmp/casa.pub

3. Configure o túnel no r1 e na casa.

   sudo ip -n r1 link add wg0 type wireguard
   sudo ip netns exec r1 wg set wg0 listen-port 51820 private-key /tmp/r1.key peer $(cat /tmp/casa.pub) allowed-ips 10.10.98.2/32
   sudo ip -n r1 addr add 10.10.98.1/24 dev wg0; sudo ip -n r1 link set wg0 up
   sudo ip -n casa link add wg0 type wireguard
   sudo ip netns exec casa wg set wg0 private-key /tmp/casa.key peer $(cat /tmp/r1.pub) endpoint 203.0.113.2:51820 allowed-ips 10.10.98.0/24,10.10.20.0/24 persistent-keepalive 25
   sudo ip -n casa addr add 10.10.98.2/24 dev wg0; sudo ip -n casa link set wg0 up
   sudo ip -n casa route add 10.10.20.0/24 dev wg0

4. Verifique o aperto de mão e o acesso ao srv só pelo túnel.

   sudo ip netns exec casa ping -c 1 10.10.20.53
   sudo ip netns exec r1 wg show wg0 latest-handshakes

   Saída de exemplo (didáctica):

   1 packets transmitted, 1 received
   (chave pública da casa)	1759012345

5. Endurecimento SSH (ficheiro de exemplo para o srv; ler e discutir, aplicar só se o srv tiver OpenSSH de prática).

   cat > /tmp/sshd-dpe.conf <<'EOF'
   PermitRootLogin no
   PasswordAuthentication no
   KbdInteractiveAuthentication no
   PubkeyAuthentication yes
   AllowUsers tecnico
   ListenAddress 10.10.20.53
   LogLevel VERBOSE
   EOF
   sshd -t -f /tmp/sshd-dpe.conf && echo sintaxe-ok

   Saída de exemplo (didáctica):

   sintaxe-ok

Critérios de sucesso

• wg show mostra aperto de mão recente.
• O ping da casa ao srv passa pelo túnel.
• O formando justifica cada linha do sshd-dpe.conf.

Como desfazer (reversão)

• sudo ip -n r1 link del wg0; sudo ip netns del casa
• sudo ip -n isp link set isp-r1 nomaster; sudo ip -n isp link del br-isp; sudo ip -n isp addr add 203.0.113.1/24 dev isp-r1
• rm -f /tmp/r1.key /tmp/r1.pub /tmp/casa.key /tmp/casa.pub /tmp/sshd-dpe.conf

Alternativa em papel: tarefas e respostas esperadas

Explique a função de AllowedIPs em cada lado do túnel desta prática.

No r1, só aceita do par pacotes com origem 10.10.98.2; na casa, envia pelo túnel o que se destina a 10.10.98.0/24 e 10.10.20.0/24 e aceita respostas dessas redes.

Porque «PasswordAuthentication no» reduz o risco?

Impede ataques de adivinhação de palavras-passe; só entra quem tem a chave privada correspondente a uma chave autorizada.

Verifique o que aprendeu

Questão 1

Onde deve ficar a chave privada do WireGuard?

1. No correio electrónico da equipa
2. Apenas no equipamento que a gerou, com permissões restritas
3. No site da instituição
4. Num papel colado ao monitor

Questão 2

Qual é a melhor forma de expor a gestão dos equipamentos a um técnico remoto?

1. Abrir SSH para toda a Internet
2. Só através de VPN, com autenticação por chave
3. Partilhar a palavra-passe por mensagem
4. Desligar a firewall durante o piquete

Em leitura fácil

• Acesso de fora passa por um túnel cifrado.
• Use chaves, não palavras-passe.
• A chave secreta nunca sai do computador.

Fontes

• WireGuard — documentação e wg(8) (https://www.wireguard.com/quickstart/)
• OpenSSH — manuais sshd_config(5) e ssh-keygen(1) (https://www.openssh.com/manual.html)
• IETF RFC 4253 — SSH Transport Layer Protocol (https://www.rfc-editor.org/rfc/rfc4253)
• NIST SP 800-77 Rev. 1 — Guide to IPsec VPNs (https://csrc.nist.gov/pubs/sp/800/77/r1/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)

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

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

2. Escreva 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;)
   EOF

3. Consola 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/suri

   Saída de exemplo (didáctica):

   ... Engine started.

4. 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.log

   Saí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?

1. Não houve ataques
2. Nada de definitivo: pode haver falsos negativos ou regras em falta
3. O IDS está avariado de certeza
4. A rede é segura

Questão 2

Diferença essencial entre IDS e IPS:

1. O IPS só funciona em Wi-Fi
2. O IPS está no caminho e pode descartar; o IDS observa e alerta
3. O IDS é sempre mais caro
4. Não há diferença

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)

Duração: 80 minutos (explicação 20, prática guiada 50, verificação 10). Resultados dos TdR trabalhados: Segurança desde a concepção; Identificar vulnerabilidades e aplicar mitigação; Políticas, normas e boas práticas.

Objectivos

• Aplicar uma lista de verificação de reforço a um encaminhador Linux de prática.
• Identificar serviços expostos desnecessários e fechá-los.
• Registar as alterações com antes/depois e forma de reverter.

Reforço da configuração

Reforçar é reduzir o que pode falhar ou ser explorado: remover serviços que não se usam, fechar portas, trocar credenciais por omissão, desactivar protocolos inseguros (Telnet, HTTP de gestão, SNMP v1/v2c com comunidades conhecidas), actualizar, sincronizar a hora e enviar registos para um servidor central.

Faz-se com uma lista escrita, aprovada e versionada (por exemplo, a partir do Manual de Segurança Debian ou das guias do fabricante), aplicada igual em todos os equipamentos do mesmo tipo e verificada depois. Cada alteração tem uma forma de reverter.

Caso fictício

Uma auditoria interna fictícia da DPE encontrou no r1 um serviço de gestão em texto claro e o encaminhamento IPv6 activo sem uso. Pede-se correcção documentada.

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. Prepare a situação encontrada pela auditoria (IPv6 a encaminhar sem uso).

   sudo ip netns exec r1 sysctl -qw net.ipv6.conf.all.forwarding=1

2. Consola C: simule um serviço de gestão inseguro no r1 (servidor HTTP de teste na porta 8080).

   sudo ip netns exec r1 python3 -m http.server 8080 --bind 0.0.0.0

3. Consola B: inventário ANTES — portas à escuta e parâmetros.

   sudo ip netns exec r1 ss -lntup
   sudo ip netns exec r1 sysctl net.ipv6.conf.all.forwarding net.ipv4.conf.all.accept_redirects net.ipv4.conf.all.send_redirects

   Saída de exemplo (didáctica):

   tcp LISTEN 0 5 0.0.0.0:8080 0.0.0.0:* users:(("python3",pid=4121,fd=3))
   net.ipv6.conf.all.forwarding = 1
   net.ipv4.conf.all.accept_redirects = 1
   net.ipv4.conf.all.send_redirects = 1

4. Aplique o reforço: pare o serviço (Ctrl+C na consola C) e ajuste parâmetros.

   sudo ip netns exec r1 sysctl -qw net.ipv6.conf.all.forwarding=0
   sudo ip netns exec r1 sysctl -qw net.ipv4.conf.all.accept_redirects=0
   sudo ip netns exec r1 sysctl -qw net.ipv4.conf.all.send_redirects=0

5. Verifique DEPOIS e confirme que o encaminhamento IPv4 continua.

   sudo ip netns exec r1 ss -lntup
   sudo ip netns exec pc-adm ping -c 1 10.10.20.53

   Saída de exemplo (didáctica):

   (sem serviços à escuta)
   1 packets transmitted, 1 received

Critérios de sucesso

• A folha de alterações tem, para cada item: antes, depois, motivo, forma de reverter.
• O IPv4 continua a funcionar.

Como desfazer (reversão)

• Repor os valores anotados no inventário ANTES (nesta prática: accept_redirects=1 e send_redirects=1; o IPv6 fica desligado, que é o valor inicial do espaço de nomes)
• sudo ip netns exec r1 sysctl -qw net.ipv4.conf.all.accept_redirects=1
• sudo ip netns exec r1 sysctl -qw net.ipv4.conf.all.send_redirects=1

Alternativa em papel: tarefas e respostas esperadas

Preencha uma lista de reforço com 8 itens para um encaminhador (sem comandos, só verificação).

Por exemplo: credenciais por omissão trocadas; gestão só por SSH e só da VLAN 99; Telnet/HTTP de gestão desligados; SNMPv3 ou SNMP desligado; hora sincronizada; registos centralizados; firmware/pacotes actualizados; cópia de configuração versionada; serviços não usados desligados.

Porque se desactivam redireccionamentos ICMP num encaminhador de fronteira?

Um redireccionamento aceite pode alterar rotas a pedido de terceiros; num ambiente com rotas definidas não são necessários.

Verifique o que aprendeu

Questão 1

Qual destas práticas NÃO faz parte de um reforço?

1. Desligar serviços não usados
2. Manter a palavra-passe de fábrica para facilitar suporte
3. Registar alterações
4. Actualizar o software

Questão 2

Porque se verifica o serviço principal depois de reforçar?

1. Por formalidade
2. Porque uma alteração pode quebrar uma função necessária
3. Para aumentar os registos
4. Não é necessário

Em leitura fácil

• Desligue o que não usa.
• Troque as palavras-passe de fábrica.
• Anote o que mudou e como desfazer.

Fontes

• Debian 12 «bookworm» — Manual de Segurança e pacotes oficiais (https://www.debian.org/doc/manuals/securing-debian-manual/)
• NIST SP 800-40 Rev. 4 — Enterprise Patch Management Planning (https://csrc.nist.gov/pubs/sp/800/40/r4/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)

Duração: 70 minutos (explicação 20, prática guiada 40, verificação 10). Resultados dos TdR trabalhados: Monitorização, análise de tráfego e gestão; Diagnóstico, desempenho e disponibilidade.

Objectivos

• Definir o que é uma linha de base e que medidas a compõem.
• Recolher, durante um período curto, contagens de tráfego por protocolo e por par de endereços.
• Usar a linha de base para reconhecer um desvio.

O normal, escrito

Uma linha de base descreve o comportamento habitual da rede num período representativo: que equipamentos falam com quem, por que serviços, em que horas e com que volume. Sem ela, «tráfego estranho» é só impressão.

Medidas úteis: débito por interface (hora a hora), protocolos mais frequentes, pares origem–destino mais activos, tempo de resposta dos serviços críticos, número de ligações novas por minuto. Regista-se também o que é normal mas raro (cópias de segurança nocturnas, actualizações ao fim do mês) para não gerar alarmes falsos.

Caso fictício

A DPE (fictícia) vai ligar alertas de volume anormal, mas ninguém sabe qual é o volume normal. Pede-se uma primeira linha de base de 5 minutos em ambiente de prática, como modelo para a medição real de uma semana.

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: serviço de teste no srv (esperar «Serving HTTP»).

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

2. Consola A: capture no r1, lado dos servidores, durante o período de medição.

   sudo ip netns exec r1 tcpdump -ni r1-srv -w /tmp/base.pcap
   Esperar «listening on r1-srv» antes de gerar tráfego.

3. Consola B: gere tráfego «normal» — 30 pedidos web espaçados e 10 pings.

   sudo ip netns exec pc-adm sh -c 'for i in $(seq 30); do python3 -c "import urllib.request as u; u.urlopen(\"http://10.10.20.53/\")"; sleep 5; done'
   sudo ip netns exec pc-adm ping -c 10 -i 2 10.10.20.53
   Depois, Ctrl+C na consola A.

4. Resuma a captura por protocolo e por conversa.

   tshark -r /tmp/base.pcap -q -z io,phs
   tshark -r /tmp/base.pcap -q -z conv,ip

   Saída de exemplo (didáctica):

   eth frames:~260 ... ip ... tcp frames:~240 ... http frames:60 ... icmp frames:20
   10.10.10.10 <-> 10.10.20.53  frames ~260  bytes ~110 kB

Critérios de sucesso

• A folha de linha de base tem: período, protocolos e percentagens, conversas principais, volume total.
• O formando indica duas limitações de uma medição de 5 minutos.

Como desfazer (reversão)

• Ctrl+C na consola C
• rm -f /tmp/base.pcap

Alternativa em papel: tarefas e respostas esperadas

Com a saída de exemplo, escreva a linha de base em quatro linhas.

Período de 5 min; ~260 tramas; HTTP ~60 tramas e ICMP 20; uma única conversa relevante pc-adm ↔ srv; volume ~110 kB.

Na semana seguinte aparecem 5000 tramas SMB entre pc-adm e 10.10.20.40 às 02h00. Qual é o primeiro passo?

Verificar se é uma actividade conhecida (por exemplo cópia de segurança agendada) antes de tratar como incidente; se não for, abrir registo de evento.

Verifique o que aprendeu

Questão 1

Para que serve a linha de base?

1. Para medir a velocidade máxima
2. Para ter uma referência do normal e reconhecer desvios
3. Para substituir a firewall
4. Para apagar registos antigos

Questão 2

Porque uma medição de 5 minutos não chega para a linha de base real?

1. Porque é ilegal
2. Porque não inclui variações por hora, dia e fim de mês
3. Porque o tshark falha
4. Chega sempre

Em leitura fácil

• Primeiro, anote como é a rede num dia normal.
• Depois, compare com o que vê agora.
• Diferença não quer dizer ataque: confirme.

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-92 — Guide to Computer Security Log Management (https://csrc.nist.gov/pubs/sp/800/92/final)

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)

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)

Duração: 80 minutos (explicação 20, prática guiada 50, verificação 10). Resultados dos TdR trabalhados: Incidentes: contenção, análise, recuperação e relatório; Trabalho em equipa, projectos, ética e confidencialidade.

Objectivos

• Aplicar as fases de resposta a incidentes (preparação, detecção e análise, contenção, erradicação, recuperação, lições aprendidas).
• Conter um equipamento suspeito na rede de prática preservando a prova.
• Comunicar o incidente aos papéis certos, com factos.

Fases e decisões

O NIST SP 800-61 Rev. 3 enquadra a resposta nas funções do NIST CSF 2.0 (identificar, proteger, detectar, responder, recuperar, governar). Na prática, a equipa percorre: confirmar o incidente; conter (isolar sem destruir prova); erradicar a causa; recuperar o serviço e verificar; registar lições.

Conter não é desligar tudo. Isolar pela rede (regra na firewall, porta em VLAN de quarentena) mantém o equipamento ligado e a memória intacta para análise. Cada acção fica no registo de incidente com hora, autor e motivo. Comunicação: responsável de TI, direcção e, quando aplicável, as entidades previstas no plano institucional.

Caso fictício

Confirmado (em exercício) que o pc-del da delegação fictícia da DPE está a varrer a sede. A direcção pede contenção imediata sem perder a prova.

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.

Passos

1. Abra o registo do incidente (papel ou ficheiro) com: número, hora de início, quem detectou, factos.

   cat > /tmp/incidente-07.txt <<'EOF'
   Incidente 07 (exercicio) — aberto 2026-09-28 10:10 por tecnico A
   Factos: 30 SYN de 10.20.10.10 para o srv em 1 min (captura anom.pcap)
   EOF

2. Prepare as rotas e confirme que o pc-del alcança a sede.

   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. Contenção: no r2, isole o pc-del de tudo excepto da gestão (para análise remota posterior).

   sudo ip netns exec r2 nft add table inet quarentena
   sudo ip netns exec r2 nft 'add chain inet quarentena forward { type filter hook forward priority -10; policy accept; }'
   sudo ip netns exec r2 nft add rule inet quarentena forward ip saddr 10.20.10.10 ip daddr != 10.10.99.0/24 counter drop comment \"incidente 07\"
   echo "$(date -Is) contencao: regra quarentena em r2 (tecnico A)" >> /tmp/incidente-07.txt

4. Verifique a contenção e que a restante delegação não foi afectada (neste lab só existe o pc-del: registe essa limitação).

   sudo ip netns exec pc-del ping -c 1 -W 1 10.10.20.53
   sudo ip netns exec r2 nft list table inet quarentena

   Saída de exemplo (didáctica):

   1 packets transmitted, 0 received
   ip saddr 10.20.10.10 ip daddr != 10.10.99.0/24 counter packets 1 bytes 84 drop comment "incidente 07"

Critérios de sucesso

• O pc-del está isolado sem ter sido desligado.
• O registo do incidente tem cada acção com hora e autor.
• O formando indica a fase seguinte (erradicação) e quem deve ser informado.

Como desfazer (reversão)

• sudo ip netns exec r2 nft delete table inet quarentena
• 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/incidente-07.txt

Alternativa em papel: tarefas e respostas esperadas

Ordene as acções: recuperar serviço; conter; lições aprendidas; confirmar incidente; erradicar.

Confirmar incidente → conter → erradicar → recuperar serviço → lições aprendidas.

Porque é preferível isolar pela rede a desligar o pc-del da corrente?

Mantém a memória e os processos para análise; desligar pode apagar indícios voláteis.

Verifique o que aprendeu

Questão 1

Qual acção é de contenção?

1. Reinstalar o sistema
2. Isolar o equipamento numa quarentena de rede
3. Escrever as lições aprendidas
4. Comprar novo antivírus

Questão 2

O que deve constar de cada entrada do registo do incidente?

1. Só a conclusão
2. Hora, autor, acção e motivo
3. O nome do culpado
4. Nada, para não deixar rasto

Em leitura fácil

• Primeiro confirme.
• Depois isole o computador, sem o desligar.
• Anote tudo: hora, quem fez, o quê.

Fontes

• NIST SP 800-61 Rev. 3 — Incident Response Recommendations (https://csrc.nist.gov/pubs/sp/800/61/r3/final)
• NIST Cybersecurity Framework 2.0 (https://www.nist.gov/cyberframework)
• Projecto nftables — wiki oficial (https://wiki.nftables.org/)

Duração: 80 minutos (explicação 20, prática guiada 50, verificação 10). Resultados dos TdR trabalhados: Documentação: diagramas, procedimentos (SOP) e contingência; Incidentes: contenção, análise, recuperação e relatório.

Objectivos

• Redigir um relatório de incidente com factos, cronologia, impacto e acções.
• Transformar lições aprendidas em alterações concretas com responsável e prazo.
• Actualizar um procedimento operacional normalizado (SOP) a partir do incidente.

Do incidente à melhoria

O relatório final responde: o que aconteceu, quando, como foi detectado, o que foi afectado, o que se fez, qual é o estado actual e o que muda. Escreve-se para leitores diferentes: resumo de uma página para a direcção, anexo técnico para a equipa.

Lições aprendidas só valem se virarem acções: «criar regra de alerta para varrimentos», responsável, prazo, forma de verificar. Os SOP (procedimentos normalizados) são actualizados e versionados; o próximo técnico de piquete segue o procedimento em vez de improvisar.

Caso fictício

O incidente 07 (exercício) da DPE fictícia está encerrado. A direcção pede o relatório e as melhorias até ao fim da semana.

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)

• Sem rede: trabalho com o registo do incidente 07 da lição anterior (ou o modelo abaixo) e um editor de texto ou papel.

Passos

1. Crie o esqueleto do relatório.

   cat > /tmp/relatorio-07.md <<'EOF'
   # Relatório do incidente 07 (exercício)
   ## Resumo para a direcção (máx. 10 linhas)
   ## Cronologia (hora — facto — fonte)
   ## Impacto (serviços, pessoas, dados)
   ## Acções realizadas (contenção, erradicação, recuperação)
   ## Estado actual
   ## Lições aprendidas e acções (acção — responsável — prazo — verificação)
   ## Anexos técnicos (comandos, capturas, registos)
   EOF

2. Preencha a cronologia a partir do registo, só com factos e fonte de cada linha.

   sed -n '1,20p' /tmp/relatorio-07.md

3. Actualize o SOP «Suspeita de varrimento interno» com os passos que funcionaram; versione-o.

   mkdir -p /tmp/sop && cd /tmp/sop && git init -q && git config user.name 'Tecnico Pratica' && git config user.email 'ti@dpe.example'
   cat > /tmp/sop/varrimento.md <<'EOF'
   # SOP — Suspeita de varrimento interno (v2)
   1. Confirmar com captura e registos (comandos em anexo).
   2. Contactar responsável do equipamento/delegação.
   3. Se não autorizado: quarentena de rede (regra modelo em anexo), sem desligar.
   4. Abrir registo de incidente; informar responsável de TI.
   5. Após análise: erradicar, recuperar, verificar, relatório.
   EOF
   git add varrimento.md && git commit -qm 'SOP varrimento v2 (lições do incidente 07)' && git log --oneline

   Saída de exemplo (didáctica):

   a1 SOP varrimento v2 (lições do incidente 07)

Critérios de sucesso

• Relatório com resumo compreensível por quem não é técnico.
• Pelo menos três acções com responsável, prazo e verificação.
• SOP versionado.

Como desfazer (reversão)

• rm -rf /tmp/sop /tmp/relatorio-07.md

Alternativa em papel: tarefas e respostas esperadas

Reescreva para a direcção: «SYN flood-like scan c/ 30 RST do 10.20.10.10, contido via nft no r2».

«Um computador da delegação tentou ligar-se a 30 serviços do servidor da sede num minuto. Foi isolado da rede às 10h12 sem ser desligado, para análise. Os serviços da sede não foram interrompidos.»

Transforme a lição «demorámos a perceber» numa acção verificável.

Exemplo: «Activar alerta IDS para mais de 10 SYN/10 s da mesma origem interna — responsável: técnico B — prazo: 15 dias — verificação: teste em rede de prática gera alerta».

Verifique o que aprendeu

Questão 1

Qual é a melhor forma de registar uma lição aprendida?

1. «Ter mais cuidado»
2. Acção concreta com responsável, prazo e verificação
3. Uma lista de culpados
4. Não registar para não expor a equipa

Questão 2

Porque se versiona o SOP?

1. Por estética
2. Para saber o que mudou, quando e porquê, e poder voltar atrás
3. Porque o git é obrigatório
4. Para esconder versões

Em leitura fácil

• Depois do problema, escreva o que aconteceu.
• Diga o que vai mudar, quem faz e até quando.
• Actualize o procedimento para a próxima vez.

Fontes

• NIST SP 800-61 Rev. 3 — Incident Response Recommendations (https://csrc.nist.gov/pubs/sp/800/61/r3/final)
• NIST Cybersecurity Framework 2.0 (https://www.nist.gov/cyberframework)
• Git — documentação oficial (https://git-scm.com/doc)

Duração: 70 minutos (explicação 20, prática guiada 40, verificação 10). Resultados dos TdR trabalhados: LAN, WAN, WLAN, virtualização e nuvem.

Objectivos

• Distinguir rede local e rede de longa distância pelo alcance, pelo proprietário do meio e pelas características da ligação.
• Comparar as tecnologias de ligação mais comuns (fibra, rádio ponto-a-ponto, ligação móvel, satélite, circuito dedicado do operador) por débito, atraso, disponibilidade e custo relativo.
• Medir, numa ligação simulada, como o atraso e a perda alteram a experiência de um serviço.

O que muda quando a ligação sai do edifício

Numa rede local a instituição é dona dos cabos e dos comutadores, as distâncias são curtas e o débito é alto. Numa rede de longa distância (WAN) o meio pertence normalmente a um operador, a distância é grande e cada megabit é pago. O técnico deixa de controlar o caminho: passa a controlar o contrato, os equipamentos das pontas e a forma como o tráfego é enviado.

Quatro medidas descrevem uma ligação WAN: débito (quantos bits por segundo passam), atraso (tempo de ida e volta, RTT), variação do atraso (jitter) e perda de pacotes. Uma ligação pode ter débito alto e mesmo assim ser má para chamadas de voz, se tiver atraso ou jitter elevados.

Tecnologias comuns e compromissos

Fibra óptica do operador: débito alto e atraso baixo, mas depende de a fibra chegar ao local. Rádio ponto-a-ponto: útil entre edifícios com linha de vista; sensível a obstáculos e chuva forte em algumas frequências. Ligação móvel (4G/5G): rápida de instalar, com débito e atraso variáveis consoante a cobertura e a carga da célula. Satélite geoestacionário: chega a zonas remotas, mas o atraso de ida e volta é tipicamente superior a 500 ms por causa da distância ao satélite; constelações de órbita baixa têm atrasos menores. Circuito dedicado ou serviço de rede privada do operador: características garantidas por contrato, custo mais alto.

Não há tecnologia «melhor» em absoluto. Escolhe-se pelo serviço que vai passar, pela disponibilidade no local, pelo orçamento e pela necessidade de alternativa. Os valores concretos de débito, atraso e preço vêm sempre da proposta escrita do operador e de medições no local.

Caso fictício

A Direcção Provincial de Exemplo (DPE, fictícia) vai abrir uma delegação distrital. O operador A oferece ligação móvel (débito anunciado 20 Mbit/s, atraso típico 60 ms); o operador B oferece satélite geoestacionário (10 Mbit/s, atraso típico 600 ms). A delegação usará o sistema de gestão documental na sede e fará videochamadas semanais. Todos os valores são fictícios.

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).
• A ligação r1–r2 (10.255.0.0/30) representa a WAN sede–delegação.
• Simulação: o atraso e a perda são introduzidos com tc netem na interface r2-r1 (só dentro do espaço de nomes r2).

Passos

1. Pré-requisito: confirme que a delegação chega ao srv (rotas do módulo 3).

   sudo ip netns exec pc-del ping -c 3 10.10.20.53

   Saída de exemplo (didáctica):

   3 packets transmitted, 3 received, 0% packet loss
   rtt min/avg/max/mdev = 0.05/0.07/0.09/0.02 ms

2. Consola C: inicie um serviço web de teste no srv (esperar «Serving HTTP»).

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

3. Meça o tempo de um pedido web sem simulação.

   sudo ip netns exec pc-del python3 -c "import time,urllib.request as u; t=time.time(); u.urlopen('http://10.10.20.53/').read(); print(round((time.time()-t)*1000),'ms')"

   Saída de exemplo (didáctica):

   3 ms

4. Simule a ligação móvel do operador A. O netem só atrasa os pacotes que saem de r2-r1; aplicando 60 ms num só sentido, a ida e volta fica perto de 60 ms.

   sudo ip netns exec r2 tc qdisc add dev r2-r1 root netem delay 60ms 10ms
   sudo ip netns exec pc-del ping -c 5 10.10.20.53

   Saída de exemplo (didáctica):

   rtt min/avg/max/mdev = 51.2/60.4/69.8/6.1 ms

5. Repita o pedido web e anote.

   sudo ip netns exec pc-del python3 -c "import time,urllib.request as u; t=time.time(); u.urlopen('http://10.10.20.53/').read(); print(round((time.time()-t)*1000),'ms')"

   Saída de exemplo (didáctica):

   125 ms (cerca de duas idas e voltas: estabelecer a ligação TCP e o pedido)

6. Simule o satélite do operador B (600 ms) e repita as duas medições.

   sudo ip netns exec r2 tc qdisc change dev r2-r1 root netem delay 600ms 20ms
   sudo ip netns exec pc-del ping -c 5 10.10.20.53

   Saída de exemplo (didáctica):

   rtt min/avg/max/mdev = 582.0/601.3/619.5/13.2 ms
   Pedido web: cerca de 1210 ms

7. Acrescente 2 % de perda à simulação do operador A e observe o ping.

   sudo ip netns exec r2 tc qdisc change dev r2-r1 root netem delay 60ms 10ms loss 2%
   sudo ip netns exec pc-del ping -c 50 -i 0.2 10.10.20.53

   Saída de exemplo (didáctica):

   50 packets transmitted, 49 received, 2% packet loss (o número exacto varia em cada execução)

Critérios de sucesso

• A tabela da dupla tem, para cada cenário, RTT médio, tempo do pedido web e perda.
• O formando explica porque o pedido web demora cerca de duas vezes o RTT.
• A dupla recomenda um operador para o caso, com duas razões e um risco.

Como desfazer (reversão)

• sudo ip netns exec r2 tc qdisc del dev r2-r1 root
• Ctrl+C na consola C (servidor web).
• Verificar: sudo ip netns exec r2 tc qdisc show dev r2-r1 deve mostrar só a fila por omissão (noqueue ou pfifo_fast).

Alternativa em papel: tarefas e respostas esperadas

Com as saídas de exemplo, preencha: cenário | RTT médio | pedido web. (sem simulação, operador A, operador B).

Sem simulação: 0,07 ms | 3 ms. Operador A: 60 ms | 125 ms. Operador B: 601 ms | 1210 ms.

Qual operador recomenda para a delegação do caso? Dê duas razões e um risco.

Operador A (móvel): atraso de 60 ms serve para a gestão documental e para videochamadas; débito anunciado maior. Risco: débito e atraso variam com a cobertura e a carga da célula; é preciso medir no local e prever alternativa. O satélite fica como alternativa se não houver cobertura móvel.

Uma ligação tem 100 Mbit/s mas 5 % de perda. Serve para chamadas de voz?

Dificilmente: a perda corta a voz e o TCP abranda por causa das retransmissões. O débito alto não compensa a perda.

Verifique o que aprendeu

Questão 1

Numa ligação por satélite geoestacionário, o que mais prejudica uma videochamada?

1. O débito, que é sempre inferior a 1 Mbit/s
2. O atraso de ida e volta elevado
3. A falta de endereço IP
4. O número de VLAN

Questão 2

Porque um pedido web demorou cerca de 125 ms numa ligação com 60 ms de RTT?

1. Porque o servidor é lento
2. Porque são precisas pelo menos duas idas e voltas: estabelecer a ligação TCP e enviar o pedido
3. Porque o tc duplica os pacotes
4. Porque o DNS falhou

Em leitura fácil

• Uma rede de longa distância liga edifícios longe uns dos outros.
• O caminho normalmente é do operador, não da instituição.
• Veja quatro coisas: velocidade, atraso, variação do atraso e perda.
• Muita velocidade não chega se o atraso ou a perda forem altos.

Fontes

• 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)
• IETF RFC 9293 — Transmission Control Protocol (https://www.rfc-editor.org/rfc/rfc9293)
• IETF RFC 792 — Internet Control Message Protocol (https://www.rfc-editor.org/rfc/rfc792)
• Debian 12 «bookworm» — Manual de Segurança e pacotes oficiais (https://www.debian.org/doc/manuals/securing-debian-manual/)

Duração: 75 minutos (explicação 20, prática guiada 45, verificação 10). Resultados dos TdR trabalhados: Serviços de rede: DHCP, DNS, VPN, NAT, VLAN e autenticação; Protecção de dados e identidades: MFA e cifra.

Objectivos

• Explicar o que uma rede privada virtual (VPN) protege e o que não protege numa ligação que atravessa o operador.
• Comparar IPsec e WireGuard quanto a normas, configuração e compatibilidade entre fabricantes.
• Configurar um túnel WireGuard entre sede e delegação e provar, por captura, que o tráfego interno segue cifrado.

Um túnel cifrado por cima de um caminho que não controlamos

Quando a ligação sede–delegação passa pelo operador ou pela Internet, quem estiver no caminho pode ler ou alterar pacotes não protegidos. Uma VPN entre locais (site-to-site) encapsula os pacotes internos dentro de pacotes cifrados e autenticados entre os dois encaminhadores. O conteúdo e os endereços internos deixam de ser visíveis no caminho; continuam visíveis os endereços das pontas do túnel, o volume e a hora do tráfego.

A VPN não substitui a firewall nem a segurança dos postos: um computador infectado na delegação continua a chegar à sede, agora por um canal cifrado. Por isso filtra-se também o que pode entrar pelo túnel.

IPsec e WireGuard

IPsec é uma arquitectura normalizada pelo IETF (RFC 4301), suportada pela generalidade dos encaminhadores e firewalls de fabricantes; tem muitas opções (IKEv2, algoritmos, modos), o que dá flexibilidade mas exige que as duas pontas acordem exactamente os mesmos parâmetros. É a escolha habitual quando uma ponta é equipamento de outro fabricante ou do operador.

WireGuard usa um conjunto fixo de algoritmos modernos e chaves públicas trocadas entre as pontas, com configuração curta; está incluído no núcleo Linux desde a versão 5.6. Não é, até à data da consulta, uma norma IETF, e o suporte em equipamentos de fabricantes varia: confirma-se na documentação do equipamento concreto. Em ambos os casos, as chaves privadas nunca saem do equipamento e as recomendações de algoritmos seguem orientações oficiais actualizadas (NIST SP 800-77 para IPsec).

Caso fictício

Na DPE (fictícia) a ligação r1–r2 passa a ser fornecida por um operador externo. A direcção pede garantia de que os documentos trocados entre a delegação e o servidor srv não possam ser lidos no caminho. O técnico propõe um túnel WireGuard entre r1 e r2, com endereços de túnel 10.255.2.1 e 10.255.2.2.

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).
• Caminho do operador (não confiável): r1 10.255.0.1 — r2 10.255.0.2.
• Túnel wg0: r1 10.255.2.1/30 (porta UDP 51820) — r2 10.255.2.2/30.
• Depois da prática: 10.20.10.0/24 e 10.10.0.0/16 passam pelo wg0 em vez do caminho directo.

Passos

1. Pré-verificação: o módulo wireguard existe e wg0 não está em uso nos dois encaminhadores.

   sudo modprobe wireguard && echo modulo-ok
   sudo ip -n r1 link show wg0 2>/dev/null && echo 'wg0 JA EXISTE em r1: parar'
   sudo ip -n r2 link show wg0 2>/dev/null && echo 'wg0 JA EXISTE em r2: parar'

   Saída de exemplo (didáctica):

   modulo-ok
   (nenhuma outra linha: pode continuar)

2. Consola A: capture no caminho do operador antes do túnel e gere um pedido do pc-del ao srv (ver o texto em claro).

   Consola C: sudo ip netns exec srv python3 -m http.server 80 --bind 10.10.20.53
   Consola A: sudo ip netns exec r2 tcpdump -ni r2-r1 -A 'tcp port 80'  (esperar «listening on r2-r1»)
   Consola B: sudo ip netns exec pc-del python3 -c "import urllib.request as u; u.urlopen('http://10.10.20.53/').read()"
   Ctrl+C na consola A.

   Saída de exemplo (didáctica):

   IP 10.20.10.10.51022 > 10.10.20.53.80: Flags [P.] ... GET / HTTP/1.1
   (o pedido é legível no caminho do operador)

3. Gere as chaves (em /tmp da máquina de prática, só leitura do root).

   sudo sh -c 'umask 077; wg genkey | tee /tmp/m9-r1.key | wg pubkey > /tmp/m9-r1.pub'
   sudo sh -c 'umask 077; wg genkey | tee /tmp/m9-r2.key | wg pubkey > /tmp/m9-r2.pub'

4. Crie o túnel nas duas pontas.

   sudo ip -n r1 link add wg0 type wireguard
   sudo ip netns exec r1 wg set wg0 listen-port 51820 private-key /tmp/m9-r1.key peer $(sudo cat /tmp/m9-r2.pub) endpoint 10.255.0.2:51820 allowed-ips 10.255.2.2/32,10.20.10.0/24
   sudo ip -n r1 addr add 10.255.2.1/30 dev wg0 && sudo ip -n r1 link set wg0 up
   sudo ip -n r2 link add wg0 type wireguard
   sudo ip netns exec r2 wg set wg0 listen-port 51820 private-key /tmp/m9-r2.key peer $(sudo cat /tmp/m9-r1.pub) endpoint 10.255.0.1:51820 allowed-ips 10.255.2.1/32,10.10.0.0/16
   sudo ip -n r2 addr add 10.255.2.2/30 dev wg0 && sudo ip -n r2 link set wg0 up

5. Desvie as rotas internas para o túnel.

   sudo ip -n r1 route replace 10.20.10.0/24 via 10.255.2.2 dev wg0
   sudo ip -n r2 route replace 10.10.0.0/16 via 10.255.2.1 dev wg0
   sudo ip netns exec pc-del traceroute -n 10.10.20.53

   Saída de exemplo (didáctica):

    1  10.20.10.1  0.05 ms
    2  10.255.2.1  0.40 ms
    3  10.10.20.53  0.45 ms

6. Repita a captura no caminho do operador e o mesmo pedido.

   Consola A: sudo ip netns exec r2 tcpdump -ni r2-r1 'udp port 51820 or tcp port 80'
   Consola B: repetir o pedido do pc-del.
   sudo ip netns exec r1 wg show wg0 latest-handshakes

   Saída de exemplo (didáctica):

   IP 10.255.0.2.51820 > 10.255.0.1.51820: UDP, length 128
   IP 10.255.0.1.51820 > 10.255.0.2.51820: UDP, length 96
   (nenhuma linha tcp port 80 no caminho do operador)
   (chave pública de r2)	1759055000

Critérios de sucesso

• Antes do túnel, o pedido HTTP é legível no caminho; depois, só aparecem pacotes UDP 51820 entre 10.255.0.1 e 10.255.0.2.
• O traceroute mostra 10.255.2.1 como segundo salto.
• O formando indica o que continua visível ao operador (endereços das pontas, volume, hora).

Como desfazer (reversão)

• sudo ip -n r1 route replace 10.20.10.0/24 via 10.255.0.2
• sudo ip -n r2 route replace 10.10.0.0/16 via 10.255.0.1
• sudo ip -n r1 link del wg0; sudo ip -n r2 link del wg0
• sudo rm -f /tmp/m9-r1.key /tmp/m9-r1.pub /tmp/m9-r2.key /tmp/m9-r2.pub
• Ctrl+C nas consolas A e C. Verificar: sudo ip netns exec pc-del traceroute -n 10.10.20.53 volta a mostrar 10.255.0.1 no segundo salto.

Alternativa em papel: tarefas e respostas esperadas

Compare as duas capturas de exemplo: o que via o operador antes e depois do túnel?

Antes: endereços internos 10.20.10.10 e 10.10.20.53, porta 80 e o texto «GET / HTTP/1.1». Depois: só UDP 51820 entre 10.255.0.2 e 10.255.0.1, com tamanhos e horas; o conteúdo e os endereços internos deixam de ser visíveis.

Na linha allowed-ips do r1 está 10.255.2.2/32,10.20.10.0/24. Explique o que acontece se faltar 10.20.10.0/24.

O WireGuard não aceita pacotes vindos do túnel com origem na delegação nem envia para lá tráfego destinado a 10.20.10.0/24: a delegação deixa de chegar à sede pelo túnel, embora o aperto de mão possa existir.

A delegação vai ligar-se a um encaminhador de outro fabricante que só suporta IPsec. Que muda na proposta?

Usar IPsec com IKEv2, acordando os mesmos parâmetros nas duas pontas, com base na documentação do equipamento e em NIST SP 800-77; o princípio (túnel cifrado entre locais e filtragem do que entra) mantém-se.

Verifique o que aprendeu

Questão 1

Com um túnel VPN entre sede e delegação, o que o operador ainda consegue ver?

1. O conteúdo dos documentos
2. Os endereços internos dos postos
3. Os endereços públicos das pontas, o volume e a hora do tráfego
4. Nada, o tráfego fica invisível

Questão 2

Um posto infectado na delegação liga-se à sede pela VPN. A VPN impede o ataque?

1. Sim, porque o tráfego é cifrado
2. Não; a VPN protege o caminho, não os postos — é preciso filtrar e proteger os equipamentos
3. Sim, se for IPsec
4. Sim, se a chave for longa

Em leitura fácil

• Uma VPN é um túnel fechado por cima do caminho do operador.
• Quem está no caminho não consegue ler o que vai dentro do túnel.
• A VPN não limpa um computador infectado.
• As chaves secretas nunca saem do equipamento.

Fontes

• WireGuard — documentação e wg(8) (https://www.wireguard.com/quickstart/)
• IETF RFC 4301 — Security Architecture for the Internet Protocol (IPsec) (https://www.rfc-editor.org/rfc/rfc4301)
• NIST SP 800-77 Rev. 1 — Guide to IPsec VPNs (https://csrc.nist.gov/pubs/sp/800/77/r1/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)
• tcpdump/libpcap — manual tcpdump(1) e pcap-filter(7) (https://www.tcpdump.org/manpages/)

Duração: 75 minutos (explicação 20, prática guiada 45, verificação 10). Resultados dos TdR trabalhados: Conceber, configurar e administrar redes pequenas, médias e grandes; LAN, WAN, WLAN, virtualização e nuvem.

Objectivos

• Comparar topologias em estrela (sede ao centro) e em malha para ligar várias delegações.
• Planear o endereçamento de delegações de forma a permitir rotas resumidas.
• Acrescentar uma segunda delegação à rede de prática e limitar, na sede, o tráfego directo entre delegações ao necessário.

Estrela ou malha

Na estrela cada delegação liga-se só à sede; o tráfego entre delegações passa pela sede. É simples de gerir e de controlar (um só ponto de filtragem), mas a sede torna-se ponto único de falha e o caminho entre delegações é mais longo. Na malha as delegações ligam-se também entre si; o caminho é mais curto e há alternativas, mas cresce o número de ligações e de túneis a gerir (n delegações exigem até n×(n−1)/2 ligações).

Para instituições públicas com serviços centralizados na sede, a estrela é normalmente o ponto de partida; acrescenta-se malha parcial só onde há tráfego intenso entre delegações ou necessidade de alternativa.

Endereçamento que se resume

Se todas as delegações usarem blocos contíguos (10.20.0.0/16 dividido em /24 por delegação: 10.20.10.0/24, 10.20.20.0/24, …), a sede pode anunciar uma rota resumida 10.20.0.0/16 em vez de uma por delegação (RFC 4632). Menos rotas significa tabelas mais pequenas e menos erros. O plano deve ser escrito antes de abrir a segunda delegação.

Ligar redes de instituições diferentes exige também acordo escrito: quem é responsável por cada ponta, que serviços podem passar, contactos e procedimento em caso de incidente. Endereços privados sobrepostos entre instituições resolvem-se com replaneamento ou NAT, decidido nesse acordo.

Caso fictício

A DPE (fictícia) abre uma segunda delegação com a rede 10.20.20.0/24, encaminhador r3 e posto pc-del2, ligada à sede pela WAN 10.255.3.0/30 (r1 = 10.255.3.1, r3 = 10.255.3.2). As delegações só precisam de aceder aos serviços da sede; a comunicação directa entre delegações deve ser recusada salvo ping de diagnóstico.

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).
• Novo: r3 (encaminhador da delegação 2) ligado a r1 por 10.255.3.0/30 e a pc-del2 (10.20.20.10/24, porta 10.20.20.1).
• Estrela: delegação 1 e delegação 2 só se ligam a r1.

Passos

1. Pré-verificação: os nomes novos não existem na máquina.

   for n in r3 pc-del2; do ip netns list | grep -qw "$n" && echo "$n JA EXISTE: parar"; done; echo verificado

   Saída de exemplo (didáctica):

   verificado

2. Crie a delegação 2 (espaços de nomes e ligações).

   sudo ip netns add r3; sudo ip netns add pc-del2
   sudo ip link add r1-r3 type veth peer name r3-r1; sudo ip link set r1-r3 netns r1; sudo ip link set r3-r1 netns r3
   sudo ip link add r3-pc-del2 type veth peer name pc-del2-r3; sudo ip link set r3-pc-del2 netns r3; sudo ip link set pc-del2-r3 netns pc-del2
   sudo ip -n r1 addr add 10.255.3.1/30 dev r1-r3; sudo ip -n r3 addr add 10.255.3.2/30 dev r3-r1
   sudo ip -n r3 addr add 10.20.20.1/24 dev r3-pc-del2; sudo ip -n pc-del2 addr add 10.20.20.10/24 dev pc-del2-r3
   for n in r3 pc-del2; do sudo ip -n $n link set lo up; done; sudo ip -n r1 link set r1-r3 up; sudo ip -n r3 link set r3-r1 up; sudo ip -n r3 link set r3-pc-del2 up; sudo ip -n pc-del2 link set pc-del2-r3 up
   sudo ip netns exec r3 sysctl -qw net.ipv4.ip_forward=1

3. Rotas em estrela: a delegação 2 envia tudo o que é interno para a sede; a sede conhece a nova rede.

   sudo ip -n pc-del2 route add default via 10.20.20.1
   sudo ip -n r3 route add 10.0.0.0/8 via 10.255.3.1
   sudo ip -n r1 route add 10.20.20.0/24 via 10.255.3.2
   sudo ip -n r2 route add 10.20.20.0/24 via 10.255.0.1
   sudo ip netns exec pc-del2 ping -c 2 10.10.20.53
   sudo ip netns exec pc-del2 traceroute -n 10.20.10.10

   Saída de exemplo (didáctica):

   2 packets transmitted, 2 received
    1  10.20.20.1  0.05 ms
    2  10.255.3.1  0.07 ms
    3  10.255.0.2  0.09 ms
    4  10.20.10.10  0.10 ms

4. Na sede, recuse o tráfego entre delegações excepto ping (tabela própria, fácil de remover).

   sudo ip netns exec r1 nft add table inet m9deleg
   sudo ip netns exec r1 nft add chain inet m9deleg fwd '{ type filter hook forward priority 0; policy accept; }'
   sudo ip netns exec r1 nft add rule inet m9deleg fwd ip saddr 10.20.0.0/16 ip daddr 10.20.0.0/16 icmp type echo-request accept
   sudo ip netns exec r1 nft add rule inet m9deleg fwd ip saddr 10.20.0.0/16 ip daddr 10.20.0.0/16 ct state established,related accept
   sudo ip netns exec r1 nft add rule inet m9deleg fwd ip saddr 10.20.0.0/16 ip daddr 10.20.0.0/16 counter drop

5. Teste: ping entre delegações passa; web da delegação 2 para a 1 é recusado; web para a sede continua.

   Consola C: sudo ip netns exec pc-del python3 -m http.server 80 --bind 10.20.10.10
   sudo ip netns exec pc-del2 ping -c 1 10.20.10.10
   sudo ip netns exec pc-del2 python3 -c "import urllib.request as u; u.urlopen('http://10.20.10.10/', timeout=3)"
   sudo ip netns exec r1 nft list chain inet m9deleg fwd

   Saída de exemplo (didáctica):

   1 packets transmitted, 1 received
   TimeoutError: timed out  (ou urlopen error timed out)
   ... counter packets 2 bytes 120 drop

Critérios de sucesso

• pc-del2 chega ao srv e o traceroute para a delegação 1 passa pela sede (10.255.3.1).
• O pedido web entre delegações falha e o contador drop aumenta; o ping passa.
• A dupla escreve a rota resumida que a sede poderia anunciar (10.20.0.0/16).

Como desfazer (reversão)

• Ctrl+C na consola C.
• sudo ip netns exec r1 nft delete table inet m9deleg
• sudo ip -n r2 route del 10.20.20.0/24 via 10.255.0.1
• sudo ip -n r1 route del 10.20.20.0/24 via 10.255.3.2
• sudo ip netns del pc-del2; sudo ip netns del r3 (só estes dois nomes, criados nesta lição; apagar o espaço r3 remove também a ponta r1-r3)
• Verificar: sudo ip -n r1 link show r1-r3 deve responder «does not exist».

Alternativa em papel: tarefas e respostas esperadas

A DPE vai ter 6 delegações. Quantas ligações exige a estrela e quantas a malha completa?

Estrela: 6 (uma por delegação). Malha completa entre sede e 6 delegações (7 locais): 7×6/2 = 21.

Atribua redes às delegações 3 e 4 e escreva a rota resumida.

Delegação 3: 10.20.30.0/24; delegação 4: 10.20.40.0/24. Rota resumida na sede e para fora: 10.20.0.0/16 (cobre 10.20.0.0 a 10.20.255.255).

Com a saída de exemplo do nft, explique porque o pedido web falhou e o ping passou.

A regra aceita echo-request entre 10.20.0.0/16 e respostas de ligações estabelecidas; o pedido web (TCP 80) não é aceite e cai na última regra, que o recusa e conta 2 pacotes (tentativas SYN).

Verifique o que aprendeu

Questão 1

Qual é a principal desvantagem da topologia em estrela?

1. Exige mais ligações do que a malha
2. A sede é ponto único de falha e o tráfego entre delegações faz um caminho mais longo
3. Não permite VPN
4. Não permite rotas resumidas

Questão 2

Porque se atribuem às delegações blocos contíguos dentro de 10.20.0.0/16?

1. Por obrigação legal
2. Para poder usar uma só rota resumida e reduzir erros
3. Para ter mais velocidade
4. Para não precisar de encaminhador

Em leitura fácil

• Estrela: todas as delegações ligam-se à sede.
• Malha: as delegações também se ligam entre si.
• Dê a cada delegação um bloco de endereços em sequência.
• Escreva um acordo antes de ligar redes de instituições diferentes.

Fontes

• IETF RFC 4632 — Classless Inter-domain Routing (CIDR) (https://www.rfc-editor.org/rfc/rfc4632)
• IETF RFC 1918 — Address Allocation for Private Internets (https://www.rfc-editor.org/rfc/rfc1918)
• 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)
• Projecto nftables — wiki oficial (https://wiki.nftables.org/)

Duração: 80 minutos (explicação 20, prática guiada 50, verificação 10). Resultados dos TdR trabalhados: Continuidade e protecção de activos digitais; Diagnóstico, desempenho e disponibilidade.

Objectivos

• Calcular o tempo de indisponibilidade admitido por uma percentagem de disponibilidade num contrato.
• Identificar o que um contrato de ligação (acordo de nível de serviço) deve conter e como se verifica.
• Demonstrar porque uma rota de reserva baseada só no estado da interface não detecta uma falha «silenciosa», e aplicar uma verificação activa do próximo salto.

Percentagens que se traduzem em horas

Um contrato de 99,5 % de disponibilidade mensal admite 0,5 % de um mês sem serviço: em 30 dias (720 horas) são 3,6 horas. 99,9 % admite cerca de 43 minutos; 99,99 %, cerca de 4 minutos. Antes de assinar, pergunta-se: como mede o operador, em que período (mês, ano), se as manutenções programadas contam, qual o tempo de reposição, que compensação existe e como se abre uma avaria (contacto, horário, número de registo).

A instituição deve medir por si própria (monitoria da ligação, módulo 11) para poder comparar com o relatório do operador. Sem medição própria, o contrato é difícil de fazer cumprir.

Redundância que detecta a falha certa

No módulo 3 a rota de reserva entrava quando a interface principal ficava em baixo. Na WAN é frequente o contrário: a interface local continua «em cima» (o equipamento do operador responde ao nível físico), mas o tráfego não passa mais à frente. Nesse caso a rota principal continua activa e o tráfego perde-se.

Soluções: um protocolo de encaminhamento dinâmico com temporizadores (OSPF, módulo 3), a detecção bidireccional BFD (RFC 5880, suportada pelo FRRouting e por muitos fabricantes) ou, em ambientes simples, uma verificação activa que testa o próximo salto e muda a rota. A redundância real exige também caminhos independentes: duas ligações do mesmo operador pela mesma vala podem falhar juntas. O plano de contingência (NIST SP 800-34) regista o que fazer e quem avisar quando a reserva entra.

Caso fictício

A DPE (fictícia) contratou uma ligação principal de 99,5 % mensais e uma reserva de outro operador (ligação 10.255.4.0/30: r1 = 10.255.4.1, r2 = 10.255.4.2). Numa segunda-feira a delegação ficou 2 horas sem sistema, apesar da reserva: o equipamento do operador principal continuava ligado, mas não encaminhava tráfego.

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).
• Novo: ligação de reserva r1-r2b / r2b-r1 com 10.255.4.1/30 (r1) e 10.255.4.2/30 (r2).
• Falha silenciosa simulada com tc netem loss 100% em r2-r1: a interface fica UP, mas nada passa.

Passos

1. Pré-verificação: as interfaces novas não existem.

   sudo ip -n r1 link show r1-r2b 2>/dev/null && echo 'r1-r2b JA EXISTE: parar'
   sudo ip -n r2 link show r2b-r1 2>/dev/null && echo 'r2b-r1 JA EXISTE: parar'
   echo verificado

   Saída de exemplo (didáctica):

   verificado

2. Crie a ligação de reserva e as rotas de reserva com métrica maior.

   sudo ip link add r1-r2b type veth peer name r2b-r1; sudo ip link set r1-r2b netns r1; sudo ip link set r2b-r1 netns r2
   sudo ip -n r1 addr add 10.255.4.1/30 dev r1-r2b; sudo ip -n r2 addr add 10.255.4.2/30 dev r2b-r1
   sudo ip -n r1 link set r1-r2b up; sudo ip -n r2 link set r2b-r1 up
   sudo ip -n r1 route add 10.20.10.0/24 via 10.255.4.2 metric 200
   sudo ip -n r2 route add 10.10.0.0/16 via 10.255.4.1 metric 200
   sudo ip -n r1 route show 10.20.10.0/24

   Saída de exemplo (didáctica):

   10.20.10.0/24 via 10.255.0.2 dev r1-r2
   10.20.10.0/24 via 10.255.4.2 dev r1-r2b metric 200

3. Provoque a falha silenciosa na principal e observe que a rota não muda.

   sudo ip netns exec r2 tc qdisc add dev r2-r1 root netem loss 100%
   sudo ip -n r2 link show r2-r1 | grep -o 'state [A-Z]*'
   sudo ip netns exec pc-del ping -c 3 -W 1 10.10.20.53
   sudo ip -n r2 route get 10.10.20.53

   Saída de exemplo (didáctica):

   state UP
   3 packets transmitted, 0 received, 100% packet loss
   10.10.20.53 via 10.255.0.1 dev r2-r1 ...

4. Crie o script de verificação activa (didáctico: corre na máquina de prática e muda as rotas das duas pontas). Guarde-o como /tmp/m9-verificar.sh.

   sudo tee /tmp/m9-verificar.sh <<'EOF'
   #!/bin/sh
   # Testa o próximo salto da ligação principal a partir de r2; se falhar 3 vezes, usa a reserva.
   if ip netns exec r2 ping -c 3 -W 1 -q 10.255.0.1 >/dev/null; then
     ip -n r1 route replace 10.20.10.0/24 via 10.255.0.2 metric 0
     ip -n r2 route replace 10.10.0.0/16 via 10.255.0.1 metric 0
     echo "$(date -Is) principal OK"
   else
     ip -n r1 route del 10.20.10.0/24 via 10.255.0.2 2>/dev/null
     ip -n r2 route del 10.10.0.0/16 via 10.255.0.1 2>/dev/null
     echo "$(date -Is) principal FALHOU: reserva em uso"
   fi
   EOF
   sudo sh /tmp/m9-verificar.sh
   sudo ip netns exec pc-del ping -c 3 10.10.20.53

   Saída de exemplo (didáctica):

   2026-09-28T10:15:03+02:00 principal FALHOU: reserva em uso
   3 packets transmitted, 3 received, 0% packet loss

5. Reponha a principal e confirme o regresso.

   sudo ip netns exec r2 tc qdisc del dev r2-r1 root
   sudo sh /tmp/m9-verificar.sh
   sudo ip -n r2 route get 10.10.20.53

   Saída de exemplo (didáctica):

   2026-09-28T10:17:40+02:00 principal OK
   10.10.20.53 via 10.255.0.1 dev r2-r1 ...

Critérios de sucesso

• A dupla mostra que, com a falha silenciosa, a interface fica UP e a rota principal não muda sozinha.
• Depois do script, o tráfego passa pela reserva; ao repor, volta à principal.
• A dupla calcula as horas admitidas pelo contrato e indica se as 2 horas do caso o violam num mês sem outras falhas.
• A dupla nomeia a solução de produção (BFD ou OSPF com temporizadores) e porque o script é só didáctico.

Como desfazer (reversão)

• sudo ip netns exec r2 tc qdisc del dev r2-r1 root 2>/dev/null
• sudo ip -n r1 route replace 10.20.10.0/24 via 10.255.0.2; sudo ip -n r2 route replace 10.10.0.0/16 via 10.255.0.1
• sudo ip -n r1 link del r1-r2b (apaga também r2b-r1 e as rotas de reserva)
• sudo rm -f /tmp/m9-verificar.sh
• Verificar: sudo ip -n r1 route show 10.20.10.0/24 mostra só a rota via 10.255.0.2.

Alternativa em papel: tarefas e respostas esperadas

Calcule o tempo admitido por mês (30 dias) para 99,5 %, 99,9 % e 99,99 %.

720 h × 0,005 = 3,6 h (3 h 36 min); 720 h × 0,001 = 0,72 h (43,2 min); 720 h × 0,0001 = 0,072 h (cerca de 4,3 min).

As 2 horas do caso violam o contrato de 99,5 % mensais, se não houve outras falhas?

Não: 2 h é menos do que as 3,6 h admitidas. Mesmo assim, é um incidente a registar, e a reserva devia ter entrado — é uma falha do desenho, não do contrato.

Com as saídas de exemplo do passo 3, explique porque a reserva não entrou.

A interface r2-r1 continua «state UP» e a rota principal continua a mais preferida (métrica 0); o sistema não sabe que o tráfego se perde mais à frente. É preciso verificação activa (BFD, OSPF ou teste do próximo salto).

Liste cinco pontos a exigir no contrato de ligação.

Disponibilidade e período de medição; se as manutenções contam; tempo máximo de reposição; forma e horário de abertura de avaria; compensação por incumprimento; relatório mensal do operador.

Verifique o que aprendeu

Questão 1

Porque a rota de reserva não entrou na falha do caso?

1. Porque a métrica da reserva era baixa
2. Porque a interface principal continuava UP e nada verificava se o tráfego passava
3. Porque o operador de reserva estava em baixo
4. Porque faltava NAT

Questão 2

Duas ligações do mesmo operador, pelo mesmo cabo até ao edifício, são redundância suficiente?

1. Sim, porque são duas
2. Não necessariamente: partilham pontos de falha (cabo, central, operador)
3. Sim, se tiverem VPN
4. Sim, se forem de fibra

Em leitura fácil

• 99,5 % por mês quer dizer até 3 horas e meia sem serviço.
• Meça a ligação você mesmo, para comparar com o operador.
• Às vezes o cabo parece ligado, mas nada passa.
• Por isso a reserva precisa de testar se o caminho funciona.

Fontes

• IETF RFC 5880 — Bidirectional Forwarding Detection (https://www.rfc-editor.org/rfc/rfc5880)
• FRRouting — documentação oficial (zebra, staticd, ospfd, vrrpd, vtysh) (https://docs.frrouting.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)
• NIST SP 800-34 Rev. 1 — Contingency Planning Guide (https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final)

Duração: 80 minutos (explicação 20, prática guiada 50, verificação 10). Resultados dos TdR trabalhados: Diagnóstico, desempenho e disponibilidade.

Objectivos

• Aplicar um método por etapas ao diagnóstico de uma ligação de longa distância (ligação local, próximo salto, caminho, serviço).
• Localizar perda num salto com mtr e distinguir perda real de limitação de respostas ICMP num encaminhador.
• Diagnosticar um problema de MTU (pedidos pequenos passam, transferências grandes param) e corrigi-lo com ajuste do MSS.

Método em quatro etapas

1) Ligação local: a interface está activa e tem endereço? 2) Próximo salto: o encaminhador do outro lado responde? 3) Caminho: onde se perde o tráfego (traceroute, mtr)? 4) Serviço: o protocolo concreto funciona (DNS, web, tamanho dos pacotes)? Registam-se hora, comando e resultado de cada etapa: é esse registo que se envia ao operador ao abrir avaria.

No mtr, perda que aparece num salto intermédio mas não nos seguintes significa normalmente que esse encaminhador limita as respostas ICMP, não que o tráfego se perde. Perda real aparece no salto onde começa e mantém-se até ao destino.

MTU: quando o ping funciona e a aplicação não

A MTU é o maior pacote que uma ligação transporta sem fragmentar (1500 bytes em Ethernet). Túneis e algumas ligações WAN reduzem-na (por exemplo WireGuard acrescenta cabeçalhos). Com a descoberta da MTU do caminho (RFC 1191), o emissor envia pacotes com «não fragmentar» e espera uma mensagem ICMP «fragmentation needed» se forem grandes demais. Se uma firewall no caminho bloquear essas mensagens ICMP, os pacotes grandes perdem-se sem aviso: o ping pequeno e o início da ligação passam, mas a página ou o ficheiro não chega.

Correcções: não bloquear as mensagens ICMP necessárias; e, no encaminhador da ligação reduzida, ajustar o MSS do TCP à MTU do caminho, para que as ligações TCP usem segmentos que cabem.

Caso fictício

Na DPE (fictícia) os utilizadores da delegação conseguem abrir a página inicial pequena do srv, mas o descarregamento de um relatório de 200 kB fica parado. O ping funciona. A ligação principal foi migrada para um operador cuja ligação tem MTU 1400, e um técnico bloqueou todo o ICMP no r1 «por segurança».

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).
• Simulação: MTU 1400 na ligação r1–r2 (interfaces r1-r2 e r2-r1) e bloqueio de ICMP «fragmentation needed» numa tabela nft própria no r1 (m9mtu).

Passos

1. Prepare o cenário do caso (formador) e um ficheiro de 200 kB no srv.

   sudo ip -n r1 link set r1-r2 mtu 1400; sudo ip -n r2 link set r2-r1 mtu 1400
   sudo ip netns exec r1 nft add table inet m9mtu
   sudo ip netns exec r1 nft add chain inet m9mtu saida '{ type filter hook output priority 0; policy accept; }'
   sudo ip netns exec r1 nft add rule inet m9mtu saida icmp type destination-unreachable icmp code frag-needed counter drop
   mkdir -p /tmp/m9-web && head -c 200000 /dev/zero > /tmp/m9-web/relatorio.bin
   Consola C: sudo ip netns exec srv python3 -m http.server 80 --bind 10.10.20.53 --directory /tmp/m9-web

2. Etapas 1 e 2: interface e próximo salto a partir da delegação.

   sudo ip -n pc-del addr show pc-del-r2 | grep inet
   sudo ip netns exec pc-del ping -c 2 10.20.10.1
   sudo ip netns exec r2 ping -c 2 10.255.0.1

   Saída de exemplo (didáctica):

   inet 10.20.10.10/24 ...
   2 packets transmitted, 2 received
   2 packets transmitted, 2 received

3. Etapa 3: caminho com mtr (10 ciclos, relatório).

   sudo ip netns exec pc-del mtr -n -r -c 10 10.10.20.53

   Saída de exemplo (didáctica):

   HOST                Loss%  Snt  Avg
   1. 10.20.10.1         0.0%   10  0.1
   2. 10.255.0.1         0.0%   10  0.1
   3. 10.10.20.53        0.0%   10  0.1

4. Etapa 4: serviço. O ficheiro grande pára; teste o tamanho com «não fragmentar».

   sudo ip netns exec pc-del python3 -c "import urllib.request as u; print(len(u.urlopen('http://10.10.20.53/relatorio.bin', timeout=5).read()))"
   sudo ip netns exec srv ping -c 1 -W 1 -M do -s 1372 10.20.10.10
   sudo ip netns exec srv ping -c 1 -W 1 -M do -s 1472 10.20.10.10
   sudo ip netns exec r1 nft list chain inet m9mtu saida

   Saída de exemplo (didáctica):

   TimeoutError: timed out
   1 packets transmitted, 1 received  (1372 + 28 = 1400 bytes)
   1 packets transmitted, 0 received  (1500 bytes não passam e o aviso ICMP é descartado)
   ... counter packets 3 bytes ... drop

5. Correcção 1: deixe passar as mensagens ICMP necessárias (retire a regra errada).

   sudo ip netns exec r1 nft delete table inet m9mtu
   sudo ip netns exec srv ping -c 1 -W 1 -M do -s 1472 10.20.10.10

   Saída de exemplo (didáctica):

   ping: local error: message too long, mtu=1400  (o emissor passa a saber a MTU do caminho)

6. Correcção 2 (complementar): ajuste do MSS no r1 para as ligações TCP que atravessam a ligação reduzida; depois repita o descarregamento.

   sudo ip netns exec r1 nft add table inet m9mss
   sudo ip netns exec r1 nft add chain inet m9mss fwd '{ type filter hook forward priority 0; policy accept; }'
   sudo ip netns exec r1 nft add rule inet m9mss fwd oifname r1-r2 tcp flags syn tcp option maxseg size set rt mtu
   sudo ip netns exec pc-del python3 -c "import urllib.request as u; print(len(u.urlopen('http://10.10.20.53/relatorio.bin', timeout=5).read()))"

   Saída de exemplo (didáctica):

   200000

Critérios de sucesso

• A folha de diagnóstico tem as quatro etapas com hora, comando e resultado.
• A dupla explica porque o ping de 1372 bytes passa e o de 1472 não.
• Depois das correcções, o ficheiro de 200000 bytes chega completo.
• A dupla escreve a mensagem de abertura de avaria ao operador com os dados recolhidos.

Como desfazer (reversão)

• Ctrl+C na consola C.
• sudo ip netns exec r1 nft delete table inet m9mss; sudo ip netns exec r1 nft delete table inet m9mtu 2>/dev/null
• sudo ip -n r1 link set r1-r2 mtu 1500; sudo ip -n r2 link set r2-r1 mtu 1500
• rm -rf /tmp/m9-web
• Verificar: sudo ip netns exec r1 nft list tables não mostra m9mtu nem m9mss; ip -n r1 link show r1-r2 mostra mtu 1500.

Alternativa em papel: tarefas e respostas esperadas

Relatório mtr de exemplo: salto 2 (10.255.0.1) com 40 % de perda; salto 3 (destino) com 0 %. Há perda real?

Não no caminho: o destino recebe tudo. O salto 2 limita respostas ICMP dirigidas a ele. Perda real apareceria também nos saltos seguintes e no destino.

Outro relatório: salto 2 com 12 % e salto 3 com 12 %. Onde começa o problema e o que envia ao operador?

Começa entre o salto 1 e o salto 2 (a ligação WAN). Envia: hora, origem e destino, relatório mtr com 12 % a partir do salto 2, confirmação de que a rede local está sem perda, número de contrato.

Com as saídas do passo 4, explique o caso em três frases.

A ligação tem MTU 1400. Pacotes de 1500 bytes com «não fragmentar» não passam e o r1 descarta o aviso ICMP que diria ao emissor para reduzir. Pedidos pequenos passam; o ficheiro grande pára.

Porque bloquear todo o ICMP «por segurança» é mau desenho?

Algumas mensagens ICMP são necessárias ao funcionamento (descoberta da MTU, destino inalcançável). Filtra-se de forma selectiva, não por completo.

Verifique o que aprendeu

Questão 1

Num relatório mtr, só o salto intermédio mostra perda e o destino tem 0 %. O que significa normalmente?

1. O cabo está partido nesse salto
2. Esse encaminhador limita as respostas ICMP; o tráfego passa
3. O destino está em baixo
4. O DNS falhou

Questão 2

O ping funciona, a página pequena abre, mas ficheiros grandes param. Primeira hipótese?

1. Vírus no servidor
2. Problema de MTU com mensagens ICMP bloqueadas no caminho
3. Falta de licença
4. Endereço IP duplicado

Em leitura fácil

• Diagnostique por etapas: cabo, vizinho, caminho, serviço.
• Anote a hora e o resultado de cada teste.
• Se o ping funciona e os ficheiros grandes não, suspeite do tamanho dos pacotes.
• Não bloqueie todo o ICMP.

Fontes

• IETF RFC 792 — Internet Control Message Protocol (https://www.rfc-editor.org/rfc/rfc792)
• IETF RFC 791 — Internet Protocol (https://www.rfc-editor.org/rfc/rfc791)
• 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)
• Projecto nftables — wiki oficial (https://wiki.nftables.org/)
• Wireshark — User's Guide e referência de filtros de visualização (https://www.wireshark.org/docs/)

Duração: 70 minutos (explicação 20, prática guiada 40, verificação 10). Resultados dos TdR trabalhados: Diagnóstico, desempenho e disponibilidade; Monitorização, análise de tráfego e gestão.

Objectivos

• Distinguir débito (throughput), débito útil (goodput), atraso de ida e volta (RTT), atraso unilateral, variação do atraso (jitter) e perda, e dizer o que cada ferramenta mede de facto.
• Medir RTT com ping, caminho e perda por salto com mtr, e débito TCP e UDP com iperf3, na rede de prática.
• Registar medições com hora, origem, destino, ferramenta, parâmetros e número de repetições, sem extrapolar para além do que foi medido.

O que se mede e com que palavras

Débito (throughput) é a quantidade de bits que atravessa um ponto por segundo, contando cabeçalhos. Débito útil (goodput) é só a parte que chega à aplicação: sem cabeçalhos Ethernet, IP e TCP e sem retransmissões. Numa ligação Ethernet com pacotes TCP de 1500 bytes, os cabeçalhos ocupam cerca de 5 % a 6 %; por isso uma ligação de 10 Mbit/s nunca entrega 10 Mbit/s de ficheiro. O RFC 6349 descreve como testar débito TCP de forma comparável.

Atraso de ida e volta (RTT, RFC 2681) é o tempo entre enviar um pacote e receber a resposta; é o que o ping mostra. Atraso unilateral (RFC 7679) é o tempo só num sentido e exige relógios sincronizados nas duas pontas, com erro conhecido; dividir o RTT por dois só é aproximação se os dois sentidos forem iguais, o que numa WAN nem sempre acontece. Variação do atraso (jitter, RFC 3393 para a métrica IPPM; o RTP usa a estimativa do RFC 3550) mede o quanto o atraso muda de pacote para pacote. Perda (RFC 7680) é a percentagem de pacotes enviados que não chegam.

O que cada ferramenta mostra — e o que não mostra

ping envia ICMP Echo e mostra RTT e perda de ICMP. Encaminhadores podem tratar ICMP com prioridade baixa ou limitá-lo; uma perda de ping num salto intermédio não prova perda para o tráfego real. mtr combina traceroute e ping salto a salto; lê-se sempre a partir do destino (módulo 9, lição 5). iperf3 cria tráfego de teste entre um cliente e um servidor iperf3: em TCP mostra o débito de dados da aplicação (próximo do goodput) e as retransmissões; em UDP envia ao ritmo pedido (-b) e o servidor relata jitter e perda.

Uma medição só vale nas condições em que foi feita: hora, caminho, tamanho dos pacotes, duração, número de fluxos e carga da rede. Um teste de 10 segundos às 10h00 não descreve a ligação às 15h00. Repete-se várias vezes e regista-se mínimo, mediana e máximo. Um teste de débito também ocupa a ligação: numa rede de produção só se faz com autorização e fora do horário de serviço.

Caso fictício

A delegação distrital da Direcção Provincial de Exemplo (DPE, fictícia) queixa-se de que «a rede está lenta». O chefe pede números antes de contactar o operador. A equipa vai medir, na rede de prática que reproduz a sede e a delegação, RTT, perda por salto e débito, e aprender a escrever um registo de medição que outra pessoa consiga repetir. Todos os valores são fictícios.

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).
• A ligação r1–r2 (10.255.0.0/30) representa a WAN sede–delegação.
• Nesta lição a WAN é limitada a 10 Mbit/s e 40 ms num sentido com tc netem em r2-r1, só dentro do espaço de nomes r2. Nota: o netem com «rate» limita o débito ao nível do pacote IP e mais cabeçalho Ethernet; não imita todas as propriedades de uma ligação real.

Passos

1. Pré-verificação (não altera nada): confirme ferramentas, que a rede DPE existe, que a delegação chega ao srv e que as interfaces WAN só têm a fila por omissão. Se alguma interface já tiver outra fila, pare: pode pertencer a outra lição não revertida — reverta-a primeiro.

   for d in iperf3 mtr curl tc nft tshark; do command -v $d >/dev/null || echo "Em falta: $d"; done
   ip netns list | grep -E '^(r1|r2|srv|pc-del)( |$)'
   sudo ip netns exec pc-del ping -c 3 10.10.20.53
   sudo ip netns exec r1 tc qdisc show dev r1-r2; sudo ip netns exec r2 tc qdisc show dev r2-r1
   sudo ip netns exec r2 nft list tables | grep qos_lab || echo 'sem tabelas qos_lab'

   Saída de exemplo (didáctica):

   (nenhuma linha «Em falta»)
   r1 (id: 2) … r2 (id: 3) … srv (id: 1) … pc-del (id: 4)
   3 packets transmitted, 3 received, 0% packet loss
   qdisc noqueue 0: root refcnt 2
   qdisc noqueue 0: root refcnt 2
   sem tabelas qos_lab

2. Crie a pasta própria da lição para guardar resultados (só esta pasta é apagada na reversão).

   mkdir -p /tmp/dpe-m10/l1

3. Simule a WAN: 40 ms e 10 Mbit/s na saída de r2 para r1 (sentido delegação → sede).

   sudo ip netns exec r2 tc qdisc add dev r2-r1 root netem delay 40ms rate 10mbit
   sudo ip netns exec r2 tc qdisc show dev r2-r1

   Saída de exemplo (didáctica):

   qdisc netem 8001: root refcnt 2 limit 1000 delay 40ms rate 10Mbit

4. RTT: 20 pings, um a cada 0,2 s. Guarde a saída. Observe que o atraso foi posto só num sentido, mas o ping mede ida e volta.

   sudo ip netns exec pc-del ping -c 20 -i 0.2 10.10.20.53 | tee /tmp/dpe-m10/l1/ping.txt | tail -2

   Saída de exemplo (didáctica):

   20 packets transmitted, 20 received, 0% packet loss, time 3805ms
   rtt min/avg/max/mdev = 40.1/40.3/40.9/0.2 ms

5. Caminho salto a salto com mtr (20 ciclos, relatório).

   sudo ip netns exec pc-del mtr -n -r -c 20 10.10.20.53 | tee /tmp/dpe-m10/l1/mtr.txt

   Saída de exemplo (didáctica):

   HOST                Loss%  Snt   Avg  Best  Wrst
   1. 10.20.10.1         0.0%   20   0.1   0.0   0.2
   2. 10.255.0.1         0.0%   20  40.2  40.1  40.6
   3. 10.10.20.53        0.0%   20  40.3  40.1  40.8

6. Consola C: inicie o servidor iperf3 no srv. A opção -1 faz o servidor terminar sozinho depois de um teste (esperar «Server listening on 5201»).

   sudo ip netns exec srv iperf3 -s -1 -B 10.10.20.53

   Saída de exemplo (didáctica):

   Server listening on 5201

7. Débito TCP delegação → sede durante 10 s. Anote o débito do receptor e as retransmissões (Retr).

   sudo ip netns exec pc-del iperf3 -c 10.10.20.53 -t 10 | tee /tmp/dpe-m10/l1/tcp.txt | tail -4

   Saída de exemplo (didáctica):

   [ ID] Interval       Transfer     Bitrate         Retr
   [  5] 0.00-10.00 sec  11.2 MBytes  9.40 Mbits/sec    0   sender
   [  5] 0.00-10.04 sec  11.1 MBytes  9.28 Mbits/sec        receiver
   (9,3 Mbit/s de dados da aplicação numa ligação limitada a 10 Mbit/s: a diferença são cabeçalhos)

8. Consola C: volte a iniciar o servidor (terminou após o teste). Débito UDP a 2 Mbit/s: o servidor relata jitter e perda.

   sudo ip netns exec srv iperf3 -s -1 -B 10.10.20.53
   sudo ip netns exec pc-del iperf3 -c 10.10.20.53 -u -b 2M -t 10 | tee /tmp/dpe-m10/l1/udp.txt | tail -3

   Saída de exemplo (didáctica):

   [ ID] Interval       Transfer     Bitrate         Jitter    Lost/Total Datagrams
   [  5] 0.00-10.04 sec  2.38 MBytes  1.99 Mbits/sec  0.041 ms  0/1726 (0%)  receiver

9. Acrescente 1 % de perda à simulação e repita só o TCP (servidor iniciado de novo na consola C). Compare o débito.

   sudo ip netns exec r2 tc qdisc change dev r2-r1 root netem delay 40ms rate 10mbit loss 1%
   sudo ip netns exec srv iperf3 -s -1 -B 10.10.20.53
   sudo ip netns exec pc-del iperf3 -c 10.10.20.53 -t 10 | tee /tmp/dpe-m10/l1/tcp-perda.txt | tail -3

   Saída de exemplo (didáctica):

   [  5] 0.00-10.00 sec  4.10 MBytes  3.44 Mbits/sec   93   sender
   [  5] 0.00-10.04 sec  3.98 MBytes  3.33 Mbits/sec        receiver
   (o valor exacto varia em cada execução e com o algoritmo de congestionamento do núcleo)

10. Escreva o registo de medição em /tmp/dpe-m10/l1/registo.txt: data e hora, origem, destino, ferramenta e parâmetros, duração, repetições, resultado, condições (simulação netem indicada).

    nano /tmp/dpe-m10/l1/registo.txt

Critérios de sucesso

• A dupla apresenta RTT (mín./média/máx.), perda por salto, débito TCP do receptor, jitter e perda UDP, cada um com a ferramenta e os parâmetros usados.
• O formando explica porque o iperf3 mostra menos de 10 Mbit/s numa ligação de 10 Mbit/s sem perda.
• O formando explica porque 1 % de perda reduz muito o débito TCP e porque o ping não mostra isso por si só.
• O registo permite a outra dupla repetir o teste nas mesmas condições.

Como desfazer (reversão)

• sudo ip netns exec r2 tc qdisc del dev r2-r1 root
• Se o servidor iperf3 ainda estiver à espera na consola C: Ctrl+C nessa consola (não usar pkill/killall).
• Guardar o registo fora da VM, se necessário, e depois: rm -r /tmp/dpe-m10/l1
• Verificar: sudo ip netns exec r2 tc qdisc show dev r2-r1 deve mostrar só «qdisc noqueue»; sudo ip netns pids srv não deve listar nenhum iperf3.

Alternativa em papel: tarefas e respostas esperadas

Com as saídas de exemplo, preencha: medida | ferramenta | valor. (RTT médio, perda até ao destino, débito TCP receptor sem perda, débito TCP receptor com 1 % de perda, jitter UDP).

RTT médio | ping | 40,3 ms. Perda até ao destino | mtr | 0 %. TCP sem perda | iperf3 | 9,28 Mbit/s. TCP com 1 % de perda | iperf3 | 3,33 Mbit/s. Jitter UDP | iperf3 -u | 0,041 ms.

Uma ligação de 10 Mbit/s transfere ficheiros a 9,3 Mbit/s. O operador está a falhar o contrato?

Não necessariamente. O iperf3 mostra débito útil da aplicação; os cabeçalhos Ethernet, IP e TCP ocupam cerca de 5–6 % em pacotes de 1500 bytes. Só se compara com o contrato depois de saber como o operador define a velocidade (normalmente ao nível da ligação) e medindo várias vezes.

O ping mostra RTT de 80 ms. Um colega escreve no relatório «atraso unilateral = 40 ms». Está correcto?

Só como aproximação e se os dois sentidos forem simétricos. O atraso unilateral mede-se com relógios sincronizados nas duas pontas (RFC 7679). No relatório deve escrever «RTT = 80 ms (ping)».

Escreva um registo de medição completo para o teste TCP sem perda.

Exemplo: 2026-09-28 10:15; origem pc-del 10.20.10.10; destino srv 10.10.20.53; iperf3 3.x TCP, 1 fluxo, 10 s, sentido delegação→sede; 1 repetição (deviam ser pelo menos 3); resultado receptor 9,28 Mbit/s, 0 retransmissões; condições: rede de prática com netem 40 ms e 10 Mbit/s em r2-r1.

Verifique o que aprendeu

Questão 1

O que mostra o valor «Bitrate» do receptor num teste TCP do iperf3?

1. O débito total da ligação, incluindo todos os cabeçalhos
2. O débito de dados da aplicação que chegou, próximo do débito útil (goodput)
3. O atraso unilateral
4. A largura de banda contratada ao operador

Questão 2

O ping mostra 0 % de perda, mas o iperf3 TCP cai de 9 para 3 Mbit/s. Qual é a explicação mais provável na simulação?

1. O ping está avariado
2. Com 1 % de perda, 20 pings podem não perder nenhum, mas o TCP reduz a janela a cada perda e o débito cai
3. O servidor iperf3 é lento
4. A VLAN está errada

Em leitura fácil

• Medir a rede é ver números, não opiniões.
• O ping mede quanto tempo um pacote vai e volta.
• O iperf3 mede quantos dados passam por segundo.
• Os dados úteis são sempre um pouco menos do que a velocidade da ligação.
• Uma perda pequena de pacotes pode deixar tudo muito lento.
• Escreva sempre quando, onde e como mediu.

Fontes

• IETF RFC 2681 — A Round-trip Delay Metric for IPPM (https://www.rfc-editor.org/rfc/rfc2681)
• IETF RFC 7679 — A One-Way Delay Metric for IP Performance Metrics (IPPM) (https://www.rfc-editor.org/rfc/rfc7679)
• IETF RFC 3393 — IP Packet Delay Variation Metric for IPPM (https://www.rfc-editor.org/rfc/rfc3393)
• IETF RFC 7680 — A One-Way Loss Metric for IP Performance Metrics (IPPM) (https://www.rfc-editor.org/rfc/rfc7680)
• IETF RFC 6349 — Framework for TCP Throughput Testing (https://www.rfc-editor.org/rfc/rfc6349)
• IETF RFC 3550 — RTP: A Transport Protocol for Real-Time Applications (https://www.rfc-editor.org/rfc/rfc3550)
• iperf3 — documentação (ESnet) (https://software.es.net/iperf/)
• mtr — página oficial e manual mtr(8) (https://www.bitwizard.nl/mtr/)
• Linux tc — páginas de manual tc-netem(8), tc-htb(8), tc-tbf(8), tc-fq_codel(8), tc-u32(8) (https://man7.org/linux/man-pages/man8/tc-netem.8.html)
• 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)

Duração: 75 minutos (explicação 20, prática guiada 45, verificação 10). Resultados dos TdR trabalhados: Diagnóstico, desempenho e disponibilidade.

Objectivos

• Explicar o modelo de serviços diferenciados (DiffServ): classificação, marcação DSCP, comportamento por salto e fronteira de confiança.
• Marcar tráfego de voz com DSCP EF num encaminhador com nftables e dar-lhe prioridade numa fila htb com tc, só na ligação congestionada.
• Justificar porque a marcação não cria largura de banda, só actua quando há congestionamento e não é um mecanismo de segurança.

DiffServ: marcar e tratar

No cabeçalho IP há um campo de 6 bits chamado DSCP (RFC 2474). O valor não faz nada sozinho: cada equipamento que o lê aplica um comportamento por salto (PHB) configurado pelo administrador (arquitectura no RFC 2475). O RFC 4594 sugere classes: EF (46, RFC 3246) para voz, AF41 (34) para videoconferência, CS0/predefinido (0) para o resto, e classes de menor prioridade para cópias de segurança.

Três passos: classificar (reconhecer o tráfego, por exemplo porto UDP ou endereço do servidor de voz), marcar (escrever o DSCP) e tratar (colocar cada marca numa fila com regras próprias na interface de saída). Se um equipamento do caminho ignorar ou apagar a marca, o tratamento pára aí. Na Internet pública os operadores normalmente não respeitam marcas de clientes; numa WAN de operador, só vale o que estiver no contrato.

O que a prioridade não faz

A prioridade só muda a ordem de saída quando há fila, isto é, quando chega mais tráfego do que a ligação consegue enviar. Sem congestionamento, todas as filas estão vazias e a marcação não tem efeito visível. A prioridade também não aumenta a capacidade: numa ligação de 2 Mbit/s, dar prioridade à voz tira tempo às outras aplicações. Se a voz marcada exceder a capacidade reservada, também sofre.

A marcação não é segurança. Qualquer computador pode escrever EF nos seus pacotes; se a rede confiar cegamente, um programa de descarregamentos marcado EF passa à frente da voz. Por isso define-se uma fronteira de confiança: no primeiro equipamento controlado pela equipa, apagam-se as marcas recebidas dos postos e volta-se a marcar segundo a política. O DSCP também não cifra nem autentica nada.

Caso fictício

Na delegação da DPE (fictícia), as chamadas de voz para a sede cortam quando alguém envia relatórios grandes. A WAN simulada tem 2 Mbit/s. A política aprovada pelo chefe diz: a voz (fictícia, UDP porto 5202) recebe EF e até 500 kbit/s garantidos; o resto partilha o que sobra; marcas vindas dos postos não são aceites. Todos os valores são fictícios.

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).
• A ligação r1–r2 representa a WAN; na saída r2-r1 (delegação → sede) cria-se congestionamento com htb a 2 Mbit/s.
• Voz simulada: iperf3 UDP a 300 kbit/s para o porto 5202 do srv. Tráfego pesado: iperf3 TCP para o porto 5201.
• Marcação em r2 com a tabela nftables «qos_lab» (nome reservado desta lição).

Passos

1. Pré-verificação (não altera nada): confirme ferramentas, que a rede DPE existe, que a delegação chega ao srv e que as interfaces WAN só têm a fila por omissão. Se alguma interface já tiver outra fila, pare: pode pertencer a outra lição não revertida — reverta-a primeiro.

   for d in iperf3 mtr curl tc nft tshark; do command -v $d >/dev/null || echo "Em falta: $d"; done
   ip netns list | grep -E '^(r1|r2|srv|pc-del)( |$)'
   sudo ip netns exec pc-del ping -c 3 10.10.20.53
   sudo ip netns exec r1 tc qdisc show dev r1-r2; sudo ip netns exec r2 tc qdisc show dev r2-r1
   sudo ip netns exec r2 nft list tables | grep qos_lab || echo 'sem tabelas qos_lab'

   Saída de exemplo (didáctica):

   (nenhuma linha «Em falta»)
   r1 (id: 2) … r2 (id: 3) … srv (id: 1) … pc-del (id: 4)
   3 packets transmitted, 3 received, 0% packet loss
   qdisc noqueue 0: root refcnt 2
   qdisc noqueue 0: root refcnt 2
   sem tabelas qos_lab

2. Crie a ligação congestionável: htb a 2 Mbit/s com duas classes (1:10 voz, garantia 500 kbit/s; 1:20 restante, 1500 kbit/s), ambas podendo usar até 2 Mbit/s. Por omissão tudo vai para 1:20. Ainda não há filtro: a voz vai para 1:20.

   sudo ip netns exec r2 tc qdisc add dev r2-r1 root handle 1: htb default 20
   sudo ip netns exec r2 tc class add dev r2-r1 parent 1: classid 1:1 htb rate 2mbit
   sudo ip netns exec r2 tc class add dev r2-r1 parent 1:1 classid 1:10 htb rate 500kbit ceil 2mbit prio 0
   sudo ip netns exec r2 tc class add dev r2-r1 parent 1:1 classid 1:20 htb rate 1500kbit ceil 2mbit prio 1
   sudo ip netns exec r2 tc class show dev r2-r1

   Saída de exemplo (didáctica):

   class htb 1:1 root rate 2Mbit ceil 2Mbit …
   class htb 1:10 parent 1:1 prio 0 rate 500Kbit ceil 2Mbit …
   class htb 1:20 parent 1:1 prio 1 rate 1500Kbit ceil 2Mbit …

3. Consolas C e D: dois servidores iperf3 no srv, um por porto (esperar «Server listening» em cada).

   C: sudo ip netns exec srv iperf3 -s -1 -B 10.10.20.53 -p 5201
   D: sudo ip netns exec srv iperf3 -s -1 -B 10.10.20.53 -p 5202

4. Medição sem prioridade. Consola B: tráfego pesado TCP durante 30 s. Logo a seguir, na consola A: voz simulada durante 20 s. Anote jitter e perda da voz.

   B: sudo ip netns exec pc-del iperf3 -c 10.10.20.53 -p 5201 -t 30
   A: sudo ip netns exec pc-del iperf3 -c 10.10.20.53 -p 5202 -u -b 300k -l 200 -t 20 | tail -2

   Saída de exemplo (didáctica):

   [  5] 0.00-20.00 sec  …  297 Kbits/sec  21.7 ms  412/3750 (11%)  receiver
   (jitter e perda altos: a voz espera na mesma fila que o TCP; os números variam em cada execução)

5. Acrescente o filtro que envia DSCP EF (46; byte TOS 0xb8) para a classe 1:10. Sem marcação ainda, nada muda — confirme repetindo o passo anterior se houver tempo.

   sudo ip netns exec r2 tc filter add dev r2-r1 parent 1: protocol ip prio 1 u32 match ip dsfield 0xb8 0xfc flowid 1:10

6. Fronteira de confiança e marcação em r2: primeiro apagar todas as marcas que chegam dos postos da delegação; depois marcar EF só a voz (UDP 5202). A ordem das regras importa.

   sudo ip netns exec r2 nft add table ip qos_lab
   sudo ip netns exec r2 nft add chain ip qos_lab marcar '{ type filter hook prerouting priority mangle; policy accept; }'
   sudo ip netns exec r2 nft add rule ip qos_lab marcar iifname "r2-pc-del" ip dscp set cs0
   sudo ip netns exec r2 nft add rule ip qos_lab marcar iifname "r2-pc-del" udp dport 5202 ip dscp set ef
   sudo ip netns exec r2 nft list table ip qos_lab

   Saída de exemplo (didáctica):

   table ip qos_lab {
     chain marcar {
       type filter hook prerouting priority mangle; policy accept;
       iifname "r2-pc-del" ip dscp set cs0
       iifname "r2-pc-del" udp dport 5202 ip dscp set ef
     }
   }

7. Consola E: confirme a marca depois de r2, capturando na entrada de r1 (esperar «Capturing on 'r1-r2'»). Reinicie os servidores nas consolas C e D e repita a medição do passo 3.

   E: sudo ip netns exec r1 tshark -i r1-r2 -c 5 -f 'udp port 5202' -T fields -e ip.dsfield.dscp
   (repetir consolas C, D, B e A do passo 3)

   Saída de exemplo (didáctica):

   46
   46
   46
   46
   46
   A: [  5] 0.00-20.00 sec  …  299 Kbits/sec  0.35 ms  0/3750 (0%)  receiver
   B: débito TCP cerca de 1,6 Mbit/s (a voz usa parte dos 2 Mbit/s)

8. Teste da fronteira de confiança: um posto tenta marcar o TCP pesado como EF (-S 0xb8). Capture na consola E durante o teste. A marca deve chegar a r1 como 0.

   E: sudo ip netns exec r1 tshark -i r1-r2 -c 5 -f 'tcp port 5201' -T fields -e ip.dsfield.dscp
   C: sudo ip netns exec srv iperf3 -s -1 -B 10.10.20.53 -p 5201
   B: sudo ip netns exec pc-del iperf3 -c 10.10.20.53 -p 5201 -t 5 -S 0xb8

   Saída de exemplo (didáctica):

   0
   0
   0
   0
   0

9. Veja os contadores por classe: a classe 1:10 tem os bytes da voz, a 1:20 os do TCP e as descartadas (dropped).

   sudo ip netns exec r2 tc -s class show dev r2-r1

   Saída de exemplo (didáctica):

   class htb 1:10 … Sent 752000 bytes 3760 pkt (dropped 0, overlimits 0 requeues 0)
   class htb 1:20 … Sent 9870000 bytes 6520 pkt (dropped 87, overlimits 0 requeues 0)

Critérios de sucesso

• A dupla mostra jitter e perda da voz antes e depois da prioridade, com os mesmos parâmetros.
• A captura mostra DSCP 46 na voz e 0 no TCP marcado pelo posto.
• O formando explica porque o débito TCP desceu quando a voz passou a ter prioridade e porque, sem o TCP a correr, não haveria diferença.
• O formando justifica a regra que apaga marcas dos postos com um exemplo de abuso.

Como desfazer (reversão)

• sudo ip netns exec r2 nft delete table ip qos_lab
• sudo ip netns exec r2 tc qdisc del dev r2-r1 root (remove também classes e filtros)
• Ctrl+C nas consolas C, D e E se algum processo ainda estiver à espera (não usar pkill/killall).
• Verificar: tc qdisc show dev r2-r1 mostra só «qdisc noqueue»; nft list tables em r2 não mostra qos_lab; ip netns pids srv não lista iperf3.

Alternativa em papel: tarefas e respostas esperadas

Com as saídas de exemplo, preencha: cenário | jitter da voz | perda da voz | débito TCP. (sem prioridade; com EF e classe 1:10).

Sem prioridade | 21,7 ms | 11 % | quase 2 Mbit/s menos a voz. Com EF | 0,35 ms | 0 % | cerca de 1,6 Mbit/s.

O chefe pergunta: «Se marcarmos tudo como EF, tudo fica rápido?» Responda.

Não. Se tudo for EF, tudo cai na mesma fila e ninguém tem prioridade; a capacidade continua 2 Mbit/s. A prioridade só serve para escolher quem espera menos quando há congestionamento.

Porque a regra «ip dscp set cs0» vem antes da regra que marca EF? O que aconteceria se estivessem ao contrário?

As regras são avaliadas por ordem e ambas alteram o pacote. Ao contrário, a voz seria marcada EF e logo a seguir apagada para CS0, perdendo a prioridade.

Um fornecedor diz que o DSCP EF «protege» as chamadas contra escutas. Comente.

Errado. O DSCP é um número no cabeçalho, visível e alterável; não cifra nem autentica. A confidencialidade exige cifra (por exemplo SRTP ou uma VPN).

Verifique o que aprendeu

Questão 1

Numa ligação sem congestionamento, o que muda ao marcar a voz com EF?

1. A voz passa a ter mais largura de banda
2. Praticamente nada: sem fila, todos os pacotes saem logo
3. A voz fica cifrada
4. O RTT reduz para metade

Questão 2

Porque se apagam as marcas DSCP que chegam dos postos de trabalho?

1. Porque o DSCP ocupa demasiados bytes
2. Porque qualquer posto pode marcar-se como EF e roubar prioridade à voz
3. Porque o nftables não lê DSCP
4. Porque a lei obriga

Em leitura fácil

• Pode dar prioridade a alguns pacotes, como a voz.
• O encaminhador põe uma marca no pacote.
• A prioridade só ajuda quando a ligação está cheia.
• A prioridade não aumenta a velocidade total.
• A marca não protege os dados: não é segurança.
• Não confie nas marcas que vêm dos computadores.

Fontes

• IETF RFC 2474 — Differentiated Services Field (https://www.rfc-editor.org/rfc/rfc2474)
• IETF RFC 2475 — An Architecture for Differentiated Services (https://www.rfc-editor.org/rfc/rfc2475)
• IETF RFC 4594 — Configuration Guidelines for DiffServ Service Classes (https://www.rfc-editor.org/rfc/rfc4594)
• IETF RFC 3246 — An Expedited Forwarding PHB (https://www.rfc-editor.org/rfc/rfc3246)
• Linux tc — páginas de manual tc-netem(8), tc-htb(8), tc-tbf(8), tc-fq_codel(8), tc-u32(8) (https://man7.org/linux/man-pages/man8/tc-netem.8.html)
• Projecto nftables — wiki oficial (https://wiki.nftables.org/)
• iperf3 — documentação (ESnet) (https://software.es.net/iperf/)
• Wireshark — User's Guide e referência de filtros de visualização (https://www.wireshark.org/docs/)

Duração: 75 minutos (explicação 20, prática guiada 45, verificação 10). Resultados dos TdR trabalhados: Diagnóstico, desempenho e disponibilidade; LAN, WAN, WLAN, virtualização e nuvem.

Objectivos

• Explicar porque voz e vídeo em tempo real são sensíveis a atraso unilateral, jitter e perda, e o papel do RTP e do tampão de jitter.
• Calcular o débito de uma chamada G.711 com 20 ms de pacote, ao nível IP e ao nível Ethernet, e o total para várias chamadas.
• Montar um orçamento de atraso unilateral e compará-lo com a referência da Recomendação ITU-T G.114, sabendo que é uma referência de planeamento e não uma garantia.
• Simular voz com iperf3 UDP e observar o efeito de jitter e perda, reconhecendo os limites da simulação.

Tempo real: porque não basta ter débito

Numa chamada, a voz é cortada em pedaços de poucos milissegundos, codificada e enviada em pacotes RTP sobre UDP (RFC 3550). Um pacote que chega tarde demais para ser tocado conta como perdido; não vale a pena retransmiti-lo. Por isso, voz e vídeo usam UDP e são muito mais sensíveis a atraso, jitter e perda do que uma transferência de ficheiros.

O receptor guarda alguns pacotes num tampão de jitter antes de tocar, para compensar chegadas irregulares. Um tampão maior tolera mais jitter, mas acrescenta atraso. A Recomendação ITU-T G.114 indica, para planeamento, que um atraso unilateral de boca a ouvido até cerca de 150 ms é aceitável para a maioria das conversas e que acima de 400 ms não deve ser usado em planeamento geral. É uma referência de planeamento; a qualidade percebida depende também do codec, da perda e do eco.

Contas de uma chamada

O codec G.711 (ITU-T) produz 64 kbit/s de voz. Com pacotes de 20 ms há 50 pacotes por segundo, cada um com 160 bytes de voz. Somam-se cabeçalhos RTP (12 bytes), UDP (8) e IPv4 (20): 200 bytes por pacote, ou seja 200 × 8 × 50 = 80 kbit/s ao nível IP, em cada sentido. Em Ethernet somam-se 18 bytes de cabeçalho e verificação: 218 × 8 × 50 = 87,2 kbit/s. Uma VPN ou IPv6 acrescentam mais cabeçalhos; compressão de cabeçalhos ou outros codecs reduzem. As contas servem para planear, e confirmam-se medindo.

O vídeo não tem débito fixo: depende do codec, da resolução, do movimento na imagem e da adaptação feita pela aplicação. Os números de planeamento tiram-se da documentação da plataforma usada e de medições, nunca de uma tabela genérica. O orçamento de atraso unilateral soma: codificação e empacotamento (por exemplo 20 ms), rede num sentido, tampão de jitter e descodificação.

Caso fictício

A DPE (fictícia) quer 8 chamadas de voz simultâneas entre a delegação e a sede e uma videoconferência semanal. A WAN simulada tem 40 ms num sentido. O técnico tem de dizer quanto débito reservar para a voz, se o atraso cabe no orçamento e o que acontece com jitter e perda. Todos os valores são fictícios.

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).
• A ligação r1–r2 representa a WAN; atraso, jitter e perda simulados com tc netem na saída r2-r1 (delegação → sede).
• Voz simulada: iperf3 UDP com datagramas de 172 bytes (160 de voz + 12 de RTP simulados) a 68,8 kbit/s de dados, o que dá 50 pacotes por segundo. Não é RTP verdadeiro: o iperf3 mede jitter e perda como o RTP, mas não há codec nem tampão.
• Limite da simulação: com jitter, o netem pode reordenar pacotes; numa ligação real a reordenação pode ser menor ou maior.

Passos

1. Pré-verificação (não altera nada): confirme ferramentas, que a rede DPE existe, que a delegação chega ao srv e que as interfaces WAN só têm a fila por omissão. Se alguma interface já tiver outra fila, pare: pode pertencer a outra lição não revertida — reverta-a primeiro.

   for d in iperf3 mtr curl tc nft tshark; do command -v $d >/dev/null || echo "Em falta: $d"; done
   ip netns list | grep -E '^(r1|r2|srv|pc-del)( |$)'
   sudo ip netns exec pc-del ping -c 3 10.10.20.53
   sudo ip netns exec r1 tc qdisc show dev r1-r2; sudo ip netns exec r2 tc qdisc show dev r2-r1
   sudo ip netns exec r2 nft list tables | grep qos_lab || echo 'sem tabelas qos_lab'

   Saída de exemplo (didáctica):

   (nenhuma linha «Em falta»)
   r1 (id: 2) … r2 (id: 3) … srv (id: 1) … pc-del (id: 4)
   3 packets transmitted, 3 received, 0% packet loss
   qdisc noqueue 0: root refcnt 2
   qdisc noqueue 0: root refcnt 2
   sem tabelas qos_lab

2. Cenário 1 — atraso fixo de 40 ms num sentido. Confirme com ping (a ida e volta fica perto de 40 ms, porque o regresso não tem atraso simulado).

   sudo ip netns exec r2 tc qdisc add dev r2-r1 root netem delay 40ms
   sudo ip netns exec pc-del ping -c 10 -i 0.2 10.10.20.53 | tail -1

   Saída de exemplo (didáctica):

   rtt min/avg/max/mdev = 40.1/40.2/40.4/0.1 ms

3. Consola C: servidor iperf3 (esperar «Server listening on 5201»). Consola A: voz simulada durante 20 s.

   C: sudo ip netns exec srv iperf3 -s -1 -B 10.10.20.53
   A: sudo ip netns exec pc-del iperf3 -c 10.10.20.53 -u -b 68.8K -l 172 -t 20 | tail -2

   Saída de exemplo (didáctica):

   [  5] 0.00-20.04 sec  168 KBytes  68.7 Kbits/sec  0.030 ms  0/1000 (0%)  receiver
   (1000 datagramas em 20 s = 50 por segundo)

4. Cenário 2 — acrescente jitter: 40 ms ± 15 ms. Repita o teste (reinicie o servidor na consola C).

   sudo ip netns exec r2 tc qdisc change dev r2-r1 root netem delay 40ms 15ms
   C: sudo ip netns exec srv iperf3 -s -1 -B 10.10.20.53
   A: sudo ip netns exec pc-del iperf3 -c 10.10.20.53 -u -b 68.8K -l 172 -t 20 | tail -2

   Saída de exemplo (didáctica):

   [  5] 0.00-20.05 sec  168 KBytes  68.6 Kbits/sec  9.84 ms  0/1000 (0%)  receiver
   (podem surgir avisos de pacotes fora de ordem: efeito do netem com jitter)

5. Cenário 3 — jitter e 2 % de perda. Repita o teste.

   sudo ip netns exec r2 tc qdisc change dev r2-r1 root netem delay 40ms 15ms loss 2%
   C: sudo ip netns exec srv iperf3 -s -1 -B 10.10.20.53
   A: sudo ip netns exec pc-del iperf3 -c 10.10.20.53 -u -b 68.8K -l 172 -t 20 | tail -2

   Saída de exemplo (didáctica):

   [  5] 0.00-20.05 sec  165 KBytes  67.3 Kbits/sec  10.1 ms  21/1000 (2.1%)  receiver

6. Confirme na captura o tamanho dos pacotes de voz simulada (consola E, esperar «Capturing on»; repetir o teste de 5 s). O comprimento IP deve ser 200 bytes (172 + 8 UDP + 20 IP).

   E: sudo ip netns exec r1 tshark -i r1-r2 -c 3 -f 'udp port 5201' -T fields -e ip.len -e frame.len
   C: sudo ip netns exec srv iperf3 -s -1 -B 10.10.20.53
   A: sudo ip netns exec pc-del iperf3 -c 10.10.20.53 -u -b 68.8K -l 172 -t 5

   Saída de exemplo (didáctica):

   200	214
   200	214
   200	214
   (frame.len = 214: a captura não inclui os 4 bytes de verificação Ethernet; somados dão os 218 usados nas contas)

7. Preencha o orçamento de atraso unilateral para os cenários 1 e 2 com: empacotamento 20 ms, rede (40 ms), tampão de jitter (cenário 1: 20 ms; cenário 2: 60 ms, cerca de 4 vezes o jitter simulado de ±15 ms), descodificação 5 ms (valor fictício de exemplo).

   nano /tmp/dpe-m10-l3-orcamento.txt

Critérios de sucesso

• A dupla tem uma tabela cenário | jitter | perda | orçamento de atraso unilateral, com a indicação de que são valores simulados.
• O formando calcula 87,2 kbit/s por chamada G.711/20 ms em Ethernet e o total para 8 chamadas (697,6 kbit/s por sentido).
• O formando explica porque um tampão de jitter maior evita cortes mas aumenta o atraso.
• O formando diz que o valor da G.114 é referência de planeamento, não promessa de qualidade.

Como desfazer (reversão)

• sudo ip netns exec r2 tc qdisc del dev r2-r1 root
• Ctrl+C nas consolas C e E se algum processo ainda estiver à espera (não usar pkill/killall).
• rm /tmp/dpe-m10-l3-orcamento.txt (depois de guardar a tabela, se necessário).
• Verificar: tc qdisc show dev r2-r1 mostra só «qdisc noqueue»; ip netns pids srv e ip netns pids r1 não listam iperf3 nem tshark.

Alternativa em papel: tarefas e respostas esperadas

Calcule o débito de uma chamada G.711 com pacotes de 20 ms: ao nível IP e em Ethernet. Depois, para 8 chamadas.

Por pacote: 160 + 12 + 8 + 20 = 200 bytes; 50 pacotes/s → 80 kbit/s ao nível IP. Ethernet: 218 bytes → 87,2 kbit/s. 8 chamadas: 640 kbit/s (IP) ou 697,6 kbit/s (Ethernet) em cada sentido, sem contar VPN.

Orçamento de atraso unilateral: cenário 1 (20 + 40 + 20 + 5) e cenário 2 (20 + 40 + 60 + 5). Cabem na referência de 150 ms da G.114?

Cenário 1: 85 ms. Cenário 2: 125 ms. Ambos abaixo de 150 ms, mas o cenário 2 tem menos margem. É referência de planeamento; a perda de 2 % do cenário 3 prejudica a qualidade mesmo com atraso aceitável.

Com as saídas de exemplo, preencha: cenário | jitter | perda.

1 (40 ms fixo): 0,030 ms | 0 %. 2 (±15 ms): 9,84 ms | 0 %. 3 (±15 ms e 2 %): 10,1 ms | 2,1 %.

Um colega propõe reservar 64 kbit/s por chamada «porque o G.711 é 64 kbit/s». O que falta?

Os cabeçalhos: 64 kbit/s é só a voz. Ao nível IP são 80 kbit/s e em Ethernet 87,2 kbit/s; numa VPN ainda mais. Reservar 64 kbit/s deixaria as chamadas a perder pacotes.

Verifique o que aprendeu

Questão 1

Porque não se retransmitem pacotes de voz perdidos numa chamada?

1. Porque o UDP proíbe
2. Porque o pacote retransmitido chegaria tarde demais para ser tocado
3. Porque a voz é cifrada
4. Porque o DSCP EF impede

Questão 2

O que acontece ao aumentar o tampão de jitter do telefone?

1. Menos cortes por chegadas irregulares, mas mais atraso de boca a ouvido
2. Mais débito disponível
3. Menos perda na rede
4. Nada

Em leitura fácil

• A voz e o vídeo precisam de chegar a tempo.
• Um pacote de voz atrasado já não serve.
• Uma chamada usa mais do que 64 kbit/s por causa dos cabeçalhos.
• O telefone guarda alguns pacotes para evitar cortes, mas isso atrasa.
• Há uma referência para o atraso: cerca de 150 ms num sentido.
• A simulação ajuda a comparar, mas não é uma ligação real.

Fontes

• IETF RFC 3550 — RTP: A Transport Protocol for Real-Time Applications (https://www.rfc-editor.org/rfc/rfc3550)
• ITU-T Recommendation G.114 — One-way transmission time (https://www.itu.int/rec/T-REC-G.114)
• ITU-T Recommendation G.711 — Pulse code modulation (PCM) of voice frequencies (https://www.itu.int/rec/T-REC-G.711)
• IETF RFC 7679 — A One-Way Delay Metric for IP Performance Metrics (IPPM) (https://www.rfc-editor.org/rfc/rfc7679)
• IETF RFC 3393 — IP Packet Delay Variation Metric for IPPM (https://www.rfc-editor.org/rfc/rfc3393)
• IETF RFC 768 — User Datagram Protocol (https://www.rfc-editor.org/rfc/rfc768)
• iperf3 — documentação (ESnet) (https://software.es.net/iperf/)
• Linux tc — páginas de manual tc-netem(8), tc-htb(8), tc-tbf(8), tc-fq_codel(8), tc-u32(8) (https://man7.org/linux/man-pages/man8/tc-netem.8.html)
• Wireshark — User's Guide e referência de filtros de visualização (https://www.wireshark.org/docs/)

Duração: 80 minutos (explicação 20, prática guiada 50, verificação 10). Resultados dos TdR trabalhados: Diagnóstico, desempenho e disponibilidade; Automação com scripts básicos.

Objectivos

• Distinguir modelação (shaping, que atrasa em fila) de policiamento (policing, que descarta), e saber que ambos só actuam no sentido e no equipamento onde estão configurados.
• Configurar com tc htb uma divisão da WAN por classes com garantia mínima e limite máximo, e confirmar com contadores.
• Reconhecer o excesso de fila (bufferbloat) e reduzi-lo com a gestão activa de fila fq_codel.
• Calcular o débito útil máximo de uma classe a partir do débito configurado e dos cabeçalhos.

Modelar ou policiar

Modelar (shaping) é guardar numa fila os pacotes que excedem o ritmo definido e enviá-los mais tarde: o tráfego sai liso, mas ganha atraso. Policiar (policing) é descartar ou remarcar o excesso logo à chegada: não há fila, mas o TCP vê perdas, retransmite e pode ficar com débito irregular. Os operadores costumam policiar à entrada da sua rede; por isso convém modelar do lado da instituição um pouco abaixo do débito contratado, para que a fila fique num equipamento que a equipa controla.

O tc só controla a saída de uma interface. Para controlar o que chega à delegação, modela-se na saída da sede (ou usa-se um dispositivo intermédio). O htb do Linux divide um débito por classes: cada uma tem uma taxa garantida (rate) e pode usar até um tecto (ceil) quando as outras não precisam. A garantia vale só dentro deste equipamento; não controla o que o operador faz depois.

Filas grandes e gestão activa de fila

Uma fila grande evita perdas, mas quando enche todos os pacotes esperam: uma ligação de 5 Mbit/s com 1000 pacotes de 1514 bytes em fila acumula até cerca de 2,4 s de espera. É o excesso de fila (bufferbloat): descarregar um ficheiro torna chamadas e páginas web lentíssimas. A gestão activa de fila CoDel (RFC 8289) descarta ou marca pacotes quando o tempo de permanência na fila fica alto durante algum tempo; o FQ-CoDel (RFC 8290) separa também os fluxos em filas pequenas, para que um fluxo pesado não atrase os leves.

Contas de débito útil: o htb conta o pacote com o cabeçalho Ethernet (14 bytes na captura, sem verificação). Um segmento TCP com 1448 bytes de dados ocupa 1514 bytes. Numa classe de 5 Mbit/s, o máximo de dados úteis é 5 × 1448 / 1514 ≈ 4,78 Mbit/s. Numa WAN real, a forma como o operador conta os bytes pode ser outra; confirma-se no contrato.

Caso fictício

A sede da DPE (fictícia) envia para a delegação cópias de segurança nocturnas que se prolongam pela manhã e deixam o sistema de gestão documental (servidor web no srv, porto 80) inutilizável. A WAN contratada (simulada) tem 5 Mbit/s. A política aprovada: gestão documental com 3 Mbit/s garantidos, o resto com 2 Mbit/s garantidos, ambos podendo usar até 5 Mbit/s quando o outro não precisa. Todos os valores são fictícios.

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).
• Sentido controlado: sede → delegação, na saída r1-r2 do espaço de nomes r1. Os testes usam iperf3 -R: o cliente fica em pc-del e o srv envia os dados.
• Gestão documental simulada: iperf3 no porto 80 do srv. Cópias de segurança simuladas: iperf3 no porto 5201.
• Limite da simulação: tudo corre no mesmo processador da VM; com processadores lentos, o limite pode ser o próprio processador e não o htb.

Passos

1. Pré-verificação (não altera nada): confirme ferramentas, que a rede DPE existe, que a delegação chega ao srv e que as interfaces WAN só têm a fila por omissão. Se alguma interface já tiver outra fila, pare: pode pertencer a outra lição não revertida — reverta-a primeiro.

   for d in iperf3 mtr curl tc nft tshark; do command -v $d >/dev/null || echo "Em falta: $d"; done
   ip netns list | grep -E '^(r1|r2|srv|pc-del)( |$)'
   sudo ip netns exec pc-del ping -c 3 10.10.20.53
   sudo ip netns exec r1 tc qdisc show dev r1-r2; sudo ip netns exec r2 tc qdisc show dev r2-r1
   sudo ip netns exec r2 nft list tables | grep qos_lab || echo 'sem tabelas qos_lab'

   Saída de exemplo (didáctica):

   (nenhuma linha «Em falta»)
   r1 (id: 2) … r2 (id: 3) … srv (id: 1) … pc-del (id: 4)
   3 packets transmitted, 3 received, 0% packet loss
   qdisc noqueue 0: root refcnt 2
   qdisc noqueue 0: root refcnt 2
   sem tabelas qos_lab

2. Limite de 5 Mbit/s na saída r1-r2 com uma só classe e uma fila simples grande (pfifo de 1000 pacotes).

   sudo ip netns exec r1 tc qdisc add dev r1-r2 root handle 1: htb default 20
   sudo ip netns exec r1 tc class add dev r1-r2 parent 1: classid 1:1 htb rate 5mbit
   sudo ip netns exec r1 tc class add dev r1-r2 parent 1:1 classid 1:20 htb rate 5mbit
   sudo ip netns exec r1 tc qdisc add dev r1-r2 parent 1:20 handle 20: pfifo limit 1000

3. Excesso de fila: consola C servidor iperf3 (esperar «Server listening»); consola B descarga de 30 s; na consola A, durante a descarga, ping ao srv.

   C: sudo ip netns exec srv iperf3 -s -1 -B 10.10.20.53 -p 5201
   B: sudo ip netns exec pc-del iperf3 -c 10.10.20.53 -p 5201 -R -t 30
   A: sudo ip netns exec pc-del ping -c 20 10.10.20.53 | tail -1

   Saída de exemplo (didáctica):

   A: rtt min/avg/max/mdev = 310.4/1180.6/2351.2/620.3 ms
   B: [  5] 0.00-30.00 sec  16.8 MBytes  4.70 Mbits/sec  receiver
   (o ping de regresso espera atrás dos pacotes da descarga; valores variam em cada execução)

4. Troque a fila da classe por fq_codel e repita o passo anterior.

   sudo ip netns exec r1 tc qdisc replace dev r1-r2 parent 1:20 handle 20: fq_codel
   (repetir C, B e A)

   Saída de exemplo (didáctica):

   A: rtt min/avg/max/mdev = 0.9/4.8/9.7/2.1 ms
   B: [  5] 0.00-30.00 sec  16.7 MBytes  4.68 Mbits/sec  receiver
   (débito útil quase igual; atraso muito menor)

5. Aplique a política: classe 1:10 (gestão documental, porto de origem 80) com 3 Mbit/s garantidos e classe 1:20 ajustada para 2 Mbit/s garantidos; ambas com tecto 5 Mbit/s e fq_codel.

   sudo ip netns exec r1 tc class change dev r1-r2 parent 1:1 classid 1:20 htb rate 2mbit ceil 5mbit
   sudo ip netns exec r1 tc class add dev r1-r2 parent 1:1 classid 1:10 htb rate 3mbit ceil 5mbit
   sudo ip netns exec r1 tc qdisc add dev r1-r2 parent 1:10 handle 10: fq_codel
   sudo ip netns exec r1 tc filter add dev r1-r2 parent 1: protocol ip prio 1 u32 match ip sport 80 0xffff flowid 1:10

6. Dois fluxos ao mesmo tempo: consolas C e D com servidores nos portos 5201 e 80; consola B cópias (40 s); consola A gestão documental (20 s), iniciada logo depois.

   C: sudo ip netns exec srv iperf3 -s -1 -B 10.10.20.53 -p 5201
   D: sudo ip netns exec srv iperf3 -s -1 -B 10.10.20.53 -p 80
   B: sudo ip netns exec pc-del iperf3 -c 10.10.20.53 -p 5201 -R -t 40
   A: sudo ip netns exec pc-del iperf3 -c 10.10.20.53 -p 80 -R -t 20 | tail -2

   Saída de exemplo (didáctica):

   A: [  5] 0.00-20.00 sec  6.80 MBytes  2.85 Mbits/sec  receiver
   B: débito por intervalo cerca de 4,7 Mbit/s antes e depois de A, cerca de 1,9 Mbit/s enquanto A corre

7. Contadores por classe (bytes enviados, descartes, excessos).

   sudo ip netns exec r1 tc -s class show dev r1-r2

   Saída de exemplo (didáctica):

   class htb 1:10 parent 1:1 leaf 10: prio 0 rate 3Mbit ceil 5Mbit … Sent 7210000 bytes …
   class htb 1:20 parent 1:1 leaf 20: prio 0 rate 2Mbit ceil 5Mbit … Sent 41300000 bytes …

8. Contraste com policiamento: retire a modelação e policie a 1 Mbit/s o que entra em r1 vindo de r2 (sentido delegação → sede). Repita um iperf3 normal (sem -R) e observe as retransmissões.

   sudo ip netns exec r1 tc qdisc del dev r1-r2 root
   sudo ip netns exec r1 tc qdisc add dev r1-r2 ingress
   sudo ip netns exec r1 tc filter add dev r1-r2 parent ffff: protocol ip prio 1 u32 match u32 0 0 police rate 1mbit burst 20k drop
   C: sudo ip netns exec srv iperf3 -s -1 -B 10.10.20.53 -p 5201
   B: sudo ip netns exec pc-del iperf3 -c 10.10.20.53 -p 5201 -t 10 | tail -3

   Saída de exemplo (didáctica):

   [  5] 0.00-10.00 sec  1.12 MBytes  0.94 Mbits/sec  187   sender
   [  5] 0.00-10.02 sec  1.05 MBytes  0.88 Mbits/sec        receiver
   (muitas retransmissões: o excesso é descartado, não esperado em fila)

Critérios de sucesso

• A dupla mostra o RTT sob carga com pfifo e com fq_codel, com débito útil semelhante.
• A dupla mostra que, com os dois fluxos, a gestão documental recebe pelo menos cerca de 2,8 Mbit/s de débito útil e que as cópias usam os 5 Mbit/s quando estão sozinhas.
• O formando explica a diferença entre modelação e policiamento usando as retransmissões observadas.
• O formando calcula ≈ 4,78 Mbit/s como débito útil máximo de uma classe de 5 Mbit/s.

Como desfazer (reversão)

• sudo ip netns exec r1 tc qdisc del dev r1-r2 ingress
• sudo ip netns exec r1 tc qdisc del dev r1-r2 root 2>/dev/null (só se a modelação ainda existir)
• Ctrl+C nas consolas C e D se algum servidor ainda estiver à espera (não usar pkill/killall).
• Verificar: sudo ip netns exec r1 tc qdisc show dev r1-r2 mostra só «qdisc noqueue» (sem «ingress»); ip netns pids srv não lista iperf3.

Alternativa em papel: tarefas e respostas esperadas

Com as saídas de exemplo, preencha: fila | RTT médio sob carga | débito útil. (pfifo 1000; fq_codel).

pfifo 1000 | ≈ 1181 ms | 4,70 Mbit/s. fq_codel | ≈ 4,8 ms | 4,68 Mbit/s. O débito quase não muda; o atraso cai muito.

Quanto tempo de espera acumulam, no máximo, 1000 pacotes de 1514 bytes numa ligação de 5 Mbit/s?

1000 × 1514 × 8 = 12 112 000 bits; a 5 000 000 bit/s dá cerca de 2,4 s.

Escreva as classes htb para uma WAN de 10 Mbit/s: videoconferência 3 Mbit/s garantidos, gestão documental 4 Mbit/s, resto 3 Mbit/s, todas com tecto 10 Mbit/s.

Classe mãe 1:1 rate 10mbit; 1:10 rate 3mbit ceil 10mbit; 1:20 rate 4mbit ceil 10mbit; 1:30 rate 3mbit ceil 10mbit (default 30); soma das garantias = 10 Mbit/s; fq_codel em cada classe; filtros por endereço/porto de cada serviço.

O director pede para «garantir 3 Mbit/s à gestão documental até à delegação» configurando só o r1. O que fica garantido e o que não fica?

Fica garantido que, à saída do r1 da sede, a gestão documental tem pelo menos 3 Mbit/s quando pede. Não fica garantido o que acontece na rede do operador nem no sentido delegação → sede; isso exige configurar o r2 e/ou constar do contrato.

Verifique o que aprendeu

Questão 1

Qual é a principal diferença entre modelação (shaping) e policiamento (policing)?

1. A modelação cifra o tráfego
2. A modelação guarda o excesso em fila; o policiamento descarta-o ou remarca-o
3. O policiamento aumenta o débito
4. Não há diferença

Questão 2

Com fq_codel, o RTT sob carga caiu de mais de 1 s para poucos milissegundos. O que aconteceu?

1. A ligação passou a ter mais largura de banda
2. A fila deixou de acumular pacotes durante muito tempo e os fluxos leves não esperam atrás do pesado
3. O ICMP passou a ser prioritário por lei
4. O iperf3 parou

Em leitura fácil

• Pode dividir a ligação entre serviços.
• Cada serviço tem um mínimo garantido e um máximo.
• Uma fila muito grande deixa tudo lento.
• O fq_codel mantém a fila curta.
• Modelar põe em fila. Policiar deita fora.
• Só controla a saída do seu equipamento, não a rede do operador.

Fontes

• Linux tc — páginas de manual tc-netem(8), tc-htb(8), tc-tbf(8), tc-fq_codel(8), tc-u32(8) (https://man7.org/linux/man-pages/man8/tc-netem.8.html)
• 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)
• IETF RFC 8289 — Controlled Delay Active Queue Management (CoDel) (https://www.rfc-editor.org/rfc/rfc8289)
• IETF RFC 8290 — The Flow Queue CoDel Packet Scheduler and AQM (FQ-CoDel) (https://www.rfc-editor.org/rfc/rfc8290)
• IETF RFC 2475 — An Architecture for Differentiated Services (https://www.rfc-editor.org/rfc/rfc2475)
• IETF RFC 6349 — Framework for TCP Throughput Testing (https://www.rfc-editor.org/rfc/rfc6349)
• iperf3 — documentação (ESnet) (https://software.es.net/iperf/)

Duração: 80 minutos (explicação 20, prática guiada 50, verificação 10). Resultados dos TdR trabalhados: Diagnóstico, desempenho e disponibilidade; Documentação: diagramas, procedimentos (SOP) e contingência.

Objectivos

• Aplicar um método de diagnóstico de lentidão: delimitar o sintoma, medir por etapas (resolução de nomes, ligação, primeira resposta, transferência), comparar com uma referência e confirmar a causa antes de corrigir.
• Usar curl --write-out, ping, mtr, iperf3 e os contadores do tc para separar lentidão do servidor, perda na ligação e limitação de débito.
• Escrever um relatório de incidente de desempenho com evidências, causa provável, correcção, verificação e limites das medições.

«Está lento» não é um diagnóstico

Primeiro delimita-se: que serviço, que utilizadores, desde quando, sempre ou a certas horas, e comparado com quê. Depois divide-se o tempo de um pedido em etapas. O curl mostra, com --write-out, o tempo de resolução do nome (time_namelookup), de ligação TCP (time_connect), até ao primeiro byte da resposta (time_starttransfer) e total (time_total), e a velocidade média de transferência. Os tempos do curl são acumulados desde o início do pedido.

Leitura típica: resolução alta aponta para DNS; ligação alta aponta para rede ou servidor sobrecarregado a aceitar ligações; primeiro byte alto com ligação rápida aponta para a aplicação ou o servidor; transferência lenta com primeiro byte rápido aponta para débito, perda ou filas no caminho. São indícios, não provas: cada hipótese confirma-se com outra medição independente (ping e mtr para perda e atraso, iperf3 para débito, contadores do equipamento para descartes).

Confirmar, corrigir, verificar, registar

Mede-se antes de mexer, muda-se uma coisa de cada vez e volta-se a medir com os mesmos parâmetros. Sem uma referência (medição de quando estava normal) não se sabe o que é «lento». Nos equipamentos que a equipa gere, os contadores (por exemplo tc -s qdisc show: sent, dropped, overlimits) mostram se há descartes ou filas; nos equipamentos do operador, pede-se a informação com evidências.

O relatório diz o que foi medido, com que ferramenta e quando; distingue facto medido de hipótese; e indica limites (amostra pequena, horário, simulação). Uma medição feita na rede de prática nunca se apresenta como medição da rede real.

Caso fictício

Na delegação da DPE (fictícia), três pessoas dizem em dias diferentes que «descarregar relatórios do srv está lento». O formador, sem revelar, activa uma de três falhas na rede de prática. As duplas diagnosticam com medições, identificam a causa, pedem a correcção ao formador e verificam. Todos os valores são fictícios.

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).
• Serviço: servidor web de teste no srv, porto 80, a servir um ficheiro de 1 000 000 bytes em /tmp/dpe-m10/l5.
• Falhas escondidas (só o formador aplica, uma de cada vez, sempre na saída r1-r2, sentido sede → delegação, ou no próprio servidor): A — atraso 20 ms e 3 % de perda (netem); B — limitação a 512 kbit/s (tbf); C — servidor que espera 2 s antes de responder.
• Limite da simulação: cada falha é artificial e isolada; na realidade podem coexistir várias causas.

Passos

1. Pré-verificação (não altera nada): confirme ferramentas, que a rede DPE existe, que a delegação chega ao srv e que as interfaces WAN só têm a fila por omissão. Se alguma interface já tiver outra fila, pare: pode pertencer a outra lição não revertida — reverta-a primeiro.

   for d in iperf3 mtr curl tc nft tshark; do command -v $d >/dev/null || echo "Em falta: $d"; done
   ip netns list | grep -E '^(r1|r2|srv|pc-del)( |$)'
   sudo ip netns exec pc-del ping -c 3 10.10.20.53
   sudo ip netns exec r1 tc qdisc show dev r1-r2; sudo ip netns exec r2 tc qdisc show dev r2-r1
   sudo ip netns exec r2 nft list tables | grep qos_lab || echo 'sem tabelas qos_lab'

   Saída de exemplo (didáctica):

   (nenhuma linha «Em falta»)
   r1 (id: 2) … r2 (id: 3) … srv (id: 1) … pc-del (id: 4)
   3 packets transmitted, 3 received, 0% packet loss
   qdisc noqueue 0: root refcnt 2
   qdisc noqueue 0: root refcnt 2
   sem tabelas qos_lab

2. Prepare a pasta própria, o ficheiro de teste e o servidor lento (este só é usado na falha C).

   mkdir -p /tmp/dpe-m10/l5
   head -c 1000000 /dev/zero > /tmp/dpe-m10/l5/relatorio.bin
   cat > /tmp/dpe-m10/l5/lento.py <<'EOF'
   import functools, http.server, time
   class H(http.server.SimpleHTTPRequestHandler):
       def do_GET(self):
           time.sleep(2)
           super().do_GET()
   http.server.ThreadingHTTPServer(('10.10.20.53', 80), functools.partial(H, directory='/tmp/dpe-m10/l5')).serve_forever()
   EOF

3. Consola C: servidor web normal (esperar «Serving HTTP»). Meça a referência três vezes e registe.

   C: sudo ip netns exec srv python3 -m http.server 80 --bind 10.10.20.53 --directory /tmp/dpe-m10/l5
   for i in 1 2 3; do sudo ip netns exec pc-del curl -o /dev/null -s -w 'ligacao=%{time_connect} primeiro_byte=%{time_starttransfer} total=%{time_total} bytes_s=%{speed_download}\n' http://10.10.20.53/relatorio.bin; done

   Saída de exemplo (didáctica):

   ligacao=0.000210 primeiro_byte=0.001310 total=0.004920 bytes_s=203252032
   (três linhas semelhantes; é a referência na rede de prática, não um valor real)

4. Formador (consola própria, sem mostrar): aplica UMA falha. Para C, faz Ctrl+C no servidor normal da consola C e inicia o servidor lento.

   A: sudo ip netns exec r1 tc qdisc add dev r1-r2 root netem delay 20ms loss 3%
   B: sudo ip netns exec r1 tc qdisc add dev r1-r2 root tbf rate 512kbit burst 16kb latency 400ms
   C: sudo ip netns exec srv python3 /tmp/dpe-m10/l5/lento.py

5. Etapa 1 — decompor o pedido com curl (três repetições). Compare com a referência.

   for i in 1 2 3; do sudo ip netns exec pc-del curl -o /dev/null -s -w 'ligacao=%{time_connect} primeiro_byte=%{time_starttransfer} total=%{time_total} bytes_s=%{speed_download}\n' http://10.10.20.53/relatorio.bin; done

   Saída de exemplo (didáctica):

   Falha A: ligacao=0.020400 primeiro_byte=0.041200 total=2.310000 bytes_s=432900
   Falha B: ligacao=0.000300 primeiro_byte=0.001600 total=15.980000 bytes_s=62578
   Falha C: ligacao=0.000220 primeiro_byte=2.003100 total=2.007400 bytes_s=498156

6. Etapa 2 — atraso e perda: ping com amostra suficiente e mtr.

   sudo ip netns exec pc-del ping -c 100 -i 0.1 10.10.20.53 | tail -2
   sudo ip netns exec pc-del mtr -n -r -c 50 10.10.20.53

   Saída de exemplo (didáctica):

   Falha A: 100 transmitted, 97 received, 3% packet loss; rtt avg 20.3 ms; mtr: perda a partir do salto 2 (10.255.0.1) e no destino
   Falha B: 0% packet loss; rtt avg 0.08 ms (sem carga, a limitação não se vê no ping)
   Falha C: 0% packet loss; rtt avg 0.07 ms

7. Etapa 3 — débito no sentido sede → delegação (consola D: servidor iperf3; esperar «Server listening»).

   D: sudo ip netns exec srv iperf3 -s -1 -B 10.10.20.53 -p 5201
   sudo ip netns exec pc-del iperf3 -c 10.10.20.53 -p 5201 -R -t 10 | tail -3

   Saída de exemplo (didáctica):

   Falha A: sender … 3.9 Mbits/sec  Retr 212; receiver 3.8 Mbits/sec
   Falha B: sender … 0.50 Mbits/sec  Retr 4; receiver 0.49 Mbits/sec
   Falha C: receiver com o débito da referência (a rede está normal)

8. Etapa 4 — confirmar no equipamento gerido (r1): contadores da fila de saída.

   sudo ip netns exec r1 tc -s qdisc show dev r1-r2

   Saída de exemplo (didáctica):

   Falha A: qdisc netem 8001: root … delay 20ms loss 3% … Sent … (dropped 212 …)
   Falha B: qdisc tbf 8002: root … rate 512Kbit burst 16Kb lat 400ms … (dropped 4, overlimits 1840 …)
   Falha C: qdisc noqueue 0: root (nenhuma fila configurada)

9. Etapa 5 — conclusão e pedido de correcção ao formador (que remove a falha: comandos na reversão). Repita a Etapa 1 para verificar que voltou à referência. Escreva o relatório.

   nano /tmp/dpe-m10/l5/relatorio-incidente.txt

Critérios de sucesso

• Para cada falha, a dupla identifica a etapa anómala no curl e confirma com pelo menos uma medição independente (ping/mtr, iperf3 ou contadores).
• A dupla distingue as três causas: perda na ligação (A), limitação de débito (B), servidor lento (C).
• A dupla verifica após a correcção, com os mesmos comandos, que os tempos voltaram à referência.
• O relatório separa factos medidos de hipóteses e indica que as medições são da rede de prática.

Como desfazer (reversão)

• Falhas A ou B: sudo ip netns exec r1 tc qdisc del dev r1-r2 root
• Falha C: Ctrl+C na consola onde corre lento.py (não usar pkill/killall).
• Ctrl+C nas consolas C e D se algum servidor ainda estiver activo.
• Guardar o relatório fora da VM, se necessário, e depois: rm -r /tmp/dpe-m10/l5 (remove ficheiro de teste, lento.py e relatório).
• Verificar: tc qdisc show dev r1-r2 mostra só «qdisc noqueue»; ip netns pids srv não lista python3 nem iperf3.

Alternativa em papel: tarefas e respostas esperadas

Para cada linha de curl de exemplo (falhas A, B e C), diga que etapa está anómala e qual a hipótese.

A: ligação e primeiro byte cerca de 20–40 ms (atraso) e transferência lenta → atraso e perda na ligação. B: ligação e primeiro byte normais, transferência muito lenta (≈ 62 kB/s ≈ 0,5 Mbit/s) → limitação de débito. C: ligação normal, primeiro byte 2 s, transferência rápida → servidor/aplicação.

Na falha B o ping sem carga era normal. Porque isso não descarta um problema de rede?

O ping sem carga usa muito pouco débito e não enche a fila; uma limitação de débito só se revela com transferências (iperf3, curl) ou com ping durante a carga, e nos contadores (overlimits) do equipamento.

Escreva o relatório de incidente para a falha A.

Sintoma: descargas lentas na delegação. Medições (rede de prática, data/hora): curl total 2,31 s vs referência 0,005 s; ping 100 amostras 3 % perda, RTT 20,3 ms; mtr perda a partir do salto 2; iperf3 -R 3,8 Mbit/s com 212 retransmissões; tc em r1 mostra netem com loss 3 %. Causa: perda e atraso na saída r1-r2 (simulados). Correcção: remoção da fila netem. Verificação: curl voltou à referência. Limites: falha artificial, amostras curtas.

Um colega reinicia o servidor e o encaminhador «para ver se resolve» antes de medir. Que problemas isso cria?

Perdem-se as evidências (contadores, estado), não se sabe qual acção resolveu, pode causar interrupção desnecessária e o problema pode voltar sem explicação. Primeiro mede-se, depois muda-se uma coisa de cada vez.

Verifique o que aprendeu

Questão 1

O curl mostra ligação em 0,2 ms e primeiro byte em 2 s. Onde procurar primeiro?

1. No cabo de rede
2. No servidor ou na aplicação, porque a ligação TCP foi rápida e a espera é pela resposta
3. No DNS
4. Na VLAN

Questão 2

Porque se mede com os mesmos comandos antes e depois da correcção?

1. Para gastar tempo
2. Para comparar de forma justa e provar que a correcção resolveu o problema
3. Porque o curl só funciona assim
4. Para apagar os registos

Em leitura fácil

• Primeiro pergunte: o quê, quem, quando.
• Meça antes de mudar qualquer coisa.
• Divida o pedido em partes: ligar, esperar resposta, receber.
• Confirme a causa com outra medição.
• Mude uma coisa de cada vez e volte a medir.
• Escreva o que mediu e o que ainda é só uma ideia.

Fontes

• curl — manual oficial (opção --write-out) (https://curl.se/docs/manpage.html)
• mtr — página oficial e manual mtr(8) (https://www.bitwizard.nl/mtr/)
• iperf3 — documentação (ESnet) (https://software.es.net/iperf/)
• Linux tc — páginas de manual tc-netem(8), tc-htb(8), tc-tbf(8), tc-fq_codel(8), tc-u32(8) (https://man7.org/linux/man-pages/man8/tc-netem.8.html)
• 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)
• IETF RFC 2681 — A Round-trip Delay Metric for IPPM (https://www.rfc-editor.org/rfc/rfc2681)
• IETF RFC 7680 — A One-Way Loss Metric for IP Performance Metrics (IPPM) (https://www.rfc-editor.org/rfc/rfc7680)
• IETF RFC 6349 — Framework for TCP Throughput Testing (https://www.rfc-editor.org/rfc/rfc6349)
• NIST SP 800-61 Rev. 3 — Incident Response Recommendations (https://csrc.nist.gov/pubs/sp/800/61/r3/final)

Duração: 70 minutos (explicação 20, prática guiada 40, verificação 10). Resultados dos TdR trabalhados: Documentação: diagramas, procedimentos (SOP) e contingência; Continuidade e protecção de activos digitais.

Objectivos

• Explicar para que servem o inventário de activos de rede, o diagrama lógico e a ficha de cada equipamento, e que informação nunca deve constar neles (palavras-passe, chaves).
• Gerar automaticamente um inventário IPv4 da rede de prática com um script Python com tratamento de erros, e detectar endereços repetidos.
• Comparar o inventário gerado com a documentação existente e registar as diferenças como pendências com responsável.

Inventário, diagrama e ficha

Só se gere o que se conhece. O inventário lista cada equipamento com função, localização, responsável, interfaces, endereços, versão do sistema, garantia e contrato de suporte. O diagrama lógico mostra como os equipamentos se ligam (redes, VLAN, encaminhadores, ligações ao operador); o diagrama físico mostra bastidores, tomadas e cabos. A ficha de equipamento junta o que é preciso para o substituir ou recuperar. Estes documentos sustentam a continuidade de serviço (NIST SP 800-34) e a gestão de configurações (NIST SP 800-128).

A documentação não guarda segredos: palavras-passe, chaves e cadeias SNMP ficam num cofre de credenciais com acesso controlado; no inventário escreve-se apenas onde estão e quem as gere. Um inventário também é informação sensível — mostra a quem ataca o que existe — e deve ter acesso restrito.

Automatizar e confrontar

Um inventário escrito à mão desactualiza-se. Recolher dados dos próprios equipamentos (aqui com 'ip -j', que devolve JSON; em equipamentos reais por SNMP, API ou exportação de configuração) dá uma fotografia do estado real. A fotografia não substitui a documentação: não diz a função, o dono, nem se aquele endereço devia existir. Por isso compara-se o gerado com o documentado e cada diferença vira uma pendência: corrigir o documento ou corrigir o equipamento, com responsável e prazo.

Um script de recolha deve falhar de forma clara: dizer qual equipamento não respondeu, não escrever um ficheiro meio vazio sem aviso e terminar com código de erro, para que quem o agenda perceba que algo correu mal.

Caso fictício

A DPE (fictícia) recebeu um técnico novo. O único diagrama tem dois anos e a folha de endereços diz que a delegação usa 10.20.20.0/24. O chefe pede um inventário actualizado da rede de prática que reproduz a sede e a delegação, e uma lista de diferenças para decidir o que corrigir. Todos os dados são fictícios.

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).
• Documento «antigo» fictício a confrontar: delegação 10.20.20.0/24; ligação WAN 10.255.0.0/30; servidor 10.10.20.53; sem referência ao operador simulado (isp).
• O script ignora o endereço 198.51.100.10/32 da interface lo do isp (as interfaces lo são excluídas de propósito); a lacuna é discutida no fim.

Passos

1. Pré-verificação (não altera nada): ferramentas presentes, rede DPE activa, delegação chega ao srv e a pasta de trabalho do módulo ainda não existe (se existir, pode ter dados de outra pessoa ou de outra lição: pare e confirme antes de continuar).

   for d in python3 git snmpget snmpwalk snmpd rsyslogd logger iperf3 sha256sum; do command -v $d >/dev/null || echo "Em falta: $d"; done
   ip netns list | grep -cE '^(pc-adm|srv|r1|r2|pc-del|isp)( |$)'
   sudo ip netns exec pc-del ping -c 2 10.10.20.53 | tail -2
   test -e /tmp/dpe-m11 && echo 'ATENÇÃO: /tmp/dpe-m11 já existe' || echo 'pasta livre'

   Saída de exemplo (didáctica):

   (nenhuma linha «Em falta»)
   6
   2 packets transmitted, 2 received, 0% packet loss
   pasta livre

2. Crie a pasta de trabalho do módulo e grave o script de inventário (texto completo abaixo).

   mkdir -p /tmp/dpe-m11/l1 && cd /tmp/dpe-m11/l1
   cat > inventario.py <<'EOF'
   #!/usr/bin/env python3
   """inventario.py — inventário IPv4 da rede de prática DPE (fictícia).
   Uso: sudo python3 inventario.py SAIDA.csv
   Lê cada espaço de nomes com 'ip -j addr' e escreve um CSV. Não altera nada."""
   import csv, json, subprocess, sys
   
   NOMES = ["pc-adm", "srv", "r1", "r2", "pc-del", "isp"]
   
   def ler(ns):
       try:
           r = subprocess.run(["ip", "-n", ns, "-j", "addr", "show"],
                              capture_output=True, text=True, check=True, timeout=10)
           return json.loads(r.stdout)
       except (subprocess.CalledProcessError, subprocess.TimeoutExpired, json.JSONDecodeError) as e:
           print(f"ERRO ao ler {ns}: {getattr(e, 'stderr', '') or e}".strip(), file=sys.stderr)
           return None
   
   if len(sys.argv) != 2:
       sys.exit("Uso: sudo python3 inventario.py SAIDA.csv")
   linhas, donos, falhas = [], {}, 0
   for ns in NOMES:
       dados = ler(ns)
       if dados is None:
           falhas += 1
           continue
       for itf in dados:
           if itf["ifname"] == "lo":
               continue
           for a in itf.get("addr_info", []):
               if a.get("family") != "inet":
                   continue
               linhas.append([ns, itf["ifname"], itf.get("address", ""),
                              f"{a['local']}/{a['prefixlen']}", itf.get("operstate", "")])
               donos.setdefault(a["local"], []).append(ns)
   try:
       with open(sys.argv[1], "w", newline="") as f:
           w = csv.writer(f)
           w.writerow(["equipamento", "interface", "mac", "ipv4", "estado"])
           w.writerows(linhas)
   except OSError as e:
       sys.exit(f"ERRO ao escrever {sys.argv[1]}: {e}")
   for ip, ns in donos.items():
       if len(ns) > 1:
           print(f"AVISO: {ip} repetido em {', '.join(ns)}")
   print(f"{len(linhas)} endereços inventariados; {falhas} equipamento(s) com erro.")
   sys.exit(1 if falhas else 0)
   EOF

3. Execute o script e veja o CSV.

   sudo python3 inventario.py inventario.csv; echo "código=$?"
   column -s, -t inventario.csv

   Saída de exemplo (didáctica):

   10 endereços inventariados; 0 equipamento(s) com erro.
   código=0
   equipamento  interface  mac                ipv4            estado
   pc-adm       pc-adm-r1  0a:1b:…:01         10.10.10.10/24  UP
   srv          srv-r1     0a:1b:…:02         10.10.20.53/24  UP
   r1           r1-pc-adm  …                  10.10.10.1/24   UP
   r1           r1-srv     …                  10.10.20.1/24   UP
   r1           r1-r2      …                  10.255.0.1/30   UP
   r1           r1-isp     …                  203.0.113.2/24  UP
   r2           r2-r1      …                  10.255.0.2/30   UP
   r2           r2-pc-del  …                  10.20.10.1/24   UP
   pc-del       pc-del-r2  …                  10.20.10.10/24  UP
   isp          isp-r1     …                  203.0.113.1/24  UP
   (os endereços MAC variam em cada VM)

4. Teste o tratamento de erros: destino onde não se pode escrever. O script deve dizer porquê e terminar com código diferente de 0.

   sudo python3 inventario.py /pasta-inexistente/x.csv; echo "código=$?"

   Saída de exemplo (didáctica):

   ERRO ao escrever /pasta-inexistente/x.csv: [Errno 2] No such file or directory: '/pasta-inexistente/x.csv'
   código=1

5. Teste a detecção de repetidos: acrescente temporariamente, no pc-del, um endereço igual ao do srv; corra o script; retire o endereço logo a seguir.

   sudo ip -n pc-del addr add 10.10.20.53/32 dev pc-del-r2
   sudo python3 inventario.py teste.csv
   sudo ip -n pc-del addr del 10.10.20.53/32 dev pc-del-r2

   Saída de exemplo (didáctica):

   AVISO: 10.10.20.53 repetido em srv, pc-del
   11 endereços inventariados; 0 equipamento(s) com erro.

6. Escreva o diagrama lógico em texto e a lista de diferenças face ao documento antigo, com responsável e prazo (fictícios).

   nano /tmp/dpe-m11/l1/diagrama.txt
   nano /tmp/dpe-m11/l1/diferencas.txt

Critérios de sucesso

• O CSV lista os 10 endereços IPv4 das interfaces não-lo, com estado UP.
• O script termina com código 1 e mensagem clara quando não consegue escrever, e avisa o endereço repetido.
• A lista de diferenças inclui pelo menos: rede da delegação (10.20.10.0/24 real vs 10.20.20.0/24 documentada), ligação ao operador em falta no documento, e o endereço em lo do isp não inventariado pelo script.
• Nenhum documento produzido contém palavras-passe ou chaves.

Como desfazer (reversão)

• Confirmar que o endereço de teste foi retirado: sudo ip -n pc-del addr show dev pc-del-r2 mostra só 10.20.10.10/24 (se não, sudo ip -n pc-del addr del 10.10.20.53/32 dev pc-del-r2).
• Guardar os ficheiros fora da VM, se necessário, e depois: rm -r /tmp/dpe-m11/l1 (se for a última lição do módulo nesta VM: rm -r /tmp/dpe-m11).

Alternativa em papel: tarefas e respostas esperadas

A partir da saída de exemplo do CSV, desenhe o diagrama lógico com redes e encaminhadores.

pc-adm (10.10.10.10) — rede 10.10.10.0/24 — r1; srv (10.10.20.53) — 10.10.20.0/24 — r1; r1 (10.255.0.1) — WAN 10.255.0.0/30 — r2 (10.255.0.2); r2 — 10.20.10.0/24 — pc-del (10.20.10.10); r1 (203.0.113.2) — 203.0.113.0/24 — isp (203.0.113.1).

Liste as diferenças entre o CSV de exemplo e o documento antigo, e para cada uma diga se corrige o documento ou o equipamento.

1) Delegação 10.20.10.0/24 no equipamento vs 10.20.20.0/24 no documento → confirmar com o responsável; muito provavelmente corrigir o documento. 2) Ligação r1–isp não documentada → acrescentar ao documento. 3) 198.51.100.10/32 em lo do isp não aparece no CSV → limitação do script; documentar ou melhorar o script.

Um colega quer pôr a palavra-passe de administração de cada encaminhador numa coluna do inventário «para facilitar». Responda.

Não. O inventário é partilhado e mostra toda a rede; as credenciais ficam num cofre com acesso controlado e registo. No inventário indica-se só o cofre e o responsável.

Que campos acrescentaria à ficha de equipamento do r1 que o script não consegue recolher?

Função, localização, responsável, fabricante/modelo e número de série, versão do sistema, data de aquisição e garantia, contrato de suporte, dependências (serviços que param se falhar) e procedimento de recuperação.

Verifique o que aprendeu

Questão 1

Porque o script termina com código 1 quando um equipamento não responde?

1. Para apagar o CSV
2. Para que quem o executa ou agenda saiba que o inventário está incompleto
3. Porque o Python obriga
4. Para reiniciar o equipamento

Questão 2

O inventário gerado automaticamente substitui a documentação?

1. Sim, completamente
2. Não: mostra o estado real, mas não a função, o responsável nem se o estado está correcto; compara-se com o documentado
3. Sim, se tiver endereços MAC
4. Não, porque o JSON é ilegível

Em leitura fácil

• O inventário é a lista de tudo o que há na rede.
• O diagrama mostra como tudo está ligado.
• Um programa pode recolher a lista automaticamente.
• Compare a lista nova com os papéis antigos.
• Nunca escreva palavras-passe no inventário.

Fontes

• NIST SP 800-34 Rev. 1 — Contingency Planning Guide (https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final)
• NIST SP 800-128 — Guide for Security-Focused Configuration Management of Information Systems (https://csrc.nist.gov/pubs/sp/800/128/upd1/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)
• Python 3 — documentação oficial dos módulos json, csv, subprocess e statistics (https://docs.python.org/3/library/)
• IETF RFC 1918 — Address Allocation for Private Internets (https://www.rfc-editor.org/rfc/rfc1918)
• IETF RFC 5737 — IPv4 Address Blocks Reserved for Documentation (https://www.rfc-editor.org/rfc/rfc5737)

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.

Objectivos

• Explicar a arquitectura SNMP (gestor, agente, MIB, OID) e porque se prefere SNMPv3 com autenticação e cifra (authPriv) às comunidades v1/v2c.
• Configurar um agente SNMPv3 de prática, isolado no espaço de nomes srv, e consultá-lo com um cliente que não expõe segredos na linha de comando.
• Calcular a utilização de uma interface a partir de contadores e definir um alerta com limiar, persistência e histerese justificados.
• Distinguir falta de dados (agente sem resposta) de valor normal, e tratar reinícios de contador.

SNMP e segurança

No SNMP, o gestor pergunta e o agente, no equipamento, responde. Cada valor tem um identificador numérico (OID) definido numa MIB; por exemplo, a IF-MIB (RFC 2863) define ifName (nome da interface) e ifHCInOctets (bytes recebidos, contador de 64 bits). Os contadores só crescem; a utilização calcula-se pela diferença entre duas leituras a dividir pelo tempo entre elas.

SNMPv1 e v2c usam uma «comunidade» enviada em claro: quem capturar o tráfego fica a conhecê-la. SNMPv3 com o modelo USM (RFC 3414, arquitectura no RFC 3411) acrescenta utilizadores, autenticação e cifra: o nível authPriv autentica (aqui HMAC-SHA-256, RFC 7860) e cifra (AES, RFC 3826). Mesmo assim, o agente só deve responder na rede de gestão, com acesso de leitura limitado e segredos guardados num cofre. Nesta prática o agente escuta só em 10.10.20.53, dentro do espaço de nomes srv: não fica visível na rede da VM nem da instituição.

Alertas que merecem ser atendidos

Um alerta útil diz o quê, onde, desde quando e o que fazer, e tem um responsável. Limiar sem persistência gera alarmes por picos de segundos; persistência (várias amostras seguidas) confirma que o problema dura. Histerese — limiar de entrada maior do que o de saída, aqui 80 % e 70 % — evita que o alerta ligue e desligue sem parar quando o valor anda à volta do limiar. Os números justificam-se pelo serviço: acima de cerca de 80 % de utilização sustentada, as filas crescem e o atraso sobe (módulo 10), por isso é altura de investigar, não de entrar em pânico.

Na prática usam-se ciclos de 10 s para caber na aula; em produção são comuns amostras de 1 a 5 minutos. «Sem dados» é um estado próprio: não é zero nem normal. A capacidade usada no cálculo é a declarada pela equipa (contrato ou velocidade da porta); nas interfaces virtuais da prática o valor reportado pelo agente não corresponde a uma ligação real.

Caso fictício

Na DPE (fictícia), a ligação ao servidor fica saturada sem que ninguém saiba até os utilizadores reclamarem. O chefe aprova: monitorizar por SNMPv3 authPriv a interface do srv, capacidade declarada 10 Mbit/s; alertar acima de 80 % em 3 amostras seguidas e voltar ao normal abaixo de 70 % em 2 amostras; alertar se o agente não responder em 3 amostras. Todos os valores e segredos são fictícios.

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).
• Agente SNMP: snmpd em primeiro plano no espaço de nomes srv, a escutar só em 10.10.20.53 UDP 161, com configuração e directório persistente próprios em /tmp/dpe-m11/l2.
• Gestor: script monitor.py no pc-adm. Tráfego de carga: iperf3 UDP do pc-del para o srv.
• Nota sobre a VM de preparação: instalar o pacote snmpd no Debian pode activar o serviço snmpd do sistema. Em que endereços ele escuta depende da versão e da configuração do pacote, por isso não se presume (nem «só 127.0.0.1»): verifica-se e regista-se na preparação, antes da aula. Esta lição não instala, não altera e não reinicia esse serviço.
• O agente desta lição corre dentro do espaço de nomes srv, que tem a sua própria pilha de rede; por isso não entra em conflito com um eventual snmpd do sistema na porta 161 da VM.

Passos

1. Pré-verificação (não altera nada): ferramentas presentes, rede DPE activa, delegação chega ao srv e a pasta de trabalho do módulo ainda não existe (se existir, pode ter dados de outra pessoa ou de outra lição: pare e confirme antes de continuar).

   for d in python3 git snmpget snmpwalk snmpd rsyslogd logger iperf3 sha256sum; do command -v $d >/dev/null || echo "Em falta: $d"; done
   ip netns list | grep -cE '^(pc-adm|srv|r1|r2|pc-del|isp)( |$)'
   sudo ip netns exec pc-del ping -c 2 10.10.20.53 | tail -2
   test -e /tmp/dpe-m11 && echo 'ATENÇÃO: /tmp/dpe-m11 já existe' || echo 'pasta livre'

   Saída de exemplo (didáctica):

   (nenhuma linha «Em falta»)
   6
   2 packets transmitted, 2 received, 0% packet loss
   pasta livre

2. Verificação só de leitura da VM de preparação (não altera nada): o serviço snmpd do sistema está activo? Em que endereços escuta de facto? Que regras de firewall tem a VM? Registe as respostas e a lista de pacotes que a instalação acrescentou na ficha de preparação da VM. Se o serviço escutar noutro endereço além de 127.0.0.1 ou ::1, não o altere durante a aula: informe o responsável da preparação, que decide (restringir, desactivar ou descartar a VM) e regista a decisão.

   systemctl is-enabled snmpd; systemctl is-active snmpd
   sudo ss -ulnp 'sport = :161'
   sudo nft list ruleset | head -n 40
   grep -E ' install (snmp|snmpd|libsnmp)' /var/log/dpkg.log | tail -n 5

   Saída de exemplo (didáctica):

   enabled
   active
   UNCONN 0 0 127.0.0.1:161 0.0.0.0:* users:(("snmpd",pid=812,fd=6))
   (exemplo: noutra VM podem aparecer outros endereços, ou o serviço pode estar inactivo; registe o que vir)
   (regras de firewall da VM, ou nada se não houver regras)
   2026-09-27 16:02:11 install snmpd:amd64 <none> 5.9.3+dfsg-2

3. Prepare a pasta, a configuração do agente, o utilizador USM (segredos fictícios) e a configuração do cliente. Restrinja as permissões dos ficheiros com segredos.

   mkdir -p /tmp/dpe-m11/l2/agente-persist /tmp/dpe-m11/l2/cliente /tmp/dpe-m11/l2/cliente-persist && cd /tmp/dpe-m11/l2
   cat > snmpd.conf <<'EOF'
   agentaddress udp:10.10.20.53:161
   rouser monitor priv
   sysLocation Rede de pratica DPE (ficticia)
   sysContact ti@dpe.example
   EOF
   cat > agente-persist/snmpd.conf <<'EOF'
   createUser monitor SHA-256 "PraticaAuth-2026-fict" AES "PraticaPriv-2026-fict"
   EOF
   cat > cliente/snmp.conf <<'EOF'
   defVersion 3
   defSecurityName monitor
   defSecurityLevel authPriv
   defAuthType SHA-256
   defAuthPassphrase PraticaAuth-2026-fict
   defPrivType AES
   defPrivPassphrase PraticaPriv-2026-fict
   EOF
   chmod 600 agente-persist/snmpd.conf cliente/snmp.conf

4. Consola C: inicie o agente em primeiro plano no srv, só com esta configuração (-C ignora os ficheiros do sistema). Espere pela linha «NET-SNMP version … ».

   C: sudo ip netns exec srv env SNMP_PERSISTENT_DIR=/tmp/dpe-m11/l2/agente-persist snmpd -f -Lo -C -c /tmp/dpe-m11/l2/snmpd.conf

   Saída de exemplo (didáctica):

   NET-SNMP version 5.9.3

5. Consulte o agente a partir do pc-adm: tempo de funcionamento e nomes das interfaces (OIDs numéricos, pois o Debian não instala todas as MIB por omissão).

   export CLI='env SNMPCONFPATH=/tmp/dpe-m11/l2/cliente SNMP_PERSISTENT_DIR=/tmp/dpe-m11/l2/cliente-persist'
   sudo ip netns exec pc-adm $CLI snmpget -On 10.10.20.53 1.3.6.1.2.1.1.3.0
   sudo ip netns exec pc-adm $CLI snmpwalk -On 10.10.20.53 1.3.6.1.2.1.31.1.1.1.1

   Saída de exemplo (didáctica):

   .1.3.6.1.2.1.1.3.0 = Timeticks: (2310) 0:00:23.10
   .1.3.6.1.2.1.31.1.1.1.1.1 = STRING: lo
   .1.3.6.1.2.1.31.1.1.1.1.2 = STRING: srv-r1
   (o número de índice pode variar)

6. Confirme a segurança: sem cifra, com segredo errado e com comunidade v2c o agente recusa ou não responde.

   sudo ip netns exec pc-adm $CLI snmpget -l authNoPriv 10.10.20.53 1.3.6.1.2.1.1.3.0
   sudo ip netns exec pc-adm $CLI snmpget -A SegredoErrado-000 10.10.20.53 1.3.6.1.2.1.1.3.0
   sudo ip netns exec pc-adm snmpget -v2c -c public -t 1 -r 0 10.10.20.53 1.3.6.1.2.1.1.3.0

   Saída de exemplo (didáctica):

   Error in packet … Reason: authorizationError (access denied to that object)
   snmpget: Authentication failure (incorrect password, community or key)
   Timeout: No Response from 10.10.20.53

7. Grave o script de monitorização (texto completo abaixo) e inicie-o na consola M.

   cat > monitor.py <<'EOF'
   #!/usr/bin/env python3
   """monitor.py — utilização de entrada de uma interface por SNMPv3 (rede de prática DPE).
   Uso: sudo ip netns exec pc-adm env SNMPCONFPATH=... SNMP_PERSISTENT_DIR=... python3 monitor.py
   Alerta: acima de 80 % em 3 ciclos seguidos; volta ao normal abaixo de 70 % em 2 ciclos."""
   import os, subprocess, sys, time
   
   ALVO, IFNAME, CAP_BPS = "10.10.20.53", "srv-r1", 10_000_000  # capacidade DECLARADA
   LIM_ALTO, LIM_BAIXO, N_ALTO, N_BAIXO, INTERVALO = 0.80, 0.70, 3, 2, 10
   OID_NOME = "1.3.6.1.2.1.31.1.1.1.1"   # IF-MIB::ifName
   OID_IN = "1.3.6.1.2.1.31.1.1.1.6"     # IF-MIB::ifHCInOctets (contador de 64 bits)
   
   def snmp(cmd, oid):
       r = subprocess.run([cmd, "-On", "-Oq", ALVO, oid], capture_output=True, text=True, timeout=10)
       if r.returncode != 0 or not r.stdout.strip() or "No Such" in r.stdout:
           raise RuntimeError((r.stderr or r.stdout).strip() or "sem resposta")
       return r.stdout.strip().splitlines()
   
   def hora():
       return time.strftime("%H:%M:%S")
   
   if "SNMPCONFPATH" not in os.environ:
       sys.exit("Defina SNMPCONFPATH com a configuração do cliente (passo 3).")
   try:
       idx = next(l.split()[0].rsplit(".", 1)[1] for l in snmp("snmpwalk", OID_NOME)
                  if l.split()[-1].strip('"') == IFNAME)
   except StopIteration:
       sys.exit(f"Interface {IFNAME} não encontrada no agente.")
   except (RuntimeError, subprocess.TimeoutExpired) as e:
       sys.exit(f"ERRO SNMP: {e}")
   print(f"{IFNAME} = ifIndex {idx}; capacidade declarada {CAP_BPS // 1_000_000} Mbit/s; Ctrl+C para parar")
   
   anterior, altos, baixos, falhas, estado = None, 0, 0, 0, "NORMAL"
   while True:
       try:
           valor = int(snmp("snmpget", f"{OID_IN}.{idx}")[0].split()[-1])
           agora, falhas = time.monotonic(), 0
       except (RuntimeError, subprocess.TimeoutExpired, ValueError) as e:
           falhas += 1
           print(f"{hora()} SEM DADOS ({e})")
           if falhas == 3:
               print(f"{hora()} ALERTA: agente não responde há 3 ciclos")
           time.sleep(INTERVALO)
           continue
       if anterior and valor < anterior[0]:
           print(f"{hora()} contador recuou (reinício do agente?): amostra ignorada")
       elif anterior:
           util = (valor - anterior[0]) * 8 / (agora - anterior[1]) / CAP_BPS
           altos = altos + 1 if util > LIM_ALTO else 0
           baixos = baixos + 1 if util < LIM_BAIXO else 0
           if estado == "NORMAL" and altos >= N_ALTO:
               estado = "ALERTA"
               print(f"{hora()} ALERTA: entrada em {IFNAME} acima de 80 % em {N_ALTO} ciclos seguidos")
           elif estado == "ALERTA" and baixos >= N_BAIXO:
               estado = "NORMAL"
               print(f"{hora()} NORMAL: entrada abaixo de 70 % em {N_BAIXO} ciclos seguidos")
           print(f"{hora()} utilização {util:6.1%}  estado {estado}")
       anterior = (valor, agora)
       time.sleep(INTERVALO)
   EOF
   M: sudo ip netns exec pc-adm env SNMPCONFPATH=/tmp/dpe-m11/l2/cliente SNMP_PERSISTENT_DIR=/tmp/dpe-m11/l2/cliente-persist python3 /tmp/dpe-m11/l2/monitor.py

   Saída de exemplo (didáctica):

   srv-r1 = ifIndex 2; capacidade declarada 10 Mbit/s; Ctrl+C para parar
   12:00:10 utilização   0.0%  estado NORMAL

8. Gere carga de cerca de 9 Mbit/s durante 60 s (consola D: servidor iperf3, esperar «Server listening»; consola B: cliente) e observe o alerta e o regresso ao normal.

   D: sudo ip netns exec srv iperf3 -s -1 -B 10.10.20.53
   B: sudo ip netns exec pc-del iperf3 -c 10.10.20.53 -u -b 9M -t 60

   Saída de exemplo (didáctica):

   12:00:20 utilização  92.4%  estado NORMAL
   12:00:30 utilização  92.6%  estado NORMAL
   12:00:40 ALERTA: entrada em srv-r1 acima de 80 % em 3 ciclos seguidos
   12:00:40 utilização  92.5%  estado ALERTA
   …
   12:01:30 utilização   8.1%  estado ALERTA
   12:01:40 NORMAL: entrada abaixo de 70 % em 2 ciclos seguidos
   (a percentagem inclui cabeçalhos Ethernet, IP e UDP, por isso passa um pouco dos 90 %)

9. Teste a falta de dados: Ctrl+C no agente (consola C) e observe três ciclos; volte a iniciar o agente com o mesmo comando do passo 4 e observe o tratamento do contador.

   C: Ctrl+C; depois repetir o comando do passo 4

   Saída de exemplo (didáctica):

   12:02:10 SEM DADOS (Timeout: No Response from 10.10.20.53.)
   12:02:20 SEM DADOS (…)
   12:02:30 SEM DADOS (…)
   12:02:30 ALERTA: agente não responde há 3 ciclos
   12:02:50 utilização   0.0%  estado NORMAL

Critérios de sucesso

• O agente responde em authPriv e recusa authNoPriv, segredo errado e v2c.
• Nenhum segredo aparece na linha de comando nem nos registos da dupla; os ficheiros com segredos têm permissões 600.
• O alerta dispara só depois de 3 amostras acima de 80 % e desliga só depois de 2 abaixo de 70 %.
• A falta de resposta aparece como «SEM DADOS» e gera o alerta próprio; o script não inventa valores.
• A dupla escreve, para o alerta de utilização, a acção esperada e o responsável.

Como desfazer (reversão)

• Ctrl+C nas consolas M (monitor), C (agente) e D (iperf3, se ainda estiver à espera). Não usar pkill/killall.
• Verificar: sudo ip netns pids srv e sudo ip netns pids pc-adm não listam snmpd, iperf3 nem python3.
• rm -r /tmp/dpe-m11/l2 (apaga configurações, segredos fictícios e script). O serviço snmpd do sistema da VM não foi tocado.

Alternativa em papel: tarefas e respostas esperadas

Duas leituras de ifHCInOctets com 10 s de intervalo: 1 000 000 e 12 500 000. Capacidade declarada 10 Mbit/s. Calcule a utilização.

(12 500 000 − 1 000 000) × 8 / 10 = 9 200 000 bit/s = 9,2 Mbit/s → 92 %.

Sequência de utilizações (uma por ciclo): 85, 60, 90, 88, 83, 75, 72, 65, 68 %. Em que ciclo dispara e em que ciclo desliga o alerta, com as regras do caso?

Dispara no 5.º ciclo (90, 88, 83: três seguidas acima de 80 %; o 85 foi interrompido pelo 60). Os ciclos 6 e 7 (75, 72) não baixam de 70 %. Desliga no 9.º ciclo (65 e 68: duas seguidas abaixo de 70 %).

Porque não se usa SNMPv2c com a comunidade «public» nesta rede?

A comunidade vai em claro e é conhecida; qualquer pessoa na rede lê os dados e, se houver escrita, altera. SNMPv3 authPriv autentica o utilizador e cifra o conteúdo.

O script não conseguiu ler o agente durante 3 ciclos. Um colega quer mostrar «0 %» no painel nesses ciclos. Comente.

Errado: 0 % significaria ligação parada mas medida. A falta de dados é outro estado e deve gerar o alerta «agente não responde»; mostrar 0 % esconde o problema.

Verifique o que aprendeu

Questão 1

Para que serve a histerese (80 % para entrar em alerta, 70 % para sair)?

1. Para aumentar a largura de banda
2. Para evitar que o alerta ligue e desligue repetidamente quando o valor oscila perto do limiar
3. Para cifrar o SNMP
4. Para reduzir o número de OID

Questão 2

Qual o nível de segurança SNMPv3 que autentica e cifra?

1. noAuthNoPriv
2. authNoPriv
3. authPriv
4. v2c

Em leitura fácil

• A monitorização vigia a rede o tempo todo.
• O SNMP pergunta números aos equipamentos.
• Use a versão 3 com palavra-passe e cifra.
• O alerta só toca se o problema durar.
• Sem resposta não é zero: é outro alerta.
• Cada alerta deve dizer o que fazer e quem faz.

Fontes

• IETF RFC 3411/3414 — Arquitectura SNMP e modelo de segurança USM (SNMPv3) (https://www.rfc-editor.org/rfc/rfc3411)
• IETF RFC 2863 — The Interfaces Group MIB (IF-MIB) (https://www.rfc-editor.org/rfc/rfc2863)
• IETF RFC 3826 — The AES Cipher Algorithm in the SNMP User-based Security Model (https://www.rfc-editor.org/rfc/rfc3826)
• IETF RFC 7860 — HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3 (https://www.rfc-editor.org/rfc/rfc7860)
• Net-SNMP — manuais snmpd.conf(5), snmpget(1) (http://www.net-snmp.org/docs/man/)
• Python 3 — documentação oficial dos módulos json, csv, subprocess e statistics (https://docs.python.org/3/library/)
• iperf3 — documentação (ESnet) (https://software.es.net/iperf/)

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

• Explicar a estrutura de uma mensagem syslog (RFC 5424: facilidade, severidade, data, origem, programa, mensagem) e porque se centralizam os registos.
• Montar um receptor rsyslog de prática, isolado, que guarda um ficheiro por origem, e enviar-lhe eventos de r1 e r2.
• Analisar registos com um script que resume por origem e severidade e detecta falhas de autenticação repetidas, tratando linhas inválidas.
• Reconhecer limites: relógios dessincronizados, perda de mensagens em UDP, falta de autenticação e cifra no transporte, e retenção.

Syslog e centralização

Cada mensagem syslog tem facilidade (a origem lógica: kern, auth, daemon, local0…), severidade de 0 (emerg) a 7 (debug), data, nome ou endereço de quem enviou, programa e texto (RFC 5424). Guardar os registos só no próprio equipamento é arriscado: perdem-se se o equipamento avariar e quem o comprometer pode apagá-los. Um receptor central guarda cópias, permite comparar equipamentos na mesma linha temporal e aplicar regras de detecção (NIST SP 800-92).

Para comparar tempos, todos os relógios têm de estar sincronizados por NTP (RFC 5905; por exemplo com chrony). O receptor pode registar a hora a que recebeu (timegenerated) e a hora indicada pelo emissor (timereported); nesta prática usa-se a hora de recepção, porque todos os espaços de nomes partilham o relógio da VM. O syslog em UDP é simples mas pode perder mensagens sem aviso e não autentica nem cifra; em produção prefere-se TCP com TLS, suportado pelo rsyslog, numa rede de gestão.

Das linhas aos eventos

Ninguém lê milhares de linhas. Primeiro resume-se (quantos eventos por origem e severidade) para ver o que mudou; depois aplicam-se regras com critério explícito, por exemplo «5 ou mais falhas de autenticação da mesma origem em 60 s». O número vem da política: poucas falhas seguidas são típicas de engano humano; muitas em pouco tempo sugerem tentativa automática. Qualquer regra tem falsos positivos e falsos negativos; ajusta-se com o histórico e regista-se a justificação.

A análise trata linhas que não seguem o formato esperado sem parar e conta-as: um aumento de linhas inválidas também é um sinal (formato mudou, fonte nova, mensagem truncada). Registos contêm dados pessoais (utilizadores, endereços): define-se quem os lê e por quanto tempo se guardam.

Caso fictício

Na DPE (fictícia), um encaminhador da delegação reiniciou-se de madrugada e ninguém soube porquê: os registos estavam só no equipamento e perderam-se. O chefe aprova um receptor central na rede de gestão e pede uma regra para detectar tentativas repetidas de acesso aos encaminhadores. Todos os eventos são fictícios e gerados na aula.

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).
• Receptor: rsyslogd em primeiro plano no srv, num endereço extra 10.10.20.14/24 acrescentado só para esta lição, UDP 514, configuração própria em /tmp/dpe-m11/l3.
• Emissores: r1 (chega ao receptor como 10.10.20.1) e r2 (chega como 10.255.0.2, via rotas do módulo 3), com o comando logger.
• Não se altera o rsyslog do sistema da VM.

Passos

1. Pré-verificação (não altera nada): ferramentas presentes, rede DPE activa, delegação chega ao srv e a pasta de trabalho do módulo ainda não existe (se existir, pode ter dados de outra pessoa ou de outra lição: pare e confirme antes de continuar).

   for d in python3 git snmpget snmpwalk snmpd rsyslogd logger iperf3 sha256sum; do command -v $d >/dev/null || echo "Em falta: $d"; done
   ip netns list | grep -cE '^(pc-adm|srv|r1|r2|pc-del|isp)( |$)'
   sudo ip netns exec pc-del ping -c 2 10.10.20.53 | tail -2
   test -e /tmp/dpe-m11 && echo 'ATENÇÃO: /tmp/dpe-m11 já existe' || echo 'pasta livre'

   Saída de exemplo (didáctica):

   (nenhuma linha «Em falta»)
   6
   2 packets transmitted, 2 received, 0% packet loss
   pasta livre

2. Prepare pastas, configuração do receptor e o endereço extra do srv (confirme antes que 10.10.20.14 não está em uso).

   sudo ip netns exec srv ping -c 1 -W 1 10.10.20.14 >/dev/null && echo 'EM USO: parar' || echo 'livre'
   mkdir -p /tmp/dpe-m11/l3/registos /tmp/dpe-m11/l3/trabalho && cd /tmp/dpe-m11/l3
   cat > rsyslog.conf <<'EOF'
   global(workDirectory="/tmp/dpe-m11/l3/trabalho")
   module(load="imudp")
   input(type="imudp" address="10.10.20.14" port="514")
   template(name="PorOrigem" type="string" string="/tmp/dpe-m11/l3/registos/%fromhost-ip%.log")
   template(name="Linha" type="string" string="%timegenerated:::date-rfc3339% %fromhost-ip% %syslogseverity-text% %programname% %msg%\n")
   *.* action(type="omfile" dynaFile="PorOrigem" template="Linha")
   EOF
   sudo ip -n srv addr add 10.10.20.14/24 dev srv-r1

   Saída de exemplo (didáctica):

   livre

3. Consola F: valide a configuração e inicie o receptor em primeiro plano, com ficheiro de PID próprio.

   sudo rsyslogd -N1 -f /tmp/dpe-m11/l3/rsyslog.conf
   F: sudo ip netns exec srv rsyslogd -n -f /tmp/dpe-m11/l3/rsyslog.conf -i /tmp/dpe-m11/l3/rsyslogd.pid

   Saída de exemplo (didáctica):

   rsyslogd: version 8.2302.0, config validation run (level 1), master config /tmp/dpe-m11/l3/rsyslog.conf
   rsyslogd: End of config validation run. Bye.

4. Envie eventos fictícios: r2 avisa uma queda de ligação; r1 regista 6 falhas de autenticação da mesma origem em poucos segundos e uma gravação de configuração.

   sudo ip netns exec r2 logger -n 10.10.20.14 -P 514 -d --rfc5424 -t kernel -p kern.warning 'r2-r1: link down (simulado)'
   for i in 1 2 3 4 5 6; do sudo ip netns exec r1 logger -n 10.10.20.14 -P 514 -d --rfc5424 -t sshd -p auth.warning "Failed password for invalid user admin from 10.20.10.10 port 5012$i ssh2"; sleep 2; done
   sudo ip netns exec r1 logger -n 10.10.20.14 -P 514 -d --rfc5424 -t config -p local0.info 'configuracao gravada por tecnico1 (simulado)'
   ls registos/; tail -n 3 registos/10.10.20.1.log

   Saída de exemplo (didáctica):

   10.10.20.1.log  10.255.0.2.log
   2026-09-28T12:10:12.401+02:00 10.10.20.1 warning sshd  Failed password for invalid user admin from 10.20.10.10 port 50126 ssh2
   2026-09-28T12:10:13.020+02:00 10.10.20.1 info config  configuracao gravada por tecnico1 (simulado)
   (fuso e horas variam)

5. Acrescente uma linha estragada para testar a robustez e grave o script de análise (texto completo abaixo).

   echo 'linha sem formato' >> registos/10.10.20.1.log
   cat > analisar.py <<'EOF'
   #!/usr/bin/env python3
   """analisar.py — resumo de registos e detecção de falhas de autenticação repetidas.
   Uso: python3 analisar.py FICHEIRO [FICHEIRO ...]
   Formato (modelo «Linha» do rsyslog desta lição): DATA IP_ORIGEM SEVERIDADE PROGRAMA MENSAGEM
   Regra: 5 ou mais «Failed password» da mesma origem em 60 s -> ALERTA."""
   import collections, datetime, re, sys
   
   LIMIAR, JANELA = 5, datetime.timedelta(seconds=60)
   if len(sys.argv) < 2:
       sys.exit("Uso: python3 analisar.py FICHEIRO [FICHEIRO ...]")
   contagem, falhas = collections.Counter(), collections.defaultdict(list)
   invalidas = lidos = 0
   for nome in sys.argv[1:]:
       try:
           f = open(nome, encoding="utf-8", errors="replace")
       except OSError as e:
           print(f"ERRO: {e}", file=sys.stderr)
           continue
       lidos += 1
       with f:
           for linha in f:
               partes = linha.rstrip("\n").split(" ", 4)
               try:
                   quando = datetime.datetime.fromisoformat(partes[0])
                   origem, sev, prog, msg = partes[1:5]
               except (ValueError, IndexError):
                   invalidas += 1
                   continue
               contagem[(origem, sev)] += 1
               m = re.search(r"Failed password .* from (\S+)", msg)
               if prog == "sshd" and m:
                   falhas[m.group(1)].append(quando)
   if not lidos:
       sys.exit("Nenhum ficheiro lido.")
   print("Eventos por origem e severidade:")
   for (origem, sev), n in sorted(contagem.items()):
       print(f"  {origem:<12} {sev:<8} {n}")
   for ip, tempos in falhas.items():
       tempos.sort()
       for i in range(len(tempos) - LIMIAR + 1):
           if tempos[i + LIMIAR - 1] - tempos[i] <= JANELA:
               print(f"ALERTA: {LIMIAR}+ falhas de autenticação de {ip} em 60 s (desde {tempos[i]:%H:%M:%S})")
               break
   print(f"Linhas ignoradas por formato inválido: {invalidas}")
   EOF

6. Analise todos os ficheiros e também um ficheiro inexistente, para ver a mensagem de erro sem parar a análise.

   python3 analisar.py registos/*.log registos/nao-existe.log; echo "código=$?"

   Saída de exemplo (didáctica):

   ERRO: [Errno 2] No such file or directory: 'registos/nao-existe.log'
   Eventos por origem e severidade:
     10.10.20.1   info     1
     10.10.20.1   warning  6
     10.255.0.2   warning  1
   ALERTA: 5+ falhas de autenticação de 10.20.10.10 em 60 s (desde 12:10:02)
   Linhas ignoradas por formato inválido: 1
   código=0

7. Escreva a ficha da regra: critério, justificação, acção esperada (confirmar com o responsável de r1, ver se 10.20.10.10 é um posto conhecido, bloquear se não autorizado), responsável e retenção proposta dos registos.

   nano /tmp/dpe-m11/l3/regra-falhas.txt

Critérios de sucesso

• Existem dois ficheiros, um por origem, com as linhas no formato do modelo.
• O script conta 8 eventos válidos, ignora 1 linha inválida, avisa o ficheiro inexistente e emite o alerta das falhas.
• A dupla explica porque a regra usa a origem (10.20.10.10) e não o emissor (10.10.20.1).
• A ficha da regra tem critério, justificação, acção, responsável e retenção.

Como desfazer (reversão)

• Ctrl+C na consola F (receptor). Não usar pkill/killall. Confirmar: sudo ip netns pids srv não lista rsyslogd.
• sudo ip -n srv addr del 10.10.20.14/24 dev srv-r1
• rm -r /tmp/dpe-m11/l3 (registos fictícios, configuração, script). O rsyslog do sistema da VM não foi tocado.

Alternativa em papel: tarefas e respostas esperadas

Linhas de exemplo: falhas sshd de 10.20.10.10 às 12:10:02, :04, :06, :08, :10, :12. Com a regra «5 em 60 s», há alerta? E se as falhas fossem às 12:00, 12:02, 12:04, 12:06, 12:08?

Primeiro caso: sim, 5 falhas entre 12:10:02 e 12:10:10 (8 s). Segundo caso: não, as 5 falhas espalham-se por 8 minutos; nenhuma janela de 60 s tem 5.

Resuma por origem e severidade as linhas da saída de exemplo.

10.10.20.1: 6 warning (sshd) e 1 info (config). 10.255.0.2: 1 warning (kernel). Mais 1 linha inválida.

O relógio de r2 está 7 minutos adiantado e o receptor usa a hora do emissor. Que problema surge na investigação da queda?

Os eventos de r2 aparecem fora de ordem face aos de r1 e do servidor; conclusões de causa e efeito ficam erradas. Solução: NTP em todos os equipamentos e, na análise, saber que hora se está a usar.

Porque é perigoso guardar os registos só no próprio encaminhador?

Perdem-se com avaria ou reinício (como no caso) e quem comprometer o equipamento pode apagá-los. O receptor central guarda cópias com acesso controlado.

Verifique o que aprendeu

Questão 1

Qual é uma limitação do syslog sobre UDP?

1. Não tem severidade
2. Pode perder mensagens sem aviso e não autentica nem cifra
3. Só funciona em IPv6
4. Exige SNMPv3

Questão 2

Porque o script conta as linhas inválidas em vez de parar?

1. Para esconder erros
2. Para continuar a análise e mostrar que algo mudou no formato ou na fonte
3. Porque o Python não consegue parar
4. Para apagar as linhas

Em leitura fácil

• Os equipamentos escrevem mensagens chamadas registos.
• Guarde os registos num servidor central.
• Todos os relógios têm de ter a mesma hora.
• Um programa pode contar e procurar problemas nos registos.
• Muitas palavras-passe erradas em pouco tempo é um alerta.
• Os registos têm dados pessoais: guarde com cuidado.

Fontes

• IETF RFC 5424 — The Syslog Protocol (https://www.rfc-editor.org/rfc/rfc5424)
• IETF RFC 5905 — Network Time Protocol Version 4 (https://www.rfc-editor.org/rfc/rfc5905)
• NIST SP 800-92 — Guide to Computer Security Log Management (https://csrc.nist.gov/pubs/sp/800/92/final)
• rsyslog — documentação oficial (https://www.rsyslog.com/doc/)
• chrony — documentação oficial (https://chrony-project.org/documentation.html)
• Python 3 — documentação oficial dos módulos json, csv, subprocess e statistics (https://docs.python.org/3/library/)

Duração: 80 minutos (explicação 20, prática guiada 50, verificação 10). Resultados dos TdR trabalhados: Automação com scripts básicos; Continuidade e protecção de activos digitais.

Objectivos

• Explicar gestão de configurações: linha de base aprovada, controlo de alterações, detecção de desvios e registo de quem mudou o quê e quando.
• Exportar automaticamente o estado de r1 e r2 para ficheiros de texto versionados em git, com um script de shell com tratamento de erros.
• Detectar uma alteração não autorizada pela diferença no git e repor a linha de base, verificando depois.
• Fazer uma cópia de segurança com soma de verificação, testar a reposição e explicar a regra 3-2-1 e porque segredos não entram no repositório.

Linha de base, alterações e desvios

A linha de base é a configuração aprovada de cada equipamento. Qualquer mudança passa por um pedido: o quê, porquê, risco, plano de reversão, aprovação, execução e verificação. Um desvio é uma diferença entre o equipamento e a linha de base que não tem pedido aprovado — pode ser um erro, um remendo esquecido ou um ataque. O NIST SP 800-128 descreve este ciclo.

Exportar as configurações para texto e guardá-las num sistema de controlo de versões (git) dá histórico completo: cada exportação é um registo com data e autor, e 'git diff' mostra linha a linha o que mudou. Em equipamentos reais exporta-se a configuração do fabricante (por SSH, API ou ficheiro); nesta prática exportam-se endereços, rotas, regras nftables e filas.

Cópias de segurança que se conseguem repor

Uma cópia só vale se a reposição tiver sido testada. A regra 3-2-1 é uma prática corrente: 3 cópias, em 2 suportes diferentes, 1 fora do local. Uma soma de verificação (SHA-256) guardada com a cópia permite confirmar que o ficheiro não se estragou nem foi alterado. Os planos de contingência (NIST SP 800-34) definem o que se copia, com que frequência e em quanto tempo se tem de repor.

Configurações exportadas podem conter segredos (chaves, cadeias SNMP, palavras-passe). Esses segredos não entram no repositório: ficam num cofre, e o repositório tem regras de exclusão (.gitignore) e revisão antes de cada envio. O próprio repositório e as cópias têm acesso restrito, porque descrevem toda a rede.

Caso fictício

Na DPE (fictícia), numa sexta-feira a delegação deixou de chegar a um serviço e ninguém sabia o que tinha mudado. Descobriu-se depois uma rota acrescentada «para testar» e esquecida. O chefe aprova: exportação diária das configurações para git, verificação de desvios e cópia semanal com reposição testada. Todos os dados são fictícios.

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).
• Repositório: /tmp/dpe-m11/l4/configs (git, só na VM). Cópias: /tmp/dpe-m11/l4/copias. Teste de reposição: /tmp/dpe-m11/l4/reposicao.
• A alteração não autorizada é uma rota fictícia 10.99.0.0/24 no r1, acrescentada pelo formador e retirada na própria lição.

Passos

1. Pré-verificação (não altera nada): ferramentas presentes, rede DPE activa, delegação chega ao srv e a pasta de trabalho do módulo ainda não existe (se existir, pode ter dados de outra pessoa ou de outra lição: pare e confirme antes de continuar).

   for d in python3 git snmpget snmpwalk snmpd rsyslogd logger iperf3 sha256sum; do command -v $d >/dev/null || echo "Em falta: $d"; done
   ip netns list | grep -cE '^(pc-adm|srv|r1|r2|pc-del|isp)( |$)'
   sudo ip netns exec pc-del ping -c 2 10.10.20.53 | tail -2
   test -e /tmp/dpe-m11 && echo 'ATENÇÃO: /tmp/dpe-m11 já existe' || echo 'pasta livre'

   Saída de exemplo (didáctica):

   (nenhuma linha «Em falta»)
   6
   2 packets transmitted, 2 received, 0% packet loss
   pasta livre

2. Crie o repositório com identidade local (só para este repositório), a exclusão de segredos e o script de exportação (texto completo abaixo).

   sudo mkdir -p /tmp/dpe-m11/l4/configs /tmp/dpe-m11/l4/copias && cd /tmp/dpe-m11/l4
   sudo git -C configs init -q && sudo git -C configs config user.name 'Tecnico Pratica' && sudo git -C configs config user.email 'ti@dpe.example'
   printf '*.segredo\n*.key\n' | sudo tee configs/.gitignore >/dev/null
   sudo tee exportar.sh >/dev/null <<'EOF'
   #!/bin/sh
   # exportar.sh — exporta o estado de r1 e r2 para texto e regista no git (rede de prática DPE).
   # Uso: sudo sh /tmp/dpe-m11/l4/exportar.sh      Só lê os equipamentos; nunca os altera.
   set -eu
   DEST=/tmp/dpe-m11/l4/configs
   [ "$(id -u)" = 0 ] || { echo "ERRO: executar com sudo." >&2; exit 1; }
   [ -d "$DEST/.git" ] || { echo "ERRO: repositório $DEST não existe (ver passo 2)." >&2; exit 1; }
   for n in r1 r2; do
     ip netns list | awk '{print $1}' | grep -qx "$n" || { echo "ERRO: espaço de nomes $n não existe." >&2; exit 1; }
     mkdir -p "$DEST/$n"
     # o sufixo @ifN muda sempre que a rede é recriada; retira-se para não gerar falsas diferenças
     ip -n "$n" -br addr show | sed 's/@[^ ]*//' > "$DEST/$n/enderecos.txt"
     ip -n "$n" route show > "$DEST/$n/rotas.txt"
     ip netns exec "$n" nft list ruleset > "$DEST/$n/nftables.txt"
     ip netns exec "$n" tc qdisc show > "$DEST/$n/filas.txt"
   done
   cd "$DEST"
   git add -A
   if git diff --cached --quiet; then
     echo "Sem alterações desde a última exportação."
   else
     git commit -qm "Exportação $(date '+%F %T') por ${SUDO_USER:-root}"
     echo "Alterações registadas:"
     git show --stat --format='%h %s' HEAD
   fi
   EOF

3. Primeira exportação: é a linha de base aprovada.

   sudo sh exportar.sh
   sudo git -C configs log --oneline

   Saída de exemplo (didáctica):

   Alterações registadas:
   3f2a1c0 Exportação 2026-09-28 12:20:05 por formando
    .gitignore         | 2 ++
    r1/enderecos.txt   | 5 +++++
    r1/rotas.txt       | 5 +++++
    …
    9 files changed, …
   3f2a1c0 Exportação 2026-09-28 12:20:05 por formando

4. Repita sem mudanças: o script não cria registos vazios.

   sudo sh exportar.sh

   Saída de exemplo (didáctica):

   Sem alterações desde a última exportação.

5. Formador (sem avisar): acrescenta uma rota não autorizada. Formandos: exportem e vejam a diferença.

   Formador: sudo ip -n r1 route add 10.99.0.0/24 via 10.255.0.2
   sudo sh exportar.sh
   sudo git -C configs diff HEAD~1 -- r1/rotas.txt

   Saída de exemplo (didáctica):

   Alterações registadas:
   8b7e9d2 Exportação 2026-09-28 12:24:40 por formando
    r1/rotas.txt | 1 +
   +10.99.0.0/24 via 10.255.0.2 dev r1-r2

6. Sem pedido aprovado para esta rota: reponha a linha de base (retirar a rota), exporte e confirme que o estado volta a ser igual à linha de base.

   sudo ip -n r1 route del 10.99.0.0/24 via 10.255.0.2
   sudo sh exportar.sh
   sudo git -C configs diff $(sudo git -C configs rev-list --max-parents=0 HEAD) HEAD -- r1/ r2/ && echo 'igual à linha de base'

   Saída de exemplo (didáctica):

   Alterações registadas:
   c41d5aa Exportação 2026-09-28 12:26:02 por formando
    r1/rotas.txt | 1 -
   igual à linha de base

7. Teste do tratamento de erros: sem sudo o script recusa e termina com código 1 (a verificação do repositório em falta funciona da mesma forma).

   sh exportar.sh; echo "código=$?"

   Saída de exemplo (didáctica):

   ERRO: executar com sudo.
   código=1

8. Cópia de segurança com soma SHA-256 e teste de reposição numa pasta separada.

   cd /tmp/dpe-m11/l4 && sudo tar -czf copias/configs-$(date +%F).tar.gz -C /tmp/dpe-m11/l4 configs
   cd copias && sudo sh -c 'sha256sum configs-*.tar.gz > SHA256SUMS' && sha256sum -c SHA256SUMS
   sudo mkdir -p ../reposicao && sudo tar -xzf configs-*.tar.gz -C ../reposicao
   sudo diff -r ../configs ../reposicao/configs && echo 'reposição idêntica'
   sudo git -C ../reposicao/configs log --oneline | wc -l

   Saída de exemplo (didáctica):

   configs-2026-09-28.tar.gz: OK
   reposição idêntica
   3

Critérios de sucesso

• O histórico git tem a linha de base, o desvio e a reposição, cada um com data e autor.
• A diferença mostra exactamente a rota 10.99.0.0/24; depois da reposição, r1 e r2 estão iguais à linha de base.
• O script recusa correr sem sudo e não cria registos quando nada mudou.
• A soma SHA-256 confere e a reposição é idêntica, com o histórico completo.
• A dupla explica a regra 3-2-1 e onde ficariam as outras duas cópias numa instituição real.

Como desfazer (reversão)

• Confirmar que a rota de teste não ficou: sudo ip -n r1 route show 10.99.0.0/24 não deve mostrar nada (se mostrar: sudo ip -n r1 route del 10.99.0.0/24 via 10.255.0.2).
• Guardar o que for preciso fora da VM e depois: sudo rm -r /tmp/dpe-m11/l4 (repositório, cópias e reposição, todos só da lição).

Alternativa em papel: tarefas e respostas esperadas

Interprete esta diferença do git em r1/rotas.txt: «+10.99.0.0/24 via 10.255.0.2 dev r1-r2» e «-10.20.10.0/24 via 10.255.0.2 dev r1-r2». Que impacto tem e o que faz?

Foi acrescentada uma rota para 10.99.0.0/24 e retirada a rota para a delegação 10.20.10.0/24: a sede deixou de chegar à delegação. Verificar se há pedido aprovado; se não, repor a linha de base (repor a rota da delegação, retirar a nova), exportar e confirmar.

Escreva um pedido de alteração para acrescentar legitimamente uma rota nova no r1.

O quê: rota X via Y em r1. Porquê: serviço/pedido. Risco: afectar o encaminhamento existente. Janela: data e hora. Reversão: comando para retirar a rota. Verificação: ping/traceroute e exportação para git. Aprovação: responsável de TI. Executor: nome.

A cópia semanal existe há um ano, mas nunca foi reposta. O que falta e porquê?

Falta testar a reposição (e verificar a soma): sem isso não se sabe se a cópia está completa, legível ou se o procedimento funciona dentro do tempo exigido.

Um colega quer guardar no repositório o ficheiro com a palavra-passe SNMPv3 «para ter tudo junto». Responda.

Não: o histórico git guarda para sempre qualquer segredo que lá entre, e o repositório é partilhado. Segredos no cofre; o repositório tem .gitignore para *.segredo/*.key e revisão antes de cada registo.

Verifique o que aprendeu

Questão 1

O que é um desvio de configuração?

1. Uma rota com métrica alta
2. Uma diferença entre o estado do equipamento e a linha de base que não tem alteração aprovada
3. Uma cópia de segurança antiga
4. Um erro de sintaxe no git

Questão 2

Porque se calcula e guarda uma soma SHA-256 com cada cópia?

1. Para cifrar a cópia
2. Para confirmar mais tarde que o ficheiro está íntegro, sem corrupção nem alteração
3. Para comprimir mais
4. Para dispensar o teste de reposição

Em leitura fácil

• Guarde a configuração aprovada de cada equipamento.
• Um programa exporta a configuração todos os dias.
• O git mostra o que mudou, quando e quem.
• Uma mudança sem autorização volta atrás.
• Uma cópia só serve se já a experimentou repor.
• Palavras-passe não entram no git.

Fontes

• NIST SP 800-128 — Guide for Security-Focused Configuration Management of Information Systems (https://csrc.nist.gov/pubs/sp/800/128/upd1/final)
• NIST SP 800-34 Rev. 1 — Contingency Planning Guide (https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final)
• Git — documentação oficial (https://git-scm.com/doc)
• 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)
• Projecto nftables — wiki oficial (https://wiki.nftables.org/)
• Debian 12 «bookworm» — Manual de Segurança e pacotes oficiais (https://www.debian.org/doc/manuals/securing-debian-manual/)

Duração: 80 minutos (explicação 20, prática guiada 50, verificação 10). Resultados dos TdR trabalhados: Conceber, configurar e administrar redes pequenas, médias e grandes; LAN, WAN, WLAN, virtualização e nuvem; Trabalho em equipa, projectos, ética e confidencialidade.

Objectivos

• Explicar planeamento de capacidade: medir a utilização, resumir com percentis, projectar a tendência e decidir a tempo, tendo em conta prazos de contratação.
• Recolher amostras de débito a partir dos contadores de uma interface e comparar média, percentil 95 e máximo.
• Projectar com regressão linear o mês em que a utilização atinge um limiar justificado, e explicar os limites da projecção.
• Relacionar a capacidade com novos serviços, crescimento de utilizadores e requisitos de continuidade.

Medir e resumir sem esconder picos

A média de um mês esconde os picos que os utilizadores sentem. O percentil 95 (p95) é o valor abaixo do qual ficam 95 % das amostras: ignora os 5 % mais altos, que podem ser picos breves, mas mostra a carga das horas de maior uso. Muitos operadores facturam pelo p95 de amostras de 5 minutos; a instituição deve saber como o seu contrato calcula. O resultado depende do intervalo das amostras: amostras longas alisam os picos.

Um limiar de planeamento, por exemplo p95 a 70 % da capacidade, deixa margem para picos, crescimento imprevisto e uma ligação alternativa com menos capacidade em caso de falha. O número justifica-se: acima de cerca de 80 % sustentado as filas e o atraso crescem (módulo 10), e a contratação de mais capacidade demora meses; por isso decide-se antes de chegar lá.

Projectar e decidir

Com pelo menos seis a doze meses de p95 mensal, uma regressão linear dá a tendência (Mbit/s por mês) e o mês em que se atinge o limiar. É uma extrapolação: não prevê um novo serviço, a mudança de horário, a entrada de mais funcionários ou uma aplicação que passa para a nuvem. Por isso junta-se à tendência o calendário de projectos conhecidos e repete-se a análise todos os trimestres.

A decisão conta para trás a partir do mês previsto: tempo de aprovação orçamental, concurso, instalação pelo operador e testes. Se tudo isso demorar oito meses e o limiar for atingido em dez, a decisão é agora. O relatório indica os dados usados, o método, o resultado e as incertezas.

Caso fictício

A WAN da DPE (fictícia) tem 20 Mbit/s contratados. O chefe tem de propor no orçamento se aumenta a capacidade. A equipa tem 12 meses de p95 mensal (fictícios) e mede, na rede de prática, como média e p95 diferem num dia com um pico curto. Aprovação e contratação demoram, em conjunto, cerca de 7 meses (valor fictício). Todos os valores são fictícios.

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).
• Medição: contadores de saída da interface r1-r2 (sentido sede → delegação), lidos com ip -j -s link no espaço de nomes r1.
• Carga: iperf3 -R (o srv envia para o pc-del) em três fases: 2 Mbit/s durante 50 s, 8 Mbit/s durante 20 s, 2 Mbit/s durante 50 s.
• Limite: amostras de 5 s numa rede virtual durante 2 minutos servem para comparar resumos, não representam um dia real.

Passos

1. Pré-verificação (não altera nada): ferramentas presentes, rede DPE activa, delegação chega ao srv e a pasta de trabalho do módulo ainda não existe (se existir, pode ter dados de outra pessoa ou de outra lição: pare e confirme antes de continuar).

   for d in python3 git snmpget snmpwalk snmpd rsyslogd logger iperf3 sha256sum; do command -v $d >/dev/null || echo "Em falta: $d"; done
   ip netns list | grep -cE '^(pc-adm|srv|r1|r2|pc-del|isp)( |$)'
   sudo ip netns exec pc-del ping -c 2 10.10.20.53 | tail -2
   test -e /tmp/dpe-m11 && echo 'ATENÇÃO: /tmp/dpe-m11 já existe' || echo 'pasta livre'

   Saída de exemplo (didáctica):

   (nenhuma linha «Em falta»)
   6
   2 packets transmitted, 2 received, 0% packet loss
   pasta livre

2. Crie a pasta e grave os dois scripts e a série mensal fictícia (textos completos abaixo).

   mkdir -p /tmp/dpe-m11/l5 && cd /tmp/dpe-m11/l5
   cat > recolher.py <<'EOF'
   #!/usr/bin/env python3
   """recolher.py — amostras do débito de saída de r1-r2 (rede de prática DPE).
   Uso: sudo python3 recolher.py N_AMOSTRAS INTERVALO_S SAIDA.csv     Só lê contadores."""
   import csv, json, statistics, subprocess, sys, time
   
   def bytes_tx():
       r = subprocess.run(["ip", "-n", "r1", "-j", "-s", "link", "show", "dev", "r1-r2"],
                          capture_output=True, text=True, check=True, timeout=5)
       return json.loads(r.stdout)[0]["stats64"]["tx"]["bytes"]
   
   try:
       n, intervalo, saida = int(sys.argv[1]), float(sys.argv[2]), sys.argv[3]
       assert n >= 2 and intervalo > 0
   except (IndexError, ValueError, AssertionError):
       sys.exit("Uso: sudo python3 recolher.py N_AMOSTRAS(>=2) INTERVALO_S SAIDA.csv")
   try:
       amostras, antes, t0 = [], bytes_tx(), time.monotonic()
       for i in range(n):
           time.sleep(intervalo)
           agora, t1 = bytes_tx(), time.monotonic()
           mbps = (agora - antes) * 8 / (t1 - t0) / 1e6
           amostras.append(round(mbps, 2))
           print(f"amostra {i + 1:>2}: {mbps:5.2f} Mbit/s", flush=True)
           antes, t0 = agora, t1
   except (subprocess.CalledProcessError, subprocess.TimeoutExpired, KeyError, json.JSONDecodeError) as e:
       sys.exit(f"ERRO ao ler contadores de r1-r2: {e}")
   try:
       with open(saida, "w", newline="") as f:
           csv.writer(f).writerows([["amostra", "mbps"]] + [[i + 1, v] for i, v in enumerate(amostras)])
   except OSError as e:
       sys.exit(f"ERRO ao escrever {saida}: {e}")
   p95 = statistics.quantiles(amostras, n=20, method="inclusive")[18]
   print(f"média {statistics.mean(amostras):.2f} | percentil 95 {p95:.2f} | máximo {max(amostras):.2f} Mbit/s")
   EOF
   cat > prever.py <<'EOF'
   #!/usr/bin/env python3
   """prever.py — tendência linear do percentil 95 mensal e mês em que atinge o limiar.
   Uso: python3 prever.py MENSAL.csv CAPACIDADE_MBPS LIMIAR(0-1)
   Aviso: extrapolação linear; só indica quando rever, não garante o futuro."""
   import csv, statistics, sys
   
   try:
       ficheiro, cap, limiar = sys.argv[1], float(sys.argv[2]), float(sys.argv[3])
       assert cap > 0 and 0 < limiar <= 1
   except (IndexError, ValueError, AssertionError):
       sys.exit("Uso: python3 prever.py MENSAL.csv CAPACIDADE_MBPS LIMIAR(0-1)")
   try:
       with open(ficheiro, newline="") as f:
           linhas = [(int(r["mes"]), float(r["p95_mbps"])) for r in csv.DictReader(f)]
   except (OSError, KeyError, ValueError) as e:
       sys.exit(f"ERRO a ler {ficheiro}: {e}")
   if len(linhas) < 6:
       sys.exit("São precisos pelo menos 6 meses de dados para uma tendência minimamente útil.")
   x, y = zip(*linhas)
   r = statistics.linear_regression(x, y)
   alvo = cap * limiar
   print(f"{len(linhas)} meses; tendência {r.slope:+.2f} Mbit/s por mês; último valor {y[-1]:.1f} Mbit/s")
   if r.slope <= 0:
       print("Sem crescimento na tendência: rever no próximo ciclo.")
   else:
       mes = (alvo - r.intercept) / r.slope
       print(f"Limiar {limiar:.0%} de {cap:g} Mbit/s = {alvo:.1f} Mbit/s; atingido por volta do mês {mes:.1f} "
             f"(cerca de {mes - x[-1]:.0f} meses depois do último dado)")
   EOF
   cat > mensal.csv <<'EOF'
   mes,p95_mbps
   1,6.1
   2,6.4
   3,6.8
   4,7.0
   5,7.5
   6,7.9
   7,8.2
   8,8.6
   9,9.1
   10,9.4
   11,9.8
   12,10.3
   EOF

3. Consola D: servidor iperf3 que aceita vários testes (esperar «Server listening»; pára-se com Ctrl+C no fim). Consola R: inicie a recolha de 24 amostras de 5 s. Logo a seguir, consola B: as três fases de carga.

   D: sudo ip netns exec srv iperf3 -s -B 10.10.20.53
   R: sudo python3 recolher.py 24 5 amostras.csv
   B: for f in '2M 50' '8M 20' '2M 50'; do set -- $f; sudo ip netns exec pc-del iperf3 -c 10.10.20.53 -R -b $1 -t $2 >/dev/null || echo 'ERRO no iperf3'; done

   Saída de exemplo (didáctica):

   amostra  1:  2.07 Mbit/s
   …
   amostra 11:  8.31 Mbit/s
   …
   amostra 24:  2.06 Mbit/s
   média 3.12 | percentil 95 8.31 | máximo 8.36 Mbit/s
   (a primeira e a última amostra podem apanhar o início ou o fim das fases; os valores variam)

4. Teste do tratamento de erros: argumentos inválidos.

   sudo python3 recolher.py 1 5 x.csv; echo "código=$?"
   python3 prever.py nao-existe.csv 20 0.7; echo "código=$?"

   Saída de exemplo (didáctica):

   Uso: sudo python3 recolher.py N_AMOSTRAS(>=2) INTERVALO_S SAIDA.csv
   código=1
   ERRO a ler nao-existe.csv: [Errno 2] No such file or directory: 'nao-existe.csv'
   código=1

5. Projecção com a série mensal fictícia: capacidade 20 Mbit/s, limiar 70 %.

   python3 prever.py mensal.csv 20 0.7

   Saída de exemplo (didáctica):

   12 meses; tendência +0.38 Mbit/s por mês; último valor 10.3 Mbit/s
   Limiar 70% de 20 Mbit/s = 14.0 Mbit/s; atingido por volta do mês 22.0 (cerca de 10 meses depois do último dado)

6. Escreva a recomendação para o orçamento: dados, método, resultado, prazo de decisão (10 meses − 7 de contratação), riscos (serviços novos, falha da ligação alternativa) e data da próxima revisão.

   nano /tmp/dpe-m11/l5/recomendacao.txt

Critérios de sucesso

• A dupla mostra que a média (≈ 3,1 Mbit/s) esconde o pico que o p95 (≈ 8,3 Mbit/s) revela.
• Os scripts terminam com mensagem clara e código 1 perante argumentos ou ficheiros inválidos.
• A projecção indica o mês ≈ 22 e a dupla calcula que a decisão tem de ser tomada até cerca de 3 meses depois do último dado.
• A recomendação distingue dados, projecção e incertezas, e marca a próxima revisão.

Como desfazer (reversão)

• Ctrl+C na consola D (servidor iperf3) e na consola R se a recolha não tiver terminado. Não usar pkill/killall. Confirmar: sudo ip netns pids srv não lista iperf3.
• rm -r /tmp/dpe-m11/l5 (scripts, dados fictícios e amostras). Se for a última lição do módulo nesta VM: rm -r /tmp/dpe-m11.

Alternativa em papel: tarefas e respostas esperadas

Amostras (Mbit/s) de 20 intervalos: dezasseis de 2, e quatro de 9. Calcule a média e diga qual valor representa melhor as horas de maior uso numa ligação de 10 Mbit/s.

Média = (16 × 2 + 4 × 9) / 20 = 3,4 Mbit/s. O p95 (9 Mbit/s, pois os 4 valores altos são 20 % das amostras) mostra que nas horas de maior uso a ligação está a 90 %; a média de 34 % dá uma ideia errada.

Com a tendência de +0,38 Mbit/s por mês e 10,3 Mbit/s no mês 12, estime o p95 aos meses 18 e 24 (use a recta: 5,61 + 0,38 × mês).

Mês 18: 5,61 + 0,38 × 18 ≈ 12,5 Mbit/s. Mês 24: ≈ 14,8 Mbit/s, acima do limiar de 14 Mbit/s (70 % de 20).

O limiar é atingido cerca de 10 meses após o último dado; aprovação e contratação levam 7 meses. Até quando se tem de decidir? Que riscos podem antecipar a data?

Até cerca de 3 meses após o último dado. Riscos: novos serviços (videoconferência, sistemas na nuvem), mais funcionários na delegação, cópias de segurança maiores, ou necessidade de a ligação alternativa aguentar a carga numa falha.

Um colega diz: «a regressão prova que em 22 meses chegamos a 14 Mbit/s». Corrija.

A regressão só extrapola a tendência passada; não prova nada sobre o futuro. Indica quando rever e decidir; a análise repete-se todos os trimestres e junta os projectos conhecidos.

Verifique o que aprendeu

Questão 1

Porque se usa o percentil 95 em vez da média para planear capacidade?

1. Porque é sempre mais baixo
2. Porque mostra a carga das horas de maior uso sem ser dominado por poucos picos muito breves
3. Porque o SNMP só dá percentis
4. Porque dispensa amostras

Questão 2

Qual é o principal limite de uma projecção por regressão linear?

1. Só funciona com IPv6
2. Assume que o futuro segue a tendência passada e não prevê serviços novos ou mudanças de uso
3. Exige 100 anos de dados
4. Não usa números

Em leitura fácil

• Planear capacidade é ver se a ligação vai chegar no futuro.
• A média esconde as horas de muito uso.
• O percentil 95 mostra melhor essas horas.
• Uma linha de tendência ajuda a ver quando a ligação vai encher.
• Comprar mais ligação demora meses: decida cedo.
• A previsão não é certa: reveja muitas vezes.

Fontes

• Python 3 — documentação oficial dos módulos json, csv, subprocess e statistics (https://docs.python.org/3/library/)
• 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)
• iperf3 — documentação (ESnet) (https://software.es.net/iperf/)
• IETF RFC 2863 — The Interfaces Group MIB (IF-MIB) (https://www.rfc-editor.org/rfc/rfc2863)
• NIST SP 800-34 Rev. 1 — Contingency Planning Guide (https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final)

Duração: 70 minutos (explicação 20, prática guiada 40, verificação 10). Resultados dos TdR trabalhados: IDS/IPS, ACL e segmentação; Protecção de dados e identidades: MFA e cifra.

Objectivos

• Explicar controlo de acessos na rede: identidade, autorização por função, menor privilégio, negação por omissão e segmentação como camadas complementares.
• Escrever e aplicar, na rede de prática, um conjunto de regras nftables que só permite o que está autorizado, com contadores para evidência.
• Substituir a autenticação por palavra-passe num serviço SSH de prática por chave, e explicar o papel do segundo factor e da cifra na protecção de identidades.
• Recolher evidência de que uma regra funciona (contador, teste positivo e teste negativo) e distinguir «não consegui ligar» de «está bloqueado pela regra».

Quem, a quê e como

Controlo de acessos responde a três perguntas: quem é (identidade autenticada), a que pode aceder (autorização) e em que condições (rede, horário, equipamento). O menor privilégio dá a cada pessoa ou sistema apenas o necessário para a sua função, durante o tempo necessário. A negação por omissão inverte a lógica: tudo é recusado excepto o que está expressamente autorizado, o que torna os esquecimentos seguros em vez de perigosos.

A segmentação (módulos 4 e 8) limita quem chega a quê ao nível da rede; a autenticação limita quem entra no serviço. São camadas diferentes: uma regra de firewall não sabe quem é a pessoa, só de onde vem o pacote; a autenticação não impede que alguém chegue à porta do serviço. O modelo de confiança zero (NIST SP 800-207) parte do princípio de que estar «dentro da rede» não é credencial.

Identidades e provas

Palavras-passe sozinhas são o elo mais fraco: são reutilizadas, adivinhadas e experimentadas em massa. Chaves criptográficas para acesso administrativo (SSH) e um segundo factor para o acesso das pessoas reduzem muito o risco (NIST SP 800-63B; TOTP no RFC 6238). A cifra do canal protege as credenciais em trânsito; sem ela, qualquer captura na rede as revela (módulo 9, lição 2).

Uma regra só está verificada quando há evidência: o teste que deve passar passa, o teste que deve falhar falha, e o contador da regra mostra os pacotes. Sem o teste negativo pode estar a funcionar por acaso; sem o contador não se sabe qual regra actuou. Um tempo de espera esgotado pode ser bloqueio, serviço parado ou rota em falta: confirma-se sempre com o contador ou com a captura.

Caso fictício

Na DPE (fictícia), qualquer computador da delegação chega a qualquer porta do servidor e a administração faz-se por SSH com palavra-passe partilhada entre três técnicos. O chefe aprova por escrito, para a rede de prática: a delegação só acede ao serviço web; a administração por SSH só a partir do posto de administração e só com chave; tudo o resto recusado, com registo. Todos os dados, chaves e endereços são fictícios.

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).
• Âmbito autorizado: apenas os espaços de nomes acima. Nada fora deles.
• Serviços de prática no srv: servidor web (porto 80) e um servidor SSH próprio no porto 22, iniciado em primeiro plano com configuração e chaves criadas na aula em /tmp/dpe-m12/l1 (não é o SSH do sistema da VM).
• Regras: tabela nftables «m12acessos» no r1, criada e removida nesta lição.
• Nota sobre a VM de preparação: instalar openssh-server no Debian pode activar o serviço ssh do sistema, normalmente em todas as interfaces da VM. Não se presume: na preparação verifica-se só com leitura (systemctl is-active ssh; sudo ss -tlnp 'sport = :22'; sudo nft list ruleset) e regista-se na ficha da VM, com os pacotes instalados. Esta lição não altera nem reinicia esse serviço; o servidor de prática corre dentro do srv, com pilha de rede própria.

Passos

1. Pré-verificação e âmbito (não altera nada): confirme as ferramentas, a rede de prática e que a pasta do módulo está livre. Leia em voz alta a declaração de âmbito: «os testes desta aula só se aplicam aos espaços de nomes da rede de prática; qualquer outro endereço está fora do âmbito autorizado». Todos os comandos de teste começam por «ip netns exec <nome>»: um comando sem esse prefixo sairia da rede de prática e não deve ser executado.

   for d in nmap nft python3 ssh ssh-keygen sshd git; do command -v $d >/dev/null || echo "Em falta: $d"; done
   ip netns list | grep -cE '^(pc-adm|srv|r1|r2|pc-del|isp)( |$)'
   sudo ip netns exec pc-adm ping -c 2 10.10.20.53 | tail -1
   test -e /tmp/dpe-m12 && echo 'ATENÇÃO: /tmp/dpe-m12 já existe' || echo 'pasta livre'

   Saída de exemplo (didáctica):

   (nenhuma linha «Em falta»)
   6
   rtt min/avg/max/mdev = 0.05/0.07/0.09/0.02 ms
   pasta livre

2. Prepare a pasta, as chaves do servidor SSH de prática e uma chave de utilizador para o pc-adm (frases de acesso vazias: são chaves descartáveis de aula, apagadas na reversão).

   mkdir -p /tmp/dpe-m12/l1 && cd /tmp/dpe-m12/l1
   ssh-keygen -q -t ed25519 -f hospedeiro_ed25519 -N ''
   ssh-keygen -q -t ed25519 -f tecnico_ed25519 -C 'tecnico-pratica' -N ''
   cp tecnico_ed25519.pub authorized_keys
   chmod 600 hospedeiro_ed25519 tecnico_ed25519 authorized_keys

3. Escreva a configuração do servidor SSH de prática (sem palavra-passe, só chave) e valide a sintaxe.

   cat > sshd-pratica.conf <<'EOF'
   Port 22
   ListenAddress 10.10.20.53
   HostKey /tmp/dpe-m12/l1/hospedeiro_ed25519
   PidFile /tmp/dpe-m12/l1/sshd.pid
   PasswordAuthentication no
   KbdInteractiveAuthentication no
   PermitRootLogin prohibit-password
   PubkeyAuthentication yes
   AuthorizedKeysFile /tmp/dpe-m12/l1/authorized_keys
   LogLevel VERBOSE
   # StrictModes no: só na prática, porque os ficheiros ficam em /tmp (pasta partilhada) e o sshd recusaria o caminho; em produção manter StrictModes yes
   StrictModes no
   EOF
   test -d /run/sshd && echo '/run/sshd existe' || { sudo install -d -m 755 /run/sshd && echo '/run/sshd criado nesta lição' | tee /tmp/dpe-m12/l1/criado-run-sshd; }
   sudo /usr/sbin/sshd -t -f /tmp/dpe-m12/l1/sshd-pratica.conf && echo sintaxe-ok

   Saída de exemplo (didáctica):

   /run/sshd existe
   sintaxe-ok

4. Consolas C e D: servidor web e servidor SSH de prática, ambos em primeiro plano dentro do srv (esperar «Serving HTTP» e «Server listening on 10.10.20.53 port 22»).

   C: sudo ip netns exec srv python3 -m http.server 80 --bind 10.10.20.53
   D: sudo ip netns exec srv /usr/sbin/sshd -D -e -f /tmp/dpe-m12/l1/sshd-pratica.conf

   Saída de exemplo (didáctica):

   Serving HTTP on 10.10.20.53 port 80 …
   Server listening on 10.10.20.53 port 22.

5. Antes das regras: mostre que a delegação chega ao SSH do servidor (situação actual, indesejada). O objectivo é só ver que a porta responde.

   sudo ip netns exec pc-del nmap -Pn -p 22,80 10.10.20.53

   Saída de exemplo (didáctica):

   PORT   STATE SERVICE
   22/tcp open  ssh
   80/tcp open  http

6. Aplique as regras de controlo de acessos no r1 (texto completo abaixo) e confirme que ficaram activas.

   cat > /tmp/dpe-m12/l1/acessos.nft <<'EOF'
   table inet m12acessos {
     chain fwd {
       type filter hook forward priority 0; policy drop;
       ct state established,related accept
       # gestão: só o posto de administração fala com o srv em SSH
       iifname "r1-pc-adm" ip saddr 10.10.10.10 ip daddr 10.10.20.53 tcp dport 22 counter accept comment "gestao-ssh"
       # utilizadores da delegação: só o serviço web do srv
       iifname "r1-r2" ip saddr 10.20.10.0/24 ip daddr 10.10.20.53 tcp dport 80 counter accept comment "delegacao-web"
       # diagnóstico: eco ICMP permitido de e para a rede de prática
       icmp type { echo-request, echo-reply } counter accept comment "diagnostico"
       counter comment "recusado"
     }
   }
   EOF
   sudo ip netns exec r1 nft -f /tmp/dpe-m12/l1/acessos.nft
   sudo ip netns exec r1 nft list table inet m12acessos | head -n 6

   Saída de exemplo (didáctica):

   table inet m12acessos {
     chain fwd {
       type filter hook forward priority filter; policy drop;
       ct state established,related accept
       iifname "r1-pc-adm" ip saddr 10.10.10.10 ip daddr 10.10.20.53 tcp dport 22 counter packets 0 bytes 0 accept comment "gestao-ssh"
       …

7. Testes positivos (devem passar): web a partir da delegação; SSH com chave a partir do posto de administração.

   sudo ip netns exec pc-del curl -s -o /dev/null -w '%{http_code}\n' http://10.10.20.53/
   sudo ip netns exec pc-adm ssh -i /tmp/dpe-m12/l1/tecnico_ed25519 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/tmp/dpe-m12/l1/known_hosts $(id -un)@10.10.20.53 'echo ligado-com-chave'

   Saída de exemplo (didáctica):

   200
   Warning: Permanently added '10.10.20.53' (ED25519) to the list of known hosts.
   ligado-com-chave

8. Testes negativos (devem falhar): SSH a partir da delegação e SSH sem chave a partir do posto de administração.

   sudo ip netns exec pc-del nmap -Pn -p 22 --host-timeout 20s 10.10.20.53
   sudo ip netns exec pc-adm ssh -o BatchMode=yes -o PreferredAuthentications=password -o PubkeyAuthentication=no -o StrictHostKeyChecking=no -o UserKnownHostsFile=/tmp/dpe-m12/l1/known_hosts $(id -un)@10.10.20.53 'echo nao-devia-aparecer'

   Saída de exemplo (didáctica):

   22/tcp filtered ssh
   Permission denied (publickey).

9. Evidência: contadores das regras. Confirme que o tempo esgotado do teste anterior corresponde à regra «recusado» e não a um serviço parado.

   sudo ip netns exec r1 nft list table inet m12acessos | grep -E 'comment|counter'

   Saída de exemplo (didáctica):

   … counter packets 4 bytes 320 accept comment "gestao-ssh"
   … counter packets 12 bytes 1440 accept comment "delegacao-web"
   … counter packets 6 bytes 504 accept comment "diagnostico"
   … counter packets 3 bytes 180 comment "recusado"
   (o contador «recusado» cresceu durante o teste negativo: é a evidência do bloqueio)

10. Escreva a ficha de evidência: regra, teste positivo, teste negativo, contador antes e depois, data, quem executou e âmbito autorizado.

    nano /tmp/dpe-m12/l1/evidencias.txt

Critérios de sucesso

• A delegação acede ao serviço web e não ao SSH; o posto de administração acede ao SSH só com chave.
• O acesso por palavra-passe é recusado com «Permission denied (publickey)».
• Cada regra tem teste positivo, teste negativo e contador registados na ficha de evidência.
• A dupla explica a diferença entre «filtered» (bloqueado antes de chegar) e «closed» (chegou, serviço não responde nessa porta).
• Nenhum comando foi executado fora dos espaços de nomes da rede de prática.

Como desfazer (reversão)

• sudo ip netns exec r1 nft delete table inet m12acessos
• Ctrl+C nas consolas C (web) e D (SSH de prática). Não usar pkill/killall. Confirmar: sudo ip netns pids srv não lista python3 nem sshd.
• Se a pasta /run/sshd foi criada nesta lição (existe /tmp/dpe-m12/l1/criado-run-sshd) e o serviço ssh do sistema não estiver instalado, pode retirá-la com sudo rmdir /run/sshd; caso contrário, deixá-la.
• rm -r /tmp/dpe-m12/l1 (chaves descartáveis, configuração, regras e evidências; guardar antes o que for preciso).
• Verificar: sudo ip netns exec r1 nft list tables não mostra m12acessos; o serviço SSH do sistema da VM não foi tocado.

Alternativa em papel: tarefas e respostas esperadas

Escreva, por palavras, as quatro regras da política do caso, começando pela negação por omissão.

1) Por omissão, recusar todo o encaminhamento. 2) Aceitar ligações já estabelecidas. 3) Aceitar SSH (porto 22) só de 10.10.10.10 para 10.10.20.53. 4) Aceitar web (porto 80) só de 10.20.10.0/24 para 10.10.20.53. Mais o eco ICMP para diagnóstico, com contador em todas.

Com a saída de exemplo, diga o que prova cada evidência do teste negativo.

«22/tcp filtered» mostra que o pacote não obteve resposta nem recusa: foi descartado no caminho. O contador «recusado» a subir 3 pacotes prova que foi a regra por omissão do r1, e não um serviço parado ou uma rota em falta.

Um técnico pede acesso SSH ao servidor a partir da delegação «durante esta semana, para um trabalho». O que faz?

Pedido escrito e aprovado com justificação, endereço de origem concreto, porto, prazo e reversão; regra específica com comentário e data; registo no controlo de alterações (módulo 11, lição 4); no fim do prazo, retirar a regra e confirmar com teste negativo. Nunca abrir a toda a rede da delegação nem sem prazo.

Porque a chave SSH não substitui o segundo factor no acesso das pessoas aos sistemas?

A chave protege o acesso administrativo ao equipamento, mas se o portátil do técnico for comprometido a chave vai com ele. Para as pessoas, o segundo factor (por exemplo um código temporário) acrescenta uma prova independente; para as chaves, protege-se o ficheiro com frase de acesso e limita-se a origem.

Verifique o que aprendeu

Questão 1

O que significa negação por omissão numa política de acessos?

1. Recusar o acesso a quem falha a palavra-passe
2. Recusar tudo o que não estiver expressamente autorizado
3. Negar o acesso fora do horário
4. Apagar as regras antigas

Questão 2

Um teste de porta devolveu «filtered» e o contador «recusado» subiu. O que se conclui?

1. O serviço está avariado
2. A regra de recusa do encaminhador bloqueou o pacote
3. A rota está em falta
4. A chave SSH expirou

Em leitura fácil

• Cada pessoa só deve aceder ao que precisa.
• Tudo o que não está autorizado fica bloqueado.
• A administração do servidor usa uma chave, não uma palavra-passe.
• Teste o que deve funcionar e o que não deve funcionar.
• Guarde a prova de cada teste.
• Só se testa a rede de prática da aula.

Fontes

• Projecto nftables — wiki oficial (https://wiki.nftables.org/)
• OpenSSH — manuais sshd_config(5) e ssh-keygen(1) (https://www.openssh.com/manual.html)
• IETF RFC 4253 — SSH Transport Layer Protocol (https://www.rfc-editor.org/rfc/rfc4253)
• IETF RFC 6238 — TOTP: Time-Based One-Time Password (https://www.rfc-editor.org/rfc/rfc6238)
• NIST SP 800-63B — Digital Identity Guidelines: Authentication (https://pages.nist.gov/800-63-4/sp800-63b.html)
• NIST SP 800-207 — Zero Trust Architecture (https://csrc.nist.gov/pubs/sp/800/207/final)
• Nmap Reference Guide (https://nmap.org/book/man.html)
• IETF RFC 1918 — Address Allocation for Private Internets (https://www.rfc-editor.org/rfc/rfc1918)
• IETF RFC 5737 — IPv4 Address Blocks Reserved for Documentation (https://www.rfc-editor.org/rfc/rfc5737)

Duração: 75 minutos (explicação 20, prática guiada 45, verificação 10). Resultados dos TdR trabalhados: Segurança desde a concepção; Identificar vulnerabilidades e aplicar mitigação.

Objectivos

• Explicar o endurecimento de equipamentos de rede: plano de gestão protegido, serviços mínimos, parâmetros seguros, credenciais únicas, registos centralizados, hora certa e actualizações.
• Verificar um encaminhador de prática com uma lista de verificação automática, só de leitura, que devolve OK/FALHA com o valor obtido e o esperado.
• Aplicar correcções justificadas (parâmetros do núcleo, retirada de serviço desnecessário, cadeia de entrada com negação por omissão) e repetir a verificação como reteste.
• Explicar a gestão de vulnerabilidades dos equipamentos: inventário de versões, avisos do fabricante, identificadores CVE e janelas de actualização.

Proteger o próprio equipamento

Um encaminhador ou comutador comprometido compromete toda a rede que passa por ele. Segurança desde a concepção significa começar pela configuração mínima: desligar serviços não usados (páginas web de gestão antigas, telnet, SNMP v1/v2c), permitir a gestão só a partir da rede de gestão e por protocolos cifrados (SSH, SNMPv3), trocar todas as credenciais de fábrica por credenciais únicas guardadas em cofre, enviar registos para o receptor central e sincronizar a hora (módulo 11).

Há também parâmetros de encaminhamento a endurecer. O filtro de caminho inverso (rp_filter) descarta pacotes com endereço de origem impossível para a interface de entrada, dificultando a falsificação de origem; em redes com encaminhamento assimétrico pode descartar tráfego legítimo, por isso escolhe-se com conhecimento da topologia. Redirecções ICMP permitem a outro equipamento alterar a tabela de encaminhamento e normalmente desactivam-se num encaminhador. No Linux, para o rp_filter conta o maior valor entre «all» e o da interface; a lista desta lição verifica só «all», o que é uma simplificação declarada.

Vulnerabilidades e actualizações

Os fabricantes publicam avisos de segurança; cada vulnerabilidade conhecida recebe um identificador CVE e, muitas vezes, uma pontuação CVSS que resume a gravidade técnica, não o risco na instituição. A gestão de actualizações (NIST SP 800-40) começa pelo inventário de modelos e versões (módulo 11, lição 1), acompanha os avisos, avalia a exposição de cada equipamento, testa, aplica numa janela aprovada com plano de reversão e confirma.

Uma lista de verificação só vale se cada item tiver um valor esperado justificado, se correr sem alterar nada e se for repetida depois da correcção (reteste). Um OK significa «este item, neste momento, tem o valor esperado»; não significa que o equipamento esteja seguro em geral.

Caso fictício

Na DPE (fictícia), o encaminhador da sede (r1 na rede de prática) foi instalado há anos: tem uma página de gestão antiga sem cifra no porto 8080, parâmetros de fábrica e nenhuma protecção de entrada. O chefe aprova uma verificação e as correcções na rede de prática, para depois preparar a mudança real com pedido de alteração. Todos os dados são fictícios.

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).
• Âmbito autorizado: apenas os espaços de nomes acima; alvo desta lição: o r1.
• Serviço desnecessário simulado: servidor web em primeiro plano no r1, porto 8080, iniciado pelo formador para representar a página de gestão antiga.
• Correcções: parâmetros sysctl dentro do espaço de nomes r1 (não afectam a VM) e tabela nftables «m12equip» no r1.
• Nota: esta lista pressupõe o r1 da rede base, sem FRR. Se o r1 correr FRR (módulos 3 e 5), há serviços à escuta legítimos: ajustar o valor esperado e justificá-lo.

Passos

1. Pré-verificação e âmbito (não altera nada): confirme as ferramentas, a rede de prática e que a pasta do módulo está livre. Leia em voz alta a declaração de âmbito: «os testes desta aula só se aplicam aos espaços de nomes da rede de prática; qualquer outro endereço está fora do âmbito autorizado». Todos os comandos de teste começam por «ip netns exec <nome>»: um comando sem esse prefixo sairia da rede de prática e não deve ser executado.

   for d in nmap nft python3 ssh ssh-keygen sshd git; do command -v $d >/dev/null || echo "Em falta: $d"; done
   ip netns list | grep -cE '^(pc-adm|srv|r1|r2|pc-del|isp)( |$)'
   sudo ip netns exec pc-adm ping -c 2 10.10.20.53 | tail -1
   test -e /tmp/dpe-m12 && echo 'ATENÇÃO: /tmp/dpe-m12 já existe' || echo 'pasta livre'

   Saída de exemplo (didáctica):

   (nenhuma linha «Em falta»)
   6
   rtt min/avg/max/mdev = 0.05/0.07/0.09/0.02 ms
   pasta livre

2. Formador, consola F: inicie o serviço desnecessário simulado no r1 (esperar «Serving HTTP»).

   F: sudo ip netns exec r1 python3 -m http.server 8080 --bind 0.0.0.0 --directory /usr/share/doc/nftables

   Saída de exemplo (didáctica):

   Serving HTTP on 0.0.0.0 port 8080 (http://0.0.0.0:8080/) ...

3. Guarde os valores iniciais dos parâmetros (para poder repor) e grave a lista de verificação (texto completo abaixo).

   mkdir -p /tmp/dpe-m12/l2 && cd /tmp/dpe-m12/l2
   for k in net.ipv4.conf.all.rp_filter net.ipv4.conf.all.accept_redirects net.ipv4.conf.all.send_redirects; do echo "$k=$(sudo ip netns exec r1 sysctl -n $k)"; done | tee valores-iniciais.txt
   cat > verificar-r1.sh <<'EOF'
   #!/bin/sh
   # verificar-r1.sh — lista de verificação SÓ DE LEITURA do encaminhador r1 (rede de prática DPE).
   # Uso: sudo sh verificar-r1.sh     Código de saída: 0 sem falhas, 1 com falhas, 2 erro de execução.
   set -u
   [ "$(id -u)" = 0 ] || { echo "ERRO: executar com sudo." >&2; exit 2; }
   ip netns list | awk '{print $1}' | grep -qx r1 || { echo "ERRO: espaço de nomes r1 não existe." >&2; exit 2; }
   falhas=0
   verif() {  # descrição, valor obtido, valor esperado
     if [ "$2" = "$3" ]; then echo "OK     $1 ($2)"
     else echo "FALHA  $1 (obtido: $2; esperado: $3)"; falhas=$((falhas + 1)); fi
   }
   s() { ip netns exec r1 sysctl -n "$1" 2>/dev/null || echo "?"; }
   verif "Filtro de caminho inverso, rp_filter (all)" "$(s net.ipv4.conf.all.rp_filter)" 1
   verif "Não aceitar redirecções ICMP (all)" "$(s net.ipv4.conf.all.accept_redirects)" 0
   verif "Não enviar redirecções ICMP (all)" "$(s net.ipv4.conf.all.send_redirects)" 0
   verif "Não aceitar encaminhamento pela origem (all)" "$(s net.ipv4.conf.all.accept_source_route)" 0
   verif "Serviços à escuta no r1 (TCP/UDP)" "$(ip netns exec r1 ss -Htuln | wc -l)" 0
   pol=$(ip netns exec r1 nft list chain inet m12equip entrada 2>/dev/null | grep -o 'policy [a-z]*' || echo "sem-cadeia")
   verif "Política da cadeia de entrada do r1" "$pol" "policy drop"
   echo "Total de falhas: $falhas"
   [ "$falhas" -eq 0 ]
   EOF

   Saída de exemplo (didáctica):

   net.ipv4.conf.all.rp_filter=0
   net.ipv4.conf.all.accept_redirects=1
   net.ipv4.conf.all.send_redirects=1
   (os valores iniciais num espaço de nomes novo podem variar com a versão do núcleo; guarde os que vir)

4. Verificação inicial (só leitura). Complete com a visão de um terceiro: o que o posto de administração vê aberto no r1.

   sudo sh verificar-r1.sh; echo "código=$?"
   sudo ip netns exec pc-adm nmap -Pn -p 22,23,80,161,8080 10.10.10.1

   Saída de exemplo (didáctica):

   FALHA  Filtro de caminho inverso, rp_filter (all) (obtido: 0; esperado: 1)
   FALHA  Não aceitar redirecções ICMP (all) (obtido: 1; esperado: 0)
   FALHA  Não enviar redirecções ICMP (all) (obtido: 1; esperado: 0)
   OK     Não aceitar encaminhamento pela origem (all) (0)
   FALHA  Serviços à escuta no r1 (TCP/UDP) (obtido: 1; esperado: 0)
   FALHA  Política da cadeia de entrada do r1 (obtido: sem-cadeia; esperado: policy drop)
   Total de falhas: 5
   código=1
   8080/tcp open  http-proxy
   22/tcp closed ssh  (e restantes closed)

5. Classifique cada falha (gravidade, justificação, correcção) na folha de remediação antes de corrigir.

   nano /tmp/dpe-m12/l2/remediacao.txt

6. Correcções: parâmetros do núcleo no r1; retirada do serviço desnecessário (Ctrl+C na consola F); cadeia de entrada com negação por omissão (texto completo abaixo).

   sudo ip netns exec r1 sysctl -w net.ipv4.conf.all.rp_filter=1 net.ipv4.conf.all.accept_redirects=0 net.ipv4.conf.all.send_redirects=0
   F: Ctrl+C
   cat > equip.nft <<'EOF'
   table inet m12equip {
     chain entrada {
       type filter hook input priority 0; policy drop;
       iifname "lo" accept
       ct state established,related accept
       icmp type { echo-request, destination-unreachable, time-exceeded } counter accept comment "diagnostico"
       iifname "r1-pc-adm" ip saddr 10.10.10.10 tcp dport 22 counter accept comment "gestao-ssh-futura"
       counter comment "entrada-recusada"
     }
   }
   EOF
   sudo ip netns exec r1 nft -f equip.nft

   Saída de exemplo (didáctica):

   net.ipv4.conf.all.rp_filter = 1
   net.ipv4.conf.all.accept_redirects = 0
   net.ipv4.conf.all.send_redirects = 0

7. Reteste: a mesma lista e a mesma visão de terceiro. Confirme também que o encaminhamento continua a funcionar (a cadeia de entrada não afecta o tráfego que atravessa o r1).

   sudo sh verificar-r1.sh; echo "código=$?"
   sudo ip netns exec pc-adm nmap -Pn -p 22,23,80,161,8080 10.10.10.1
   sudo ip netns exec pc-del ping -c 2 10.10.20.53 | tail -1

   Saída de exemplo (didáctica):

   OK     Filtro de caminho inverso, rp_filter (all) (1)
   OK     Não aceitar redirecções ICMP (all) (0)
   OK     Não enviar redirecções ICMP (all) (0)
   OK     Não aceitar encaminhamento pela origem (all) (0)
   OK     Serviços à escuta no r1 (TCP/UDP) (0)
   OK     Política da cadeia de entrada do r1 (policy drop)
   Total de falhas: 0
   código=0
   8080/tcp filtered http-proxy  (e restantes filtered)
   rtt min/avg/max/mdev = 0.06/0.07/0.08/0.01 ms

8. Exercício de vulnerabilidades (em papel, com dados fictícios): o inventário diz que o encaminhador real tem o sistema versão 4.2.1; o aviso fictício do fabricante DPE-SA-2026-07 afecta 4.0 a 4.2.3 na página de gestão web, corrigido em 4.2.4. Preencha a ficha de decisão.

   nano /tmp/dpe-m12/l2/ficha-vulnerabilidade.txt

Critérios de sucesso

• A verificação inicial mostra 5 falhas com valor obtido e esperado; o reteste mostra 0 falhas e código 0.
• O visto de terceiro passa de 8080 «open» para «filtered», e o encaminhamento continua a funcionar.
• A folha de remediação tem, para cada falha, gravidade, justificação e correcção, preenchida antes de corrigir.
• A ficha de vulnerabilidade indica exposição, medida provisória (desligar a página de gestão), actualização numa janela aprovada e reteste.

Como desfazer (reversão)

• sudo ip netns exec r1 nft delete table inet m12equip
• Repor os valores iniciais guardados, um a um: por exemplo sudo ip netns exec r1 sysctl -w net.ipv4.conf.all.rp_filter=0 (usar os valores de /tmp/dpe-m12/l2/valores-iniciais.txt).
• Confirmar que a consola F já não tem o servidor web (Ctrl+C feito) e que sudo ip netns pids r1 não lista python3.
• rm -r /tmp/dpe-m12/l2. Nada foi alterado fora do espaço de nomes r1.

Alternativa em papel: tarefas e respostas esperadas

Para cada falha da verificação inicial de exemplo, indique gravidade (alta/média/baixa), porquê e a correcção.

Página de gestão sem cifra em 8080: alta (credenciais em claro, superfície de ataque) — retirar o serviço. Sem cadeia de entrada: alta — negação por omissão com excepções para diagnóstico e gestão. rp_filter 0: média — activar, confirmando que não há encaminhamento assimétrico. Aceitar redirecções: média — desactivar. Enviar redirecções: baixa — desactivar. (Outras gradações são aceitáveis se justificadas.)

Ficha de decisão para o aviso fictício DPE-SA-2026-07 (versão 4.2.1 afectada; correcção em 4.2.4).

Afectado: sim (4.2.1 está entre 4.0 e 4.2.3). Exposição: a página de gestão web está activa? Se sim, medida provisória imediata: desligá-la ou limitá-la à rede de gestão. Correcção: actualizar para 4.2.4 numa janela aprovada, com cópia da configuração e plano de reversão. Reteste: confirmar versão e que a página não está exposta. Registo no inventário.

Um colega diz: «a lista deu 0 falhas, o encaminhador está seguro». Corrija.

Quer dizer só que os 6 itens verificados têm o valor esperado neste momento. Não cobre versões vulneráveis, credenciais, registos, hora, cópias de configuração, nem itens que a lista não inclui; e só verifica «all» no rp_filter.

Porque se guardam os valores iniciais antes de corrigir?

Para poder repor exactamente o estado anterior se a correcção causar problemas (plano de reversão) e para documentar a diferença antes/depois como evidência.

Verifique o que aprendeu

Questão 1

Porque se retira uma página de gestão web antiga sem cifra de um encaminhador?

1. Porque ocupa largura de banda
2. Porque expõe credenciais em claro e aumenta a superfície de ataque sem necessidade
3. Porque o nmap a detecta
4. Porque impede o encaminhamento

Questão 2

O que significa um resultado «OK» numa lista de verificação automática?

1. Que o equipamento está seguro
2. Que aquele item tinha o valor esperado no momento da verificação
3. Que não há vulnerabilidades CVE
4. Que a auditoria terminou

Em leitura fácil

• Os equipamentos de rede também precisam de protecção.
• Desligue os serviços que não são usados.
• A gestão faz-se só a partir de computadores autorizados.
• Uma lista automática verifica cada ponto.
• Depois de corrigir, verifique outra vez.
• Actualize os equipamentos quando o fabricante avisar.

Fontes

• NIST SP 800-40 Rev. 4 — Enterprise Patch Management Planning (https://csrc.nist.gov/pubs/sp/800/40/r4/final)
• NIST SP 800-41 Rev. 1 — Guidelines on Firewalls and Firewall Policy (https://csrc.nist.gov/pubs/sp/800/41/r1/final)
• NIST SP 800-128 — Guide for Security-Focused Configuration Management of Information Systems (https://csrc.nist.gov/pubs/sp/800/128/upd1/final)
• FIRST — Common Vulnerability Scoring System (CVSS) v4.0 Specification (https://www.first.org/cvss/v4-0/specification-document)
• Programa CVE — Common Vulnerabilities and Exposures (https://www.cve.org/)
• 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)
• Nmap Reference Guide (https://nmap.org/book/man.html)

Duração: 75 minutos (explicação 20, prática guiada 45, verificação 10). Resultados dos TdR trabalhados: Identificar vulnerabilidades e aplicar mitigação; Avaliações básicas de segurança e auditoria técnica; Trabalho em equipa, projectos, ética e confidencialidade.

Objectivos

• Distinguir descoberta, varrimento de portas, identificação de versões, análise de vulnerabilidades e teste de intrusão, e situar cada um no processo do NIST SP 800-115.
• Preparar e assinar uma autorização de teste com âmbito, testes permitidos, janela, executantes e confidencialidade, antes de qualquer comando.
• Executar um varrimento autorizado na rede de prática, guardar a evidência e comparar com a linha de base esperada.
• Classificar cada achado como indício, confirmado ou falso positivo, com a verificação que o suporta, e produzir um plano de remediação com prioridades e reteste.

Tipos de teste e limites legais e éticos

Descoberta identifica que equipamentos existem; varrimento de portas mostra que portas respondem; identificação de versões tenta saber que programa e versão atendem; análise de vulnerabilidades compara o que se encontrou com listas de falhas conhecidas; teste de intrusão tenta explorar falhas para demonstrar impacto. Cada nível é mais intrusivo e exige autorização mais explícita. O NIST SP 800-115 descreve planeamento, execução, análise e relatório.

Sem autorização escrita, um varrimento contra sistemas de terceiros é uma intrusão não autorizada, com consequências disciplinares e legais. A autorização define o âmbito (endereços exactos), o que é permitido e proibido, a janela, quem executa, quem é o contacto durante o teste e as regras de confidencialidade dos resultados. Nesta aula o âmbito são apenas os espaços de nomes da rede de prática, com endereços reservados para documentação (RFC 1918 e RFC 5737). Resultados de testes são informação sensível: guardam-se com acesso restrito e apagam-se quando deixam de ser necessários.

Indício não é vulnerabilidade confirmada

Uma ferramenta diz o que observou, muitas vezes por inferência. «Porta 80 aberta» é facto observado; «servidor X versão Y» é inferência a partir de respostas e pode enganar; «versão Y é vulnerável ao CVE-…» é hipótese que depende da versão real, das opções activas e das correcções aplicadas pela distribuição, que às vezes mantém o número de versão. Por isso cada achado é classificado: indício (a ferramenta sugere), confirmado (verificado por outra via: configuração, inventário, teste controlado dentro do âmbito) ou falso positivo (verificação mostra que não se aplica).

Um varrimento também não vê tudo: portas filtradas podem esconder serviços, um serviço pode estar parado no momento, e a ferramenta não conhece configurações internas nem permissões. Um relatório honesto diz o que foi testado, quando, com que ferramenta e parâmetros, e o que ficou por cobrir. A remediação prioriza por exposição e impacto no serviço, não pela ordem em que os achados apareceram, e termina sempre com reteste.

Caso fictício

A DPE (fictícia) vai receber uma auditoria externa. O chefe pede à equipa um teste interno prévio, apenas na rede de prática, para saber o que está exposto no servidor e nos encaminhadores e preparar correcções. Uma dupla é a equipa de teste; outra prepara a autorização e a verificação dos achados. Todos os dados são fictícios.

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).
• Âmbito autorizado (repetido em cada comando pelo prefixo ip netns exec): apenas os espaços de nomes da rede de prática.
• Alvos: srv (10.10.20.53) e r1 (10.10.10.1 e 10.255.0.1). Posto de teste: pc-adm.
• Serviços de exercício iniciados na aula no srv: web no porto 80 e um serviço de texto no porto 2323 (simula um serviço de gestão antigo, sem cifra).
• Limite: o varrimento vê apenas o que responde no momento; não substitui a revisão de configuração nem o inventário de versões.

Passos

1. Pré-verificação e âmbito (não altera nada): confirme as ferramentas, a rede de prática e que a pasta do módulo está livre. Leia em voz alta a declaração de âmbito: «os testes desta aula só se aplicam aos espaços de nomes da rede de prática; qualquer outro endereço está fora do âmbito autorizado». Todos os comandos de teste começam por «ip netns exec <nome>»: um comando sem esse prefixo sairia da rede de prática e não deve ser executado.

   for d in nmap nft python3 ssh ssh-keygen sshd git; do command -v $d >/dev/null || echo "Em falta: $d"; done
   ip netns list | grep -cE '^(pc-adm|srv|r1|r2|pc-del|isp)( |$)'
   sudo ip netns exec pc-adm ping -c 2 10.10.20.53 | tail -1
   test -e /tmp/dpe-m12 && echo 'ATENÇÃO: /tmp/dpe-m12 já existe' || echo 'pasta livre'

   Saída de exemplo (didáctica):

   (nenhuma linha «Em falta»)
   6
   rtt min/avg/max/mdev = 0.05/0.07/0.09/0.02 ms
   pasta livre

2. Preencha e assine a autorização de teste (texto completo abaixo). Nenhum comando de varrimento antes disto. Leia em voz alta a lista de endereços do âmbito.

   mkdir -p /tmp/dpe-m12/l3 && cd /tmp/dpe-m12/l3
   cat > autorizacao.txt <<'EOF'
   AUTORIZAÇÃO DE TESTE TÉCNICO (exercício de aula — documento fictício)
   Instituição: Direcção Provincial de Exemplo (DPE), fictícia.
   Âmbito autorizado: SÓ os espaços de nomes da rede de prática desta VM:
     10.10.10.0/24, 10.10.20.0/24, 10.20.10.0/24, 10.255.0.0/30, 203.0.113.0/24.
   Fora do âmbito (proibido): qualquer outro endereço, a rede da instituição,
     a Internet, e o sistema da VM fora dos espaços de nomes.
   Testes permitidos: descoberta de equipamentos e portas, identificação de
     serviços e versões. NÃO permitido: exploração, ataques de negação de
     serviço, tentativas de adivinhar palavras-passe, alteração de dados.
   Janela: durante esta sessão de formação, com o formador presente.
   Executantes: ____________________  Data: ____________
   Autoriza (formador/responsável): ____________________
   Confidencialidade: os resultados são do exercício, não se divulgam fora da
     turma e são apagados no fim (VM descartável).
   EOF
   nano autorizacao.txt

3. Consolas C e D: serviços de exercício no srv (esperar «Serving HTTP» e a consola ficar ocupada no segundo).

   C: sudo ip netns exec srv python3 -m http.server 80 --bind 10.10.20.53
   D: sudo ip netns exec srv python3 -c "import socketserver,socket;socketserver.TCPServer.allow_reuse_address=True;s=socketserver.TCPServer(('10.10.20.53',2323),socketserver.BaseRequestHandler);print('gestao-antiga a escutar em 2323',flush=True);s.serve_forever()"

   Saída de exemplo (didáctica):

   Serving HTTP on 10.10.20.53 port 80 …
   gestao-antiga a escutar em 2323

4. Etapa 1 — descoberta na rede do servidor (só ping ARP/ICMP, sem portas).

   sudo ip netns exec pc-adm nmap -sn 10.10.20.0/24 -oN descoberta.txt
   tail -n 4 descoberta.txt

   Saída de exemplo (didáctica):

   Nmap scan report for 10.10.20.1
   Host is up (0.00018s latency).
   Nmap scan report for 10.10.20.53
   Nmap done: 256 IP addresses (2 hosts up) scanned in 2.31 seconds

5. Etapa 2 — portas mais comuns no srv, com registo em ficheiro.

   sudo ip netns exec pc-adm nmap -Pn --top-ports 100 10.10.20.53 -oN portas-srv.txt
   grep -E '^[0-9]+/tcp' portas-srv.txt

   Saída de exemplo (didáctica):

   80/tcp   open  http
   (as restantes portas do top 100 aparecem como closed e não são listadas individualmente)

6. Etapa 3 — portas não habituais: o serviço antigo não está no top 100. Varra o intervalo acordado.

   sudo ip netns exec pc-adm nmap -Pn -p 1-3000 10.10.20.53 -oN portas-srv-1-3000.txt
   grep -E '^[0-9]+/tcp +open' portas-srv-1-3000.txt

   Saída de exemplo (didáctica):

   80/tcp   open  http
   2323/tcp open  3d-nfsd
   (o nome do serviço vem da lista de portas conhecidas do nmap: é um palpite, não uma identificação)

7. Etapa 4 — identificação de versões apenas nas portas encontradas (mais intrusivo: permitido pela autorização).

   sudo ip netns exec pc-adm nmap -Pn -sV -p 80,2323 10.10.20.53 -oN versoes-srv.txt
   grep -E '^[0-9]+/tcp' versoes-srv.txt

   Saída de exemplo (didáctica):

   80/tcp   open  http    SimpleHTTPServer 0.6 (Python 3.11.2)
   2323/tcp open  unknown
   (o nmap não identificou o serviço de 2323: fica como indício por esclarecer)

8. Etapa 5 — varrimento do encaminhador e comparação com a linha de base (o r1 deve ter os serviços mínimos da lição 2).

   sudo ip netns exec pc-adm nmap -Pn -p 1-1024 10.10.10.1 -oN portas-r1.txt
   grep -cE '^[0-9]+/tcp +open' portas-r1.txt

   Saída de exemplo (didáctica):

   0
   (nenhuma porta aberta no r1: coerente com a linha de base)

9. Verificação dos achados a partir do próprio alvo (outra via, dentro do âmbito): que processos estão à escuta no srv?

   sudo ip netns exec srv ss -tlnp

   Saída de exemplo (didáctica):

   LISTEN 0 5 10.10.20.53:80   0.0.0.0:* users:(("python3",pid=2311,fd=3))
   LISTEN 0 5 10.10.20.53:2323 0.0.0.0:* users:(("python3",pid=2318,fd=3))
   (confirma as duas portas e mostra que o «3d-nfsd» era só um palpite do nome)

10. Preencha a tabela de achados (indício/confirmado/falso positivo, com a verificação) e o plano de remediação com prioridade, responsável, prazo e reteste.

    nano /tmp/dpe-m12/l3/achados.txt
    nano /tmp/dpe-m12/l3/remediacao.txt

Critérios de sucesso

• A autorização está preenchida e assinada antes do primeiro varrimento, e todos os comandos correram dentro dos espaços de nomes.
• Cada etapa deixou ficheiro de evidência com data, ferramenta e parâmetros.
• A tabela classifica: porta 80 aberta (confirmado), porta 2323 aberta (confirmado), «3d-nfsd» (falso positivo do nome), «SimpleHTTPServer 0.6» (indício, confirmado pelo ss), r1 sem portas abertas (confirmado, coerente com a linha de base).
• O plano de remediação prioriza o serviço sem cifra do porto 2323 e prevê reteste com o mesmo comando.
• A dupla nomeia pelo menos duas coisas que o varrimento não cobriu.

Como desfazer (reversão)

• Ctrl+C nas consolas C e D. Não usar pkill/killall. Confirmar: sudo ip netns pids srv não lista python3.
• Os ficheiros de resultado são sensíveis: mostrar ao formador, e depois rm -r /tmp/dpe-m12/l3.
• Nada foi alterado nos alvos: as etapas só observaram (nenhum comando de exploração foi executado).

Alternativa em papel: tarefas e respostas esperadas

Classifique, com justificação, estes quatro achados de exemplo: (a) 80/tcp open; (b) 2323/tcp open «3d-nfsd»; (c) «SimpleHTTPServer 0.6 (Python 3.11.2)»; (d) r1 sem portas abertas.

(a) Confirmado: a porta respondeu e o ss mostra o processo. (b) Porta aberta: confirmado; o nome «3d-nfsd»: falso positivo, vem da lista de portas conhecidas. (c) Indício, depois confirmado pelo ss no alvo; note-se que versões anunciadas podem enganar. (d) Confirmado para as portas 1-1024 no momento do teste; não prova que não haja portas acima de 1024.

Escreva o plano de remediação para o serviço de gestão antiga no porto 2323.

Prioridade alta (serviço de gestão sem cifra, acessível à rede). Medida imediata: limitar o acesso à rede de gestão por regra de firewall. Correcção: substituir por acesso cifrado (SSH) e desligar o serviço antigo. Responsável: equipa de redes. Prazo: fictício, por exemplo 15 dias. Reteste: repetir «nmap -Pn -p 2323» e confirmar «filtered» ou serviço ausente, e registar a evidência.

Um formando quer testar «só um bocadinho» um servidor da instituição, fora da rede de prática. Responda.

Não. Está fora do âmbito autorizado; seria uma intrusão não autorizada, com consequências disciplinares e legais, e pode perturbar serviços reais. Se houver necessidade, pede-se autorização escrita própria, com âmbito, janela e contacto.

Indique três limitações a escrever no relatório deste teste.

Só foram varridas as portas TCP indicadas (não todas, nem UDP); só se viu o que respondia naquele momento; não houve revisão de configurações, permissões, contas nem versões instaladas; não se testou exploração, por isso o impacto real não foi demonstrado.

Verifique o que aprendeu

Questão 1

A ferramenta diz «2323/tcp open 3d-nfsd». O que se pode afirmar?

1. Que há um serviço 3d-nfsd vulnerável
2. Que a porta 2323 respondeu; o nome é apenas o palpite da lista de portas conhecidas
3. Que o servidor está comprometido
4. Nada, o resultado é inútil

Questão 2

O que tem de existir antes de qualquer varrimento?

1. Uma cópia de segurança
2. Autorização escrita com âmbito, testes permitidos, janela e contactos
3. Um servidor de registos
4. Um relatório preliminar

Em leitura fácil

• Nunca teste uma rede sem autorização escrita.
• A autorização diz que endereços pode testar.
• Primeiro veja que computadores existem.
• Depois veja que portas respondem.
• O que a ferramenta diz pode estar errado: confirme.
• Escreva o que encontrou, como corrigir e quando vai verificar de novo.

Fontes

• NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment (https://csrc.nist.gov/pubs/sp/800/115/final)
• NIST SP 800-30 Rev. 1 — Guide for Conducting Risk Assessments (https://csrc.nist.gov/pubs/sp/800/30/r1/final)
• FIRST — Common Vulnerability Scoring System (CVSS) v4.0 Specification (https://www.first.org/cvss/v4-0/specification-document)
• Programa CVE — Common Vulnerabilities and Exposures (https://www.cve.org/)
• Nmap Reference Guide (https://nmap.org/book/man.html)
• 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)
• IETF RFC 1918 — Address Allocation for Private Internets (https://www.rfc-editor.org/rfc/rfc1918)
• IETF RFC 5737 — IPv4 Address Blocks Reserved for Documentation (https://www.rfc-editor.org/rfc/rfc5737)

Duração: 80 minutos (explicação 20, prática guiada 50, verificação 10). Resultados dos TdR trabalhados: Avaliações básicas de segurança e auditoria técnica; Políticas, normas e boas práticas.

Objectivos

• Distinguir auditoria de teste técnico: a auditoria compara a realidade com um referencial (política, norma, contrato) e produz conclusões rastreáveis a evidências.
• Preparar uma lista de verificação com controlo, fonte, método, evidência mínima e resultado, e aplicá-la à rede de prática.
• Recolher evidências reprodutíveis, registar «conforme», «não conforme», «parcial», «não verificado (evidência insuficiente)» ou, só para controlos fora do âmbito, «não aplicável» com justificação, e evitar conclusões sem prova.
• Escrever conclusões e recomendações priorizadas, com responsável, prazo e reteste, e conhecer os limites da auditoria realizada.

Auditar é comparar com um referencial

Um teste técnico procura o que está exposto; uma auditoria verifica se a realidade cumpre o referencial: a política interna, uma norma como a ISO/IEC 27001, guias como os do NIST, ou as obrigações de um contrato. Cada item da auditoria é um controlo com uma fonte identificada, um método de verificação e a evidência mínima que o sustenta. Sem referencial, a auditoria vira opinião.

Os resultados usam uma escala clara: conforme (evidência mostra que cumpre), não conforme (evidência mostra que não cumpre), parcial (cumpre em parte, com o que falta identificado), não verificado (evidência insuficiente: regista-se a limitação e a acção necessária para concluir) e não aplicável (apenas quando o controlo está realmente fora do âmbito, com justificação sustentada no referencial ou no âmbito aprovado). Falta de prova nunca é «não aplicável». Cada resultado aponta para um ficheiro ou saída guardada, de forma a que outra pessoa possa repetir a verificação e chegar ao mesmo resultado. O NIST SP 800-53A descreve exactamente esta lógica de examinar, entrevistar e testar.

Independência, prova e limites

Quem audita não deve auditar o seu próprio trabalho: no mínimo, uma dupla verifica o trabalho da outra. A auditoria não altera o sistema; se algo tiver de ser corrigido, isso é remediação e faz-se depois, com pedido de alteração. Durante a auditoria, as evidências são tratadas como informação sensível.

O relatório indica âmbito, data, método, referencial, equipa, resultados por controlo com evidência, conclusões e recomendações priorizadas com responsável, prazo e reteste. Indica também as limitações: o que não foi verificado, o que dependeu de declaração de terceiros e o que foi observado apenas num momento. Uma recomendação sem prazo nem responsável não é uma recomendação: é um desejo.

Caso fictício

A DPE (fictícia) vai ser auditada pela tutela dentro de um mês. O chefe pede uma auditoria interna à rede de prática, com 12 controlos aprovados, para saber o que está conforme e preparar as correcções. Duas duplas trocam de papel: a dupla A audita a rede configurada pela dupla B, e vice-versa. Todos os dados são fictícios.

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).
• Âmbito da auditoria (declarado): rede de prática desta VM, controlos A01 a A12 da lista aprovada; sem alterações ao sistema durante a auditoria.
• Estado a auditar: cada dupla repõe, antes da troca, as configurações das lições 1 e 2 deste módulo (tabelas m12acessos e m12equip, SSH de prática) — a lista de verificação da lição 2 fica disponível.
• Os controlos A07 a A12 referem-se a práticas do módulo 11: nesta aula verificam-se pela evidência guardada nessas lições ou, se a dupla não as tiver conservado, marcam-se «não verificado (evidência insuficiente)», com a limitação e a acção para concluir (repetir a prática ou obter a evidência). Não são «não aplicável»: estão dentro do âmbito.

Passos

1. Pré-verificação e âmbito (não altera nada): confirme as ferramentas, a rede de prática e que a pasta do módulo está livre. Leia em voz alta a declaração de âmbito: «os testes desta aula só se aplicam aos espaços de nomes da rede de prática; qualquer outro endereço está fora do âmbito autorizado». Todos os comandos de teste começam por «ip netns exec <nome>»: um comando sem esse prefixo sairia da rede de prática e não deve ser executado.

   for d in nmap nft python3 ssh ssh-keygen sshd git; do command -v $d >/dev/null || echo "Em falta: $d"; done
   ip netns list | grep -cE '^(pc-adm|srv|r1|r2|pc-del|isp)( |$)'
   sudo ip netns exec pc-adm ping -c 2 10.10.20.53 | tail -1
   test -e /tmp/dpe-m12 && echo 'ATENÇÃO: /tmp/dpe-m12 já existe' || echo 'pasta livre'

   Saída de exemplo (didáctica):

   (nenhuma linha «Em falta»)
   6
   rtt min/avg/max/mdev = 0.05/0.07/0.09/0.02 ms
   pasta livre

2. Prepare a pasta e a lista de verificação (texto completo abaixo). Leia a coluna «evidência mínima» antes de começar: é o que tem de guardar.

   mkdir -p /tmp/dpe-m12/l4/evidencias && cd /tmp/dpe-m12/l4
   cat > lista-auditoria.csv <<'EOF'
   id,controlo,fonte,como_verificar,evidencia_minima,resultado,observacao
   A01,Segmentação: negação por omissão no encaminhamento,NIST SP 800-41,ver política da cadeia forward,saída do nft com policy drop,,
   A02,Acesso de gestão limitado à origem autorizada,NIST SP 800-41,regra específica + teste negativo,contador da regra e saída do teste,,
   A03,Gestão por protocolo cifrado (sem telnet/HTTP de gestão),NIST SP 800-41,varrimento de portas do equipamento,ficheiro do varrimento,,
   A04,Autenticação administrativa sem palavra-passe partilhada,NIST SP 800-63B,config do serviço + tentativa recusada,config e mensagem de recusa,,
   A05,Serviços desnecessários desactivados,NIST SP 800-41,lista de portas à escuta no equipamento,saída de ss,,
   A06,Parâmetros de encaminhamento endurecidos,NIST SP 800-41,lista de verificação da lição 2,saída OK/FALHA,,
   A07,Registos enviados para receptor central,NIST SP 800-92,evento de teste visível no receptor,linha do registo,,
   A08,Hora sincronizada em todos os equipamentos,RFC 5905,comparar horas,saídas de data dos equipamentos,,
   A09,Monitorização com alerta definido e responsável,NIST SP 800-137,ficha do alerta,ficha com limiar e responsável,,
   A10,Configurações exportadas e versionadas,NIST SP 800-128,histórico de versões,registo com data e autor,,
   A11,Cópia de segurança com integridade e reposição testada,NIST SP 800-34,soma verificada e reposição,saída da verificação e da reposição,,
   A12,Inventário actualizado e sem credenciais,NIST SP 800-128,comparar inventário com recolha,CSV e lista de diferenças,,
   EOF
   column -s, -t lista-auditoria.csv | head -n 5

3. Registe o âmbito e a hora de início; declare que a auditoria não altera o sistema.

   printf 'Auditoria interna (exercício)\nAmbito: rede de pratica, controlos A01-A12\nInicio: %s\nEquipa: dupla A (audita a configuracao da dupla B)\nRegra: so leitura; nenhuma alteracao ao sistema\n' "$(date '+%F %T')" | tee evidencias/00-ambito.txt

   Saída de exemplo (didáctica):

   Auditoria interna (exercício)
   Inicio: 2026-09-28 13:05:12

4. A01 e A02 — segmentação e acesso de gestão: examine as regras e faça o teste negativo. Guarde as saídas.

   sudo ip netns exec r1 nft list table inet m12acessos | tee evidencias/A01-A02-regras.txt | grep -E 'policy|comment'
   sudo ip netns exec pc-del nmap -Pn -p 22 --host-timeout 20s 10.10.20.53 | tee evidencias/A02-teste-negativo.txt | grep 22/tcp

   Saída de exemplo (didáctica):

   type filter hook forward priority filter; policy drop;
   … comment "gestao-ssh"
   … comment "delegacao-web"
   … comment "recusado"
   22/tcp filtered ssh

5. A03, A04 e A05 — portas do equipamento, autenticação administrativa e serviços à escuta.

   sudo ip netns exec pc-adm nmap -Pn -p 1-1024 10.10.10.1 | tee evidencias/A03-portas-r1.txt | grep -cE '^[0-9]+/tcp +open'
   grep -E 'PasswordAuthentication|PubkeyAuthentication|PermitRootLogin' /tmp/dpe-m12/l1/sshd-pratica.conf | tee evidencias/A04-config-ssh.txt
   sudo ip netns exec pc-adm ssh -o BatchMode=yes -o PreferredAuthentications=password -o PubkeyAuthentication=no -o StrictHostKeyChecking=no -o UserKnownHostsFile=/tmp/dpe-m12/l4/known_hosts $(id -un)@10.10.20.53 true 2>&1 | tee -a evidencias/A04-config-ssh.txt
   sudo ip netns exec r1 ss -tuln | tee evidencias/A05-escuta-r1.txt

   Saída de exemplo (didáctica):

   0
   PasswordAuthentication no
   PermitRootLogin prohibit-password
   PubkeyAuthentication yes
   Permission denied (publickey).
   (nenhuma linha LISTEN no r1)

6. A06 — parâmetros endurecidos: use a lista da lição 2 (só leitura) e guarde a saída.

   sudo sh /tmp/dpe-m12/l2/verificar-r1.sh | tee evidencias/A06-parametros.txt; echo "código=$?"

   Saída de exemplo (didáctica):

   Total de falhas: 0
   código=0

7. A07 a A12 — práticas do módulo 11: verifique a evidência guardada dessas lições. Se não existir nesta VM, marque «não verificado — evidência insuficiente (não conservada nesta VM)», registe a limitação e a acção (repetir a prática do módulo 11 ou obter a evidência) — não invente resultado nem use «não aplicável».

   ls -l /tmp/dpe-m11 2>/dev/null || echo 'evidências do módulo 11 não conservadas nesta VM'
   for n in pc-adm srv r1 r2; do printf '%s: ' $n; sudo ip netns exec $n date '+%F %T'; done | tee evidencias/A08-horas.txt

   Saída de exemplo (didáctica):

   evidências do módulo 11 não conservadas nesta VM
   pc-adm: 2026-09-28 13:12:40
   srv: 2026-09-28 13:12:40
   r1: 2026-09-28 13:12:40
   r2: 2026-09-28 13:12:40
   (todos os espaços de nomes partilham o relógio da VM: A08 conforme nesta rede, mas isto não demonstra sincronização entre equipamentos reais — limitação a registar)

8. Preencha as colunas «resultado» e «observação» da lista, apontando o ficheiro de evidência de cada controlo.

   nano lista-auditoria.csv

9. Escreva o relatório: âmbito, data, método, referencial, equipa, resultados, conclusões, recomendações priorizadas (responsável, prazo, reteste) e limitações.

   nano relatorio-auditoria.txt

Critérios de sucesso

• Os 12 controlos têm resultado, e cada resultado aponta um ficheiro de evidência; os «não verificado» indicam limitação e acção; qualquer «não aplicável» só é aceite com justificação de fora de âmbito — marcar «não aplicável» por falta de prova conta como erro de classificação.
• Nenhuma configuração foi alterada durante a auditoria (verificável: não há comandos de alteração nos registos da consola).
• As recomendações estão priorizadas e têm responsável, prazo e reteste.
• O relatório declara pelo menos três limitações, incluindo a do relógio partilhado e a dos controlos do módulo 11 não verificados.
• A dupla auditada consegue repetir qualquer verificação e obter o mesmo resultado.

Como desfazer (reversão)

• A auditoria não alterou nada; não há configuração a repor.
• As evidências são sensíveis: mostrar ao formador e depois rm -r /tmp/dpe-m12/l4.
• As configurações das lições 1 e 2 ficam para a lição 5 ou removem-se com as reversões dessas lições.

Alternativa em papel: tarefas e respostas esperadas

Classifique (conforme/não conforme/parcial/não verificado/não aplicável) e justifique: (a) A02 com regra específica e teste negativo «filtered»; (b) A04 com PasswordAuthentication no, mas a chave privada guardada sem frase de acesso; (c) A11 sem qualquer cópia nesta VM; (d) A08 com todos os relógios iguais por partilharem a VM.

(a) Conforme: evidência de regra e teste negativo. (b) Parcial: a autenticação por palavra-passe está desactivada, mas a protecção da chave é fraca; falta frase de acesso ou protecção equivalente. (c) Se a lista exige cópias e a verificação mostrou que não existem: não conforme. Se simplesmente não houve dados para verificar: não verificado (evidência insuficiente), com limitação e acção. Só é não aplicável se o âmbito aprovado excluir cópias — e essa justificação tem de constar; falta de prova não é motivo. (d) Conforme no âmbito da rede de prática, com limitação registada: não demonstra sincronização em equipamentos reais.

Escreva duas recomendações priorizadas a partir dos achados de exemplo.

1) Alta: proteger a chave administrativa com frase de acesso e limitar a origem do acesso. Responsável: equipa de redes. Prazo: 15 dias (fictício). Reteste: tentar usar a chave sem frase e confirmar recusa. 2) Média: instituir cópia semanal das configurações com verificação de integridade e reposição testada. Responsável: equipa de redes. Prazo: 30 dias. Reteste: repor numa pasta de teste e comparar.

Um auditor escreve «a rede está segura». Reescreva de forma defensável.

«Dos 12 controlos do âmbito, 9 conformes, 2 parciais e 1 não conforme, verificados em 28-09-2026 na rede de prática, com as evidências indicadas. Fora do âmbito: aplicações, postos de trabalho, rede sem fios e procedimentos de pessoal.»

Porque a dupla não deve auditar a sua própria configuração?

Falta independência: tende a confirmar o que fez, conhece os atalhos que tomou e pode saltar verificações. A troca entre duplas aproxima-se da separação entre quem executa e quem verifica.

Verifique o que aprendeu

Questão 1

Qual é a diferença essencial entre um teste técnico e uma auditoria?

1. A auditoria usa mais ferramentas
2. A auditoria compara a realidade com um referencial e sustenta cada conclusão numa evidência
3. O teste técnico não precisa de autorização
4. Não há diferença

Questão 2

Um controlo não pôde ser verificado por falta de dados. O que se escreve?

1. Conforme, para não atrasar
2. Não verificado (evidência insuficiente), com a limitação e a acção necessária para concluir
3. Não conforme, sempre
4. Nada

Em leitura fácil

• Auditar é comparar o que existe com as regras escritas.
• Cada resposta precisa de uma prova guardada.
• Escreva: cumpre, não cumpre, cumpre em parte ou não verificado.
• Quem fez o trabalho não deve ser quem verifica.
• A auditoria não muda nada: só observa.
• Sem prova, escreva «não verificado» e diga o que falta.
• «Não se aplica» só quando a regra está fora do trabalho combinado.

Fontes

• NIST SP 800-53A Rev. 5 — Assessing Security and Privacy Controls (https://csrc.nist.gov/pubs/sp/800/53/a/r5/final)
• ISO/IEC 27001:2022 — Information security management systems — Requirements (https://www.iso.org/standard/27001)
• NIST SP 800-41 Rev. 1 — Guidelines on Firewalls and Firewall Policy (https://csrc.nist.gov/pubs/sp/800/41/r1/final)
• NIST SP 800-92 — Guide to Computer Security Log Management (https://csrc.nist.gov/pubs/sp/800/92/final)
• NIST SP 800-128 — Guide for Security-Focused Configuration Management of Information Systems (https://csrc.nist.gov/pubs/sp/800/128/upd1/final)
• NIST SP 800-34 Rev. 1 — Contingency Planning Guide (https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final)
• IETF RFC 5905 — Network Time Protocol Version 4 (https://www.rfc-editor.org/rfc/rfc5905)
• Nmap Reference Guide (https://nmap.org/book/man.html)
• Projecto nftables — wiki oficial (https://wiki.nftables.org/)

Duração: 80 minutos (explicação 20, prática guiada 50, verificação 10). Resultados dos TdR trabalhados: Políticas, normas e boas práticas; Documentação: diagramas, procedimentos (SOP) e contingência; Competências profissionais e de formador replicador.

Objectivos

• Aplicar o ciclo de melhoria contínua (planear, executar, verificar, agir) à segurança da rede, a partir dos achados de testes e auditorias.
• Manter um registo de acções com origem, prioridade, responsável, prazo, estado e reteste, e calcular indicadores com um script que trata erros.
• Distinguir acção fechada de acção eficaz: sem reteste positivo, a acção reabre.
• Preparar a actividade integrada do curso e a apresentação como formador replicador, com critérios de avaliação rastreáveis aos resultados R01–R18.

Planear, executar, verificar, agir

Segurança não é um estado que se atinge; é um ciclo. Planeia-se (riscos, prioridades, acções), executa-se, verifica-se (monitorização, testes, auditorias) e age-se sobre o que a verificação mostrou. A ISO/IEC 27001 exige este ciclo num sistema de gestão da segurança da informação, e o NIST SP 800-137 descreve a monitorização contínua que o alimenta.

Cada achado vira uma acção com origem rastreável (o controlo ou teste de onde veio), prioridade justificada (exposição e impacto), responsável com nome, prazo e critério de fecho. Uma acção só está concluída quando o reteste confirma que o problema desapareceu; «fechada» sem reteste positivo é apenas papel.

Indicadores e transmissão do conhecimento

Poucos indicadores, bem definidos, dizem se o ciclo funciona: percentagem de acções concluídas com reteste positivo, acções atrasadas por prioridade, tempo médio até à correcção de achados altos. Cada indicador tem fórmula, fonte de dados e frequência; um indicador que não leva a nenhuma decisão não vale a pena medir. Os números servem para decidir, não para enfeitar relatórios: um indicador verde com reteste em falta esconde risco.

O formador replicador leva o conhecimento a outras equipas. Uma boa sessão tem objectivo claro, demonstração segura (em rede de prática, nunca em produção), alternativa sem computador, verificação da aprendizagem e materiais acessíveis. A actividade integrada deste curso avalia cada resultado R01–R18 com um critério e a evidência correspondente.

Caso fictício

Depois da auditoria interna (lição 4), a DPE (fictícia) tem cinco acções de melhoria. O chefe quer saber, a 15 de Outubro de 2026, quantas estão realmente concluídas, quais estão atrasadas e o que apresentar à direcção. Depois, cada equipa prepara a actividade integrada do curso e uma sessão de 10 minutos para colegas de outra delegação. Todos os dados são fictícios.

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).
• Esta lição trabalha sobretudo com ficheiros: registo de acções fictício e script de indicadores em /tmp/dpe-m12/l5.
• Reteste técnico: repete-se, dentro dos espaços de nomes, uma verificação das lições anteriores para fechar uma acção com evidência.

Passos

1. Pré-verificação e âmbito (não altera nada): confirme as ferramentas, a rede de prática e que a pasta do módulo está livre. Leia em voz alta a declaração de âmbito: «os testes desta aula só se aplicam aos espaços de nomes da rede de prática; qualquer outro endereço está fora do âmbito autorizado». Todos os comandos de teste começam por «ip netns exec <nome>»: um comando sem esse prefixo sairia da rede de prática e não deve ser executado.

   for d in nmap nft python3 ssh ssh-keygen sshd git; do command -v $d >/dev/null || echo "Em falta: $d"; done
   ip netns list | grep -cE '^(pc-adm|srv|r1|r2|pc-del|isp)( |$)'
   sudo ip netns exec pc-adm ping -c 2 10.10.20.53 | tail -1
   test -e /tmp/dpe-m12 && echo 'ATENÇÃO: /tmp/dpe-m12 já existe' || echo 'pasta livre'

   Saída de exemplo (didáctica):

   (nenhuma linha «Em falta»)
   6
   rtt min/avg/max/mdev = 0.05/0.07/0.09/0.02 ms
   pasta livre

2. Prepare a pasta, o registo de acções fictício e o script de indicadores (textos completos abaixo).

   mkdir -p /tmp/dpe-m12/l5 && cd /tmp/dpe-m12/l5
   cat > registo-accoes.csv <<'EOF'
   id,origem,accao,prioridade,responsavel,prazo,estado,data_fecho,reteste
   M01,A04,Frase de acesso nas chaves administrativas,alta,Equipa de redes,2026-10-12,fechada,2026-10-09,ok
   M02,A11,Cópia semanal das configurações com reposição testada,media,Equipa de redes,2026-10-28,aberta,,
   M03,A07,Receptor central de registos em produção,media,Equipa de sistemas,2026-11-15,aberta,,
   M04,L3-2323,Retirar serviço de gestão antigo sem cifra,alta,Equipa de redes,2026-10-05,aberta,,
   M05,A09,Alerta de utilização da WAN com responsável,baixa,Equipa de redes,2026-11-30,fechada,2026-10-20,falhou
   EOF
   cat > indicadores.py <<'EOF'
   #!/usr/bin/env python3
   """indicadores.py — indicadores do registo de acções de melhoria (exercício DPE, fictício).
   Uso: python3 indicadores.py REGISTO.csv DATA_DE_REFERENCIA(AAAA-MM-DD)
   Uma acção só conta como concluída se estiver fechada E com reteste 'ok'."""
   import csv, datetime, sys
   
   try:
       ficheiro, hoje = sys.argv[1], datetime.date.fromisoformat(sys.argv[2])
   except (IndexError, ValueError):
       sys.exit("Uso: python3 indicadores.py REGISTO.csv AAAA-MM-DD")
   try:
       with open(ficheiro, newline="", encoding="utf-8") as f:
           accoes = list(csv.DictReader(f))
       for a in accoes:
           a["prazo_d"] = datetime.date.fromisoformat(a["prazo"])
   except (OSError, KeyError, ValueError) as e:
       sys.exit(f"ERRO a ler {ficheiro}: {e}")
   if not accoes:
       sys.exit("Registo vazio.")
   concluidas = [a for a in accoes if a["estado"] == "fechada" and a["reteste"] == "ok"]
   reabrir = [a for a in accoes if a["estado"] == "fechada" and a["reteste"] != "ok"]
   atrasadas = [a for a in accoes if a not in concluidas and a["prazo_d"] < hoje]
   print(f"Acções: {len(accoes)} | concluídas com reteste ok: {len(concluidas)} ({len(concluidas) / len(accoes):.0%})")
   for a in reabrir:
       print(f"REABRIR: {a['id']} fechada mas reteste '{a['reteste'] or 'em falta'}'")
   for a in sorted(atrasadas, key=lambda a: a["prazo_d"]):
       print(f"ATRASADA: {a['id']} ({a['prioridade']}) prazo {a['prazo']} — {a['accao']}")
   EOF

3. Calcule os indicadores na data de referência do caso.

   python3 indicadores.py registo-accoes.csv 2026-10-15; echo "código=$?"

   Saída de exemplo (didáctica):

   Acções: 5 | concluídas com reteste ok: 1 (20%)
   REABRIR: M05 fechada mas reteste 'falhou'
   ATRASADA: M04 (alta) prazo 2026-10-05 — Retirar serviço de gestão antigo sem cifra
   (M02, M03 e M05 não aparecem como atrasadas: o prazo ainda não passou)
   código=0

4. Teste o tratamento de erros: data inválida e ficheiro inexistente.

   python3 indicadores.py registo-accoes.csv 15-10-2026; echo "código=$?"
   python3 indicadores.py nao-existe.csv 2026-10-15; echo "código=$?"

   Saída de exemplo (didáctica):

   Uso: python3 indicadores.py REGISTO.csv AAAA-MM-DD
   código=1
   ERRO a ler nao-existe.csv: [Errno 2] No such file or directory: 'nao-existe.csv'
   código=1

5. Reteste técnico da acção M04 na rede de prática: inicie o serviço antigo como na lição 3, aplique a correcção (bloqueio no r1) e confirme com o mesmo comando da lição 3. Registe a evidência e só então feche a acção.

   C: sudo ip netns exec srv python3 -c "import socketserver;socketserver.TCPServer.allow_reuse_address=True;socketserver.TCPServer(('10.10.20.53',2323),socketserver.BaseRequestHandler).serve_forever()"
   sudo ip netns exec pc-adm nmap -Pn -p 2323 10.10.20.53 | grep 2323
   sudo ip netns exec r1 nft add table inet m12melhoria
   sudo ip netns exec r1 nft add chain inet m12melhoria fwd '{ type filter hook forward priority -10; policy accept; }'
   sudo ip netns exec r1 nft add rule inet m12melhoria fwd ip daddr 10.10.20.53 tcp dport 2323 counter drop comment \"M04\"
   sudo ip netns exec pc-adm nmap -Pn -p 2323 10.10.20.53 | tee reteste-M04.txt | grep 2323

   Saída de exemplo (didáctica):

   2323/tcp open  3d-nfsd
   2323/tcp filtered 3d-nfsd

6. Actualize M04 no registo (estado fechada, data, reteste ok, evidência reteste-M04.txt) e volte a calcular. Nota: o bloqueio é a medida provisória; a acção definitiva (retirar o serviço) continua a exigir alteração aprovada.

   sed -i 's/^M04,\(.*\),aberta,,$/M04,\1,fechada,2026-10-15,ok/' registo-accoes.csv && grep ^M04 registo-accoes.csv
   python3 indicadores.py registo-accoes.csv 2026-10-15

   Saída de exemplo (didáctica):

   M04,L3-2323,Retirar serviço de gestão antigo sem cifra,alta,Equipa de redes,2026-10-05,fechada,2026-10-15,ok
   Acções: 5 | concluídas com reteste ok: 2 (40%)
   REABRIR: M05 fechada mas reteste 'falhou'

7. Actividade integrada: leia o enunciado e os critérios C01–C18 (rastreáveis a R01–R18), distribua os papéis na equipa e escreva o índice do relatório e o guião da apresentação de 10 minutos.

   nano /tmp/dpe-m12/l5/indice-relatorio.txt
   nano /tmp/dpe-m12/l5/guiao-apresentacao.txt

Critérios de sucesso

• O indicador inicial é 1 de 5 (20 %) e passa a 2 de 5 (40 %) só depois do reteste com evidência.
• A dupla explica porque M05 reabre apesar de estar «fechada».
• O script termina com mensagem clara e código 1 perante data ou ficheiro inválidos.
• O índice do relatório cobre C01 a C18, cada secção com a evidência prevista, e o guião da apresentação tem objectivo, demonstração segura, alternativa em papel e verificação.

Como desfazer (reversão)

• sudo ip netns exec r1 nft delete table inet m12melhoria
• Ctrl+C na consola C (serviço de exercício). Não usar pkill/killall. Confirmar: sudo ip netns pids srv não lista python3.
• Se ainda existirem as tabelas das lições 1 e 2, removê-las com as reversões dessas lições (m12acessos, m12equip) e repor os valores sysctl guardados.
• Guardar o índice e o guião fora da VM e depois rm -r /tmp/dpe-m12 (todas as pastas do módulo). A forma segura de repor tudo continua a ser descartar a VM.

Alternativa em papel: tarefas e respostas esperadas

Com o registo fictício, calcule à mão os indicadores a 15-10-2026: acções concluídas com reteste ok, acções a reabrir, acções atrasadas.

Concluídas com reteste ok: 1 (M01) = 20 %. A reabrir: M05 (fechada, reteste falhou). Atrasadas: M04 (prazo 05-10, aberta). M02, M03 e M05 têm prazo futuro; M05 reabre mas não está atrasada.

Defina um indicador útil para a direcção, com fórmula, fonte, frequência e decisão que suporta.

Exemplo: «percentagem de acções de prioridade alta concluídas com reteste ok dentro do prazo» = altas concluídas no prazo / altas com prazo vencido; fonte: registo de acções; mensal; decisão: reforçar recursos ou rever prioridades se ficar abaixo de 80 %.

Para os critérios C07, C12 e C18 da actividade integrada, diga que evidência entregaria.

C07: contadores das regras nftables antes/depois de um teste negativo, ou captura que mostra o descarte. C12: configuração SSH só com chave e a mensagem «Permission denied (publickey)»; verificação de que os documentos não contêm segredos. C18: guião da sessão de 10 minutos e grelha de avaliação dos pares preenchida.

Escreva o guião de uma sessão de 10 minutos para colegas sobre «testes autorizados», incluindo a alternativa sem computador.

0–2 min objectivo e regra da autorização; 2–6 min demonstração na rede de prática (ou leitura das saídas de exemplo impressas) de uma porta aberta e da sua confirmação; 6–8 min exercício: classificar três achados; 8–10 min pergunta de verificação e resumo. Materiais em letra grande; comandos lidos em voz alta.

Verifique o que aprendeu

Questão 1

Uma acção de melhoria está marcada «fechada», mas o reteste falhou. Como se conta no indicador?

1. Como concluída
2. Como não concluída, e a acção reabre
3. Como não aplicável
4. Retira-se do registo

Questão 2

Para que serve ligar cada critério da actividade integrada a um resultado R01–R18?

1. Para aumentar o número de páginas
2. Para demonstrar, com evidência, que cada resultado de aprendizagem dos TdR foi avaliado
3. Para dispensar a apresentação
4. Para substituir a auditoria

Em leitura fácil

• A segurança melhora num ciclo que nunca acaba.
• Cada problema encontrado vira uma tarefa com responsável e prazo.
• Uma tarefa só acaba quando se confirma que resolveu.
• Poucos números bem escolhidos mostram se está a melhorar.
• No fim do curso, a equipa faz um trabalho completo e apresenta-o.
• Ensine os colegas com uma rede de prática, nunca com a rede real.

Fontes

• ISO/IEC 27001:2022 — Information security management systems — Requirements (https://www.iso.org/standard/27001)
• NIST SP 800-137 — Information Security Continuous Monitoring (ISCM) (https://csrc.nist.gov/pubs/sp/800/137/final)
• NIST SP 800-53A Rev. 5 — Assessing Security and Privacy Controls (https://csrc.nist.gov/pubs/sp/800/53/a/r5/final)
• NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment (https://csrc.nist.gov/pubs/sp/800/115/final)
• Projecto nftables — wiki oficial (https://wiki.nftables.org/)
• Nmap Reference Guide (https://nmap.org/book/man.html)
• Python 3 — documentação oficial dos módulos json, csv, subprocess e statistics (https://docs.python.org/3/library/)

O que a lei exige

A pessoa com deficiência tem direito de acesso ao ambiente físico, transporte, informação e tecnologias e sistemas de comunicação com base no desenho universal e ajustamento razoável.

O que significa na prática para um servidor público

Ao criar ou escolher um serviço, comece por torná-lo utilizável pelo maior número de pessoas. Quando uma pessoa ainda encontra uma barreira, faça o ajustamento adequado à sua necessidade.

Exemplo concreto de serviço digital moçambicano

No Portal do Governo de Moçambique, um formulário deve poder ser preenchido só com o teclado e lido por um leitor de ecrã.

Fonte: Lei n.º 10/2024, de 7 de Junho, artigo 16.

O que a lei exige

As entidades públicas e privadas que prestam serviços públicos devem procurar disponibilizar informação em formatos acessíveis. O Estado deve garantir formação de comunicadores e agentes do Estado em língua de sinais.

O que significa na prática para um servidor público

Publique a mesma informação em formatos que pessoas diferentes consigam usar. Use texto claro, documentos acessíveis, legendas, áudio e Língua de Sinais Moçambicana quando necessário.

Exemplo concreto de serviço digital moçambicano

Num aviso publicado num portal de um ministério, disponibilize texto acessível, versão áudio e vídeo com legendas e interpretação em Língua de Sinais Moçambicana.

Fonte: Lei n.º 10/2024, de 7 de Junho, artigo 17.

O que a lei exige

Os processos de contratação de empreitadas, fornecimento de bens e prestação de serviços devem ter em conta as necessidades da pessoa com deficiência.

O que significa na prática para um servidor público

Inclua requisitos de acessibilidade desde o caderno de encargos. Avalie esses requisitos antes de contratar. Verifique o seu cumprimento na entrega.

Exemplo concreto de serviço digital moçambicano

Na contratação de um sistema de marcação de consultas para uma unidade pública de saúde, exija navegação por teclado, compatibilidade com leitor de ecrã e atendimento alternativo acessível.

Fonte: Lei n.º 10/2024, de 7 de Junho, artigo 20.

O que a lei exige

A pessoa com deficiência tem direito à educação em instituições públicas e privadas. O Estado deve adequar metodologias, materiais, infra-estruturas, mobiliário e equipamento. Deve também incluir matérias sobre deficiência na formação de professores, quadros administrativos e gestores.

O que significa na prática para um servidor público

Planeie a formação para diferentes formas de aprender e participar. Dê materiais acessíveis. Garanta que a sala, a plataforma e os equipamentos não criam barreiras.

Exemplo concreto de serviço digital moçambicano

Numa plataforma pública de ensino à distância, disponibilize os materiais em texto acessível e áudio. Legende os vídeos. Permita concluir as actividades sem usar o rato.

Fonte: Lei n.º 10/2024, de 7 de Junho, artigo 24.

O que a lei exige

O Estado promove a recolha, a análise, o armazenamento e a divulgação de dados sobre pessoas com deficiência em todas as esferas da vida.

O que significa na prática para um servidor público

Recolha apenas os dados necessários, com uma finalidade clara. Proteja a informação individual. Use os dados agregados para melhorar políticas e serviços.

Exemplo concreto de serviço digital moçambicano

Num serviço digital de inscrição para formação pública, o tipo de deficiência é opcional e autodeclarado. A pessoa pode alterá-lo ou removê-lo. Os relatórios não identificam indivíduos.

Fonte: Lei n.º 10/2024, de 7 de Junho, artigo 30.

O que a lei exige

O Estado garante a produção estatística com indicadores que permitam desagregar os dados por sexo, idade, tipo de deficiência, causas, prevalência e outras variáveis relevantes.

O que significa na prática para um servidor público

Prepare os sistemas para produzir indicadores desagregados. Ao divulgar, proteja grupos pequenos para impedir a identificação das pessoas.

Exemplo concreto de serviço digital moçambicano

No Painel Nacional desta plataforma, os resultados podem ser cruzados por género e tipo de deficiência. Grupos com menos de cinco pessoas aparecem como informação insuficiente para divulgação.

Fonte: Lei n.º 10/2024, de 7 de Junho, artigo 31.