Segurança em Redes de Computadores

Uma mensagem pode ser privada e ainda assim ser alterada ou vir de uma impostora. Por isso, a comunicação segura precisa de várias propriedades, cada uma respondendo a uma pergunta diferente sobre a troca.

Identifique a propriedade em risco

Alice e Bob são as partes que se comunicam; Trudy é a atacante. Uma atacante passiva captura tráfego sem alterá-lo. Ler uma senha é interceptação. Inferir um horário de trabalho intenso pelos horários das conexões é análise de tráfego, mesmo quando o conteúdo está cifrado. Uma atacante ativa insere, altera, apaga ou repete pacotes. A falsificação de origem declara uma identidade de origem falsa; o sequestro toma controle de uma troca existente; a inundação tenta esgotar recursos.

Os roteadores da internet geralmente encaminham pacotes sem comprovar que seus endereços de origem são verdadeiros. Os pacotes também atravessam redes fora do controle de ambos os usuários. No Wi-Fi, outro dispositivo de rádio ao alcance pode capturar quadros transmitidos. Os protocolos devem proteger a comunicação mesmo quando uma atacante controla o caminho.

Acompanhe uma entrada exposta

Bob se conecta ao ponto de acesso de um café e entra em um site usando HTTP sem proteção. Trudy lê a senha: a confidencialidade falhou. Ela altera um link de download na resposta: a integridade falhou. Se ela fornecer um ponto de acesso falso com o nome do café, Bob também não terá uma verificação confiável da identidade do ponto de acesso. Cifrar apenas a senha não corrigiria todas essas falhas. Uma atacante pode alterar algumas mensagens cifradas sem entendê-las e pode repetir sem alterações uma mensagem de autenticação capturada.

Mantenha a chave em segredo

O princípio de Kerckhoffs afirma que a segurança deve resistir à divulgação do algoritmo. O segredo é a chave. Um algoritmo caseiro secreto pode ser recuperado do software; alterar e distribuir um algoritmo inteiro também é mais difícil que substituir uma chave. Substituir uma chave exposta protege o tráfego futuro, mas não torna seguros os registros feitos com a chave antiga.

O conhecimento da atacante também importa. Um ataque somente com texto cifrado começa com mensagens cifradas interceptadas. Um ataque com texto claro conhecido acrescenta as mensagens originais correspondentes, como o texto previsível de HTTP/1.1 que começa com “GET /”. Em um ataque com texto claro escolhido, a atacante pode obter a cifragem de mensagens que seleciona. A cifragem moderna é projetada para resistir a essas situações mais fortes.

Localize o trecho protegido

A segurança Wi-Fi e celular protege um enlace de rádio. O TLS protege a comunicação entre as extremidades da aplicação. O IPsec protege o tráfego IP selecionado entre hospedeiros ou gateways. A proteção no nível da mensagem, como no correio eletrônico seguro, pode permanecer com a mensagem durante o armazenamento. Um salto de rádio seguro não protege o restante de uma rota pela internet: depois que um ponto de acesso remove a proteção do enlace, outro mecanismo deve proteger o tráfego adiante.

Uma cifra simétrica usa a mesma chave secreta nas duas extremidades. Texto claro é a mensagem original; texto cifrado é sua forma cifrada. Escreva a cifragem como $c=E_{K_S}(m)$ e a decifragem como $m=D_{K_S}(c)$: a chave é compartilhada, mas as duas operações desfazem uma à outra.

Tamanho da chave e fraquezas estruturais

Um deslocamento de César de 3 transforma “MEET AT NOON” em “PHHW DW QRRQ”. Testar todos os 25 deslocamentos úteis quebra a cifra. Uma cifra de substituição tem $26!\approx \mathrm{4,03}\times {10}^{26}$ chaves, mas preserva as frequências das letras. Uma atacante pode usar letras repetidas e palavras comuns para recuperar o mapeamento sem testar todas as chaves. O tamanho do espaço de chaves, por si só, não prova a segurança.

O AES é uma cifra de bloco com blocos de 128 bits e chaves de 128, 192 ou 256 bits. O DES tinha blocos de 64 bits e uma chave de 56 bits; uma busca exaustiva encontrou uma chave DES em 1998, e o DES e o Triple DES foram retirados do uso padronizado. Cada bit adicional da chave dobra o trabalho da busca exaustiva. A ${10}^{12}$ tentativas por segundo, buscar todas as chaves DES leva cerca de $2^{56}\mathrm{/}{10}^{12}\approx 72.000$ segundos, ou 20 horas; encontrá-la leva, em média, metade desse tempo. Buscar todas as chaves AES-128 nessa taxa leva cerca de $\mathrm{1,1}\times {10}^{19}$ anos.

O modo altera a proteção da mensagem

Um modo de operação trata mais de um bloco.

O primeiro bloco do CBC usa um vetor de inicialização, ou IV, no lugar de um bloco anterior de texto cifrado. O IV é enviado abertamente; importam sua imprevisibilidade e seu caráter novo, não seu sigilo. A aleatorização oculta padrões diretos de igualdade entre mensagens. Ela não detecta adulterações por si só.

Analise a reutilização de uma sequência de chave

Suponha que duas mensagens usem a mesma sequência de chave $k$. Seus textos cifrados são $c_1=m_1\oplus k$ e $c_2=m_2\oplus k$. Aplicar XOR entre eles cancela a sequência de chave repetida:

Conhecer um dos textos claros agora revela o outro. Os IVs repetidos do WEP causaram esse tipo de falha. Uma chave de cifragem mais longa não corrige uma sequência de chave repetida.

A AEAD, cifragem autenticada com dados associados, combina confidencialidade com integridade. AES-GCM e ChaCha20-Poly1305 autenticam o texto cifrado e quaisquer dados associados. Dados associados, como um campo de roteamento, permanecem legíveis, mas não podem ser alterados sem que a verificação falhe. O TLS 1.3 usa AEAD para cada registro protegido.

Distribua o segredo

A cifragem rápida de grandes volumes de dados ainda exige uma chave compartilhada. Se cada par entre $n$ usuários precisa de uma chave diferente, o total é $n(n-1)\mathrm{/}2$. Para 100 usuários, são 4.950 chaves. Mecanismos de chave pública permitem que as partes estabeleçam chaves de sessão sem distribuir antecipadamente um segredo separado para cada par.

Bob publica $K_B^{+}$ e mantém $K_B^{-}$ privada. Alice pode cifrar para Bob sem primeiro compartilhar um segredo com ele. Recuperar a chave privada a partir da chave pública deve ser computacionalmente inviável.

Calcule uma troca RSA simplificada

O RSA começa com os números primos $p$ e $q$. Calcule $n=pq$ e $z=(p-1)(q-1)$. Escolha um expoente público $e$ relativamente primo a $z$ e encontre $d$ tal que $ed<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>z=1$. A chave pública é $(n,e)$; a chave privada é $(n,d)$. Para um número de mensagem menor que $n$:

