rkhunter: bonne façon de gérer les avertissements plus loin?

J'en ai recherché sur Google et vérifié les deux premiers liens qu'il a trouvés:

1. http://www.skullbox.net/rkhunter.php
2. http://www.techerator.com/2011/07/how-to-detect-rootkits-in-linux-with-rkhunter/

Ils ne mentionnent pas ce que je dois 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 HowTos plus étendus qui expliquent comment gérer différents types d'avertissements?

Et la deuxième question. Mes actions ont-elles été suffisantes pour résoudre ces avertissements?

a) Pour trouver le paquet qui contient le fichier suspect, par exemple ce sont des 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 /bin/whichcomme je vois bien

/bin/which                                                                    OK

d) Pour mettre le fichier /bin/whichen /etc/rkhunter.conftant queSCRIPTWHITELIST="/bin/which"

e) Pour les avertissements comme pour le fichier, /usr/bin/lynxje mets à jour la somme de contrôle avecrkhunter --propupd /usr/bin/lynx.cur

Q2: Dois-je résoudre ces avertissements correctement?

L'utilisation debsumsest 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 également être réécrit /var/lib/dpkg/info/*.md5sumsavec une somme de contrôle mise à jour. Il n'y a pas de chaîne de possession sur une signature Debian / Ubuntu, à ma connaissance. 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 en direct.

Au lieu de cela, pour vraiment vérifier un fichier, vous devez télécharger une nouvelle copie de ce deb, extraire le control.tar.gzfichier interne , puis regarder son fichier md5sums pour le comparer avec un réel md5sum /bin/which. C'est un processus douloureux.

Ce qui s'est probablement produit ici, c'est que vous avez eu quelques mises à jour du système (même une mise à niveau de la distribution) et que vous n'avez pas demandé à rkhunter de mettre à jour ses profils. rkhunter a besoin de savoir à quoi doivent ressembler les fichiers, donc toute mise à jour du système va le perturber.

Une fois que vous savez que quelque chose est sûr, vous pouvez exécuter sudo rkhunter --propupd /bin/whichpour mettre à jour sa référence du fichier.

C'est l'un des problèmes avec rkhunter. Il a besoin d'une intégration profonde dans le processus deb pour que lorsque des packages signés et approuvés sont installés, rkhunter met à jour ses références aux fichiers.

Et non, je ne mettrais pas en liste blanche des choses comme ça parce que c'est exactement le genre de chose qu'un rootkit rechercherait.

zuba, l'idée de la liste blanche est mauvaise; il n'attribue pas un fichier à vérifier qui devrait être visible pour vous et votre anti-malware, l'idée est cependant utilisée et la visualisation du message est inoffensive. Pourrions-nous plutôt créer un document écrit, ce serait mieux. quelque part le long des lignes de \ lignes commençant par \ sera ignoré; mais cela prend une certaine expérience de codage et une connaissance intime du fonctionnement de rkhunter.

Le bac / qui sera réécrit au besoin pour s'adapter aux changements de programmation; En général, un fichier peut être remplacé ou des fichiers peuvent être créés temporairement et modifiés ou disparaissent après un redémarrage, ce qui peut tromper le logiciel rkhunter.

Il existe une ligne où les logiciels / mises à jour ou anti-programmes malveillants ressemblent à un rootkit, et je pense que ce sont ceux-là.

La méthode que vous utilisez n'est dangereuse que si elle modifie un programme ou un fichier qui affectera (agira) d'une manière ou d'une autre le fonctionnement de l'ordinateur. Parfois, nous sommes pires que nos machines à cet égard. Il est vraiment injuste de le prouver pour votre ordinateur, comme je le pourrais si c'était le mien. Je saurais, documenterais les avertissements et les sommes de contrôle et noterais chaque fois qu'il y aurait un changement.