rkhunter: il modo giusto per gestire ulteriormente gli avvisi?


8

Ne ho cercato su Google e ho verificato due primi link trovati:

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

Non menzionano cosa devo fare in caso di tali avvertimenti:

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

D1: Esistono HowTo più estesi che spiegano come gestire avvisi di tipo diverso?

E la seconda domanda. Le mie azioni sono state sufficienti per risolvere questi avvisi?

a) Per trovare il pacchetto che contiene il file sospetto, ad es. sono debianutils per il file / bin / che

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

b) Per controllare i checksum del pacchetto 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) Rilassarsi /bin/whichcome vedo OK

/bin/which                                                                    OK

d) Per mettere il file /bin/whichdi /etc/rkhunter.confcomeSCRIPTWHITELIST="/bin/which"

e) Per avvisi come per il file con /usr/bin/lynxcui aggiorno checksumrkhunter --propupd /usr/bin/lynx.cur

Q2: risolvo tali avvisi nel modo giusto?


CERT USA - Passaggi per il ripristino da un compromesso di sistema UNIX o NT :In general, the only way to trust that a machine is free from backdoors and intruder modifications is to reinstall the operating system from the distribution media and install all of the security patches before connecting back to the network. We encourage you to restore your system using known clean binaries.
ignis

Risposte:


3

L'utilizzo debsumsè un'idea molto intelligente con un grande difetto: se qualcosa dovesse sovrascrivere un file di proprietà di root come /bin/which, potrebbe anche riscrivere /var/lib/dpkg/info/*.md5sumscon un checksum aggiornato. Per quanto ne so, non esiste una catena di custodia di una firma Debian / Ubuntu. Il che è un vero peccato perché sarebbe un modo molto semplice e molto veloce per verificare l'autenticità di un file live.

Invece per verificare veramente un file, devi scaricare una nuova copia di quel deb, estrarre l'interno control.tar.gze quindi guardare il suo file md5sums per confrontarlo con un reale md5sum /bin/which. È un processo doloroso.

Ciò che è probabilmente accaduto qui è che hai avuto alcuni aggiornamenti di sistema (anche un aggiornamento della distribuzione) e non hai chiesto a rkhunter di aggiornare i suoi profili. rkhunter deve sapere come dovrebbero essere i file, quindi eventuali aggiornamenti di sistema lo sconvolgeranno.

Una volta che sai che qualcosa è sicuro, puoi eseguire sudo rkhunter --propupd /bin/whichper aggiornare il suo riferimento al file.

Questo è uno dei problemi con rkhunter. Ha bisogno di una profonda integrazione nel processo deb in modo che, quando sono installati pacchetti affidabili e firmati, rkhunter aggiorni i suoi riferimenti ai file.


E no, non vorrei inserire nella whitelist cose come questa perché è esattamente il genere di cose che un rootkit dovrebbe seguire.


Grazie Oli, apprezzo molto le tue spiegazioni, ma preferirei una soluzione pratica o una soluzione alternativa. Sto aprendo un'altra taglia. Se non ottengo ciò di cui ho bisogno, assegnerò la taglia alla tua risposta. Ok?)
zuba,

1

zuba, l'idea della whitelist è negativa; si sta annullando l'assegnazione di un file da controllare che dovrebbe essere visibile a te e al tuo antimalware, ma l'idea viene utilizzata e la visualizzazione del messaggio è innocua. Potremmo creare una scrittura invece sarebbe meglio. da qualche parte lungo le linee di \ linee che iniziano con \ saranno ignorate; ma ciò richiede una certa esperienza di programmazione e una conoscenza intima del funzionamento di rkhunter.

Il cestino / che verrà riscritto quando necessario per adattarsi alle modifiche di programmazione; In generale, un file può essere sostituito o i file possono essere temporaneamente creati e modificati o scompaiono dopo un riavvio, e ciò può ingannare il software rkhunter.

C'è una linea in cui software / aggiornamenti o antimalware ricorda un rootkit, e credo che questi siano uno di quelli.

Il metodo utilizzato è pericoloso solo se modifica un programma o un file che (agirà) in qualche modo influenzerà il funzionamento del computer. A volte siamo peggio delle nostre macchine a tale riguardo. Provare questo per il tuo computer è davvero ingiusto da chiedere, come potrei se fosse mio. Vorrei sapere, documentare gli avvertimenti e i checksum e noterei ogni volta che c'era un cambiamento.


1
Sì, sono d'accordo che la whitelisting / bin / che è una cattiva idea
zuba
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.