# Preservar provas antes de reinstalar o servidor

> Preservação de provas antes de reinstalar: que vestígios do servidor são voláteis, por que ordem os guardar e como manter a cópia de segurança fiável.

Fonte: https://phpsos.de/pt/blog/beweise-sichern-vor-neuinstallation/  
Atualizado em: 25/10/2026  
Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**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](https://phpsos.de/pt/leistungen/it-forensik/).

## 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:

```bash
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](https://phpsos.de/pt/ratgeber/logfiles-auswerten/) 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:

1. **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.
2. **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.
3. **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.

> **Importante:**
> 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](https://phpsos.de/pt/compliance/cyberversicherung/).

## 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](https://phpsos.de/pt/blog/zeitleiste-eines-vorfalls/). Se a reconstrução ou a limpeza é o caminho certo, é o que analisa o artigo [Reinstalar o servidor ou limpá-lo?](https://phpsos.de/pt/blog/neu-aufsetzen-oder-bereinigen/).

## 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.

## Fontes

- [BSI: indicações sobre incidentes de segurança informática](https://www.bsi.bund.de/)
- [RGPD, art. 33: notificação à autoridade de controlo](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [Polícia: pontos de contacto centrais para cibercrime](https://www.polizei.de/)