KI-Log-Checker: Linux-Logs analysieren beim Security-Incident (Befehle + Automatisierung)

IRC-Mania Die Seite rund um Sicherheit und Programmierung

Internet, Sicherheit , Internet Relay Chat

Gesponsert

Was dieser Artikel behandelt

• Die Linux-Log-Landkarte: Welche Logdatei wo liegt (auth.log vs. secure, journalctl, audit.log, wtmp/btmp, bash_history).
• Die Befehl-Triage beim Security-Incident: verdächtige Logins, Failed-Logins, Shell-History, auditd, Persistence (Cron, systemd, ld.so.preload), SSH-Backdoor-Keys, /proc-Forensik.
• Wie man Logs lokal mit KI analysiert (Ollama, LogWhisperer, logllama, Sentinel) vs. Cloud-Dienste, und warum lokal bei Security-Logs die richtige Wahl ist.
• Automatisierte Meldungen: systemd-Timer + LLM + Discord/Slack/Telegram-Alert.

Einleitung

Beim Verdacht auf einen Security-Incident ist die Uhr der Feind: Wer eingedrungen ist, hinterlässt Spuren in Logs, und die erste Frage ist immer „welche Logs, welche Befehle”. Dieser Artikel ist die Checkliste plus der KI-Layer: wie ein lokales LLM die rohen Zeilen einordnet und automatisiert meldet, ohne dass die Logs je Deinen Server verlassen.

Die Linux-Log-Landkarte: Welche Log wo

Auf reinen systemd-Systemen gibt es die Textdateien eventuell nicht, dann: journalctl -u ssh -u sshd -S "2026-09-22 01:00:00" --no-pager.

Security-Incident-Triage: Die Befehle

1. Wer ist (erfolgreich) reingekommen?

# Erfolgreiche SSH-Logins (Debian/Ubuntu)
grep -E "Accepted (publickey|password)" /var/log/auth.log | tail -25

# Dasselbe auf RHEL/Fedora
grep "Accepted" /var/log/secure | tail -25

# Wer ist gerade eingeloggt + letzte Logins
who
last -20
lastlog | grep -v "Never"

2. Failed-Login-Sturm (Brute Force)

# Fehlgeschlagene Logins aus btmp (nicht im Text-Log!)
sudo lastb | head -20

# Häufigste Angreifer-IPs
grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head

3. Was wurde ausgeführt? Shell-History + auditd

# History des Users (Achtung: Angreifer löschen das oft)
cat /home/user/.bash_history | tail -50
cat /root/.bash_history | tail -50

# Besser: auditd liefert kernel-seitig JEDE Ausführung
sudo ausearch -m EXECVE --start recent | tail -100
sudo ausearch -i -m EXECVE --start today        # lesbar (-i = interpret)
sudo aureport --failed                          # fehlgeschlagene Events
sudo aureport -x --summary                      # alle execve-Aufrufe

auditd sieht, was die History verheimlicht, weil es im Kernel sitzt. Wichtige Regeln zum Vorsorgen (in /etc/audit/rules.d/):

-a always,exit -F arch=b64 -S execve -S execveat -k exec
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k privilege
-w /etc/cron.d/ -p wa -k persistence
-w /etc/systemd/system/ -p wa -k persistence
-w /root/.ssh/ -p wa -k persistence
-w /etc/ld.so.preload -p wa -k preload

4. Persistence finden: Wo der Angreifer „Tag 2” versteckt

# Alle Crontabs (versteckte Jobs!)
for u in $(cut -d: -f1 /etc/passwd); do echo "== $u"; crontab -l -u $u 2>/dev/null; done
ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/ /var/spool/cron/crontabs/

# systemd-Timer (die moderne Cron-Tarnung)
systemctl list-timers --all

# Neue Service-Dateien
ls -lt /etc/systemd/system/ /lib/systemd/system/ | head -15

# Shell-Startup-Skripte
grep -r "curl\|wget\|base64\|nc " /etc/profile.d/ ~/.bashrc ~/.profile /etc/profile 2>/dev/null

5. SSH-Backdoor-Keys

# Alle authorized_keys auf dem System finden
sudo find / -name "authorized_keys" -type f 2>/dev/null

# Inhalt prüfen, unbekannte Keys?
cat /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys 2>/dev/null

# Zuletzt geänderte Dateien systemweit (Angreifer-Artefakte)
sudo find / -ctime -2 -type f 2>/dev/null | grep -v -E "^/(proc|sys|run|dev|var/log)"

6. /proc-Forensik: Was rootkits nicht verstecken können

Ein userspace-Rootkit (LD_PRELOAD) kann Prozesse vor ps verstecken. /proc ist die Wahrheit:

# Exe eines verdächtigen Prozesses
sudo ls -l /proc/<PID>/exe

