18/02/2016 → Guxta → Comentários: 6
Na madrugada de hoje, um bando de desempregados ou um desempregado, executou um ataque DDoS contra o blog utilizando o WordPress’s “pingback”, uma vulnerabilidade mais do que conhecida no mercado.
O fato é que o blog foi afetado pelos seguintes motivos:
1 – o bypass do sucuri ainda era possível de ser explorado – pegar o ip real e depois ataca-lo diretamente
2 – a digitalocean, o provedor que utilizado para hospedar a vm do coruja de ti, possui um limitador de tráfego, cerca de 200mbps. Acima disso, eles bloqueiam todo o tráfego para a sua vm. Vejam no gráfico abaixo:
Como bloquear o ataque ?
Existe uma série de formas de você fazer isso, da mais fácil até a mais difícil.
Vamos lá..
Tendo em mãos o log do seu varnish, já que ele que está respondendo por todo o tráfego http do seu site, vc pode começar a criar regras para bloquear os user agents indesejados:
[18/Feb/2016:01:04:22 -0200] “GET http://162.243.120.22/ HTTP/1.0” 200 75953 “-” “WordPress/4.3;
A regra, para a versão 3.2, é a seguinte:
Abaixo da rotina subl_recv, adicionar a regra:
if (
req.http.user-agent ~ “WordPress”
) {
error 403 “You are banned from this site. Please contact via a different client configuration if you believe that this is a mistake.”;
}
Salvar e compilar.
Para testar se a sua regra está funcionando, basta executar o seguinte comando abaixo:
curl -A “WordPress/4.3″ http://ipdo server
Essa será a resposta para a sua requisição:
<?xml version=”1.0″ encoding=”utf-8”?>
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html>
<head>
<title>403 You are banned from this site. Traduzindo, pq sei o quanto vc �77777703 burro – seu ataque foi bloqueado.</title>
</head>
<body>
<h1>Error 403 You are banned from this site. Traduzindo, pq sei o quanto vc �77777703 burro – seu ataque foi bloqueado.</h1>
<p>You are banned from this site. Traduzindo, pq sei o quanto vc �77777703 burro – seu ataque foi bloqueado.</p>
<h3>Guru Meditation:</h3>
<p>XID: 1111026768</p>
<hr>
<p>Varnish cache server</p>
</body>
</html>
Problema:
De qualquer forma, o seu varnish continuará consumindo recursos, sejam eles memória e cpu, já que todas as requisições serão respondidas.
No meu caso, mesmo sem essa regra, o ataque consumiu 30% de cpu da minha máquina. Nada mal para dizer a verdade.
Os meus cálculos apontam que um ataque de 300mbps – inbound – seria o suficiente para consumir toda a cpu da máquina – muito para quem está desempregado, não é mesmo ?! heheh
Com a regra acima fosse implementada, a minha capacidade de suporte ao ataque passaria de 300 mbps para 1.5 gbps, isso contando com toda a cpu e memória que tenho disponível na máquina.
A outra forma que teria para mitigar um ataque deste tamanho, sem que os recursos da máquina fossem exauridos, é a utilização do iptables. Para isso, dois scripts básicos teriam que ser criados.
1 – a execução de um parsing nos logs do varnish buscando pelo user agent WordPress, como demonstrado abaixo:
cat /var/log/varnish/varnish.log | grep “verifying pingback from” >> lista.log
2 – a criação de um script php que realize o parsing para geração das regras do iptables
Nota: No momento que estava escrevendo o script, eu o encontrei no seguinte endereço. Ele é básico, precisa melhora-lo, principalmente no que tange a adição de novas regras, mas atende a principal necessidade, que é o bloqueio dos ips.
Vejam que o script php já cria as regras de DROP para os ips que foram listados no arquivo.log. 🙂
Assim que as regras forem implementadas, vocês verão os recursos utilizados pela máquina cairem. Bacana.
Mas e o ataque continuará ? Sim, eles, os desempregados, ainda possuem o ip do server, só que não conseguirão estabelecer uma conexão tcp/ip.
A pergunta que fica é “digitalocean, o que vc faz nesta situação de tráfego alto? Bloqueia ou deixa o server resolver ?”
Ainda há outras alternativas, quanto a segurança, que podem ser implementadas ?
Sim, há.
A criação de regras mais específicas no iptables para suportar o tráfego http, o que já foi feito.
Agora é só esperar o próximo ataque e ver se eles entenderão a surpresa que foi preparada. Eu acho difícil disso acontecer, mas temos que ter esperanças com os menos favorecidos, não é mesmo ?
Conclusão:
O Varnish é uma baita solução de cache, auxiliando, e muito, no que diz respeito ao suporte de conteúdo estático, mas ele não faz milagre. Além dele bem configurado, vc precisa do iptables sendo munido de informações para bloquear os desempregados.
Atualização:
Resolvi alterar algumas configurações e até a arquitetura, isso pq o stag fez uma aposta comigo. Vamos ver quem ganhará..
Desempregados, por favor, ajudem aê e ataquem os site..
NoRm4nD
Seu servidor estaria fora pelo simples fato de a quantidade de recursos que exigiria do kernel para manter as conexões anteriormente abertas pelo DDoS ativas.
O modo mais adequado de lidar com isso sem ser por blackrole é através do modulo no caso do linux “ng_string” com a ação reset, isso evitaria do kernel manter alocado recursos de socket de conexão, resetando já no inicio da conexão.
Tiago
Olá Gustavo,
muito interessante o seu post. Uma duvida, talvez primaria, mas prefiro perguntar do que morrer sem entender.
Hoje o “Sucuri” responde ao acesso do seu site ou filtra o que indesejado/invalido/malicioso encaminhando os pacotes valido para seu server?
Gustavo Lima
Opa, obrigado pela dica, mas não conheço o ng_string. Vc tem como me passar mais detalhes ?
Eduardo
NoRm4nD, vc se refere ao módulo ipt_string do iptables ?
Rafael
Olá, Gustavo,
Parabéns pelos excelentes posts.
Com relação aos ataques ddos, o pessoal da minha empresa está querendo contratar um serviço para testar nssa resistência (e a do provedor) a esses ataques. Você sabe onde podemos contratar esses serviços? Conheçe algum específico?
Gustavo Lima
Loadimpact ou https://loader.io/ – excelentes empresas..