Linux absichern mit KI: Security-Checks installieren, automatisieren, auswerten

Was dieser Artikel behandelt

• Die fünf Kernwerkzeuge rkhunter, chkrootkit, ClamAV, Lynis und AIDE: Installation auf Debian, Ubuntu, Fedora, Arch und CachyOS, dazu die nötige Erstkonfiguration.
• Ein Cron-Turnus: welcher Check täglich, welcher wöchentlich und welcher monatlich läuft.
• Ein Security-Chef-Skript als Template, das nur Wichtiges prüft: offene Ports, neue Benutzer, fehlgeschlagene Logins und veränderte Systemdateien.
• Alarmierung über Mail hinaus: Push mit Priorität, Signal, SMS-Gateway, Anruf, lokale Signale, Eskalationsstufen und Heartbeat-Überwachung, damit auch Schweigen auffällt.
• Die KI-Schicht: lokale Modelle fassen die Logfiles zusammen und sortieren Befund von Routine.

Das konzeptionelle Fundament, warum klassische Scanner plus KI die richtige Kombination sind, steht in Linux-Server absichern: Rootkit-Scanner, Lynis und die KI im Logfile. Dieser Artikel ist der praktische Teil: Befehle, Konfiguration, Zeitplan.

Die fünf Werkzeuge und ihre Aufgabe

Werkzeug	Aufgabe	Sinnvoller Rhythmus
rkhunter	Rootkits, Backdoors, veränderte Systemdateien per Signatur und Hash	Wöchentlich plus nach jedem Update --propupd
chkrootkit	Zweiter Rootkit-Scanner mit anderer Methode, deckt rkhunter-Blindspots ab	Wöchentlich
ClamAV	Malware-Signaturen in Dateien, sinnvoll für Downloads und Home-Verzeichnisse	Wöchentlich, Signaturen täglich per freshclam
Lynis	Härtungs-Audit der gesamten Konfiguration, liefert Hardening-Index	Monatlich oder nach größeren Umbauten
AIDE	Integritäts-Datenbank: meldet jede Änderung an überwachten Dateien	Wöchentlich, Datenbank sauber initialisieren

Dazu kommen zwei Checks, die kein extra Tool brauchen: offene Ports über ss und die Benutzerliste über /etc/passwd. Beides gehört in den täglichen Lauf, weil neue Listener und neue Accounts die ersten Anzeichen eines Einbruchs sind.

Installation auf allen Distributionen

Debian und Ubuntu

sudo apt update
sudo apt install rkhunter chkrootkit clamav clamav-daemon lynis aide

Debian bringt bei rkhunter eine Cron-Integration mit: in /etc/default/rkhunter steuerst Du den automatischen Lauf (CRON_DAILY_RUN="true"). AIDE initialisierst Du unter Debian nicht mit aide --init, sondern mit dem Wrapper:

sudo aideinit
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Fedora

sudo dnf install rkhunter chkrootkit clamav clamav-update lynis aide

Fedora trennt die Signatur-Updates in clamav-update. Damit freshclam läuft, musst Du einmalig in /etc/freshclam.conf die Zeile Example entfernen oder auskommentieren, sonst verweigert das Tool den Dienst. Danach:

sudo freshclam
sudo systemctl enable --now clamav-freshclam

AIDE initialisierst Du klassisch mit sudo aide --init und verschiebst die neue Datenbank an den konfigurierten Zielpfad.

Arch Linux und CachyOS

sudo pacman -S rkhunter chkrootkit clamav lynis arch-audit

Zwei Arch-Besonderheiten: Erstens liegt AIDE nicht in den offiziellen Repos, sondern im AUR, Du brauchst also einen AUR-Helper wie yay oder paru (yay -S aide) und solltest Dir das PKGBUILD vor dem Bauen ansehen. Zweitens gibt es mit arch-audit ein Arch-eigenes Werkzeug, das installierte Pakete gegen die CVE-Datenbank prüft. Das ist auf einem Rolling-Release-System Pflicht, weil Sicherheitslücken dort über Paket-Updates hereinkommen:

arch-audit

Erstkonfiguration der fünf Werkzeuge

rkhunter

sudo rkhunter --update     # Signaturen laden
sudo rkhunter --propupd    # Datei-Eigenschaften als Baseline speichern
sudo rkhunter --check --sk # Unbeaufsichtigter Scan ohne Rückfragen

