rkhunter avertit d'un changement d'inode mais pas de changement de date de modification de fichier

8

J'ai plusieurs systèmes exécutant Centos 6 avec rkhunter installé. J'ai un crkh quotidien qui exécute rkhunter et fait un rapport par e-mail.

Je reçois très souvent des rapports comme:

---------------------- 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

D'après ce que je comprends, rkhunter rapportera généralement une date de hachage et / ou de modification modifiée sur les fichiers numérisés, ce qui m'amène à penser qu'il n'y a pas de réel changement.

Ma question: y a-t-il une autre activité sur la machine qui pourrait faire le changement d'inode (exécutant ext4) ou est-ce vraiment yumapporter des changements réguliers (~ une fois par semaine) à ces fichiers dans le cadre des mises à jour de sécurité normales?

centos yum rkhunter Nic Cottrell
la source

Réponses:

8

La mise à jour des fichiers se fait souvent en écrivant un nouveau fichier dans le même répertoire, puis en renommant le fichier par-dessus l'ancien fichier. Cette méthode est généralement appliquée à tout ce qui est installé via un gestionnaire de packages, mais également à toute mise à jour effectuée sur les exécutables et les bibliothèques, même si elle est mise à jour pour d'autres raisons.

Cette façon de mettre à jour les fichiers garantit que tout processus ouvrant le fichier obtiendra l'ancien ou le nouveau et ne verra rien changer dans le fichier qu'ils ont ouvert. Cela signifie que chaque fois qu'il est mis à jour, vous aurez en fait un nouveau fichier avec le même nom, donc le numéro d'inode a changé.

Je suppose que c'est la raison pour laquelle ces fichiers ont un nouveau numéro d'inode.

Une mise à jour de sécurité pourrait être l'une des raisons. Mais il y a une autre possibilité, que j'ai observée pour la première fois sur Fedora Core 1, et qui aurait très bien pu devenir Centos à un moment donné.

Les exécutables et les bibliothèques sont pré-liés de manière à pouvoir démarrer plus rapidement et utiliser moins de mémoire. Au cours de ce processus, l'adresse de chargement est randomisée pour rendre l'exploitation des vulnérabilités de sécurité un peu plus difficile. Un travail cron répéterait périodiquement le processus avec de nouvelles adresses aléatoires, ce qui entraînerait la mise à jour de tous les exécutables et bibliothèques pré-liés.

kasperd
la source
2
Oui, le pré-lien semble l'explication la plus probable ici.
Michael Hampton
Existe-t-il un bon moyen de gérer cela? Si j'ai juste un cron à exécuter, rkhunter --propupdje pourrais manquer un hack et invalider tout le point de rkhunter, non?
Nic Cottrell
1
@NicholasTolleyCottrell le rpmgère en vérifiant d'abord l'intégrité de l' prelinkexécutable, puis il appelle l' prelinkexécutable avec des arguments pour rétablir la pré-liaison avec l'entrée d'un exécutable pré-lié et la sortie vers stdout. Ensuite, rpmpeut vérifier l'intégrité de cette sortie. Aucune idée si cette approche peut être appliquée rkhunter.
kasperd
1
Voir ce fil pour savoir comment obtenir une somme de contrôle qui ne sautera pas: linuxquestions.org/questions/linux-security-4/… . Je me suis éloigné de rkhunter en tant qu'outil basé sur cron. Il a beaucoup de vérifications utiles, mais l'impossibilité de désactiver les vérifications qui équivalent à des faux positifs le rend presque inutile pour attirer votre attention là où il est nécessaire, car je viens de m'habituer à ignorer ses rapports envoyés par e-mail. Je le trouve encore parfois utile comme outil exécuté manuellement.
mc0e
2

L'autre option que j'ai trouvée était de désactiver complètement ces tests de propriétés. Si vous modifiez /etc/rkhunter.confet recherchez la DISABLE_TESTSligne et la changez en:

DISABLE_TESTS="suspscan hidden_procs deleted_files packet_cap_apps apps properties"

Le propertiestest est celui qui vérifie et renvoie les faux positifs sur les hachages de fichiers.

Nic Cottrell
la source
1

Un numéro d'inode modifié signifie généralement que le fichier a été remplacé. Cela pourrait, comme vous le dites, être dû à une mise à jour prévue. Je vérifierais que les sommes md5 de ces fichiers correspondent à celles des versions distribuées. Si vous avez un autre système comparable, il pourrait être plus facile de le comparer.

Jetez un oeil à la réponse acceptée aux changements de rkhunter dans les propriétés des fichiers, mais je ne vois pas qu'ils ont été mis à jour par yum pour savoir de quel paquet proviennent ces binaires.

Il ne serait pas trop surprenant que ces binaires proviennent d'une distribution qui a été mise à jour en raison d'un problème avec un autre binaire qui a été modifié, mais les binaires que vous répertoriez ont été inclus dans la nouvelle version du package inchangés. Votre rapport a-t-il également montré un fichier binaire dont le contenu a été modifié?

mc0e
la source
Non, en fait, il semble que je n'ai jamais reçu que les propriétés du fichier ont changé - jamais le contenu.
Nic Cottrell
-1

J'ai cloné un disque sur un disque plus grand et j'ai reçu les avertissements de fichiers avec différents numéros d'inodes. J'ai retiré rkhunter du système et j'ai réinstallé et exécuté à nouveau l'analyse sans aucun avertissement concernant le changement des numéros d'inodes

va forger
la source