Análise forense: operações D4 - criptografia de fio com TLS 1.3 e cirurgia de SSH

Introdução: a premissa da rede hostil (zero trust físico)#

Se você administra servidores Linux em ambientes de produção, o tráfego que sai das suas Placas de Interface de Rede (NICs) passará inevitablemente por roteadores de operadoras terceiras, backbones transoceânicos públicos e proxies interceptadores antes de atingir o destino final. Em Operações D4 (Defesa de Rede), a premissa adotada é a de Zero Trust Físico: todo o tráfego em trânsito está sendo ativamente espelhado, capturado e armazenado por agentes maliciosos ou agências governamentais adversárias.

A principal ameaça dessa interceptação passiva é o ataque de armazenamento de longo prazo, conhecido como "Harvest Now, Decrypt Later" (Armazene Agora, Descriptografe Depois). Os atacantes coletam gigabytes de tráfego cifrado hoje com a expectativa de descriptografá-los retrospectivamente no futuro - seja pelo vazamento posterior da chave privada do servidor, pela descoberta de falhas matemáticas em algoritmos legados (como o RSA estático) ou pelo avanço da computação quântica.

Para mitigar essa ameaça de forma absoluta, a criptografia moderna exige o uso obrigatório de Perfect Forward Secrecy (PFS). Neste artigo, faço uma autópsia detalhada no protocolo de handshake do TLS 1.3 e uma cirurgia de endurecimento criptográfico (hardening) no OpenSSH, analisando a estrutura dos logs e dos pacotes no fio.

1. A autópsia do TLS 1.3: morte ao RSA key exchange#

O protocolo TLS 1.2, embora ainda amplamente suportado na internet por questões de retrocompatibilidade, carrega dívidas técnicas severas que comprometem a segurança a longo prazo. Ele aceita o modo de cifra CBC (vulnerável a ataques de temporização e preenchimento de bloco, como o Lucky Thirteen e a variante POODLE-TLS que afeta implementações específicas) e suporta a troca de chaves baseada puramente no RSA estático.

Se um atacante capturar um histórico de tráfego TLS 1.2 cifrado via RSA estático e, dez anos depois, conseguir comprometer a chave privada .pem armazenada no disco do servidor, ele conseguirá recalcular o segredo compartilhado (Pre-Master Secret) de cada sessão passada, descriptografando retroativamente todo o histórico de dados capturados.

O TLS 1.3 representa uma ruptura arquitetural completa:

• Forward Secrecy Obrigatório: Ele removeu por completo a troca de chaves RSA estática. Toda conexão TLS 1.3 utiliza obrigatoriamente algoritmos efêmeros baseados em curvas elípticas, como o ECDHE (Elliptic-Curve Diffie-Hellman Ephemeral).
• Depuração Criptográfica: Foram banidos algoritmos quebrados de hashing e cifragem simétrica, tais como MD5, SHA-1, RC4, DES, 3DES e o modo de cifra CBC.
• Cifragem AEAD: O TLS 1.3 suporta apenas cifras que utilizam criptografia autenticada com dados associados (AEAD): integridade e confidencialidade combinadas em uma única operação.

A otimização do handshake: 1-RTT (round-trip time)#

No TLS 1.2, o estabelecimento de uma sessão segura exigia duas viagens de ida e volta de pacotes entre o cliente e o servidor (2-RTT). No TLS 1.3, o cliente reduz essa latência para apenas uma viagem (1-RTT) especulando a curva criptográfica preferida do servidor (como a curva elíptica de alta velocidade X25519) e enviando a sua parte pública do segredo matemático (Key Share) diretamente no primeiro pacote do fluxo.

O fluxo de handshake do TLS 1.3 é representado a seguir:

Observe que, a partir do momento em que o Server Hello é respondido pelo servidor, a conexão já está estabelecida e toda a transposição de dados (incluindo o envio do certificado de segurança do servidor e a validação de assinatura) ocorre de forma cifrada no fio, impedindo que interceptadores passivos saibam quais domínios específicos estão associados à sessão no nível do certificado.

Implementação cirúrgica no Nginx#

Para garantir que o seu balanceador de carga ou servidor web de borda rejeite negociações inseguras, configure o bloco de TLS de forma restritiva no arquivo nginx.conf:

