# Webserver-Logs nach einem Angriff auswerten: Access-Log richtig lesen

> Access-Log nach einem Angriff auswerten: Logs zuerst sichern, typische Spuren finden, Befehle für Apache und Nginx nutzen und Besonderheiten bei PHP2Shell.

Quelle: https://phpsos.de/ratgeber/logfiles-auswerten/  
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:** Wer das Access-Log nach einem Angriff auswerten will, sichert die Logs zuerst unverändert und arbeitet danach nur mit Kopien. Gesucht werden Anfragen mit Status 200 auf unbekannte PHP-Dateien, auffällige POST-Anfragen, Zugriffe auf Upload-Verzeichnisse und zeitliche Muster. Für PHP2Shell gibt es keine veröffentlichten, bestätigten Indicators of Compromise, deshalb zählt das Gesamtbild aus mehreren Logquellen.

## Zuerst sichern, dann auswerten

Logdateien werden auf den meisten Servern automatisch rotiert und nach einer festen Zeit gelöscht. Nach einem Angriff ist deshalb der erste Schritt, die vorhandenen Logs zu sichern, bevor sie verschwinden. Das gilt auch, wenn Sie noch nicht sicher sind, ob überhaupt etwas passiert ist. Zu PHP2Shell rät die Fachpresse, Logs ab dem 20.10.2026 aufzubewahren.

```bash
# Logs mit Zeitstempeln kopieren und Prüfsummen festhalten
ZIEL=/root/sicherung-logs-$(date +%F)
mkdir -p "$ZIEL"
cp -a /var/log/nginx /var/log/apache2 /var/log/php* "$ZIEL"/ 2>/dev/null
cp -a /var/log/auth.log* /var/log/syslog* "$ZIEL"/ 2>/dev/null
find "$ZIEL" -type f -exec sha256sum {} + > "$ZIEL.sha256"
```

