Uma Rara Oportunidade de Fazer Ataques de Negação de Serviço

Neste artigo, vou narrar uns testes de resistência a ataques de negação de serviço que um cliente nosso há uns meses atrás pediu que fizéssemos contra um de seus sites. Pedidos como esse são relativamente raros; a maioria dos operadores de sites já intuem que seus sistemas não são projetados para aguentar esse tipo de ataque e muitas vezes preferem não pensar muito a fundo no assunto. Mas esse cliente, obviamente diferenciado, não só queria pensar no assunto, mas também queria algo mais "científico" do que "achismos". Por isso, quando o pedido chegou, o pessoal da equipe de pen-test da Tempest veio me pedir umas sugestões.

Eu não só dei um monte de sugestões, mas também acabei me envolvendo, ajudando a preparar alguns dos testes (eu tinha acabado de encerrar um projeto chatíssimo e a "mudança de ares" me faria bem.) Após entregues os resultados, passei semanas aporrinhando a equipe para que eles escrevessem uma versão publicável para postar aqui no Blog; mas, como em geral acontece, fomos atropelados por outras prioridades e esquecemos o assunto.

Com os crescentes relatos de ataques feitos por "grupos hackers" (odeio essa designação) a sites brasileiros e no exterior, um monte de gente veio me perguntar como são esses ataques – perguntas tipo "como é que os caras conseguem derrubar um site?". Aí lá vou eu explicar que muitas vezes eles não atingem o site em si, mas apenas criam um engarrafamento de propósito que impede que os visitantes legítimos acessem o site. "Por que ninguém consegue se defender?" Aí lá vou eu explicar que alguns até conseguem, mas muitos não, devido à maneira específica como os sites foram montados. E por aí vai.

Foi quando lembrei que tínhamos começado a escrever algo sobre o assunto e resolvi ressucitar o artigo, pois talvez ele ajude a esclarecer na cabeça das pessoas como esses ataques funcionam.

Ressalvas

Inicialmente, é importante deixar claro que esse artigo não é uma análise dos ataques que esses "grupos hackers" têm perpetrado por aí. Antes, o foco deste artigo é descrever algumas técnicas de negação de serviço que nós usamos em um projeto para um cliente nosso de forma totalmente lícita, sob sua expressa autorização, regulada por contrato.

Se você quiser reproduzir as técnicas que descrevemos aqui, faça-o em laboratório, em sistemas de sua propriedade; ou em sistemas que você tenha permissão do proprietário. Faça como nós: obtenha a permissão por escrito. É claro que o dono do sistema vai querer entender direitinho o que você quer fazer, por que quer fazer isso, que objetivos pretende alcançar, qual o escopo exato e talvez queira impor uma série de limitações (algumas das quais talvez não lhe pareçam razoáveis ou que tornem os resultados míopes) ou lhe peça certas garantias que você talvez não tenha como dar. Mas isso faz parte do jogo. Tenha todas essas coisas muito claras na sua cabeça – ou, melhor ainda, faça como nós: ponha-as no papel na forma de uma proposta.

Em outras palavras: é perfeitamente possível obter permissão para fazer testes "perigosos", desde que as expectativas sejam alinhadas com antecedência com todos os interessados e/ou afetados, para evitar surpresas. E nada substitui ter tudo isso no papel a priori, pois, se alguma surpresa nefasta acontecer apesar dos seus cuidados, você terá como se defender. É esse tipo de cuidado que diferencia a molecagem de um trabalho sério, ético, responsável e profissional.

O Escopo do Trabalho

No nosso caso, a solicitação partiu do próprio cliente. E ele colocou bem poucas restrições: os testes deveriam ser total e intrinsecamente não-destrutivos, com seus efeitos transientes e reversíveis; e deveriam ser feitos em apenas em certas datas, em um janela de duas horas durante a madrugada em que, baseado na análise histórica dos logs, raramente havia alguém acessando o site. Nós deveríamos ligar para os operadores no início de cada teste e ao final faríamos uma conferência por telefone batendo o que estava previsto no cronograma com o que foi realmente feito e combinando as tarefas para o dia seguinte.

