Como o WordPress pode ajudar no overload de um servidor

Como dono do Tugaleaks tenho um objetivo: garantir a segurança do meu servidor. Constantemente recebo ataques e tenho IPs bloqueados. mod_security, mod_noloris, mod_reqtimeout e outros são ferramentas do dia-a-dia que ao não usar, deixava todos os meus negócios estancados, dada a complexidade e notoriedade que este e outros sites têm.

Lembra-te que se ainda não tens o teu e desejas criar o teu blog, não percas o Tutorial da Hostinger.

O problema

Há cerca de três semanas vi um ataque bastante bom e rápido: o meu servidor com loads de 30 e memória a 100% em menos de 20 segundos. Obviamente que fiquei em pânico e pus-me logo de htop aberto a vasculhar a coisa. Nada. Nadinha de nada. Achei grave, tendo em conta que o htop, para quem não conhece, detalha muito melhor que o comando top. Decidi então investigar os logs.
Os logs eram compostos por pedidos HEAD a um site com o URL a terminar em /?s=#### onde #### ernm palavras random. E depressa cheguei ao WordPress como o causador do problema. Atenção que para já indico não ser um problema totalmente ligado ao WordPress mas bastante facilitado pelo WordPress, uma vez que podemos fazer pesquisas diretas usando o url /?s=termodepesquisa. Por exemplo uma pesquisa de canalmail neste site com link direto vai retornar imediatamente as pesquisas.
E neste campo os plugins de cache também não ajudam pois é algo que também é impossível de travar com pesquisas ao calhas. Então, tinha o servidor há meia hora sob ataque e não sabia como parar.

As experiências

Pensei ser do problema do ficheiro.php.kkk onde o kkk é uma extensão não reconhecida que é executado indevidamente no Apache com as configurações defaut (mais info aqui) e logo pensei ser problema do mod_noloris mal configurado.
Nada disso era. Recompilei o apache e já lá iam 50 minutos.
Entretanto alguém num canal da AnonOps (rede Internacional dos Anonymous) deu-me a dica do exploit  CVE-2011-3192 mas não fazia sentido porque tinha feito update do Apache mesmo há minutos e os logs não eram “iguais” aos que daquele exploit produzia.
Até que passado uma hora, finalmente encontrei o bichinho. Chama-se keep alive dos script e foi criado por alguém que depois de conhecer comecei a idolaterar. Scripts para forçar SEO, scripts bastantes interessantes e este keep alive é o culminar de uma awesomeness enorme deste senhor.
O engraçado é o nome, pois keep alive supostamente refere-se ao KeepAlive On/Off do httpd.conf (ficheiro de configurações do Apache) e mesmo com isso Off o problema continua.

A solução

Tentei mitigar com PHP Caching e EAccelerator e nada. Entretanto andava a bloquear os IPs todos à mão, e dei mais de 100 blocks numa noite apenas.
Já em contacto com a cPanel team e escalado em menos de 5 horas para os devolopers tirei a ideia que o melhor era bloquear com uma regra de mod_security. E foi o que fiz.

A regra… pois, essa é a parte que vem a seguir.

O WordPress ajudou a criar problemas

Se há coisa que não gosto no WordPress é o registo de utilizadores e agora a pesquisa. Não encontrei addons para limitar pesquisas, ou poupar de alguma forma recursos de pesquisa em MySQL.
Por exemplo no SMF a pesquisa pode ser limitada e aí o PHP Caching já ajuda imenso e resolve o problema sem ser preciso mais nada.
Mas o WordPress com a sua pesquisa básica (bastante básica) cria um imenso problema.
Ora, para quem sabe eu vou estar presente este sábado no WordCamp, e pretendo expor a quem quiser ouvir (ou naquelas coisas que dizem ter experts do WordPress) este problema.

A regra de ouro para parar este ataque

É simples: com mod_security fazer um block com REQUEST_METHOD, gravar dados num ficheiro, ver se o HEAD count é X em X segundos e usar a lfd para dar block temporário ou definitivo ao IP atacante. E tudo isto, em menos de 1 segundo.
No Domingo após falar com o pessoal do WordPress vou colocar aqui no blog esta regra. No entanto, e antes que comecem a criticar, este não é uma tentativa de hacking geral ou de lançar o pânico na Web Portuguesa (como se fosse eu a fazer isso). É apenas um teste e um problema real com que me deparei. E desta forma, estou a ajudar outros a preveni-lo.
E por não ser uma tentativa de lançar o pânico, a regra vai estar disponível para os ISPs, SPs e donos de servidores através do meu e-mail mail@ruicruz.pt para que não sejam afetados. Basta pedir. No entanto, não a divulgo para ver o que “acontece” no WordCamp.
E faço isto, com consciência, porque sei que o WordPress pode melhorar. Mas como decidiram ignorar (ou pelo menos a não responder) a mensagem que enviei para o security@wordpress.org, aqui fica o meu “agradecimento”.

WordPress, eu amo-te. Mas tu deste-me hora e meia de serviços web offline e muitas mais horas de dor de cabeça. Ainda assim, é o meu CMS preferido.

Rui