Ataques Syn Flood.

Sabemos que é, ou quase é, impossível conter um ataque DoS/Syn Flood em um servidor porém, existe uma regra que se aplicada no IPtables onde algúns admins usam, parece conter esses ataques. A regra chama-se Syn Cookie e se eu entendí direito, ela só aloca recursos quando receber o terceiro e último pacote do handshake, onde ele só irá alocar os recurso no último ACK porém, se o SYN inicial acontecer. Parece que ele manipula os números sequênciais e de verificação do TCP, onde ao enviar o primeiro SYN é enviado também um número de 32 bits que é manipulado, gerado e acrescentado pelo servidor e devolvido ao cliente que ao completar o handshake, devolve ele acrescido de um número onde será verificado pelo servidor refazendo o cálculo do Hash e supondo que o cliente seja legítimo.

Alguém já aplicou e testou essa regra e realmente ela funciona contra os ataques?

Grande anjoed!!!

A implementação da regra está ok, eu sabia como implantar, o que eu realmente queria saber e testar é, até que ponto o syncookie segurava um ataque desses.

Fizemos algúns testes e os mesmos nos mostraram que, pacotes enviados com intervalos de tempo maiores e poucas máquinas, ele consegue impedir que a máquina gaste recursos demais com conexões que não pretendem se concluir, porém, aumentando os envios e máquinas, sem chance, não segura nada e o web server e consequentemente a lan vão ao chão rapidamente.

O syncookie leva em consideração que a máquina atacante realmente não pretende terminar o handshake, ou seja, que ele está forjando os pacotes syn sem usar os recursos do próprio kernel senão, ela cairia junto por falta de recursos, mas, não protege contra ataques distribuídos, em que diversos computadores realmente fecham a conexão.

Só para vocês terem uma ideia, fiz testes também com conexão discada onde eu utilizei um aplicativo e diminuí o tcp windows e de tempos em tempos enviava um pacote para não permitir o timeout do socket, com isso conseguí também esgotar recursos do meu servidor sem precisar usar muita banda. Nessa brincadeira, o web server foi ao chão rapidamente e o acesso administrativo "conseguiu" sobreviver por pouco tempo, pois eu ainda tinha buffers e interrupções sobrando para atender as requisições.

Uma observação interessante, normalmente as implementações do TCP/IP geram retransmissões para pacotes que supostamente não chegaram ao destino, logo mais pacotes para inundar a rede.

A grande maioria dos admins acham que syn limit como esta na firewall iria resolver esse problema:

iptables -A FORWARD -p tcp --syn -m limit --limit 7/s -j ACCEPT

iptables -A FORWARD -p tcp --syn -j DROP

Poderia até funcionar e deixar o servidor no ar mas, nesse caso, quem irá negar serviço será a firewall.

Resumindo, os ataques de negação são feitos para vários propósitos mas, a grande maioria dos malas o fazem apenas para terem o prazer de derrubar um server e o admin ter que rebootar os sistemas.

Mais novidades eu vou postando...

(...) continuando os estudos e testes,

eu realmente chego a conclusão que a infra-estrutura de roteamento ainda é extremamente vulnerável a este tipo de ataque, ou seja, ataques de negação de serviço DoS/DDoS.

Nesses ataques, são caracteristicas o facto do desconhecimento da sua origem verdadeira, visando tornar inacessíveis os demoms instalados pelas vítimas, e este objetivo, normalmente é alcançado através do envio de Ns pacotes com uma taxa de banda maior do que podem ser servidos, e fazendo com que as legítimas requisições ao daemom não sejam atendidas.

O mais interessante e pertubador, é o facto de não conseguir conter e identificar sua origem, pois a técnica usada pelo datagrama no protocolo IP é mantida pelo facto de poder injetar pacotes na rede com endereço forjado, não existindo mecanismos responsáveis pela verificação da autenticidade da origem/fonte, além do mais, como todo roteamento é baseado exclusivamente no endereço de destino, pacotes com endereço de origem forjado geralmente alcançam a vítima sem dificuldades. Uma outra curiosidade e característica que permite a execução de ataques anônimos é a ausência de estado nos roteadores, onde nenhuma informação relativa aos pacotes roteados é armazenada para consultas futuras e em face disso, o encaminhamento dos pacotes não deixam pegadas tornando assim, quase impossível descobrir as rotas percorridas por eles.

