Em resumo: mudar de CMS depois de um ataque só ajuda se o sistema antigo tiver sido a própria causa, por exemplo porque o fabricante já não fornece atualizações de segurança ou extensões importantes deixaram de ser mantidas. Se a causa estava em plugins desatualizados, acessos fracos ou numa vulnerabilidade como o PHP2Shell no PHP subjacente, uma mudança apenas desloca o esforço. Em qualquer caso vale: primeiro verificar os conteúdos, depois migrar, caso contrário o código malicioso migra também.
Quando a confiança desaparece
Depois de uma intrusão, o estado de espírito é muitas vezes inequívoco: «Com este sistema, nunca mais.» É compreensível. O site redirecionou visitantes para páginas alheias, a Google avisou, os clientes perguntaram. Um novo CMS parece um recomeço.
A situação em torno do PHP2Shell mostra, porém, porque é que este reflexo pode induzir em erro. A vulnerabilidade está no interpretador PHP, não no WordPress, no TYPO3, no Shopware ou noutro sistema. Segundo o drweb.de, o WordPress.org não planeia por isso uma atualização própria contra ela. Quem agora passa de um CMS em PHP para outro CMS em PHP acaba com a mesma dependência, apenas com outro logótipo. Que sistemas correm em PHP, mostra-o a visão geral Que CMS e sistemas de loja correm em PHP.
É a causa que decide
Antes de pensar numa mudança, a causa da intrusão tem de estar esclarecida. As portas de entrada típicas são extensões desatualizadas, palavras-passe reutilizadas ou fracas, falta de autenticação de dois fatores, um servidor sem patch ou instalações de teste esquecidas. Nenhuma destas causas está ligada a um CMS em particular.
Quem não conhece a causa arrisca-se a levá-la para o novo sistema. Uma equipa que até agora adiou as atualizações fará o mesmo no novo CMS. Uma agência que usava contas de administrador partilhadas repetirá isso, se ninguém alterar o procedimento. A pergunta é, pois, menos «que CMS?» e mais «que processo?».
Mudar de CMS depois do ataque: a ponderação
| Critério | Manter o CMS atual e fazer hardening | Mudar para outro CMS |
|---|---|---|
| Causa da intrusão | Conhecida e corrigível, por exemplo um plugin desatualizado | Está no próprio sistema, por exemplo falta de atualizações do fabricante |
| Manutenção pelo fabricante | As atualizações de segurança são fornecidas | O fabricante deixou de fazer a manutenção |
| Dependência de extensões | Poucas extensões, mantidas | Muitas extensões sem manutenção ativa |
| Esforço | Limpeza, hardening, alteração do processo | Reconstrução, migração, formação, muitas vezes novo design |
| Tempo até um site seguro | Mais curto | Mais longo, é necessária uma solução provisória |
| Proteção contra vulnerabilidades do PHP | Sem alteração, o PHP tem de receber o patch | Sem alteração, enquanto o novo sistema usar PHP |
| Benefício a longo prazo | Elevado, se os processos forem melhorados | Elevado, se o sistema antigo já estava de qualquer modo no fim |
Se a maioria das linhas na sua situação ficar à esquerda, a mudança dificilmente compensa. Ficar, limpar, fazer hardening e melhorar o procedimento de manutenção traz mais segurança por menos dinheiro. Para os operadores de WordPress, WordPress e PHP2Shell resume os passos mais importantes.
Nem sempre precisa de um prestador de serviços para esta decisão. Se a causa foi inequívoca, por exemplo um plugin conhecido com vulnerabilidade publicada, e a sua agência ou o seu administrador reconstruiu o site de forma limpa, pode decidir por si. A ajuda externa compensa quando a causa permanece pouco clara ou dados pessoais possam estar afetados.
Se mudar: não leve o código malicioso consigo
Se a decisão for mudar, a própria migração é um risco de segurança. Os atacantes deixam vestígios não só nos ficheiros, mas também na base de dados. Estes passos ajudam a migrar de forma limpa:
- Preservar e isolar o sistema antigo: cópia de segurança completa como prova, depois retirar o sistema antigo da rede ou torná-lo acessível apenas internamente.
- Exportar os conteúdos de forma direcionada: textos, estrutura de páginas e multimédia, não a base de dados completa. Não migrar as contas de utilizador, mas criá-las de novo.
- Verificar os conteúdos: examinar os textos quanto a scripts introduzidos, ligações escondidas e redirecionamentos alheios. Como fazê-lo, descreve-o Verificar a base de dados quanto a código introduzido.
- Filtrar o multimédia: aceitar apenas os tipos de ficheiro esperados, separar ficheiros com extensões duplas ou conteúdo de script.
- Montar o novo sistema de forma limpa: a partir da fonte original do fabricante, num servidor com PHP com patch, com credenciais novas e autenticação de dois fatores.
- Planear os redirecionamentos: redirecionar os endereços antigos para os novos, para que motores de pesquisa e visitantes cheguem ao destino, sem que caminhos antigos fiquem abertos.
Uma mudança de CMS não substitui a limpeza do servidor antigo. Se o sistema antigo continuar a funcionar, por exemplo como cópia esquecida num subdomínio, a porta dos fundos permanece aberta.
A alternativa que muitas vezes passa despercebida
Algumas empresas verificam, após um ataque, que nem sequer precisam das funções de um grande CMS. Um site de empresa com poucas páginas, raramente alteradas, dispensa também o PHP no servidor. Um gerador de páginas estáticas produz ficheiros HTML prontos, que já não precisam de lógica de programa do lado do servidor. Que vantagens e desvantagens isso tem, descreve-o Sites estáticos: menos PHP, menos superfície de ataque.
Inversamente, isso não é em regra uma opção para lojas, portais ou sites com muitos editores. Aqui continua a fazer sentido um sistema dinâmico, e a segurança nasce da manutenção, do hardening e da vigilância.
Quem tem dúvidas sobre se no antigo WordPress ainda se escondem acessos ocultos encontra em Encontrar backdoors no WordPress os locais típicos de descoberta. Isso ajuda também a decidir se uma limpeza é realista.
Como ajuda concretamente a PHP SOS?
- Esclarecemos primeiro a causa da intrusão e dizemos-lhe se está no CMS ou no processo e no servidor.
- Limpamos o sistema existente no âmbito da remoção de malware ou preparamo-lo como prova para uma reconstrução.
- Numa mudança, verificamos os conteúdos e o multimédia a migrar quanto a código malicioso antes de chegarem ao novo sistema.
- Montamos o novo servidor com PHP com patch e configuração com hardening.
Conclusão
Uma mudança de CMS após um ataque raramente é a solução, mas por vezes é a ocasião certa. Se o sistema antigo já não é mantido, o recomeço compensa. Se a causa estava nos processos ou no servidor, o trabalho no processo traz mais do que um logótipo novo. Em ambos os casos vale: primeiro verificar, depois migrar.
Perguntas frequentes
Mudar de CMS ajuda contra o PHP2Shell?
Não, desde que o novo CMS também corra em PHP. O PHP2Shell está no interpretador PHP, não no CMS. O decisivo é o estado do patch do PHP no servidor, não o sistema que está por cima.
O WordPress é menos seguro do que outros CMS?
Não se pode dizer em termos gerais. Muitas intrusões nascem de extensões desatualizadas, acessos fracos ou falta de atualizações, e estas causas existem em qualquer sistema. A difusão torna, porém, um CMS um alvo mais frequente de análises automatizadas.
Posso simplesmente exportar os conteúdos do CMS invadido?
Só depois de verificar. A base de dados pode conter scripts introduzidos, ligações escondidas ou contas de administrador alheias. Os ficheiros carregados podem camuflar código malicioso. Exporte os conteúdos de forma direcionada e verifique-os antes da importação.
Quando é que uma mudança de CMS faz mesmo sentido?
Quando o fabricante já não fornece atualizações de segurança, quando o site depende de extensões que já não são mantidas ou quando o sistema simplesmente já não se adequa aos requisitos de hoje. O ataque é então a ocasião, não o motivo.