# Login Auditing: Wer war wann auf dem Server?

TL;DR / Management Summary In einem gehärteten System ist die Überwachung der Logins Pflicht. Wir müssen jederzeit nachweisen können, welcher Benutzer sich von welcher IP-Adresse eingeloggt hat und wie lange er aktiv war. In diesem Modul lernen wir die klassischen Werkzeuge (last, who, w) kennen, nutzen lastlog für die Inaktivitäts-Prüfung und implementieren mit auditd eine revisionssichere Protokollierung, die selbst von Root-Benutzern nicht unbemerkt manipuliert werden kann.

# 1. Einführung & Architektur

Die Login-Datenbanken.

Linux speichert Login-Daten in binären Dateien, die nicht einfach mit einem Texteditor gelesen werden können:

• /var/run/utmp: Wer ist aktuell eingeloggt?
• /var/log/wtmp: Historie aller Logins/Logouts.
• /var/log/btmp: Alle fehlgeschlagenen Login-Versuche.

# Der Audit-Stack (Mermaid)

graph TD
    A[Login Event] --> B[systemd-logind]
    B --> C[Binary DB: utmp / wtmp]
    B --> D[Text Log: /var/log/secure]
    B --> E[Auditd: Syscall Monitoring]
    F[Admin CLI: last / who] --> C
    G[Security Team] --> D
    H[Compliance Officer] --> E

# 2. Die Standard-Werkzeuge

Schnelle Übersicht.

# Wer ist aktuell da?

w
# Zeigt User, TTY, Remote-IP, Login-Zeit und aktuellen Befehl.

# Die Historie der Logins

# Zeige die letzten 20 Logins
last -n 20

# Zeige alle fehlgeschlagenen Logins (erfordert oft sudo)
sudo lastb

# 3. lastlog: Inaktive Accounts finden

Sicherheit durch Aufräumen.

Accounts, die monatelang nicht genutzt wurden, sind ein Risiko.

# Zeige alle User, die sich noch NIE eingeloggt haben
lastlog -n 0

# Zeige User, die sich länger als 90 Tage nicht gemeldet haben
lastlog -b 90

# 4. Day-2 Operations: Revisionssicheres Auditing mit auditd

Den Wächter schärfen.

Während wtmp manipuliert werden kann, schreibt auditd (Artikel 030) direkt in einen gehärteten Stream.

# Regel für Logins hinzufügen

In /etc/audit/rules.d/audit.rules:

-w /var/log/lastlog -p wa -k logins
-w /var/run/utmp -p wa -k session

# Abfrage

# Suche nach allen Login-Events
sudo ausearch -k logins

# 5. Troubleshooting & “War Stories”

Wenn die Spuren verwischt werden.

# Story 1: “Der hängende ‘w’ Output”

Symptom: Der Befehl w oder who braucht 30 Sekunden für die Anzeige. Ursache: Das Tool versucht für jede Remote-IP einen Reverse-DNS-Lookup durchzuführen. Wenn der DNS-Server nicht antwortet, hängt der Prozess. Lösung: Nutzen Sie das Flag -n, um DNS-Auflösung zu unterbinden: who -n.

# Story 2: “Log Cleaning durch Angreifer”

Symptom: Ein Server wurde gehackt, aber last zeigt keine verdächtigen Logins an. Das Textlog /var/log/secure ist jedoch voll mit Einträgen. Ursache: Der Angreifer hat mit dem Tool wipe oder durch direktes Editieren der wtmp-Datei seine Einträge gelöscht. Die binären Datenbanken sind für Profis leicht zu manipulieren. Lösung: Senden Sie Ihre Login-Logs in Echtzeit an einen externen Log-Server (Artikel 046). Ein Angreifer kann lokale Spuren löschen, aber er kann das bereits gesendete Paket nicht zurückholen.

# 6. Fazit & Empfehlung

• Routine: Führen Sie wöchentlich lastb aus, um die Wirksamkeit Ihres Fail2Ban (Artikel 028) zu prüfen.
• Compliance: Nutzen Sie lastlog, um verwaiste Service-Accounts zu finden und zu deaktivieren.
• Sicherheit: Verlassen Sie sich bei forensischen Untersuchungen niemals nur auf last. Nutzen Sie immer die Kombination aus Syslog und Auditd.

# Anhang: Cheatsheet