Pode-se ofuscar a identificação da fonte também, através de ataques indiretos que consistem no uso de estações intermediárias, ativas ou passivas, entre uma ponta e a outra.

Muitas soluções são usadas na identificação dos causadores desses ataques e um recurso bem aceito na área são os filtros de Bloom, que consistem na realização de testes de pertinência visando determinar a afiliação de um elemento a um grupo determinado. Outras soluções estão sendo desenvolvidas para esse propósito, e os filtros de Bloom estão sendo utilizados, aperfeiçoados e implementados para mitigar o impacto causado por esses ataques aos grandes servidores e provedores.

O mundo acadêmico também está dando uma grande contribuição e amparo nessas questões, e esperamos que ambos os esforços, contínuos, estimulantes nos tragam soluções para uma rede cada vez melhor.

(...)

nao sei se posso postar aqui. parece ser um topico didatico e explicativo. gostaria apenas de agradecer a explicaçao profunda sobre o assunto guru Lord. eu tinha uma ideia de como era esse ataque, agora voce deu uma explicaçao mais tecnica sobre ele e pelo que li nem o firewall resolve. mas eu tenho uma curiosidade e se me permitir. se esse ataque é fulminante e nao podemos fazer nada para conter, o que devemos fazer a respeito. como proceder em face de estar recebendo um ataque desses. em um aspecto usuario e empresas. como identificar que e um ataque de negaçao e o que fazer.

Olá Phin3as Phr3ak,

Gurú, eu?, imagina, sou apenas um aprendiz. Tenho certeza que no fórum existem pessoas mais elevadas que eu sobre o assunto.

Bom, vamos lá, tentarei explicar e tirar suas dúvida acerca do tema.

se esse ataque é fulminante e nao podemos fazer nada para conter

Realmente não tem o que fazer. Um ataque bem distribuído e bem executado, nem o provedor ISP poderá contê-lo, a não ser que, a somatória das bandas sejam menores que do provedor, o que geralmente não o é, porém, não é o caso e muito menos o perfil dos atacantes perpetrarem ataques à ISP, pelo simples facto que eles precisam dos links.

O que torna os ataques tão poderosos, além do já explicado acima, é que eles podem ser distribuidos e as vítimas poderão ser atingidas por ataques do tipo UDP flood, TCP flood, ICMP flood ou Smurf/fraggle, nesse caso, o daemon pode ser instruído para alternar aleatóriamente entre estes quatro tipos de ataque. O controle remoto do master é realizado através de comandos via pacotes TCP, UDP, ICMP ou os três de modo aleatório. Estes pacotes são criptografados usando o algoritmo CAST. Deste modo, a filtragem de pacotes ou qualquer outro mecanismo passivo, torna-se impraticável e ineficiente. Geralmente essas ferramentas são completamente silenciosas, isto é, não existe confirmação (ACK) na, e da recepção dos comandos, a comunicação de controle é unidirecional e o master ainda poderá utilizar um endereço IP forjado, dificultando ainda mais sua localização.

o que devemos fazer a respeito. como proceder em face de estar recebendo um ataque desses. em um aspecto usuário e empresas.

Como dito, não há muito o que fazer. No âmbito doméstico, ao perceberes teu servidor/máquina ficando lenta ao ponto de parar os daemons, pode-se acreditar que muito provavelmente você está sendo vítima de um ataque DoS/DDoS. É prudente sempre manter as firewalls e os AVs atualizados e em vigília constante para segurar até certo ponto os ataques e evitar outros tipos de incursões.

No âmbito corporativo, além das recomendações acima, existem outros procedimentos à serem executados pela equipe de tratamento e resposta à incidentes.

Incrementar a segurança no server é uma das primeiras atitudes à serem feitas, sendo que a característica principal deste ataque é a formação de uma rede de máquinas comprometidas atuando como masters e agentes, recomenda-se fortemente aumentar o nível de segurança de suas máquinas, isto dificulta a formação da rede do ataque. A instalação de patches também é primordial, pois os sistemas utilizados pelos atacantes geralmente contém brechas nos sistemas possibilitando porém o ataque em execução. Limitar banda por tráfego, aplicar filtros anti-spoofing na máquina ou nos routers de borda para prevenir que eles não enviem pacotes forjados, etc, também são práticas corporativas para mitigar os ataques.

