Após ver um monte de scripts usando regras de iptables para evitar Syn Flood facilitarem o ataque, resolvi escrever uma breve dica, sem o intuito de aprofundar, deixando para o futuro (talvez?) um artigo completo.
Primeiro vamos entender rapidamente como seria uma conexão TCP correta:
Tem-se clientes(A), servidores(B), identificação cliente(Ic) e servidor (Is):
A envia um pacote com o flag SYN on e com um número de 4 bytes Ic, o B recebe esse pacote e, caso aceite a conexão, responde (para o ip de origem) a mesma com um pacote com os flags SYN e ACK on e com um número de 4 bytes Is e com Ic+1, caso o A ainda esteja lá (conectado) e queira estabilizar a conexão, responde com um pacote contendo o flag ACK, Ic e com Is+1.
Sabendo como funciona, fica mais fácil de entender como o ataque ocorre, simplesmente o atacante envia várias requisições de conexões com IPs variados, fazendo spoofing do mesmo.
Requisições de conexões?
Sim, o atacante manda muitos pacotes apenas com o flag SYN on, fazendo o servidor responder com SYN-ACK para o ip (forjado), alocar os recursos para a conexão, além de ficar aguardando pela resposta contendo o ACK, diminuindo os recursos do sistema, aumentando a demora para responder novas conexões, verdadeiras ou falsas, até que o serviço que está ouvindo na porta não consiga mais responder, ocasionando uma negação de serviço (DOS).
Bom, e então, esses scripts mágicos nos ensinam que:
A primeira vez que vi esse comando, pensei ser um erro do script que usei, porém ao buscar, vi que o mesmo é MUITO comum, então vamos ver o que isso realmente faz:
Adiciona a regra no final da chain FORWARD (rejeita educadamente) conexões TCP com o flag syn on de forma a aceitar APENAS se tiver limitado a 2 desses pacotes por segundo independente do ip... e se 3 clientes quiserem se conectar em 1 segundo?
Pois bem, 1 deles terá a conexão rejeitada, educadamente é claro ( :P ), mas a nível de um ataque, se o atacante mandar 40 "pacotes syn" por segundo, dando um chute alto para sempre aceitar, ele sozinho causará a negação de serviço com um número de pacotes MUITO abaixo do necessário para causar do DOS caso não houvesse essa regra no iptables! Bastava enviar 2 conexões, no caso dele conhecer a regra, para causar o DOS...
Bem, isso só facilita o ataque ao invés de tentar proteger :|
E a solução?
# echo "1" > /proc/sys/net/ipv4/tcp_syncookies
Uaal, mas e aí, por que isso funciona?
Bem, lembra do processo que descrevi para a conexão?
Então, com isso o servidor SÓ irá alocar recursos após receber o ACK com Ic e Is+1, evitando clientes "fantasmas", ou seja, aqueles que mandam um pacote SYN com um IP falso e não recebem o pacote com SYN-ACK com Ic+1 e Is.
Aí está!
Acredito que, considerando as limitações existentes em uma curta dica, a mesma ajudará a abrir os olhos e possibilitará entender melhor as coisas antes de copiar e colar. :P
[1] Comentário enviado por gewehr em 03/11/2013 - 15:53h
boa tarde
Existem poucas literaturas sobre o assunto, mas recentemente li uma obra e esta cita que em meados de 2002, o Sr Manfred Spraul, detectou que os syn-cookies continham uma vulnerabilidade em sua estrutura que possibilitavam ao atacante contornar as regras de firewall e efetivamente abrir uma conexão para a porta protegida, recomendando assim desabilitar o tcp_syncookies do firewall. Pergunto se isso é verdade e a partir de qual versão do kernel esta falha foi corrigida?
[3] Comentário enviado por octopos em 28/03/2014 - 15:23h
Havia tempos em que não acessava o email relacionado a esta conta ... =(
Essa foi uma dica muito superficial e imatura ehehe.... a escolha no uso ou não o tcp sync cookies depende de diversos fatores para ser válida.
Existem porém diversas referências que mencionam o tradeoff envolvido no uso, e mesmo a sua eficiência.