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

Wed Sep 24 14:21:20 -03 2008

Guilherme,

Não sei o volume que você compra.
Mas dependendo do volume contratado está barato.

A operadora precisa investir em ativos, equipe especializada e monitoramento
constante para que os dados cheguem limpos até você.
Nada mais justo do que pagar por um investimento realizado e um produto de
qualidade.

Veja o caso do colega que teve um ataque que colocou a pique o seu link e
correndo o risco de se afundar o negócio.
Se tenho um baixo volume contratado a operadora me fala R$400,00 por um Mb
sujo e R$800,00 por um Mb limpo, dependendo do volume que eu comprar pago os
R$800,00 rindo ainda.
Isso é garantia para o seu negócio, menor risco de operação e melhor
qualidade do serviço para o seu cliente.

Quanto ao preço ser elevado aqui no Brasil tem vários motivos para isso e a
discusão sobre o assunto é longa e acredito não fazer parte do tema do
"forum".

Mas diversas empresas tem se juntado e conseguido melhores valores e
condições em cima do contratado.
Caso queira conversar sobre o tema pode me chamar em PVT.

-- 
Atenciosamente,
Carlos Roberto Maciel Carneiro
carlos.roberto.maciel at gmail.com
Macaé/RJ

Tel.: (22) 9869-5054

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

> Carlos,
>
> Mas o dobro já é muito não acha ? :)
> Ainda mais o absurdo que cobram para cada mbit aqui no Brasil
>
> Atenciosamente,
>
> Guilherme Alberto
> www.maxihost.com.br
> ----- Original Message ----- From: "Carlos Carneiro" <
> carlos.roberto.maciel at gmail.com>
> To: "Grupo de Trabalho de Engenharia e Operacao de Redes" <
> gter at eng.registro.br>
> Sent: Tuesday, September 23, 2008 10:10 PM
>
> Subject: Re: [GTER]Resposta a post 2006 - Ataques de DDoS, será que existe
> uma solução ?
>
>
> Nada mais justo.
> Dependendo do volume contratado sai mais barato contratar um link limpo do
> que contratar um link "sujo" e ter que investir em ativos.
>
>
> --
> Atenciosamente,
> Carlos Roberto Maciel Carneiro
> carlos.roberto.maciel at gmail.com
> Macaé/RJ
>
> Tel.: (22) 9869-5054
>
>
>
> 2008/9/23 Adriano <adr.silva at gmail.com>
>
>  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
>> >
>> --
>> 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
>