WordPress proteger BruteForce

De vez em quando gosto de dar uma vista de olhos nos logs do servidor para ver se deteto algo “anormal”, uma das coisas que me saltou à vista já há algum tempo foi o número exagerado de tentativas de autenticação inválidas! Estas tentativas tinham várias origens mas o método é sempre o mesmo tentar combinações comuns de utilizador e passwords de forma a entrar no Painel de administração do WordPress (isto é conhecido por BruteForce).

Para proteger a minha instalação de WordPress ainda pensei usar um plugin para proteger deste género de ataque mas decidi tentar uma abordagem de mais baixo nível, uma vez que já uso o Fail2Ban no servidor decidi aproveitar o mesmo e criar uma regra para à terceira tentativa de autenticação bloquear o ip de origem, fui acompanhando o número de ip’s bloqueados e são mais do que eu imaginava.

Como não sou nenhum master em regex usei uma expressão extremamente simples, quando uma tentativa de autenticação falha o WordPress retorna um erro http 403  (o comportamento standard retorna um 200 OK, com o JetPack ativo e com a opção de bloquear tentativas de login inválidas é que gera o 403), então é só mandar o Fail2Ban pesquisar acessos ao wp-login.php que retornaram 403, a regra que cheguei que se mostrou mais eficaz após alguns testes foi a seguinte:

failregex = :80 <HOST> .* /wp-login.php HTTP/1.1″ 403

Para já tem funcionado como esperado:

Optei por não usar plugins porque mesmo que um plugin detecte uma tentativa de intrusão, vai permitir que o atacante continue a gastar recursos ao servidor, ao enviar centenas ou milhares de pedidos seguidos. Como o Fail2Ban impede o ip do servidor de chegar sequer ao servidor o gasto de recursos é mínimo praticamente nulo.

Uma alteração que faço sempre no Fail2Ban é configurar para que quando bane um ip não faça REJECT e em vez disso faça um DROP(criei um Gist com isso) assim quem está do outro lado (o atacante) tem que aguardar pelo timeout do pedido para proceder para outro, isto fará com que no mínimo a aplicação que estão a usar para nos atacar consuma mais tempo e mais recursos ao atacante.

WordPress Importar Blogspot

O blogger é muito bom e gratuito mas também limitado em alguns aspetos, quando o blogspot não chega a solução pode passar por migrar para o WordPress.
O WordPress facilita esta migração ao disponibilizar uma ferramenta própria para o efeito, para a usar basta ir ao Painel do WordPress, seleccionar Ferramentas e clicar em “Importar”, nesta página surgem vários “importadores” de várias plataformas entre as quais o Blogger… seleccionamos “Instalar Agora” e o plugin de importação será instalado.

É Também possível importar do Blogroll, LiveJournal, Movable Type e TypePad, Tumblr e de sites alojados no WordPress.com.

Este importador importa o ficheiro xml exportado no Blogger, para gerar o ficheiro tem que fazer login no Blogger e ir a Definições -> Outros e seleccionar “Criar Cópia de Segurança de Conteúdo” será gerado um ficheiro com os posts.

Com o ficheiro do Blogger guardado voltamos ao painel do WordPress à página Importar e iniciamos o processo de importação basta seleccionar o novo autor para os posts e aguardar… quando o processo terminar todos os artigos da cópia estarão Publicados no WordPress.

 

 

Nova morada

Link

Decidi deixar de usar o domínio que usava neste blogue desde o seu inicio em 2005, embora não publique com muita frequência uso o servidor e o domínio para alojar algumas experiências e fazer testes.

Utilizei nestes 11 anos o serviço gratuito do no-ip.com, que nunca me deixou mal! quando criei a conta o domínio no-ip.com ainda fazia parte dos domínios que podia usar nas contas gratuitas, sei que isso já não é possível há alguns anos….

Neste período o blogue esteve offline algumas vezes com motivos como por exemplo, acidentalmente me “fechar” fora da firewall (Iptables) ou quando faltava a corrente eléctrica ou a internet e principalmente quando fazia alterações no servidor (que também me serve para outras coisas!!!) que corriam mal!

