Authentifizierungsprotokolle helfen, Anmeldeversuche, Berechtigungsänderungen und Sitzungsaktivität zu erklären. Sie sind sicherheitssensible Belege, doch eine einzelne Zeile belegt selten die Absicht eines Benutzers oder die Kompromittierung eines Kontos.
Protokollierung · Lektion 5
Authentifizierungsprotokollierung
Lerne, Linux-Authentifizierungsdatensätze aufzufinden, zu interpretieren und sicher miteinander zu verknüpfen.
Authentifizierungsdatensätze auffinden
Syslog-Konfigurationen der Debian-Familie leiten Authentifizierungsereignisse gewöhnlich nach /var/log/auth.log, während Konfigurationen der Red-Hat-Familie häufig /var/log/secure verwenden. Ein systemd-Journal kann dieselben Ereignisse mit Unit- und Prozessmetadaten aufbewahren, und eine zentrale Protokollierung kann die maßgebliche Kopie enthalten.
Ermittle das lokale Ziel und frage den betreffenden Dienst ab, zum Beispiel:
$ sudo journalctl -u ssh.service --since '1 hour ago'
$ sudo less /var/log/auth.log
Die SSH-Unit kann ssh.service oder sshd.service heißen. Berechtigungen beschränken diese Datensätze gewöhnlich, weil sie Konto- und Zugriffsdetails offenlegen.
Wo müssen Linux-Authentifizierungsereignisse immer gespeichert sein?
Ein Ereignis interpretieren
Ein herkömmlicher Datensatz könnte Folgendes enthalten:
Jan 31 10:37:50 icebox pkexec: pam_unix(polkit-1:session): session opened for user root by (uid=1000)
Dies bezeichnet Zeit, Host, ausgebendes Programm, PAM-Modul und -Dienst, angeforderten Sitzungsbenutzer sowie ursprüngliche UID. Es identifiziert für sich allein weder den Menschen hinter UID 1000 noch beweist es eine böswillige Handlung. Löse die UID anhand der zum Zeitpunkt des Vorfalls gültigen Kontodatensätze auf und verknüpfe Terminal, entfernte Adresse, Sitzung und umgebende Ereignisse.
Was belegt uid=1000 in diesem Datensatz?
Erfolg und Fehlschlag untersuchen
Suche in einem begrenzten Zeitraum sowohl nach angenommenen als auch abgelehnten Versuchen. Untersuche bei SSH außerdem Verbindungsquelle, Authentifizierungsmethode, Zielkonto, Sitzungsbeginn und -ende sowie Dienstneustarts. Wiederholte Fehlschläge können Benutzerfehler, Automatisierung mit veralteten Anmeldedaten, Scans oder einen Angriff bedeuten; die Rate allein wählt keine dieser Erklärungen aus.
last und lastb können, sofern sie geführt werden, Datensätze aus wtmp und btmp zusammenfassen. Diese Binärdatenbanken besitzen jedoch eigene Aufbewahrungs- und Integritätsgrenzen. Vergleiche sie mit Journal- oder Syslog-Datensätzen und zentralen Quellen.
Womit sollten wiederholte fehlgeschlagene Anmeldungen verknüpft werden?
Belege bewahren und reagieren
Falls ein Vorfall vermutet wird, erfasse Hostzeit und Zeitzone, bewahre ursprüngliche Protokolle samt Metadaten und sichere jede exportierte Kopie. Bearbeite Belege nicht an Ort und Stelle. Kontosperren, Firewalländerungen und das Beenden von Sitzungen können berechtigten Zugriff unterbrechen oder einen Angreifer warnen. Befolge deshalb den Prozess zur Vorfallsreaktion und erhalte einen Wiederherstellungszugang.
Wie sollten Authentifizierungsbelege während einer Untersuchung behandelt werden?
Lektion abgeschlossen
Sie haben Authentifizierungsprotokollierung abgeschlossen
Du kannst Authentifizierungsereignisse nun untersuchen, ohne die Aussagekraft eines einzelnen Datensatzes zu überschätzen.
Ermittle das lokal konfigurierte Ziel für Authentifizierungsprotokolle.
Interpretiere Identität, Dienst, Methode und Sitzungsfelder im Zusammenhang.
Verknüpfe fehlgeschlagene und erfolgreiche Aktivität über aufbewahrte Quellen hinweg.
Bewahre Belege und koordiniere unterbrechende Reaktionsmaßnahmen.
Lernfortschritt speichern
Erstellen Sie ein kostenloses Konto, um diese Lektion zu speichern und auf jedem Gerät weiterzulernen.
Kostenloses Konto erstellen