SSH Brute Force erkennen: Grundrauschen oder Angriff? | Fallakte 003

Ein fehlgeschlagener SSH-Login ist noch kein Angriff. In Fallakte 001 haben wir gesehen, dass SSH-Login-Versuche Spuren im auth.log hinterlassen. In Fallakte 002 haben wir geklärt, warum ein offener SSH-Port nicht automatisch gefährlich ist, sondern zunächst nur erreichbar bedeutet. In Fallakte 003 stellen wir jetzt die entscheidende SOC-Frage: Wann ist ein fehlgeschlagener Login nur Grundrauschen? Und wann wird daraus ein Brute-Force-Verdacht? Wir schauen uns an, warum einzelne Events selten ausreichen, warum Kontext wichtig ist und wie aus mehreren fehlgeschlagenen Logins ein Muster entstehen kann. Im Cyber-Lab analysieren wir SSH-Login-Versuche auf web01 und machen die Spuren in Splunk sichtbar. Dabei geht es nicht darum, jeden Failed-password-Eintrag zu dramatisieren. Es geht darum, zu verstehen, wann LogSpam relevant wird. Themen dieser Folge: Failed password im auth.log SSH-Login-Versuche richtig einordnen Grundrauschen vs. verdächtiges Muster Quell-IP und Benutzername analysieren Zeitfenster und Schwellenwert verstehen erste Detection-Logik in Splunk SOC-Triage: Event, Muster, Verdacht Wichtiger Grundsatz dieser Folge: Ein Event ist noch kein Incident. Ein einzelner Failed Login ist noch kein Angriff. Kontext entscheidet. Diese Folge dient ausschließlich der Ausbildung und Analyse in einer eigenen isolierten Laborumgebung. Es werden keine fremden Systeme angegriffen oder gescannt. Logbuch 443: Jeder Angriff hinterlässt Spuren. Die Frage ist nur, ob jemand hinsieht.