Logs und Login-Audit auf dem Server
Logs beantworten drei Fragen: Was ist kaputtgegangen, wer hat sich am Server angemeldet und was hat er dort getan. Eine Antwort gibt es nur, wenn die Logs aktiviert sind, lange genug aufbewahrt werden und nicht ausschließlich auf dem Server liegen, der kompromittiert worden sein könnte. Hier lesen Sie, wo Sie die Logs unter Linux finden, welche Befehle die Anmeldungen zeigen, wie Sie die Rotation einrichten und was Sie vorab tun sollten, damit es nach einem Vorfall etwas zu analysieren gibt.
Unter Linux mit systemd schreiben zwei Systeme die Logs. Der Dienst journald von systemd sammelt die Meldungen aller Dienste, des Kernels und der Anmeldungen in einem binären Journal. Der Dienst rsyslog verteilt dieselben Meldungen, sofern er installiert ist, auf Textdateien in /var/log. Webserver, Datenbank und Docker führen eigene Logs. Wo was liegt, sollten Sie vor einem Vorfall wissen, nicht erst währenddessen.
Wo die Logs liegen
- journald. Gelesen wird es mit dem Befehl
journalctl. Das Journal wird auf der Festplatte gespeichert, wenn das Verzeichnis/var/log/journalexistiert, andernfalls nur im Arbeitsspeicher, und es geht beim Neustart verloren (journald.conf, ParameterStorage=auto). Prüfen Sie das auf einem neuen Server mitls /var/log/journal. Fehlt das Verzeichnis, legen Sie es an und starten den Dienst neu:systemctl restart systemd-journald. - Systemdateien. Unter Ubuntu landen Anmeldungen und sudo in
/var/log/auth.log, allgemeine Meldungen in/var/log/syslog. Unter AlmaLinux und Rocky Linux sind das/var/log/secureund/var/log/messages. Unter Debian 12 und neuer wird rsyslog standardmäßig nicht installiert, und alles steht nur in journald. - Webserver. nginx schreibt nach
/var/log/nginx/access.logunderror.log, Apache unter Debian und Ubuntu nach/var/log/apache2/, unter AlmaLinux nach/var/log/httpd/. Das Zugriffslog zeigt jede Anfrage: Adresse, Zeit, Pfad, Antwortcode, Größe und Browser. Welche Felder es enthält, legt die Direktive log_format fest. Steht die Website hinter einem CDN, richten Sie die Übergabe der echten Besucheradresse ein, sonst stehen im Log nur die Adressen des CDN (mehr dazu im Artikel CDN: wann eine Website eines braucht). - Anwendungen und Docker. Datenbanken schreiben in eigene Verzeichnisse unter
/var/log, Container in Docker-Dateien, die Sie mitdocker logslesen.
Einige Befehle von journalctl, die in den meisten Fällen genügen: journalctl -u nginx --since "1 hour ago" zeigt die Meldungen eines Dienstes der letzten Stunde, journalctl -p err -b die Fehler seit dem letzten Systemstart, journalctl -f den laufenden Strom neuer Meldungen und journalctl --disk-usage den Platz, den das Journal belegt.
Wer sich am Server angemeldet hat
Jede SSH-Anmeldung hinterlässt einen Eintrag mit Benutzername, Adresse und Anmeldeart, also Schlüssel oder Passwort. Erfolgreiche Anmeldungen sehen Sie so:
- in journald:
journalctl -u ssh --since today | grep Accepted(unter AlmaLinux heißt der Dienstsshd); - in der Datei:
grep Accepted /var/log/auth.logbeziehungsweise/var/log/secure; - als Übersicht: Der Befehl
lastzeigt Anmeldungen und Neustarts,lastbfehlgeschlagene Versuche.
In Debian 13 gibt es die Befehle last, lastb und lastlog nicht mehr, weil ihre alten Dateien keine Daten nach dem Jahr 2038 speichern können. An ihre Stelle treten die Pakete wtmpdb und lastlog2 (Versionshinweise zu Debian 13). Die Einträge Accepted im Journal gibt es in jeder Version.
Worauf Sie achten sollten: Anmeldungen von unbekannten Adressen und zu ungewöhnlichen Zeiten. Anmeldungen per Passwort, obwohl Sie nur Schlüssel zugelassen haben: Dann wurde die Einstellung nicht übernommen. Befehle über sudo: In auth.log und in journald steht zu jedem, wer was ausgeführt hat. Neue Schlüssel in ~/.ssh/authorized_keys und neue Benutzer in /etc/passwd: Angreifer legen sie an, um später zurückzukehren. Brauchen Sie ein detailliertes Audit von Dateiänderungen und Befehlen, bietet Linux das Audit-Subsystem auditd, dessen Regeln allerdings eine eigene Einrichtung und Speicherplatz erfordern.
fail2ban: was es außer dem SSH-Schutz leistet
fail2ban liest die Logs und sperrt vorübergehend Adressen, die sich wiederholt bei der Anmeldung vertun. Installation und SSH-Schutz beschreibt der Artikel Die ersten 10 Schritte nach dem VPS-Kauf: Sicherheit. Standardmäßig wird eine Adresse nach 5 Fehlversuchen innerhalb von 10 Minuten für 10 Minuten gesperrt (jail.conf). Sinnvolle Ergänzungen:
- Lange Sperren für Wiederholungstäter. Die Regel
recidiveliest das Log von fail2ban selbst und sperrt eine Adresse für eine Woche, wenn sie innerhalb eines Tages mehrmals aufgefallen ist. Der Parameterbantime.increment = trueverdoppelt die Sperrdauer mit jeder neuen Sperre. - Regeln für den Webserver. Die fertigen Regeln
nginx-http-auth,nginx-limit-requndnginx-botsearchreagieren auf falsche Passwörter auf geschützten Seiten, auf das Überschreiten der Anfragerate und auf das massenhafte Abfragen nicht existierender Adressen. - Eigene Adressen als Ausnahme. Der Parameter
ignoreipmit der statischen Adresse Ihres Büros verhindert, dass Sie sich selbst aussperren.
fail2ban schützt nicht vor verteilten Angriffen von Tausenden Adressen und ersetzt nicht die Anmeldung per Schlüssel. Für das Audit liegt sein Hauptnutzen in einem kürzeren Log: Darin bleiben aussagekräftige Ereignisse statt Zehntausender gleichförmiger Passwortrateversuche. Die Liste der gesperrten Adressen zeigt fail2ban-client status sshd.
Rotation und Speicherplatz
Logs wachsen ständig, und günstige VPS haben kleine Festplatten. Laut Katalog von accsly.io mit Stand November 2026 haben VPS-Tarife mit 1 GB Arbeitsspeicher im Median eine Festplatte von 20 GB, und bei 9 % der VPS-Tarife sind es 20 GB oder weniger. Das Zugriffslog einer stark besuchten Website oder ein Container, der in einer Schleife Fehler schreibt, füllt eine solche Festplatte in wenigen Tagen, danach fallen die Datenbank und die Website selbst aus.
- journald belegt standardmäßig höchstens 10 % des Dateisystems und nicht mehr als 4 GB. Eine eigene Grenze setzen Sie mit
SystemMaxUse=in/etc/systemd/journald.conf, die Aufbewahrungsdauer mitMaxRetentionSec=, das standardmäßig deaktiviert ist. Einmalig Platz schaffen Sie mitjournalctl --vacuum-size=500Moder--vacuum-time=30d. - Textdateien rotiert logrotate nach den Regeln in
/etc/logrotate.d/. Unter Ubuntu 24.04 werden die Systemlogs wöchentlich rotiert und 4 alte Dateien aufbewahrt, also etwa ein Monat. Die nginx-Logs aus dem Paket von AlmaLinux 9 werden täglich rotiert, 10 alte Dateien bleiben erhalten. Die Parameterrotate,dailyoderweekly,compressundmaxsizesteuern Aufbewahrung, Kompression und Rotation nach Größe. Der Moduscopytruncateeignet sich für Programme, die eine Datei nicht neu öffnen können, kann laut Dokumentation aber Zeilen verlieren. Eine Regel prüfen Sie ohne Änderungen mitlogrotate -d /etc/logrotate.d/nginx. - Docker schreibt die Container-Logs standardmäßig ohne Größenbegrenzung (Treiber json-file). Setzen Sie
max-sizeundmax-filein/etc/docker/daemon.jsonund erstellen Sie die Container neu, denn die Einstellungen gelten nur für neue Container. Mehr dazu im Artikel Docker auf einem VPS: der Einstieg.
Was die Festplatte belegt, finden Sie so: df -h zeigt die volle Partition, du -xh /var/log | sort -h | tail die größten Verzeichnisse. Löschen Sie keine Logdatei, die ein Dienst geöffnet hält: Der Platz wird erst frei, wenn der Dienst neu startet. Leeren Sie sie stattdessen mit truncate -s 0. Eine Warnung vor einer vollen Festplatte erhalten Sie besser rechtzeitig, dazu der Artikel Servermonitoring: Uptime, Last, Alarme.
Logs für die Analyse eines Vorfalls aufbewahren
Wird ein Server kompromittiert, ändert oder löscht ein Angreifer mit Root-Rechten als Erstes die Logs. Deshalb ist eine Kopie, die den Server sofort verlässt, wertvoller als jede Aufbewahrungseinstellung auf dem Server selbst.
- Senden Sie die Logs an einen anderen Server. rsyslog kann Meldungen über das Netz weiterleiten, für journald gibt es dafür den Dienst systemd-journal-upload. Als Empfänger dient ein separater günstiger VPS mit größerer Festplatte oder ein Log-System wie Loki, Graylog oder OpenSearch; passende Tarife sammelt die Auswahl VPS für Elasticsearch.
- Legen Sie die Aufbewahrungsdauer fest. Für die Analyse der meisten Vorfälle brauchen Sie die Logs von 30–90 Tagen, denn ein Einbruch wird oft nicht am Tag des Eindringens bemerkt. Auf dem Server selbst genügen ein bis zwei Wochen, der Rest liegt auf dem Sammelserver oder im Archiv.
- Synchronisieren Sie die Uhrzeit. Ohne genaue Zeit lassen sich Ereignisse auf verschiedenen Servern nicht zuordnen. Prüfen Sie
timedatectl: In der Zeile „System clock synchronized“ muss yes stehen. - Speichern Sie nichts Überflüssiges. Passwörter, Tokens und vollständige Kartennummern gehören nicht ins Log. IP-Adressen und Benutzernamen sind nach der DSGVO personenbezogene Daten. Halten Sie Zweck und Aufbewahrungsdauer der Logs deshalb im Verzeichnis von Verarbeitungstätigkeiten und in der Datenschutzerklärung fest; mehr dazu im Artikel DSGVO und Hosting.
- Bei einem Vorfall erst sichern, dann reparieren. Kopieren Sie die Logs und erstellen Sie beim Hoster einen Snapshot der Festplatte, bevor Sie das System neu installieren. Wie Snapshots und Backups funktionieren, beschreibt der Artikel VPS-Backups: Strategien und Werkzeuge.
Brauchen Sie die Logs nicht nur zur Analyse, sondern auch für Benachrichtigungen, etwa bei einer Häufung von 500-Fehlern oder einer Anmeldung als root, sammeln Sie sie zusammen mit den Metriken auf einem separaten Monitoring-Server. Tarife dafür finden Sie in der Auswahl VPS für Monitoring.