Auf Debian und Ubuntu protokolliert Nginx in /var/log/nginx/access.log und error.log, und Apache in /var/log/apache2/access.log und error.log. Auf RHEL, Rocky und Alma verwendet Apache /var/log/httpd/access_log und error_log, mit Unterstrichen und keiner Erweiterung. In Containern, die aus dem offiziellen Nginx-Bild erstellt wurden, gibt es überhaupt keine Logdateien: alles geht an stdout und stderr, daher ist docker logs Ihr Export.
Das Webserver-Log ist oft der erste Ort, an dem ein Eindringen Spuren hinterlässt: der Scanner, der nach .env-Dateien sucht, der Exploit-String, der POST zu einer Datei, die nicht existieren sollte. Prime Core hat 812 Erkennungsregeln für Webserver-Logs, die 337 MITRE ATT&CK-Techniken zugeordnet sind. Darunter: Ausnutzung von öffentlich zugänglichen Anwendungen (T1190), Web-Shells (T1505.003) und Schwachstellenscans (T1595.002).
Bevor Sie beginnen
Finden Sie die tatsächlichen Pfade. Virtuelle Hosts protokollieren oft an einem benutzerdefinierten Ort. Fragen Sie den Server selbst:
# Nginx: dumpen Sie die vollständige effektive Konfiguration und wählen Sie die Protokollierungsvorgaben aus
sudo nginx -T 2>/dev/null | grep -E 'access_log|error_log'
# Apache
sudo apachectl -S
sudo grep -Ri -E 'CustomLog|ErrorLog' /etc/apache2/ /etc/httpd/ 2>/dev/null
Auf Apache-Systemen, die auf Debian basieren, landen virtuelle Hosts ohne eigenen CustomLog in other_vhosts_access.log. Das wird oft übersehen.
Überprüfen Sie, wessen IP Sie protokollieren. Hinter einem Load Balancer, CDN oder Reverse Proxy kann jede Anfrage vom Proxy zu kommen scheinen. Das gilt, es sei denn, der Server ist so eingerichtet, dass er den echten Client protokolliert: set_real_ip_from und real_ip_header in Nginx, mod_remoteip in Apache. Wenn jede Zeile dieselben internen IPs zeigt, befindet sich die Adresse des Angreifers nur in X-Forwarded-For, falls Sie sie protokollieren, oder in den Logs des Proxys.
Überprüfen Sie das Format. Beide Server verwenden standardmäßig das „kombinierte“ Format, doch viele Setups passen es an (log_format in Nginx, LogFormat in Apache). Notieren Sie, wie Ihres aussieht, bevor Sie hochladen.
Berechtigungen. Auf Debian und Ubuntu sind diese Logs für root und die adm-Gruppe lesbar; in anderen Fällen planen Sie mit sudo.
Export aus Logdateien
Logs rotieren täglich oder wöchentlich, also schließen Sie die rotierten Dateien ein. zcat -f liest sowohl normale als auch gzip-Dateien:
# Nginx, aktuell und rotiert, älteste zuerst
sudo zcat -f $(ls -tr /var/log/nginx/access.log*) > web-03_nginx_access.log
# Apache auf RHEL
sudo zcat -f $(ls -tr /var/log/httpd/access_log*) > web-03_httpd_access.log
Für einen einzelnen Tag reichen kombinierte Format-Zeitstempel aus: grep genügt:
grep '19/Oct/2026' web-03_nginx_access.log > web-03_access_1019.log
Nehmen Sie auch das Fehlerprotokoll. Upstream-Fehler, PHP-Fehler und einige Exploit-Versuche erscheinen nur dort.
Export aus Containern
# Docker: stdout ist das Zugriffprotokoll, stderr das Fehlerprotokoll
docker logs --since 2026-10-19T00:00:00 --until 2026-10-20T00:00:00 nginx > nginx_access.log 2> nginx_error.log
# Kubernetes
kubectl logs deploy/nginx --since=24h > nginx.log
Container-Logs verschwinden mit dem Container, es sei denn, jemand sammelt sie. Wenn der Pod ersetzt wurde, überprüfen Sie den Log-Sammler Ihres Clusters.
Worauf man achten sollte
| Muster | Was das normalerweise bedeutet |
|---|---|
| Schübe von 404s für /.env, /.git/config, /wp-login.php, /phpmyadmin | Automatisiertes Scannen |
| ../, ${jndi:, union select, <script> in der URL | Exploit-Versuche: Directory Traversal, Log4Shell, SQL-Injection, XSS |
| 200 auf einen POST zu einer merkwürdigen Datei in einem Upload-Verzeichnis | Mögliche Web-Shell; schauen Sie, was diese IP sonst noch angefragt hat |
| User-Agenten wie sqlmap, nikto, nuclei | Werkzeuge, die sich nicht die Mühe gemacht haben, sich zu verstecken |
| Ein Anstieg von 5xx direkt nach seltsamen Anfragen | Etwas ist kaputt gegangen, möglicherweise weil ein Exploit gegriffen hat |
Hochladen, bereinigen und in LogTotal überprüfen
- Hochladen. Öffnen logtotal.com und Datei einfügen.
- Bereinigen. [what gets masked: client IPs, hostnames, usernames and tokens in URLs]. Look it over before you continue. Query strings often carry session tokens.
- Überprüfen.
Wenn es schief geht
| Symptom | Wahrscheinliche Ursache | Fix |
|---|---|---|
| Kein /var/log/nginx | Benutzerdefinierter Pfad, oder es läuft in einem Container | nginx -T, oder docker logs |
| access.log existiert, aber ist leer | Logs gehen an stdout, oder access_log ist aus | Überprüfen Sie die Konfiguration und den Container |
| Jede Anfrage kommt von denselben IPs | Proxy oder Load Balancer davor; echte IP nicht konfiguriert | Verwenden Sie X-Forwarded-For oder die Logs des Proxys |
| Nur die letzten paar Tage | Rotierte Dateien wurden ausgelassen | Verwenden Sie den zcat -f Befehl mit * Glob |
| Zugriff verweigert | Kein root, nicht in adm | sudo |
FAQ
Welches ist wichtiger, das Zugriffs- oder das Fehlerprotokoll?
Das Zugriffsprotokoll sagt Ihnen, was angefordert wurde. Das Fehlerprotokoll sagt Ihnen, was kaputt ging. In einem Exploit-Fall wollen Sie beides, nebeneinander.
Was ist mit IIS?
IIS schreibt W3C-Logs standardmäßig in C:inetpublogsLogFiles. Das bekommt einen eigenen Leitfaden.