Lord Enigm@
Zerinho
Registrado
5K Mensagens
642 Curtidas
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 idéia, 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.
Lord Enigm@
Zerinho
Registrado
5K Mensagens
642 Curtidas
... na continuação dos 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.
...................
Lord Enigm@
Zerinho
Registrado
5K Mensagens
642 Curtidas
Citação:
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.
Citaçã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 maiores informações a respeito do ataque Smurf/Fraggle em: .
Citação:
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.
joao_douglas
Super Participante
Registrado
965 Mensagens
19 Curtidas
A um tempo atras, não vou saber especificar o quanto, mas lembro que era no inicio da computação nas nuvens, um especialista disse o seguinte, numa revista (os com memória de verdade por favor...):
"Eu não acredito que computação nas nuvens seja algo que vá pegar, pelo menos não de imediato, esse tipo de tecnologia parte do principio que a internet vai estar sempre no ar e disponível, o que não é verdade ja que alguns serviços são muito simples de se atacar, tanto virtualmente quanto fisicamente"
E pela aula que você vem nos dando Lord Enigm@ ele tem razão...
P.S.: Não estou querendo abrir uma guerra contra a computação nas nuvens pelo contrario acho que a tecnologia é fantástica, mas antes é necessário uma serie maior de garantias para o serviço.
João Douglas
