Sua instalação do WordPress pode ser tão segura ou insegura quanto você quiser. Saiba quais são as cinco coisas mais importantes quando se trata de segurança.
Preocupações e reclamações sobre a segurança do WordPress não são novidade.
Se você precisar de um CMS e por acaso consultar um provedor de serviços que não esteja no WordPress, a segurança é o golpe número um sobre o qual você ouvirá falar. Isso significa que todos deveriam largar o WordPress e mudar para geradores de sites estáticos ou um CMS headless?
Não, porque assim como toda verdade na vida, esta também tem muitos lados.
últimas postagens
O WordPress é altamente inseguro?
Vamos dar uma olhada em alguns sites enormes que foram construídos no WordPress:
- TechCrunch
- O Nova-iorquino
- BBC América
- Bloomberg
- Notícias da MTV
- PlayStationBlog
Então, o que faz com que essas empresas – com bolsos absurdamente profundos e uma força de trabalho incompreensível – não mudem do WordPress? Se você acha que a resposta é código legado, pense novamente: para esses nomes, segurança de dados e imagem pública são infinitamente mais importantes do que uma simples migração que custará (estou estimando) menos de US$ 200.000.
Certamente seus engenheiros sabem o que estão fazendo e não veem problemas de segurança fundamentais e insolúveis com o WordPress?
Até eu tenho a sorte de gerenciar uma instalação do WordPress que recebe de 3,5 a 4 milhões de visitantes por mês. O número total de violações de segurança nos últimos oito anos? Zero!
Então . . . O WordPress é seguro?
Desculpe se parece trollagem, mas aqui está minha resposta:
Digo isso porque, como toda verdade na vida, é complicada. Para chegar a uma resposta legítima, devemos primeiro entender que o WordPress (ou qualquer CMS pré-construído) não é como um armário que você coloca em algum lugar permanentemente e pronto.
É um software complexo com muitas dependências:
- PHP, que é a linguagem com a qual é construído
- Uma máquina publicamente visível que hospeda a instalação
- O servidor web usado para lidar com os visitantes (Apache, Nginx, etc.)
- O banco de dados que está sendo usado (MySQL/MariaDB)
- Temas (pacotes de arquivos PHP, CS e JS)
- Plugins (pacotes de arquivos PHP, CS e JS)
- E muito mais, dependendo de quanto sua instalação pretende realizar
Em outras palavras, uma violação de segurança em qualquer uma dessas costuras será chamada de violação do WordPress.
Se a senha root do servidor foi admin123 e foi comprometida, é uma falha de segurança do WordPress?
Se a versão do PHP tinha uma vulnerabilidade de segurança, ou se o novo plugin que você comprou e instalou continha uma falha de segurança gritante; e assim por diante. Para resumir: um subsistema falha e é uma falha de segurança do WordPress.
Como um aparte, por favor, também não deixe que isso lhe dê a impressão de que PHP, MySQL e Apache não são seguros. Todo software tem vulnerabilidades, cuja contagem é impressionante no caso de código aberto (porque está disponível para todos verem e analisarem).
Alguém disse “seguro”? 😛
O que aprendemos com todo esse exercício é o seguinte:
Nada é seguro ou inseguro por si só. São os diferentes componentes usados que formam os elos da cadeia, a cadeia, é claro, sendo tão forte quanto o mais fraco deles. Historicamente, o rótulo “não seguro” do WordPress era uma combinação de versões antigas do PHP, hospedagem compartilhada e adição de plugins/temas de fontes não confiáveis.
Ao mesmo tempo, alguns descuidos bastante comuns tornam sua instalação do WordPress vulnerável para aqueles que sabem como explorá-los e são determinados. E é disso que trata este post. Então, sem mais delongas (e argumentos circulares), 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 é a melhor coisa que aconteceu com o WordPress, mas como todos os assistentes de instalação, nos deixa preguiçosos e deixa as coisas no padrão.
Isso significa que o prefixo padrão para suas tabelas do WordPress é wp_, resultando em nomes de tabelas que qualquer um pode adivinhar:
- wp-users
- wp-options
- wp-posts
Agora, considere um ataque conhecido como SQL Injection, onde consultas de banco de dados maliciosas são habilmente inseridas e executadas dentro do WordPress (observe – isso não é de forma alguma um ataque exclusivo do WordPress/PHP).
Embora o WordPress tenha mecanismos integrados para lidar com esses tipos de ataques, ninguém pode garantir que isso não aconteça.
Então, se de alguma forma, o invasor conseguir executar uma consulta como DROP TABLE wp_users; DROP TABLE wp_posts;, todas as suas contas, perfis e postagens serão apagadas em um instante sem chance de recuperação (a menos que você tenha um esquema de backup em vigor, mas mesmo assim, você perderá dados desde o último backup ).
Simplesmente alterar o prefixo durante a instalação é um grande problema (que não exige esforço).
Algo aleatório como sdg21g34_ é recomendado porque não faz sentido e é difícil de adivinhar (quanto maior o prefixo, melhor). A melhor parte é que esse prefixo não precisa ser memorável; o prefixo é algo que o WordPress salvará, e você nunca mais terá que se preocupar com isso (assim como você não se preocupa com o prefixo wp_ padrão!).
O URL de login padrão
Como você sabe que um site está sendo executado no WordPress? Um dos sinais indicadores é que você vê a página de login do WordPress quando adiciona “/wp-login.php” ao endereço do site.
Como exemplo, vamos pegar meu site (http://ankushthakur.com). É no WordPress? Bem, vá em frente e adicione a parte de login. Se você está se sentindo muito preguiçoso, aqui está o que acontece:
¯_(ツ)_/¯
WordPress, certo?
Uma vez que isso seja conhecido, o atacante pode esfregar as mãos de alegria e começar a aplicar truques desagradáveis de seu Bag-O’-Doom em ordem alfabética. Pobre de mim!
A solução é alterar o URL de login padrão e fornecê-lo apenas para as pessoas confiáveis.
Por exemplo, este site também está no WordPress, mas se você visitar http://etechpt.com.com/wp-login.php, tudo que você terá é uma profunda decepção. O URL de login está oculto e é conhecido apenas pelos administradores?
Alterar o URL de login também não é ciência do foguete. Apenas pegue isso plugar.
Parabéns, você acabou de adicionar outra camada de segurança frustrante contra ataques de força bruta.
A versão do PHP e do servidor web
Já discutimos que todo software já escrito (e sendo escrito) está cheio de bugs esperando para serem explorados.
O mesmo vale para o PHP.
Mesmo se você estiver usando a versão mais recente do PHP, não poderá ter certeza de quais vulnerabilidades existem e podem ser descobertas da noite para o dia. 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 a ele: x-powered-by.
Veja como fica se você verificar as ferramentas de desenvolvimento do seu navegador favorito:
Como podemos ver aqui, o site está nos dizendo que está rodando no Apache 2.4 e usando o PHP versão 5.4.16.
Agora, isso já é uma tonelada de informações que estamos passando sem motivo, ajudando o invasor a restringir sua escolha de ferramentas.
Esses cabeçalhos (e similares) precisam ser ocultados.
Felizmente, isso pode ser feito rapidamente; infelizmente, é necessário um conhecimento técnico sofisticado, pois você precisará mergulhar nas entranhas do sistema e mexer em arquivos importantes. Portanto, meu conselho é pedir ao seu provedor de hospedagem de sites para fazer isso por você; se eles não virem se um consultor pode fazê-lo, embora isso dependa em grande parte do host do seu site, se a configuração deles tem essas possibilidades ou não.
Se não funcionar, talvez seja hora de mudar de provedor de hospedagem ou mudar para um VPS e contratar um consultor para questões de segurança e administração.
Vale a pena? Só você pode decidir isso. 🙂
Ah, e se você quiser nerd nos cabeçalhos de segurança, aqui está a solução!
Número de tentativas de login
Um dos truques mais antigos do manual do hacker é o chamado Ataque de dicionário.
A ideia é que você tente um número ridiculamente grande (milhões, se possível) de combinações para uma senha, a menos que uma delas seja bem-sucedida. Como os computadores são extremamente rápidos no que fazem, um esquema tão tolo é sensato e pode produzir resultados em um tempo razoável.
Uma defesa comum (e extremamente eficaz) tem sido adicionar um atraso antes de mostrar o erro. Isso faz com que o destinatário espere, o que significa que se for um script empregado por um hacker, levará muito tempo para ser concluído. Essa é a razão pela qual seu computador ou aplicativo favorito salta um pouco e depois diz: “Opa, a senha errada!”.
De qualquer forma, o ponto é que você deve limitar o número de tentativas de login para o seu site WordPress.
Além de um número definido de tentativas (digamos, cinco), a conta deve ser bloqueada e deve ser recuperada apenas pelo e-mail do titular da conta.
Felizmente, fazer isso é uma moleza se você se deparar com um bom plugar.
HTTP x HTTPS
O certificado SSL com o qual seu fornecedor está incomodando você é mais importante do que você imagina.
Não é apenas uma ferramenta de reputação para mostrar um ícone de cadeado verde no navegador que diz “Seguro”; em vez disso, instalar um certificado SSL e forçar todos os URLs a funcionar em “https” é o suficiente para transformar seu site de um livro aberto em um pergaminho enigmático.
Se você não entende como isso acontece, por favor leia sobre algo conhecido como ataque man-in-the-middle.
Outra maneira de interceptar o tráfego que flui do seu computador para o servidor é o packet sniffing, que é uma forma passiva de coleta de dados e nem precisa se esforçar para se posicionar no meio.
Para sites que rodam em “HTTP” simples, a pessoa que intercepta o tráfego de rede, suas senhas e números de cartão de crédito aparecem em texto simples e claro.
Fonte: comparatech.com
Apavorante? Muito!
Mas depois que você instala um certificado SSL e todos os URLs são convertidos em “https”, essas informações confidenciais aparecem como sem sentido que apenas o servidor pode descriptografar. Em outras palavras, não gaste esses poucos dólares por ano. 🙂
Conclusão
Será que essas cinco coisas sob controle protegerão bem seu site?
Não, de jeito nenhum. Como dizem inúmeros artigos de segurança, você nunca está 100% seguro, mas é possível eliminar uma grande classe desses problemas com um esforço razoável. Você pode considerar usar o SUCURI cloud WAF para proteger seus sites de forma holística.