Outra característica incomum é que o escopo incluía o site de produção publicamente acessível na Internet – em geral, quando pedem esse tipo de coisa, os clientes usam sites internos de desenvolvimento ou homologação, o que tende a dar resultados míopes porque esses ambientes normalmente são bem diferentes do de produção. Não nesse caso; o cliente explicitamente queria resultados os mais próximos possíveis do "real", e por isso optaram por usar o site de produção.

Inundação UDP

A técnica da inundação usando pacotes UDP é facílima de explicar e de fazer. Ela nem sequer toca nos servidores que hospedam o site; o que ela faz é gerar um engarrafamento de propósito na conexão com a Internet do site-vítima. Por exemplo: quando você está baixando um arquivo muito grande, tudo mais que você estiver fazendo na Internet – navegação, MSN, etc., ficam lentos, não é? Isso ocorre porque você está próximo da velocidade máxima que sua conexão com a Internet é capaz de suportar.

Certa vez li em algum lugar (não lembro exatamente onde) uma tentativa de ser didático na hora de explicar ataques de inundação apelando para uma forçada de barra: é como uma greve de caminhoneiros. Eles estacionam seus caminhões no meio da pista, impedindo os outros de passar. A forçada de barra é que, na Internet, os pacotes (que seriam os "caminhões") nunca param, estão sempre em movimento. Eles são descartáveis: eles nascem no início da cada trecho da estrada (ao custo de alguns milésimos de centavo de energia elétrica) e são destruídos ao chegar no destino logo após entregarem sua carga. Na Internet, engarrafamentos – quando dois pacotes tentam passar ao mesmo tempo pela mesma estrada – são resolvidos "à moda do velho oeste": um deles é destruído, sem dó nem piedade.

Se você ficar gerando esses pacotes mais rápido do que eles são recebidos, o resultado será um acúmulo de pacotes pendentes (e muitos pacotes desintegrados porque não acham lugar pra entrar) que fará o acesso ao site ficar tão lento que os usuários acham que o site saiu do ar. Se fosse possível ver as linhas de comunicação como estradas e os pacotes como carros, eles se pareceriam vagamente com um daqueles engarrafamentos quilométricos que costumam assolar a cidade de São Paulo.

O script em Perl abaixo mostra como é espetacularmente simples gerar um programa de inundação:

#!/usr/bin/perl

use IO::Socket::INET;

my $host = shift or die 'no host';
my $port = shift or die 'no port';

my $sock = IO::Socket::INET->new(
     PeerAddr => $host,
     PeerPort => $port,
     Proto    => 'udp',
);

my $payload = "a" x 1400;
my $max = 100_000_000;
while ($max-->0) {
    $sock->datagram($payload);
    printf STDERR "%10d\r",$max if !($max % 10_000);
}

O programa acima aceita dois parâmetros na linha de comando: o primeiro especifica o endereço IP ou nome DNS do site; e o segundo dita a porta UDP de destino. Como de praxe toda vez que mostro código "perigoso", introduzi deliberadamente um bug que impedirá o programa de funcionar se copiado literalmente, para deter os sem-noção. Mas qualquer programador minimamente competente saberá consertá-lo.

Esse programa gera um comboio de cem milhões de pacotes UDP, cada um com 1400 bytes de tamanho (um pouco abaixo da MTU padrão das redes Ethernet, que é de 1500 bytes). Ou seja, é uma fábrica de pacotes ("caminhõezinhos") que rapidamente satura a capacidade máxima das linhas de comunicação ("estradas") entre a origem e o destino-vítima.