Der Schritt --propupd ist entscheidend: Er speichert die aktuellen Datei-Hashes als Referenz. Ohne ihn meldet jeder Scan legitime Paketdateien als verändert. Nach jedem größeren apt upgrade, dnf upgrade oder pacman -Syu wiederholst Du ihn, sonst ertrinkst Du in Fehlalarmen.

Fehlalarme, die bleiben, whitelistest Du in /etc/rkhunter.conf über Einträge wie ALLOWHIDDENDIR oder SCRIPTWHITELIST. Log liegt unter /var/log/rkhunter.log.

chkrootkit

Braucht keine Konfiguration, nur einen sinnvollen Aufruf:

sudo chkrootkit -q

Der Modus -q (quiet) zeigt nur Funde und Infiziertes, nicht die hunderte Zeilen „nothing found”. Für Cron genau richtig.

ClamAV

sudo freshclam                      # Signaturen aktualisieren
sudo clamscan -r -i /home /root /tmp --log=/var/log/clamav/home-scan.log

-i zeigt nur infizierte Dateien, -r scannt rekursiv. Den Daemon clamd brauchst Du nur, wenn Mail oder Upload-Verzeichnisse dauerhaft gescannt werden sollen, auf einem Arbeitsplatz reicht der Cron-Scan.

Lynis

sudo lynis audit system

Der Report landet in /var/log/lynis-report.dat, das Log in /var/log/lynis.log. Für Cron nutzt Du lynis audit system --cronjob, dann läuft das Audit ohne Ausgabe-Formatierung und schreibt nur die Dateien.

AIDE

AIDE vergleicht Dateien gegen eine Datenbank von Checksummen. Die Datenbank erstellst Du einmal auf dem frisch installierten, sauberen System:

# Debian: aideinit, Fedora/Arch: aide --init
sudo aide --init
# Danach die neue Datenbank an den in /etc/aide.conf definierten Pfad legen

Der wöchentliche Check ist dann sudo aide --check. Nach legitimen Systemänderungen (Updates, Konfigurationsarbeit) aktualisierst Du die Datenbank mit aide --update, sonst meldet der nächste Lauf die Update-Änderungen als Angriff.

Der Cron-Turnus: Täglich, wöchentlich, monatlich

Häufigkeit	Check	Befehl
Täglich	Security-Chef-Schnelllauf: Ports, Benutzer, Failed Logins, ausstehende Updates	security-chef.sh
Wöchentlich	rkhunter + chkrootkit	rkhunter --check --sk, chkrootkit -q
Wöchentlich	AIDE-Integritätsprüfung	aide --check
Wöchentlich	ClamAV auf Home- und Download-Verzeichnisse	clamscan -r -i
Monatlich	Lynis-Härtungsaudit	lynis audit system --cronjob
Nach Updates	rkhunter-Baseline und AIDE-Datenbank erneuern	rkhunter --propupd, aide --update

Die Crontab dazu:

# Täglicher Schnellcheck um 6 Uhr
0 6 * * * /usr/local/bin/security-chef.sh

# Sonntags 4 Uhr: Rootkit-Scanner und Integrität
0 4 * * 0 /usr/bin/rkhunter --check --sk --nocolors > /var/log/security-weekly.log 2>&1
15 4 * * 0 /usr/sbin/chkrootkit -q >> /var/log/security-weekly.log 2>&1
30 4 * * 0 /usr/bin/aide --check >> /var/log/security-weekly.log 2>&1

# Sonntags 5 Uhr: ClamAV auf Home-Verzeichnisse
0 5 * * 0 /usr/bin/clamscan -r -i /home --log=/var/log/clamav/weekly-scan.log

# Erster Tag im Monat, 3 Uhr: Lynis-Audit
0 3 1 * * /usr/sbin/lynis audit system --cronjob

Das Security-Chef-Template: nur Wichtiges prüfen

Der tägliche Lauf soll leicht sein und nur melden, wenn etwas von der Norm abweicht. Das Template speichert Baselines und vergleicht:

#!/bin/bash
# /usr/local/bin/security-chef.sh
BASE=/var/lib/security-chef
REPORT=/var/log/security-chef.log
mkdir -p "$BASE"

