Imprimir post Imprimir post
 

WordPress: instalação segura, desempenho e gerenciamento de memória

Posted by Eriberto on fev 16, 2012 in Internet, Linux, Rede, Segurança |

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.

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.

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.

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.

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!!!

BackUpWordPress

Backup sempre é necessário. Este plugin é simples e eficiente. No entanto, ocupa cerca de 1 MB de memória quando ativado. Assim, caso você não tenha outro meio de realizar backup, ative-o. No entanto, caso possa, prefira backup via provedor. Ou ainda, caso o seu provedor lhe dê acesso via shell, como é o meu caso, utilize scripts e tarefas agendadas. Ainda, você terá problemas em provedores de hospedagem compartilhada, caso o seu conteúdo WP seja muito grade. Isso porque durante o backup haverá alto consumo de memória e o processo será encerrado prematuramente. Com isso, dependendo do caso, você nunca terá backup.

Apesar de ocupar 1 MB de RAM, o plugin é o mais simples e eficiente que testei. Cheguei a usá-lo quando hospedava em outro provedor que não me concedia shell. Para se ter uma ideia, o plugin Backup Scheduler, quando ativado, só em stand by, já ocupa mais de 5 MB de RAM.

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

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:

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

Vamos desinstalar e ver como fica. Resultado:

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.

Conclusão

A correta instalação do WordPress é muito importante para o seu funcionamento. Segurança também é primordial. Assim, vários detalhes deverão ser observados. Provedores como o DreamHost serão o céu ou o inferno, dependendo de como você hospede o seu site. Se fizer errado ou de qualquer jeito, com certeza, você será presenteado com um festival de erros 500.

Uma dica é testar em um servidor local todo o seu ambiente, antes de fazer upload para o provedor. Observe mensagens de erro nos logs, consumo de memória com auxílio do comando free e plugin específico etc. Assim, você escolherá os melhores plugins e temas. E lembre-se do conselho final: não abuse dos plugins!!! Eles poderão esgotar a memória e, talvez, abrir brechas de segurança.

Tags:, , , , , , , , , , , , , , , , , , , , , , , , , , ,

3 Comments

Anderson
jun 20, 2012 at 9:24 pm

Parabéns pelo post, grande em todos os sentidos mas vou te confessar uma coisa um dos poucos que li na integra, muito explicativo, faça uma video aula amigo parabens...


 
Eriberto
jun 21, 2012 at 2:10 pm

Grato Anderson!

Abs


 

Reply

*

Copyright © 2018 Eriberto Blog All rights reserved.
desk-mess-mirrored v theme from BuyNowShop.com.