Ist Ihr SSH-Server sicher? Eine umfassende Analyse von Hacking-Indikatoren in SSH-Server-Protokollen

Ihr SSH-Server wird mit hoher Wahrscheinlichkeit hunderte Male pro Tag angegriffen. Es reicht nicht aus zu sagen, dass die Wahrscheinlichkeit hoch ist. Ich bin mir fast sicher, dass Ihr Server an einem Tag hunderte von Angriffen erlebt. Trotzdem öffnen viele Entwickler den /var/log-Ordner nahezu nie. Führen Sie doch einfach einmal den Befehl journalctl -f | grep ssh im Terminal aus.

Wenn Sie die Protokolle richtig lesen:

• Wer

• Wann

• Von wo

• Wie
  versucht hat, in den Server einzudringen.

In diesem Artikel werde ich aus der Perspektive eines Entwicklers wie man SSH-Server-Protokolle interpretiert und wie man Hacking-Indikatoren erkennt zusammenfassen.

1. Wo werden SSH-Protokolle gespeichert?

Der Standort der SSH-Protokolle variiert je nach Linux-Distribution.

Im Allgemeinen:

• Ubuntu / Debian-basierte Systeme

  • /var/log/auth.log

• CentOS / RHEL-basierte Systeme

  • /var/log/secure

• Gemeinsame systemd-Befehle

  • journalctl -u ssh.service oder journalctl -u sshd

Sie können tail verwenden, aber ich persönlich bevorzuge es, die Protokolle über journald einzusehen, da alle Logdateien an einem Ort gesammelt werden.

# Beispiel für Ubuntu
sudo tail -f /var/log/auth.log

# Beispiel für CentOS/RHEL
sudo tail -f /var/log/secure

# Echtzeitansicht der systemd-Dienstprotokolle
sudo journalctl -u ssh.service -f

tipp: Selbst auf einem Entwicklungsserver ist es ratsam, sich gelegentlich die „Überwachung“ der Protokolle mit tail -f zur Gewohnheit zu machen.

Für detaillierte Informationen zur Verwendung von journald klicken Sie hier.

2. Analyse einer Zeile im SSH-Protokoll

Schauen wir uns eine typische Zeile im SSH-Protokoll an, um die Struktur zu verstehen. (Beispiel für Ubuntu)

2.1 Erfolgreiche Anmeldung mit Schlüssel

Jan 10 12:34:56 myserver sshd[12345]: Accepted publickey for deploy from 203.0.113.10 port 50312 ssh2: ED25519 SHA256:xxxx

Die Bedeutung jedes Teils:

• Jan 10 12:34:56 : Datum, Uhrzeit

• myserver : Hostname

• sshd[12345] : Prozessname (SSH-Daemon) und PID

• Accepted publickey : Authentifizierung erfolgreich, Methode ist der öffentliche Schlüssel

• for deploy : Benutzername des angemeldeten Kontos

• from 203.0.113.10 : Ursprungs-IP der Verbindung

• port 50312 : Client-Seiten-Port

• ssh2: ED25519 ... : Protokoll-/Schlüsseltyp-Informationen

Wenn Sie das verstehen, können Sie schnell feststellen, „wer von wo mit welchem Schlüssel verbunden hat“.

2.2 Fehlgeschlagene Passwortanmeldung

Jan 10 12:35:01 myserver sshd[12346]: Failed password for root from 198.51.100.23 port 50320 ssh2

• Failed password : Fehlgeschlagene Passwortauthentifizierung

• for root : Versuch mit dem root-Konto

• from 198.51.100.23 : Remote-IP

Fällt so eine Logzeile mehrere Male in wenigen Sekunden,
ist es so gut wie sicher ein Brute-Force-Angriff.

2.3 Versuch, sich mit nicht existentem Benutzer anzumelden

Jan 10 12:35:05 myserver sshd[12347]: Invalid user admin from 198.51.100.23 port 50325

