Atualizado 13/08/2012

Muitos, como eu, utilizam o WordPress para fazerem os seus sites e blogs. E, com certeza, o WordPress é o sistema mais utilizado para blogs e um dos mais difundidos para sites na atualidade. O grande problema é que a maioria dos usuários descompacta o WordPress dentro dos seus GNU/Linux ou dos seus espaços em provedores, realiza a configuração básica via web, instala um monte de plugins e… pronto. Dessa forma, poderão ocorrer muitos problemas de desempenho e segurança.

O grande objetivo deste post é mostrar como agregar um pouco mais de segurança à instalação e como escolher os plugins de uma forma mais cuidadosa.

A instalação do WordPress

Depois da clássica instalação do tipo “descompacte o .zip, chame a URL do site, configure o seu WordPress“, algumas medidas deverão ser adotadas. A primeira delas é via shell (ssh, por exemplo) ou via FTP. Consiste em apagar arquivos que deem pistas sobre o seu WordPress, como versão etc. Ao realizar ataques, por exemplo, é sempre bom saber o software que está rodando do outro lado, incluindo a sua versão. Um dos grandes vilões aqui é o arquivo readme.html do WordPress. Ele cita a versão do WordPress instalado. Será possível encontrar um monte desses arquivos se você procurar no Google por algo como isto:

wordpress inurl:readme.html

Um exemplo de resultado, retirado da web (clique para ampliar):

Assim sendo, apague o quanto antes os arquivos license.txt e readme.html, existentes na raiz do diretório que contém o WordPress. Note que esse procedimento poderá ser necessário também depois de uma atualização do WP. Para tanto, utilize o comando:

# rm license.txt readme.html

Mas há outra saída, caso você deseje preservar tais arquivos. Alterar as suas permissões para 000 com o comando chmod.

IMPORTANTE: depois de escrever esta parte do post, encontrei um plugin que realiza, automaticamente, as ações descritas acima. Ele será comentado mais adiante. Trata-se do SIG.

O próximo passo será alterar o nível de permissão de acesso ao arquivo wp-config.php, que contém a senha de acesso ao banco de dados. Este passo só deverá ser realizado depois da configuração inicial do WordPress, ou seja, já deverá ter ocorrido a conexão entre o WP e o banco de dados. Para tanto, utilize o comando a seguir:

# chmod 400 wp-config.php

Dependendo de como o servidor de páginas esteja configurado, poderemos alterar mais um nível de permissionamento. Um exemplo disso é o Apache2 no Debian, que roda sob o usuário www-data. Então, neste caso, para maior segurança, devermos deixar arquivos com 640 (exceto o wp-config.php) e os diretórios com 750. Ainda, todos os arquivos e diretórios, inclusive o que contém o WordPress, deverão pertencer ao usuário www-data. Para isso, considerando que o site WordPress esteja em /var/www/teste/, deveremos executar:

# find /var/www/teste -type f -perm 644 -exec chmod 640 {} ;
# find /var/www/teste -type d -perm 755 -exec chmod 750 {} ;
# chown -R www-data.www-data /var/www/teste

O último item deste tópico, mas não menos importante,é sobre a conta de administrador. Essa conta, por default, é criada com o nome de usuário admin. Então, os robôs da Internet que buscam descobrir senhas utilizam sempre admin como usuário para tentarem entrar no blog. Por este e muitos outros motivos, é fundamental que você crie um usuário com outro nome para ser administrador e exclua o admin.

Esta é a configuração básica de segurança do WordPress. Os próximos tópicos tentarão descobrir “brechas” ou problemas.

De olho no log

A partir de agora deveremos ter o cuidado de verificar se aparecem erros no log /var/log/apache2/error.log. É MUITO IMPORTANTE testar o WordPress com o tema padrão e sem plugins. Teste com uma página ou com um post e um comentário, dependendo do seu caso. Depois, configure o WordPress, utilizando o painel de controle, de acordo com o seu gosto. Verifique o log novamente. Somente depois disso, instale temas e plugins. Mas não esqueça de testar um a um.