A limitação de cem milhões é para evitar tiros no próprio pé – às vezes, quando a gente roda esse programa em máquinas remotas via SSH, o fluxo é tão grande que atrapalha até nossa conexão SSH, tornando-a insuportavelmente lenta e, em casos extremos, fazendo com que a gente perca o controle da máquina. Se tivéssemos colocado um loop infinito, teríamos de mandar alguém parar o progrma ou reiniciar a máquina remota manualmente para podermos reaver controle dela. Com a limitação, se esse tipo de problema acontecer, pelo menos ele passa sozinho após algum tempo.

Esse tipo de ataque é como uma quebra de braço: vence o mais forte. Quando eu fui fazer o ensaio lá no cliente, a máquina de onde eu disparei a inundação tinha uma conexão de 100 megabits por segundo com a Internet. A conexão do cliente com a Internet era feita com através de uma linha que só suportava 4 megabits. Resultado: a conexão do cliente, mais fraca, de "apenas" 4 megabits1 não teve a menor chance contra o meu "tsunami" de 100 megabits.

Os operadores do site, que estavam na rede Interna da empresa, continuaram acessando o site normalmente. Praticamente todos os pacotes chegaram com sucesso ao destino e foram integralmente descartados pelo firewall de borda deles. Se ele conectasse no servidor web e pedisse uma listagem das conexões ativas usando o comando netstat -an, ele veria poucas conexões. O consumo de CPU estaria próximo de zero, com alguns pulinhos ocasionais para alguns porcento devido às atividades de rotina do sistema operacional. Por isso, eles ficariam com a falsa impressão de que nada está errado.

Mas os visitantes, por sua vez, não conseguiam chegar porque eu engarrafei a estrada que levava até eles, tal como fizeram os caminhoneiros. Do ponto de vista de um visitante externo, o site estava fora do ar.

Quando eu interrompi a execução do programa de inundação, em poucos segundos os meus milhões de pacotes em trânsito chegaram ao fim de suas efêmeras vidas de poucos milissegundos e tudo voltou ao normal: testando a partir do meu navegador, passei a conseguir acessar o site normalmente. Ou seja: o ataque é passageiro e não causa dano permanente.

Se eu tentasse fazer esse ataque a partir da conexão Internet da minha residência, que, na direção da Internet só dá 1 megabit por segundo, eu não conseguiria gerar tráfego suficiente para engarrafar a conexão deles, que é de 4 megabits por segundo. Ou seja, eu perderia a "queda de braço". Mas se eu e mais três colegas combinássemos de fazer isso ao mesmo tempo a partir de pontos de origem diferentes ao redor da Internet (de fato, fizemos essa experiência), a força combinada dos nossos pacotes tenderia a se somar e provavelmente conseguiria saturar a capacidade da conexão da vítima.

Saindo do âmbito do nosso cliente e comentando sobre os malfeitores virtuais: é exatamente isso que eles fazem. Eles usam as redes sociais para combinar vítima e momento do ataque e atiram todos juntos ao mesmo tempo – a mais pura arruaça virtual.

Esse tipo de ataque ilustra maravilhosamente bem as diferenças entre o mundo físico e o mundo virtual: no mundo físico, organizar um engarrafamento desses é caro – as pessoas ou levam seus caminhões, carros ou a si próprias, expondo-se a ações repressivas, perda de propriedade, risco de prisão, etc. E ainda assim acontece, haja vista as passeatas do MST e manifestações semelhantes. A diferença é a escala: a passeata mais bem sucedida que eu conheço – o Galo da Madrugada, aqui em Recife – reúne "apenas" 1,5 milhão de pessoas. No "mundo virtual" da Internet, com o programinha acima, geramos 100 milhões de pacotes muito mais rápido e facilmente do que os 1,5 de pessoas do Galo – e com exposição física quase zero, sem risco de cacetetes nem gás lacrimogênio.

Uma maneira de ganhar o "cabo de guerra" é comprar mais "muque" do seu provedor – digamos, uma "banda super-larga" de 1000 megabits. Mas se mil usuários de um megabit se juntarem contra você, você vai perder do mesmo jeito. Não dá pra comprar uma banda tão larga que resista ao resto da Internet inteira. Você pode até ser forte e ganhar muitas quedas de braço, mas isso não lhe garante que algum dia você não venha a encontrar alguém mais forte que você.

