Resumo

  • Um SYN flood explora uma diferença de tempo: o servidor reserva estado semiaberto antes de o iniciador concluir o handshake, permitindo que pedidos baratos ocupem uma fila finita.
  • O RFC 4987 compara duas defesas de ponta: manter um registro menor num cache SYN limitado ou não guardar estado e reconstruí-lo a partir de um cookie devolvido pelo ACK.

Ao receber um SYN, o servidor em escuta toma uma decisão que parece pequena. Ele registra a tentativa, envia um SYN-ACK e espera. Para um cliente legítimo, é o cotidiano do TCP. Para o atacante, é crédito antecipado: o servidor paga em memória e temporizadores antes de o suposto cliente mostrar que consegue sequer ouvir a resposta.

O RFC 4987 organiza o ataque em torno desse adiantamento. Uma pilha TCP convencional mantém estado SYN-RECEIVED enquanto o handshake permanece incompleto. A fila de conexões semiabertas é finita. Se pedidos entram mais depressa do que os registros são recuperados, novas conexões legítimas deixam de encontrar espaço. O documento trata do esgotamento do estado TCP no host e da indisponibilidade da aplicação em escuta. Não pretende resolver a situação diferente em que o volume de pacotes satura primeiro o enlace de rede.

Forjar o endereço de origem é uma maneira de fazer a resposta desaparecer, mas não é requisito universal. Máquinas comprometidas podem transmitir de endereços válidos e manter a mesma pressão. O mecanismo exige apenas que cada SYN provoque alocação, que a reserva de estados semiabertos seja limitada e que a chegada ultrapasse a recuperação. No cenário descrito pelo RFC, o dano imediato recai sobre novas conexões de entrada para a porta atacada, não sobre conexões que já foram estabelecidas.

Algumas soluções intuitivas apenas mudam a marca de saturação. Aumentar o backlog faz o defensor comprar mais memória e dá ao agressor um número maior para preencher. Reduzir o temporizador SYN-RECEIVED libera entradas antes, mas descarta clientes honestos submetidos a atrasos normais; o atacante pode aumentar a frequência. Reciclar o bloco semiaberto mais antigo usa idade como critério de sacrifício sem saber quem é legítimo. A filtragem de ingresso ajuda contra tráfego dependente de origem forjada, mas não existe em toda parte e não remove pedidos de botnets com endereços roteáveis.

Lembrar menos, com limites claros

O cache SYN reduz o preço da primeira mensagem. Em vez de criar imediatamente um bloco de controle TCP completo, o servidor guarda um registro pequeno, suficiente para concluir o handshake depois. O cache possui um teto. O RFC também descreve a distribuição dos registros em buckets por meio de hash com segredo. Se a função fosse previsível, o atacante poderia concentrar pedidos em um único bucket mesmo com espaço livre no restante. O segredo dificulta essa concentração dirigida, enquanto o limite contém memória e trabalho de busca.

O cache continua sendo estado. Precisa expirar e preservar a retransmissão de um SYN-ACK perdido. Responder uma vez e esquecer a obrigação de retransmitir transformaria perda comum em falha de conexão. Seu valor não é apagar o comportamento do TCP, e sim postergar o objeto caro sem perder o mínimo necessário para alcançar o ACK final.

Colocar o recibo dentro da resposta

Os cookies SYN levam o princípio para um caminho sem estado. O servidor não mantém registro SYN-RECEIVED daquela tentativa. Ele constrói seu número de sequência inicial de forma que o ACK final devolva informação suficiente para validar a troca e reconstruir a conexão. O bloco de controle completo só é alocado depois que esse ACK é aceito.

O Apêndice A ilustra uma construção com o número de sequência do iniciador, uma codificação do tamanho máximo de segmento, um contador de tempo, endereços, portas e uma função secreta. Quando o ACK retorna, o servidor verifica o resultado com seu segredo e com valores recentes do contador. Isso é um recibo compacto de um handshake específico, não autenticação de pessoa ou aplicação. Ele indica, dentro da resistência do cálculo a adivinhação, que o emissor possui informação derivada do SYN-ACK; não cria identidade duradoura.

A ausência de estado cobra um preço semântico. Entre SYN e ACK, o TCP normalmente guarda opções negociadas. O espaço que cabe num cookie é limitado, portanto construções comuns podem restringir window scaling, SACK ou opções futuras. O RFC também menciona dados enviados com o SYN. Se o ACK final se perder e a aplicação do servidor só falar depois de receber dados do cliente, pode faltar estado para retransmitir o SYN-ACK de modo normal. A alocação foi adiada, mas parte da memória do protocolo foi adiada junto.

As duas técnicas podem cooperar. O servidor usa cache SYN enquanto houver capacidade e ativa cookies quando o limite é atingido. O modelo híbrido preserva negociação mais rica em condições normais e reserva o recibo sem estado para a sobrecarga. Firewall ou proxy também pode mediar a abertura, mas desloca a carga de estado e pode alterar a semântica de ponta a ponta. A decisão de recurso não sumiu; apenas mudou de dono.

Publicado em agosto de 2007, o RFC 4987 é Informational, não uma obrigação da Standards Track. Sua análise considera cache e cookies SYN modificações viáveis de ponta e favorece o cache como comportamento normal quando possível. É uma avaliação histórica, não prova das configurações padrão atuais de nenhum sistema operacional.

A regra durável é evitar um compromisso caro, escasso e dirigido pelo adversário na primeira mensagem não verificada quando uma representação barata e reversível consegue levar a troca adiante. Esperar a devolução de informação contida na resposta melhora a evidência de alcance pelo caminho de retorno. Isso não autentica o par e pode perder contexto útil. Uma defesa honesta precisa mostrar tanto o recurso que economiza quanto a semântica que enfraquece.

A única fonte é o RFC 4987, “TCP SYN Flooding Attacks and Common Mitigations”. Este artigo se mantém nos limites do estado TCP de ponta, das defesas avaliadas e dos custos declarados no documento, sem inferir padrões, implantação ou frequência de ataques atuais.