Segurança Aplicada e Auditoria de Redes

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)