Rootkit-Erkennung mit rkhunter und chkrootkit

1. Was rkhunter und chkrootkit wirklich prüfen

rkhunter (Rootkit Hunter) und chkrootkit sind keine Antivirenprogramme im klassischen Sinn, sondern Diagnosewerkzeuge, die den aktuellen Zustand eines Linux-Systems gegen bekannte Auffälligkeiten und einen gespeicherten Referenzzustand prüfen. Beide arbeiten größtenteils als Shell-Skripte, die Systembinaries, Kernelmodule, Netzwerkschnittstellen und Konfigurationsdateien durchsuchen und Abweichungen melden, die typisch für eine Kompromittierung sind. Kein einzelner Test beweist eine Infektion für sich allein, jeder Test liefert lediglich einen Hinweis, der im Kontext bewertet werden muss.

Der Wert beider Tools liegt in der Kombination vieler kleiner, spezifischer Prüfungen: MD5-Prüfsummen von /bin und /sbin, bekannte Dateinamen und Verzeichnisse historischer Rootkits, verdächtige SUID-Bits, versteckte Einträge im Netzwerk-Interface-Status und Diskrepanzen zwischen verschiedenen Systemaufrufen zur Prozessliste. Wer rkhunter und chkrootkit als zusätzliche Kontrollschicht neben Firewall, SSH-Härtung und regelmäßigen Updates versteht, gewinnt echten Mehrwert. Wer sie als vollständige Absicherung missversteht, verschätzt sich systematisch.

2. Signaturbasierte Erkennung bekannter Rootkits

Der Kern von rkhunter ist eine gepflegte Datenbank bekannter Rootkit-Signaturen: charakteristische Dateinamen, Verzeichnisstrukturen und Byte-Muster, die von dokumentierten Rootkit-Familien wie Adore, T0rn, Suckit oder Beastkit hinterlassen wurden. Bei jedem Lauf gleicht rkhunter --check das Dateisystem gegen diese Liste ab und meldet Treffer als Warning. chkrootkit verfolgt denselben Ansatz mit einem eigenen, kleineren Satz an Tests, die gezielt nach Strings und Artefakten bekannter LKM-Trojaner und User-Space-Rootkits suchen.

Diese Signaturdatenbanken werden über rkhunter --update aktualisiert und ziehen neue Definitionen von den konfigurierten Mirrors. Entscheidend ist: Ein Treffer bedeutet, dass exakt dieses bekannte Muster gefunden wurde, keine heuristische Bewertung von „verdächtigem“ Verhalten. Genau das macht die Erkennung präzise bei bekannten Bedrohungen, aber wirkungslos gegenüber jedem Rootkit, das nicht in der Datenbank steht, weil es neu, custom entwickelt oder gezielt für das Zielsystem geschrieben wurde.

#!/usr/bin/env bash
# Update the signature database, then run a signature-focused check
rkhunter --update
rkhunter --versioncheck

# Run only the known-rootkit signature tests
rkhunter --check --enable known_rkts --disable all

3. Dateiintegrität und verdächtige Berechtigungen

Ein zweiter zentraler Prüfbereich ist die Integrität kritischer Systembinaries. rkhunter erstellt bei der ersten Ausführung von rkhunter --propupd eine Baseline mit MD5-Hashes und Metadaten von Dateien wie /bin/login, /usr/sbin/sshd oder /bin/ps. Bei jedem folgenden Lauf werden diese Hashes neu berechnet und mit der gespeicherten Baseline verglichen. Eine Abweichung heißt entweder: Die Datei wurde durch ein legitimes Paket-Update ersetzt, oder sie wurde durch ein trojanisiertes Binary ausgetauscht, das dieselbe Funktion vortäuscht, aber zusätzlich Hintertüren enthält.

Ergänzend prüfen beide Tools auf unerwartete SUID- und SGID-Bits, Dateien mit ungewöhnlichen Eigentümern in /etc und /dev, sowie versteckte Dateien mit führendem Punkt in untypischen Systempfaden, ein klassisches Versteck für Rootkit-Komponenten. debsums -c oder rpm -Va liefern eine zweite, unabhängige Bestätigung, da sie gegen die Paketverwaltung statt gegen eine lokal gespeicherte Baseline prüfen, was für Cross-Checks bei einem Verdachtsfall wichtig ist.

4. Versteckte Prozesse und Netzwerk-Anomalien aufspüren

Klassische Rootkits manipulieren Systemwerkzeuge wie ps, netstat oder ls so, dass bestimmte Prozesse, Ports oder Dateien in der Ausgabe verschwinden. chkrootkit enthält dafür den Test chkproc, der die Prozessliste aus /proc direkt mit der Ausgabe von ps vergleicht. Eine Diskrepanz, ein Prozess, der in /proc existiert, aber in ps fehlt, ist ein starkes Indiz für eine manipulierte Systembinary oder ein Loadable-Kernel-Module-Rootkit, das Systemaufrufe abfängt.