Use os números primos simplificados 11 e 13. Então $n=143$ e $z=120$. Com $e=7$, escolha $d=103$ porque $7\times 103=721=6\times 120+1$. Para $m=9$, a elevação repetida ao quadrado resulta em $9^2<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>143=81$ e $9^4<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>143=126$. Combinar as potências resulta em $9^7<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>143=48$. A decifragem retorna ${48}^{103}<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>143=9$.

Esses números mostram a aritmética; o RSA na prática usa módulos de pelo menos 2.048 bits. Fatorar o módulo revela os números primos e permite recuperar a chave. A cifragem RSA real também usa preenchimento OAEP aleatorizado: o RSA de livro sem preenchimento repete seu texto cifrado quando uma mensagem se repete.

Estabeleça um segredo com Diffie–Hellman

O Diffie–Hellman estabelece um segredo compartilhado sem enviá-lo. Alice e Bob publicam um número primo $p$ e um gerador $g$. Alice mantém $a$ em segredo e envia $A=g^a<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>p$. Bob mantém $b$ em segredo e envia $B=g^b<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>p$. Alice calcula $B^a<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>p$ e Bob calcula $A^b<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>p$; ambos obtêm $g^{ab}<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>p$.

Para $p=29$, $g=2$, $a=5$ e $b=12$, Alice envia 3 e Bob envia 7. O cálculo de Alice é $7^5<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>29=16$; o de Bob é $3^{12}<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>29=16$. O pequeno exemplo é fácil de quebrar; grupos grandes tornam inviável recuperar os expoentes secretos. Trocas de curvas elípticas como X25519 têm o mesmo objetivo com chaves menores.

Autentique a troca

O Diffie–Hellman simples não identifica nenhum dos participantes. Trudy pode substituir os valores públicos pelos seus e criar dois segredos compartilhados separados, um com Alice e outro com Bob. Ela então lê o tráfego e o cifra novamente. Um protocolo autenticado vincula os valores trocados a identidades confiáveis, usando assinaturas e certificados ou um segredo compartilhado já estabelecido.

Os protocolos usam cifragem híbrida: o trabalho com chave pública estabelece uma chave de sessão, e o AES ou o ChaCha20 trata o volume principal dos dados. O RSA pode transportar uma chave de sessão aleatória, mas o roubo posterior da chave privada RSA expõe trocas registradas. Valores Diffie–Hellman efêmeros novos, apagados após o uso, proporcionam sigilo futuro contra o roubo posterior de chaves de autenticação de longo prazo.

Um computador quântico suficientemente grande quebraria o RSA e o Diffie–Hellman clássico. O ML-KEM, padronizado pelo NIST na FIPS 203 em 2024, trata do estabelecimento de chaves pós-quântico. Um sistema híbrido como X25519MLKEM768 combina componentes clássicos e pós-quânticos. Esse uso de “híbrido” descreve dois mecanismos de estabelecimento de chaves; o volume principal dos dados ainda usa cifragem simétrica, incluindo chaves de 256 bits para uma forte margem de segurança.

Uma verificação de integridade deve resistir a uma atacante deliberada, não apenas a erros acidentais. Uma soma de verificação de rede e um hash criptográfico têm finalidades diferentes, e nenhum dos dois autentica uma mensagem por si só.

Entenda as propriedades do hash

Uma função hash criptográfica associa uma mensagem de qualquer comprimento a um resumo de tamanho fixo. O SHA-256 produz 256 bits, geralmente escritos como 64 dígitos hexadecimais. Bons hashes têm três propriedades distintas de resistência:

Colisões existem porque um conjunto finito de resumos representa uma quantidade maior de mensagens possíveis. Segurança significa que encontrar uma colisão útil é inviável. MD5 e SHA-1 são vulneráveis a ataques práticos de colisão e não são adequados para assinaturas e certificados. O SHA-3 oferece outra família moderna de hashes.

Pequenas alterações na mensagem se espalham pelo resumo: esse é o efeito avalanche. Alterar “Pay Ana 100” para “Pay Ana 900” muda 124 bits da saída do SHA-256; os resumos começam com ECD0D31E e 21736708. Em comparação, a soma de verificação da internet tanto de “PAY 1290” quanto de “PAY 9012” é 0xEC3B: trocar as palavras de 16 bits relevantes preserva sua soma. Uma soma de verificação projetada para detectar danos aleatórios é fácil de preservar deliberadamente.

Acrescente o segredo que a atacante não possui

Enviar uma mensagem e seu hash abertamente não resolve o problema da adulteração ativa. Trudy substitui tanto a mensagem quanto seu resumo, então o recálculo do destinatário passa. Um código de autenticação de mensagem, ou MAC, acrescenta uma chave de autenticação secreta compartilhada por Alice e Bob.

Alice envia $m$ e $\mathrm{M}\mathrm{A}\mathrm{C}(s,m)$. Bob calcula uma etiqueta a partir da mensagem recebida e de sua própria cópia de $s$ e então compara as etiquetas. Se Trudy alterar “Pay Ana 100” para “Pay Ana 900”, Bob calculará a etiqueta para o texto alterado. A etiqueta antiga copiada por Trudy não passa na comparação. A mensagem ainda pode ser legível: um MAC fornece integridade e autenticação de quem possui a chave, não confidencialidade.

O HMAC usa um hash em duas etapas aninhadas que incorporam a chave. HMAC-SHA256 é uma escolha padronizada. Usar simplesmente $H(s\mathrm{\parallel }m)$ com SHA-256 é inseguro: uma extensão de comprimento pode permitir que uma atacante acrescente bytes e calcule uma etiqueta correspondente sem descobrir a chave. A construção do HMAC evita essa falha.

Separe autenticidade de atualidade

Uma mensagem antiga com seu MAC original ainda tem uma etiqueta válida. Para rejeitar repetições, autentique um número de sequência ou um novo desafio junto com a mensagem e verifique esse valor de atualidade no destinatário. Acrescentar um número não autenticado é insuficiente, pois Trudy poderia alterá-lo.

Ambos os detentores da chave compartilhada podem criar etiquetas válidas. Portanto, terceiros não podem usar um MAC para decidir qual detentor escreveu uma mensagem. Assinaturas digitais fornecem essa prova verificável publicamente. Ao combinar cifragem com um MAC separado, use chaves separadas e cifre antes de aplicar o MAC, autenticando o texto cifrado; uma construção AEAD oferece uma alternativa integrada.

Uma assinatura digital permite que qualquer pessoa verifique uma prova criada com uma chave privada. Quem verifica precisa tanto de uma verificação de assinatura confiável quanto de um vínculo confiável entre a chave pública e a identidade que ela representa.

Assine e verifique uma mensagem