{
echo "=== Security-Check $(date -Iseconds) ==="

# 1. Offene Ports gegen Baseline
ss -tulpn | awk 'NR>1 {print $5}' | sort > /tmp/ports-now.txt
if [ ! -f "$BASE/ports.txt" ]; then
  cp /tmp/ports-now.txt "$BASE/ports.txt"
elif ! diff -q "$BASE/ports.txt" /tmp/ports-now.txt > /dev/null; then
  echo "WARNUNG: Port-Liste hat sich geändert:"
  diff "$BASE/ports.txt" /tmp/ports-now.txt
fi

# 2. Neue Benutzer oder Accounts mit UID 0
awk -F: '$3 >= 1000 || $3 == 0 {print $1":"$3}' /etc/passwd > /tmp/users-now.txt
if [ ! -f "$BASE/users.txt" ]; then
  cp /tmp/users-now.txt "$BASE/users.txt"
elif ! diff -q "$BASE/users.txt" /tmp/users-now.txt > /dev/null; then
  echo "WARNUNG: Benutzerliste hat sich geändert:"
  diff "$BASE/users.txt" /tmp/users-now.txt
fi

# 3. Fehlgeschlagene Logins der letzten 24h
FAILED=$(journalctl _COMM=sshd --since "24 hours ago" 2>/dev/null | grep -c "Failed password")
[ "$FAILED" -gt 20 ] && echo "WARNUNG: $FAILED fehlgeschlagene SSH-Logins in 24h"

# 4. Ausstehende Sicherheits-Updates (je nach Distro anpassen)
if command -v apt > /dev/null; then
  apt list --upgradable 2>/dev/null | grep -c -i secur
elif command -v pacman > /dev/null; then
  arch-audit | wc -l
elif command -v dnf > /dev/null; then
  dnf updateinfo list security 2>/dev/null | wc -l
fi

echo "=== Ende ==="
} >> "$REPORT"

Beim ersten Lauf legt das Skript die Baselines für Ports und Benutzer an und meldet nichts. Ab dem zweiten Lauf schlägt es nur noch an, wenn die Realität vom gespeicherten Zustand abweicht. Das ist der Punkt: Ein Check, der täglich „alles ok” brüllt, wird ab Tag drei nicht mehr gelesen.

Benachrichtigung und Alarmierung: Ergebnisse müssen Dich erreichen

Ein Log, das niemand liest, ist kein Monitoring. Eine Mail reicht dabei nicht: Sie landet im Spam, im Ordner, den Du abends nicht mehr öffnest, oder sie kommt gar nicht an, weil der Angreifer den MTA gleich mit lahmgelegt hat. Im Sicherheitsfall zählen drei Dinge: Der Kanal erreicht Dich zuverlässig, die Dringlichkeit passt zum Befund, und es gibt eine Meldung auch dann, wenn das System selbst schon kompromittiert ist.

Kanäle im Überblick

Kanal	Werkzeug	Stärke	Haken
Push	ntfy, Gotify	Self-hosted, ein curl-Aufruf, Prioritäten	Öffentlicher Dienst sieht Deine Themen, selbst hosten ist sauberer
Messenger	Telegram-Bot, signal-cli, Matrix	Reichweite, Gruppen möglich	Account und App nötig, Drittanbieter-Infrastruktur
SMS	Android-Gateway, GSM-Stick, Dienste wie seven.io	Erreicht Dich ohne Internet auf dem Empfängerhandy	Kosten oder zusätzliche Hardware
Anruf	Twilio, Asterisk	Weckt Dich nachts	Kosten, Konfigurationsaufwand
Lokal	notify-send, wall, KDE Connect, Signalton	Kein Drittdienst nötig	Wirkt nur, wenn Du am Gerät sitzt
Remote-Syslog	rsyslog, syslog-ng	Log liegt außerhalb des angegriffenen Systems	Braucht zweite Maschine

ntfy und Gotify. ntfy läuft selbst-gehostet oder als öffentlicher Dienst und ist ein einzelner curl-Befehl:

curl -H "Priority: urgent" -H "Title: Security-Warnung" \
  -d "$(tail -20 /var/log/security-chef.log)" \
  https://ntfy.sh/dein-geheimes-thema

