Olá amigos!
Estava lendo sobre ataques de negação de serviço(D)DoS e me deparei com este tema. O trabalho na área de segurança nos faz conhecer a respeito dos métodos de proteção, mas não em essência. Nem todos sabem o que realmente acontece ‘nos bastidores’, restringindo-se ao procedimento ou implementação do controle em seus dispositivos de rede ou sistemas operacionais. Tentarei explicar sucintamente sobre o assunto.
Um breve histórico
O TCP/IP apresentou-se formalmente ao mundo em 1981 (já rolava algo na (D)ARPA bem antes disso), por meio do famoso RFC 793. Cerca de uma década depois, quando o TCP/IP já era considerado mainstream, várias vulnerabilidades tornaram-se públicas (o underground sempre sabe antes, não?), dentre elas pode-se destacar: a fragilidade do processo de geração (baixa entropia) e ‘manuseio’ dos números de sequência, o que levava aos ataques de IP Spoofing e descoberta prévia do número de sequência inicial; a ausência de recomendações ou boas práticas para descarte e manuseio de pacotes contendo combinações diversas de flags TCP, o que facilitava o processo de reconhecimento de versões (kernel, firmware, etc.); a ausência de implementações para tratar vários pedidos de conexão (bit SYN setado) em curtos intervalos de tempo, o que causava a exaustão de recursos e, consequentemente, DoS. Este último será descrito aqui.
Como ocorre o ataque?
Um ataque de SYN Flood nada mais é que um ataque de DoS, onde um ou vários clientes iniciam múltiplas conexões TCP em direção ao servidor (vítima) com intuito de levar a exaustão de recursos por meio do processamento e alocação de buffers no servidor, de tal modo que nenhuma das conexões é continuada, ou seja, o famoso three-way handshake não é completado. Vale lembrar que mesmo a partir de um único host é possível sobrecarregar o servidor utilizando-se de técnicas de IP spoofing.
Quando a tabela que aloca o estado das conexões é totalmente preenchida, por padrão (depende da implementação), passa-se a descartar ou ignorar pedidos de novas conexões, restringindo-se a este dano (dificilmente leva à parada total de um servidor). Passados alguns minutos do final do ataque, e após o timeout por espera de pacotes não correspondidos (SYN+ACK), o servidor retorna ao funcionamento normal.
Proteção
Assim como em outras situações (se não, todas) no contexto de segurança, dificilmente pode-se afirmar que algum controle oferece total segurança; o mesmo acontece aqui: nenhum controle ou mecanismo poderá garantir que é imune a todas as formas de (D)DoS.
Naquela época, alguns provedores de acesso chegavam a entrar em colapso devido aos ataques de SYN Flood [1], o que incentivou programadores a implementação de proteções na pilha TCP/IP. Dentre as proteções, sem dúvida, a mais notável tornou-se conhecida como syn cookies.
Por meio dos syn cookies, um servidor não precisa alocar recursos (estado) imediatamente após receber o pacote sinalizado para sincronização (SYN). O mecanismo funciona da seguinte maneira. O número de sequência inicial (NSI) é cuidadosamente manipulado, ao lugar de ser gerado randomicamente. Assim, após o recebimento do primeiro pacote (SYN), o servidor gera o NSI baseado em informações vitais que seriam armazenadas na tabela de estado. Esse número é uma espécie de ‘hash’ que é colocado no pacote SYN+ACK de resposta ao cliente, resultado de um cálculo criptográfico. O terceiro pacote (ACK), oriundo do cliente, chega ao servidor com o valor de sequência incrementado (NSI+1), podendo inclusive ser validado pelo servidor, que então aloca recursos para a conexão, após o término do three-way handshake.
De forma prática, no Linux o controle é ativado da seguinte maneira:
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
No Windows (2000 e 2003) é um pouco mais complicado. Existem chaves de registro no caminho HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters, dentre essas, a chave SynAttackProtec (DWORD), cujo valor pode ser 1 ou 2, dependendo do comportamento esperado na ocorrência de um ataque de SYN Flood. Este é disparado por meio da comparação do estado de conexões TCP com valores contidos nas chaves (parâmetros) TcpMaxHalfOpen, TcpMaxHalfOpenRetried e TcpMaxPortsExhausted. Mais detalhes podem ser encontrados em um artigo publicado no portal Security Focus. [2]
Cenário Atual
Ao ativar proteções como syn cookies, um dispositivo ou servidor torna-se imune ao ataque? A solução é eficaz, dependendo da intensidade ou da proporção de um ataque. A existência do controle apenas miniminiza ou retarda os danos. Perceba que, hoje em dia, há inclusive comércio online [3] de botnets (hosts zumbis), cujo controle pode ser feito até pelo IRC. Todos podem ser utilizados para realizar ataques (DoS, SPAM, disseminação de malware, etc).
Além disso, a proteção por meio de syn cookies também aloca recursos, em menos quantidade, lógico; mas continua sendo uma maneira de explorar recursos do servidor. Existem discussões acerca de melhorias, não só para o método dos cookies, mas para outros mecanismos. [4]
Referências
[1] http://cr.yp.to/syncookies.html, D. J. Bernstein
[2] Hardening the TCP/IP stack to SYN attacks, http://www.securityfocus.com/infocus/1729
[3] BBC Team Exposes Cyber-Crime Risk
[4] Improving Syncookies, http://lwn.net/Articles/277146/
PCF-3 