Quem assina usa uma chave privada; quem verifica usa a chave pública correspondente. As assinaturas vinculam sua prova à mensagem, de modo que uma alteração faz a verificação falhar. A chave privada deve permanecer sob o controle de quem assina. Isso sustenta o não repúdio: uma prova da assinatura verificável independentemente, ao contrário de um MAC que qualquer detentor da chave compartilhada poderia criar.

Os esquemas processam um resumo ou uma representação codificada da mensagem. Em um modelo RSA simplificado, a assinatura é $K_B^{-}(H(m))$. O destinatário calcula o resumo e o compara com o valor recuperado usando a chave pública de Bob. Assinaturas RSA reais acrescentam uma codificação como RSASSA-PSS; ECDSA e Ed25519 usam uma aritmética diferente. Assinar não é um método de uso geral para cifrar uma mensagem com uma chave privada.

Para uma chave RSA simplificada com $n=143$, $e=7$ e $d=103$, suponha que o número do resumo seja 20. Bob calcula $\sigma ={20}^{103}<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>143=58$. Alice obtém ${58}^7<mrow><mi\; mathvariant="normal">m</mi><mi\; mathvariant="normal">o</mi><mi\; mathvariant="normal">d</mi></mrow>143=20$ e o compara com seu próprio resumo. Se o texto alterado tiver resumo 21, o 20 recuperado não corresponderá. A resistência a colisões importa porque duas mensagens com o mesmo resumo poderiam, caso contrário, compartilhar a mesma entrada para assinatura.

Vincule uma chave a um nome

Trudy pode gerar um par de chaves perfeitamente válido. Se ela identificar a chave pública desse par como “Bob”, a verificação bem-sucedida da assinatura, sozinha, não revelará a substituição. Um certificado vincula uma identidade a uma chave pública sob a assinatura de uma autoridade certificadora.

Um certificado X.509 de site contém nomes de domínio no campo de nome alternativo do titular, a chave pública do titular, um emissor, datas de validade e a assinatura do emissor. Um servidor normalmente fornece seu certificado final e os certificados intermediários. O cliente verifica essa cadeia até uma raiz já confiável em seu sistema operacional ou navegador. A autoassinatura de uma raiz não é o que a torna confiável; sua inclusão no repositório de confiança fornece essa confiança inicial.

Quem verifica confere as assinaturas ao longo da cadeia, as datas de validade, o nome pretendido, o uso permitido e as informações de revogação, quando disponíveis. Uma cadeia que termina em uma raiz desconhecida não se torna confiável apenas porque suas assinaturas são matematicamente válidas.

Exija prova de posse da chave

Certificados são públicos e podem ser copiados. Um servidor também deve demonstrar controle da chave privada associada assinando dados novos da negociação. Um arquivo de certificado roubado, sozinho, não pode produzir essa assinatura. Um certificado válido comum de site comprova o controle do nome de domínio; ele não comprova que o conteúdo ou a atividade comercial do site seja honesto.

A autenticação das entidades nas extremidades pergunta quem está participando agora. Uma mensagem antiga válida pode provar que alguém já possuiu uma chave, mas não provar que o remetente atual a possui.

Quebre as versões fracas

Alice primeiro envia “Sou Alice”. Trudy pode enviar as mesmas palavras. Acrescentar o endereço IP de origem de Alice não funciona porque um datagrama pode conter um endereço falsificado. Enviar uma senha a expõe a quem observa. Cifrar uma senha fixa oculta seu conteúdo, mas deixa uma prova reutilizável: Trudy registra o texto cifrado e o envia em outra entrada.

Esse é um ataque de repetição. A atacante não decifra nem altera a prova antiga. A fraqueza é que Bob aceita os mesmos bytes em uma nova sessão. Uma cifra mais forte não corrigiria esse erro de protocolo.

Faça a prova depender desta tentativa

Bob envia um valor de uso único novo e imprevisível, um desafio usado uma vez nesse contexto de autenticação. Alice retorna um valor que exige sua chave secreta, como um HMAC do desafio. Bob calcula a resposta esperada com sua cópia da chave. Uma resposta copiada de um desafio anterior não corresponderá.

Por exemplo, o desafio de segunda-feira é 0x7F3A91C2. Trudy captura sua resposta válida. Na terça-feira, Bob envia 0x0B66E4D9. Repetir a resposta de segunda-feira falha porque a etiqueta esperada na terça-feira é calculada a partir de bytes diferentes. Os valores hexadecimais curtos ilustram a troca; desafios reais precisam de bits aleatórios suficientes para evitar previsão ou repetição úteis.

A imprevisibilidade também impede a coleta antecipada. Se for fácil adivinhar o próximo desafio de Bob, Trudy poderá se passar por Bob, pedir que Alice responda a esse desafio futuro e depois apresentar a resposta coletada a Bob. Um desafio deve estar vinculado à troca atual do protocolo, não apenas parecer diferente do anterior.

Autentique com chaves públicas

Alice pode assinar um novo desafio usando sua chave privada. Bob verifica a assinatura usando a chave pública verdadeira dela. Se Bob aceitar uma chave pública substituta fornecida por Trudy, ela poderá assinar o desafio de Bob. Os certificados estabelecem o vínculo entre identidade e chave; a nova assinatura prova a posse atual dessa chave.

Na autenticação mútua, as duas partes provam suas identidades. Um protocolo deve distinguir seus papéis e vincular as provas à sessão para que a resposta de uma parte não possa simplesmente ser refletida como a da outra. O TLS web comum geralmente autentica o servidor com um certificado; o usuário então se autentica dentro desse canal protegido usando uma senha ou chave de acesso. Conexões entre serviços e VPNs costumam autenticar as duas extremidades.

Proteja o que vem depois da entrada

Uma autenticação bem-sucedida não protege o tráfego posterior em texto claro. Trudy poderia esperar a entrada terminar e então inserir comandos ou sequestrar a conexão. Negociações seguras estabelecem chaves de sessão, e as mensagens seguintes recebem proteção de integridade vinculada a essa sessão.

O desafio-resposta também não fortalece automaticamente uma senha humana fraca. Se uma pessoa que observa puder recalcular uma resposta capturada para cada palpite de senha, ela poderá executar um ataque de dicionário offline. A verificação de atualidade impede a repetição, enquanto um segredo forte ou uma troca apropriada autenticada por senha trata dos palpites; as duas proteções resolvem problemas diferentes.

O TLS fornece a dois processos de aplicação um canal confidencial e autenticado sobre um fluxo de bytes confiável. No caso comum do HTTPS, o HTTP usa TLS sobre TCP, normalmente na porta 443. Uma biblioteca de aplicação como OpenSSL ou BoringSSL cuida do TLS; o TCP transporta seus bytes sem interpretá-los.

Estabeleça chaves e depois proteja registros

Uma negociação autentica a outra parte e estabelece material de chave compartilhado. A derivação de chaves transforma esse material em segredos separados para o tráfego da negociação e os dados da aplicação, com chaves diferentes para cada direção. Um registro enviado por Alice não pode simplesmente ser refletido de volta como se fosse de Bob, pois a direção de recepção usa uma proteção diferente.