Der Header Priority: urgent ist der entscheidende Unterschied zur Mail: Auf dem Android-Client kommt die Meldung als lauter Alarm durch, auch wenn das Telefon auf lautlos steht. Gotify ist die Alternative, komplett self-hosted mit Weboberfläche und eigenem Android-Client, und ebenfalls ein POST-Request pro Meldung.

Signal über signal-cli. Wer Telegram nicht mag, nimmt signal-cli: Der Daemon läuft headless auf dem Server, Du registrierst eine eigene Nummer oder verknüpfst Dein Konto, und schickst Warnungen direkt an Dich oder eine Gruppe:

signal-cli -u +49DEINENUMMER send -m "$(tail -10 $REPORT)" +49EMPFÄNGER

SMS als Fallback. Für den Ernstfall ohne Datenvolumen: Ein altes Android-Handy mit einer SMS-Gateway-App (etwa die Open-Source-App sms-gate) wird zum eigenen Gateway, das per HTTP-POST SMS verschickt. Alternativ ein USB-GSM-Stick mit gammu-smsd direkt am Server, dann braucht der Alarm nicht einmal das Internet.

Anruf für den roten Alarm. Über Twilio oder eine eigene Asterisk-Anlage kann das Skript bei KRITISCH-Meldungen einen Sprachanruf auslösen. Aufwand und Kosten lohnen sich erst bei Systemen, bei denen eine Stunde Verzug richtig wehtut. Für ein Homelab reicht meist die Push-Priorität.

Lokale Alarme. Sitzt Du am Gerät, reichen notify-send "Security" "$(tail -5 $REPORT)" für die Desktop-Benachrichtigung oder wall für alle angemeldeten Terminals. Auf einem Pi kann ein Piezo-Buzzer oder eine per Home Assistant angesteuerte Lampe rot blinken, das klingt verspielt, ist aber der Kanal, der garantiert nicht versandet.

Eskalationsstufen statt Alarm für alles

Der Fehler vieler Setups ist ein einziger Kanal für jede Meldung. Baue drei Stufen:

Stufe	Beispiel	Reaktion
Info	Tagesdigest, normale Update-Hinweise	Wöchentliche ntfy-Meldung, keine Eile
Warnung	Geänderte Portliste, neue Benutzer, viele Failed Logins	Sofortige Push-Meldung mit Priority high
Kritisch	AIDE meldet veränderte Systembinärdateien, Rootkit-Fund	Push mit Priority urgent plus SMS plus Remote-Syslog

Im Skript ist das ein zweiter grep: WARNUNG geht an ntfy, KRITISCH löst zusätzlich SMS und Remote-Log aus. Die KI-Schicht kann dabei helfen, die Stufe vorzuschlagen, die Zuordnung im Skript bleibt aber regelbasiert, damit kein Fehlurteil einen kritischen Fund zur Info degradiert.

Der stille Alarm: Heartbeat statt Nachricht

Das gefährlichste Szenario ist nicht der laute Alarm, sondern das Schweigen: Angreifer deaktivieren als Erstes Cronjobs und Logging. Dagegen hilft die umgekehrte Logik, ein Dead-Man-Switch. Das Skript pingt am Ende jedes Laufs eine URL bei einem Healthcheck-Dienst an, etwa healthchecks.io oder eine self-hosted Alternative:

curl -fsS --retry 3 https://healthchecks.io/ping/dein-uuid-token

Meldet sich der Check nicht wie erwartet, alarmiert der Dienst Dich. Du bekommst also nicht nur Meldungen, wenn etwas gefunden wurde, sondern auch dann, wenn Dein Wächter selbst ausgefallen ist. Dieselbe Idee gilt für Remote-Syslog: Die Security-Logs gehen zusätzlich an eine zweite Maschine, damit ein Angreifer die Spuren nicht durch Löschen der lokalen Logs verwischen kann.

Der einfache Einstieg bleibt: Hänge den Versand ans Ende des Skripts, aber nur, wenn der Report WARNUNG-Zeilen enthält:

if grep -q "WARNUNG" "$REPORT"; then
  curl -H "Priority: high" -d "$(tail -20 $REPORT)" https://ntfy.sh/dein-geheimes-thema
fi
curl -fsS https://healthchecks.io/ping/dein-uuid-token   # Heartbeat immer

