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
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 livreCrie 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 EOFPrimeira exportação: é a linha de base aprovada.
sudo sh exportar.sh sudo git -C configs log --onelineSaí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 formandoRepita sem mudanças: o script não cria registos vazios.
sudo sh exportar.shSaída de exemplo (didáctica):
Sem alterações desde a última exportação.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.txtSaí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-r2Sem 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 baseTeste 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=1Có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 -lSaí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?
- Uma rota com métrica alta
- Uma diferença entre o estado do equipamento e a linha de base que não tem alteração aprovada
- Uma cópia de segurança antiga
- Um erro de sintaxe no git
Ver resposta comentada
Resposta: Uma diferença entre o estado do equipamento e a linha de base que não tem alteração aprovada
O desvio pode ser um esquecimento, um erro ou um ataque; detecta-se comparando o estado exportado com a linha de base e trata-se com repor ou aprovar.
Questão 2
Porque se calcula e guarda uma soma SHA-256 com cada cópia?
- Para cifrar a cópia
- Para confirmar mais tarde que o ficheiro está íntegro, sem corrupção nem alteração
- Para comprimir mais
- Para dispensar o teste de reposição
Ver resposta comentada
Resposta: Para confirmar mais tarde que o ficheiro está íntegro, sem corrupção nem alteração
A soma confirma a integridade; não cifra nem substitui o teste de reposição. Para detectar alteração maliciosa, a soma deve ser guardada separadamente da cópia.
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/)