O TLS divide os dados em registros, permitindo que o destinatário verifique uma parte por vez. Um registro em texto claro transporta no máximo $2^{14}=16.384$ bytes de conteúdo. Seu cabeçalho curto inclui um tipo, um campo de versão legado e o comprimento. A cifragem acrescenta sobrecarga, então um registro cifrado é maior que o conteúdo original. No TLS 1.3, o tipo externo do registro protegido não revela diretamente o tipo de conteúdo da aplicação ou da negociação nele contido.

O TLS 1.3 exige AEAD. O destinatário verifica a etiqueta de autenticação de um registro antes de liberar seu texto claro para a aplicação. Se Trudy alterar uma requisição HTTP protegida, a verificação da etiqueta falhará: o destinatário encerrará a conexão, usando bad_record_mac para uma falha na proteção do registro. O TLS detecta interferências; ele não transforma bytes alterados maliciosamente em uma requisição válida.

Conte os registros em cada direção

Cada remetente e destinatário mantém um número de sequência implícito de registro. Ele não é enviado no cabeçalho do registro TLS. O TLS 1.3 aplica XOR entre ele e um IV específico da direção para produzir o valor de uso único da AEAD. Repetir um registro antigo em uma nova posição usa o número esperado errado e faz a autenticação falhar. Apagar ou reordenar registros protegidos também interrompe a sequência esperada quando os bytes posteriores são processados.

Os números de sequência do TCP continuam tratando da entrega e da reordenação comuns. Eles não autenticam a outra parte: uma atacante que controla o caminho pode falsificar cabeçalhos TCP. A contagem de registros do TLS está vinculada à proteção por chave secreta, então uma entrega TCP bem-sucedida não implica, por si só, uma verificação TLS bem-sucedida.

Detecte um encerramento incompleto

Suponha que Bob espere um documento, mas a conexão TCP seja encerrada na metade. Um FIN falsificado ou um enlace interrompido pode encerrar a entrega de transporte sem provar que o remetente TLS terminou. O TLS usa o alerta protegido close_notify para sinalizar um fim ordenado de seu fluxo de envio. Sem ele, o destinatário deve considerar um possível truncamento e usar as regras de completude da aplicação; um EOF TCP inesperado não é um marcador de fim autenticado.

Uma atacante sempre pode descartar pacotes e impedir o avanço. Confidencialidade e integridade não garantem disponibilidade. Um comprimento completo de mensagem HTTP pode ajudar uma aplicação a reconhecer que uma mensagem chegou, mas essa é uma verificação separada do encerramento ordenado do TLS.

Diferencie protocolos relacionados

O TLS 1.3 é especificado pela RFC 9846, que substituiu a RFC 8446 em 2026. O TLS 1.2 continua em uso; SSL 2.0/3.0 e TLS 1.0/1.1 estão obsoletos. O DTLS adapta o projeto de segurança a datagramas. O QUIC transporta a negociação do TLS 1.3 dentro de seu protocolo de transporte baseado em UDP e depois protege os próprios pacotes QUIC; ele não envia registros comuns de TLS sobre TCP por UDP.

Uma negociação TLS deve estabelecer um segredo e mostrar a quem ele pertence. Em uma troca completa do TLS 1.3 baseada em certificado, o acordo efêmero de chaves fornece novo material de chave e as assinaturas vinculam a negociação à identidade do servidor.

Acompanhe os conjuntos de mensagens

1. ClientHello oferece versões, conjuntos de cifras AEAD, grupos de troca de chaves, algoritmos de assinatura, dados aleatórios e um ou mais valores key_share. Geralmente identifica o servidor por meio do SNI.
2. ServerHello seleciona parâmetros e fornece o valor de troca de chave do servidor. As duas partes calculam material de chave compartilhado e derivam as chaves de tráfego da negociação.
3. O servidor envia as mensagens cifradas EncryptedExtensions, Certificate, CertificateVerify e Finished. CertificateVerify assina uma entrada estruturada que inclui o hash do registro da negociação; Finished autentica esse registro com uma chave MAC derivada.
4. O cliente verifica a cadeia, o nome do servidor, a assinatura e Finished, e então envia seu próprio Finished. O tráfego da aplicação usa segredos de tráfego derivados separadamente.

O certificado do servidor associa um nome a uma chave pública. CertificateVerify prova o controle da chave privada nessa troca. Finished detecta interferências no registro da negociação. São verificações separadas: derivar um segredo compartilhado com sucesso não estabelece a identidade do servidor.

Conte os tempos de ida e volta

Com RTT de 40 ms, ignorando atrasos de processamento e transmissão, o estabelecimento do TCP leva 40 ms e uma negociação completa do TLS 1.3 acrescenta 40 ms. O cliente envia sua requisição em 80 ms; uma resposta pode retornar por volta de 120 ms. Uma negociação completa do TLS 1.2 acrescenta dois RTTs após o TCP, então os tempos correspondentes são 120 ms e 160 ms. O QUIC combina o estabelecimento do transporte com a negociação TLS, permitindo que uma nova conexão envie sua requisição após um RTT, em 40 ms.

Uma HelloRetryRequest acrescenta um tempo de ida e volta quando o servidor precisa de um valor de troca de chave diferente. O suporte compartilhado a um grupo não basta se a oferta inicial não contiver um valor aceitável.

Vincule a negociação e separe os segredos

Se Trudy remover conjuntos de cifras fortes de um ClientHello em trânsito, o cliente e o servidor registrarão versões diferentes da negociação. A autenticação desses registros falhará. O TLS também inclui sinalização de rebaixamento de versão quando um servidor capaz negocia uma versão mais antiga.

O processo de derivação de chaves usa HKDF, baseado em HMAC, para derivar segredos específicos para cada finalidade. Chaves de negociação protegem mensagens de estabelecimento; chaves de aplicação protegem dados posteriores. KeyUpdate substitui as chaves de tráfego da aplicação durante uma conexão longa. O TLS 1.3 removeu o transporte estático de chaves RSA: um certificado RSA ainda pode autenticar uma negociação por meio de assinatura, enquanto o acordo efêmero de chaves proporciona sigilo futuro.

Retome sem repetir a autenticação por certificado

Após o estabelecimento, NewSessionTicket permite que as partes preparem a retomada. Elas derivam uma PSK de retomada a partir do segredo de retomada e do valor de uso único do ticket; mais tarde, o cliente apresenta o ticket como identificador da PSK e prova que a possui. A retomada pode incluir uma nova troca Diffie–Hellman para obter sigilo futuro.

O 0-RTT envia dados antecipados com o primeiro conjunto de mensagens, mas esses dados podem ser repetidos. Use-o apenas quando for seguro repetir uma requisição, nunca para uma ação de pagamento repetível sem proteção. As proteções da negociação posterior não tornam retroativamente os dados antecipados resistentes à repetição.

