Há algumas horas, rolou o post sobre o ataque que está sendo planejado e executado contra o G1.

Demos os nomes aos bois, ou melhor, à galera que o está executando e até dissemos como ter um pouco de sucesso quanto a ele.

Acontece que um tal de Thorhundred sec diz ter executado um ataque DoS/DDoS junto ao blog. tsc tsc tsc.. Brincadeira de criança né…

O cara tinha até vindo falar comigo, via face, mas depois, fez como qualquer criança de 12 anos, me bloqueou. Tsc tsc tsc pela segunda vez.

Nem passou pela cabeça do mega ultra blaster hacker da porra que não possuo algum perfil fake no face para saber quem ele é ? E o pior, ele nem em modo privado ou só para amigo deixa os seus posts.

Captura de Tela 2014-03-03 às 4.18.44 PM Captura de Tela 2014-03-03 às 4.18.10 PM

Criança. 😉

Quem acompanha o blog sabe que a KingHost, empresa a qual cuida da hospedagem do blog, não possui uma infra muito boa para segurar ataques DDoS/DoS. Eles são bem reativos, para dizer a verdade.

Regras em firewall e roteadores só são criados depois que o ataque já começou ou prior, quando abro um chamado reclamando que o blog está fora.

Mas parece que desta vez, eles conseguiram criar um regrinha e bloquearam o ataque (juro que tenha esperanças que tenha sido isso que tenha ocorrido).

Daí, eu passei a ajudar a KingHost, colocando uma nova camada de proteção, física mesmo, junto ao blog.

Acontece que o pessoal de casa precisa esperar o refresh das entradas de dns que apontam para o blog.corujadeti.com.br para o que eu fiz surta efeito. Isso levará umas 24 horas.

Porém, Dr. mega ultra blaster hacker Thorhundred sec, que tal vc dar um refresh no seu cache de DNS  (procura como faz isso na google para windows XP) e envia um ataque novamente. Vamos ver se o que eu fiz, de fato, funcionou, caso contrário, precisarei voltar para prancheta.

P.S.: As parametrizações que foram executadas para bloquear os ataques que o blog vem sofrendo, caso funcionem, serão apresentadas, em detalhes, na versão 2.0 do curso de varnish+nginx+apache, o qual será lançado até o final desta semana.

Já adianto que foi bem diferente do que fiz para ajudar o pessoal do Sedentario.org e de tantos outros blogs que sofreram com ataques DDoS nas últimas semanas.

Uma pequena consideração e é referente ao PHP5-FPM – acho que terei que alterar mais algumas coisas ele, mas preciso ver como ficará o tráfego direcionado para o site depois destas últimas alterações.

Atualização 1: O servidor que foi adicionado a infra do Coruja de TI possui 4 CPUs. Mas neste momento, o load da máquina está em 0.22. Baixíssimo, já que deveríamos nos preocupar caso o mesmo estivesse em 4.01.

Atualização 2: Por enquanto, a alteração que fiz surtiu efeito. Digo isso, pois graças a ela, eu consegui duas coisas importantes:

  • Logs detalhados dos métodos HTTP e ips que o blog recebe
  • Dois ataques foram deferidos contra o blog e não surtiram efeito, já que tomaram http request 200

 Atualização 3: Acabamos de sofrer outro ataque, mas desta vez os logs do primeiro servidor demonstraram a origem – 108.60.134.238 e o método que foi utilizado – um simples POST – que infelizmente não pode ser tratado facilmente pelo Varnish, mas sim com a criação de uma regra no iptables –  iptables -A INPUT -s 108.60.134.238 -j DROP

O engraçado é que testei, via t50, o mesmo ataque, e funcionou. Motivo “A infra da kinghost é uma bosta”.

Um simples php5-fpm, bem configurado, poderia bloquear este tipo de ataque. Até mesmo o fail2ban. Mas como não tenho acesso a minha hospedagem, eu devo montar um proxy para tratar tudo isso, é o jeito.

Atualização 4: Fail2ban configurado no frontend e os ataques estão sendo bloqueados. Acontece que ele está analisando os logs w3c gerados pelo varnish, via o seguinte comando –   /usr/bin/varnishncsa -a -w /var/log/varnish/varnishncsa.log -D -P /var/run/varnishncsa.pid

Fui obrigado a mudar o regex do fail2ban, dentro do diretório de filtros, para a seguinte sintaxe failregex = ^<HOST>.*”GET –

Rodei o comando fail2ban-regex /var/log/varnish/varnishncsa.log http-get-dos.conf para saber se o regex funciona.

Veio uma lista de ips. Pronto, isso prova que o Regex funciona.

Feito isso, a segunda parte foi criar a regra, na verdade, o jail, que ficou da seguinte forma:

[http-get-dos]
enabled = true
port = http,https
filter = http-get-dos
logpath = /var/log/varnish/varnishncsa.log
maxretry = 600 ##os valores aqui estão diferentes para  o meu ambiente
findtime = 60 ##os valores aqui estão diferentes para  o meu ambiente
#ban for 25 hours
bantime = 600
action = iptables[name=HTTP, port=http, protocol=tcp]

//* peguei algumas configurações deste guia

Problemas: O fail2ban analisa todo o conteúdo dos arquivos de log que vc configura para ele monitorar. Sendo assim, se vc colocar um arquivo de 2GB para ser monitorado, o fail2ban utilizará muita cpu para o parsing.

Por este motivo que configurar, e de forma adequada, o logrotate em seu ambiente é primordial. Assim vc deixa utilizar muita CPU.

Depois de configurado o fail2ban, é bom vc verificar como está a utilização de CPU da sua máquina, assim como executar um teste, com o ab -n 1000 -c 100 http://blog.corujadeti.com.br/

Caso o fail2ban esteja funcionando, vc verá a seguinte mensagem abaixo no tail -f /var/log/fail2ban.log

WARNING [http-get-dos] Ban <SEUIP>

Já testei outros 6 ataques, a partir de ips diferentes e a configuração acima funcionou. A reconfiguração do meu logrotate fez que o load do servidor cai-se de 4.32 para 0.20, tudo por causa do parsing dos .out e .logs realizado pelo fail2bain.

Vamos aguardar..