A segurança da sua instalação WordPress é tão forte ou fraca quanto as medidas que você implementar. Descubra as cinco ações cruciais para reforçar a sua proteção.
As preocupações sobre a segurança do WordPress são frequentes e antigas.
Se você busca um CMS e consulta fornecedores que não utilizam o WordPress, a segurança será o principal ponto negativo que você ouvirá. Isso significa que todos deveriam abandonar o WordPress em favor de geradores de sites estáticos ou um CMS headless?
Não, pois, como em qualquer assunto complexo, há vários ângulos a considerar.
O WordPress é realmente tão inseguro assim?
Observe alguns grandes sites construídos com WordPress:
- TechCrunch
- The New Yorker
- BBC America
- Bloomberg
- MTV News
- PlayStation Blog
Por que essas empresas, com recursos financeiros vastos e equipes enormes, continuam com o WordPress? Se você pensa que a razão é o código legado, repense: para essas organizações, a segurança de dados e a imagem pública são mais importantes do que uma migração que custaria (estimando) menos de US$200.000.
Certamente, seus engenheiros entendem o que fazem e não enxergam problemas de segurança graves e insolúveis no WordPress, correto?
Eu mesmo tenho o privilégio de gerenciar uma instalação WordPress que recebe entre 3,5 e 4 milhões de visitantes mensalmente. O número de violações de segurança nos últimos oito anos? Zero!
Então… o WordPress é seguro?
Peço desculpas se parece com uma provocação, mas aqui está a minha resposta:
A questão é complexa, como tudo na vida. Para obter uma resposta sensata, precisamos entender que o WordPress (ou qualquer CMS pré-construído) não é como um armário que se instala e esquece.
É um software intricado com diversas dependências:
- PHP, a linguagem na qual é construído
- Um servidor publicamente acessível que hospeda a instalação
- O servidor web que lida com os visitantes (Apache, Nginx, etc.)
- O banco de dados utilizado (MySQL/MariaDB)
- Temas (conjuntos de arquivos PHP, CSS e JS)
- Plugins (conjuntos de arquivos PHP, CSS e JS)
- E mais, dependendo do que sua instalação precisa executar
Ou seja, uma falha de segurança em qualquer um desses elementos será atribuída ao WordPress.
Se a senha root do servidor era admin123 e foi comprometida, é uma falha de segurança do WordPress?
Se a versão do PHP possuía uma vulnerabilidade, ou se o plugin recém-adquirido continha uma falha grave de segurança; e assim por diante. Em resumo: se um subsistema falha, é uma falha de segurança do WordPress.
Aproveitando o parêntese, não deixe que isso transmita a ideia de que PHP, MySQL e Apache são inseguros. Todo software tem vulnerabilidades, o que é comum no código aberto (disponível para todos analisarem).
Alguém disse “seguro”? 😛
O que concluímos com essa análise é que:
Nada é inerentemente seguro ou inseguro. São os componentes utilizados que formam os elos de uma corrente, cuja força é determinada pelo seu elo mais fraco. Historicamente, a fama de “inseguro” do WordPress vinha da combinação de versões antigas do PHP, hospedagem compartilhada e instalação de plugins/temas de fontes duvidosas.
Ao mesmo tempo, alguns descuidos comuns tornam a instalação do WordPress vulnerável para quem sabe como explorá-los. É disso que trata este artigo. Então, sem mais delongas (e digressões), vamos começar.
Principais brechas do WordPress que os hackers podem explorar
O prefixo da tabela do WordPress
A famosa instalação em 5 minutos é uma maravilha do WordPress, mas como todos os assistentes de instalação, nos torna preguiçosos e nos faz usar as configurações padrão.
Isso significa que o prefixo padrão das suas tabelas do WordPress é wp_, resultando em nomes de tabelas previsíveis:
- wp_users
- wp_options
- wp_posts
Agora, considere um ataque conhecido como SQL Injection, onde consultas de banco de dados maliciosas são inseridas e executadas no WordPress (note que isso não é um ataque exclusivo do WordPress/PHP).
Embora o WordPress possua mecanismos para lidar com esses ataques, não há garantias de que não ocorrerão.
Portanto, se um invasor conseguir executar uma consulta como DROP TABLE wp_users; DROP TABLE wp_posts;, todas as suas contas, perfis e posts serão apagados instantaneamente, sem possibilidade de recuperação (a menos que você tenha um sistema de backup, e mesmo assim, perderá dados desde o último backup).
A simples alteração do prefixo durante a instalação é uma medida de grande impacto (e sem esforço).
Algo aleatório como sdg21g34_ é recomendado, pois não tem significado e é difícil de adivinhar (quanto maior o prefixo, melhor). O melhor é que esse prefixo não precisa ser memorável; o WordPress o armazenará e você não precisará mais se preocupar com ele (assim como não se preocupa com o prefixo padrão wp_!).
O URL de login padrão
Como sabemos que um site usa WordPress? Um dos sinais é a página de login do WordPress ao adicionar “/wp-login.php” ao endereço do site.
Como exemplo, usemos meu site (http://ankushthakur.com). É WordPress? Tente adicionar a parte de login. Se estiver com preguiça, veja o que acontece:
¯\_(ツ)_/¯
WordPress, certo?
Ao descobrir isso, o invasor pode esfregar as mãos de alegria e começar a aplicar suas táticas maliciosas em ordem alfabética. Que azar!
A solução é alterar o URL de login padrão e fornecê-lo apenas para pessoas de confiança.
Por exemplo, este site também usa WordPress, mas se você visitar http://etechpt.com.com/wp-login.php, terá uma grande decepção. O URL de login está oculto e é conhecido apenas pelos administradores.
Alterar o URL de login não é complicado. Basta usar este plugin.
Parabéns, você adicionou mais uma camada de proteção contra ataques de força bruta.
A versão do PHP e do servidor web
Já discutimos que todo software (já criado e em desenvolvimento) está cheio de falhas esperando para serem exploradas.
O mesmo vale para o PHP.
Mesmo com a versão mais recente do PHP, não há garantia de quais vulnerabilidades existem ou podem surgir. A solução é ocultar um cabeçalho específico enviado pelo seu servidor web (nunca ouviu falar de cabeçalhos? leia isto!) quando um navegador se conecta: x-powered-by.
Veja como ele aparece nas ferramentas de desenvolvedor do seu navegador:
Aqui, vemos que o site revela que usa Apache 2.4 e PHP versão 5.4.16.
Isso já é muita informação desnecessária, que ajuda o invasor a restringir suas ferramentas.
Esses cabeçalhos (e similares) precisam ser ocultados.
Felizmente, isso é rápido; infelizmente, é preciso um conhecimento técnico apurado, pois você precisará mexer em arquivos do sistema. Recomendo pedir ao seu provedor de hospedagem que faça isso por você. Se eles não puderem, um consultor pode ajudar, mas isso depende da configuração do seu provedor.
Se não funcionar, talvez seja hora de trocar de provedor ou migrar para um VPS e contratar um consultor para questões de segurança e administração.
Vale a pena? Só você pode decidir. 🙂
Se quiser saber mais sobre cabeçalhos de segurança, veja isto!
Número de tentativas de login
Um truque antigo do manual do hacker é o chamado Ataque de Dicionário.
A ideia é testar um grande número (milhões, se possível) de combinações de senha, até encontrar uma válida. Como os computadores são rápidos, esse método pode produzir resultados em tempo razoável.
Uma defesa comum e eficaz é adicionar um atraso antes de exibir o erro. Isso faz o usuário esperar, o que significa que, se for um script de um hacker, levará mais tempo. Por isso, seu aplicativo favorito dá um salto e diz “Senha incorreta!”.
O importante é limitar o número de tentativas de login no seu site WordPress.
Após um número definido de tentativas (por exemplo, cinco), a conta deve ser bloqueada e recuperada apenas pelo e-mail do titular.
Felizmente, isso é fácil com um bom plugin.
HTTP x HTTPS
O certificado SSL que seu provedor insiste em que você utilize é mais importante do que parece.
Não é só um selo para exibir o cadeado verde que diz “Seguro”; instalar um certificado SSL e forçar todos os URLs a usarem “https” transforma seu site de um livro aberto em um texto criptografado.
Se você não entende por que, pesquise sobre o ataque man-in-the-middle.
Outra forma de interceptar o tráfego que vai do seu computador ao servidor é o packet sniffing, que coleta dados passivamente e nem precisa estar “no meio”.
Em sites que usam apenas “HTTP”, a pessoa que intercepta o tráfego verá suas senhas e números de cartão de crédito em texto simples.
Fonte: comparatech.com
Assustador? Muito!
Mas após instalar um certificado SSL e usar “https” em todos os URLs, essas informações confidenciais se tornam dados sem sentido que apenas o servidor pode decifrar. Não economize esses poucos dólares por ano! 🙂
Conclusão
Controlar esses cinco pontos tornará seu site seguro?
Não, de forma alguma. Como muitos artigos de segurança dizem, nunca se está 100% seguro, mas é possível eliminar uma grande parte dos problemas com um esforço razoável. Você pode considerar o uso do SUCURI cloud WAF para proteger seus sites de forma abrangente.