Atualize sempre!

Ao ser informado sobre atualizações no core do WordPress, em plugins ou temas, não hesite! Sistemas atualizados são chave primordial para manter a segurança do seu site. Atualizar ajuda a evitar invasões, defacements etc. Há plugins que avisam por e-mail sempre que uma atualização é lançada. Particularmente, gosto do WP Updates Notifier.

Lembramos que 99% das atualizações são relacionadas a questões de segurança. Quem não atualiza, o wordpress é um forte alvo de hackers e os convidando a entrar no s eu site.

Mas há uma regra básica para atualizações sem impacto: evite alterar o código-fonte do WordPress. Muitos sites ensinam dicas e truques que irão requerer alteração de código. Isso não é bom, pois qualquer atualização irá matar as suas alterações. Prefira utilizar plugins que executem tarefas específicas em vez de alterar código para obter benefícios.

Cuidados com temas e plugins

A maioria dos usuários de WordPress adora instalar temas e plugins indiscriminadamente. Realmente é prazeroso ter um monte de recursos. No entanto, temas não testados e plugins diversos podem trazer alguns problemas, como:

• Bugs. Um tema ou um plugin pode não funcionar corretamente. Com isso não teremos os resultados desejados, ou teremos resultados indesejados, ou poderemos ter ocorrências de difícil observação mas que nos levarão de simples telas brancas a desastres, como a perda de dados.
• Problemas de segurança. Isso poderá ocorrer principalmente em plugins que interagem com usuários. Assim, antes de instalar um plugin desse tipo, procure saber sobre o mesmo na Internet.
• Queda do serviço durante atualizações do WP. Plugins e temas poderão não estar preparados para novas versões do WordPress por ocasião de atualizações.
• Esgotamento de memória. Quanto mais plugins você tiver, mais consumo de memória você terá. E muitos provedores não toleram isso. Atenção também para plugins que consomem memória descontroladamente.

Como conselho final neste tópico, tenha o MÍNIMO de plugins instalados sempre. Quanto menos, melhor! Mas, para isso, você terá que vencer a sua vontade de ter milhões de plugins instalados. Então, preocupe-se se estiver utilizando mais de 10 plugins. Além disso, verifique o consumo de memória, erros etc. E cuidado com os sites que dizem: 30 maravilhosos plugins para isso ou aquilo. A maioria deles é maravilhosa mesmo. No entanto, os autores desses sites, raramente, testam os plugins que usam ou aconselham e… Espalham o caos.

Fechando o acesso aos diretórios de plugins

Alguns plugins permitem o acesso aos seu diretórios (que podem conter dados valiosos armazenados). Um deles, pelo menos até a versão atual, é o Lightbox Gallery, muito conhecido e utilizado. Para saber sobre o que estou falando, procure no Google por:

inurl:plugins lightbox-gallery

Assim, é uma boa ideia bloquear o acesso direto ao diretório de cada plugin instalado. Há várias formas de fazer isto. Vou citar duas:

• Se você tiver acesso às configurações do servidor de páginas e se este for um Apache2, edite o arquivo de configuração do site (possivelmente em /etc/apache2/sites-available/) e adicione:

<Directory /var/www/site/wp-content/plugins>
        Options -Indexes
</Directory>

Observe que você deverá alterar, no código acima, a primeira linha, de forma que o path referente ao diretório de plugins fique correto.

• Se você não tiver acesso às configurações do servidor de páginas, poderá criar um index.php vazio dentro dos diretórios de plugins que não contenham qualquer index (index.php, index.html etc). Realmente esta não é a solução mais profissional. No entanto, ela cai bem neste caso, pois será possível resolver o problema em provedores de acesso e também criar esse tipo de arquivo via script, se o servidor ou provedor permitir o agendamento de tarefas.

