{"id":3892,"date":"2014-12-08T10:18:25","date_gmt":"2014-12-08T12:18:25","guid":{"rendered":"http:\/\/blog.turbosite.com.br\/?p=3892"},"modified":"2014-12-08T10:18:25","modified_gmt":"2014-12-08T12:18:25","slug":"deixando-seu-wordpress-mais-seguro","status":"publish","type":"post","link":"https:\/\/www.turbosite.com.br\/blog\/deixando-seu-wordpress-mais-seguro\/","title":{"rendered":"Deixando seu WordPress mais Seguro"},"content":{"rendered":"

Em 2014 o n\u00famero de utilizadores do WordPress s\u00f3 vem aumentando, ele j\u00e1 ocupa 60,9% do mercado de sites com gerenciamento de conte\u00fado. De pequeno a grandes portais todos devem se preocupar com a seguran\u00e7a de seus sites e hoje, vamos compartilhar uma dica que pode fazer a o seu site n\u00e3o\u00a0ser “mais um blog em WordPress”.<\/em><\/p>\n

De acordo com o relat\u00f3rio da w3techs.com<\/a>, todos os sites com gerenciamento de conte\u00fado, 60,9% est\u00e3o em WordPress.<\/p>\n

WordPress is used by 60.9%<\/b> of all the websites whose content management system we know. This is 23.2% of all websites.<\/p><\/blockquote>\n

 <\/p>\n

A dica postada hoje foi escrita pelo\u00a0Tiago\u00a0Hillebrandt<\/a>. Vale a pena a leitura.<\/p>\n

 <\/p>\n

Nos dias atuais, infelizmente a seguran\u00e7a n\u00e3o tem sido encarada da forma que deveria por muitos desenvolvedores, e at\u00e9 mesmo pelas empresas de hospedagem.<\/p>\n

\u00c9 muito comum encontrarmos instala\u00e7\u00f5es sendo invadidas pelo descuido em quest\u00f5es b\u00e1sicas de seguran\u00e7a, como permiss\u00f5es de arquivos ou hashes<\/em> n\u00e3o atualizados no wp-config.php<\/em>.<\/p>\n

Com base nisso, resolvi publicar aqui um simples tutorial separado por etapas com algumas boas dicas de seguran\u00e7a focadas em\u00a0WordPress<\/strong>.<\/p>\n

\"Dicas<\/p>\n

 <\/p>\n

<\/span>1. PHP<\/h3>\n

Basicamente, \u00e9 de suma import\u00e2ncia manter as seguintes diretivas no seu\u00a0php.ini<\/em>:<\/p>\n

display_errors=Off\nallow_url_fopen=Off\ndisable_functions=popen,exec,system,passthru,proc_open,shell_exec,highlight_file,escapeshellcmd,pcntl_exec<\/pre>\n
Essas diretivas ir\u00e3o desabilitar algumas fun\u00e7\u00f5es que podem representar risco para seu servidor.<\/p>\n
Mas e se meu tema ou um dos meus plugins<\/em> usar alguma dessas fun\u00e7\u00f5es? Considere remov\u00ea-lo ou substitu\u00ed-lo!<\/p>\n
Por exemplo, \u00e9 comum ver\u00a0plugins<\/em>\u00a0usando a fun\u00e7\u00e3o exec()<\/em>\u00a0para manipular imagens. Manipula\u00e7\u00e3o de imagens \u00e9 um processo que em geral consome muitos recursos do servidor, e certamente vai acarretar na perda de performance em seu site<\/em>. Assim, al\u00e9m de todas as quest\u00f5es de seguran\u00e7a envolvidas, temos mais um motivo para n\u00e3o utilizar esses plugins<\/em>.<\/p>\n
 <\/p>\n
2. Servidor web<\/h3>\n
A p\u00e1gina Hardening WordPress<\/a> no Codex<\/a>\u00a0recomenda a adi\u00e7\u00e3o de algumas regras no servidor web<\/em> para seguran\u00e7a do diret\u00f3rio wp-includes<\/em> e do arquivowp-config.php<\/em>.<\/p>\n
 <\/p>\n
2.1. Nginx<\/h4>\n
Se o seu servidor\u00a0web<\/em>\u00a0for o\u00a0Apache<\/strong>, ignore essa etapa.<\/p>\n
Como as regras est\u00e3o no formato\u00a0Apache<\/strong>, efetuei a convers\u00e3o delas para o formato\u00a0Nginx<\/strong> manualmente.<\/p>\n
Assim, voc\u00ea dever\u00e1 editar o arquivo de configura\u00e7\u00e3o do seu site, geralmente dispon\u00edvel em \/etc\/nginx\/sites-available\/<\/em>, e adicionar as seguintes linhas:<\/p>\n
# WordPress Hardening\nif ($request_uri ~ ^\/wp-admin\/includes\/) { return 403; }\nif ($request_uri ~ ^\/wp-includes\/js\/tinymce\/langs\/.+\\.php$) { return 403; }\nif ($request_uri ~ ^\/wp-includes\/theme-compat\/) { return 403; }\nif ($request_uri ~ ^\/wp-config\\.php$) { return 403; }<\/pre>\n
 <\/p>\n
Al\u00e9m disso, a linha abaixo tamb\u00e9m dever\u00e1 ser adicionada se voc\u00ea N\u00c3O estiver rodando uma instala\u00e7\u00e3o\u00a0multisite<\/em>\u00a0do WordPress<\/strong>:<\/p>\n
if ($request_uri ~ ^\/wp-includes\/[^\/]+\\.php$) { return 403; }\n<\/pre>\n
 <\/p>\n
Ap\u00f3s adicionar as linhas, salve o arquivo, d\u00ea um reload<\/em> no Nginx<\/strong> e voil\u00e1.<\/em><\/p>\n
 <\/p>\n
2.2. Apache<\/h4>\n
Se o seu servidor web<\/em> for o\u00a0Nginx<\/strong>, ignore essa etapa.<\/p>\n
Voc\u00ea dever\u00e1 editar o arquivo .htaccess<\/em> do seu site e adicionar as seguintes instru\u00e7\u00f5es:<\/p>\n
# WordPress Hardening: wp-config.php\n<files wp-config.php>\norder allow,deny\ndeny from all\n<\/files><\/pre>\n
 <\/p>\n
# Disables the access to htaccess file\n<files .htaccess>\norder allow,deny\ndeny from all\n<\/files><\/pre>\n
 <\/p>\n
# WordPress Hardening: wp-includes\n<IfModule mod_rewrite.c>\nRewriteEngine On\nRewriteBase \/\nRewriteRule ^wp-admin\/includes\/ - [F,L]\nRewriteRule !^wp-includes\/ - [S=3]\nRewriteRule ^wp-includes\/[^\/]+\\.php$ - [F,L]\nRewriteRule ^wp-includes\/js\/tinymce\/langs\/.+\\.php - [F,L]\nRewriteRule ^wp-includes\/theme-compat\/ - [F,L]\n<\/IfModule><\/pre>\n
 <\/p>\n
Al\u00e9m disso, a linha abaixo tamb\u00e9m dever\u00e1 ser adicionada dentro do bloco do\u00a0wp-includes<\/em> se voc\u00ea N\u00c3O estiver rodando uma instala\u00e7\u00e3o\u00a0multisite<\/em>\u00a0do\u00a0WordPress<\/strong>:<\/p>\n
RewriteRule ^wp-includes\/[^\/]+\\.php$ - [F,L]<\/pre>\n
 <\/p>\n
Feito isso, salve o arquivo e voil\u00e0<\/em>, o Apache<\/strong> dever\u00e1 carregar suas regras automaticamente.<\/p>\n
 <\/p>\n
3. MySQL<\/h3>\n
Primeiramente, recomendaria adicionar a seguinte linha ao seu my.cnf<\/em>:<\/p>\n
bind-address=127.0.0.1<\/pre>\n
 <\/p>\n
Feito isso, basta salvar o arquivo e reiniciar o MySQL<\/strong>.\u00a0Com aquela linha, somente acessos vindouros do pr\u00f3prio servidor ser\u00e3o aceitos.<\/p>\n
Em rela\u00e7\u00e3o a base de dados, meu conselho seria criar um usu\u00e1rio dedicado porsite<\/em> rodando\u00a0WordPress<\/strong>.<\/p>\n
Para criar um novo usu\u00e1rio, basta executar os seguintes comandos SQL como\u00a0root<\/strong>\u00a0\u2014 substituindo database<\/em> pelo nome da sua base de dados,\u00a0user<\/em> pelo nome de usu\u00e1rio e\u00a0password<\/em> pela senha desejada:<\/p>\n
GRANT ALL PRIVILEGES ON database.* TO user@'localhost' IDENTIFIED BY 'password';\nFLUSH PRIVILEGES;<\/pre>\n
 <\/p>\n
Um bom site para gerar senhas \u00e9 o Random Keygen<\/a><\/em>.<\/p>\n
Depois disso, v\u00e1 at\u00e9 o seu wp-config.php<\/em> e edite as credenciais de acordo com o novo usu\u00e1rio que criou.<\/p>\n
 <\/p>\n
4. Permiss\u00f5es dos arquivos e diret\u00f3rios<\/h3>\n
\u00c9 muito comum encontrarmos instala\u00e7\u00f5es\u00a0WordPress<\/strong>\u00a0com permiss\u00f5es atribu\u00eddas de maneira inadequada e potencialmente perigosas, principalmente se tratando de hospedagens compartilhadas (shared hosting<\/em>).<\/p>\n
O mais comum dos erros nessa etapa \u00e9 a defini\u00e7\u00e3o recursiva da permiss\u00e3o 777 para o diret\u00f3rio wp-content\/uploads\/<\/em>. Fazendo uma pequena pesquisa \u00e9 poss\u00edvel encontrar uma conhecida empresa de hospedagem aqui no Brasil recomendando o uso dessa permiss\u00e3o naquele diret\u00f3rio.<\/p>\n
Para evitar dores de cabe\u00e7a devido a permiss\u00f5es inapropriadas, basta executar tr\u00eas comandos no diret\u00f3rio onde seu site<\/em> est\u00e1 instalado:<\/p>\n
# find . -type d -exec chmod 755 {} \\;\n# find . -type f -exec chmod 644 {} \\;\n# chmod 400 wp-config.php<\/pre>\n
 <\/p>\n
Assim, todos os diret\u00f3rios ter\u00e3o permiss\u00e3o 755, e todos os arquivos 644, conforme recomendado pela p\u00e1gina\u00a0<\/strong>Hardening WordPress<\/a>\u00a0dispon\u00edvel noCodex<\/a>. Al\u00e9m disso, adicionalmente seu wp-config.php<\/em> ter\u00e1 permiss\u00f5es de somente leitura para o usu\u00e1rio root<\/em>.<\/p>\n
Na\u00a0Synthesis<\/strong><\/a>, que oferece hospedagem especializada em\u00a0WordPress<\/strong>, essas permiss\u00f5es j\u00e1 est\u00e3o definidas por padr\u00e3o na sua instala\u00e7\u00e3o!<\/p>\n
Est\u00e1 usando uma hospedagem compartilhada e n\u00e3o tem acesso ao servidor para executar os comandos? Envie um e-mail para o suporte t\u00e9nico da empresa solicitando para executarem estes comandos em sua instala\u00e7\u00e3o WordPress<\/strong>. Provavelmente eles n\u00e3o ir\u00e3o se opor, se tratando apenas de tr\u00eas simples comandos.<\/p>\n
Dica: se a empresa n\u00e3o for capaz de rodar aqueles comandos por voc\u00ea, confie em mim, mude de hospedagem o mais r\u00e1pido poss\u00edvel.<\/p>\n
 <\/p>\n
5. Hashes<\/em> do wp-config.php<\/em><\/h3>\n
Possivelmente, navegando pelo wp-config.php<\/em>, voc\u00ea j\u00e1 se deparou com as seguintes constantes:<\/p>\n
define('AUTH_KEY', 'put your unique phrase here');\ndefine('SECURE_AUTH_KEY', 'put your unique phrase here');\ndefine('LOGGED_IN_KEY', 'put your unique phrase here');\ndefine('NONCE_KEY', 'put your unique phrase here');\ndefine('AUTH_SALT', 'put your unique phrase here');\ndefine('SECURE_AUTH_SALT', 'put your unique phrase here');\ndefine('LOGGED_IN_SALT', 'put your unique phrase here');\ndefine('NONCE_SALT', 'put your unique phrase here');<\/pre>\n
 <\/p>\n
Daria para escrever um belo texto explicando essas constantes e como o\u00a0WordPress<\/strong> lida com elas, mas vou simplificar para n\u00e3o fugirmos do foco do texto.<\/p>\n
As constantes\u00a0AUTH_KEY<\/em>, SECURE_AUTH_KEY<\/em>, LOGGED_IN_KEY<\/em> eNONCE_KEY<\/em> s\u00e3o respons\u00e1veis por garantir a criptografia dos cookies<\/em>\u00a0do usu\u00e1rio gerados pelo\u00a0WordPress<\/strong>. O sistema de autentica\u00e7\u00e3o do WordPress<\/strong> \u00e9 baseado nesses\u00a0cookies<\/em>.<\/p>\n
Quer tirar a prova real? Autentique-se no Dashboard,<\/em>\u00a0edite o valor da constanteAUTH_KEY<\/em> no seu wp-config.php\u00a0<\/em>e d\u00ea um refresh<\/em>\u00a0na p\u00e1gina rec\u00e9m-autenticada do Dashboard<\/em>. Voc\u00ea ser\u00e1 direcionado(a) para p\u00e1gina de log in<\/em>\u00a0do\u00a0WordPress<\/strong>.<\/p>\n
Repare que para cada KEY<\/em> h\u00e1 um SALT<\/em> correspondente. As KEYs<\/em> adicionam elementos aleat\u00f3rios para a senha. J\u00e1 os SALTs<\/em> s\u00e3o usados para melhorar ainda mais o resultado gerado pelas\u00a0KEYs<\/em>.<\/p>\n
Deixando a teoria de lado, para nos auxiliar o time do\u00a0WordPress<\/strong> disponibilizou uma pequena fun\u00e7\u00e3o em sua API para gerar os valores das constantes automaticamente:\u00a0https:\/\/api.wordpress.org\/secret-key\/1.1\/salt\/<\/a><\/p>\n
Assim, basta acessar a p\u00e1gina acima, copiar o conte\u00fado dela e substituir as atuais constantes KEYs e SALTs em seu wp-config.php<\/em>\u00a0com as geradas pela API.<\/p>\n
 <\/p>\n
6. Atualiza\u00e7\u00f5es do WordPress<\/h3>\n
\u00c9 sempre importante manter seu WordPress<\/strong> atualizado.<\/p>\n
As vers\u00f5es pontuais em geral trazem corre\u00e7\u00f5es de bugs<\/em>\u00a0e pequenas modifica\u00e7\u00f5es.\u00a0Assim, \u00e9 sempre uma boa pr\u00e1tica configurar o WordPress<\/strong>\u00a0para receb\u00ea-las automaticamente.<\/p>\n
Como exemplo, cito a vers\u00e3o 3.8.1 do\u00a0WordPress<\/strong>, que trouxe a\u00a0corre\u00e7\u00e3o de 31\u00a0bugs<\/em><\/a>\u00a0existentes na vers\u00e3o 3.8.<\/p>\n
Para ativar as atualiza\u00e7\u00f5es autom\u00e1ticas das vers\u00f5es pontuais, adicione a seguinte linha ao seu wp-config.php<\/em>:<\/p>\n
define('WP_AUTO_UPDATE_CORE', 'minor');<\/pre>\n
 <\/p>\n
Depois disso basta salvar o arquivo e fech\u00e1-lo.<\/p>\n
 <\/p>\n
7. WordPress, plugins<\/em> e temas<\/h3>\n
Por padr\u00e3o, o WordPress<\/strong> permite editar arquivos PHP via Dashboard<\/em>. Isso pode trazer grandes problemas se algu\u00e9m que n\u00e3o deveria, de alguma forma, obtiver acesso ao Dashboard<\/em>.<\/p>\n
Assim, recomendo que desabilite o editor padr\u00e3o do WordPress<\/strong> e edite seus arquivos somente via SFTP ou SSH. Para desabilit\u00e1-lo, basta adicionar a seguinte linha ao wp-config.php<\/em>:<\/p>\n
define('DISALLOW_FILE_EDIT', true);<\/pre>\n
 <\/p>\n
Outro ponto importante: manter seus\u00a0temas e plugins<\/em> atualizados. As atualiza\u00e7\u00f5es trazem corre\u00e7\u00f5es de seguran\u00e7a e de demais bugs<\/em>, bem como novas funcionalidades para o tema ou\u00a0plugin<\/em>.<\/p>\n
Tamb\u00e9m \u00e9 importante ter certeza que o plugin<\/em> ou tema continua sendo suportado pelo(s) desenvolvedor(es), bem como verificar se ele \u00e9 compat\u00edvel com sua atual vers\u00e3o do WordPress<\/strong>.<\/p>\n
Al\u00e9m disso, temas e plugins<\/em>\u00a0que n\u00e3o est\u00e3o sendo usados devem ser removidos do seu WordPress<\/strong>, pois podem representar problemas de seguran\u00e7a, tendo em vista que continuam acess\u00edveis mesmo quando desativados no Dashboard<\/em>.<\/p>\n
 <\/p>\n
8. Prote\u00e7\u00e3o contra ataques DDoS ao xmlrpc.php<\/h3>\n
Atualmente existe uma onda de ataques DDoS<\/em><\/a> destinados ao arquivo\u00a0xmlrpc.php<\/em> das instala\u00e7\u00f5es WordPress<\/strong>. E \u00e9 muito comum ver este tipo de ataque comprometer a performance do site<\/em> e, muitas vezes, at\u00e9 tir\u00e1-lo do ar.<\/p>\n
Para resolver o problema, a Sucuri.net<\/a>\u00a0\u2013 empresa especializada em seguran\u00e7a\u00a0WordPress<\/strong>\u00a0\u2013 recomenda que o protocolo XMLRPC (pingback<\/em>) seja desativado.<\/p>\n
Com base no c\u00f3digo recomendado pela\u00a0Sucuri<\/em>, escrevi um pequeno plugin<\/em> que pode ser adicionado ao\u00a0WordPress<\/strong>. Basta criar um arquivo chamado disable-xmlrpc.php<\/em> em seu diret\u00f3rio de plugins<\/em>\u00a0(normalmente wp-content\/plugins\/<\/em>) com o seguinte conte\u00fado:<\/p>\n
\/**\n * Plugin Name: Disable XMLRPC\n * Description: This plugin disables the XMLRPC protocol to avoid DDoS attacks.\n * Version: 0.1 by Sucuri Security\n *\/<\/pre>\n
 <\/p>\n
add_filter( 'xmlrpc_methods', function( $methods ) {\n unset( $methods['pingback.ping'] );\n return $methods;\n} );<\/pre>\n
 <\/p>\n
Depois disso, salve e feche o arquivo, v\u00e1 at\u00e9 o Dashboard<\/em> e habilite o plugin<\/em> \":)\"<\/p>\n
ATUALIZA\u00c7\u00c3O:<\/strong>\u00a0seguindo a dica do Diego, o bloqueio sugerido pela Sucuri.net<\/em>\u00a0\u00e9 efetuado por meio de c\u00f3digo PHP<\/strong>. Ou seja, vai funcionar por\u00e9m exigir\u00e1 v\u00e1rios recursos do servidor para, por exemplo, bloquear um ataque DDoS<\/em>. Assim, se torna mais eficiente colocar este bloqueio diretamente no servidor web<\/em>.<\/p>\n
Com base nisso, apresento abaixo uma solu\u00e7\u00e3o mais eficiente, bloqueando as requisi\u00e7\u00f5es ao XMLRPC diretamente no servidor web<\/em>.<\/p>\n
Nginx
\n<\/strong>Adicionar a seguinte linha no arquivo de configura\u00e7\u00e3o do seu site:<\/p>\n
if ($request_uri ~ ^\/xmlrpc\\.php$) { return 403; }<\/pre>\n
 <\/p>\n
Ap\u00f3s adicionar, ser\u00e1 necess\u00e1rio reiniciar o Nginx<\/em>.<\/p>\n
Apache
\n<\/strong>Basta adicionar a seguinte regra ao seu .htaccess<\/em>:<\/p>\n
# Disables the access to XMLRPC file\n<files xmlrpc.php>\norder allow,deny\ndeny from all\n<\/files><\/pre>\n
 <\/p>\n
9. Outras medidas de seguran\u00e7a<\/h3>\n
Al\u00e9m das dicas anteriores, seguem algumas outras medidas de seguran\u00e7a que poderiam ser adotadas:<\/p>\n
    \n
  • Instalar um\u00a0plugin<\/em>\u00a0de seguran\u00e7a para evitar ataques de for\u00e7a bruta e\/ouDDoS<\/em><\/li>\n
  • Manter os softwares<\/em> do servidor atualizados<\/li>\n
  • Atualizar as senhas dos usu\u00e1rios esporadicamente<\/li>\n
  • Configurar um firewall<\/em><\/li>\n
  • Habilitar autentica\u00e7\u00e3o HTTP b\u00e1sica para acessar o wp-admin<\/em><\/li>\n<\/ul>\n
     <\/p>\n
    O que achou das dicas? Esse tutorial lhe ajudou de alguma forma? Se sim, tudo que pe\u00e7o \u00e9 que ajude a divulg\u00e1-lo. E n\u00e3o esque\u00e7a de compartilhar suas experi\u00eancias e dicas nos coment\u00e1rios, para incrementar ainda mais a troca de conhecimento por aqui.<\/p>\n","protected":false},"excerpt":{"rendered":"
    Dica de como aumentar a seguran\u00e7a do seu site ou blog feito em Wordpress. Esta postagem aborda 9 itens que podem fazer a diferen\u00e7a entre n\u00e3o virar estat\u00edstica de sites hackeados.<\/p>\n","protected":false},"author":1,"featured_media":3899,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6,25,30],"tags":[513,569,674],"class_list":["post-3892","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-dicas","category-seguranca","category-wordpress-2","tag-proteger-wordpress","tag-seguranca-wordpress","tag-wordpress-seguro"],"_links":{"self":[{"href":"https:\/\/www.turbosite.com.br\/blog\/wp-json\/wp\/v2\/posts\/3892","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.turbosite.com.br\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.turbosite.com.br\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.turbosite.com.br\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.turbosite.com.br\/blog\/wp-json\/wp\/v2\/comments?post=3892"}],"version-history":[{"count":0,"href":"https:\/\/www.turbosite.com.br\/blog\/wp-json\/wp\/v2\/posts\/3892\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.turbosite.com.br\/blog\/wp-json\/wp\/v2\/media\/3899"}],"wp:attachment":[{"href":"https:\/\/www.turbosite.com.br\/blog\/wp-json\/wp\/v2\/media?parent=3892"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.turbosite.com.br\/blog\/wp-json\/wp\/v2\/categories?post=3892"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.turbosite.com.br\/blog\/wp-json\/wp\/v2\/tags?post=3892"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}