Die KI-Schicht: Logs lesen lassen statt selbst zu lesen

Die Scanner produzieren pro Lauf hunderte Zeilen. Die KI-Aufgabe ist Einordnung: Was davon ist Routine, was ist ein echter Befund? Dafür zwei Grundsätze.

Lokal statt Cloud. Security-Logs enthalten Benutzernamen, Pfade, interne Dienstnamen und im Zweifel Hinweise auf Schwachstellen Deines Systems. Das schickst Du nicht an einen Cloud-Dienst. Ein lokales Modell über Ollama reicht für die Zusammenfassung völlig aus:

cat /var/log/security-weekly.log | \
  ollama run llama3.2 "Fasse diesen Security-Log zusammen. \
  Liste nur echte Warnungen und verdächtige Funde. \
  Wenn nichts Auffälliges dabei ist, antworte nur: alles sauber."

Die Ausgabe hängst Du an die ntfy-Benachrichtigung. Statt 400 Zeilen Rohlog bekommst Du drei Sätze. Die Incident-Triage mit Befehlen für auth.log, auditd und Persistence-Suche steht im KI-Log-Checker.

Die KI entscheidet nicht, sie sortiert. rkhunter und AIDE entscheiden deterministisch, ob sich etwas verändert hat. Das Modell soll diese Funde einordnen und beschreiben, aber Du lässt es keine Funde wegfiltern. Ein Filter-Prompt, der „Unwichtiges” unterdrückt, ist ein Risiko: Wenn das Modell einen echten Befund falsch einstuft, siehst Du ihn nie. Die Regel lautet: KI fasst zusammen, alle WARNUNG-Zeilen gehen ungekürzt durch.

Ergänzende Werkzeuge für die Routine

• fail2ban bannt IPs nach wiederholten Fehlversuchen und gehört auf jedes System mit offenem SSH-Port. Der Security-Chef-Zählcheck oben ist die Diagnose, fail2ban ist die Abwehr.
• auditd protokolliert Systemaufrufe und Dateizugriffe auf Kernel-Ebene. Aufwand höher, aber für Forensik nach einem Vorfall unschlagbar.
• unattended-upgrades (Debian), dnf-automatic (Fedora) oder diszipliniertes pacman -Syu (Arch): zeitnahe Updates bleiben die effektivste Einzelmaßnahme.
• debsecan auf Debian listet CVEs der installierten Pakete, das Debian-Gegenstück zu arch-audit.

Grenzen und was das Setup nicht leistet

Diese Werkzeuge erkennen bekannte Rootkits, Signatur-Malware und Veränderungen gegenüber einer Baseline. Sie finden keine Zero-Days, keinen einmalig geloggten legitimen Missbrauch und nichts in Containern oder VMs, die sie nicht sehen. AIDE schützt nur, wenn die Datenbank auf einem sauberen Stand aufgebaut wurde und nach Updates gepflegt wird. Und jeder Cron-Check läuft nur so zuverlässig, wie jemand die Warnungen liest, deshalb die Benachrichtigung. Wer die Methoden hinter den Tools selbst lernen will, findet Übungsumgebungen im Artikel zu Security-Labs mit KI und bei IRC-Security.de weiteres Material rund um Sicherheit und Netzwerktechnik.

Häufige Fragen zu Linux Security-Checks mit KI

In welcher Reihenfolge richte ich die Werkzeuge ein?

Erst Lynis für den Ist-Zustand, dann rkhunter und chkrootkit mit Baseline, dann AIDE auf dem sauberen System, dann ClamAV, zuletzt Cron und Benachrichtigung. AIDE immer zuletzt vom Fundament her, weil die Datenbank den sauberen Endzustand abbilden soll.

Warum brauche ich rkhunter und chkrootkit parallel?

Beide nutzen unterschiedliche Erkennungsmethoden und Signaturen. rkhunter prüft Hash-Werte und Dateieigenschaften, chkrootkit testet bekannte Rootkit-Muster direkt. Was der eine übersieht, findet mitunter der andere.

Melde ich jeden AIDE-Fund sofort?

Nein. Nach Paket-Updates meldet AIDE massenhaft legitime Änderungen. Deshalb gehört aide --update nach jedem Systemupdate in die Routine. Erst dann sind die Funde des nächsten Laufs aussagekräftig.

