Projetando a mitigação de inundações SYN para a Internet real

Visão geral

A missão da Nexusguard é proteger nossos clientes contra ataques disruptivos de DDoS, preservando o desempenho do aplicativo. Uma das ameaças mais comuns que enfrentamos é a Inundação de TCP SYN. Esse ataque tem como alvo o estágio de aperto de mão do Protocolo de Controle de Transmissão (TCP), enviando uma enxurrada de segmentos SYN na tentativa de esgotar os recursos do servidor. Os invasores geralmente falsificam os endereços de origem, então o servidor de destino investe recursos em conexões semiabertas com hosts que nunca responderão. Em casos extremos, esses SYNs também podem ser usados para refletir o tráfego para vítimas inocentes, explorando a disposição do servidor de responder a cada aperto de mão.

‍

Para combater esses ataques, nossos Bastions locais deliberadamente descarte o primeiro SYN e só aceita conexões quando um cliente prova sua legitimidade por meio da retransmissão. Essa abordagem elimina o risco de o Bastions se tornar um refletor e mantém a funcionalidade TCP completa para usuários legítimos. As seções a seguir explicam a natureza das inundações de SYN, comparam a mitigação de cookies SYN sem estado com a validação baseada em retransmissão e discutem por que preferimos a última.

Como funcionam as inundações SYN

O handshake tridirecional começa quando um cliente envia um SYN, progride quando o servidor responde com um SYN‑ACK e é concluído quando o cliente confirma com um ACK. Em condições normais, esse aperto de mão sincroniza os números da sequência inicial e negocia opções como tamanho máximo do segmento e dimensionamento da janela. Durante uma inundação de SYNs, o invasor envia um grande número de SYNs, geralmente com endereços falsos, para ocupar a fila de conexão semiaberta do servidor. Como o servidor não tem como verificar a origem antes de responder, ele envia corretamente pacotes SYN‑ACK e espera por confirmações que nunca chegam. O servidor retransmitirá o SYN‑ACK se o ACK esperado não for recebido, conforme exigido pela especificação TCP. Quando os endereços falsificados pertencem a terceiros, esses Syn‑acks repetidos se tornam um ataque de reflexão, amplificando a inundação ao forçar o servidor a retransmitir o tráfego para a vítima. Essa amplificação depende de quantas vezes o servidor retransmite seu SYN‑ACK.

‍

O diagrama abaixo ilustra um reflexo do SYN‑ACK: um botnet direciona SYNs falsificados para um servidor público, fazendo com que esse servidor envie SYN‑ACKS repetidos para a vítima inocente. Como a vítima nunca termina o aperto de mão, o servidor continua retransmitindo.

Cookies SYN: vantagens e desvantagens

Uma defesa amplamente adotada contra inundações de SYN é a Cookie SYN algoritmo. Quando a lista de pendências de um servidor está sobrecarregada, em vez de alocar uma conexão semiaberta, ele codifica os parâmetros de conexão no número de sequência do SYN‑ACK, descarta seu estado e aguarda o ACK do cliente. O cookie é construído a partir de um campo limitado de 32 bits; apenas alguns bits estão disponíveis para representar parâmetros como o tamanho máximo do segmento e o dimensionamento da janela. Devido a essa limitação, o servidor não consegue se lembrar de muitos recursos TCP opcionais e negociará padrões conservadores. Como resultado, as conexões estabelecidas por meio de cookies SYN podem ter janelas menores, não ter registros de data e hora ou suporte a ECN e não podem usar opções mais recentes. Além disso, quando o próprio SYN‑ACK é perdido, o servidor que usa cookies SYN puros não retransmite; o cliente deve reenviar seu SYN para reiniciar o handshake. Finalmente, como o servidor responde a todos os SYNs (incluindo os falsificados) com um SYN‑ACK, ele pode ser usado como refletor durante um ataque distribuído.

‍