Inundação HTTP

A inundação HTTP consiste em simular uma enxurrada de usuários acessando o site ao mesmo tempo. Todo site, como toda loja ou agência bancária no mundo real, tem uma capacidade máxima de atendimento, não importa o quão bem equipado. Exceda essa capacidade e o serviço vai ficar lento ou até inviável pra todo mundo – como muito bem sabe quem sofre em fila de banco. O mesmo ocorre com qualquer web site: sobrecarregue-o de trabalho e ele não dará conta.

Deveria fazer parte do ciclo de desenvolvimento de qualquer site a realização de testes pra determinar que carga – normalmente medida na forma de "quantos atendimentos por segundo" – o site aguenta. É uma medida surpreendentemente complexa, que depende de diversos fatores. Por ser considerado um quesito "básico", que todo mundo deveria fazer (mas quase ninguém de fato faz), existem muitas ferramentas prontas pra ajudar a fazer esse teste de carga.

Uma das ferramentas padrão para isso é um programinha chamado ab, sigla de "Apache Benchmark", que já vem por padrão com instalações do Apache, o servidor web mais popular da Internet. Mas toda ferramenta benigna pode ser abusada; a diferença entre um teste de carga e um ataque de inundação está apenas na intenção.

Para saturar o site do nosso cliente, nossa primeira tentativa foi usando o seguinte comando (novamente a partir daquela máquina com 100Mbps de conexão para a Internet):

ab -r -k -n 100000 -c 250 \
    http://www.sitedocliente.com/pasta/busca.cgi?texto=algo

O parâmetro 250 após o -c indica a quantidade de conexões simultâneas sendo feitas para o site. A opção -k ativa o recurso de "keep-alive", permitindo que várias requisições HTTP possam ser enviadas uma após a outra em uma mesma conexão TCP; sem essa opção, só seria feita uma requisição por conexão, o que liberaria o servidor HTTP relativamente rápido para aceitar conexões de outras pessoas. Seria como se o caixa do banco só aceitasse que você fizesse uma única transação; se quisesse fazer outra, teria de entrar na fila de novo. Com a opção -k ativada, o programa ab monopoliza o servidor web por mais tempo.

Escolhemos a URL da funcionalidade de busca porque normalmente é uma das coisas que mais exige processamento em um site; servir páginas estáticas é muito "leve", normalmente requereria muito mais carga para saturar um site desse jeito.

Acessando o site do cliente pelo navegador a partir de outra máquina, pudemos constatar que esse ensaio deixou o site perceptivelmente lento, mas não o parou por completo. Experimentamos aumentar o "250" para "300", "400", etc. O efeito foi mais ou menos o mesmo: ficou lento, mas não parou.

A explicação é simples e ilustra muito bem a interação entre os vários fatores de rede e aplicação: simultaneamente, eu estava rodando um outro programinha que media a quantidade de bytes por segundo sendo emitida e o valor girava em torno de um pouco menos de 4 megabits/segundo. Ou seja, as centenas de requisições simultâneas estavam saturando a conexão da Internet do cliente, e não a capacidade de atendimento do servidor web.

Por que o ataque acima, que saturou o link2, não inviabilizou totalmente ao aceso ao site, ao passo que o ataque via UDP, que também saturou o link, inviabilizou? É porque o HTTP roda por sobre o TCP, e o TCP é um protocolo "bem educado": ele detecta a ocorrência de um congestionamento e desacelera, ajustando-se automaticamente à capacidade da conexão mais lenta no caminho entre a origem e o destino. Com isso, ele chega próximo de saturar o link, mas sempre sobra um pouquinho pelo qual ainda dá pra passar mais pacotes. O protocolo UDP não tem essa "boa educação": ele é indiferente à existência de um engarrafamento; ele sempre vai com força total.

