Poszukałem go i sprawdziłem dwa pierwsze znalezione linki:
- http://www.skullbox.net/rkhunter.php
- 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?
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.Odpowiedzi:
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 rzeczywistymmd5sum /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.
źródło
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.
źródło