# Chkrootkit: Die zweite Meinung im Security-Audit

TL;DR / Management Summary Ein einzelnes Sicherheits-Tool kann blind sein. chkrootkit ist die ideale Ergänzung zu rkhunter (Artikel 350). Es ist ein spezialisiertes Shell-Skript, das nach Signaturen von über 70 bekannten Rootkits sucht und Anomalien in der Prozessliste und im /proc Dateisystem aufdeckt. Ein Senior Admin nutzt chkrootkit als Teil eines mehrschichtigen Audit-Verfahrens, um die Wahrscheinlichkeit unentdeckter Hintertüren zu minimieren.

# 1. Einführung & Architektur

Wie chkrootkit sucht.

Im Gegensatz zu rkhunter, das stark auf Hash-Vergleiche setzt, fokussiert sich chkrootkit auf Verhaltens-Anomalien:

• WTMX Checks: Findet gelöschte Einträge in den Login-Datenbanken.
• LKM Checks: Sucht nach Anzeichen für bösartige Kernel-Module.
• Strings Analysis: Scannt Binaries nach typischen Hacker-Kommentaren.

# Der Vergleich (Mermaid)

graph LR
    A[Security Audit] --> B[rkhunter: Baseline & Hashes]
    A --> C[chkrootkit: Behavioral Analysis]
    C --> D[Scan for deleted log entries]
    C --> E[Check for hidden processes]
    C --> F[Scan /dev/last for suspicious activity]
    D/E/F --> G{Alert if INFECTED}

# 2. Nutzung von chkrootkit

Schnell und effizient.

# Installation

sudo apt install chkrootkit # Debian/Ubuntu
sudo dnf install chkrootkit # RHEL/Rocky

# Scan starten

sudo chkrootkit

Achten Sie auf Meldungen, die mit INFECTED oder suspicious markiert sind.

# 3. Fortgeschrittene Suche

Tiefgreifende Analyse.

# Nur Fehlermeldungen anzeigen

sudo chkrootkit -q

# Suche nach versteckten Dateien (LKM)

Angreifer nutzen oft Kernel-Module, um Dateien vor ls zu verstecken. chkrootkit vergleicht die Sicht des Kernels mit der Sicht des Dateisystems.

# 4. Day-2 Operations: Der externe Scan

Vertrauen ist gut, Live-CD ist besser.

Wenn ein System kompromittiert ist, kann der Angreifer den chkrootkit-Befehl selbst manipulieren, damit er immer “NOT INFECTED” zurückgibt.

# Die Goldene Regel

Führen Sie chkrootkit niemals nur vom laufenden System aus, wenn Sie einen echten Verdacht haben.

1. Booten Sie den Server von einem Live-ISO (z.B. Arch ISO).
2. Mounten Sie die Festplatten des Servers nach /mnt.
3. Führen Sie chkrootkit mit dem Pfad zum gemounteten System aus:

   sudo chkrootkit -r /mnt

# 5. Troubleshooting & “War Stories”

Vermeiden Sie Panik durch Fehlalarme.

# Story 1: “Der Fehlalarm durch PHP”

Symptom: chkrootkit meldet The following suspicious files were found: /usr/lib/php/.../.libs/libphp.... Ursache: Viele Build-Systeme (wie für PHP oder Python Module) nutzen versteckte Verzeichnisse (.libs), die chkrootkit als verdächtig einstuft. Lösung: Überprüfen Sie den Dateityp (Artikel 263). Wenn es sich um eine legitime Library Ihrer Distribution handelt, ignorieren Sie die Meldung.

# Story 2: “Das hängende Last-Log”

Symptom: chkrootkit bricht beim Test lastlog ab oder braucht 10 Minuten. Ursache: Eine korrupte lastlog Datei (oft durch Disk-Fehler). Lösung: Löschen Sie die Datei (sie wird vom System neu angelegt) oder prüfen Sie das Dateisystem mit fsck.

# 6. Fazit & Empfehlung

• Routine: Lassen Sie chkrootkit einmal pro Monat automatisiert laufen.
• Zweifach-Check: Ein “Clean” von rkhunter bedeutet nicht, dass chkrootkit nichts findet. Nutzen Sie beide Tools.
• Minimalismus: Installieren Sie chkrootkit nur zum Zeitpunkt des Scans oder nutzen Sie eine portable Version, um keine Spuren auf dem System zu hinterlassen.

# Anhang: Cheatsheet