Vale notar que a direção que saturou foi a do site para nós; de nós para o site, não havia engarrafamento, porque as requisições HTTP são pequenas. As respostas do site é que eram grandes: páginas longas, muitas figuras e animações em Flash, etc.

Em outras palavras: como o link saturou antes do servidor web, não estávamos realmente conseguindo atingir as 250 conexões simultâneas. O número "250" foi o que nós pedimos que o ab tentasse fazer, mas a saturação do link impediu que esse patamar fosse atingido. Se parássemos por aqui, teríamos chegado à conclusão errônea que não dá pra saturar esse site e que ele resiste a esse tipo particular de ataque.

Todavia, conseguimos saturar o site usando o seguinte comando:

ab -r -k -n 100000 -c 500 -H 'Accept-Encoding: gzip' \
     http://www.sitedocliente.com/pasta/busca.cgi?texto=algo

O "pulo do gato" aqui está na opção -H. Nós a usamos para acrescentar um cabeçalho HTTP chamado Accept-Encoding pedindo ao servidor que comprima as páginas usando o método gzip. Isso tem dois efeitos: primeiro, o servidor gasta mais esforço para comprimir as páginas antes de enviá-las; segundo, como as páginas comprimidas ficam bem menores, cabem muito mais delas nos 4 megabits. Com isso, conseguimos ir até além das 250 conexões simultâneas – por isso, mudamos o parâmetro -c para 500.

No frigir dos ovos, após esse singelo teste, o site capitulou – testando aqui do nosso navegador, o site parecia inacessível. O medidor de consumo de banda reportava 2,8 megabits por segundo em média – ou seja, ainda havia 1,2 megabits por seguindo sobrando. Por isso, pudemos afirmar que saturamos a capacidade do servidor e não da conexão à Internet.

Se o operador do site conectasse no servidor web e pedisse uma listagem das conexões TCP ativas usando o comando netstat -an, ele veria centenas de conexões ativas. Repetindo o comando, veria que elas mudam bem rapidamente. O consumo de CPU estaria elevado, talvez até saturado próximo de 100%, o que talvez lhes fizesse desconfiar de que um ataque estaria em andamento; ou talvez eles simplesmente achassem que houve um breve surto na popularidade do site.

Interrompendo a execução do programa ab, em poucos segundos as requisições se encerram e tudo volta à calma e normalidade. Tal como a inundação UDP descrita na seção anterior, este ataque não causa nenhum efeito permanente.

Slowloris: Abusando o Tempo de Expiração do Protocolo HTTP

O Slowloris é um programa cujo nome "homenageia" um bicho que vive na Ásia, de hábitos noturnos, movimentos lentos e deliberados e que tem uma mordida tóxica, coisa rara entre os mamíferos. A homenagem é apropriada: o programa Slowloris se aproveita de uma falha na implementação de certos servidores web para induzi-los a ficarem esperando muito tempo por requisições que nunca se completam, fazendo com que o site passe uma longa quantidade de tempo "de braços cruzados", sem fazer nada de útil – e sem atender os usuários legítimos.

Funciona assim: quando o servidor web aceita uma conexão TCP de um webserver, ele dá partida em um timer que regula a "paciência" que o servidor vai ter para esperar que o navegador transmita sua requisição. Se o navegador demorar demais para enviar alguma coisa, o timer dispara e o servidor aborta a conexão na marra, ficando livre para atender outra pessoa.

Essa "paciência" é implementada de diferentes maneiras em diferentes servidores. Várias versões do Apache (que era o servidor web usado pelo nosso cliente) têm um comportamento que nos permite abusar da paciência dele: a cada cabeçalho HTTP recebido, ele reinicia o timer. Tudo que o Slowloris tem de fazer é ficar mandando os cabeçalhos beeeeem devagar (digamos, um por minuto) sem jamais enviar a linha em branco que encerra a seção de cabeçalhos da resquisição HTTP. Assim, você prende a atenção de uma instância específica do servidor web por várias dezenas de minutos, e, às vezes, por horas a fio.

