# Beweise sichern, bevor Sie den Server neu aufsetzen

> Beweissicherung vor der Neuinstallation: Welche Spuren am Server flüchtig sind, in welcher Reihenfolge Sie sichern und wie die Sicherung belastbar bleibt.

Quelle: https://phpsos.de/blog/beweise-sichern-vor-neuinstallation/  
Stand: 25.10.2026  
Anbieter: PHP SOS, PHP-Notfallhilfe und Server-Sicherheit. Soforthilfe per WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wir%20brauchen%20Hilfe%20mit%20unserem%20PHP-Server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kurz gesagt:** Bevor Sie einen kompromittierten Server neu aufsetzen, sichern Sie die Beweise in der Reihenfolge ihrer Flüchtigkeit: zuerst Prozesse, Verbindungen und angemeldete Benutzer, dann Logs und Konfiguration, dann ein vollständiges Abbild des Systems und die Daten vorgelagerter Dienste. Jede Sicherung erhält eine Prüfsumme und wird außerhalb des Servers abgelegt. Der Server wird dafür vom Netz getrennt, aber nicht ausgeschaltet.

## Der Reflex, sofort neu aufzusetzen

Wer einen Einbruch entdeckt, will ihn so schnell wie möglich beenden. Ein frisches System, sauber installiert, mit neuen Passwörtern: Das fühlt sich nach Kontrolle an. Technisch ist ein Neuaufbau oft auch der richtige Weg, besonders wenn ein Angreifer Root-Rechte hatte.

Das Problem ist der Zeitpunkt. Mit dem alten System verschwinden alle Antworten auf die Fragen, die in den Tagen danach kommen. Über welche Lücke kam der Angreifer? Seit wann war er im System? Hatte er Zugriff auf Kundendaten? Ist der Datenbankserver nebenan auch betroffen? Ohne Spuren bleiben nur Vermutungen, und die helfen weder beim Datenschutz noch bei der Versicherung.

Nach PHP2Shell kommt ein besonderer Punkt dazu: Es gibt keine veröffentlichten, bestätigten Indicators of Compromise. Ob und wie ein Server betroffen war, lässt sich nur aus dem Verhalten ablesen, also aus genau den Spuren, die ein vorschneller Neuaufbau löscht. Die Fachpresse rät, Server-Logs ab dem 20.10.2026 aufzubewahren.

## Beweissicherung am Server: Die Reihenfolge zählt

Spuren sind unterschiedlich flüchtig. Was im Arbeitsspeicher steht, ist mit dem nächsten Neustart weg. Logs überleben länger, werden aber rotiert. Daten auf vorgelagerten Diensten verschwinden nach deren eigenen Fristen. Daraus ergibt sich die Reihenfolge:

| Spur | Flüchtigkeit | Wie sichern |
|---|---|---|
| Prozesse, Netzwerkverbindungen, angemeldete Benutzer | verschwindet bei Neustart | Ausgaben der Systembefehle in Dateien schreiben |
| Arbeitsspeicher | verschwindet bei Neustart | nur mit Spezialwerkzeug, Aufgabe für Forensiker |
| Temporäre Dateien in `/tmp` oder `/dev/shm` | oft bei Neustart gelöscht | kopieren, ohne auszuführen |
| Logs von Webserver, PHP, System | werden rotiert | vollständig kopieren, Rotation anhalten |
| Dateisystem und Datenbank | stabil bis zur Neuinstallation | Snapshot oder Datenträgerabbild, Datenbankexport |
| CDN, WAF, Firewall, Hoster | Aufbewahrung nach Fristen des Anbieters | Export anfordern, schriftlich bestätigen lassen |

