rkhunter warnt vor Inode-Änderungen, aber es ändert sich das Änderungsdatum der Datei nicht

8

Ich habe mehrere Systeme, auf denen Centos 6 mit installiertem rkhunter ausgeführt wird. Ich habe einen täglichen Cron, der rkhunter ausführt und per E-Mail zurückmeldet.

Ich bekomme sehr oft Berichte wie:

---------------------- Start Rootkit Hunter Scan ----------------------
Warning: The file properties have changed:
        File: /sbin/fsck
        Current inode: 6029384    Stored inode: 6029326
Warning: The file properties have changed:
        File: /sbin/ip
        Current inode: 6029506    Stored inode: 6029343
Warning: The file properties have changed:
        File: /sbin/nologin
        Current inode: 6029443    Stored inode: 6029531
Warning: The file properties have changed:
        File: /bin/dmesg
        Current inode: 13369362    Stored inode: 13369366

Soweit ich weiß, meldet rkhunter normalerweise ein geändertes Hash- und / oder Änderungsdatum für die gescannten Dateien an, sodass ich denke, dass es keine wirklichen Änderungen gibt.

Meine Frage: Gibt es eine andere Aktivität auf dem Computer, die die Inode-Änderung bewirken könnte (ext4 ausführen), oder werden wirklich yumregelmäßig (~ einmal pro Woche) Änderungen an diesen Dateien im Rahmen normaler Sicherheitsupdates vorgenommen?

centos yum rkhunter

— Nic Cottrell
quelle

8

Das Aktualisieren von Dateien erfolgt häufig durch Schreiben einer neuen Datei in dasselbe Verzeichnis und anschließendes Umbenennen der Datei über der alten Datei. Diese Methode wird normalerweise auf alles angewendet, was über einen Paketmanager installiert wird, aber auch auf alle Aktualisierungen, die an ausführbaren Dateien und Bibliotheken durchgeführt werden, selbst wenn diese aus anderen Gründen aktualisiert werden.

Durch diese Art der Aktualisierung von Dateien wird sichergestellt, dass bei jedem Vorgang, bei dem die Datei geöffnet wird, entweder die alte oder die neue Datei angezeigt wird und sich in der geöffneten Datei nichts ändert. Dies bedeutet, dass Sie bei jeder Aktualisierung tatsächlich eine neue Datei mit demselben Namen haben, daher hat sich die Inode-Nummer geändert.

Ich denke, dies ist der Grund dafür, dass diese Dateien eine neue Inode-Nummer haben.

Ein Sicherheitsupdate könnte ein Grund sein. Aber es gibt noch eine andere Möglichkeit, die ich zum ersten Mal bei Fedora Core 1 beobachtet habe, und die es sehr gut irgendwann in Centos geschafft haben könnte.

Ausführbare Dateien und Bibliotheken werden vorab verknüpft, damit sie schneller starten und weniger Speicher benötigen. Während dieses Vorgangs wird die Ladeadresse zufällig ausgewählt, um das Ausnutzen von Sicherheitslücken etwas zu erschweren. Ein Cron-Job wiederholt den Vorgang regelmäßig mit neuen zufälligen Adressen, wodurch alle vorverknüpften ausführbaren Dateien und Bibliotheken aktualisiert werden.

— Kasperd
quelle

2

Ja, das Vorverknüpfen scheint hier die wahrscheinlichste Erklärung zu sein.

— Michael Hampton

Gibt es eine gute Möglichkeit, damit umzugehen? Wenn ich nur einen Cron zum Laufen rkhunter --propupdhabe, könnte ich einen Hack verpassen und den ganzen Punkt von rkhunter ungültig machen, oder?

— Nic Cottrell

1

@NicholasTolleyCottrell rpmbehandelt dies, indem zuerst die Integrität der prelinkausführbaren Datei überprüft wird. Anschließend wird die prelinkausführbare Datei mit Argumenten aufgerufen, um die Vorverknüpfung mit der Eingabe einer vorverknüpften ausführbaren Datei und die Ausgabe in stdout zurückzusetzen. Dann rpmkann die Integrität dieser Ausgabe überprüft werden. Keine Ahnung, ob dieser Ansatz angewendet werden kann rkhunter.

— Kasperd

1

In diesem Thread erfahren Sie, wie Sie eine Prüfsumme erhalten, die nicht herumspringt : linuxquestions.org/questions/linux-security-4/… . Ich habe mich von rkhunter als Cron-basiertes Tool entfernt. Es gibt viele nützliche Überprüfungen, aber die Unfähigkeit, Überprüfungen zu deaktivieren, die zu falsch positiven Ergebnissen führen, macht es fast nutzlos, Ihre Aufmerksamkeit darauf zu lenken, wo sie benötigt werden, da ich mich nur daran gewöhne, die per E-Mail gesendeten Berichte zu ignorieren. Ich finde es immer noch gelegentlich nützlich als manuell ausgeführtes Tool.

— mc0e

2

Die andere Option, die ich gefunden habe, war, diese Eigenschaftstests vollständig zu deaktivieren. Wenn Sie /etc/rkhunter.confdie DISABLE_TESTSZeile bearbeiten, suchen und ändern in:

DISABLE_TESTS="suspscan hidden_procs deleted_files packet_cap_apps apps properties"

Der propertiesTest ist derjenige, der falsch positive Ergebnisse in den Datei-Hashes überprüft und zurückgibt.

— Nic Cottrell
quelle

1

Eine geänderte Inode-Nummer bedeutet normalerweise, dass die Datei ersetzt wurde. Es könnte, wie Sie sagen, an einem erwarteten Update liegen. Ich würde überprüfen, ob die MD5-Summen dieser Dateien mit denen der verteilten Versionen übereinstimmen. Wenn Sie ein anderes vergleichbares System haben, ist es möglicherweise am einfachsten, dies zu vergleichen.

Werfen Sie einen Blick auf die akzeptierte Antwort bei Änderungen der Dateieigenschaften von rkhunter-Berichten, aber ich sehe nicht, dass sie von yum aktualisiert wurden, um zu überprüfen, aus welchem Paket diese Binärdateien stammen.

Es wäre nicht allzu überraschend, wenn diese Binärdateien aus einer Distribution stammen würden, die aufgrund eines Problems mit einer anderen geänderten Binärdatei aktualisiert wurde. Die von Ihnen aufgelisteten Binärdateien wurden jedoch unverändert in die neue Version des Pakets aufgenommen. Hat Ihr Bericht auch einige binäre zeigen , wo der Inhalt wurde geändert?

— mc0e
quelle

Nein, eigentlich habe ich anscheinend nur erhalten, dass sich die Dateieigenschaften geändert haben - niemals, dass sich der Inhalt geändert hat.

— Nic Cottrell

-1

Ich habe ein Laufwerk auf ein größeres Laufwerk geklont und die Warnungen von Dateien mit unterschiedlichen Inodes-Nummern erhalten. Ich habe rkhunter aus dem System entfernt und erneut installiert und den Scan erneut ausgeführt, ohne dass Warnungen bezüglich der Änderung der Inodes-Nummern vorliegen

— will Smith
quelle