IMPORTANTE: o mesmo plugin que citei anteriormente, aquele que encontrei depois de escrever as primeiras partes deste post, também cuida dos diretórios sem index. Ele será comentado mais adiante. Trata-se do SIG.

Protegendo a pasta wp-admin

você já tens um nome de usuario e uma senha (password) virtualmente impossíveis de descobrir, isso é otimo, mas ainda pode aplicar uma protecção extra ao painel de administração. Com o  .htaccess ou através do painel de controle do seu site (cPanel), pode proteger o acesso à pasta wp-admin com um nome de utilizador e password extra. O plugin Ask Apache faz isso mesmo.

Esconder o login

Todo mundo sabe qual é o endereço url para fazer login (www.seuwordpress/wp-admin/) e para aceder ao painel de administração do WordPress. É possivel alterar este endereço do seu blog da forma que você seja o único a saber o link de acesso. Para esse efeito temos o plugin Stealth Login.

Alterar a base de dados (prefixo do BD)!

Por defeito, as tabelas da base de dados do WordPress usam o prefixo “wp-”. Em vez disso, tente trocar a base, usando um prefixo diferente e único para cada instalação do wordpress.

Instale o plugin Login Lock Down
Alguns metidos a “hackers” tentam ter controle do blog na base da tentativa e erro (também chamado de força bruta),digitando logins e senhas que acreditam que podem dar certo.

Para resolver este problema, você pode utilizar o plugin Login Lock Down, que guarda o IP de quem estiver tentando acessar o blog por força bruta, bloqueando o acesso ao invasor após um número X de tentativas sem êxito

Plugins essenciais para segurança

Alguns plugins são muito interessantes para a segurança. Na verdade, eles são essenciais e vale a pena tê-los. É importante ressaltar que todos foram testados de forma básica, inclusive no que tange a consumo de memória.

Limit Login Attempts

Este plugin, permite configurar o número de tentativas de login, por exemplo, caso você configure com no máximo 5 tentativas, após exceder esse número o IP do usuário será bloqueado. Essa função aumenta muito a segurança e evita principalmente ataques Brute Force. Para quem não sabe Brute Force é um ataque em que um sistema ou script tenta várias combinações de senhas e usuários até ter sucesso.

AntiVirus

O plugin ajuda a proteger o seu site contra vírus, worms e malwares que podem prejudica-lo. Além disse ele monitora os arquivos e fornece alertas sobre possíveis ataques.

WP-Sentinel

O WP-Sentinel checa todas as solicitações HTTP utilizando um serie de regras a fim de encontrar ações maliciosas como, Brute Force, SQL Injections e várias outras. Quanto o ativo o plugin é carregado antes dos outros e verifica os pedidos HTTP, quando algo de errado é detectado o sistema bloqueia o acesso, exibe uma mensagem de erro para o usuário e envia um e-mail para o administrador com detalhes do ataque. O plugin não verifica os pedidos do administrador, sendo assim, caso você desejar fazer testes saia da área administrativa antes ou utilize ou outro navegador.

WordPress Firewall 2

Este plugin detecta ataques diversos, bloqueando-os. Utiliza eurísticas e pode avisar, via e-mail, sobre atividades irregulares ocorridas. Simples e rápido de configurar.

Ban Hammer

O Ban Hammer é um plugin indicado para sites que permitem o cadastro de usuários, ele permite que você bloquei e-mails, IPs ou domínios inteiros. Com as funções do plugin você pode evitar que sistemas utilizem o mesmo domínio para se cadastrar automaticamente em seu site.

TAC

TAC ou Theme Authenticity Checker verifica os arquivos dos temas e identifica links maliciosos ou que você pode considerar indesejados. Ajuda muito a encontrar links com propaganda e códigos criptografados. Este plugin é muito util, pois muitos usuarios (99%) usa temas (themes, layouts) de wordpress gratis, achados na web ou comprados de forma duvidosa, CUIDADO, muitos destes, ja estão comprometidos, com scripts, malwares, troyans que rouba senhas, etc. O seja, a maioria dos hackers conta com que você instale alguns temas gratuitos, pois com eles, poderá invadir/hackear facilmente seu wordpress.