O TLS mútuo acrescenta um certificado de cliente solicitado e uma prova de posse de sua chave privada. Grupos híbridos pós-quânticos como X25519MLKEM768, definido na RFC 10024, combinam X25519 e ML-KEM-768 para que o sigilo se mantenha se pelo menos um dos componentes permanecer seguro.

A cifragem só é útil quando chega à parte pretendida. Um cliente deve validar a identidade associada às chaves antes de enviar dados sensíveis da aplicação.

Verifique toda a declaração de identidade

Um cliente TLS verifica se a cadeia de certificados chega a uma raiz em seu repositório de confiança, se as assinaturas e os períodos de validade passam nas verificações, se o nome solicitado corresponde ao certificado e se o certificado permite a autenticação de servidor TLS. Quando verifica a revogação, essa verificação também deve passar. CertificateVerify demonstra então a posse da chave privada correspondente.

A correspondência de nomes diz respeito ao hospedeiro que o cliente pretendia contatar, não a um nome que o servidor sugere após a conexão. Um certificado para *.example.com cobre www.example.com e mail.example.com. Ele não cobre example.com nem a.b.example.com: o curinga substitui exatamente um componente do nome. Um certificado perfeitamente válido para o domínio errado ainda falha na autenticação.

Por exemplo, um cliente solicita shop.example.net, mas recebe um certificado confiável e dentro da validade para *.example.com. A cadeia e as datas podem passar; a verificação do nome falha. O cliente deve rejeitar essa conexão. Um certificado não é uma autorização geral para seu titular se passar por qualquer servidor.

Entenda uma interceptação cifrada

Se a verificação de certificados estiver desativada, Trudy poderá encerrar o TLS vindo do cliente e criar uma segunda conexão TLS com o servidor real. Ambos os enlaces são cifrados, mas Trudy tem acesso ao texto claro entre eles. Portanto, verificar a cifragem sem verificar a outra parte deixa o ataque passar despercebido. Mantenha a validação de certificados ativada e trate uma falha na verificação de identidade como uma falha de conexão.

Um proxy de inspeção TLS de uma organização segue deliberadamente uma estrutura relacionada. Dispositivos gerenciados confiam na raiz da organização, permitindo que seu proxy emita certificados que eles aceitam. O proxy encerra uma conexão segura e inicia outra. O caminho do navegador ao servidor passa então a ter uma extremidade confiável adicional com acesso ao texto claro.

Proteja a primeira requisição

Na remoção da proteção SSL/TLS, uma atacante mantém o lado do usuário em HTTP enquanto contata o site por HTTPS. Isso pode começar quando um navegador tenta acessar um endereço simples por HTTP pela primeira vez. O HSTS informa ao navegador que use HTTPS em visitas posteriores. Uma entrada pré-carregada pode impor HTTPS mesmo antes da primeira visita; uma política aprendida apenas após uma visita HTTPS bem-sucedida não pode proteger retroativamente uma requisição HTTP anterior.

Identifique o que continua visível

O TLS 1.3 cifra o certificado do servidor e o conteúdo da aplicação, mas quem observa ainda vê endereços de rede, portas, momentos e tamanhos dos registros. O SNI comum do ClientHello expõe o nome do servidor solicitado. O ClientHello cifrado, padronizado na RFC 9849, protege esse nome quando implementado. Uma consulta DNS não protegida separadamente também pode revelar o nome de destino.

O TLS protege dados entre suas extremidades enquanto trafegam. Ele não pode corrigir malware no cliente, um servidor comprometido, dados armazenados de forma insegura ou falhas da aplicação. Também não pode impedir o descarte de pacotes. O IPsec trata de um escopo diferente: aplica proteção na camada de rede ao tráfego IP selecionado sem exigir que cada aplicação invoque o TLS. Usar ambos pode proteger trechos diferentes da mesma rota.

O IPsec aplica proteção na camada IP, onde pode cobrir tráfego TCP, UDP e ICMP sem alterar suas aplicações. Suas extremidades podem ser hospedeiros individuais ou gateways que conectam redes inteiras.

Escolha um protocolo e um modo

O AH usa o protocolo IP de número 51; o ESP usa o 50. O ESP é a escolha usual para o tráfego de VPN moderno. A proteção do AH inclui campos de endereço que o NAT reescreve, tornando a tradução comum de endereços incompatível com sua verificação de autenticação. O ESP não autentica o cabeçalho IP externo.

No modo de transporte, o cabeçalho ESP fica entre o cabeçalho IP original e o segmento de transporte. Os roteadores ainda veem a origem e o destino originais. No modo túnel, um novo cabeçalho IP endereça as duas extremidades do túnel, e o datagrama IP original trafega dentro dele. Com ESP cifrado em modo túnel, observadores externos não podem ler os endereços dos hospedeiros originais nem as portas de transporte, mas podem ler os endereços dos gateways necessários ao encaminhamento. O AH em modo túnel continua sem fornecer confidencialidade.

O IPsec pode fornecer confidencialidade, integridade, autenticação da origem e proteção antirrepetição. Os serviços efetivos dependem do protocolo, dos algoritmos e da política; escolher AH não fornece cifragem apenas porque ele pertence ao IPsec.

Mantenha o estado em cada direção

Uma associação de segurança, ou SA, define uma direção do tráfego protegido. Ela mantém algoritmos, chaves, modo, extremidades, estado da sequência, estado da janela de repetição e um tempo de vida. Um índice de parâmetros de segurança de 32 bits, ou SPI, ajuda o destinatário a selecionar a SA correta. Ele é um identificador, não uma chave de cifragem, e pode trafegar abertamente no cabeçalho ESP.

O tráfego nos dois sentidos precisa de duas SAs IPsec. Um gateway da matriz que atende uma filial e 50 laptops em viagem tem 51 pares de comunicação. Com um par ESP por parte, ele precisa de $2\times 51=102$ SAs ESP, além de uma SA IKE por parte para gerenciamento. A substituição de chaves ou classes de tráfego separadas podem acrescentar outras SAs; a contagem aqui segue o projeto declarado de um par por parte.

Embora o encaminhamento IP não seja orientado a conexão, esse estado criptográfico é mantido nas extremidades que aplicam a proteção. Os roteadores entre elas não precisam conhecer as chaves de sessão nem manter a SA IPsec.

Separe a política do estado ativo de proteção

A base de dados de políticas de segurança (SPD) busca correspondências em seletores de tráfego, como endereços, protocolos e portas. Sua decisão é proteger o tráfego selecionado, permitir que ele passe sem proteção ou descartá-lo. A base de dados de associações de segurança (SAD) armazena os parâmetros e o estado mutável das SAs estabelecidas. Um destinatário usa o SPI do pacote e o contexto relevante para encontrar esse estado.

A SPD responde “O que deve acontecer com este tráfego?”. A SAD responde “Quais chaves e contadores estabelecidos implementam essa proteção?”. Uma política de VPN pode proteger sub-redes de escritórios enquanto permite que outro destino passe sem proteção. Ter o IPsec ativado não significa que todo pacote enviado por um hospedeiro entre em um túnel.