# Gelöschte, aber noch laufende Binaries (klassisches Rootkit-Zeichen)
sudo ls -l /proc/*/exe 2>/dev/null | grep "(deleted)"

# Prozess-Umgebung und Kommandozeile
sudo cat /proc/<PID>/cmdline | tr '\0' ' '; echo
sudo cat /proc/<PID>/environ | tr '\0' '\n' | grep -i "preload\|ld_"

# Der klassische Preload-Rootkit-Check
cat /etc/ld.so.preload 2>/dev/null    # sollte leer sein!
ls -la /etc/ld.so.preload

7. Wichtig zu wissen: Logs sind manipulierbar

Ein ernsthafter Angreifer löscht auth.log-Zeilen und bash_history. Gegenbeweise: auditd (Kernel), wtmp/btmp (Binärformat, schwerer zu editieren), Remote-Syslog (die Kopie auf dem zentralen Server kann der Angreifer nicht fälschen) und Datei-Timestamps. Immer mehrere Quellen kreuzen.

KI-Analyse der Logs: Lokal vs. Cloud

Cloud-Warnung zuerst: Security-Logs enthalten IPs, Usernamen, Hostnamen, teils interne Pfade, also genau das, was ein Angreifer bräuchte. Das Einfügen von auth.log in ChatGPT oder eine Web-API ist ein Datenschutz- und Sicherheitsproblem. Deshalb: lokale LLMs via Ollama sind für Log-Analyse die richtige Wahl. Siehe Lokale KI und Ollama.

Fertige lokale KI-Log-Tools

Die klassische DIY-Pipeline (self-hosted, 0 €)

Das Pattern hinter allen diesen Tools ist dasselbe und in ~50 Zeilen baubar:

# 1. Logs sammeln (hier: letzte auth.log-Fails)
grep "Failed password" /var/log/auth.log | tail -100 > /tmp/fails.txt

# 2. An lokales Ollama geben
ollama run llama3.1:8b "Du bist Linux-Sysadmin. Analysiere diese Failed-Logins:
Muster? IPs? Brute Force oder gezielt? Antworte kurz + strukturiert.
$(cat /tmp/fails.txt)"

# 3. Automatisieren: systemd-Timer alle 5 min
#    journalctl/Loki → Python → Ollama-API → Klassifizierung → Alert

Produktiv ausgebaut (das ist exakt der LogWhisperer/Sentinel-Weg):

journalctl -f  (oder Loki-Query alle 5 min)
  → Keyword-Gate (nur ERROR/Failed/Accepted-Pattern, kein LLM nötig)
  → Ollama-LLM: „Noise oder Anomaly: [Grund]?"
  → wenn Anomaly → Alert an Discord/Slack/Telegram/n8n-Webhook
  → Dedup-Cache: gleiche Signatur nicht doppelt melden

Empfohlene lokale Modelle: llama3.1:8b für Security-Logs, gemma2:9b für allgemeine Analyse (beide ~5-6 GB RAM in Q4). N8N kann denselben Flow auch ohne Python bauen, siehe Beste n8n-Workflows.

Wichtig: KI klassifiziert, Du entscheidest

Das LLM ist der Vorfilter (Rauschen raus, Muster erklären), nicht der Forensiker. Die Beweisführung bleibt bei den Befehlen oben. Gute Tools wie logllama erzwingen „belege jede Behauptung mit der Log-Zeile”, genau das sollte Dein Prompt auch fordern: „Nenne die Zeilennummer als Beleg. Keine Annahmen.”

Die Incident-Checkliste (Reihenfolge)

1. Wer rein?     → grep "Accepted" auth.log/secure, last, lastlog
2. Wer versuchte?→ sudo lastb, Failed-password-IPs
3. Was lief?     → ausearch -m EXECVE --start recent, bash_history
4. Was bleibt?   → cron, systemd-timer, authorized_keys, ld.so.preload
5. Was läuft?    → /proc/*/exe (deleted), cmdline, environ
6. Absichern     → Keys revoken, Passwörter, Remote-Syslog, auditd-Regeln
7. Meldung       → KI-Pipeline auf Dauerbetrieb, nicht nur einmalig

Weiterführende Links

• IRC-Security.de: weitere Security-Artikel und Guides.
• IRC-Coding.de: Programmier-Tutorials und Coding-Artikel.
• Logging: Logging-Strategie.
• Monitoring: Alerting-Grundlagen.
• Agenten-Sicherheit: Guardrails.
• Ollama: Das lokale LLM hinter der Analyse.
• Beste n8n-Workflows: Alert-Automatisierung.
• Secrets richtig handhaben: Credentials in Logs nie mitschicken.

Key Takeaways:

• Distro-Karte: Debian/Ubuntu loggen Auth nach /var/log/auth.log, RHEL-Familie nach /var/log/secure, systemd-fallback journalctl -u ssh.
• Incident-Befehle: grep "Accepted", last/lastb, ausearch -m EXECVE --start recent, aureport --failed, crontab -l, systemctl list-timers, find / -name authorized_keys, /proc/PID/exe, /etc/ld.so.preload.
• Persistence-Check: Cron (alle User), systemd-Timer, Startup-Skripte, SSH-Keys, preload.
• KI-Analyse lokal via Ollama: LogWhisperer, logllama, log-explainer, Sentinel, oder DIY journalctl → LLM → Discord/Slack/n8n-Alert. Logs nie in die Cloud senden.
• Das LLM ist der Vorfilter, die Beweisführung machen die Befehle.

FAQ

Quellen und weiterführende Literatur

• LogWhisperer, logllama, log-explainer
• Sentinel / OpenClaw Log-Anomaly, AI Log Analysis mit Ollama
• auditd Incident Response, ausearch(8) man page
• IRC-Security.de: weitere Security-Artikel.
• IRC-Coding.de: Programmier-Tutorials.

Premium VPS Hosting

Schnelle und sichere VPS Server

Gesponsert