BulletProof Security

O BulletProof Security é um plugin bem completo que permite a proteção dos arquivos “.htacess”, “wp-config.php”, “php.ini” e vários outros. O plugin também protege o site contra ataques, SQL Injection, verifica arquivos, banco de dados e possui diversas opções de proteção.

WP Security Scan

A função deste plugin é bem simples e útil, ele verifica o site a procura de falhas e sugere as correções. Durante o processo são verificadas as senhas, permissão dos arquivos, banco de dados e proteção da área administrativa. Caso o plugin solicite alguma mudança na permissão dos arquivos ou banco de dados, eu recomendo a realização de um backup completo antes, afinal você estará modificando arquivos e dados do sistema e vale apena ter uma cópia de segurança original.

WP Sanitize

O WP Sanitize realiza algumas ações de segurança muito importantes. Dentre elas, remove a versão do WordPress das páginas apresentadas na Internet. Ele também possui um recurso muito útil, que é a limpeza diária automática do banco de dados, removendo os overhead (lixo deixado no banco).

WP Updates Notifier

Avisa, via e-mail, sobre a atualização de elementos no WordPress. São eles: o core, plugins e temas. Mas não abuse, pois essas verificações consomem memória e link, e provedores não gostam disso. Sugiro uma verificação por dia.

Silence is Golden Guard plugin (SIG)

O plugin é capaz de fazer verificações diárias no WordPress, atuando sobre problemas encontrados. Alguns já foram descritos neste post e foi gratificante encontrar um plugins que automatizasse as ações. Algumas delas: cria arquivos index.php em diretórios de plugins e outros, apaga arquivos readme.txt etc. NO ENTANTO, este plugin ao ser ativado, consome 5 MB de RAM constantemente (um valor absurdo para WordPress). Esse detalhe foi visto com o auxílio do plugin PHP memory indicator. Assim, creio que seja uma boa ideia deixá-lo desativado. De vez em quando, ative-o, clique em Scan Now (disponível na página de configuração do plugin) e desative-o. Recomendo que faça isso sempre que houver qualquer instalação ou upgrade de core, tema ou plugin. Então, o seu WordPress estará protegido e não haverá consumo de memória desnecessariamente.

WordPress File Monitor Plus

Este plugin realiza o famoso check de integridade do sistema, avisando por e-mail caso algum arquivo tenha sido criado, apagado ou alterado. É bem configurável e essencial para denunciar casos de invasão ou preparação para a invasão. Use isto!!!

Agora, veja os logs…

Se você tiver acesso aos logs do servidor, olhá-los será o próximo passo. O que nos interessa é o log error.log do Apache. Normalmente fica em /var/log/apache2/error.log. Lá será possível encontrar algumas ocorrências irregulares, como esta:

[Thu Feb 16 14:27:23 2012] [error] [client 200.x.x.1] File does not exist:

 /var/www/wp2/wp-content/plugins/silence-is-golden-guard/images/tom.png,

referer: http://www.rede.com.br/wp2/wp-admin/options-general.php?page=sig-guard.php

Neste caso, é nítido que está faltando o arquivo /var/www/wp2/wp-content/plugins/silence-is-golden-guard/images/tom.png. Geralmente os problemas apresentados serão relativos à falta de arquivos. Mas isso é importante? Sim! Muito! Porque haverá consumo de mais tempo e memória procurando algo que não existe e, logo depois, escrevendo em log. Os logs também ficarão recheados e ocupando espaço. Então, deveremos fazer os seguinte:

• Criar os arquivos faltosos, deixando vazio o seu conteúdo. Isso poderá ser feito com o comando touch. Exemplo:

# touch /var/www/wp2/wp-content/plugins/silence-is-golden-guard/images/tom.png