Fazendo uma analogia com agências bancárias, voltemos àquele cenário do office boy que monopoliza o caixa do banco. Agora imagine que o office boy seja muuuuito enrolado, fazendo tudo muuuuuuito devagar, tirando só um documento por vez da sua pastinha, cada um dele dentro de um monte de saquinhos, e todos aqueles comportamentos que enlouquecem os que estão esperando na fila. Pois bem, o Slowloris faz exatamente isso levado ao extremo. A diferença (que alguns chamariam de "fraqueza") é que o servidor web não perde a paciência.

Como se trata de um ataque lento, ele consome pouquíssima banda. No teste com o nosso cliente, rodamos o dito cujo assim:

perl slowloris.pl www.sitedocliente.com 80

O medidor de banda reportou uns 280 kilobits por seguindo nos primeiros quatro ou cinco segundos, depois passou alguns minutos em zero, depois outros poucos kilobits, depois mais alguns minutos em zero, e por aí vai. Claramente, não se trata de um ataque de inundação; muito pelo contrário: é um ataque lento, quase "gentil", como se você estivesse hipnotizando o servior web. Por isso, pode ser feito com sucesso até por usuários que estiverem conectados via modem analógico em linha telefônica convencional de aúdio.

Se o operador do site conectasse no servidor web e pedisse uma listagem das conexões TCP ativas usando o comando netstat -an, ele veria centenas de conexões ativas, quase todas ociosas, e que mudariam muito devagar. O consumo de CPU seria baixo, próximo do 0%, com alguns pulinhos ocasionais para alguns porcento. É bem possível que eles vissem isso e achassem que não havia nada de errado.

Interrompendo a execução do Slowloris faz com que as conexões penduradas sejam gradualmente liberadas. Assim, em questão de minutos, tudo volta ao normal, sem nenhum efeito permanente.

Os servidores web poderiam evitar esse ataque de uma maneira óbvia: limitar o tempo máximo para que uma transação se complete, abortando-a no meio se isso acontecer. Mas muitos, e o Apache em particular, não implementam esse tipo de limitação porque ela tende a causar efeitos colaterais indesejados: por exemplo, o servidor pode ficar incapaz de processar requisições de usuários legítimos que estiverem vindo de lugares do mundo com conexões lentas.

Comentários Finais

Apesar da dinâmica exata dos ataques de negação de serviço ser bastante complexa em termos da interação entre os pacotes que transitam na rede, o comportamento dos protocolos, a implementação do servidor web e das aplicações que compõem os websites, a execução prática desses ataques é de uma eficácia nefasta e simplicidade chocante – muita gente fica surpresa ao descobrir como é fácil levar esses ataques a cabo.

Nos exemplo acima, não fizemos nenhum esforço para sermos sorrateiros: o endereço IP de origem dos nossos pacotes e conexões prontamente apareceu nos logs do servidor web do nosso cliente. Se estivéssemos fazendo isso sem a anuência do cliente, essa pista permitira que nós fôssemos prontamente rastreados e poderíamos ser pegos. Todavia, há algumas técnicas que permitiriam disfarçar esses IPs, pelo menos no caso do Slowloris – poderíamos passar as conexões HTTP pelo Tor ou via uma rede de túneis SSH, como eu mostrei em uma série de artigos anteriores.

A equipe técnica do nosso cliente não ficou surpresa com os resultados; eles já imaginavam que seria isso mesmo. Já a gerência ficou meio assustada. O objetivo dos técnicos era esse mesmo: deixar a gerência bem a par das vulnerabilidades a que estavam sujeitos. Em um post futuro, vou falar sobre as técnicas que propusemos para eles que podem ser usadas para incrementar a resistência a ataques desse tipo.



1 Uma conexão simétrica de 4 megabits é considerada bem boazinha aqui no Brasil e bem mais do que o suficiente para as necessidades estritamente funcionais do site do nosso cliente [ voltar ]

2 Nesse contexto, "link" significa "conexão com a Internet" e não um lugar onde você clica no navegador para ir para outra página [ voltar ]

