web-dev-qa-db-fra.com

Pourquoi chkrootkit ne teste-t-il pas syslogd?

Lorsque je numérise ma machine avec chkrootkit je remarque que cela dit toujours pour l'un d'eux:

Checking `syslogd'...                                       not tested

Pourquoi cela n'est-il pas testé? Faut-il tester cela? Et si c'est une bonne chose à tester, comment puis-je le faire tester?

Informations sur le système d'exploitation:

Description:    Ubuntu 14.10
Release:    14.10

Informations sur le paquet:

chkrootkit:
  Installed: 0.49-5ubuntu1
  Candidate: 0.49-5ubuntu1
  Version table:
 *** 0.49-5ubuntu1 0
        500 http://gb.archive.ubuntu.com/ubuntu/ utopic/universe AMD64 Packages
        100 /var/lib/dpkg/status
securityantivirussyslogrsyslogchkrootkit
4
user364819

Cela se produit car chkrootkit recherche un exécutable nommé syslogd dans plusieurs emplacements courants, mais comme Ubuntu utilise rsyslog , son démon syslog est à la place appelé rsyslogd .

Pour vérifier que le démon syslog sur votre machine s'appelle spécifiquement rsyslogd plutôt que syslogd, vous pouvez exécuter locate syslogd (bien sûr, si vous aviez un rootkit, cela pourrait également entraîner des résultats incorrects):

ek@Io:~$ locate syslogd
/etc/apparmor.d/usr.sbin.rsyslogd
/etc/apparmor.d/disable/usr.sbin.rsyslogd
/etc/apparmor.d/local/usr.sbin.rsyslogd
/usr/sbin/rsyslogd
/usr/share/man/man8/rsyslogd.8.gz

Pour vérifier que c'est la raison pour laquelle chkrootkit ne teste pas le démon syslog, vous pouvez exécuter chkrootkit avec le -d flag (pour debug mode) et envoyer une copie de la sortie dans un fichier:

Sudo chkrootkit -d |&tee ~/chkrootkit.log

Ouvrez ensuite le fichier journal dans un éditeur de texte et examinez la sortie de débogage entre le Checking `syslogd'... et not tested messages. Sur ma machine, cela ressemble à ceci (sur le vôtre, je pense que ce sera similaire):

Checking `syslogd'...                                       + chk_syslogd
+ STATUS=1
+ SYSLOG_I_L=/usr/lib/pt07|/dev/pty[pqrs]|/dev/hd[als][0-7]|/dev/ddtz1|/dev/ptyxx|/dev/Tux|syslogs\.h
+ loc syslogd syslogd /usr/local/sbin /usr/local/bin /usr/sbin /usr/bin /sbin /bin /sbin /usr/sbin /lib /usr/lib /usr/libexec .
+ thing=syslogd
+ shift
+ dflt=syslogd
+ shift
+ :
+ test -f /usr/local/sbin/syslogd
+ :
+ test -f /usr/local/bin/syslogd
+ :
+ test -f /usr/sbin/syslogd
+ :
+ test -f /usr/bin/syslogd
+ :
+ test -f /sbin/syslogd
+ :
+ test -f /bin/syslogd
+ :
+ test -f /sbin/syslogd
+ :
+ test -f /usr/sbin/syslogd
+ :
+ test -f /lib/syslogd
+ :
+ test -f /usr/lib/syslogd
+ :
+ test -f /usr/libexec/syslogd
+ :
+ test -f ./syslogd
+ [ / = / ]
+ echo syslogd
+ exit 1
+ CMD=syslogd
+ [ ! -r syslogd ]
+ return 2
+ STATUS=2
+ [  = t ]
+ echo not tested
not tested

Puisqu'un fichier appelé syslogdn'existe dans aucun de ces emplacements (ou pas du tout), il n'a rien à tester.

Une solution de contournement partielle possible serait de créer un lien symbolique à l'un de ces emplacements vers l'exécutable réel ryslogd. Je considère cela uniquement comme une solution partielle parce que je ne connais pas les détails de ce que chkrootkit vérifie (ou devrait vérifier), ou s'il y a quelque chose de spécial à faire pour inspecter correctement rsyslogd, ou si cela fonctionne vraiment correctement lors de l'inspection des liens symboliques et des fichiers récemment créés. chkrootkit ne signale pas avoir vérifié avec succès syslogd quand je fais cela, cependant:

ek@Io:~$ Sudo ln -s /usr/sbin/rsyslogd /usr/local/sbin/syslogd
ek@Io:~$ Sudo chkrootkit | grep syslogd
Checking `syslogd'...                                       not infected

