Aujourd'hui, j'ai scanné ma machine avec le chkrootkit en cours d'exécution :
sudo chkrootkitEt voici une partie du résultat :
Vérification de `lkm'... Vous avez
2 processus cachés pour la commande readdir Vous avez 2 processus cachés pour la commande commande ps chkproc : Warning : Possible cheval de Troie LKM installé chkdirs : rien détecté
Y a-t-il lieu de s'inquiéter ? Et si oui, comment puis-je remédier à cette situation ?
Je fonctionne sous Ubuntu 14.10 et chkrootkit version 0.49.
Y a-t-il lieu de s'inquiéter ?
Non, c'est un faux positif et un bug de longue date dans chrootkit. Vous verrez le message chaque fois que la vérification lkm signale des processus cachés inaccessibles par la commande readdir. Si vous avez quelque chose comme ClamAV, MySQL, Exim ou MailScanner en cours d'exécution, vous verrez certainement cet avertissement.
Vérification la plus simple : exécutez chrootkit plusieurs fois avec autant de services arrêtés (par exemple, mysql, clamav, etc.). Si les résultats varient, c'est un indicateur clair qu'il s'agit d'un faux positif.
Au fait : rkhunter a une meilleure vérification pour lkm.
Quelques sujets aléatoires sur ce message : stackexchange , cpanel.net , Linuxquestions.org et tous affirment que c'est un faux et un bug.
Un plus : la commande ./chkproc -v affichera l'identifiant du processus (PID) pour le message que vous obtenez et vous pouvez l'utiliser pour trouver le programme qui est connecté à ce processus avec cd /proc/{PID}/ && cat cmdline
Si cela est suffisamment convaincant, vous pouvez arrêter de lire. Si vous voulez en savoir plus sur votre machine et son fonctionnement, continuez à lire.
Que devez-vous donc savoir sur votre système pour pouvoir vous attaquer à ce problème ?
Premièrement : le meilleur détecteur de rootkit, c'est vous. Savoir quels services sont actifs sur votre machine, savoir quels scripts sont exécutés sur votre machine est ce qui permet de garder votre système propre et sûr. Et oui, cela prendra un peu de temps pour comprendre pleinement un système Linux.
Deuxièmement : Il y a un peu de malware qui cible Linux mais c'est rare. Pour la simple raison que, bien que Linux soit très portable, il n'est pas si portable que cela. Les différences entre les distributions (si petites soient-elles), les bibliothèques, les différents noyaux et compilateurs rendent l'exécution de code aléatoire sur des machines aléatoires extrêmement difficile. Et les personnes qui s'intéressent aux logiciels malveillants le font pour des raisons financières. Ils se concentrent donc sur Windows pour les raisons très simples qu'il s'agit d'une source fermée, avec de nombreuses failles qui dépendent de Microsoft pour les corriger. (simplifié :) )
Maintenant, l'avertissement que vous voyez concernant un éventuel cheval de Troie LKM installé. LKM est l'abréviation de Linux Kernel Module et est l'un des modules de base de Linux. Les modules du noyau sont chargés dans les noyaux correspondants et si les deux ne vont pas ensemble, les modules ne seront pas chargés. Il s'agit de l'une des fonctions de sécurité de base d'un système Linux que vous pouvez utiliser pour traquer le code malveillant (1).
Quelques notions de base sur les noyaux (2) :
uname -r montre votre noyau.
les noyaux installés peuvent être consultés dans /boot .
rinzwind@schijfwereld:/boot$ ls abi-3.16.0-22-generic initrd.img-3.16.0-29-generic abi-3.16.0-23-generic initrd.img-3.16.0-30-generic abi-3.16.0-24-generic memtest86+.bin abi-3.16.0-25-generic memtest86+.elf abi-3.16.0-28-generic memtest86+_multiboot.bin abi-3.16.0-29-generic System.map-3.16.0-22-generic abi-3.16.0-30-generic System.map-3.16.0-23-generic config-3.16.0-22-generic System.map-3.16.0-24-generic config-3.16.0-23-generic System.map-3.16.0-25-generic config-3.16.0-24-generic System.map-3.16.0-28-generic config-3.16.0-25-generic System.map-3.16.0-29-generic config-3.16.0-28-generic System.map-3.16.0-30-generic config-3.16.0-29-generic vmlinuz-3.16.0-22-generic config-3.16.0-30-generic vmlinuz-3.16.0-23-generic grub vmlinuz-3.16.0-24-generic initrd.img-3.16.0-22-generic vmlinuz-3.16.0-25-generic initrd.img-3.16.0-23-generic vmlinuz-3.16.0-28-generic initrd.img-3.16.0-24-generic vmlinuz-3.16.0-29-generic initrd.img-3.16.0-25-generic vmlinuz-3.16.0-30-generic initrd.img-3.16.0-28-generic
Les modules du noyau sont installés dans /lib/modules dans un sous-répertoire correspondant à votre noyau.
Donc, sur la base de (1) et (2), la prochaine étape est de redémarrer dans un autre noyau. Le module incriminé a été compilé pour un noyau spécifique et ne pourra pas se compiler dans l'autre noyau (simplement parce que les en-têtes ne correspondent pas).
La quantité de répertoires et de fichiers qui peuvent être affectés lorsque vous avez un rootkit est limitée (un rootkit doit être lancé de quelque part). Il y a 2 répertoires et un groupe de fichiers qui seront ciblés ...
/etc/init.d/
Faites un ls -ltr /etc/init.d (il les répertorie dans l'ordre de leur dernière modification) et vérifiez les services inconnus. Les services normaux auront des noms sains. Ces services peuvent être lancés par le système ou manuellement.
rinzwind@schijfwereld:/etc/init.d$ ls acpid hwclock.sh reboot alsa-utils irqbalance resolvconf anacron kerneloops rsync apparmor killprocs rsyslog apport kmod saned atieventsd lightdm sendsigs avahi-daemon lvm2 single bluetooth mountall-bootclean.sh skeleton bootmisc.sh mountall.sh smartmontools brltty mountdevsubfs.sh speech-dispatcher cgmanager mountkernfs.sh sslh cgproxy mountnfs-bootclean.sh sudo checkfs.sh mountnfs.sh thermald checkroot-bootclean.sh networking udev checkroot.sh network-manager udev-finish console-setup ondemand ufw cron php5-fpm umountfs cups pppd-dns umountnfs.sh cups-browsed procps umountroot dbus pulseaudio unattended-upgrades dns-clean rc urandom grub-common rc.local uuidd halt rcS x11-common hostname.sh README
/etc/rc*/
Les scripts de démarrage et d'arrêt scripts sont situés dans /etc/rc[0-5,S].d . En général, les fichiers ici ont des numéros et une description saine (ces fichiers sont exécutés dans l'ordre alphabétique au démarrage et dans l'ordre inverse lors d'un kill. Faites attention aux scripts composés de chiffres et de lettres aléatoires. Voici une liste (ce sont des scripts valides).
rinzwind@schijfwereld:/etc$ ls rc*/ rc0.d/: K01alsa-utils K01lightdm K01unattended-upgrades K05umountnfs.sh K01atieventsd K01php5-fpm K01urandom K06networking K01bluetooth K01pulseaudio K01uuidd K07umountfs K01cgmanager K01resolvconf K02avahi-daemon K08umountroot K01cgproxy K01speech-dispatcher K03sendsigs K09halt K01cups-browsed K01sslh K04rsyslog README K01irqbalance K01thermald K05hwclock.sh
rc1.d/: K01alsa-utils K01irqbalance K01speech-dispatcher README K01atieventsd K01kerneloops K01sslh S01dns-clean K01bluetooth K01lightdm K01thermald S01killprocs K01cgmanager K01php5-fpm K01ufw S01pppd-dns K01cgproxy K01pulseaudio K01uuidd S02single K01cups K01saned K02avahi-daemon K01cups-browsed K01smartmontools K04rsyslog
rc2.d/: README S01uuidd S02kerneloops S04cups S01apport S02acpid S02rsync S04cups-browsed S01cgmanager S02anacron S02smartmontools S04pulseaudio S01dns-clean S02atieventsd S02speech-dispatcher S04saned S01php5-fpm S02cgproxy S02thermald S05grub-common S01pppd-dns S02cron S03avahi-daemon S05ondemand S01rsyslog S02dbus S03bluetooth S05rc.local S01sslh S02irqbalance S03lightdm
rc3.d/: README S01uuidd S02kerneloops S04cups S01apport S02acpid S02rsync S04cups-browsed S01cgmanager S02anacron S02smartmontools S04pulseaudio S01dns-clean S02atieventsd S02speech-dispatcher S04saned S01php5-fpm S02cgproxy S02thermald S05grub-common S01pppd-dns S02cron S03avahi-daemon S05ondemand S01rsyslog S02dbus S03bluetooth S05rc.local S01sslh S02irqbalance S03lightdm
rc4.d/: README S01uuidd S02kerneloops S04cups S01apport S02acpid S02rsync S04cups-browsed S01cgmanager S02anacron S02smartmontools S04pulseaudio S01dns-clean S02atieventsd S02speech-dispatcher S04saned S01php5-fpm S02cgproxy S02thermald S05grub-common S01pppd-dns S02cron S03avahi-daemon S05ondemand S01rsyslog S02dbus S03bluetooth S05rc.local S01sslh S02irqbalance S03lightdm
rc5.d/: README S01uuidd S02kerneloops S04cups S01apport S02acpid S02rsync S04cups-browsed S01cgmanager S02anacron S02smartmontools S04pulseaudio S01dns-clean S02atieventsd S02speech-dispatcher S04saned S01php5-fpm S02cgproxy S02thermald S05grub-common S01pppd-dns S02cron S03avahi-daemon S05ondemand S01rsyslog S02dbus S03bluetooth S05rc.local S01sslh S02irqbalance S03lightdm
rc6.d/: K01alsa-utils K01lightdm K01unattended-upgrades K05umountnfs.sh K01atieventsd K01php5-fpm K01urandom K06networking K01bluetooth K01pulseaudio K01uuidd K07umountfs K01cgmanager K01resolvconf K02avahi-daemon K08umountroot K01cgproxy K01speech-dispatcher K03sendsigs K09reboot K01cups-browsed K01sslh K04rsyslog README K01irqbalance K01thermald K05hwclock.sh
rcS.d/: README S03udev S08checkroot-bootclean.sh S01console-setup S04brltty S08kmod S02alsa-utils S04mountdevsubfs.sh S08urandom S02apparmor S04procps S09mountall.sh S02hostname.sh S04udev-finish S09networking S02mountkernfs.sh S05hwclock.sh S10mountall-bootclean.sh S02resolvconf S05lvm2 S10mountnfs.sh S02ufw S06checkroot.sh S11mountnfs-bootclean.sh S02x11-common S07checkfs.sh S12bootmisc.sh
un script de démarrage.
En général, Ubuntu utilise bash dans un terminal et dash au démarrage. echo $SHELL vous montrera quel Shell est utilisé. Pour bash les fichiers cachés pour vérifier les Shell ou les lignes de code bizarres sont...
/etc/profile
/etc/bashrc
/etc/bash.bashrc
~/.profile
~/.bash_profileCe sont les 5 plus courantes. Toute machine peut en avoir d'autres. En plus de cela, vous pouvez également inclure
/etc/crontab
crontabLe dernier pour votre utilisateur et en faisant sudo su . "crontab" que vous pouvez lister avec crontab -l . Attention aux scripts qui ne sont pas des Linux généraux ou créés par vous.
Si vous disposez d'un deuxième système, la vie devient beaucoup plus facile : vous pouvez simplement comparer tous les fichiers ci-dessus avec la deuxième machine.
Je sais qu'il y a déjà une réponse acceptée, mais je veux montrer une autre façon de déboguer ceci, qui pourrait aider quelqu'un d'autre dans le futur. Cela m'a aidé à comprendre que c'était effectivement un faux positif. Je suis également tombé sur une sortie comme celle-ci sur Ubuntu 20.04 en utilisant chkrootkit v0.53
Checking `lkm'... You have 12 process hidden for readdir command
You have 12 process hidden for ps command
chkproc: Warning: Possible LKM Trojan installedNotez, que le montant de 12 changeait à chaque fois que je l'exécutais. Pour déboguer davantage, j'ai donc exécuté chkproc -v (généralement en /usr/lib/chkrootkit/ ), qui donne un résultat comme celui-ci :
PID 277881(/proc/277881): not in readdir output
PID 277881: not in ps output
You have 1 process hidden for readdir command
You have 1 process hidden for ps commandNotez que cela change aussi à chaque fois que je l'exécute (différents PID, différentes quantités). Il semble donc que des processus (non identifiés) de courte durée aient perturbé le fonctionnement de chkproc qui est une source connue de faux positifs, cf. http://www.chkrootkit.org/faq/ . Pour rendre mon jugement final, je devais identifier ces processus de courte durée et pour cela, je ne peux que recommander d'utiliser atop qui peut suivre l'historique des processus dans le temps, de sorte qu'il peut vous dire quels processus ont été actifs sur une période donnée.
Donc, pour déboguer tout cela, voici ce que vous devez faire :
chkproc -v dans un Shell et de laisser atop exécuté dans un autre Shell.chkproc vous renvoie un PID, attendez que atop pour mettre à jour sa sortie et la mettre en pause ensuite (généralement z ).atop où vous trouverez la liste des processus en commençant par les processus actuellement actifs et en terminant par ceux qui se sont arrêtés dans le passé. atop période d'enregistrement. Ces processus seront marqués par <> dans la colonne la plus à droite.chkproc -v de l'étape 1. Si ce n'est pas là, alors vous avez peut-être mis en pause atop trop tôt, alors réessayez dans ce cas. Si vous pouvez trouver le PID, alors regardez son CMD y RUID entrée de la colonne. Cela devrait vous donner un bon indice, ce que ce processus était et devrait vous donner une idée si c'est un faux positif ou non.Enfin, je peux mentionner que j'ai trouvé un grand nombre de ces processus de courte durée (par exemple beaucoup de sleep ), qui se sont avérés être des conteneurs Docker à venir exécutant des applications Web sur mon système. Pour vérifier que j'ai arrêté temporairement tous les conteneurs Docker et que tous ces processus éphémères ont disparu, j'ai procédé comme suit chkproc ainsi que chkrootkit étaient de nouveau heureux en ne trouvant rien.
Donc, pour résumer : Les processus à courte durée de vie dans les conteneurs Docker peuvent provoquer des faux positifs. Toutefois, veillez à les identifier en premier lieu au lieu de les ignorer d'emblée.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
