Em resumo: se deve reinstalar ou limpar um servidor após um ataque depende do grau de certeza com que conhece a extensão da intrusão. Se o atacante possa ter tido direitos de root, o momento da intrusão for incerto ou faltarem registos, uma reconstrução a partir de fontes de confiança é a escolha mais fiável. Uma limpeza só é admissível numa infeção estritamente delimitada e bem comprovada. Em ambos os casos vale: primeiro preservar as provas e fechar a vulnerabilidade, só depois arrumar.
Porque é que esta pergunta é tão frequente após o PHP2Shell
Segundo o php.net, o PHP2Shell permite a execução remota de código malicioso sem autenticação. Quem operou um servidor sem patch tem por isso de perguntar-se se, desde 17/10/2026, a data da primeira tentativa de ataque observada segundo notícias dos media, aconteceu alguma coisa. O patch não responde a esta pergunta, e não existem Indicators of Compromise publicados e confirmados.
Se depois se encontra um ficheiro suspeito, um processo desconhecido ou um cronjob alheio, é preciso decidir. O impulso é muitas vezes apagar depressa ou reinstalar de imediato. Ambos podem estar certos, mas não como primeiro passo.
A ordem antes da decisão
Antes de escolher entre limpar e reinstalar, há três coisas a tratar. Aplicam-se aos dois caminhos.
- Conter: retirar o servidor da rede ou limitar o acesso ao estritamente necessário, sem o desligar, se ainda se quiser preservar a memória.
- Preservar as provas: guardar registos, ficheiros, base de dados e, se possível, uma imagem do sistema, com data e soma de verificação. Porque isto é necessário antes de qualquer reinstalação, explica-o Preservar as provas antes de reinstalar.
- Envolver a seguradora e a proteção de dados: muitas apólices de ciberseguro esperam que os passos essenciais sejam coordenados. Indicações estão em Ciberseguro: o que conta em caso de sinistro. Se existe uma obrigação de notificação nos termos do RGPD, avaliam-no os encarregados da proteção de dados ou um advogado.
Só depois compensa a ponderação propriamente dita.
Reinstalar o servidor após um ataque ou limpar: os critérios
| Critério | Limpar | Reinstalar |
|---|---|---|
| Extensão da intrusão | Estritamente delimitada, comprovada, por exemplo um ficheiro na pasta de uploads sem outros vestígios | Incerta ou com indícios de acesso ao sistema |
| Possíveis direitos de root do atacante | Excluídos com boas provas | Não excluíveis |
| Disponibilidade de registos | Completos para o período relevante | Lacunares, sobrescritos ou manipuláveis |
| Esforço | Menor, se a constatação for clara | Maior, mas mais fácil de planear |
| Incerteza remanescente | Maior, é difícil excluir portas dos fundos escondidas | Menor, se construído de forma limpa a partir de fontes de confiança |
| Tempo de paralisação | Em regra mais curto | Em regra mais longo, bem controlável com preparação |
| Adequação a sistemas antigos | Problemático, se o sistema já estiver desatualizado | Boa oportunidade para mudar para uma versão do PHP suportada |
Como regra prática: quanto menos souber, mais pesa a favor da reconstrução. Numa vulnerabilidade do interpretador PHP que executa código no contexto do utilizador do servidor web, um atacante pode usar outras vulnerabilidades para obter mais direitos. Isto dificilmente se pode excluir sem uma investigação a fundo.
Os dois caminhos na prática
O que «reinstalar» realmente significa
Reinstalar não significa copiar a cópia de segurança antiga para um servidor novo. Uma reconstrução começa com um sistema operativo limpo de fonte oficial, pacotes atuais e uma versão do PHP com patch. A aplicação é instalada a partir do original do fabricante, tal como plugins e temas.
Só então entram os conteúdos próprios, e verificados. Os ficheiros carregados não podem conter scripts executáveis, a base de dados pode conter conteúdos introduzidos, por exemplo contas de administrador escondidas ou scripts em artigos. Os ficheiros de configuração são reescritos em vez de copiados. Todas as credenciais são renovadas: base de dados, administradores do CMS, chaves SSH, chaves de API, painel de alojamento.
As cópias de segurança desempenham aqui um papel importante, mas só se o seu estado for anterior à intrusão e elas próprias não tiverem sido alteradas. Várias gerações em locais separados tornam isso verificável; mais sobre isto em Cópias de segurança segundo a regra 3-2-1.
Quando a limpeza é defensável
Uma limpeza pode fazer sentido se a infeção foi descoberta cedo, existem registos completos e a investigação não aponta para outros acessos. Então os ficheiros encontrados são removidos depois de preservados, cronjobs, contas de utilizador e chaves SSH são verificados e os ficheiros do núcleo são comparados com o original do fabricante.
É importante uma avaliação realista: as webshells são muitas vezes discretas e escondidas em vários locais. Como encontrá-las, descreve-o Reconhecer e remover webshells. Depois de uma limpeza, o servidor deve ser observado de perto, para que uma porta dos fundos esquecida seja notada.
Não apague nada antes de os registos e os ficheiros estarem preservados e feche a vulnerabilidade antes de o servidor voltar à rede. Caso contrário, perde os vestígios e convida a próxima intrusão.
Quando não precisa de um prestador de serviços
Num site simples em alojamento partilhado, em que o fornecedor gere o sistema e confirma o patch do PHP, a decisão muitas vezes nem está nas suas mãos. Pode reinstalar a aplicação a partir do original, verificar os conteúdos e renovar as credenciais, com o apoio do fornecedor de alojamento. Também uma equipa interna experiente pode assumir sozinha uma reconstrução, se a preservação de provas e a documentação estiverem asseguradas.
A ajuda externa compensa quando não se podem excluir direitos de root, dados pessoais possam estar afetados, a seguradora esteja envolvida ou vários sistemas estejam interligados.
Como ajuda concretamente a PHP SOS?
- Preservamos registos, ficheiros e base de dados com valor probatório antes de alterar o que quer que seja.
- Avaliamos a extensão da intrusão e recomendamos limpar ou reconstruir, com fundamentação, separando o comprovado, o provável e o desconhecido.
- Reconstruímos o servidor, se necessário, a partir de fontes de confiança, com versão do PHP com patch e acessos renovados.
- Assumimos a remoção de malware onde uma limpeza é defensável e documentamos cada passo.
Conclusão
A pergunta «reinstalar ou limpar?» responde-se através do conhecimento da intrusão. Quem não conhece a extensão com segurança reconstrói. Quem a consegue delimitar com boas provas pode limpar. Em ambos os casos vale a mesma ordem: conter, preservar, fechar a vulnerabilidade, depois arrumar.
Perguntas frequentes
Reinstalar é sempre melhor após um ataque?
Nem sempre, mas muitas vezes. Se não é claro até onde o atacante chegou, uma reconstrução a partir de fontes de confiança é em regra a escolha mais fiável. Numa infeção estritamente delimitada e bem comprovada, uma limpeza pode bastar.
Posso simplesmente restaurar uma cópia de segurança antiga?
Só se for seguro que a cópia foi feita antes da intrusão e não contém nenhuma porta dos fundos. Além disso, a vulnerabilidade tem de estar fechada antes, caso contrário o servidor volta a ser imediatamente atacável. Os dados mais recentes têm de ser verificados em separado.
O que devo preservar antes de reinstalar?
Registos, uma cópia dos ficheiros e da base de dados e, se possível, uma imagem do sistema. Precisa destas provas para a análise de causas, o seguro e uma possível notificação. Depois de apagadas, desaparecem.
Basta apagar a webshell encontrada?
Raramente. Os atacantes criam muitas vezes várias portas dos fundos, por exemplo cronjobs, contas de utilizador ou chaves SSH. Quem só apaga o ficheiro visível deixa os outros acessos abertos.