Resumo

  • Um SYN cookie codifica estado provisório verificável no número de sequência inicial do servidor, permitindo esperar pelo ACK final antes de alocar um registro explícito em SYN-RECEIVED.
  • O recibo que volta demonstra acesso recente ao caminho de resposta daquele quádruplo. Não autentica uma pessoa, não autoriza a aplicação e não garante recursos depois do handshake.
  • O campo de 32 bits impõe um orçamento de informação. Gatilho, opções recuperáveis, reação à perda e gargalos remanescentes precisam ser comprovados na pilha realmente implantada.

Na abertura passiva comum, o servidor assume a primeira obrigação. Ao receber um SYN, entra em SYN-RECEIVED, escolhe seu número de sequência, envia um SYN-ACK e guarda dados da tentativa na fila de conexões embrionárias. O remetente ainda não mostrou que recebe tráfego no endereço declarado, mas já consome uma posição limitada.

O SYN flood explora esse adiantamento. Inícios que nunca terminam ocupam memória enquanto aguardam retransmissão e expiração. Quando a fila enche, clientes legítimos podem ser recusados mesmo que o enlace, a aplicação e os sockets já estabelecidos ainda tenham folga. O RFC 4987 delimita o caso: o alvo clássico é o estado de estabelecimento, não necessariamente toda a largura de banda ou todo o processamento do serviço.

Cada mitigação escolhe um prejuízo diferente. Aumentar o backlog compra espera ao custo de mais memória exposta. Diminuir o temporizador libera entradas, mas penaliza rotas lentas ou com perda. Reciclar a tentativa mais antiga faz a idade decidir quem some. Um SYN cache mantém uma ficha reduzida. Um proxy termina o handshake em outro ponto e transfere para ele tanto a semântica quanto a pressão.

O SYN cookie abre mão da ficha. O servidor constrói seu número de sequência inicial para carregar uma descrição comprimida da tentativa e uma verificação derivada de segredo local. Desenhos históricos combinam endereços e portas, o número inicial do cliente, um contador temporal lento, uma classe de MSS e segredos do servidor. O RFC registra alternativas e compromissos; não determina um algoritmo idêntico para todos os sistemas.

O cliente continua falando TCP normal. Recebe o SYN-ACK e devolve um ACK para o número do servidor mais um. Quando o terceiro pacote chega, o servidor recupera o valor, testa janelas de tempo ainda válidas e recalcula a função secreta sobre o quádruplo observado. Se houver correspondência, reconstrói estado suficiente e entra em ESTABLISHED. Caso contrário, descarta o retorno sem procurar uma entrada que jamais armazenou.

O cookie funciona como um recibo carregado pelo próprio solicitante. O servidor o emite com um selo que só ele consegue verificar e não abre uma conta. A devolução demonstra que alguém recebeu, observou ou aprendeu o SYN-ACK recente destinado àquele caminho. É evidência suficiente para uma decisão local de memória, mas não identifica usuário, empresa ou intenção, nem mede o custo do trabalho seguinte.

O segredo dificulta a falsificação fora do caminho. Não transforma TCP em protocolo de identidade. Quem está no caminho pode observar a troca; máquinas reais podem devolver cookies corretos em massa. Depois da admissão, conexões válidas ainda consomem sockets, TLS, workers, bancos de dados e cotas de negócio. O mecanismo adia um compromisso. Ele não elimina compromissos futuros.

Não guardar exige comprimir. O número de sequência tem 32 bits e continua cumprindo sua função original. Uma entrada normal poderia reter as opções exatas do primeiro SYN. Um cookie básico precisa dividir espaço entre frescor, integridade e parâmetros indispensáveis. Esquemas históricos reservaram, por exemplo, um pequeno índice para classes comuns de MSS. O que não está codificado nem pode ser inferido do ACK não existe na reconstrução.

Window Scale mostra o impacto. O RFC 7323 limita sua negociação a segmentos com SYN e fixa o fator em cada direção quando a conexão começa. Se o servidor esqueceu a oferta do cliente e não dispõe de uma extensão que a recupere, não pode negociá-la depois. Por isso, o RFC 4987 descreveu perdas históricas de estado de Window Scale, SACK e outros recursos, ao mesmo tempo em que registrou uma técnica do FreeBSD que usava bits de Timestamp ecoados para recuperar mais opções.