Uma VPN entre sites une duas redes por meio de gateways; uma VPN de acesso remoto une o dispositivo de um usuário a um gateway. Ambas encapsulam o tráfego para que roteadores comuns da internet possam transportá-lo entre as extremidades que aplicam a proteção.

Estabeleça as associações

O IKEv2 estabelece chaves e SAs. IKE_SA_INIT troca propostas de algoritmos, valores Diffie–Hellman e valores de uso único. As chaves resultantes protegem IKE_AUTH, em que as partes autenticam suas identidades e criam o primeiro par de SAs ESP. Com assinaturas ou uma chave pré-compartilhada, isso normalmente leva quatro mensagens em dois tempos de ida e volta. A autenticação EAP pode acrescentar trocas IKE_AUTH. Trocas posteriores criam mais SAs ou substituem chaves que estão expirando.

O IKE usa inicialmente a porta UDP 500. Quando um NAT é detectado, o IKE e o ESP encapsulado em UDP usam a porta 4500. O próprio ESP não tem portas TCP ou UDP; o encapsulamento permite que mapeamentos NAT baseados em portas o transportem de forma confiável, inclusive para vários clientes. O transporte externo muda, enquanto o ESP continua protegendo o tráfego interno.

Envie um datagrama

O hospedeiro 10.1.0.5 envia para 10.2.0.9. O gateway da filial é 198.51.100.1; a matriz usa 203.0.113.1.

1. A SPD da filial seleciona a proteção por túnel para a sub-rede de destino, e o gateway obtém a SA correspondente.
2. Ele trata o datagrama original completo como carga útil interna do ESP, acrescentando um trailer com preenchimento, comprimento do preenchimento e próximo cabeçalho 4 para IPv4.
3. Ele cifra o datagrama interno e o trailer e acrescenta o cabeçalho ESP contendo o SPI e o próximo número de sequência. A proteção de integridade cobre o cabeçalho ESP e a carga útil protegida; um algoritmo AEAD integra a cifragem e a geração da etiqueta.
4. Ele acrescenta o cabeçalho IP externo, endereçado do gateway da filial ao gateway da matriz. O ESP nativo usa o protocolo 50; a travessia de NAT transporta ESP dentro de UDP.

Os roteadores da internet veem os endereços externos das extremidades. Os endereços e as portas internos estão dentro da carga útil cifrada.

Receba e autentique

A matriz usa o SPI para selecionar uma SA, verifica preliminarmente o número de sequência, verifica a integridade e decifra. Ela atualiza o estado confiável de proteção contra repetição apenas depois que a autenticação é bem-sucedida. Remove a proteção do túnel e encaminha o datagrama original recuperado para 10.2.0.9. O campo próximo cabeçalho identifica a carga útil recuperada: 4 para IPv4, 41 para IPv6 ou 6 para TCP em um exemplo de ESP em modo de transporte.

Permita reordenação, mas rejeite repetição

Uma janela antirrepetição de 64 pacotes cujo maior número autenticado é 1000 cobre de 937 a 1000. O pacote 990, ainda não visto, pode chegar atrasado e ser aceito. Sua próxima cópia é rejeitada. O pacote 930 é antigo demais. Um pacote válido 1005 move o intervalo para 942 até 1005. Uma atacante não consegue mover a janela confiável apenas enviando um pacote não autenticado com um número grande.

Uma VPN protege apenas o caminho entre suas extremidades. Após a remoção do túnel, a entrega interna precisa de proteção própria quando necessário. O tunelamento dividido envia parte do tráfego fora da VPN. Uma VPN comercial torna seu provedor outro operador de rede em quem se confia. VPNs baseadas em TLS/DTLS e o WireGuard usam outros protocolos para implementar túneis; “VPN” designa a organização da rede, não um protocolo de cifragem obrigatório.

Um quadro Wi-Fi fica disponível para rádios ao alcance. Uma atacante próxima pode capturar tráfego ou anunciar um gêmeo maligno, um ponto de acesso falso que usa o nome de uma rede conhecida. A segurança sem fio deve autenticar o acesso e proteger os quadros, não apenas ocultar o nome da rede.

Por que o WEP falhou

O WEP combinava um segredo compartilhado de 40 ou 104 bits com um IV público de 24 bits para inicializar o RC4. Sua verificação CRC-32 detectava erros, mas não era um autenticador com chave. O espaço de IVs tem apenas $2^{24}=\mathrm{16.777.216}$ possibilidades; IVs escolhidos aleatoriamente chegam a uma chance de repetição de cerca de 50% após aproximadamente 4.823 quadros.

Um IV repetido com a mesma chave repete a sequência de chave. Aplicar XOR a dois textos cifrados revela então o XOR dos textos claros. A estrutura linear do CRC-32 também permite que uma atacante modifique bits e ajuste a verificação de erros. Fraquezas na programação de chaves do RC4 permitiam a recuperação da chave a partir de quadros capturados. Essas falhas envolvem reutilização de valores de uso único, integridade não autenticada e construção da cifra; simplesmente escolher um nome de rede menos óbvio não corrige nenhuma delas.

Substitua a proteção dos quadros

O WPA2, baseado no IEEE 802.11i, usa CCMP: cifragem AES em modo contador combinada com integridade CBC-MAC. Seu número de pacote ajuda a construir valores de uso único e a rejeitar repetições. O WPA/TKIP anterior foi uma medida transitória para hardware antigo e está obsoleto.

A conexão passa pela descoberta, pela autenticação que estabelece uma chave mestra par a par (PMK), pela negociação em quatro etapas e pela transferência protegida. No WPA2-Personal, uma frase secreta e o nome da rede produzem uma PMK de 256 bits por meio de PBKDF2 com 4.096 iterações de HMAC-SHA1. Todos que usam essa frase secreta e esse SSID derivam a mesma PMK. A autenticação ainda não forneceu uma chave de tráfego nova para cada associação.

Acompanhe a negociação em quatro etapas

1. O ponto de acesso envia ANonce.
2. A estação gera SNonce e deriva a PTK a partir da PMK, dos dois valores de uso único e dos dois endereços MAC. Ela envia SNonce e um código de integridade de mensagem (MIC).
3. O ponto de acesso deriva a mesma PTK e verifica o MIC. Ele fornece a chave de tráfego de grupo (GTK) em uma mensagem protegida.
4. A estação confirma o recebimento e a instalação.

A PMK não é enviada na negociação. Novos valores de uso único produzem novas chaves de sessão a partir da PMK existente. A GTK atende ao tráfego de grupo, enquanto a chave par a par atende à comunicação entre essa estação e o ponto de acesso.

Saiba o que a senha permite

