
- Konzentrieren Sie sich auf auth.log, syslog und kern.log – dort liegen die meisten Spuren.
- Nutzen Sie grep, um fehlgeschlagene Logins und unbekannte IPs zu filtern.
- Erkennen Sie Brute-Force-Angriffe durch Zählen der Fehlversuche pro IP (z. B. mehr als 10 in einer Stunde).
- Prüfen Sie erfolgreiche Logins von ungewöhnlichen Quellen und überwachen Sie Cron-Jobs sowie SUID-Dateien.
- Automatisieren Sie die Überwachung mit Tools wie fail2ban oder Logwatch, um keine Anomalie zu verpassen.
Die wichtigsten Log-Dateien identifizieren
Bevor wir uns in die Analyse stürzen, müssen Sie wissen, wo die entscheidenden Daten liegen. Ich empfehle, sich auf diese Dateien zu konzentrieren:
/var/log/auth.log– alle Authentifizierungsversuche (SSH, sudo, Login)/var/log/syslog– allgemeine Systemmeldungen/var/log/kern.log– Kernel-Meldungen (z. B. Fehler bei Treibern)/var/log/secure– auf RedHat/CentOS (entspricht auth.log)
Erstellen Sie eine Liste dieser Pfade und prüfen Sie, ob sie existieren und lesbar sind. (Ich habe schon erlebt, dass Logs fehlten, weil die Rotation zu aggressiv war.)
Wie filtere ich mit grep nach verdächtigen Mustern?
Der erste Angriffspunkt ist das Durchsuchen nach bekannten Signalen. Nutzen Sie den Befehl grep gezielt:
grep "Failed password" /var/log/auth.log | tail -20Achten Sie auf:
- Wiederholte fehlgeschlagene Logins
- Unbekannte Benutzernamen
- Zugriffe zu ungewöhnlichen Zeiten (z. B. 3 Uhr morgens)
Ich persönlich filtere immer zuerst nach „Failed password“ – das ist der Klassiker. Aber Vorsicht: Ein Angreifer kann auch über andere Dienste eindringen, also prüfen Sie auch Web-Server-Logs.
Brute-Force-Angriffe erkennen
Ein klassisches Einbruchssignal ist eine hohe Anzahl fehlgeschlagener Anmeldeversuche in kurzer Zeit. Führen Sie folgende Analyse durch:
- Zählen Sie die Anzahl der Fehlversuche pro IP:
grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head -10 - Identifizieren Sie IPs mit mehr als 10 Fehlversuchen innerhalb einer Stunde.
- Prüfen Sie, ob diese IPs auch erfolgreiche Logins hatten.
Diese Methode – die ich seit Jahren anwende – hat mir schon oft geholfen. Laut einer Studie von SecureWorks haben 73% aller Brute-Force-Angriffe weniger als 100 Versuche, bevor sie aufgeben. Aber die hartnäckigen Angreifer gehen weiter.
Für eine schnellere Reaktion auf Bedrohungen kann die manuelle Analyse durch eine Echtzeit-Log-Analyse unter Linux ergänzt werden, die sofort Alarme auslöst.
Erfolgreiche Logins von unbekannten Quellen prüfen
Ein Eindringling kann sich erfolgreich anmelden. Suchen Sie nach allen erfolgreichen SSH-Logins:
grep "Accepted publickey" /var/log/auth.logVergleichen Sie die IP-Adressen mit Ihrer Whitelist. Fragen Sie sich:
- Kenne ich diese IP?
- Stimmt der Benutzername?
- Ist der Login zu einer ungewöhnlichen Zeit erfolgt?
Ich habe einmal einen Fall gehabt, da war ein Login um 3:17 Uhr von einer IP in Russland – das war eindeutig ein Einbruch. (Der Kunde hatte keinen Remote-Mitarbeiter dort.)
Dateiänderungen und Cron-Jobs überwachen
Ein Angreifer installiert oft Hintertüren. Achten Sie auf:
- Neue Cron-Jobs:
crontab -lund/var/spool/cron/crontabs/ - Unbekannte SUID-Dateien:
find / -perm -4000 -type f 2>/dev/null - Versteckte Prozesse:
ps aux | grep -i "nc|netcat|perl|python"
Nutzen Sie auditd, um permanente Änderungen zu protokollieren. Das ist wie ein Überwachungskamera für Ihr System.
Logs mit journalctl durchsuchen (systemd-Systeme)
Wenn Ihr Server systemd nutzt, ist journalctl mächtiger als klassische Logs:
journalctl -u sshd.service --since "1 hour ago" | grep "Failed password"Tipp: Kombinieren Sie journalctl mit -o json-pretty, um strukturierte Daten zu erhalten und sie leichter zu analysieren. Das ist besonders nützlich, wenn Sie viele Logs haben.
Um Brute-Force-Angriffe automatisch abzuwehren, sollten Sie Fail2ban konfigurieren, das Logdateien überwacht und verdächtige IPs blockiert.
Häufige Fehler bei der Log-Analyse
Aus meiner Erfahrung als Systemarchitekt sehe ich immer wieder dieselben Fehler:
| Fehler | Folge | Lösung |
|---|---|---|
| Nur auf auth.log achten | Angreifer über andere Dienste übersehen | Prüfen Sie auch Apache/Nginx-Logs |
| Logs zu selten rotieren | Alte Logs werden überschrieben | Stellen Sie logrotate auf 90 Tage Aufbewahrung ein |
| Keine Alarme einrichten | Manuelle Prüfung reicht nicht | Nutzen Sie fail2ban oder Logwatch |
| Logs ohne Kontext lesen | Einzelner Fehlversuch wird überbewertet | Erst Kombination vieler Fehlversuche + erfolgreicher Login + Dateiänderung ist kritisch |
Ich selbst habe den Fehler gemacht, nur auf auth.log zu schauen – und prompt einen Angriff über den Webserver verpasst. Seitdem prüfe ich immer alle relevanten Logs.
FAQ – Häufige Fragen zur Erkennung von Eindringlingen
Wie erkenne ich, ob ein Angreifer bereits meine Logs gelöscht hat?
Prüfen Sie die Dateigröße von /var/log/auth.log mit ls -la. Fehlen Einträge oder ist die Datei leer, obwohl der Server läuft, könnte das ein Zeichen sein. Auch der Befehl last -f /var/log/wtmp zeigt, ob Logs manipuliert wurden.
Welches Tool ist am besten für Einsteiger geeignet?
Für den Anfang reicht grep und awk. Später können Sie Logwatch oder GoAccess (für Web-Logs) einsetzen. Diese Tools fassen Muster automatisch zusammen. Ich empfehle Logwatch, weil es eine übersichtliche E-Mail-Zusammenfassung liefert.
Was mache ich, wenn ich einen erfolgreichen Einbruch vermute?
Trennen Sie den Server sofort vom Netzwerk. Erstellen Sie eine Sicherung der Logs (cp /var/log/* /backup/). Analysieren Sie dann systematisch die oben genannten Schritte und informieren Sie Ihren Hosting-Provider. Zögern Sie nicht – jede Minute zählt.
Wie oft sollte ich Logs manuell prüfen?
Bei einem produktiven Server mindestens einmal pro Woche. Bei Hochrisiko-Diensten (z. B. SSH offen) täglich. Automatisierte Alarme sind jedoch zu empfehlen. Ich persönlich lasse Logwatch jede Nacht laufen und bekomme eine Morgenmail.
Haben Sie einen verdächtigen Log-Eintrag gefunden?
Teilen Sie Ihre Erfahrung in den Kommentaren – gemeinsam werden wir sicherer! Ich bin gespannt auf Ihre Geschichten.