Comentários
Aceita-se formatação à la TWiki. HTML e scripts são filtrados. Máximo 15KiB.

 
Enviando... por favor aguarde...
Comentário enviado com suceso -- obrigado.
Ele aparecerá quando os moderadores o aprovarem.
Houve uma falha no envio do formulário!
Deixei uma nota para os admins verificarem o problema.
Perdoe-nos o transtorno. Por favor tente novamente mais tarde.
Urlan | 2011-10-12 19:24:00 | permalink | topo

Prezados,

Vocês não acham que também seria interessante demonstrar o impacto que os ataques causaram à rede por meio de métricas e ilustrar empregando gráficos?

Creio que isso o deixaria o post mais científico e, digamos, analisável. =)

Felipe Bagetti | 2011-08-31 20:06:44 | permalink | topo

Obs. Tava relendo o comentário e vi que escrevi CEO, mas na verdade queria me referir a gerência da empresa, no caso, a equipe responsável por contratar ou não um serviço como esse.

Felipe Bagetti | 2011-07-27 03:22:11 | permalink | topo

Eu achei o texto razoavelmente grande, em parte, devido as diversas analogias. Sei que são importantes para um público leigo no assunto entender o texto.

Entretanto, isso torna o texto um pouco cansativo e demorado, principalmente para quem tem algum conhecimento sobre o assunto. Digo isso em relação a conhecimentos básicos na área de computação (por ex. o funcionamento dos protocolos TCP/UDP), até porque não tenho muito conhecimento em segurança computacional.

Mas como eu disse, depende do público a ser atingido. Será que o CEO dessa empresa leria esse post? E se lesse será que entenderia o funcionamento dos testes e do ataque DDOS? Dependendo das respostas, talvez um post tão "mastigado" seja desnecessário.

Esse foi o primeiro post que li aqui, gostei bastante e estou lendo outros. Se essa foi ou não a melhor abordagem, foi boa o suficiente para ganhar um leitor.

Parabéns pelo blog e pelo trabalho realizado ;)

Marco Carnut | 2011-07-24 10:48:55 | permalink | topo

Olá Felipe,

Obrigado pelos comentários.

Você poderia ser mais específico quanto ao "foco mais na parte técnica" você gostaria de ter visto? Talvez eu possa abordá-lo em um futuro artigo que estou preparando.

-K.

Felipe Bagetti | 2011-07-23 19:29:40 | permalink | topo

"Saindo do âmbito do nosso cliente e comentando sobre os malfeitores virtuais: é exatamente isso que eles fazem. Eles usam as redes sociais para combinar vítima e momento do ataque e atiram todos juntos ao mesmo tempo – a mais pura arruaça virtual." - Post

Acho que faltou falar que são usados zombies nos ataques, o que torna o ataque muito mais poderoso.

"Em um ataque distribuído de negação de serviço, um computador mestre (denominado "Master") pode ter sob seu comando até milhares de computadores ("Zombies" - zumbis). Neste caso, as tarefas de ataque de negação de serviço são distribuídas a um "exército" de máquinas escravizadas." - Wikipedia

Gostei do post. Bem escrito e explicado, acho que poderia ter focado mais na parte técnica, mas isso depende do público desejado.

Ricardo Ulisses | 2011-06-25 00:40:28 | permalink | topo

Kiko,

Embora você tenha deixado bem claro que o objetivo do artigo não era analisar os ataques de negação de serviço recentes, o timing da publicação deste post não poderia ter sido melhor.

Apesar do teor mais técnico de alguns trechos, acho que o artigo cumpre o papel de tornar menos obscura essa classe de ataques para o público não técnico; em especial, acho que deveria ser lido por todo jornalista que cobre notícias de informática/Internet.

Aos leitores técnicos, muito interessante sua exposição sobre os detalhes dos testes, como os cuidados tomados para evitar uma interpretação equivocada dos mesmos e o comportamento insidioso do slowloris.