• Invalid user admin : Versuch, sich mit dem nicht existierenden admin-Konto anzumelden

Dieses Muster wird ebenfalls häufig von automatisierten Bots verwendet.

3. Übliche Angriffsmuster anhand von Protokollen

3.1 Brute-Force-Angriff

Merkmale:

• Failed password-Logs treten in sehr kurzer Zeit vermehrt auf

• Versuche von der selben IP, die Dutzende bis Hunderte Male wiederholt werden

• Verwendung von Kontonamen wie root, admin, test, oracle

Hier ein schneller Überblick:

# Gesamtanzahl der fehlgeschlagenen Passwortversuche
sudo grep "Failed password" /var/log/auth.log | wc -l

# Welches Konto am häufigsten angegriffen wird
sudo grep "Failed password" /var/log/auth.log \
  | awk '{for (i=1;i<=NF;i++) if ($i=="for") print $(i+1)}' \
  | sort | uniq -c | sort -nr | head

3.2 Scan nach nicht existierenden Benutzern

sudo grep "Invalid user" /var/log/auth.log | head

Eine hohe Anzahl dieser Logs bedeutet, dass „hier versucht wird, auf gut Glück zu erraten, welche Konten auf diesem Server vorhanden sein könnten“.

3.3 Häufige Versuche von bestimmten IPs

Um herauszufinden, welche IPs besonders viel scheitern:

sudo grep "Failed password" /var/log/auth.log \
  | awk '{print $(NF-3)}' \
  | sort | uniq -c | sort -nr | head

Das $(NF-3) sorgt in der Regel für die IP, die zu from <IP> gehört,
aber je nach Umgebung kann es leicht variieren. Passen Sie daher die Logstruktur Ihren Bedürfnissen an.

4. Ungewöhnliche Anzeichen während erfolgreicher Anmeldungen

Angriffe enden oft im Scheitern, doch die wirklich beunruhigenden Vorfälle sind erfolgreiche Anmeldungen.

4.1 Protokolle erfolgreicher Anmeldungen sammeln

sudo grep "Accepted" /var/log/auth.log

Hier sollten Sie insbesondere auf Folgendes achten:

• Zugriffe von Konten, die normalerweise nicht verwendet werden

• Zugriffe zu unüblichen Zeiten (z.B. um 3 Uhr morgens)

• IPs aus seltsamen Ländern/Regionen (nicht IPs von Unternehmen/Häusern/VPNs)

4.2 Überblick über folgende Anmeldehistorie

Der Befehl last zeigt die letzten Anmeldeereignisse an.

# Letzte SSH-Anmeldehistorie
last -i | head

# Fehlgeschlagene Anmeldungen (in unterstützten Umgebungen)
lastb | head

Wenn Sie dies regelmäßig überprüfen,
könennen Sie leicht „Zugriffsprotokolle aus Zeiten, in denen ich nicht angemeldet war“ erkennen.

5. Praktische Protokollanalyse: Beispiel eines schnellen Prüfprotokolls

Angenommen, Sie haben einen SSH-Server,
hier ist ein Prüfprotokoll, das Sie in 5 Minuten durchführen können.

5.1 Schritt 1: Gesamtanzahl fehlgeschlagener Anmeldungen prüfen

sudo grep "Failed password" /var/log/auth.log | wc -l
sudo grep "Invalid user" /var/log/auth.log | wc -l

• Wenn die Zahlen plötzlich stark ansteigen, könnte dies auf eine „Zunahme der Angriffsintensität“ hindeuten.

5.2 Schritt 2: Top 10 angreifende IPs

sudo grep "Failed password" /var/log/auth.log \
  | awk '{print $(NF-3)}' \
  | sort | uniq -c | sort -nr | head

• Die Haupt-IP-Adressen können Sie in Ihre Firewall/fail2ban-Regeln einfügen.

5.3 Schritt 3: Anmeldungen mit root