• Avisar ao autor sobre o problema para que ele possa corrigi-lo. Isso poderá ser feito na página específica do plugin, dentro do site http://wordpress.org/extend/plugins.

Tratando a memória

A partir de agora falaremos um pouco sobre memória.

O WordPress costuma ser uma dor de cabeça para os provedores de conteúdo, uma vez que a maioria dos administradores de blogs e sites costuma instalar milhões de plugins sem saber o que está fazendo. Então, os WordPress da vida vão virando monstros comedores de RAM. Na maioria das vezes, os provedores optam por utilizar ferramentas que matam os processos, principalmente os baseados em PHP, que estejam consumindo muita memória. O resultado disso, geralmente, será uma mensagem “500 Internal Server Error” na tela de quem acessa o site. Isso ocorre, especialmente, em provedores com hospedagem compartilhada, onde vários site são abrigados pela mesma máquina e usam o mesmo processador e a mesma memória.

O ajuste da memória

Regras de ouro, caso esteja utilizando um espaço comprado em um provedor:

• Nunca abuse de plugins.
• Otimize ao máximo o seu WordPress.
• Faça medição de uso de memória com plugin específico para isso.

Além disso, o WordPress vem configurado para utilizar somente 32 MB de RAM em caso de uso simples ou 64 MB para multisites, que é a situação referente a disponibilizar vários sites e blogs utilizando apenas um motor WordPress. No entanto um WordPress com um tema comum e alguns plugins, em standby, já consome uns 35 MB ou mais. O tema escolhido também interfere nisso. E por incrível que pareça, plugins instalados, mesmo desativados, também consomem memória. Então, será necessário ampliar esse limite de 32 MB ou você enfrentará constantes erros 500. Mas o limite de memória a ser utilizado pelo WordPress não poderá ser maior que o limite estabelecido pelo PHP para todas as aplicações gerenciadas por ele.

A primeira ação será instalar um plugin de visualização de memória. Lembre-se de desativá-lo depois do uso! Então, sugiro o “PHP memory indicator”. Ele mostra dados no rodapé da página. Veja a figura a seguir (clique para ampliar):

O primeiro valor exibido é a quantidade de memória utilizada pelo WordPress (40.74 MB), incluindo o tema e plugins. O segundo valor é a quantidade máxima de memória com utilização permitida pelas configurações do PHP (90 MB). O limite de memória imposto pelo WordPress não é mostrado.

No caso anterior, sabendo que o valor limite default do WordPress para sites e blogs fora do sistema multisites é 32 MB, faltará memória. Com isso, teremos um festival de erros 500, pois os acessos de usuários irão gerar um uso de memória que será rejeitado pelo sistema. Para evitar isso, poderemos alterar as configurações do WordPress. Procure utilizar o valor máximo permitido pelo PHP, reduzido em 10%. Ou seja: 90 – 10% = 81 MB.

Para alterar a quantidade de memória utilizada pelo WordPress, aumentando de 32 para 81 MB, edite o arquivo wp-config.php (na raiz do WordPress) e insira no início, logo depois de <?php:

define('WP_MEMORY_LIMIT', '81M');

Caso você precise de um maior controle sobre o que está ocorrendo na memória e informações detalhadas sobre o sistema, utilize o plugin TPC! Memory Usage. Ele é um pouco difícil de encontrar. Então, clique aqui. Mas lembre-se: depois de utilizar, desative-o! A seguir um exemplo de tela de informações do plugin (clique para ampliar):

Mito: plugin para medir uso de memória lhe dirá tudo!

Muitos e muitos sites e blogs, na verdade todos os que eu vi, dizem que plugins como o TCP! Memory Usage mostram toda a memória que o WordPress está usando. Diversos sites ensinam: “olhe a quantidade de memória utilizada pelo WordPress no radapé, antes e depois da instalação do plugin. A diferença entre os dois será a quantidade de memória gasta pelo plugin”. ERRADO!!!!!!

