em Wordpress

Protegendo melhor o meu WordPress

Depois de ter sido recentemente atacado por uma script injection que surgiu do nada, fiquei mais cauteloso no que diz respeito ao blog, quando se trata de segurança.

No começo deste mês acabei encontrando um artigo da Smashing Magazine, com 10 dicas para reforçar a proteção de sites que, como o meu, utilizam o WordPress. Embora seja verdade que reforçar a segurança de um site por conta própria requeira um conhecimento mínimo de Apache — e não se sentir intimidado com alterações no arquivo .htaccess —, não há nada realmente muito cabeludo a se fazer.

Assim sendo, quero compartilhar com vocês duas das alterações que fiz:

Primeira coisa: Proteger o blog de injeções de script

Os ataques de injeção de scripts acontecem quando um hacker introduz algumas linhas de código malicioso em um site através de um de seus formulários — o de comentários, por exemplo — e então envia tais dados através deste formulário. Isso é feito, geralmente, para que se possa enganar os sistemas em uso nos sites, de maneira que eles pensem que se trata de conteúdo enviado por um usuário válido, e assim acabem permitindo, sem querer, que dados sejam acessados, editados excluídos, ou que scripts mal intencionados sejam acessados e instalem vírus nas máquinas dos internautas desavisados.

Uma das técnicas básicas para um script injection é que uma máquina cliente submeta informações que contem tags, como a tag <script>. Isso nos leva  s diretivas abaixo, sugerida no artigo que li:

Options +FollowSymLinks 
RewriteEngine On 
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR] 
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR] 
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2}) 
RewriteRule ^(.*)$ index.php [F,L]

Ao serem adicionadas ao arquivo .htaccess, tais diretivas fazem com que qualquer requisição de acesso   uma página no blog seja verificada. Caso ela contenha referências   uma tag <script> ou, mais ainda, tenha tentado modificar o valor das variáveis GLOBALS ou _REQUEST do PHP, a requisição será bloqueada com um erro 403 (“Forbidden“) do Apache, ou seja, quem quer que esteja tentando realizar o acesso — neste caso, provavelmente alguém muito mal intencionado — será impedido de fazê-lo. Você pode até criar um documento personalizado para recepcionar alguém que tenha recebido o erro em questão:

ErrorDocument 403 /forbidden.php

Uma última palavra sobre as diretivas acima, é que estas podem ser facilmente modificadas para que incluam também as tags  <object>, <applet> e <embed>, também utilizadas em script injections. Desta maneira, reforça-se ainda mais a segurança.

Segunda coisa: Proteger o arquivo wp-config.php

Quando li o artigo da Smashing Magazine, vi que eles recomendam a proteção do arquivo wp-config.php — onde residem todas as configurações principais do WordPress, inclusive nomes de usuário e senha do banco de dados, que permitem a qualquer um com más intenções acesse todo o conteúdo do seu blog e faça com ele o que bem entender —, o que, afinal de contas, é uma excelente ideia.

O único problema é que eles, mais uma vez, se valem de alterações no arquivo .htaccess, da seguinte maneira:

<files wp-config.php>
order allow,deny
deny from all
</files>

Acredito, no entanto, que uma solução muito mais efetiva para impedir o acesso ao conteúdo do arquivo seja movê-lo para um lugar inacessível publicamente. Na prática, normalmente, isso significa movê-lo para antes da pasta public_html — onde fica tudo o que é visível para o mundo lá fora — em sua conta de usuário. Felizmente, desde a versão 2.6 do WordPress, isso é possível. Dessa maneira, basta que você utilize um programa de FTP de sua confiança e mova o arquivo em questão um nível acima.

De qualquer maneira, a dica dada pela Smashing Magazine ainda é válida se adaptarmos um pouco as coisas: Por exemplo, podemos aproveitar para proteger não o arquivo wp-config.php, mas sim o próprio arquivo .htaccess, da seguinte maneira:

<files .htaccess>
order allow,deny
deny from all
</files>

Conclusão

É óbvio que a proteção de um site contra ataques envolve uma série de outros passos e medidas de segurança, e muito mais leitura e estudo. Ainda assim, minha decisão de dividir estas duas simples alterações se deu porquê acredito serem realmente de grande valia para alguém que está pensando em proteger melhor seu conteúdo, e espero que, desta maneira, esteja prestando um serviço a quem se encontrar em uma situação difícil.

Para maiores informações, recomendo também a leitura do excelente artigo Hardening WordPress, disponível no próprio Codex da ferramenta.

Escreva um comentário

Comentário

  1. Muito obrigado pelas iformações, estou pesquisando muito sobre segurança.

    Tenho uma dúvida…

    As instruções de segurança, devo escrever em todos os arquivos .htaccess?
    Exemplo..
    Tem um .htaccess no diretório principal, outro em www , e mais um em wp-admin.

    Devo repetir as instruções para cada um?

    OBrigado.