rkhunter ergänzt das um Netzwerkprüfungen: Es kontrolliert, ob eine Netzwerkschnittstelle im Promiscuous-Modus läuft, was auf einen installierten Sniffer hindeuten kann, und prüft bekannte Backdoor-Ports gegen eine Liste typischer Trojaner-Standardports. Beide Ansätze sind wertvoll, aber begrenzt: Ein sauber implementiertes Kernel-Rootkit kann sowohl die /proc-Daten als auch die Netzwerk-Statistiken auf Kernel-Ebene fälschen, sodass selbst dieser Kreuzvergleich keine verlässliche Aussage mehr liefert.

#!/usr/bin/env bash
# Compare /proc process list against ps output directly (chkrootkit's chkproc logic)
chkrootkit -x chkproc

# Check network interfaces for promiscuous mode manually
ip link show | grep -i promisc

# List listening ports to cross-check against rkhunter's backdoor port list
ss -tulpn

5. Installation und Erstkonfiguration

Auf Debian- und Ubuntu-Systemen installieren sich beide Tools über die Standard-Paketquellen: apt install rkhunter chkrootkit. Direkt nach der Installation sollte rkhunter --update ausgeführt werden, um die aktuelle Signaturdatenbank zu ziehen, gefolgt von rkhunter --propupd, um die Datei-Baseline auf einem als sauber angenommenen System zu erstellen. Diese Reihenfolge ist wichtig: Eine Baseline auf einem bereits kompromittierten System schreibt die manipulierten Dateien als „normal“ fest und macht das Werkzeug wertlos.

Die Konfigurationsdatei /etc/rkhunter.conf steuert unter anderem, ob True-Positive-Meldungen für bekannte, legitime Systemabweichungen unterdrückt werden. Auf Systemen mit Docker, ungewöhnlichen SSH-Konfigurationen oder Konfigurationsmanagement-Tools erzeugt eine unkonfigurierte Standardinstallation regelmäßig False Positives, die die Aussagekraft echter Warnungen verwässern. Eine saubere Erstkonfiguration reduziert diesen Rauschpegel, bevor das Tool in den produktiven Baseline-Betrieb übergeht.

; /etc/rkhunter.conf - selected production settings
; Automatically update signature mirrors before each check
UPDATE_MIRRORS=1
MIRRORS_MODE=0

; Disable interactive prompts for unattended cron execution
CRON_DAILY_RUN=true
CONFIGFILE_CHECK=1

; Explicitly document why root SSH login is (not) allowed here
ALLOW_SSH_ROOT_USER=no
ALLOW_SSH_PROT_V1=0

; Whitelist scripts flagged as false positives after manual review
SCRIPTWHITELIST=/usr/bin/whatis
SCRIPTWHITELIST=/usr/bin/lwp-request

; Package manager used to cross-check file properties
PKGMGR=DPKG

6. Baseline erstellen und als Cronjob planen

Der eigentliche Nutzen entsteht erst durch regelmäßige, automatisierte Läufe. Das Debian-Paket richtet standardmäßig einen täglichen Cronjob unter /etc/cron.daily/rkhunter ein, der Ergebnisse per Mail verschickt, sofern CRON_DAILY_RUN=true in /etc/default/rkhunter gesetzt ist. Für chkrootkit muss ein eigener Cronjob oder systemd-Timer angelegt werden, da es keinen integrierten Scheduler mitbringt. Wichtig ist, dass nach jedem legitimen System-Update rkhunter --propupd erneut ausgeführt wird, sonst meldet jeder folgende Lauf dieselben, längst erklärten Dateiänderungen als neue Warnungen.

Diese Baseline-Pflege ist der Punkt, an dem viele Betreiber scheitern: Ein Scanner, der bei jedem Lauf zwanzig erwartete Warnungen produziert, wird nach kurzer Zeit ignoriert, und genau dann geht ein echter Fund unter. Ein sauberer Betrieb protokolliert jede Abweichung, ordnet sie einer bekannten Ursache zu und aktualisiert die Baseline erst nach dieser Prüfung, nie automatisch und ungesehen.

#!/usr/bin/env bash
# Run after every verified package update to avoid stale-baseline false positives
apt full-upgrade -y
rkhunter --propupd
rkhunter --check --sk --report-warnings-only >> /var/log/rkhunter-manual.log

# Unattended nightly run with warnings-only output for alerting pipelines
rkhunter --check --sk --nocolors --report-warnings-only
echo "Exit code: $?"   # 0 = clean, 1 = warnings found

7. Die Grenzen: was diese Tools nicht erkennen können

Die wichtigste Einschränkung ist strukturell: Beide Tools erkennen primär, was bereits bekannt und in ihrer Signaturdatenbank hinterlegt ist. Ein neu entwickeltes, gezielt für ein bestimmtes System geschriebenes Rootkit, ein sogenanntes Custom- oder Zero-Day-Rootkit, taucht in keiner Signaturdatenbank auf und wird von der signaturbasierten Erkennung schlicht nicht gefunden. Auch ein Angreifer mit Root-Rechten kann theoretisch die lokal gespeicherte Baseline selbst manipulieren, sodass ein manipuliertes Binary fortan als „bekannt und korrekt“ gilt.