Não há conclusão universal. É incorreto afirmar que todo SYN cookie sempre perde as mesmas extensões, porque implementações posteriores codificam mais. Também é incorreto presumir que tudo sobreviva porque uma pilha encontrou bits adicionais. O contrato efetivo pertence ao kernel, à versão, ao offload, ao balanceador, ao proxy e ao listener que recebe o tráfego de produção.

A perda do terceiro ACK cria um caso sutil em protocolos nos quais o servidor fala primeiro. O RFC 4987 usa SMTP como exemplo. O cliente envia o ACK final e passa a esperar a saudação. Se o pacote desaparece, o servidor sem estado não tem uma ficha para retransmitir sua decisão e ainda não avisou a aplicação. A recuperação depende das retransmissões e da implementação. Economizar memória muda qual lado percebe primeiro o silêncio.

Uma política híbrida preserva melhor a normalidade. Sob carga comum, o backlog ou um SYN cache guarda negociação mais rica e o comportamento usual de retransmissão. Quando um limiar local estoura, a pilha pode recorrer a cookies em vez de expulsar uma tentativa existente. O modo sem estado passa a ter condição de entrada, efeito observável e condição de saída, em vez de se tornar substituto permanente da abertura TCP.

A documentação atual do Linux explicita esse limite. tcp_syncookies é descrito como fallback quando o SYN backlog do socket transborda e não como forma de fazer um servidor sobrecarregado aguentar taxa legítima que não consegue atender. tcp_max_syn_backlog controla separadamente quantas solicitações SYN_RECV cada listener lembra. Se demanda ordinária ativa o fallback continuamente, o operador precisa investigar fila, retransmissão e capacidade.

Mesmo um cookie perfeito deixa outros orçamentos expostos. A máquina ainda recebe e analisa SYNs, calcula respostas, envia SYN-ACK e valida ACK. Enlace, interrupções, filas e CPU podem saturar. Depois do estabelecimento, accept queue, memória de sockets, criptografia, workers e dependências podem acabar. Mover o gargalo pode ser o efeito esperado; deixar o próximo gargalo invisível não é.

A validação de endereço de origem é complementar. BCP 38 e BCP 84 reduzem a exportação de tráfego falsificado e, assim, respostas para endereços inventados. Não impedem bots com endereços verdadeiros nem picos legítimos de completar handshakes. A rede de origem decide o que deixa sair; o endpoint decide quando compromete estado. Uma autoridade não substitui a outra.

A observabilidade precisa repor a evidência que o estado explícito deixou de fornecer. O RFC 4898 separa eventos da fila embrionária, a alocação completa e a aceitação pela aplicação. Também observa que sistemas com SYN cookies não possuem representação explícita do SYN-RCVD codificado. Um painel com zero conexões incompletas pode indicar tranquilidade ou apenas que o servidor parou de lembrar.

É necessário correlacionar SYNs recebidos, SYN-ACK, retransmissões, ocupação e estouro, cookies emitidos, retornos válidos, inválidos e vencidos, estabelecimentos, accept queue e aceitações da aplicação. Compare ainda MSS, Window Scale, SACK, Timestamp, ECN e Fast Open entre conexões normais e reconstruídas. Sem um contador de transição, a ausência de estado apaga também o alarme.

TCP Fast Open adiciona dados de aplicação ao SYN sob outro cookie e outras premissas de replay. O RFC 7413 não permite supor que um fallback SYN-cookie convencional retenha esses dados. Front-end, balanceador, offload e kernel devem ser testados no mesmo caminho. O nome comum “cookie” não cria equivalência de contrato.

SCTP oferece outro desenho. No RFC 9260, a abertura em quatro etapas inclui um State Cookie de tamanho variável com dados para criar a associação, MAC, timestamp e vida útil. Ele não é compatível com TCP nem idêntico ao cookie compacto. A comparação mostra apenas que o adiamento de estado preserva mais semântica quando o protocolo reserva um contêiner explícito em vez de comprimir uma negociação crescente num campo antigo.

A especificação comum pode definir invariantes e registrar compromissos, mas não conhece memória, latência, opções obrigatórias e custo posterior de cada listener. O princípio de especificação inicial mínima de Heng Lu deixa o limiar e a perda aceitável com o operador. A primazia do código em execução impõe a verificação: a configuração escrita é intenção; as conexões observadas revelam qual serviço realmente sobreviveu.

Fontes