# /etc/nginx/conf.d/tls.conf
server {
    listen 443 ssl http2;
    server_name domain.com;

    # TLS 1.3 e TLS 1.2 estrito
    ssl_protocols TLSv1.2 TLSv1.3;
    
    # Obriga a CPU do servidor a escolher a cifra prioritária, ignorando preferências fracas do cliente
    ssl_prefer_server_ciphers on;

    # Cifras TLS 1.2 (ECDHE obrigatório + AEAD)
    # ATENÇÃO: As cifras TLS 1.3 são gerenciadas automaticamente pelo OpenSSL e NÃO podem ser configuradas nesta diretiva!
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';

    # Curvas elípticas autorizadas para a geração do Key Share efêmero (X25519 prioritária)
    ssl_ecdh_curve X25519:secp384r1;

    # OCSP Stapling (evita latência de verificação no cliente e protege a privacidade do usuário)
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/letsencrypt/live/domain.com/chain.pem;
    resolver 1.1.1.1 8.8.8.8 valid=300s;
    resolver_timeout 5s;

    # Session tickets (desabilitar para garantir Perfect Forward Secrecy absoluto)
    ssl_session_tickets off;

    # HSTS (HTTP Strict Transport Security)
    # ALERTA: Habilitar "preload" envia o domínio para a lista fixa dos navegadores. 
    # Isso é irreversível a curto prazo e quebrará subdomínios HTTP que não suportam HTTPS. Habilite apenas após homologação plena.
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
    
    ssl_certificate /etc/letsencrypt/live/domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/domain.com/privkey.pem;
}

Notas de produção e hardening do Nginx:#

• Cifras TLS 1.3 Independentes: No OpenSSL 1.1.1+, a diretiva ssl_ciphers gerencia apenas conexões TLS 1.2 e inferiores. Tentar forçar cifras TLS 1.3 aqui resultará no seu ignoramento silencioso ou em falha de inicialização em algumas versões do Nginx. A suíte TLS 1.3 é negociada automaticamente em background.
• OCSP Stapling: Essencial para a performance de produção. Em vez de o navegador consultar a Autoridade Certificadora (CA) a cada conexão para verificar se o certificado foi revogado, o próprio Nginx faz o cache da resposta assinada pela CA e a anexa (staples) no handshake. Isso elimina uma latência de 200 a 500ms e preserva a privacidade do usuário.
• Session Tickets vs PFS: Desabilitar os session tickets (ssl_session_tickets off) força a geração de novos segredos a cada sessão. Caso a chave estática do ticket fosse comprometida em disco, seria possível descriptografar sessões passadas protegidas com PFS.
• Riscos do HSTS Preload: O cabeçalho Strict-Transport-Security com a flag preload solicita a inclusão do seu domínio na lista global dos navegadores. O processo de remoção dessa lista pode levar meses, e se você tiver subdomínios legados rodando em HTTP (como sistemas de intranet ou dispositivos antigos), eles ficarão completamente inacessíveis. Por isso, a diretiva acima omite a flag preload por padrão.

2. Hardening de openssh: desativando compatibilidades inseguras#

O OpenSSH é o principal vetor de acesso para a gerência de servidores Linux. Por padrão, a maioria das distribuições Linux vem configurada de forma permissiva para manter compatibilidade com clientes antigos (como terminais legados, switches de rede corporativos antigos ou scripts automatizados antigos).

Essa política padrão permite que o servidor aceite algoritmos de troca de chave (KEX) baseados em hashes fracos como o SHA-1, cifras simétricas obsoletas em modo CBC e o uso de chaves RSA baseadas em assinaturas vulneráveis (ssh-rsa).

Endurecer o OpenSSH de forma profissional exige delimitar quais instruções matemáticas a CPU do host está autorizada a computar para a geração do túnel seguro.

Configuração criptográfica avançada do SSHD#

⚠️ Aviso de Compatibilidade: A configuração restritiva a seguir desabilita algoritmos legados. Ela rejeitará conexões de clientes SSH antigos (OpenSSH < 7.4), sistemas rodando OpenSSL < 1.1.1, dispositivos IoT com firmware antigo e clientes que dependem do Diffie-Hellman Group 14 ou inferior. Antes de aplicar em produção, valide a versão do cliente (ssh -V). Para evitar lockout de clientes legados, mantemos o HostKey RSA como fallback no exemplo abaixo.

Substitua ou edite as diretivas no arquivo /etc/ssh/sshd_config para adotar o perfil de segurança restritivo recomendado pelo CIS (Center for Internet Security):

# /etc/ssh/sshd_config

# 1. Algoritmos de Troca de Chaves (KEX)
# Autoriza apenas a curva Curve25519 e o Diffie-Hellman baseado em SHA-512 (grupo 16)
KexAlgorithms curve25519-sha256,[email protected],diffie-hellman-group16-sha512

# 2. Cifras Simétricas do Túnel
# Exclui o modo CBC. Permite apenas cifras AEAD de alta velocidade e blindagem contra ataques de canal lateral
Ciphers [email protected],[email protected],[email protected]

# 3. Message Authentication Codes (MACs)
# As cifras AEAD acima possuem autenticação e integridade embutidas. 
# Estes MACs são limitados a variantes EtM (Encrypt-then-MAC) para a fase de handshake inicial
MACs [email protected],[email protected]

# 4. Chaves de Host do Servidor
# Habilita Ed25519 e mantém RSA como fallback para evitar incompatibilidades e lockout
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

