[GTER] Melhores Práticas em Ataques DOS/DDOS

Sat Aug 11 10:29:59 -03 2012

Bom dia,

Tenho um texto ótimo que pode te dar uma luz.

Uso irresponsável do T50A muito
tempo não escrevo um artigo em português, assim como já faz muito tempo que
nada escrevo sobre este tema, porém nos últimos dias foram liberados alguns alertas sobre a utilização do T50
para fins de DoS e DDoS e me senti na obrigação de romper com o
silêncio. Antes de
continuar, quero re-afirmar que NÃO APÓIO:O
     uso irresponsável do T50 e me sinto desrespeitado quando grupos de
     pessoas o utiliza desta forma, pois fui categórico ao colocar um aviso no
     "help/usage" do T50:"5. Be nice
      when using t50, the author DENIES its use for DoS/DDoS purposes."Qualquer
     uso to T50 para finalidade de DoS e DDoS contra
     qualquer entidade, empresa, instituição, etc.As
     causas, os grupos de pessoas e as formas como estes grupos de pessoas
     estão se manifestando.O T50,
como alguns já devem saber, já está integrado na distribuição Backtrack,
portanto sua finalidade de testar redes TCP/IP foi comprovada através desta
integração e dos muitos profissionais que vem utilizando o T50 de
forma responsável para medir a capacidade de operação e proteção de suas redes
em situações de grande volume de tráfego e para isso não precisam mais comprar
ou alugar equipamentos caros para realizar estes testes. Este é um exemplo do
uso responsável do T50. Porém,
buscando evitar o uso irresponsável do T50, foram criadas algumas
"travas" dentro do próprio código, entre elas uma trava para
adequação com as RFC1700, RFC1918 e RFC3330, com a qual impossibilita o uso
proposital ou acidental do T50 contra redes com endereçamento
válido na Internet, fazendo do T50 uma ferramenta de uso
exclusivo para redes locais. Porém esta "trava" não seria
um problema para desenvolvedores mal-intencionados que quisessem modificar
o T50 para uso proposital contra redes com endereçamento
válido. A
intenção principal da criação e, consequentemente, da liberação do código do T50
(Web Security Forum) foi
apenas proporcionar e compartilhar uma ferramenta de testes de estresse em
redes TCP/IP com administradores e profissionais de segurança em rede de
computadores, porém, assim como tantas outras ferramentas criadas e amplamente
utilizadas, o T50 começa a ser utilizado de forma irresponsável (deturpada)
e com finalidades mal-intencionadas. Como
muitos já devem saber, as técnicas empregadas no T50, com exceção do
envio de multi-protocolos, não são novidades e já eram amplamente conhecidas
pela comunidade de segurança (CA-1996-21). Atualmente
não faço mais parte do time de projeto do T50,
porém a equipe atual manteve algumas "travas" dentro do
código. Assim
como compartilhei a ferramenta, por acreditar que compartilhar o conhecimento é
uma das melhores formas de se educar os profissionais e entusiastas de
segurança, seguem algumas dicas, onde compartilho algumas idéias, de como se
proteger destes tipos de ataque:Bloqueio
     no segmento de borda de qualquer protocolo que não seja utilizado pela
     empresa. Por exemplo:Se
      o segmento de borda não utiliza tráfego IGMP, este tráfego deverá
      ser bloqueado.Bloqueio
      de qualquer protocolo de uso "exclusivo" interno, como
      por exemplo: RIP, DCCP, RSVP, GRE, EIGRP
      e OSPF.Criação
     de ACLs em Routers/Firewalls, assim como criação de políticas de NIPS,
     para bloqueio de anomalias nos protocolos. Por exemplo:Se
      o segmento de borda utiliza IPSec, mas o pacote IPSec venha
      com os cabeçalhos AH e ESP sem "payload",
      este tráfego deverá ser bloqueado por ser um tráfego anômalo.Tanto
      o T50 quanto algumas outras ferramentas utilização geração
      aleatória de valores para alguns campos de cabeçalho de protocolos,
      portanto isto deve ser considerado uma anomalia e seu tráfego,
      consequentemente, deve ser bloqueado.Para
     TCP SYN Flood (RFC4987), utilize SYN cookies e defesas contra anomalias
     do protocolo TCP.Para
     UDP Flood, bloqueie qualquer tráfego não necessário para este
     protocolo.Monitore
     anomalias estatísticas do volume de tráfego na rede. Por exemplo:Ataques
      de TCP SYN Flood,
      assim como demais TCP Floods, possuem pacotes de aproximadamente
      40 bytes, sendo que sua utilização não deve passar de ¼ do total do
      tráfego TCP (obviamente esta métrica deve ser
      minuciosamente avaliada para cada ambiente).Tenha
     um contato técnico interno na sua operadora de acesso à Internet, pois
     somente as operadoras poderão, de forma muito mais eficaz, criar ACLs para
     Ingress Filters (RFC2827/RFC3704), bloqueando pacotes com IP Spoofing. Por exemplo:Tráfego
      com endereçamento IP do bloco de endereços pertencente ao Rio de Janeiro
      que venham por canais de comunicação de São Paulo sugerem que este
      tráfego utiliza IP Spoofing, portanto a operadora será
      capaz de criar ACLs impedindo a propagação deste tráfego.Crie
     ACLs para Egress Filters (RFC3013), impedindo que sua rede seja
     uma origem de ataques com IP Spoofing.Crie
     ACLs para Ingress Filters (RFC2827/RFC3704), bloqueando os endereços IP
     contidos e listados nos seguintes documentos:RFC919, RFC922, RFC1112, RFC1122, RFC1356, RFC1700, RFC1918, RFC2365, RFC3068, RFC3330, RFC3927, RFC5735, RFC5736, RFC5737, RFC5771 e RFC6034.Outras