Den Arbeitsspeicher sichern Sie nur, wenn jemand mit passendem Werkzeug und Erfahrung bereitsteht. Bei Systemen mit sensiblen Daten oder absehbarem Rechtsstreit sollte das eine [IT-Forensik](https://phpsos.de/leistungen/it-forensik/) übernehmen.

## Flüchtige Daten in wenigen Minuten festhalten

Die folgenden Befehle verändern nichts am System. Sie schreiben den aktuellen Zustand in Dateien, die anschließend außerhalb des Servers gesichert werden. Legen Sie das Zielverzeichnis möglichst auf einem angeschlossenen, separaten Datenträger an:

```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"
```

Wie Sie anschließend die Logs vollständig sichern und auswerten, beschreibt der Ratgeber [Webserver-Logs nach einem Angriff auswerten](https://phpsos.de/ratgeber/logfiles-auswerten/). Bei virtuellen Servern ist ein Snapshot über die Verwaltung des Anbieters der einfachste Weg zu einem vollständigen Abbild. Er erfasst das System, ohne dass Sie auf dem kompromittierten Server weitere Werkzeuge starten müssen.

## Damit die Sicherung später etwas wert ist

Eine Sicherung ist nur so gut wie ihr Nachweis. Drei Regeln machen sie belastbar:

1. **Prüfsummen:** Jede gesicherte Datei erhält eine SHA-256-Prüfsumme. Damit lässt sich später zeigen, dass die Kopie unverändert ist.
2. **Protokoll:** Wer hat wann was gesichert, mit welchem Befehl, wohin? Jede Übergabe an Dritte wird festgehalten. Fachleute nennen das die Beweiskette.
3. **Getrennte Ablage:** Kopien gehören auf ein System, auf das der Angreifer keinen Zugriff hatte, und werden nur lesend weiterverwendet.

Arbeiten Sie danach nur noch mit Kopien. Jede Analyse am Original verändert Zeitstempel und kann Spuren überschreiben. Führen Sie verdächtige Dateien niemals aus und öffnen Sie sie nicht über den Browser.

> **Wichtig:**
> Fordern Sie die Logs von CDN, WAF und Hoster früh an. Diese Daten liegen außerhalb Ihres Servers und sind für einen Angreifer schwer zu manipulieren, werden aber oft nur kurz aufbewahrt.

## Was die Beweislage zerstört

Viele Spuren gehen nicht durch den Angreifer verloren, sondern durch gut gemeinte erste Hilfe. Diese Schritte sollten vor der Sicherung unterbleiben:

- **Neustart oder Ausschalten:** Prozesse, Verbindungen und Arbeitsspeicher sind danach weg.
- **Virenscanner mit automatischer Löschung:** Er entfernt Dateien, bevor jemand sie gesichert hat, und verändert Zeitstempel.
- **Aufräumen von Logs oder Temp-Ordnern:** Auch wenn der Platz knapp wird, erst kopieren, dann löschen.
- **Neue Werkzeuge aus dem Internet auf dem Server installieren:** Jede Installation schreibt ins Dateisystem und kann Spuren überdecken.
- **Anmeldung mit privilegierten Zugangsdaten ohne Not:** Läuft auf dem Server noch Schadcode, können eingegebene Passwörter mitgelesen werden.

Gerade Versicherer fragen später, was wann gesichert wurde. Hinweise zu typischen Obliegenheiten finden Sie unter [Cyberversicherung: Was im Schadensfall zählt](https://phpsos.de/compliance/cyberversicherung/).

## Abwägen: Wie viel Zeit ist für die Sicherung da?

Nicht jeder Vorfall erlaubt eine lange Sicherung. Läuft gerade ein Datenabfluss oder werden Besucher angegriffen, hat die Eindämmung Vorrang. Die Trennung vom Netz bei laufendem System verbindet beides: Der Angreifer verliert den Zugriff, die Spuren bleiben erhalten. Für die meisten Webserver reicht danach eine überschaubare Zeitspanne für die flüchtigen Daten und den Snapshot.

Treffen Sie die Entscheidung bewusst und halten Sie sie fest: Wer hat entschieden, wann neu aufgesetzt wird, und was wurde vorher gesichert? Diese Notiz ist später Teil der [Zeitleiste des Vorfalls](https://phpsos.de/blog/zeitleiste-eines-vorfalls/). Ob Neuaufbau oder Bereinigung der richtige Weg ist, beleuchtet der Beitrag [Server neu aufsetzen oder bereinigen?](https://phpsos.de/blog/neu-aufsetzen-oder-bereinigen/).

## Wie hilft PHP SOS konkret?

- Wir sichern flüchtige Daten, Logs und Systemabbilder in der richtigen Reihenfolge, mit Prüfsummen und Protokoll.
- Wir fordern die Daten vorgelagerter Dienste an, bevor deren Aufbewahrungsfristen ablaufen.
- Bei Bedarf übernehmen wir mit spezialisierten Partnern die forensische Sicherung und Auswertung.
- Erst danach bauen wir den Server neu auf, schließen das Einfallstor und dokumentieren den Vorfall, bis er abgeschlossen ist.


## Häufige Fragen

**Warum sollte ich vor dem Neuaufsetzen Beweise sichern?**  
Weil nur die Spuren zeigen, wie der Angreifer hereinkam, wie lange er im System war und welche Daten er erreichen konnte. Diese Antworten brauchen Sie für Datenschutz, Versicherung und die Frage, ob weitere Systeme betroffen sind. Nach dem Neuaufbau sind sie verloren.

**Was ist bei der Sicherung am dringendsten?**  
Flüchtige Daten wie laufende Prozesse, Netzwerkverbindungen und angemeldete Benutzer verschwinden beim Herunterfahren. Sie werden zuerst festgehalten. Danach folgen Logs, ein Abbild des Systems und Daten von vorgelagerten Diensten.

**Reicht ein normales Backup als Beweissicherung?**  
Meist nicht. Viele Backups enthalten keine Logs, keine Systemdateien und keine Metadaten wie Zeitstempel und Eigentümer. Für die Beweissicherung brauchen Sie eine vollständige, unveränderte Kopie mit Prüfsumme, idealerweise einen Snapshot oder ein Datenträgerabbild.

**Darf ich den Server vor der Sicherung vom Netz nehmen?**  
Ja, wenn er dabei weiterläuft. Eine Trennung vom Netz stoppt Datenabfluss und Fernsteuerung, ohne flüchtige Spuren zu zerstören. Ein Neustart oder Ausschalten dagegen löscht den Arbeitsspeicher und laufende Prozesse.

## Quellen

- [BSI: Hinweise zu IT-Sicherheitsvorfällen](https://www.bsi.bund.de/)
- [DSGVO Art. 33: Meldung an die Aufsichtsbehörde](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [Polizei: Zentrale Ansprechstellen Cybercrime](https://www.polizei.de/)