Isso acontece porque chkrootkit procura um executável chamado syslogd em vários locais comuns, mas como o Ubuntu usa o rsyslog , seu daemon syslog é chamado rsyslogd .
Para verificar se o daemon syslog em sua máquina é especificamente chamado de rsyslogd em vez de syslogd , você pode executar locate syslogd (embora, se você tivesse um rootkit, isso pudesse fazer com que resultados errados fossem reportados por este comando também):
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
Para verificar se é por isso que chkrootkit não está testando o daemon syslog, você pode executar chkrootkit com o -d flag (para o modo debug ) e enviar uma cópia da saída para um arquivo:
sudo chkrootkit -d |& tee ~/chkrootkit.log Em seguida, abra o arquivo de log em um editor de texto e examine a saída de depuração entre as mensagens Checking 'syslogd'... e not tested . Na minha máquina parece com isso (no seu eu espero que seja semelhante):
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
Como um arquivo chamado syslogd não existe em nenhum desses locais (ou nada), não há nada para testar.
Uma possível solução parcial seria criar um link simbólico em um desses locais para o executável ryslogd real. Eu considero isso apenas uma solução parcial porque eu não sei os detalhes de qual chkrootkit verifica (ou deveria verificar), ou se há algo especial que deveria estar fazendo para inspecionar corretamente rsyslogd , ou se realmente funciona corretamente ao inspecionar links simbólicos e arquivos recentemente criados . chkrootkit reporta com sucesso a verificação de syslogd quando eu faço isso:
ek@Io:~$ sudo ln -s /usr/sbin/rsyslogd /usr/local/sbin/syslogd
ek@Io:~$ sudo chkrootkit | grep syslogd
Checking 'syslogd'... not infected O subdiretório sbin de /usr/local pode não estar disponível existe, caso em que você pode criá-lo. De qualquer maneira, sugiro remover o link simbólico syslogd depois de usá-lo.
Em qualquer caso, a solução real é como bodhi.zazen diz - isso deve ser relatado como um bug contra o pacote chkrootkit no Ubuntu. A maneira que eu sugiro que você relate o bug é:
- Leia este guia , se ainda não o fez. Ele fornece excelente orientação sobre como escrever relatórios de bugs. ( Esta questão é outro bom recurso.)
- Executar
ubuntu-bug chkrootkit. - O suporte dirá que é "Coletando informações sobre problemas". Quando terminar, clique em "Enviar". Isso abrirá uma nova guia do navegador na qual você poderá denunciar o bug.
- Inclua informações documentando a saída de
chkrootkitquando o problema ocorrer. Eu recomendo anexar um log mostrando sua saída, preferencialmente incluindo saída de depuração. Você pode anexar o arquivo de log criado se / quando você executousudo chkrootkit -d |& tee ~/chkrootkit.log(veja acima). Você também pode reproduzir a parte pequena e mais relevante no texto do próprio relatório de erros. - Envie o relatório de erros.
- Opcionalmente, se você comentar essa resposta, eu irei até o relatório de erros e indicarei que também estou sendo afetado, já que consegui reproduzir o bug no meu sistema. Eu também posso ser capaz de fornecer informações adicionais - por exemplo, posso confirmar que ocorre no 15.04 Beta, e se você não tem tempo para produzir e anexar um log, eu poderia fazê-lo. (Mas eu encorajo você a fornecer o máximo de informações relevantes que puder no relatório original).