# 5. Autenticação e Hardening Criptográfico
# Desabilita autenticação por senha (evitando ataques de credential stuffing e brute force)
PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin prohibit-password
KbdInteractiveAuthentication no
AuthenticationMethods publickey

# 6. Proteção de Acesso e Limites
# Restringe o número de tentativas, sessões e grace period
MaxAuthTries 3
LoginGraceTime 30
MaxSessions 3
MaxStartups 10:30:60

# 7. Restrição de Acesso de Usuários (Ajuste para seu ambiente)
# Permita apenas usuários/grupos específicos. OpenSSH aceita padrões de curinga (ex: [email protected].*)
# AllowUsers [email protected].* [email protected].*
# ou
# AllowGroups ssh-users

# 8. Log de Auditoria Avançado
# Altera o nível do log para VERBOSE para registrar os fingerprints das chaves de conexões
LogLevel VERBOSE

Aplicando e testando a configuração#

⚠️ ALERTA CRÍTICO DE LOCKOUT: Se houver qualquer falha ou erro de configuração, você poderá perder o acesso ao servidor permanentemente. Nunca feche sua sessão de terminal SSH atual enquanto aplica e testa estas alterações. Mantenha pelo menos uma conexão ativa para reverter as alterações caso ocorra algum problema.

Antes de reiniciar o serviço, certifique-se de testar a sintaxe do arquivo de configuração para evitar bloqueio acidental do acesso ao host:

# Validar sintaxe das regras
sudo sshd -t

Se o comando retornar sem erros de output, reinicie o daemon do SSH:

sudo systemctl restart sshd

Nota: Mantenha a sua sessão atual do SSH ativa enquanto abre um novo terminal para testar a conexão; assim você consegue reverter as regras em caso de erro na chave pública.

3. Visibilidade D7: validando os logs e auditando cifras#

Com a ativação do LogLevel VERBOSE, as conexões que utilizarem chaves de usuário (como a assinatura Ed25519) registrarão nos logs do sistema (/var/log/auth.log ou via journalctl) a impressão digital criptográfica exata da sessão estabelecida (Atenção: Logs verbosos de conexões podem crescer de forma substancial em ambientes de altíssimo tráfego. Certifique-se de que a rotação de logs em /etc/logrotate.d/rsyslog ou do systemd-journald está ativa e devidamente dimensionada para evitar o esgotamento do espaço em disco):

sudo tail -f /var/log/auth.log | grep sshd

Output esperado no console forense:

sshd[45192]: Connection from 10.0.0.55 port 45192 on 10.0.0.10 port 22
sshd[45192]: Accepted publickey for user from 10.0.0.55 port 45192 ssh2: ED25519 SHA256:4oY5lJ9NnLgH4kPqRxTYuZ81mWt2K83aD1ePfV9g
sshd[45192]: pam_unix(sshd:session): session opened for user user(uid=1000) by (uid=0)
sshd[45192]: Connection closed by authenticated user user 10.0.0.55 port 45192 [preauth]

O log detalhado expõe:

• O IP de origem (10.0.0.55) e a porta efêmera utilizada.
• O tipo de chave de assinatura autorizado (ED25519).
• O hash SHA256 do fingerprint da chave pública do usuário, permitindo correlacionar de forma imediata o acesso físico à chave correspondente.

Auditoria remota de cifras autorizadas (nmap)#

Para auditar o seu próprio servidor a partir de uma estação externa e confirmar que nenhuma cifra vulnerável ou legada é aceita pelo OpenSSH, utilize o script utilitário do Nmap:

nmap -p 22 --script ssh2-enum-algos domain.com

Resultado da auditoria de hardening:

Starting Nmap 7.92 ( https://nmap.org ) at 2026-06-15 03:00
Nmap scan report for domain.com (10.0.0.10)
Host is up (0.012s latency).

PORT   STATE SERVICE
22/tcp open  ssh
| ssh2-enum-algos: 
|   kex_algorithms: (3)
|       curve25519-sha256
|       [email protected]
|       diffie-hellman-group16-sha512
|   server_host_key_algorithms: (1)
|       ssh-ed25519
|   encryption_algorithms: (3)
|       [email protected]
|       [email protected]
|_      [email protected]

Este output valida que apenas os algoritmos matemáticos modernos e seguros selecionados na configuração estão expostos na porta de gerência. Qualquer tentativa de conexão utilizando cifras obsoletas falhará imediatamente na negociação de KEX inicial, eliminando ataques passivos ou reativos de descriptografia retroativa.

Veja também

Cibersegurança Como alterar a porta do SSH no Linux de forma segura

Cibersegurança Troubleshooting real: do crash status 255 no Fail2ban ao backend systemd e modularização no Nginx

Cibersegurança Análise forense de um comprometimento no CloudLinux e cPanel: da armadilha do sshd_config à persistência no PAM e IPMI

Este post está licenciado sob CC BY-NC.