Iptables protege contra SYN FLOOD?
Uma das técnicas de negação de serviço mais conhecidas é a técnica de Syn Flood. Mas se encontra em diversos lugares "receitas" e regrinhas iptables para se defender dela. Funciona? É eficaz? Se não é, qual é realmente a defesa necessária?
Parte 3: Tipos de negação de serviço
O DoS (Denied of Service) podem ser de dois tipos:
a) DoS local: nesta o atacante possui acesso à máquina, ou porque é um usuário legítimo, ou porque roubou a senha de um usuário ou ainda porque explorou alguma vulnerabilidade (como em scripts PHP mal programados, por exemplo). De qualquer maneira, para que esta técnica tenha sucesso o atacante deve ter condições de executar comandos locais na máquina.
Mas o que o atacante, estando na máquina, pode fazer para derrubar serviços? Muitas coisas! Pode executar comandos em seqüência que esgotem a memória, por exemplo. Ou a capacidade do kernel de criar novos processos. Um exemplo bem típico de DOS local é o atacante fazer:
# dd if=/dev/zero of=/var/spool/mail/usuario
(considerando que /var/spool/mail é partição onde estão os emails dos usuários e que ele possa escrever no arquivo usuario, que é seu)
Se nenhuma defesa existir (neste caso seria o emprego de quotas), o disco ou esta partição será esgotado, impedindo a entrada de novos emails. Causa-se um DoS no serviço de email.
As defesas para DoS locais são fáceis e requerem apenas a sua configuração, como o emprego de quotas, particionamento correto do disco e a adoção de limites de recursos para cada processo ou usuário (no Linux tem o PAM limits que faz isto).
b) DoS remoto: neste o atacante não precisa estar logado na máquina e nem executar comandos nela. Remotamente, de alguma forma, ele derruba o serviço.
Programas mal feitos, com bugs, são os recordistas deste tipo de negação. Devido a descuidos na programação, as vezes só por enviar um pacote devidamente construído já é suficiente para derrubar o serviço.
O lendário ping da morte pode ser citado como um exemplo bem típico. Ou ainda o ataque XMAS (árvore de natal), onde se enviava um pacote TCP com todos os flags ligados (anormal e impossível. Como um pacote teria, por exemplo, flag de SYN, RST e FIN ao mesmo tempo?).
Uma pilha TCP bem programada deveria descartar este pacote, mas implementações antigas se perdiam e caiam. De qualquer forma estes ataques, baseados em erros de programação, acabam tendo vida curta: só existem até que o fabricante do sistema disponibilize correções (se bem que por vezes acabam sendo eternos para aqueles que não aplicam correções nos seus sistemas).
Mas existem as negações de serviços que são baseados na forma como os protocolos TCP/IP foram implementados e alguns, como o SYN flood, não existem correções, ou seja, eles existem e continuarão existindo. Só nos resta nos defender deles.
Um destes ataques de negação de serviço é o SYN flood, que quando realizado de forma distribuída (dDoS) derrubam o serviço mesmo!
a) DoS local: nesta o atacante possui acesso à máquina, ou porque é um usuário legítimo, ou porque roubou a senha de um usuário ou ainda porque explorou alguma vulnerabilidade (como em scripts PHP mal programados, por exemplo). De qualquer maneira, para que esta técnica tenha sucesso o atacante deve ter condições de executar comandos locais na máquina.
Mas o que o atacante, estando na máquina, pode fazer para derrubar serviços? Muitas coisas! Pode executar comandos em seqüência que esgotem a memória, por exemplo. Ou a capacidade do kernel de criar novos processos. Um exemplo bem típico de DOS local é o atacante fazer:
# dd if=/dev/zero of=/var/spool/mail/usuario
(considerando que /var/spool/mail é partição onde estão os emails dos usuários e que ele possa escrever no arquivo usuario, que é seu)
Se nenhuma defesa existir (neste caso seria o emprego de quotas), o disco ou esta partição será esgotado, impedindo a entrada de novos emails. Causa-se um DoS no serviço de email.
As defesas para DoS locais são fáceis e requerem apenas a sua configuração, como o emprego de quotas, particionamento correto do disco e a adoção de limites de recursos para cada processo ou usuário (no Linux tem o PAM limits que faz isto).
b) DoS remoto: neste o atacante não precisa estar logado na máquina e nem executar comandos nela. Remotamente, de alguma forma, ele derruba o serviço.
Programas mal feitos, com bugs, são os recordistas deste tipo de negação. Devido a descuidos na programação, as vezes só por enviar um pacote devidamente construído já é suficiente para derrubar o serviço.
O lendário ping da morte pode ser citado como um exemplo bem típico. Ou ainda o ataque XMAS (árvore de natal), onde se enviava um pacote TCP com todos os flags ligados (anormal e impossível. Como um pacote teria, por exemplo, flag de SYN, RST e FIN ao mesmo tempo?).
Uma pilha TCP bem programada deveria descartar este pacote, mas implementações antigas se perdiam e caiam. De qualquer forma estes ataques, baseados em erros de programação, acabam tendo vida curta: só existem até que o fabricante do sistema disponibilize correções (se bem que por vezes acabam sendo eternos para aqueles que não aplicam correções nos seus sistemas).
Mas existem as negações de serviços que são baseados na forma como os protocolos TCP/IP foram implementados e alguns, como o SYN flood, não existem correções, ou seja, eles existem e continuarão existindo. Só nos resta nos defender deles.
Um destes ataques de negação de serviço é o SYN flood, que quando realizado de forma distribuída (dDoS) derrubam o serviço mesmo!