Muitas dessas ferramentas de ataques DoS/DDoS podem lançar vários ataques no estilo Smurf/Fraggle, pois eles utilizam mecanismos de envio de pacotes à endereços de broadcasting, e um recurso que está sendo muito utilizado pelas empresas é implementar em todas as interfaces dos routers, directivas que previnam o recebimento destes pacotes, endereçados à tais endereços, isso evitará que sua rede seja amplificada, dando maior poder de fogo ao ataque. Caso se interesse pelo estudo desse assunto, segue mais informações a respeito do ataque Smurf/Fraggle em: http://users.quadrunner.com/chuegen/smurf .

como identificar que e um ataque de negaçao e o que fazer.

A lentidão e consequentemente a interrupção dos daemons são sinais característicos desses ataques. As firewalls, IDS, anti-spoofing, são ferramentas que registram em log e comprovam a pertinência dos ataques.

depois de uma explicaçao dessa é mais que guru Oo. muito obrigado mestre Lord pela excelente explicação e conteudo. estarei lendo os links indicados e qualquer duvida eu retorno e posto aqui.

Achei bem interessante o teste feito. Já fiz inúmeros testes com regras IPTABLES e SYN Flood e realmente foram poucas as ocasiões (p'ra não dizer quase nenhuma) em que conseguir ter a certeza que apenas ACLs do IPTABLES pudessem sanar ataques assim.

Não há como ter a prevenção completa, nisso concordo. Mas ainda assim vale se preparar muito pra evitar esse cenário quando ele ocorrer. Também concordo que um syn flood bem arquitetado a minuciosamente distribuído pode ser fatal e até chato, extremanmente chato de conviver quando seu sítio ou ambiente doméstico se torna alvo ininterrupto.

Eu ainda prefiro acreditar que testar, testar e testar (se preparar e se munir de informação) seja o melhor caminho para se prevenir ou estar habilidosamente apto quando se vir de frente a um ataque de syn flood.

Para quem gosta de reproduzir esse ataque e quer testar esse cenário, tem uma discussão bem interessante aqui (http://www.hexcodes.org/mptcp.i) sobre um ambiente/ferramenta de ataque em português que pode ajudar na reprodução e comportamento de um cenário assim (Mptcp junto com IPTABLES).

Enfim, acho muito difícil esse tipo de situação ser condensada a zero e resolver o problema, mas ainda sugiro que quanto mais informação e planejamento por parte do Administrador, mais munido ele fica quando se ver diante de tal ataque.

Até..

Olá Adminin,

Achei bem interessante o teste feito. Já fiz inúmeros testes com regras IPTABLES e SYN Flood e realmente foram poucas as ocasiões (p'ra não dizer quase nenhuma) em que conseguir ter a certeza que apenas ACLs do IPTABLES pudessem sanar ataques assim.

Não há como ter a prevenção completa, nisso concordo. Mas ainda assim vale se preparar muito pra evitar esse cenário quando ele ocorrer. Também concordo que um syn flood bem arquitetado a minuciosamente distribuído pode ser fatal e até chato, extremanmente chato de conviver quando seu sítio ou ambiente doméstico se torna alvo ininterrupto.

Eu ainda prefiro acreditar que testar, testar e testar (se preparar e se munir de informação) seja o melhor caminho para se prevenir ou estar habilidosamente apto quando se vir de frente a um ataque de syn flood.

Para quem gosta de reproduzir esse ataque e quer testar esse cenário, tem uma discussão bem interessante aqui (http://www.hexcodes.org/mptcp.i) sobre um ambiente/ferramenta de ataque em português que pode ajudar na reprodução e comportamento de um cenário assim (Mptcp junto com IPTABLES).

Enfim, acho muito difícil esse tipo de situação ser condensada a zero e resolver o problema, mas ainda sugiro que quanto mais informação e planejamento por parte do Administrador, mais munido ele fica quando se ver diante de tal ataque.

Até..