rkhunter: maneira correta de lidar com os avisos adicionais?

8

Eu pesquisei alguns e verifiquei dois primeiros links encontrados:

  1. link
  2. link

Eles não mencionam o que devo fazer no 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 os diferentes tipos de avisos?

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 / qual

~ > 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 sobre /bin/which como eu vejo OK

/bin/which                                                                    OK

d) Para colocar o arquivo /bin/which em /etc/rkhunter.conf as SCRIPTWHITELIST="/bin/which"

e) Para avisos como para o arquivo /usr/bin/lynx atualizo a soma de verificação com rkhunter --propupd /usr/bin/lynx.cur

Q2: Eu resolvo tais avisos de maneira correta?

    
por zuba 14.02.2013 / 10:18

2 respostas

3

Usar debsums é uma ideia muito inteligente com uma grande falha: se algo substituísse um arquivo de propriedade da raiz, como /bin/which , poderia também reescrever /var/lib/dpkg/info/*.md5sums com uma atualização checksum. Não há 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, muito rápida de verificar a autenticidade de um arquivo ao vivo.

Em vez de verificar verdadeiramente um arquivo, você precisa fazer o download de uma nova cópia desse deb, extrair o control.tar.gz interno e depois examinar seu arquivo md5sums para comparar com um% realmd5sum /bin/which. É um processo doloroso.

O que mais provavelmente aconteceu aqui é que você teve algumas atualizações do sistema (até mesmo uma atualização de distribuição) e não solicitou ao rkhunter que atualizasse seus perfis. O rkhunter precisa saber quais arquivos devem ser usados para que as atualizações do sistema o incomodem.

Quando souber que algo é seguro, você poderá executar sudo rkhunter --propupd /bin/which para atualizar sua referência do arquivo.

Este é um dos problemas do rkhunter. Ele precisa de integração profunda no processo de 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 na lista de permissões coisas assim, porque isso é exatamente o tipo de coisa que um rootkit poderia seguir.

    
por Oli 22.10.2013 / 12:35
1

zuba, a ideia da lista branca é ruim; é desatribuir um arquivo a ser verificado      que deve ser visível para você e seu anti-malware, a idéia é usada e ver a mensagem é inofensiva. Poderíamos criar um writthrough em vez disso seria melhor. em algum lugar ao longo das linhas de \ linhas que começam com \ serão ignoradas; mas isso requer alguma experiência de codificação e conhecimento íntimo do funcionamento do rkhunter.

O bin / que será reescrito quando necessário para acomodar mudanças de programação; Em geral, um arquivo pode ser substituído ou arquivos podem ser temporariamente criados e alterados ou desaparecidos após a 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 sejam um desses.

O método empregado é perigoso apenas se alterar um programa ou arquivo que afetará (de alguma forma) a operação dos computadores. Às vezes somos piores que nossas máquinas a esse respeito. Provar isso para o seu computador é realmente injusto perguntar, como eu poderia se fosse meu. Eu sei, documente os avisos e checksums e anote sempre que houver uma mudança.

    
por Diogenes Lantern 05.11.2013 / 04:28

Tags