rkhunter: le bon moyen de gérer les avertissements plus loin?
J'ai googlé certains et vérifié deux premiers liens qu'il a trouvé:
- http://www.skullbox.net/rkhunter.php
- http://www.techerator.com/2011/07/how-to-detect-rootkits-in-linux-with-rkhunter/
Ils ne mentionnent pas ce que je devrais faire en cas de tels avertissements:
Warning: The command '/bin/which' has been replaced by a script: /bin/which: POSIX Shell script text executable
Warning: The command '/usr/sbin/adduser' has been replaced by a script: /usr/sbin/adduser: a /usr/bin/Perl script text executable
Warning: The command '/usr/bin/ldd' has been replaced by a script: /usr/bin/ldd: Bourne-Again Shell script text executable
Warning: The file properties have changed:
File: /usr/bin/lynx
Current hash: 95e81c36428c9d955e8915a7b551b1ffed2c3f28
Stored hash : a46af7e4154a96d926a0f32790181eabf02c60a4
Q1: Existe-t-il des procédures plus détaillées expliquant comment traiter différents types d'avertissements?
Et la deuxième question. Mes actions ont-elles été suffisantes pour résoudre ces avertissements?
a) Pour rechercher le package contenant le fichier suspect, par exemple c'est debianutils pour le fichier/bin/qui
~ > dpkg -S /bin/which
debianutils: /bin/which
b) Pour vérifier les sommes de contrôle du paquet debianutils:
~ > debsums debianutils
/bin/run-parts OK
/bin/tempfile OK
/bin/which OK
/sbin/installkernel OK
/usr/bin/savelog OK
/usr/sbin/add-Shell OK
/usr/sbin/remove-Shell OK
/usr/share/man/man1/which.1.gz OK
/usr/share/man/man1/tempfile.1.gz OK
/usr/share/man/man8/savelog.8.gz OK
/usr/share/man/man8/add-Shell.8.gz OK
/usr/share/man/man8/remove-Shell.8.gz OK
/usr/share/man/man8/run-parts.8.gz OK
/usr/share/man/man8/installkernel.8.gz OK
/usr/share/man/fr/man1/which.1.gz OK
/usr/share/man/fr/man1/tempfile.1.gz OK
/usr/share/man/fr/man8/remove-Shell.8.gz OK
/usr/share/man/fr/man8/run-parts.8.gz OK
/usr/share/man/fr/man8/savelog.8.gz OK
/usr/share/man/fr/man8/add-Shell.8.gz OK
/usr/share/man/fr/man8/installkernel.8.gz OK
/usr/share/doc/debianutils/copyright OK
/usr/share/doc/debianutils/changelog.gz OK
/usr/share/doc/debianutils/README.shells.gz OK
/usr/share/debianutils/shells OK
c) Pour me détendre à propos de /bin/which comme je vois bien
/bin/which OK
d) Mettre le fichier /bin/which en /etc/rkhunter.conf comme SCRIPTWHITELIST="/bin/which"
e) Pour les avertissements comme pour le fichier /usr/bin/lynx Je mets à jour la somme de contrôle avec rkhunter --propupd /usr/bin/lynx.cur
Q2: Est-ce que je résous ces avertissements correctement?
Utiliser debsums est une idée très intelligente avec un défaut majeur: si quelque chose devait écraser un fichier appartenant à la racine tel que /bin/which, il pourrait réécrire également /var/lib/dpkg/info/*.md5sums avec une somme de contrôle mise à jour. Autant que je sache, il n'y a pas de chaîne de contrôle menant à une signature Debian/Ubuntu. Ce qui est vraiment dommage, car ce serait un moyen très simple et très rapide de vérifier l’authenticité d’un fichier live.
Au lieu de vérifier réellement un fichier, vous devez télécharger une nouvelle copie de cette deb, extraire le control.tar.gz interne, puis regarder son fichier md5sums pour le comparer à un vrai md5sum /bin/which. C'est un processus douloureux.
Ce qui est probablement arrivé ici est que vous avez eu des mises à jour du système (même une mise à jour de la distribution) et que vous n'avez pas demandé à rkhunter de mettre à jour ses profils. rkhunter a besoin de savoir à quoi ressemblent les fichiers pour que les mises à jour du système le perturbent.
Une fois que vous savez que quelque chose est sûr, vous pouvez exécuter Sudo rkhunter --propupd /bin/which pour mettre à jour sa référence du fichier.
C'est l'un des problèmes avec rkhunter. Il nécessite une intégration poussée dans le processus deb afin que, lorsque des packages sécurisés et signés soient installés, rkhunter mette à jour ses références aux fichiers.
Et non, je ne mettrais pas la liste blanche comme ça parce que c'est exactement le genre de chose qu'un rootkit irait après.
zuba, l’idée de la liste blanche est mauvaise; il consiste à désattribuer un fichier à vérifier qui devrait être visible pour vous et votre anti-malware, l'idée est néanmoins utilisée et l'affichage du message est inoffensif. Pourrions-nous créer un écrit en lieu et place serait mieux. quelque part dans le sens des lignes commençant par\seront ignorées; mais cela demande une certaine expérience de codage et une connaissance intime du fonctionnement de rkhunter.
La corbeille/qui sera réécrite au besoin pour tenir compte des changements de programmation; En général, un fichier peut être remplacé ou créé temporairement et modifié ou disparu après un redémarrage, ce qui peut tromper le logiciel rkhunter.
Il existe une ligne où logiciels/mises à jour ou antimalwares ressemble à un rootkit, et je pense que ceux-ci en font partie.
La méthode que vous employez n’est dangereuse que si elle modifie un programme ou un fichier qui aura une incidence sur le fonctionnement de l’ordinateur. Parfois, nous sommes pires que nos machines à cet égard. Prouver cela pour votre ordinateur est vraiment injuste, comme je pourrais le faire si c'était le mien. Je saurais, documenter les avertissements et les sommes de contrôle et noter chaque fois qu'il y a un changement.