formas, um pouco mais esotéricas, podem ser adotadas. Por exemplo:Rate LimitingConnection
     LimitingTraffic ShapingQuality of ServiceBlackholeSinkholeCordialmente.Nelson
Brito

Espero que te ajude.

Beijundaaaaaaaaaaa,

Alexandre

> Date: Sat, 11 Aug 2012 08:19:02 -0300
> From: lucas.bocchi at gmail.com
> To: gter at eng.registro.br
> Subject: Re: [GTER] Melhores Práticas em Ataques DOS/DDOS
> 
> bom dia rosauro
> 
> mitigacao dessa forma so se resolve com as operadoras. ja tentei usar
> blackhole com a oi e sem sucesso aqui na nossa regiao mas se vc falar com o
> consultor da tua conta corporativa pose ser que de certo.
> no formulario da operadora uando vc contratou o link vc esclareceu que
> gostaria de usar comunities? no nosso caso nao foi e dai tivemos mais dor
> de cabeca
> se atente tbm ao fato da versao do daemon de roteamento que vc esta usando.
> se ainda eh vyatta lembro que algumas versoes tinham um bugzinho com
> communities. num cliente acabei trocando ele por um bird por causabdesse
> problema, mas isso faz tempo
> gvt nao sei pq nunca mexi com os cabras
> 
> boa sorte
> Em 10/08/2012 19:11, "Rosauro Baretta" <rosauro at rline.com.br> escreveu:
> 
> > Boa noite,
> >
> > gostaria de ajuda dos colegas, pois estamos passando pela seguinte
> > situação:
> >
> > temos 2 links com GVT e OI, e estamos sofrendo ataques DOS/DDOS com
> > destino a ips de nossos clientes... mas como a banda que vem no ataque é
> > grande acaba derrubando toda a nossa rede em vários momentos, de momento o
> > que melhor funciona é solicitar para as operadoras bloquearem do lado
> > deles.. mas o problema é a demora para isso ser feito....
> >
> > Também estamos anunciando as redes atacadas em apenas um link (e também ja
> > testamos deixar sem anunciar as redes) ai conseguimos sucesso, mas o
> > problema que ai o ataque logo aparece em outras redes...
> >
> > Aproveito para tirar uma duvida, a community  de Blackhole das operadoras,
> > eu posso passar para a operadora o IP de origem que está me gerando o
> > ataque ?
> >
> > e o que os colegas mais experientes no assunto me recomendam a fazer ?
> >
> >
> >
> > --
> > Atenciosamente,
> >
> > Rosauro Baretta
> > Fixo: 46 3555 8000
> > Cel Claro: 46 8401 4560
> > Cel TIM: 46 9975 2565
> > --
> > gter list    https://eng.registro.br/**mailman/listinfo/gter<https://eng.registro.br/mailman/listinfo/gter>
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter