Início » Internet » O maior ataque DDoS já registrado teve como alvo o GitHub

O maior ataque DDoS já registrado teve como alvo o GitHub

1,3 Tb/s de tráfego sem usar botnet

Felipe Ventura Por

O GitHub é a maior plataforma de hospedagem de código-fonte no mundo. Trata-se de um recurso essencial para milhões de programadores, permitindo colaborar em projetos privados ou de código aberto.

Nesta quarta-feira (28), o GitHub passou pelo maior ataque DDoS já registrado. Foi 1,35 terabit por segundo de tráfego usando um método que não requer botnet.

Foto por Jun OHWADA/Flickr

Os motivos do ataque ainda são desconhecidos. Depois da primeira onda de 1,3 Tb/s, que derrubou o site por apenas seis minutos, veio uma segunda onda de 400 Gb/s. A Akamai protegeu o site, encaminhando o tráfego para centros de depuração.

Até então, o maior ataque DDoS havia sido registrado em 2016. A Dyn, uma das principais fornecedoras de serviços de DNS, teve que lidar com picos de 1,2 Tb/s. Isso causou instabilidade em diversos serviços na época, incluindo Twitter, Spotify e SoundCloud. O estrago foi causado por uma botnet feita para derrubar servidores de Minecraft.

O GitHub também já teve que lidar com ataques DDoS massivos. Em 2015, a plataforma enfrentou uma enxurrada de tráfego durante seis dias seguidos.

Acredita-se que hackers da China estavam por trás disso. Devido a um código malicioso, milhões de chineses carregavam sem saber o repositório do GreatFire.org, para combate à censura; e o repositório da edição em mandarim do New York Times.

Isso é um problema, já que o GitHub é vital para muitos desenvolvedores. Ele tem 20 milhões de usuários e 57 milhões de repositórios. Como aponta Matteo Gavagnin no Twitter, ele hospeda repositórios dos quais dependem a maioria dos gerenciadores de pacotes ou de dependências — como npm, bower, yarn, gems e cocoapods.

O maior ataque

Como ocorreu o ataque mais recente ao GitHub? Primeiro, é preciso conhecer o memcached: trata-se de um sistema distribuído de cache usado por servidores para acelerar redes e sites. Ele é feito apenas para computadores que não estão expostos à internet, porque não exige autenticação.

No entanto, existem atualmente mais de 50 mil servidores vulneráveis na internet, segundo a Akamai. O problema é que, da forma que o memcached funciona, ele pode ser usado para ataques DDoS.

“15 bytes de solicitação podem desencadear uma resposta de 134 KB enviada para o alvo. Este é um fator de ampliação de 10 mil vezes! Na prática, vimos uma solicitação de 15 bytes resultar em uma resposta de 750 KB (é uma amplificação de 51.200x)”, explica a Cloudflare.

Ataque DDoS ao GitHub

Isso acontece porque, quando um sistema com o memcached recebe uma solicitação “get”, ele coleta os valores solicitados da memória e envia tudo em um fluxo ininterrupto.

Um hacker pode, então, invadir um servidor exposto e colocar um arquivo grande, para depois solicitá-lo com o comando “get”. O destino será o endereço IP do alvo, que receberá uma quantidade absurda de tráfego.

Faça isso com vários servidores, e você tem um ataque distribuído de negação de serviço, ou DDoS. É o que ocorreu com o GitHub.

Com informações: Wired, ZDNet.

Comentários

Envie uma pergunta

Os mais notáveis

Comentários com a maior pontuação

Samuel Meireles

MUITO OBRIGADO POR ENSINAR COMO REALIZAR O ATAQUE DDOS USANDO MEMCACHED.

frekele

Impressionante a força deste ataque, para fazer isso não é simples, deve-se ter sido muito bem planejado e para suportar um ataque desses somente o GitHub mesmo para aguentar esse tempo, pois muito site por ai não iria aguentar tanto.
Pelo que eu sei o GitHub aplica todas as top 10 regras de segurança recomendadas pela OWASP.

TLDR:

Fora o básico do DDoS, se você der uma olhada em muitos sites importantes por ai e fizer umas chamadas de rede você vê que o CSP(Content Security Policy) no header não são nem informados "como o site do tecnoblog :)" já no github são muito bem definidos, o que é ótimo para proteger contra ataque XSS, outro detalhe é o uso HSTS Preload não vejo nenhum site aqui no brasil usando e é super fácil implementar isso, o próprio site (hstspreload org) dá instruções para fazer isso.

O ponto mais importante, conforme a akamai disse existem mais de 50mil servidores vulnerareis na internet, 'acho que ela quis dizer sobre servidores DNS', acredito que seja os servidores que não implementam DNSSEC, se falarmos em DNSSEC aqui no brasil não tem quase nenhum site usando o que permite um ataque 'man in middle' facilmente(mesmo o registro br disponibilizando essa opção).

Acho que o pessoal tem que começar a olhar mais para isso e uma NOTÍCIA como essa vai ajuda a trazer mais a atenção dos desenvolvedores para a segurança.

Um excelente site que recomendo para testar se você está implementando todas as regras necessárias(não inclui DDoS) é o (observatory mozilla org).

Para verificação do DNSSEC tem vários, um que eu recomendo é o ( dnssec debugger verisignlabs com) da verisign.

Para a proteção DDoS fora o uso de uma CDN( que amortece o impacto no teu servidor), o recomendável é você fazer uma implementação de um proxy reativo, por exemplo criar regras caso um determinado IP faça mais de 20mil chamadas em 5 minutos você coloca ele numa blacklist do teu firewall e libera somente depois de 1 dia por exemplo.
Também é importante adicionar ao seu firewall uma blacklist já pre-definida dos principais IPs perigosos, por exemplo os IPs que são de usuários da rede TOR.

Aqui uma lista de sites onde você pode encontrar os ips, e você deve criar uma rotina que constantemente olha para eles e atualiza as regras do seu firewall.
(spamhaus org)
(rules emergingthreats net)
(check torproject org - exit addresses)
OBS: Porem isso funciona bem para IPV4 já para IPV6 é praticamente inviável, pois a quantidade IPV6 que podem existir é imensa.

Outro ponto é caso o teu site seja somente para acesso de usuários no Brasil, por exemplo uma loja virtual que vende produtos somente aqui no BR, não faz sentido liberar o acesso a usuários de outro pais como do Japão, China, Russia etc. então fazer uma restrição de Geo-localização ajuda muito também.

Também é importante usar o SRI(Subresource Integrity), o SRI é uma funcionalidade nova nos navegadores e pouca gente conhece.
Imagine que a tua CND, seja comprometida e um hacker altera um javascript na CDN, então os usuários que carregarem a url vão estar comprometidos, por isso o SRI é importante, você simplesmente adiciona um hash (sha256, sha384 ou sha512) junto a tag e quando o navegador carregar o arquivo ele vai fazer uma verificação de integridade e ver se não foi alterado, caso tenha sido ele bloqueia o processamento.

Fica a dica. :) .

frekele

Impressionante a força deste ataque, para fazer isso não é simples, deve-se ter sido muito bem planejado e para suportar um ataque desses somente o GitHub mesmo para aguentar esse tempo, pois muito site por ai não iria aguentar tanto.
Pelo que eu sei o GitHub aplica todas as top 10 regras de segurança recomendadas pela OWASP.

TLDR:

Fora o básico do DDoS, se você der uma olhada em muitos sites importantes por ai e fizer umas chamadas de rede você vê que o CSP(Content Security Policy) no header não são nem informados "como o site do tecnoblog :)" já no github são muito bem definidos, o que é ótimo para proteger contra ataque XSS, outro detalhe é o uso HSTS Preload não vejo nenhum site aqui no brasil usando e é super fácil implementar isso, o próprio site (hstspreload org) dá instruções para fazer isso.

O ponto mais importante, conforme a akamai disse existem mais de 50mil servidores vulnerareis na internet, 'acho que ela quis dizer sobre servidores DNS', acredito que seja os servidores que não implementam DNSSEC, se falarmos em DNSSEC aqui no brasil não tem quase nenhum site usando o que permite um ataque 'man in middle' facilmente(mesmo o registro br disponibilizando essa opção).

Acho que o pessoal tem que começar a olhar mais para isso e uma NOTÍCIA como essa vai ajuda a trazer mais a atenção dos desenvolvedores para a segurança.

Um excelente site que recomendo para testar se você está implementando todas as regras necessárias(não inclui DDoS) é o (observatory mozilla org).

Para verificação do DNSSEC tem vários, um que eu recomendo é o ( dnssec debugger verisignlabs com) da verisign.

Para a proteção DDoS fora o uso de uma CDN( que amortece o impacto no teu servidor), o recomendável é você fazer uma implementação de um proxy reativo, por exemplo criar regras caso um determinado IP faça mais de 20mil chamadas em 5 minutos você coloca ele numa blacklist do teu firewall e libera somente depois de 1 dia por exemplo.
Também é importante adicionar ao seu firewall uma blacklist já pre-definida dos principais IPs perigosos, por exemplo os IPs que são de usuários da rede TOR.

Aqui uma lista de sites onde você pode encontrar os ips, e você deve criar uma rotina que constantemente olha para eles e atualiza as regras do seu firewall.
(spamhaus org)
(rules emergingthreats net)
(check torproject org - exit addresses)
OBS: Porem isso funciona bem para IPV4 já para IPV6 é praticamente inviável, pois a quantidade IPV6 que podem existir é imensa.

Outro ponto é caso o teu site seja somente para acesso de usuários no Brasil, por exemplo uma loja virtual que vende produtos somente aqui no BR, não faz sentido liberar o acesso a usuários de outro pais como do Japão, China, Russia etc. então fazer uma restrição de Geo-localização ajuda muito também.

Também é importante usar o SRI(Subresource Integrity), o SRI é uma funcionalidade nova nos navegadores e pouca gente conhece.
Imagine que a tua CND, seja comprometida e um hacker altera um javascript na CDN, então os usuários que carregarem a url vão estar comprometidos, por isso o SRI é importante, você simplesmente adiciona um hash (sha256, sha384 ou sha512) junto a tag e quando o navegador carregar o arquivo ele vai fazer uma verificação de integridade e ver se não foi alterado, caso tenha sido ele bloqueia o processamento.

Fica a dica. :)

Tori

Tinha ate esquecido desse gordo

ʞǝʌǝɥs

não o gordinho da CN não ?

/s

Uriel Dos Santos Souza

Usei muito o memcached. Muito bom e rápido. Usei quando o Varnish não funcionava bem com SSL. E o memcached funcionava perfeito.

Já faz algum tempo que não mexo no memcached

Programador Front-End

Aqui morreu também... Mas ja voltou

Diego Rocha

Hoje parece que está acontecendo com o bitbucket hahahaha pelo menos ele está completamente fora aqui pra mim, site e ssh

Diego Rocha

Dá pra dizer que "invadiu", pq se esse memcached tem dados sigilosos eles podem ter sido coletados

Aurélio Carlos

"Um hacker pode, então, invadir um servidor exposto e colocar um arquivo grande, para depois solicitá-lo com o comando “get”. O destino será o endereço IP do alvo, que receberá uma quantidade absurda de tráfego."

Não foi preciso invadir, fizeram requisições para servidores que tinham o serviço memcached respondendo não apenas localmente e sim externamente, que era o padrão em várias instalações de outros serviços.

Tori

China e Russia ultimamente querem ficar brincando de "Temos o melhor DDoS/Vírus/Spyware" na internet.
Poarr, que bagulho chato, depois dá bosta, vai falar "M-Muh estávamos testando nossos desenvolvedores, não sabíamos (sabiam) que iria dar bosta"