Não me esforcei muito para encontrar um novo domínio… substitui apenas o .no-ip.com por .net!!

Para esta alteração ser transparente renomeie o host antoniocampos.no-ip.com do apache para antoniocampos.net e apontei o host antoniocampos.no-ip.com para uma pasta que apenas tem um .htaccess que reencaminha todos os pedidos para o novo domínio exactamente com os mesmo parâmetros!!!

RewriteEngine on
RewriteRule ^(.*)$ http://antoniocampos.net/$1 [R=301,L]

Na configuração do WordPress alterei o domínio nas configurações reiniciei o Apache e parece que funcionou!!!

Como o servidor é fraquinho aproveitei para configurar o serviço cloudflare para me poupar alguma largura de banda e alguns pedidos…

Embora não seja coisa que me preocupa muito… segundo o video do Matt Cutts (da Google) esta alteração não deve afectar a indexação dos motores de busca… nem a “autoridade” (se é que tenho alguma!!) do site…

WordPress não mostra a “Admin Bar”

Hoje depois de atualizar uma das minhas instalações de WordPress para a versão 3.1 a nova barra de admin que aparece quando estamos no site não aparecia, como é um theme feito por mim resolvi investigar o porquê.

A causa para a barra não aparecer é que não estava a implementar corretamente a class do body, para resolver este problema bastou no ficheiro em que abro a tag body, bastou adicionar a seguir à abertura da tag <body> adicionar a função do wordpress que faz echo da class adequada para ser possível a apresentação da dita barra de admin. O código a adicionar é o seguinte <?php body_class($class)?>, pelo que a declaração do body ficará <body <?php body_class($class); ?>>. E basta isto para tornar qualquer theme compatível com a nova barra de admin omnipresente.

WordPress Child Themes

Recentemente depois de actualizar um blogue para o WordPress 3.0, cliquei sem em actualizar Plugins e Temas sem me lembrar que o tema usado estava modificado. Ao actualizar as modificações foram perdidas”¦ para evitar o mesmo erro no futuro decidi criar um Child Theme, e que é um Child Theme???

Um Child Theme é um Theme que deriva de outro Theme, ou seja no Child Theme que podemos chamar Tema Derivado implementamos apenas as modificações ao tema original, se por exemplo quiser-mos alterar algo no ficheiro single.php alteramos apenas esse ficheiro ficando o original do tema intacto, viabilizando assim futuras actualizações, sem comprometer as alterações que fizemos.

A estrutura de um Child Theme é bastante simples, primeiro criamos um directório para alojar os ficheiros modificados, fazemos as alterações que pretendemos, aconselho a copiar o ficheiro original do Theme Parent e fazer ai as alterações. Depois de termos as alterações pretendidas falta apenas criar o ficheiro onde o WordPress vai ler as informações do Tema esse ficheiro tem o nome de Style.css e vai sobrepor o Style.css do tema original á semelhança do que acontece com os outros ficheiros que colocar-mos no nosso Child Theme, este Style.css tem uma particularidade em relação ao original, que é uma tag que informa o WordPress de qual é o tema em que nos baseamos, esta tag é a tag Template. Deixo a seguir o Style.css para um Child Theme baseado no novo tema por defeito do WordPress que é o “Twenty Ten”:

/*
Theme Name:     Nome do Child Theme
Theme URI:      http: //UmUrlQualquer.com/
Description:    Descrição do Child Theme 
Author:         O seu nome
Author URI:     http: //OutroUrlQualquer.com/
Template:       twentyten
Version:        0.0.1
*/

 

Se quisermos usar o css do tema original basta fazer um import do style.css original, que no caso do tema Twenty Ten será:

@import url("../twentyten/style.css");

Podemos ainda no style.css modificar o css original, basta criar os elementos com o mesmo nome e adicionar as nossas personalizações.

Depois do tema criado é só fazer upload para a pasta “wp-content/themes/” e no painel de administração do blogue activar o mesmo. E os problemas com as actualizações do tema principal deixam de ser um  problema.