Qualquer processo, quando ativo, consome muito mais memória do que quando está em standby. Então, um plugin como o BackUpWordPress, por exemplo, irá consumir muito mais memória no momento em que estiver realizando o backup. Além disso, há diversas variáveis que interferem de forma diferente no sistema a cada instante. Então, se você instalar, por exemplo, o PHP memory indicator e executar vários refreshes no browser enquanto olha o rodapé, notará que o consumo de memória variará um pouco. Porque é assim que um sistema operacional funciona! Simples!

Vamos a um exemplo. No rodapé de um WordPress, podemos ver:

Obrigado por criar com o WordPress. | Load 40.72 of 90M

Agora, vamos instalar o plugin BackUpWordPress. Depois da instalação, o sistema mostra:

Obrigado por criar com o WordPress. | Load 41.56 of 90M

Vamos desinstalar e ver como fica. Resultado:

Obrigado por criar com o WordPress. | Load 40.69 of 90M

Observe que houve uma pequena variação, ou seja, o valor final não foi 40.72 e sim 40.69. Isso é o esperado em um sistema operacional. Com isso, a teoria mostrada na maioria dos sites está um pouco fora da realidade, apesar de ser inegável que você terá uma excelente ideia do consumo de memória COM O PLUGIN EM STANDBY. Não é exato. É aproximado. Mas muito próximo do real.

Agora vamos fazer uma prova de fogo. Passei a monitorar a memória com um watch. Depois de vários refreshes em cima do browser que mostra o WordPress, obtive:

# watch -n1 free -m

Every 1,0s: free -m

             total       used       free     shared    buffers     cached
Mem:          3516        792       2724          0         99        240
-/+ buffers/cache: 452 3064
Swap:            0          0          0

Em outras palavras, o sistema está gastando 452 MB de RAM para se manter neste momento. Agora iniciarei, manualmente, uma operação de backup via plugin. Veja o resultado, durante todo o período do backup:

-/+ buffers/cache:        483       3033

A operação foi repetida e o mesmo resultado foi obtido novamente. Isso quer dizer que, durante o backup, 31 MB de RAM são consumidos (483 MB – 452 MB). É lógico que não foi o plugin quem gastou sozinho esses 31 MB. Isso porque há chamadas de sistema envolvidas, que também consomem memória. Mas consideremos que o BackUpWordPress tenha utilizado, pelo menos, 30% desse total (número mágico que saiu da minha cabeça). Então, podemos arbitrar que o plugin consumiu cerca de 9 MB. Resumo: o plugin ocupa cerca de 850 KB em standby e, estimativamente, 9 MB ou mais em funcionamento. Assim sendo, fique de olho nos seus plugins e temas (também ocupam memória).

É importante ressaltar que, além de consumo de memória, é durante o seu funcionamento que plugins podem apresentar falhas de segurança. Uma atenção especial deve ser dada aos plugins que interagem com o usuário.

Importante:

Não é recomendado utilizar todos os plugins em apenas uma instalação, é necessário analisar quais você precisa antes de instalar, há plugins que não são necessários dependendo da configuração do WordPress, por exemplo o plugin Ban Hammer é indicado para site que permitem o cadastro de usuários, se o seu site está com essa função desabilitada, não faz sentido tê-lo ativo. Outro exemplo é o plugin TAC, após verificar os links dos temas, poderá desativa-lo e até removê-lo do diretório, uma vez que o mesmo será útil apenas quando você instalar um novo tema.

Você deve fazer um backup completo do WordPress e banco de dados antes de instalar qualquer plugin. Os plugins podem apresentar erros e se comportar de forma diferente em cada instalação, ter um backup de segurança evita que você tenha dores de cabeça caso algo não saia como planejado.

Não deixe de compartilhar com os seus amigos e comentar sobre os plugins, quais você utiliza e quais irá tentar.

Fontes: http://eriberto.pro.br e http://web.iconectado.com.br/