Boas!

Você é aquele cara que sempre ouviu os outros falando em Syn Floods e DoS, mas nunca te explicaram direito o que era o negócio? Não temas! Você é parte de um grande conjunto de outras pessoas na mesma situação.

Mas como eu sou um cara legal.. quer dizer, algumas pessoas dizem isso. Se bem que as pessoas que não me acham legal não devem dizer isso pra mim. Resumindo! Vou acreditar naquelas pessoas que mentem dizendo que eu sou legal e vou te explicar, com detalhes o funcionamento dos Syn Floods.

Já que o meu organismo diz que precisa de sono (e eu só posso trabalhar no site à noite), eu não posso contrariá-lo, então vou dividir este artigo em duas partes. Aqui eu vou falar sobre a teoria por trás dos Syn Floods e no próximo artigo eu vou criar um programinha mostrando como o negócio funciona na prática.

[[ A conexão TCP – O mundo normal ]]

Pra falar em Syn Floods, primeiro é preciso saber como a conexão TCP funciona. Em um mundo “normal”, onde apenas usuários coexistem felizes e harmônicos, o processo de conexão do TCP funciona com um processo conhecido como Three-way Handshake.

TCP - Three-Way Handshake

A figura acima mostra os passos da conexão.

  1. O cliente envia para o servidor uma requisição de conexão TCP, o que gera um pacote desse protocolo com o flag SYN ligado e o flag ACK desligado. Neste instante, o cliente fica aguardando pela resposta do servidor;
  2. O servidor, bondoso por natureza, envia de volta ao cliente uma espécie de “pois não, seja bem vindo”, isto é, um pacote TCP contendo os flags SYN e ACK ligados. Nesse pacote, os números de sequência também precisam corretos. Neste ponto, o cliente precisa armazenar, em uma lista na memória, que este cliente solicitou uma conexão e que está pendente do último pacote pra finalizar a conexão. Muita atenção nessa hora!!
  3. O cliente, por sua vez, envia um pacote TCP ao servidor, com o flag ACK ligado e o SYN desligado. As duas máquinas consideram que a conexão está feita.

Mas como eu sei que você é um cara bastante curioso e não aceita tudo o que eu falo, eu vou provar por A+B o que estou falando. Pra isso, eu vou efetuar uma conexão com um famoso site chamado www.codebunker.org e vou monitorar isso através do meu sniffer-for-dummies preferido, o Ethereal.

Beleza! Você pode reproduzir isso na sua casa sem problemas. Confia em mim agora? Eu sei que não! 🙁 Mas tudo bem, vamos lá!

[[ A falha ]]

Você percebeu que tem alguma coisa ali cheirando a brecha, não é? (No bom sentido sempre). O fato é que você leu aquele negócio e achou um lugar onde você pode mexer…

Lembra que, quando você manda um pacote com o flag SYN, o servidor manda de volta um SYN/ACK e deixa na memória um registro de que esse cliente ainda vai mandar um TCP ACK? O local onde esse registro fica armazenado é chamado Backlog Queue.

No Linux, o tamanho do Backlog Queue é definido pelo parâmetro /proc/net/ipv4/tcp_max_syn_backlog. No Vindou$, esse parâmetro é definido na chave de registro HKLM\System\CurrentControlSet\Services\AFD\Parameters\MaximumDynamicBacklog.

O problema é que, se as conexões não forem completadas, essa área de memória começa a encher, até que ela chega a seu limite. Quando isso ocorre, o comportamento padrão é parar de receber conexões e isso deixa o servidor indisponível para novas conexões, o famoso Denial of Service (DoS, embora esse seja apenas um tipo). Pra fazer isso, basta mandar um monte de pacotes com TCP SYN pra um servidor e ignorar as respostas 🙂

Por dentro agora, né? Veja bem, como agravante, as pessoas utilizam uma técnica chamada de IP Spoofing pra forjar o endereço de origem dos pacotes. Com isso, fica bastante difícil rastrear a pessoa que efetuou o ataque, afinal, os pacotes enviados de volta pelo servidor são inúteis.

[[ E agora?? O que eu faço???? ]]

A solução mais simples é, com certeza, aumentar a área de memória do Backlog Queue até não ter mais memória pros outros serviços.. certo?? Não!!

O que o CERT sugere é que as pessoas que configuram roteadores bloqueiem pacotes cujo endereço de origem não faz parte de sua rede interna.. o que é confiar em uma Internet formada apenas por pessoas boazinhas. O problema é que as pessoas sempre podem forjar endereços de origem da própria rede interna.

[[ Por hoje 🙁 ]]

Eu falarei mais sobre algumas soluções possíveis no próximo post e também vou mostrar um pequeno programa de exemplo que faz Syn Floods, basicamente um PoC (Proof of Concept).

Quem sobreviver verá.

See ya.