Segurança de redes
Escuta, falsificação, TLS, firewalls/IDS, malware e contas de negação de serviço.
O navegador da Ana envia à loja um pedido com o cookie de sessão. Um atacante no caminho pode observar ou alterar tráfego desprotegido; um atacante apenas remoto pode enviar os seus próprios pedidos, sem necessariamente observar os da Ana. A posição do atacante determina as mensagens que controla e os recursos que consegue esgotar.
Observação e falsificação
A escuta procura ler tráfego. A falsificação, ou spoofing, apresenta uma identidade ou endereço falso. Num ataque ativo de intermediário, o atacante interceta e pode alterar a comunicação entre os extremos.
| Mecanismo atacado | Fraqueza explorada | Defesa e limite |
|---|---|---|
| ARP numa rede local | O atacante envia associações falsas entre o IP do router e o seu MAC | Controlos na rede local; um canal autenticado protege dados mesmo com caminho hostil |
| DNS | Resposta ou resolução adulterada | Validação DNSSEC onde aplicável; não cifra consultas nem garante que o serviço final é honesto |
| TCP | Manipulação de estado ou segmentos | Validações do protocolo e transporte autenticado; um endereço IP não é prova de identidade |
| Aplicação sem TLS | Conteúdo legível ou alterável no caminho | TLS corretamente validado; os extremos continuam a ver o conteúdo |
Nem todo atacante pode ver todos os pacotes, por isso numa resposta justifica que mensagens ele controla.
TLS, SSH e IPsec
TLS protege o canal entre os extremos que terminam TLS. Num handshake autenticado, segue quatro passos: o cliente anuncia versões e mecanismos; o servidor escolhe, apresenta o certificado e prova a posse da chave; ambos estabelecem chaves de sessão; depois protegem registos com cifragem autenticada. Este handshake é do TLS, não do TCP, por isso completar o TCP não autentica ninguém. TLS 1.3 tem diferenças relevantes face ao TLS antigo, incluindo a seleção de mecanismos criptográficos.
HTTPS é HTTP transportado por TLS. Protege o conteúdo HTTP, incluindo caminho, cabeçalhos e corpo, durante o transporte. Um observador ainda pode conhecer endereços IP, tamanhos e tempos; o nome do servidor pode ficar visível por DNS ou por mecanismos do handshake, conforme a configuração. Por isso, HTTPS não esconde dados do servidor nem corrige XSS ou uma autorização em falta.
No HTTPS habitual, o cliente verifica o certificado do servidor, mas o servidor não pede um certificado de cliente. Essa autenticação assimétrica não significa cifragem numa única direção: o canal protege dados enviados nos dois sentidos. O login da aplicação pode identificar o utilizador depois do handshake. TLS também admite certificados de cliente e mecanismos com segredo prévio; a descrição com certificado do servidor não abrange todas as configurações.
O Handshake estabelece parâmetros e material criptográfico e autentica conforme a configuração. O Record protege os dados transportados com as chaves estabelecidas. Não confundas a apresentação de uma chave pública com o envio de uma chave de sessão em claro; no TLS 1.3 com certificados, a assinatura autentica a troca, e o acordo de chaves fornece o segredo a partir do qual se derivam chaves.
O TLS 1.3 admite retomar sessões com dados enviados antes de completar o handshake (0-RTT), protegidos por uma chave pré-partilhada. Esses bytes podem ser repetidos por um intermediário, porque ainda não há frescura da nova sessão: repetir bytes válidos continua a verificar, e a etiqueta prova origem sob a chave antiga, não novidade. A aplicação tem de ser projetada para ser segura sob repetição, no mínimo idempotente, e muitas vezes com condições mais fortes como resposta em tempo constante e ausência de efeitos observáveis por cache ou tempo. Uma consulta pode ainda expor informação por temporização de cache, e operações idempotentes podem ter efeitos. Por isso, só pedidos definidos num perfil explícito como seguros sob repetição podem usar 0-RTT, por decisão do servidor, que pode recusar e forçar novo handshake. Repetir uma transferência duplica o efeito; repetir uma consulta sem esse perfil também pode vazar ou sobrecarregar. O anexo E.5 do RFC 8446 descreve estes ataques de repetição.
SSH oferece um canal autenticado para acesso remoto e outros serviços. A validação da chave do servidor é necessária para evitar um intermediário. A autenticação do utilizador pode usar chave pública autorizada, palavra-passe ou outros mecanismos permitidos pelo servidor. Uma chave registada é frequente em conjuntos conhecidos de utilizadores; SSH também admite certificados, pelo que não exige sempre uma CA nem proíbe PKI.
IPsec protege tráfego ao nível IP. Com ESP e cifragem em modo transporte, protege-se a carga do pacote, conservando o cabeçalho IP exterior; em modo túnel, o pacote IP original, incluindo o seu cabeçalho, fica dentro de um novo pacote, cujo cabeçalho exterior continua necessário ao encaminhamento. As garantias dependem de ESP/AH, modo e política. Autenticar tráfego numa associação não elimina toda falsificação de IP noutras partes da rede.
No modelo comum de HTTPS sobre TCP, a ordem é IP, TCP, TLS e HTTP; IPsec atua no nível IP, abaixo de TCP. IPsec não interpreta automaticamente permissões como «esta conta pode ler esta fatura». Uma VPN não torna uma aplicação interna automaticamente autorizada para todos os clientes.
Firewalls e deteção
Uma firewall aplica uma política sobre tráfego. Um filtro sem estado decide com campos do pacote; um filtro com estado acompanha conexões; um proxy pode aplicar regras da aplicação. Aceitar qualquer pacote com o bit ACK não prova que pertence a uma conexão permitida.
Uma regra deve dizer direção, origem, destino, protocolo, porta e, quando existe, estado; depois verifica-se a ordem das regras e a decisão por defeito, como neste caso:
- aceitar TCP de saída para porta 443 com estado novo ou estabelecido;
- aceitar TCP de entrada só com estado estabelecido;
- recusar o resto e registar.
Com esta ordem, um SYN inicial de fora é recusado pela regra 3. Um pacote com ACK de fora sem conexão conhecida também é recusado, porque a regra 2 exige estado estabelecido. Permitir HTTPS para um servidor não impede ataques que chegam por pedidos HTTPS válidos.
Um IDS deteta eventos suspeitos; um IPS pode bloquear. Deteção por assinatura reconhece padrões conhecidos; deteção por anomalia compara comportamento com um modelo. Uma mudança legítima pode produzir um falso positivo. Um ataque semelhante ao normal pode produzir um falso negativo.
Malware: propagação, função e controlo
Malware é código que compromete objetivos de segurança. Os nomes podem descrever dimensões diferentes: como se propaga, o que faz ou como é controlado.
| Termo | Característica que o distingue |
|---|---|
| Vírus | Replica-se através de um ficheiro ou programa hospedeiro |
| Worm | Propaga-se autonomamente entre sistemas, por exemplo explorando um serviço vulnerável |
| Cavalo de Troia | Apresenta-se como software desejado enquanto executa ações ocultas |
| Ransomware | Procura impedir acesso e extorquir, por exemplo cifrando dados |
| Bot | Componente comprometido controlável pelo operador |
| Botnet | Conjunto de bots coordenados para tarefas como DDoS ou envio de mensagens |
Um worm pode instalar um bot e integrar os sistemas numa botnet. “Worm” descreve propagação; “botnet” descreve coordenação. Não são categorias necessariamente exclusivas.
Uma assinatura reconhece um padrão conhecido. Alterar representação, empacotar ou cifrar partes do código pode dificultar esse reconhecimento. Deteção comportamental observa ações, mas tem falsos positivos e depende do comportamento executado. O malware pode atrasar ações ou reconhecer indícios de uma sandbox. Não fazer nada numa execução de teste não demonstra inocuidade.
Numa análise defensiva, combina origem do ficheiro, análise estática, execução isolada e telemetria, sem executar amostras no ambiente de trabalho. Prevenção inclui corrigir a via de entrada, restringir privilégios e segmentar. Recuperação pode exigir isolar equipamentos, substituir credenciais e restaurar cópias verificadas; eliminar um ficheiro não garante que toda a persistência desapareceu.
DoS, SYN flood e amplificação
DoS afeta a disponibilidade. DDoS usa origens distribuídas, que podem incluir máquinas comprometidas ou refletores. Um SYN flood procura ocupar recursos de conexões TCP incompletas. O diagrama seguinte mostra o handshake normal e o flood no mesmo cenário, em duas partes.
No flood, o SYN-ACK vai para o endereço falsificado e nunca obtém resposta; o servidor guarda estado até encher a fila e o SYN do cliente legítimo fica sem resposta.
SYN cookies reduzem o estado guardado antes de o cliente completar o handshake; não resolvem todos os limites de capacidade nem os ataques à aplicação.
Em reflexão, três papéis participam. O atacante falsifica o endereço da vítima em pedidos pequenos a terceiros. Os terceiros respondem à vítima. A vítima recebe respostas que nunca pediu. Se a resposta é maior que o pedido, há amplificação.
Suponhamos pedidos de 60 bytes e respostas de 3 000 bytes, contando apenas o conteúdo indicado. O fator é . Com 2 Mbit/s de pedidos, a vítima pode receber 100 Mbit/s de respostas, se os refletores conseguirem gerar esse tráfego. Cabeçalhos, perdas e limitações reais alteram a conta; o enunciado tem de dizer o que está incluído.
O problema da taxa base
Um IDS analisa 10 000 eventos. Há 10 ataques. Deteta 90% dos ataques e alerta em 1% dos eventos legítimos. Dos 10 ataques, 9 geram alerta e 1 não: são os verdadeiros positivos e o falso negativo esperados. Nos 9 990 eventos legítimos, esperamos falsos positivos. A precisão esperada dos alertas é:
Uma taxa de deteção alta não implica que a maioria dos alertas seja um ataque. A raridade dos ataques afeta a interpretação.
| Classe real | Alerta | Sem alerta | Total |
|---|---|---|---|
| Ataques | 9 | 1 | 10 |
| Eventos legítimos | 99,9 | 9 890,1 | 9 990 |
| Total esperado | 108,9 | 9 891,1 | 10 000 |
As células fracionárias são valores esperados, não contagens observadas de um ensaio. Para a precisão lemos a coluna dos alertas: só 9 dos 108,9 alertas esperados correspondem a ataques.
Para escolher uma defesa DoS, identifica o recurso esgotado. Se o acesso à Internet já está saturado, filtrar só no servidor chega tarde. Se a CPU gasta trabalho caro por pedido, limites e filas na aplicação podem ajudar, porque bloquear um IP também pode bloquear utilizadores legítimos que partilham esse endereço.
Exercícios
Quanto chega à vítima?
Um refletor responde com 2 400 bytes a um pedido de 80 bytes. Com 3 Mbit/s de pedidos, qual débito de respostas é previsto? Ignora cabeçalhos e limitações dos refletores.
Pista
Calcula a razão resposta/pedido.
Solução
. O débito previsto é Mbit/s sob as hipóteses indicadas.
Erros frequentes
Não multiplicar bits por bytes sem preservar a razão e as unidades.
Maioria dos alertas?
Em 100 000 eventos, 100 são ataques. O IDS deteta 80% dos ataques e alerta em 0,2% dos eventos legítimos. Qual precisão esperada, em percentagem? Arredonda a duas casas decimais.
Pista
Precisão divide ataques detetados por todos os alertas.
Solução
Esperamos 80 verdadeiros positivos e 199,8 falsos positivos: e . A precisão é . Os valores são expectativas, não contagens inteiras observadas: a precisão divide ataques detetados por todos os alertas.
Erros frequentes
80% é sensibilidade, não precisão. A taxa falsa positiva aplica-se a eventos legítimos.
Quem consegue ler?
O navegador usa TLS até um proxy e o proxy usa TLS até à aplicação. Um atacante controla o proxy. HTTPS impede-o de ler o conteúdo HTTP? Justifica.
Pista
Marca onde cada canal começa e termina.
Solução
Não. O proxy termina TLS e tem acesso ao conteúdo nesse ponto, ou seja os dois canais protegem os percursos, não o conteúdo contra o próprio proxy. A hipótese de confiança nesse componente importa.
Confere a tua resposta:
- Identifica o proxy como extremo de ambos os canais.
- Explica que o proxy pode aceder ao conteúdo entre a decifragem e nova cifragem.
- Distingue proteção em trânsito de proteção contra um extremo comprometido.
Erros frequentes
Não assumir cifragem ponta a ponta da aplicação só porque todos os enlaces usam TLS.
Propagação, controlo e recuperação
Um programa propaga-se autonomamente explorando um serviço. Cada instância recebe depois ordens de um operador para gerar tráfego. A equipa corrige a vulnerabilidade do serviço e considera o incidente resolvido. Caracteriza as duas dimensões do malware e avalia a conclusão.
Pista
Segue o que o patch muda e o que já existia antes dele.
Solução
A propagação autónoma caracteriza um worm. As instâncias controláveis são bots e o conjunto coordenado pode formar uma botnet. O patch atua na via de entrada, mas não demonstra que os bots instalados desapareceram nem que as credenciais estão intactas. Isola os sistemas afetados, investiga persistência e exposição, restaura estados verificados e substitui credenciais comprometidas. Confirma a correção e a recuperação por evidência, sem tratar as duas categorias como exclusivas.
Confere a tua resposta:
- Distingui propagação de worm e coordenação de botnet.
- Expliquei por que corrigir a entrada não remove instâncias já comprometidas.
- Propus isolamento e recuperação além do patch.
Erros frequentes
Não concluir que impedir novas infeções elimina as anteriores.
Nada aconteceu no ensaio
Um ficheiro suspeito não executa ações visíveis durante dois minutos numa sandbox. O analista conclui que é seguro. Avalia a conclusão e propõe uma forma de a investigar sem correr o ficheiro no posto de trabalho.
Pista
O que acontece se o ramo relevante não for ativado?
Mais uma pista
O programa pode esperar mais tempo ou depender de condições não presentes.
Solução
A observação é limitada a esse ensaio. Ações adiadas, condições externas ou reconhecimento da sandbox podem explicar a inatividade; também pode ser benigno. Combina análise estática, origem, outras execuções isoladas apropriadas e telemetria. Não transformes uma hipótese de evasão numa prova de malware, nem a falta de ação numa prova de segurança.
Confere a tua resposta:
- Diz que uma execução sem comportamento não prova inocuidade.
- Identifica tempo, condições de execução ou reconhecimento de sandbox como explicações possíveis.
- Propõe combinar evidência estática, execução isolada e telemetria sem executar no posto normal.
Erros frequentes
Não afirmar que todos os programas que esperam são maliciosos.
Que regra decide o pacote
A firewall usa: 1. aceitar TCP de saída para a porta 443 com estado novo ou estabelecido; 2. aceitar TCP de entrada só com estado estabelecido; 3. recusar o resto e registar. Chega de fora um SYN para a porta 443 sem conexão conhecida. Qual decisão é adequada?
Pista
Segue a ordem das regras com a direção do pacote.
Solução
A regra 1 só trata saída. A regra 2 exige estado estabelecido, que um SYN inicial não tem. A decisão por defeito recusa e regista.
- Recusado pela regra por defeito: SYN inicial de fora sem conexão conhecida.. A regra de entrada exige estado estabelecido e a decisão por defeito recusa o resto.
- Aceite pela regra de saída para a porta 443.. A direção do pacote é de entrada, não de saída.
- Aceite pela regra 2 porque se destina à porta 443.. A regra 2 exige estado estabelecido, não apenas a porta de destino.
- Aceite porque HTTPS é permitido ao servidor.. A permissão de serviço não dispensa direção, origem e estado.
Erros frequentes
Não aceites pacotes só pela porta de destino sem verificar direção e estado.
Um certificado, dois sentidos
Um cliente HTTPS valida o certificado do servidor e não fornece certificado de cliente. Usa depois um login da aplicação e pede uma fatura. Identifica quem é autenticado por certificado neste handshake. A resposta do servidor para o cliente fica protegida? Associa estabelecer chaves e proteger dados a Handshake ou Record. O certificado do servidor permite decidir se o utilizador pode ler a fatura?
Solução
O cliente autentica o servidor por certificado e prova de posse da chave; neste caso, o servidor não autentica o cliente por certificado. Ainda assim, dados da aplicação ficam protegidos nos dois sentidos do canal. Handshake estabelece material e parâmetros; Record protege os dados com as chaves estabelecidas. O login identifica o utilizador no nível da aplicação e a autorização continua a verificar o acesso àquela fatura. Certificado do servidor e canal seguro não concedem direitos sobre objetos.
Confere a tua resposta:
- Distingui autenticação do servidor de identificação do utilizador.
- Reconheci proteção de dados nos dois sentidos.
- Separei Handshake, Record e autorização da fatura.
Dados antes do handshake
Um servidor TLS 1.3 aceita dados 0-RTT. Um intermediário regrava os mesmos bytes e o servidor executa-os duas vezes. O canal estava cifrado e autenticado. Porque é que a proteção do canal não impediu a repetição? Para que pedidos pode o servidor continuar a aceitar 0-RTT?
Pista
O atacante precisou de decifrar ou forjar alguma coisa?
Solução
Os bytes 0-RTT são protegidos pela chave pré-partilhada, mas não têm frescura da nova sessão: repetir bytes válidos continua a verificar. A etiqueta prova origem sob a chave antiga, não novidade. O servidor só deve aceitar 0-RTT para pedidos definidos num perfil explícito como seguros sob repetição, o que exige mais do que ausência de escrita, pois consultas podem expor informação por cache ou tempo e operações idempotentes podem ter efeitos. Transferências, que duplicam o efeito, nunca pertencem a esse perfil. A decisão pertence à política do servidor, que pode recusar e forçar novo handshake.
Confere a tua resposta:
- Explica que 0-RTT usa chave pré-partilhada sem frescura da nova sessão.
- Distingue pedidos seguros sob repetição, por perfil explícito, de operações com efeitos.
- Atribui ao servidor a decisão de permitir ou recusar 0-RTT.
Erros frequentes
Não apresentar AEAD ou certificados como prova automática de frescura de uma sessão retomada.