rkhunter: właściwy sposób dalszego postępowania z ostrzeżeniami?

Poszukałem go i sprawdziłem dwa pierwsze znalezione linki:

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

Nie wspominają, co mam zrobić w przypadku takich ostrzeżeń:

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

P1: Czy jest więcej rozszerzonych poradników wyjaśniających, jak postępować z różnego rodzaju ostrzeżeniami?

I drugie pytanie. Czy moje działania były wystarczające, aby rozwiązać te ostrzeżenia?

a) Aby znaleźć pakiet zawierający podejrzany plik, np. jest to debianutils dla pliku / bin / który

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

b) Aby sprawdzić sumy kontrolne pakietu 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) Odpocząć, /bin/whichjak widzę OK

/bin/which                                                                    OK

d) Aby umieścić plik /bin/whichdo /etc/rkhunter.confjakSCRIPTWHITELIST="/bin/which"

e) W przypadku ostrzeżeń jak dla pliku, za pomocą /usr/bin/lynxktórego aktualizuję sumę kontrolnąrkhunter --propupd /usr/bin/lynx.cur

Q2: Czy poprawnie rozwiązuję takie ostrzeżenia?

Używanie debsumsjest bardzo sprytnym pomysłem z jedną poważną wadą: jeśli coś zastąpiłoby plik będący własnością roota, taki jak /bin/which, mógłby również przepisać /var/lib/dpkg/info/*.md5sumsprzy użyciu zaktualizowanej sumy kontrolnej. O ile wiem, nie ma łańcucha dostaw z powrotem do podpisu Debian / Ubuntu. To wielka szkoda, ponieważ byłby to naprawdę prosty, bardzo szybki sposób na sprawdzenie autentyczności pliku na żywo.

Zamiast tego, aby naprawdę zweryfikować plik, musisz pobrać nową kopię tego deba, wyodrębnić wewnętrzny control.tar.gzplik, a następnie spojrzeć na jego plik md5sums, aby porównać go z rzeczywistym md5sum /bin/which. To bolesny proces.

Najprawdopodobniej wydarzyło się tutaj, że masz jakieś aktualizacje systemu (nawet uaktualnienie dystrybucji) i nie poprosiłeś rkhunter o aktualizację jego profili. rkhunter musi wiedzieć, jakie powinny być pliki, aby wszelkie aktualizacje systemu mogły go zdenerwować.

Gdy wiesz, że coś jest bezpieczne, możesz uruchomić, sudo rkhunter --propupd /bin/whichaby zaktualizować odniesienie do pliku.

Jest to jeden z problemów związanych z rkhunter. Wymaga głębokiej integracji z procesem deb, aby po zainstalowaniu zaufanych, podpisanych pakietów rkhunter aktualizował swoje odniesienia do plików.

I nie, nie umieszczałbym na białej liście takich rzeczy, ponieważ jest to dokładnie taka rzecz, po którą sięgałby rootkit.

zuba, pomysł na białej liście jest zły; odznacza plik do sprawdzenia, który powinien być widoczny dla ciebie i twojego programu anty-malware, pomysł jest jednak wykorzystany i przeglądanie wiadomości jest nieszkodliwe. Czy zamiast tego moglibyśmy stworzyć przejście, byłoby lepsze. gdzieś wzdłuż linii \ linii zaczynających się na \ zostaną zignorowane; ale wymaga to trochę doświadczenia w programowaniu i dogłębnej znajomości działania rkhuntera.

Bin /, który zostanie przepisany w razie potrzeby, aby uwzględnić zmiany w programowaniu; Zasadniczo jeden plik może zostać zastąpiony lub pliki mogą zostać tymczasowo utworzone i zmienić lub zniknąć po ponownym uruchomieniu, co może oszukać oprogramowanie rkhunter.

Istnieje linia, w której oprogramowanie / aktualizacje lub oprogramowanie antymalware przypomina rootkita i uważam, że jest to jeden z nich.

Stosowana metoda jest niebezpieczna tylko wtedy, gdy zmienia program lub plik, który (w jakiś sposób) wpłynie w jakiś sposób na działanie komputerów. Czasami jesteśmy gorsi niż nasze maszyny pod tym względem. Udowodnienie tego na twoim komputerze jest naprawdę niesprawiedliwe, gdybym zapytał, jakbym był mój. Chciałbym wiedzieć, udokumentować ostrzeżenia i sumy kontrolne i zanotować za każdym razem, gdy nastąpiła zmiana.