Apesar dessas limitações, os cookies SYN fornecem uma apátrida mecanismo para manter a disponibilidade durante uma inundação. Como o servidor não aloca memória para conexões semiabertas, seus recursos não podem ser esgotados. Para algumas implantações, essa compensação é aceitável, especialmente quando a memória é escassa ou o servidor está posicionado em um ponto de trânsito upstream. No entanto, para os Bastions da Nexusguard, que operam à margem do cliente com amplos recursos e a necessidade de preservar o desempenho total do TCP, esse compromisso não é desejável.

Validação baseada em retransmissão

Nossa alternativa é descartar intencionalmente o primeiro SYN e continuar com o aperto de mão somente quando o cliente retransmitir. Os clientes TCP são projetados para tentar novamente quando as confirmações não são recebidas; portanto, clientes legítimos enviarão um segundo SYN após um tempo limite, enquanto as ferramentas de falsificação não conseguem porque nunca veem a resposta do servidor. Quando o Bastions observa o SYN retransmitido, ele encaminha a solicitação para o servidor protegido e permite que o SYN‑ACK retorne ao cliente. O aperto de mão então é concluído normalmente, preservando todas as opções negociadas. Essa técnica filtra SYNs forjados sem enviar tráfego para o endereço falsificado, eliminando o papel dos Bastions na reflexão. Como o Bastion só encaminha conexões que foram repetidas, a probabilidade de um falso positivo é extremamente baixa e os usuários legítimos experimentam apenas um pequeno atraso.

‍

Visualizamos a diferença abaixo. Na Cookie SYN faça com que o servidor responda imediatamente a cada SYN com um SYN‑ACK codificado, sacrificando alguns recursos opcionais. Na retransmissão A abordagem do Bastions elimina o primeiro SYN; somente quando o cliente tenta novamente, ele passa pelo SYN e permite que o handshake continue.

Por que a Nexusguard escolhe a retransmissão

As escolhas de design da Nexusguard são guiadas por três princípios: desempenho, confiabilidade e segurança.

• Preservando a funcionalidade TCP completa. Muitos aplicativos modernos dependem de opções de TCP, como confirmações seletivas, janelas grandes e carimbos de data/hora para obter alto rendimento. Ao permitir que o aperto de mão nativo continue após o cliente provar seu valor, nossos Bastions garantem que esses recursos sejam negociados. Por outro lado, os cookies SYN aproximam os parâmetros usando alguns bits e não podem suportar valores maiores de MSS ou escalas de janela.
• Evitando a reflexão. Nossas mitigações nunca devem se tornar uma arma no ataque de outra pessoa. Como o Bastion não responde ao SYNs inicial, ele não envia tráfego de volta para endereços falsificados e não pode ser aproveitado para reflexão.
• Aproveitando o comportamento inerente do TCP. A retransmissão faz parte da especificação TCP. Clientes legítimos já implementam a lógica de repetição; ao confiar nesse mecanismo, separamos usuários reais de inundações automatizadas sem introduzir protocolos proprietários ou exigir a cooperação do cliente.
• Operando em grande escala. Nossos Bastions são implantados na borda da rede, onde a largura de banda está disponível. Descartar um grande número de SYNs maliciosos é mais barato do que computar cookies criptográficos para cada solicitação. A experiência com ataques em grande escala mostra que o envio até mesmo de Syn‑acks sem estado com altas taxas de pacotes pode saturar os links upstream; nossa abordagem evita isso suprimindo totalmente as respostas.

Conclusão

As inundações de TCP SYN continuam sendo uma ameaça generalizada. Existem duas mitigações primárias: codificar o estado no número de sequência via Cookies SYN, e validação baseada em retransmissão que filtra SYNs falsificados exigindo que os clientes tentem novamente. Embora os cookies SYN forneçam uma forma sem estado de manter um servidor on-line, eles impedem a negociação de opções avançadas de TCP, não retransmitem SYN‑ACKS perdidos e podem participar involuntariamente de ataques de reflexão. Os Bastions da Nexusguard empregam retransmissão porque preservam a funcionalidade total do protocolo, aproveitam o comportamento TCP incorporado e garantem que o dispositivo não amplifique os ataques. Essa estratégia nos permite oferecer o mais alto nível de proteção e desempenho para nossos clientes.