rkhunter: maneira correta de lidar com os avisos ainda mais?

Eu pesquisei alguns e verifiquei dois primeiros links encontrados:

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

Eles não mencionam o que devo fazer em caso de tais avisos:

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: há mais HowTos estendidos que explicam como lidar com diferentes avisos de tipo?

E a segunda pergunta. Minhas ações foram suficientes para resolver esses avisos?

a) Para encontrar o pacote que contém o arquivo suspeito, por exemplo, é debianutils para o arquivo / bin /

~ > dpkg -S /bin/which
debianutils: /bin/which

b) Para verificar as somas de verificação do pacote 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) Para relaxar /bin/whichcomo vejo OK

/bin/which                                                                    OK

d) Para colocar o arquivo /bin/whichde /etc/rkhunter.confcomoSCRIPTWHITELIST="/bin/which"

e) Para avisos quanto ao arquivo /usr/bin/lynx, atualizo a soma de verificação comrkhunter --propupd /usr/bin/lynx.cur

P2: Resolvo esses avisos da maneira correta?

Usar debsumsé uma idéia muito inteligente com uma falha importante: se algo sobrescrever um arquivo de propriedade raiz, como /bin/which, também poderá reescrever /var/lib/dpkg/info/*.md5sumscom uma soma de verificação atualizada. Não existe uma cadeia de custódia de volta para uma assinatura Debian / Ubuntu, tanto quanto eu posso ver. O que é uma pena, porque seria uma maneira muito simples e rápida de verificar a autenticidade de um arquivo ativo.

Em vez de realmente verificar um arquivo, você precisa fazer o download de uma nova cópia dessa deb, extrair o interno control.tar.gze, em seguida, examinar seu arquivo md5sums para comparar com um real md5sum /bin/which. É um processo doloroso.

O que provavelmente aconteceu aqui é que você teve algumas atualizações do sistema (até mesmo uma atualização de distribuição) e não pediu ao rkhunter para atualizar seus perfis. O rkhunter precisa saber como devem ser os arquivos, para que todas as atualizações do sistema o perturbem.

Depois de saber que algo é seguro, você pode executar sudo rkhunter --propupd /bin/whichpara atualizar sua referência do arquivo.

Este é um dos problemas do rkhunter. Ele precisa de profunda integração no processo deb para que, quando pacotes assinados e confiáveis ​​sejam instalados, o rkhunter atualize suas referências aos arquivos.

E não, eu não colocaria coisas como esta na lista de permissões, porque esse é exatamente o tipo de coisa que um rootkit buscaria.

zuba, a idéia da lista de desbloqueio é ruim; está desassociando um arquivo a ser verificado, que deve estar visível para você e seu antimalware, embora a idéia seja usada e a visualização da mensagem seja inofensiva. Poderíamos criar uma redação através de uma redação seria melhor. em algum lugar ao longo das linhas de \ linhas começando com \ serão ignoradas; mas isso requer alguma experiência em codificação e conhecimento íntimo do funcionamento do rkhunter.

O compartimento / que será reescrito quando necessário para acomodar alterações de programação; Em geral, um arquivo pode ser substituído ou arquivos temporariamente criados e alterados ou desaparecem após uma reinicialização, o que pode enganar o software rkhunter.

Existe uma linha em que software / atualizações ou antimalware se assemelha a um rootkit, e acredito que esses sejam um deles.

O método que você emprega é perigoso apenas se ele alterar um programa ou arquivo que afetará de alguma forma a operação do computador. Às vezes somos piores que nossas máquinas nesse sentido. Provar isso para o seu computador é realmente injusto, como eu poderia fazer se fosse meu. Eu saberia, documentaria os avisos e somas de verificação e anotaria sempre que houvesse uma alteração.