Segurança Aplicada e Auditoria de Redes

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)