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:

 

Screen Shot 2016-02-18 at 7.24.50 AM

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..