[GTER] Resposta a post 2006 - Ataques de DDoS, será que existe uma solução ?

Tue Sep 23 20:48:18 -03 2008

Guilherme,

Me tira uma dúvida.... quem no Brasil fornece "clean pipes" ???
No momento desconheço qualquer provedor no Brasil que forneça este produto,
pois as soluções são muito caras, para garantir uma eficiencia 100%.

Att.

Voce pagaria para ter um link "clean pipe" levando em consideração que o
custo de seu link atual poderia até dobrar ??

2008/9/20 Guilherme Alberto <guilherme at maxihost.com.br>

> Antonio,
>
> Realmente este tipo de ataque é bem comum, e nós já encontramos uma solução
> para os
> clientes que possuem servidor de counter strike conosco, e que autenticam
> na valve, que fica no exterior. Mesmo com
> blackhole estamos utilizando uma forma de autenticar na valve através de
> outro método (melhor não colocar aqui para não dar brecha para os hackers)
>
> Já recebi estes ataques de 1Gb/s de nodes nacionais, mas vou te confessar
> que não me assustam, é bem dificil os hackers encontrarem um servidor no
> Brasil comprometido, posso te dizer que nestes últimos anos, 99,99% dos
> ataques realmente foram nodes no exterior
>
> Sobre os ataques many>many já aconteceu, e não foram poucas vezes. Após
> algum tempo que implantamos o Fireslayer, os hackers identificaram que
> atacar um IP apenas não adianta, devido a velocidade com que o bloqueio é
> efetuado. Ficamos fora do ar algumas vezes quando este tipo de ataque
> começou a ocorrer, porém agora o sistema já possui uma nova versão que
> efetua o bloqueio automático do /24 se a rede receber ataques em mais que X
> IPs em menos de X segundos, e vai liberando o /24 aos poucos até o hacker
> desistir. Já aconteceu do sistema ter que bloquear o /20 também.
>
> Nós estamos atualmente com a Intelig, e parece que eles não querem adotar
> este sistema de clean pipes, inclusive o "sistema" de bloqueio deles é nulo.
> Fica uma pessoa no NOC olhando para a tela do MRTG e quando o tráfego sobe
> ele vai atras para saber para onde foi, quem foi, quando, onde, etc (isto
> quando o técnico dorme e deixa o backbone recebendo ataque a madrugada
> inteira). A política deles para DDoS é tirar o anúncio do /20 do cliente e
> informar a ele que está recebendo ataque. Eu acho esta atitude um completo
> desrespeito, tanto do backbone com o hosting quando do hosting com cliente
> final. Sempre acreditei que DDoS não é problema do cliente final, é
> responsabilidade do iDC resolver.
>
>
>
> Ps: (não da nem para chamar de hackers né ? um ataque simples deste podemos
> chamar de muleques sem nada o que fazer mesmo)
>
> Atenciosamente
>
> Guilherme Alberto
> www.maxihost.com.br
> ----- Original Message ----- From: "Antonio Carlos Pina" <
> antoniocarlospina at gmail.com>
> To: "Grupo de Trabalho de Engenharia e Operacao de Redes" <
> gter at eng.registro.br>
> Sent: Saturday, September 20, 2008 3:00 PM
> Subject: Re: [GTER]Resposta a post 2006 - Ataques de DDoS, será que existe
> uma solução ?
>
>
> Na verdade, o que o Guilherme está apresentando é um dos tipos de ataques.
> E
> eu vou concordar com ele que isso é um tipo bastante comum.
> l
> Evidente que se o cliente é um servidor de jogos que possui um hub
> internacional, ele perde a conexão com o hub até que se retire o anúncio
> feito com as comunidades para as operadoras.
>
> Entretanto, com o crescimento dos links nacionais, eu já recebi ataques de
> mais de 1Gb/s 100% nacionais. Logo, o exemplo citado pelo Guilherme é um
> dos
> possíveis casos, mas já deixou de ser "o padrão" há algum tempo. Guilherme,
> se você só recebe ataques desse tipo (internacionais com o kiddie testando
> com ping do seu adsl/cable modem), ótmo para você e eu desejo sinceramente
> que continue assim. Mas o padrão vem mudando e na medida que as operadoras
> nacionais aumentam suas capacidades, o potencial de ataques cresce.
>
> Fora ataques do tipo many->many (milhares de sources spoof contra todos os
> seus endereços destino). Você aplicará blackhole em todos os seus endereços
> ?
>
> Além do sistema da Arbor, existe o WanGuard que faz clean-pipes, mas me
> parece que ele só vai até 155Mb/s (está no website) de capacidade de
> tratamento, o que, na minha visão, já o invalida para qualquer uso mais
> sério atualmente a não ser no lado da operadora para atender clientes até
> STM-1.
>
> Abs
>
> 2008/9/20 Julio Arruda <jarruda-gter at jarruda.com>
>
>  Guilherme Alberto wrote:
>>
>>  Júlio,
>>>
>>>  Mas se o destino do ataque esta fora (blackholed), como o hacker
>>>
>>>> assumiria que o ataque foi ineficaz ? Eu ja vi ataques "rotativos", mas
>>>> somente em mitigacoes inteligentes, onde um scrubber mantem o site no ar
>>>> "apesar" do ataque, ai o atacante vai variando o ataque, mas com
>>>> blackhole..
>>>>
>>>>
>>> Não sei como você está acostumado a utilizar certos termos, mas eu
>>> utilizo
>>> da seguinte forma,
>>> Blackhole - Bloqueio para trafego internacional
>>> Synchole - Bloqueio para trafego nacional
>>> Eu aprendi desta forma, não sei se é a correta, mas é como eu costumo
>>> falar aqui com o pessoal da empresa
>>>
>>>
>> http://www.arbornetworks.com/downloads/Sinkhole_Tutorial_June03.pdf
>> Acho que no NANOG, RIPE e APRICOT tem tambem bastante material..
>>
>> o Sinkhole e' na verdade um blackhole que vai para algum lugar :-), nao
>> para Dave Null..ao menos eu gosto de dizer que, blackhole, e' um caso
>> especifico do sinkhole na verdade, pois ambos funcionam exatamente da
>> mesma
>> forma.
>> Blackhole por regioes, e' ainda assim, chamado de blackhole, geralmente
>> associado com communities especificas por exemplo, voce anuncia 666 para
>> 'tudo para o lixo', 667 para somente peers nacionais para lixo e por ai
>> vai,
>> certo ?
>>
>> O scrubber de que falava, usa tambem o mesmo tipo de gato, e' via um tipo
>> de sinkhole (nome bonito seria "offramping") para levar o trafego ao
>> scrubber. Existe a opcao de ser inline, mas eu nao sou nem um pouco
>> simpatico a ideia..existem clientes que usam, mas nao na America Latina
>> (ao
>> menos nos projetos que me envolvi). Consideracoes de que voce NAO precisa
>> 2-way traffic para fazer a mitigacao, e que vai estar adicionando ponto de
>> falha, latencia (minima que seja), complexidade de gerencia
>> (bump-in-the-wire, mas esta la :-)....
>>
>>
>>
>>  O hacker vai assumir que o ataque foi ineficaz pelo seguinte, este hacker
>>> está no Brasil com um ping -t no IP atacado, ele
>>> vai usar sua botnet para derrubar este destino, e a botnet possui
>>> servidores vulneráveis em todos os lugares do mundo, assim
>>> que lançado o ataque, o sistema vai detectar e subir anuncio BGP na
>>> community de blackhole para o /32 atacado, bloqueando
>>> todo o tráfego internacional e permitindo apenas o nacional, então ele
>>> vai
>>> pensar, ué, meu ataque não funcionou, o IP continua pingando
>>> mesmo atacando.
>>> Em raríssimos casos o hacker consegue um servidor vulnerável no Brasil em
>>> um Datacenter com muita banda, e desta forma realmente para
>>> este hacker o ataque é eficaz, uma vez que nossa única opção é subir o
>>> anúncio BGP como synchole pelo sistema, indisponibilizando totalmente o
>>> acesso
>>>
>>>
>> Humm..vou discordar..
>> DDoS nao e' feito somente de servidores com muito upstream, ele e' feito
>> com volume de bots mesmo. Entao, alguns 10.000 de cable users sao problema
>> para qualquer provedor. O que os pesquisadores que conhecem dizem, e' que
>> eles geralmente segregam porcoes da botnet com mais banda para
>> determinados
>> ataques por exemplo. So que ao menos em um grande site de eCommerce, teve
>> sim, zombies ai no Pindorama (e ao menos um C&C la nos hermanos :-))
>>
>>  nacional e internacional, porém mesmo assim se o ataque for grande você
>>
>>> protege sua rede, indisponibilizando apenas o /32 atacado e não seu /24
>>> ou
>>> seu /20 todo
>>>
>>>
>> Por isto estou dizendo, o /32 (a vitima), com um blackhole, vai para o
>> brejo, por isto nao e' considerado uma solucao de Clean Pipes/Protecao de
>> DDoS para a vitima propriamente dita...
>> Estou de pleno acordo de que em alguns casos, simplesmente cortando o dedo
>> para salvar o braco faz sentido, so que se o dedo for o recurso a ser
>> protegido, blackhole vai "completar" o ataque..
>>
>>
>>   Que servidor comprometido ? a vitima do ataque ? Que atitude ele pode
>>>
>>>> tomar em um caso destes ?
>>>>
>>>>
>>>
>>>  Por isto queria entender a nomenclatura, geralmente eu vejo bot ou
>> zombie
>> sendo aplicado para descrever as 100s de maquinas comprometidas.
>>
>>  O servidor comprometido não é a vítima do ataque e sim o servidor zoombie
>>
>>> utilizado pelo hacker para lançar o ataque.
>>> A atitude que o provedor pode tomar é simplesmente tirar o cabo de rede
>>> do
>>> cliente dele e mandar formatar a maquina :) e o cliente pode resolver o
>>> problema fechando
>>> seu /tmp ou colocando um firewall na saida
>>>
>>>
>>>  Hehe...sim, walled gardens, e por ai vai, isto tudo e' parte do 'outra
>> parte' do problema, um dos motivos pelo qual a Arbor comprou a Ellacoya.
>> Agora, ao menos na America Latina, o que vejo MUITO mais forte, e' ainda a
>> preocupacao com o lado "destino" dos ataques.
>>
>>
>>  Atenciosamente,
>>
>>>
>>> Guilherme Alberto
>>> www.maxihost.com.br
>>> ----- Original Message ----- From: "Julio Arruda" <
>>> jarruda-gter at jarruda.com>
>>> To: "Grupo de Trabalho de Engenharia e Operacao de Redes" <
>>> gter at eng.registro.br>
>>> Sent: Friday, September 19, 2008 10:56 PM
>>> Subject: Re: [GTER] Resposta a post 2006 - Ataques de DDoS, será que
>>> existe uma solução ?
>>>
>>>
>>> Guilherme Alberto wrote:
>>>
>>>  Júlio,
>>>>
>>>> Entendi sua colocação.
>>>>
>>>>  Uma curiosidade...se o seu exemplo de blackhole 'automatico', que fica
>>>>
>>>>> no ar por 20 minutos, como ele sabe se o ataque se foi ?
>>>>> Ele tem que 'abrir a comporta' para ver se ainda tem ataque, certo ?
>>>>>
>>>>>
>>>> Ele não sabe na verdade se o ataque se foi, precisa abrir a comporta
>>>> novamente e verificar se o ataque continua
>>>>
>>>>  Eu sei que uma dos truques de scrubber com mitigacao automatica, e'
>>>>
>>>>> exatamente o ponto onde voce monitora o ataque :-).
>>>>> Se e' DEPOIS do scrubber, voce tem a impressao que o ataque se foi,
>>>>> assim que comeca a mitigacao, e ai, se o sistema 'desabilita' a
>>>>> mitigacao
>>>>> novamente, o ataque recomeca, e fica o sistema
>>>>> 'mitigando/nao-mitigando' em
>>>>> ciclos :-)..
>>>>>
>>>>>
>>>> Em 80% dos casos, o ataque não continua após os 20 minutos, pois o
>>>> atacante verifica que existe algum tipo de
>>>> proteção automática, ou seja, tornou o ataque dele ineficaz em 8
>>>> segundos
>>>> e para de atacar.
>>>>
>>>>
>>> Mas se o destino do ataque esta fora (blackholed), como o hacker
>>> assumiria que o ataque foi ineficaz ? Eu ja vi ataques "rotativos", mas
>>> somente em mitigacoes inteligentes, onde um scrubber mantem o site no ar
>>> "apesar" do ataque, ai o atacante vai variando o ataque, mas com
>>> blackhole..
>>>
>>>  Nos outros 20%, o que tenho visto acontecer é mitigar/não mitigar por
>>>
>>>> umas 4-8 vezes, depois disto o responsável pelo
>>>> servidor comprometido acaba tomando uma atitude, já que o sistema fica
>>>> avisando o ASN responsável de 20 em 20 minutos até o ataque cessar.
>>>>
>>>>
>>> Que servidor comprometido ? a vitima do ataque ? Que atitude ele pode
>>> tomar em um caso destes ?
>>>
>>>  Atenciosamente,
>>>
>>>>
>>>> Guilherme Alberto
>>>> www.maxihost.com.br
>>>> ----- Original Message ----- From: "Julio Arruda" <
>>>> jarruda-gter at jarruda.com>
>>>> To: "Grupo de Trabalho de Engenharia e Operacao de Redes" <
>>>> gter at eng.registro.br>
>>>> Sent: Friday, September 19, 2008 8:14 PM
>>>> Subject: Re: [GTER] Resposta a post 2006 - Ataques de DDoS, será que
>>>> existe uma solução ?
>>>>
>>>>
>>>> Guilherme Alberto wrote:
>>>>
>>>>  Júlio,
>>>>>
>>>>> Vamos lá. Em relação ao HTTP flood da Amazon, certamente que um
>>>>> Blackhole iria comprometer muitos usuários, ou seja, comprometer
>>>>> muito tráfego legítimo, entretanto as operadoras/backbones do exterior
>>>>> possuem APIs mais avançadas que nós para que o bloqueio seja feita
>>>>> de outra maneira, bloqueando a origem ao invés do destino com
>>>>> blackhole.
>>>>> Ainda mais que os backbones de fora possuem uma largura de
>>>>> banda muito maior que a nossa para poder segurar este tráfego no
>>>>> "muque"
>>>>> sem comprometer o tráfego legítimo, entretanto nossa realidade é outra;
>>>>> Sem
>>>>> dúvidas
>>>>> eles podem trabalhar com ACLs para bloquear este tráfego, porém se
>>>>> fizermos isto aqui em um ataque de grande magnitude não adiantaria e a
>>>>> única
>>>>> coisa que resolveria
>>>>> seria efetivamente um blackhole.
>>>>>
>>>>>
>>>> Na verdade, existem ocasioes em que usam Blackhole, mesmo alguns
>>>> clientes que conheco com n x 10G de banda. Novamente, e' ferramenta e
>>>> existe para ser usada, so que faz parte de um 'toolkit', nao e' a unica
>>>> :-)..
>>>> Quanto ao bloqueio por origem...nao e' bem API, sao scrubbers que sao
>>>> usados nos casos que conheco. E nao e' para bloqueio
>>>> indiscriminadamente, vide caso do spoofing.
>>>> E ACL, sinceramente, apesar de ferramenta tambem, entra em caso similar
>>>> a do blackhole.
>>>> (deny Http para um servidor Web == blackholear o bicho :-)..
>>>>
>>>> Quando voce esta 'do outro lado do link', a carrier, o seu negocio e'
>>>> vender link, e link e' commodity, por isto, eles querem oferecer
>>>> solucoes que 'preservem os servicos' do cliente.
>>>> O blackhole ou acls/flowspec, podem ser usados por exemplo, para um
>>>> cliente sem contrato de Clean Pipes, assim a carrier economiza recursos
>>>> de scrubber por exemplo.
>>>>
>>>>
>>>> Uma curiosidade...se o seu exemplo de blackhole 'automatico', que fica
>>>> no ar por 20 minutos, como ele sabe se o ataque se foi ?
>>>> Ele tem que 'abrir a comporta' para ver se ainda tem ataque, certo ?
>>>>
>>>> Eu sei que uma dos truques de scrubber com mitigacao automatica, e'
>>>> exatamente o ponto onde voce monitora o ataque :-).
>>>> Se e' DEPOIS do scrubber, voce tem a impressao que o ataque se foi,
>>>> assim que comeca a mitigacao, e ai, se o sistema 'desabilita' a
>>>> mitigacao novamente, o ataque recomeca, e fica o sistema
>>>> 'mitigando/nao-mitigando' em ciclos :-)..
>>>>
>>>>
>>>>
>>>>
>>>>> Atenciosamente,
>>>>>
>>>>> Guilherme Alberto
>>>>> www.maxihost.com.br
>>>>> ----- Original Message ----- From: "Julio Arruda" <
>>>>> jarruda-gter at jarruda.com>
>>>>> To: "Grupo de Trabalho de Engenharia e Operacao de Redes" <
>>>>> gter at eng.registro.br>
>>>>> Sent: Friday, September 19, 2008 4:07 PM
>>>>> Subject: Re: [GTER] Resposta a post 2006 - Ataques de DDoS, será que
>>>>> existe uma solução ?
>>>>>
>>>>>
>>>>> Guilherme Alberto wrote:
>>>>>
>>>>>  Júlio,
>>>>>>
>>>>>> Acredito que você não tenha entendido. A "vitima" tendo BGP, ASN
>>>>>> próprio e comunidades de
>>>>>> blackhole e synchole liberadas pelas operadoras o sistema resolve sim.
>>>>>> No nosso caso, possuimos uma classe /10, ou seja,
>>>>>> somos ASN, possuimos o BGP e estas comunidades são liberadas pelas
>>>>>> operdoras para anuncio em /32. Detectado um ataque
>>>>>> internacional (na maioria dos casos são internacionais) o sistema
>>>>>> efetua em 8 segundos anuncio blackhole em /32, se for ataque nacional
>>>>>> simplesmente faz o synchole no /32. Tem outras funções de avisar o ASN
>>>>>> do atacante, e também por exemplo se atacar vários IPs da classe
>>>>>> ao mesmo tempo faz bloqueio no /24 se estiver enchendo o link.
>>>>>>
>>>>>> Você perguntou se a The Planet comprou a Ev1 ? Sim, isto faz tempo.
>>>>>>
>>>>>>
>>>>> Entendi, o que estou dizendo, e' que o blackhole, nao resolve problemas
>>>>> de DDoS em que o resource sendo atacado tem que ser protegido, o que
>>>>> ele
>>>>> ajuda (e faz parta, podemos dizer, do 'kit de ferramenta' de defesa),
>>>>> e'
>>>>> a isolar parte da network, para que outras partes nao sofram dano
>>>>> colateral.
>>>>> Exemplo, se e' um HTTP flood contra o servidor da Amazon, eles nao
>>>>> podem
>>>>> fazer um blackhole daquele trafego :-)...e por ai vai, outros servicos
>>>>> podem ter a mesma caracteristica, em que se voce fizer um blackhole (e
>>>>> muitas vezes, ate mesmo ACLs), voce 'completou' o DDoS contra aquele ip
>>>>> sob ataque..
>>>>>
>>>>>
>>>>>  ----- Original Message ----- From: "Julio Arruda" <
>>>>>
>>>>>> jarruda-gter at jarruda.com>
>>>>>> To: "Grupo de Trabalho de Engenharia e Operacao de Redes" <
>>>>>> gter at eng.registro.br>
>>>>>> Sent: Thursday, September 18, 2008 7:39 PM
>>>>>> Subject: Re: [GTER] Resposta a post 2006 - Ataques de DDoS, será que
>>>>>> existe uma solução ?
>>>>>>
>>>>>>
>>>>>> Guilherme Alberto wrote:
>>>>>>
>>>>>>  Olá Pessoal,
>>>>>>>
>>>>>>> Sou novo na lista do GTER e gostaria de fazer meu primeiro post em
>>>>>>> resposta a uma mensagem
>>>>>>> que encontrei por acaso no Google referente a problemas com ataques
>>>>>>> DDoS em provedores no Brasil,
>>>>>>> http://eng.registro.br/pipermail/gter/2006-April/010329.html
>>>>>>>
>>>>>>> Nós da MaxiHost estamos utilizando já há alguns meses a solução
>>>>>>> oferecida pela empresa FireSlayer (http://www.fireslayer.com.br).
>>>>>>> Nós
>>>>>>> estamos bastante infiltrados na àrea de servidores de jogos, e como
>>>>>>> todos
>>>>>>> devem saber, estes recebem ataques DoS/DDoS de grande magnitude
>>>>>>> diariamente.
>>>>>>>
>>>>>>> O FireSlayer é o modelo de sistema de proteção que a antiga Ev1
>>>>>>> adotava adaptado para o Brasil, eles formataram um sistema que fica
>>>>>>> compatível com as limitações que possuimos atualmente no Brasil nos
>>>>>>> backbones.
>>>>>>>
>>>>>>> É bem interessante, consegue bloquear qualquer ataque DoS/DDoS em
>>>>>>> mais
>>>>>>> ou menos 8 segundos, avisa automaticamente os responsáveis pelo ASN
>>>>>>> sobre o
>>>>>>> ataque com logs sobre o evento e possui uma interface bem amigável.
>>>>>>>
>>>>>>> Vale a pena dar uma olhada la.
>>>>>>>
>>>>>>>
>>>>>> Pelo que entendi do ataque que e' mencionado no thread, nao
>>>>>> resolveria.
>>>>>> Nenhuma solucao "do lado da vitima" resolveria..
>>>>>> Um ataque de DDoS de 155Mbps (pequeno portanto), nao tem como ser
>>>>>> 'limpo' do lado da vitima que tem um E3 de banda por exemplo..
>>>>>>
>>>>>> disclaimer, trabalho na Arbor, que fornece DDoS gear para The Planet,
>>>>>> que entendo, comprou a EV1 ?
>>>>>>
>>>>>>  --
>>>>>
>>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>
>>> --
>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>
>>>
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
>>  --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>