Em resumo: Antes de reinstalar um servidor comprometido, preserve as provas pela ordem da sua volatilidade: primeiro processos, ligações e utilizadores com sessão iniciada, depois registos e configuração e, por fim, uma imagem completa do sistema e os dados dos serviços a montante. Cada cópia recebe uma soma de verificação e é guardada fora do servidor. Para isso, o servidor é desligado da rede, mas não é desligado da corrente.
O reflexo de reinstalar de imediato
Quem descobre uma intrusão quer pôr-lhe fim o mais depressa possível. Um sistema novo, instalado de raiz, com palavras-passe novas: dá a sensação de controlo. Do ponto de vista técnico, a reconstrução é muitas vezes também o caminho certo, sobretudo quando o atacante teve direitos de root.
O problema é o momento. Com o sistema antigo desaparecem todas as respostas às perguntas que surgem nos dias seguintes. Por que vulnerabilidade entrou o atacante? Desde quando estava no sistema? Teve acesso a dados de clientes? O servidor de base de dados ao lado também está afetado? Sem vestígios, restam apenas suposições, e estas não ajudam nem na proteção de dados nem no seguro.
Depois do PHP2Shell, acresce um ponto especial: não existem indicadores de comprometimento publicados e confirmados. Se um servidor foi afetado, e de que forma, só se pode deduzir do comportamento, ou seja, precisamente dos vestígios que uma reconstrução precipitada apaga. A imprensa especializada aconselha a conservar os registos do servidor a partir de 20/10/2026.
Preservação de provas no servidor: a ordem conta
Os vestígios têm diferentes graus de volatilidade. O que está na memória de trabalho desaparece no próximo reinício. Os registos duram mais, mas são rodados. Os dados em serviços a montante desaparecem de acordo com os prazos próprios desses serviços. Daí resulta a ordem:
| Vestígio | Volatilidade | Como preservar |
|---|---|---|
| Processos, ligações de rede, utilizadores com sessão iniciada | desaparece ao reiniciar | gravar em ficheiros as saídas dos comandos do sistema |
| Memória de trabalho | desaparece ao reiniciar | só com ferramenta especializada, tarefa para peritos forenses |
Ficheiros temporários em /tmp ou /dev/shm |
muitas vezes apagados ao reiniciar | copiar, sem executar |
| Registos do servidor web, do PHP e do sistema | são rodados | copiar por inteiro, suspender a rotação |
| Sistema de ficheiros e base de dados | estável até à reinstalação | snapshot ou imagem do suporte de dados, exportação da base de dados |
| CDN, WAF, firewall, alojamento | conservação segundo os prazos do fornecedor | pedir exportação, fazer confirmar por escrito |
A memória de trabalho só deve ser preservada se estiver disponível alguém com a ferramenta adequada e experiência. Em sistemas com dados sensíveis ou perante um litígio previsível, isso deve ficar a cargo de uma perícia informática forense.
Registar os dados voláteis em poucos minutos
Os comandos seguintes não alteram nada no sistema. Escrevem o estado atual em ficheiros que são depois guardados fora do servidor. Crie o diretório de destino, se possível, num suporte de dados separado e ligado ao servidor:
ZIEL=/mnt/sicherung/fall-$(date -u +%Y%m%dT%H%MZ)
mkdir -p "$ZIEL"
date -u > "$ZIEL/zeitpunkt-utc.txt"
ps auxwwf > "$ZIEL/prozesse.txt"
ss -tunap > "$ZIEL/verbindungen.txt"
who -a > "$ZIEL/angemeldet.txt"
last -F > "$ZIEL/anmeldungen.txt"
ip addr > "$ZIEL/netz.txt"; ip route >> "$ZIEL/netz.txt"
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done > "$ZIEL/cronjobs.txt"
sha256sum "$ZIEL"/* > "$ZIEL.sha256"
O guia Analisar os registos do servidor web após um ataque descreve como preservar e analisar depois os registos por inteiro. Em servidores virtuais, um snapshot através da gestão do fornecedor é o caminho mais simples para obter uma imagem completa. Capta o sistema sem que tenha de iniciar outras ferramentas no servidor comprometido.
Para que a cópia valha alguma coisa mais tarde
Uma cópia só vale o que valer a sua comprovação. Três regras tornam-na fiável:
- Somas de verificação: cada ficheiro preservado recebe uma soma de verificação SHA-256. Assim, é possível demonstrar mais tarde que a cópia está inalterada.
- Registo: quem preservou o quê, quando, com que comando e para onde? Cada entrega a terceiros fica registada. Os especialistas chamam a isto cadeia de custódia.
- Armazenamento separado: as cópias pertencem a um sistema a que o atacante não teve acesso e só voltam a ser utilizadas em modo de leitura.
Depois disso, trabalhe apenas com cópias. Qualquer análise no original altera datas e pode sobrescrever vestígios. Nunca execute ficheiros suspeitos e não os abra através do navegador.
Peça cedo os registos do CDN, do WAF e do fornecedor de alojamento. Estes dados estão fora do seu servidor e são difíceis de manipular por um atacante, mas muitas vezes só são conservados por pouco tempo.
O que destrói a situação probatória
Muitos vestígios perdem-se não por ação do atacante, mas por uma primeira ajuda bem-intencionada. Estes passos devem ser evitados antes da preservação:
- Reiniciar ou desligar: depois disso, os processos, as ligações e a memória de trabalho desaparecem.
- Antivírus com eliminação automática: remove ficheiros antes de alguém os ter preservado e altera datas.
- Limpar registos ou pastas temporárias: mesmo que o espaço escasseie, primeiro copiar, depois eliminar.
- Instalar no servidor novas ferramentas descarregadas da Internet: cada instalação escreve no sistema de ficheiros e pode encobrir vestígios.
- Iniciar sessão com credenciais privilegiadas sem necessidade: se ainda houver código malicioso a correr no servidor, as palavras-passe introduzidas podem ser lidas.
As seguradoras, em particular, perguntarão mais tarde o que foi preservado e quando. Encontra indicações sobre as obrigações típicas em Seguro de cibersegurança: o que conta em caso de sinistro.
Ponderar: de quanto tempo se dispõe para a preservação?
Nem todo o incidente permite uma preservação demorada. Se estiver em curso uma fuga de dados ou se os visitantes estiverem a ser atacados, a contenção tem prioridade. Desligar da rede com o sistema em funcionamento concilia as duas coisas: o atacante perde o acesso e os vestígios mantêm-se. Para a maioria dos servidores web, basta depois um período limitado para os dados voláteis e o snapshot.
Tome a decisão de forma consciente e registe-a: quem decidiu quando se reinstala, e o que foi preservado antes? Esta nota será mais tarde parte da cronologia do incidente. Se a reconstrução ou a limpeza é o caminho certo, é o que analisa o artigo Reinstalar o servidor ou limpá-lo?.
Como ajuda concretamente a PHP SOS?
- Preservamos dados voláteis, registos e imagens do sistema pela ordem certa, com somas de verificação e registo.
- Pedimos os dados dos serviços a montante antes de expirarem os respetivos prazos de conservação.
- Se necessário, assumimos, com parceiros especializados, a preservação e a análise forenses.
- Só depois reconstruímos o servidor, fechamos a porta de entrada e documentamos o incidente até ao seu encerramento.
Perguntas frequentes
Porque devo preservar provas antes de reinstalar?
Porque só os vestígios mostram como o atacante entrou, durante quanto tempo esteve no sistema e a que dados conseguiu aceder. Precisa destas respostas para a proteção de dados, para o seguro e para saber se há outros sistemas afetados. Depois da reconstrução, perdem-se.
O que é mais urgente na preservação?
Os dados voláteis, como processos em execução, ligações de rede e utilizadores com sessão iniciada, desaparecem ao desligar. Registam-se primeiro. Seguem-se os registos, uma imagem do sistema e os dados de serviços a montante.
Uma cópia de segurança normal serve como preservação de provas?
Na maioria dos casos, não. Muitas cópias de segurança não incluem registos, ficheiros de sistema nem metadados como datas e proprietários. Para a preservação de provas precisa de uma cópia completa e inalterada, com soma de verificação, idealmente um snapshot ou uma imagem do suporte de dados.
Posso desligar o servidor da rede antes de preservar?
Sim, desde que continue a funcionar. Cortar a ligação à rede impede a fuga de dados e o controlo remoto sem destruir vestígios voláteis. Já reiniciar ou desligar apaga a memória de trabalho e os processos em execução.