Uma negociação WPA2-Personal capturada permite um teste de palpites de senha offline: derive uma PMK e uma PTK candidatas, recalcule o MIC e compare-o com o capturado. Um usuário que já conhece a frase secreta da rede também pode derivar a PTK de outro usuário a partir da negociação capturada desse usuário. O KRACK explorou a reinstalação de chaves e a reutilização de valores de uso único em implementações; correções tratam desse defeito.

O WPA2-Enterprise usa 802.1X. A estação é a suplicante; o ponto de acesso é o autenticador e retransmite EAP a um servidor de autenticação, geralmente por RADIUS. O EAP-TLS usa certificados de cliente; PEAP e EAP-TTLS transportam credenciais dentro da proteção TLS. Os usuários obtêm material de chave individual e podem ter o acesso revogado separadamente. Em qualquer um dos modos, a proteção Wi-Fi termina no ponto de acesso; o TLS pode continuar a proteção até um servidor de aplicação.

Um enlace sem fio protegido precisa de uma maneira segura de estabelecer suas chaves. O WPA3 altera o estabelecimento de chaves Wi-Fi baseado em senha, enquanto as redes celulares começam com um segredo de assinante mantido pelo SIM e pela rede de origem.

Melhore o Wi-Fi baseado em senha

O WPA3-Personal usa SAE, autenticação simultânea de iguais, para estabelecer a PMK. Uma troca SAE capturada não fornece o teste de senha offline do WPA2: cada palpite exige interação ativa. O SAE também proporciona sigilo futuro, então descobrir a senha depois não expõe sessões anteriores registradas. A negociação em quatro etapas deriva então as chaves de tráfego da PMK.

O WPA3 exige quadros de gerenciamento protegidos (PMF), que autenticam quadros robustos de gerenciamento, como mensagens de desautenticação. Isso bloqueia mensagens de encerramento falsificadas; não pode impedir a interferência deliberada de rádio. O WPA3-Enterprise mantém o 802.1X e oferece um modo de segurança opcional de 192 bits que usa escolhas de algoritmos mais fortes, como GCMP-256.

O modo de transição aceita WPA2 e WPA3 sob um nome de rede. Sua compatibilidade pode expor dispositivos ao caminho WPA2, mais fraco. Na operação em 6 GHz, WPA3 ou Enhanced Open é obrigatório, e o modo de transição WPA2 não é permitido; o WPA3-Personal usa o método hash-to-element do SAE.

O Enhanced Open, baseado em OWE, estabelece cifragem sem senha por meio de Diffie–Hellman. Ele impede que observadores passivos leiam os quadros, mas não autentica o ponto de acesso. Um gêmeo maligno pode estabelecer seu próprio enlace cifrado com o usuário.

Autentique um assinante de rede celular

Um segredo de longo prazo $K$ reside no USIM e na infraestrutura de autenticação da rede de origem: HSS no 4G e UDM/ARPF no 5G. Uma rede visitada recebe material de autenticação sem descobrir esse segredo de longo prazo.

No AKA do 4G, o MME da rede visitada obtém do HSS de origem um vetor contendo RAND, AUTN, XRES e material de chave. O celular recebe o desafio aleatório RAND e o token de autenticação AUTN. Seu USIM verifica AUTN para autenticar a rede e a atualidade do desafio e então calcula RES. A rede visitada aceita o assinante quando RES corresponde a XRES. Chaves derivadas protegem a comunicação posterior.

Isso é autenticação mútua. O GSM 2G anterior autenticava o celular perante a rede, mas não fornecia ao celular uma verificação equivalente da rede, permitindo ataques com estações rádio base falsas. A autenticação mútua ainda precisa de algoritmos seguros e tratamento correto das chaves; o segredo de longo prazo nunca precisa ser enviado à rede visitada.

Oculte a identidade permanente

No 5G, a rede de origem toma a decisão final de autenticação. O celular também pode ocultar a parte específica do assinante de sua identidade permanente, SUPI, usando a chave pública da rede de origem para formar o SUCI. As informações de roteamento permanecem legíveis para que a requisição possa chegar à rede de origem correta.

A ocultação exige um esquema de proteção provisionado. O esquema nulo deixa a identidade sem proteção. O SUCI protegido reduz a exposição a dispositivos que solicitam identidades permanentes; ele não torna anônima toda a atividade de rádio. Após o registro, identificadores temporários reduzem o uso rotineiro da identidade permanente. A segurança do acesso celular ainda não protege toda a rota até um servidor de aplicação: o TLS fornece essa proteção separada entre as extremidades da aplicação.

Um firewall aplica uma política entre redes ou segmentos de rede. Ele só funciona quando o tráfego relevante passa por ele, e o próprio firewall deve resistir a comprometimentos. Um filtro sem estado toma uma nova decisão para cada pacote usando campos do cabeçalho.

Leia uma regra com precisão

Uma regra pode corresponder a endereços IP de origem e destino, protocolo de transporte, portas, indicadores TCP, tipo ICMP, interface e direção. As regras são avaliadas em ordem: a primeira correspondência decide. Uma regra final de negação por padrão descarta pacotes que não corresponderam a nenhuma regra de permissão.

Para a rede 203.0.113.0/24, considere um servidor web em 203.0.113.10:

Um SYN de 198.51.100.7:50000 para a porta 443 do servidor web corresponde à regra 1. Um SYN para sua porta 22 chega à regra 3 e é descartado. Uma resposta da porta 443 do servidor com ACK ativado corresponde à regra 2. Cada campo de uma regra importa: um pacote que usa a porta UDP 443 não corresponde a uma regra de permissão para TCP.

Encontre regras encobertas

Suponha que uma regra anterior diga “permitir TCP de entrada para qualquer hospedeiro em 203.0.113.0/24 em qualquer porta”. Uma regra posterior que nega SSH para 203.0.113.10 não tem efeito: a permissão ampla anterior já decidiu. Verifique a ordem das regras junto com o texto de cada uma. Coloque as exceções pretendidas antes da regra geral que, de outra forma, corresponderia a elas.

A negação por padrão é útil porque acrescentar um novo serviço não o torna acessível silenciosamente. A permissão por padrão tem a consequência oposta: todo tráfego não bloqueado explicitamente passa. Nenhum dos padrões corrige uma tabela de regras mal ordenada.

Reconheça o atalho do ACK

Uma política pode bloquear pacotes SYN de entrada com ACK desativado para impedir novas conexões TCP iniciadas de fora. Para permitir respostas a clientes internos, um filtro sem estado pode permitir TCP de entrada da porta de origem 443 quando ACK estiver ativado. Trudy pode definir tanto essa porta de origem quanto esse indicador. O filtro não tem memória que prove que um hospedeiro interno realmente abriu a conexão.

Um indicador TCP ACK é um campo escolhido pelo remetente, não um certificado de sessão estabelecida. A filtragem com estado melhora essa decisão consultando o histórico de conexões.

Filtre endereços falsificados