Le sous-répertoire sbin de /usr/local n'existe peut-être pas déjà, auquel cas vous pouvez le créer. Quoi qu'il en soit, je suggère de supprimer le lien symbolique syslogd après l'avoir utilisé.

Dans tous les cas la vraie solution est comme bodhi.zazen dit - cela devrait être signalé comme un bogue contre le package chkrootkit dans Ubuntu. La façon dont je vous suggère de signaler le bogue est de:

  1. Lisez ce guide , si vous ne l'avez pas déjà fait. Il fournit d'excellentes indications sur la rédaction de rapports de bogues. ( Cette question est une autre bonne ressource.)
  2. Courir ubuntu-bug chkrootkit.
  3. Apport dira qu'il s'agit de "Collecte d'informations sur les problèmes". Quand c'est fait, cliquez sur "Envoyer". Cela ouvrira un nouvel onglet de navigateur où vous pourrez signaler le bogue.
  4. Incluez des informations documentant la sortie de chkrootkit lorsque le problème se produit. Je recommande de joindre un journal montrant sa sortie, y compris de préférence la sortie de débogage. Vous pouvez joindre le fichier journal créé si/lorsque vous avez exécuté Sudo chkrootkit -d |& tee ~/chkrootkit.log (voir au dessus). Vous pouvez également reproduire la petite partie la plus pertinente du texte du rapport de bogue lui-même.
  5. Soumettez le rapport de bogue.
  6. Facultativement, si vous commentez cette réponse, je vais aller au rapport de bogue et indiquer que je suis également affecté - car j'ai pu reproduire le bogue sur mon système. Je peux également être en mesure de fournir des informations supplémentaires - par exemple, je peux confirmer que cela se produit sur la version bêta 15.04, et si vous n'avez pas le temps de produire et de joindre un journal, je pourrais le faire. (Mais je vous encourage à fournir autant d'informations pertinentes que possible dans le rapport d'origine.)
6
Eliah Kagan

De http://www.chkrootkit.org/README :

"non testé": le test n'a pas été effectué - cela peut se produire dans les situations suivantes:
a) le test est spécifique au système d'exploitation;
b) le test dépend d'un programme externe qui n'est pas disponible;
c) certaines options de ligne de commande spécifiques sont données. (par exemple, -r).

En supposant que vous n'avez pas passé une option de ligne de commande spécifique, je suppose que c'est "spécifique au système d'exploitation" d'une certaine manière.

Je voudrais déposer un rapport de bogue avec Ubunt .

2
Panther

J'ai écrit aux auteurs de chkrootkit à ce sujet en vérifiant syslogd et non sur syslogd, présent dans les distributions basées sur Ubuntu.

Voici la partie pertinente de la conversation:

--- coupure ---

Je comprends qu'il s'agit exclusivement d'un problème de distribution basé sur Ubuntu, mais est-il possible que rsyslog devienne éventuellement une cible?

Oui, tous les binaires linux peuvent être infectés (rsyslogd inclus), mais pour le vérifier, j'ai besoin de voir le binaire infecté. Après 20 ans depuis la création de chkrootkit, je n'ai jamais vu un rsyslogd infecté. --- coupure ---

Ce n'est donc pas un bug.

À votre santé.

0
Altoid