Kernel-Level-Rootkits stellen die größte Herausforderung dar: Sie können Systemaufrufe auf einer Ebene abfangen, die unterhalb von rkhunter und chkrootkit liegt, und damit genau die Daten fälschen, auf die sich beide Tools verlassen, etwa die Ausgabe von /proc oder Netzwerkstatistiken. Für belastbare Ergebnisse sollte ein Verdachtsfall daher immer zusätzlich mit Werkzeugen geprüft werden, die außerhalb des potenziell kompromittierten Systems laufen, etwa Live-Boot-Medien, externe Integritätsprüfungen oder Netzwerk-Traffic-Analysen von einem separaten Host aus.

8. Einen positiven Fund richtig interpretieren

Eine Meldung mit Warning ist kein Beweis für eine Kompromittierung, sondern ein Hinweis, der Nacharbeit erfordert. Der erste Schritt ist immer, den konkreten Testnamen im Log nachzuschlagen (/var/log/rkhunter.log) und zu klären, welche Datei oder welches Verhalten genau angeschlagen hat. Bei Dateiänderungen hilft der Abgleich mit dpkg -V paketname oder debsums, ob die Änderung durch ein reguläres Paket-Update erklärbar ist. Stimmen beide Quellen überein, handelt es sich meist um einen erklärbaren False Positive, der nach Prüfung in die Baseline übernommen werden kann.

Bestätigt sich der Verdacht dagegen, etwa weil ein Binary weder durch dpkg noch durch ein bekanntes Update erklärt werden kann und zusätzlich chkrootkit unabhängig denselben Bereich als auffällig meldet, ist das System als kompromittiert zu behandeln. Ab diesem Punkt gilt: keine forensische Analyse mit den möglicherweise manipulierten Bordmitteln des betroffenen Systems selbst durchführen, den Host vom Netzwerk isolieren, Datenträger-Images für eine Offline-Analyse sichern und im Zweifel neu aufsetzen statt zu „bereinigen“, da ein vollständig sauberer Zustand nach einer Root-Kompromittierung praktisch nicht garantierbar ist.

{
  "check": "rootkit_scan_summary",
  "host": "shop-prod-02",
  "timestamp": "2026-07-12T03:05:00Z",
  "tool": "rkhunter",
  "tests_run": 312,
  "warnings": 1,
  "findings": [
    {
      "test": "File properties changed",
      "path": "/usr/sbin/sshd",
      "expected_md5": "a1b2c3d4e5f6",
      "current_md5": "9f8e7d6c5b4a",
      "explained_by_update": true,
      "package_version": "1:9.6p1-3ubuntu13.5"
    }
  ],
  "status": "reviewed_false_positive",
  "baseline_updated": "2026-07-12T03:10:00Z"
}

9. rkhunter vs. chkrootkit im Vergleich

Beide Tools ergänzen sich, statt sich zu ersetzen: rkhunter ist umfangreicher konfigurierbar und pflegt eine größere, aktiv aktualisierte Signaturdatenbank samt Baseline-Funktion, während chkrootkit schlanker ist und mit dem chkproc-Test einen unabhängigen zweiten Blick auf die Prozessliste liefert. Der größte praktische Nutzen entsteht, wenn beide parallel laufen: Stimmen die Ergebnisse überein, steigt die Verlässlichkeit eines Fundes deutlich.

In der Praxis bewährt sich ein wöchentlicher oder täglicher Lauf beider Tools mit strukturierter Log-Auswertung, statt sich auf ein einzelnes Werkzeug zu verlassen. Die Kombination reduziert blinde Flecken, ersetzt aber in keinem Fall eine vollständige Sicherheitsstrategie mit Firewall, Härtung, Zugriffsprotokollierung und regelmäßigen Updates.

10. Zusammenfassung

rkhunter und chkrootkit prüfen bekannte Rootkit-Signaturen, Dateiintegrität gegen eine gespeicherte Baseline und Diskrepanzen in Prozess- und Netzwerkdaten, die auf manipulierte Systemwerkzeuge hindeuten. Beide Tools sind wertvolle, kostenlose Bausteine einer Sicherheitsstrategie, wenn sie regelmäßig als Baseline-Check per Cronjob laufen, ihre Signaturdatenbanken aktuell gehalten werden und die Datei-Baseline nach jedem legitimen Update mit rkhunter --propupd gepflegt wird.

Die zentrale Grenze bleibt strukturell: Signaturbasierte Erkennung findet nur, was bereits bekannt ist, ein neues oder gezielt entwickeltes Rootkit bleibt unentdeckt. Ein positiver Fund ist immer ein Hinweis, kein Beweis, er verlangt manuelle Nachprüfung gegen die Paketverwaltung und im Zweifel eine Analyse von außerhalb des betroffenen Systems. Wer rkhunter und chkrootkit als eine von mehreren Kontrollschichten neben Firewall, Härtung und Monitoring einsetzt, statt sie als vollständige Absicherung zu betrachten, gewinnt einen realistischen und nachhaltigen Sicherheitsgewinn.

11. FAQ: Rootkit-Erkennung mit rkhunter und chkrootkit