Kann ich die KI-Analyse auch in die Cloud schicken?

Technisch ja, aber Security-Logs enthalten sensible Details über Dein System. Die lokale Analyse über Ollama ist für reine Zusammenfassungen ausreichend und lässt die Daten auf der Maschine.

Was ist, wenn rkhunter dauerhaft denselben Fehlalarm meldet?

Prüfe den Fund einmal manuell. Ist er legitim, trägst Du die Datei oder das Verzeichnis in /etc/rkhunter.conf über die Whitelist-Einträge ein statt den Scanner abzuschalten.

Lohnt sich clamd auf einem Desktop?

Meist nicht. Der Daemon kostet dauerhaft RAM und lohnt sich für Mail- oder Upload-Verzeichnisse. Für den wöchentlichen Home-Scan reicht clamscan per Cron.

Wie erkenne ich neue Benutzer zuverlässig?

Über den Baseline-Vergleich von /etc/passwd wie im Template. Zusätzlich lohnt der Blick auf Accounts mit UID 0, denn legitimes System darf nur root dort stehen haben.

Deckt arch-audit alles auf CachyOS ab?

arch-audit prüft gegen die Arch-CVE-Datenbank. CachyOS nutzt eigene Paketquellen mit teils abweichenden Versionen, deshalb bleibt es eine gute Annäherung, aber kein vollständiges Bild. Zusätzlich hilft regelmäßiges pacman -Syu.

Reicht ein wöchentlicher Rootkit-Scan?

Für Arbeitsplätze und Heimserver ja. Server mit öffentlichen Diensten fahren tägliche Scans sinnvoll. Wichtiger als die Frequenz ist, dass die Baselines nach Updates gepflegt werden.

Was mache ich bei einem echten rkhunter-Fund?

Nicht hektisch löschen. Erst den Fund verifizieren: Datei-Hash gegen Paketdatenbank prüfen (dpkg -V oder rpm -Va), Logzeitraum eingrenzen, im Zweifel System vom Netz nehmen und forensisch vorgehen. Der KI-Log-Checker-Artikel beschreibt die Triage-Schritte.

Kann ich das Template auf einem Raspberry Pi laufen lassen?

Ja, alle genannten Werkzeuge laufen auf ARM. Achte nur darauf, dass clamscan recht speicherhungrig ist und auf einem Pi länger braucht, der Cron darf das in der Nacht erledigen.

Warum filtert die KI nicht selbst unwichtige Meldungen raus?

Weil ein Fehlurteil des Modells dann echte Funde verschluckt, ohne dass Du es merkst. Die KI fasst zusammen und sortiert, aber jede WARNUNG-Zeile geht vollständig durch die Benachrichtigung.

Brauche ich fail2ban, wenn der Security-Chef Failed Logins zählt?

Ja. Der Zähler meldet das Problem, fail2ban löst es. Zählen ohne Blockieren bedeutet, dass Du jede Nacht über Brute-Force-Versuche informiert wirst, ohne dass etwas passiert.

Wie teste ich, ob die Benachrichtigung funktioniert?

Füge testweise eine Zeile echo "WARNUNG: Testmeldung" ins Skript ein, führe es einmal aus und prüfe, ob ntfy oder Telegram anspringt. Danach die Testzeile wieder entfernen.

Gelten die Befehle auch für Ubuntu-Derivate wie Mint oder Pop!_OS?

Ja, alle Debian-basierten Systeme nutzen dieselben Paketnamen und Pfade. Ebenso verhält es sich bei Fedora-Spinoffs und Arch-Derivaten wie CachyOS oder EndeavourOS mit pacman beziehungsweise AUR.

Worum es bei der Linux-Absicherung wirklich geht

Die Werkzeuge sind der leichte Teil, die Routine ist der schwere. Wer rkhunter installiert, aber die Baseline nie pflegt, und AIDE aufbaut, aber die Warnungen nie liest, hat Aufwand ohne Schutz betrieben. Das Gerüst hier löst genau das: Baselines statt Alles-loggen, ein Schnellcheck der nur Abweichungen meldet, eine Benachrichtigung die Dich erreicht, und eine lokale KI, die aus den Logbergen drei lesbare Sätze macht. Damit wird aus fünf Einzeltools der Chef, der Dein System wirklich im Blick hält.