sudo grep "Failed password for root" /var/log/auth.log | tail
sudo grep "Accepted.*root" /var/log/auth.log

• Wenn Accepted erscheint, bedeutet das, dass bereits eine erfolgreiche Anmeldung mit root sehr gefährlich ist.

5.4 Schritt 4: Scan nach zuletzt erfolgreichen Anmeldungen

sudo grep "Accepted" /var/log/auth.log | tail -n 50

Hier sind die zu prüfenden Punkte:

• Ist es eine mir unbekannte IP?

• Fand dies zu einer gewöhnlichen Arbeitszeit statt?

• Handelt es sich möglicherweise um ein neu aufgetauchtes Konto?

6. Was bringen Protokolle? Sofort anwendbare Abwehrmaßnahmen

Wenn Sie Angriffe anhand der Protokolle erkannt haben,
sollten Sie jetzt zu den Abwehrmaßnahmen übergehen.

6.1 Passwortanmeldung deaktivieren (nur Schlüssel zulassen)

In der Datei /etc/ssh/sshd_config:

PasswordAuthentication no
PubkeyAuthentication yes

Nach der Anpassung:

sudo systemctl reload sshd
# oder
sudo service ssh restart

Deaktivieren Sie unbedingt die Passwortanmeldung erst, nachdem Sie die Anmeldung mit einem öffentlichen Schlüssel getestet haben.
Sonst könnte es passieren, dass Sie selbst nicht mehr hineinkommen.

6.2 Direkte Anmeldung als root verbieten

PermitRootLogin no

Verhindern Sie, dass Sie direkt als root einloggen, und zwingen Sie die Nutzung eines normalen Kontos gefolgt von sudo.

6.3 Portwechsel (zur Reduzierung von Geräuschen)

Port 22    # -> Ändern Sie z. B. auf 2222

• Ein Portwechsel alleine erhöht nicht unbedingt die Sicherheit,

• allerdings verringert es erheblich die Anzahl an automatisierten Scans/Angriffsprotokollen,
  was dazu führt, dass „richtige Anomalien“ besser wahrgenommen werden.

6.4 Verwendung von Tools wie fail2ban

fail2ban überwacht die Protokolle und

• bei mehrfachen Anmeldefehlern von der gleichen IP in kurzer Zeit

fügt automatisch Regeln zur Firewall hinzu, um zu blockieren.

Das Konzept ist einfach:

1. Überwachung des Musters Failed password in auth.log

2. Wenn ein bestimmter Schwellenwert überschritten wird, wird die IP mit iptables/ufw blockiert

Das bedeutet, dass die Log-Analyse automatisiert wird, um Brute-Force-Angriffe automatisch zu blockieren.

6.5 Einschränkung des SSH-Zugangs über die Firewall

Wenn möglich:

• Erlauben Sie nur den Zugang über 22/tcp (oder den geänderten Port) von der Unternehmens-VPN oder einer bestimmten festgelegten IP

• Alle anderen Zugriffe blockieren

Beispiel: Einfaches Beispiel für ufw

sudo ufw allow from 203.0.113.50 to any port 22 proto tcp
sudo ufw deny 22/tcp

7. „Minimale Lebensprotokollüberprüfungsroutine“ für Entwickler

Wenn man die Sicherheitspraktiken für Entwickler im Alltag zusammenfasst, wird deutlich,
dass schon diese grundlegenden Schritte die Sicherheitssensitivität erheblich verändern.

Einmal pro Woche:

1. Überprüfen Sie die Anzahl der Failed password und Invalid user der letzten Woche

2. Prüfen Sie die Top 10 der fehlgeschlagenen IPs

3. Überprüfen Sie die Accepted-Protokolle und

   • ob es neue IPs gibt,

   • ungewöhnliche Zeiten,

   • oder seltsame Konten

4. Verdächtige IPs blockieren (z.B. mit Firewall/fail2ban)