Legen Sie die Sicherung zusätzlich auf einem anderen System ab. Ein Angreifer mit Zugriff auf den Server könnte Logs sonst nachträglich verändern. Die Prüfsummen zeigen später, dass die Kopie unverändert ist. Ist eine gerichtsfeste Sicherung nötig, etwa für eine Anzeige oder die Versicherung, sollte eine [IT-Forensik](https://phpsos.de/leistungen/it-forensik/) die Sicherung übernehmen.

> **Wichtig:**
> Prüfen Sie die Logrotation (`/etc/logrotate.d/`) und verlängern Sie die Aufbewahrung vorübergehend, damit während der Analyse keine weiteren Dateien gelöscht werden.

## Wo die Logs liegen und wie eine Zeile aufgebaut ist

Die Speicherorte hängen von Distribution und Verwaltungsoberfläche ab. Typische Pfade:

| System | Access- und Error-Log |
|---|---|
| Debian, Ubuntu mit Apache | `/var/log/apache2/` |
| RHEL, AlmaLinux, Rocky mit Apache | `/var/log/httpd/` |
| Nginx | `/var/log/nginx/` |
| Plesk | `/var/www/vhosts/system/<domain>/logs/` |
| PHP-FPM | `/var/log/php*-fpm.log` oder im Journal |

Im verbreiteten Combined-Format enthält jede Zeile die Client-Adresse, Datum und Uhrzeit, Methode und Pfad der Anfrage, den Statuscode, die Antwortgröße in Bytes, den Referer und den User-Agent. Achten Sie auf die Zeitzone im Zeitstempel, besonders wenn Sie Logs mit Meldungen in UTC abgleichen. Die PHP2Shell-Patches wurden zum Beispiel am 21.10.2026 um 14:00 UTC veröffentlicht, also um 16 Uhr deutscher Zeit.

Liegt Ihre Website hinter einem Proxy, CDN oder Load Balancer, steht im Log womöglich nur dessen Adresse. Die echte Besucheradresse findet sich dann in einem eigenen Feld oder in den Logs des vorgeschalteten Dienstes.

### Ohne Kommandozeile: Logs im Panel oder beim Hoster

Nicht jeder Betreiber hat Shell-Zugriff. Bei Shared Hosting oder verwalteten Servern bieten Verwaltungsoberflächen meist eine Logansicht und einen Download der Access- und Error-Logs. Laden Sie die Dateien für den gesamten verfügbaren Zeitraum herunter und bewahren Sie sie sicher auf. Fragen Sie Ihren Hoster schriftlich, wie lange Logs vorgehalten werden und ob ältere Stände gesichert werden können, bevor sie ablaufen.

Beachten Sie dabei den Datenschutz: Logs enthalten IP-Adressen und oft weitere personenbezogene Angaben. Speichern Sie die Kopien zugriffsgeschützt, geben Sie sie nur an Personen weiter, die sie für die Aufklärung brauchen, und legen Sie fest, wann sie nach Abschluss des Vorfalls gelöscht werden.

## Access-Log auswerten: die wichtigsten Abfragen

Die folgenden Befehle lesen nur und eignen sich für Nginx und Apache im Combined-Format. Rotierte und komprimierte Dateien durchsuchen Sie mit `zgrep` oder `zcat`.

```bash
LOG=/root/sicherung-logs-2026-10-25/nginx/access.log

# Erfolgreiche Anfragen auf PHP-Dateien, nach Häufigkeit
awk '$9 == 200 && $7 ~ /\.php/ {split($7,p,"?"); print p[1]}' "$LOG" | sort | uniq -c | sort -rn | head -40

# PHP-Aufrufe in Upload-, Cache- oder Bildverzeichnissen
grep -E '"(GET|POST) /[^ ]*(uploads|cache|images|tmp)/[^ ]*\.php' "$LOG"

# POST-Anfragen nach Ziel und Adresse
awk '$6 == "\"POST" {print $1, $7}' "$LOG" | sort | uniq -c | sort -rn | head -40

# Fehler 5xx je Stunde: Häufungen können auf abstürzende PHP-Prozesse hinweisen
awk '$9 ~ /^5/ {print substr($4, 2, 14)}' "$LOG" | sort | uniq -c

# Rotierte Logs einbeziehen
zgrep -h ' 200 ' /var/log/nginx/access.log.*.gz | grep -c '\.php'
```

Bei der ersten Abfrage interessieren besonders Dateinamen, die Sie nicht kennen oder die nicht zur Anwendung gehören. Gleichen Sie verdächtige Dateien mit dem Dateisystem ab: Wann wurden sie angelegt, wem gehören sie, was steht darin? Hinweise dazu gibt der Ratgeber [Webshells erkennen und entfernen](https://phpsos.de/ratgeber/webshell-erkennen/).

## Besonderheiten bei PHP2Shell

Bei PHP2Shell liegen die Lücken in der Anfrageverarbeitung von PHP selbst. Bei mod_php wurde ein Exploit gezeigt, bevor überhaupt Anwendungscode läuft. Das heißt: Eine Anfrage auf eine völlig normale Seite kann ausreichen. Im Access-Log sieht eine solche Anfrage womöglich unauffällig aus, weil der Inhalt des Anfragekörpers dort nicht steht.

Es gibt keine veröffentlichten, bestätigten Indicators of Compromise. Achten Sie deshalb auf Verhalten und Zusammenhänge, etwa ab dem 17.10.2026, dem laut Medienberichten ersten beobachteten Angriffsversuch:

- Häufungen von Fehlern 500 oder abgebrochenen Antworten auf gewöhnliche Seiten.
- Meldungen über erschöpften Speicher oder beendete Worker im Error- und PHP-FPM-Log.
- Neue PHP-Dateien oder geänderte Dateien kurz nach solchen Häufungen.
- Neue Cronjobs, Prozesse oder ausgehende Verbindungen unter dem Benutzer des Webservers.

Keines dieser Signale ist allein ein Beweis. Zusammen mit anderen Spuren ergeben sie aber ein Bild, das die Frage nach einer Kompromittierung beantwortet oder eine tiefere Untersuchung begründet. Eine Übersicht der Anzeichen finden Sie unter [Bin ich schon kompromittiert?](https://phpsos.de/php2shell/bin-ich-gehackt-anzeichen/).

## Weitere Quellen: Error-Log, PHP-FPM und Systemprotokolle

Das Access-Log zeigt nur einen Teil. Für ein vollständiges Bild ziehen Sie weitere Quellen hinzu:

```bash
# PHP-FPM und Webserver im Journal ab einem Datum
journalctl -u 'php*-fpm*' --since "2026-10-17" --no-pager | tail -200

# Anmeldungen am Server
last -Fa | head -40
grep -E 'Accepted|Failed' /var/log/auth.log | tail -100

# Geplante Aufgaben aller Benutzer prüfen
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done
```

Typische Fehler bei der Auswertung sind, nur das aktuelle statt auch der rotierten Logs zu durchsuchen, die Zeitzone zu übersehen und einzelne Treffer automatisierter Scanner für einen erfolgreichen Angriff zu halten. Ebenso riskant ist das Gegenteil: ein unauffälliges Access-Log als Entwarnung zu werten, obwohl Error-Log und Dateisystem noch nicht geprüft sind.

Notieren Sie jeden Fund mit Uhrzeit, Quelle und Beobachtung in einer Zeitleiste. Diese Zeitleiste ist später die Grundlage für Entscheidungen, für Meldungen an Behörden oder Versicherer und für den Abschlussbericht.

## Wie hilft PHP SOS konkret?

- Wir sichern Logs und relevante Dateien so, dass sie für spätere Prüfungen nachvollziehbar bleiben.
- Wir werten Access-, Error-, PHP- und Systemlogs gemeinsam aus und erstellen eine Zeitleiste des Vorfalls.
- Bei Hinweisen auf eine Kompromittierung übernehmen wir die [Incident Response](https://phpsos.de/leistungen/incident-response/) mit Eindämmung und Bereinigung.
- Wir richten Logrotation und Aufbewahrung so ein, dass beim nächsten Vorfall die nötigen Daten vorhanden sind.


## Häufige Fragen

**Wie lange sollte ich Webserver-Logs aufbewahren?**  
So lange, wie es Ihr Datenschutzkonzept zulässt und eine Analyse sinnvoll ist. Zu PHP2Shell rät die Fachpresse, Logs ab dem 20.10.2026 aufzubewahren. Prüfen Sie die Logrotation, damit ältere Dateien nicht automatisch gelöscht werden.

**Zeigt das Access-Log, ob ein Angriff erfolgreich war?**  
Nicht allein. Es zeigt Anfragen, Statuscodes und Antwortgrößen, aber nicht, welcher Code auf dem Server ausgeführt wurde. Erst zusammen mit Error-Log, PHP-FPM-Log, Dateiänderungen und Systemprotokollen entsteht ein belastbares Bild.

**Darf ich IP-Adressen aus Logs an Dritte weitergeben?**  
IP-Adressen gelten in der Regel als personenbezogene Daten. Für die Aufklärung eines Vorfalls und für Strafanzeigen gibt es zwar Grundlagen, die Weitergabe sollte aber mit dem Datenschutzbeauftragten abgestimmt werden.

**Warum sehe ich im Log viele Angriffe, obwohl nichts passiert ist?**  
Öffentliche Server werden ständig automatisiert gescannt. Die meisten dieser Anfragen laufen ins Leere und enden mit 404 oder 403. Interessant sind vor allem Anfragen mit Status 200 auf unbekannte Dateien und Muster, die zeitlich mit anderen Spuren zusammenfallen.

## Quellen

- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)
- [php.net: Sicherheitsmeldungen](https://www.php.net/)
- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)