A filtragem de entrada pode rejeitar pacotes vindos da internet que declarem um endereço de origem interno ou privado que não deveria chegar por essa interface. A filtragem de saída rejeita pacotes de saída cuja origem esteja fora das faixas atribuídas à organização. Essas verificações reduzem a falsificação de faixas não permitidas; elas não identificam um hospedeiro individual nem impedem que uma máquina se passe por outro endereço interno permitido.

Filtros sem estado inspecionam cabeçalhos, não o significado da aplicação. A porta 443 não prova que o tráfego seja HTTPS ou inofensivo. Uma conexão permitida pode transportar conteúdo malicioso. Por isso, a filtragem de pacotes atua junto com gateways de aplicação, controles nas extremidades e detecção de intrusões.

Um firewall com estado acrescenta contexto à filtragem de pacotes. Um gateway de aplicação acrescenta compreensão das requisições de uma aplicação. A separação de redes limita os locais que um servidor público comprometido pode alcançar.

Acompanhe o fluxo real

Um filtro de pacotes com estado registra endereços, portas, protocolo e estado da conexão. Quando um cliente interno abre uma conexão permitida, o firewall cria uma entrada e permite os pacotes de retorno apropriados. Uma nova conexão de entrada ainda precisa de sua própria permissão explícita. As entradas expiram quando a conexão é encerrada ou fica inativa.

Suponha que a tabela registre um fluxo TCP estabelecido de 203.0.113.25:51000 para 198.51.100.80:443. Um segmento de entrada que inverta esse par de endereços e portas pode corresponder ao seu estado. Um ACK de 192.0.2.66:443 para 203.0.113.30:52000 não corresponde à entrada. Sua porta de origem e seu indicador ACK satisfariam uma regra sem estado permissiva para respostas, mas não demonstram que ele pertence à conexão acompanhada.

O UDP não tem o estabelecimento de conexão do TCP. Filtros com estado aproximam uma conversa acompanhando pares de endereços e portas usados recentemente, com um tempo limite. Uma consulta DNS a um servidor escolhido abre uma oportunidade limitada para a resposta correspondente, não uma permissão para todo pacote que alegue ser DNS.

Inspecione a requisição da aplicação

Um gateway de aplicação, ou proxy, recebe e processa o tráfego da aplicação em nome dos usuários. Um proxy web pode autenticar um usuário e verificar um endereço ou conteúdo solicitado em relação à política. Para impor esse caminho, o filtro de pacotes deve impedir que os clientes abram conexões diretas que contornem o proxy.

Um proxy tem lógica específica do protocolo, custos de processamento e possíveis gargalos. Os clientes podem precisar de configuração, ou a rede pode interceptar o tráfego de forma transparente. O conteúdo cifrado permanece oculto para um proxy, a menos que ele encerre a conexão TLS e crie outra conexão adiante. Isso altera o conjunto de extremidades às quais se confia o texto claro.

Isole servidores públicos

Uma DMZ é um segmento separado para serviços públicos. O firewall permite tráfego selecionado da internet para a DMZ e restringe o acesso da DMZ à rede interna. Se um servidor web for comprometido, a atacante não obterá automaticamente acesso interno irrestrito. Toda conexão necessária da DMZ para a rede interna deve ter uma política específica.

Isso é defesa em profundidade: vários controles reduzem diferentes caminhos de falha. Um firewall de hospedeiro continua importante quando um laptop infectado já está dentro da rede ou outro enlace contorna o perímetro. Um projeto de confiança zero não concede acesso simplesmente porque um dispositivo está em uma sub-rede interna; ele autentica e autoriza requisições. A localização na rede pode informar a política, mas não substitui as verificações de identidade e permissão.

Um firewall pode permitir uma conexão que transporta um ataque. A detecção de intrusões examina o conteúdo e os padrões do tráfego em busca de sinais de uso indevido; a prevenção de intrusões pode agir diretamente com base nessas descobertas.

Escolha a detecção e o posicionamento

Um IDS geralmente observa uma cópia do tráfego e gera alertas. Um IPS fica no caminho do tráfego e pode descartar tráfego suspeito. Esse posicionamento permite o bloqueio imediato, mas acrescenta atraso de processamento e cria o risco de interromper o uso legítimo quando uma detecção está errada.

Snort e Suricata são exemplos de sistemas capazes de usar assinaturas. Uma regra pode reconhecer o caminho de requisição ../../etc/passwd, mais de 20 novas conexões à porta SSH 22 de uma origem em um minuto ou SYNs para centenas de portas. Esses padrões indicam comportamento suspeito; uma correspondência, por si só, não prova uma intrusão bem-sucedida.

Um detector de anomalias pode sinalizar uma grande mudança na taxa de tráfego ou na combinação de protocolos. Uma nova tarefa legítima de backup também pode parecer incomum. Um falso positivo é um alerta sobre atividade inofensiva; um falso negativo é um ataque que o detector deixa passar. Alterar um limiar de sensibilidade normalmente troca um tipo de erro pelo outro.

Calcule o que um alerta significa

Considere 1.000.000 de conexões inofensivas e 10 ataques por dia. Um detector identifica 99% dos ataques e gera falsos alertas em 0,1% das conexões inofensivas.

1. Alertas verdadeiros esperados: $10\times \mathrm{0,99}=\mathrm{9,9}$.
2. Alertas falsos esperados: $\mathrm{1.000.000}\times \mathrm{0,001}=1.000$.
3. Fração verdadeira esperada entre os alertas: $\mathrm{9,9}\mathrm{/}(\mathrm{9,9}+1.000)\approx \mathrm{0,0098}$, ou cerca de 1%.

Essas são quantidades esperadas ao longo de vários dias, então 9,9 não precisa ser um resultado diário inteiro. A taxa de detecção de 99% é a parcela de ataques detectados, não a chance de um alerta ser um ataque. Ataques raros e uma enorme população inofensiva explicam a diferença: esse é o problema da taxa-base.

Coloque sensores onde possam observar

Sensores logo dentro do firewall observam o tráfego que passou por ele. Sensores na DMZ observam o tráfego de serviços públicos; sensores internos podem revelar ataques que nunca cruzam o perímetro. Um sensor deve acompanhar o tráfego que recebe. Ele também deve remontar fragmentos e segmentos TCP de modo consistente com o destino; caso contrário, um ataque dividido entre pacotes pode escapar de uma verificação de padrões.

TLS e IPsec ocultam cargas úteis cifradas de um sensor de rede sem acesso à decifragem. Endereços, portas, momentos, comprimentos e campos não cifrados da negociação ainda podem ajudar. A inspeção da carga útil pode ocorrer em uma extremidade onde a decifragem acontece, mas uma cópia comum do fluxo cifrado não fornece esse texto claro.

Um sistema-isca é um engodo sem usuários comuns previstos. O contato é, portanto, suspeito e pode revelar técnicas de varredura ou ataque com menos ruído de fundo. Clientes configurados incorretamente ou tráfego automatizado inofensivo ainda podem contatá-lo, então uma isca não torna todo alerta conclusivo.