rkhunter: richtiger weg, um mit warnungen weiter umzugehen?

Ich habe einige gegoogelt und zwei erste gefundene Links überprüft:

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

Sie erwähnen nicht, was ich im Falle solcher Warnungen tun soll:

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

Frage 1: Gibt es ausführlichere HowTos, die erklären, wie mit verschiedenen Arten von Warnungen umgegangen wird?

Und die zweite Frage. Waren meine Maßnahmen ausreichend, um diese Warnungen zu beheben?

a) Um das Paket zu finden, das die verdächtige Datei enthält, z. B. debianutils für die Datei / bin / which

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

b) So überprüfen Sie die Prüfsummen des Debianutils-Pakets:

~ > 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) Um sich zu entspannen, /bin/whichwie ich OK sehe

/bin/which                                                                    OK

d) Um die Datei /bin/whichauf /etc/rkhunter.confas zu setzenSCRIPTWHITELIST="/bin/which"

e) Für Warnungen wie für die Datei, mit der /usr/bin/lynxich die Prüfsumme aktualisiererkhunter --propupd /usr/bin/lynx.cur

F2: Löse ich solche Warnungen richtig?

Die Verwendung debsumsist eine sehr clevere Idee mit einem großen Fehler: Wenn etwas eine Root-Datei überschreibt, wie z. B. /bin/which, könnte es auch /var/lib/dpkg/info/*.md5sumsmit einer aktualisierten Prüfsumme neu geschrieben werden. Soweit ich sehen kann, gibt es keine Sorgerechtskette für eine Debian / Ubuntu-Signatur. Das ist wirklich schade, denn das wäre eine sehr einfache und schnelle Möglichkeit, die Echtheit einer Live-Datei zu überprüfen.

Um eine Datei wirklich zu überprüfen, müssen Sie eine neue Kopie dieser Deb herunterladen, die interne extrahieren control.tar.gzund dann die md5sums-Datei betrachten, um sie mit einer echten zu vergleichen md5sum /bin/which. Es ist ein schmerzhafter Prozess.

Was hier höchstwahrscheinlich passiert ist, ist, dass Sie einige Systemupdates hatten (sogar ein Distributions-Upgrade) und rkhunter nicht gebeten haben, seine Profile zu aktualisieren. rkhunter muss wissen, wie Dateien aussehen sollten, damit Systemaktualisierungen es stören.

Sobald Sie wissen, dass etwas sicher ist, können Sie es ausführen sudo rkhunter --propupd /bin/which, um die Referenz der Datei zu aktualisieren.

Dies ist eines der Probleme mit rkhunter. Es muss tiefgreifend in den Deb-Prozess integriert werden, damit rkhunter bei der Installation vertrauenswürdiger, signierter Pakete seine Verweise auf Dateien aktualisiert.

Und nein, ich würde solche Dinge nicht auf die Whitelist setzen, weil dies genau das ist, wonach ein Rootkit streben würde.

zuba, die Whitelist-Idee ist schlecht; Es wird die Zuweisung einer zu überprüfenden Datei aufgehoben, die für Sie und Ihre Anti-Malware sichtbar sein sollte. Die Idee wird jedoch verwendet und das Anzeigen der Nachricht ist harmlos. Könnten wir stattdessen ein Durchschreiben erstellen, wäre besser. irgendwo entlang der Zeilen von \ Zeilen, die mit \ beginnen, werden ignoriert; Dies erfordert jedoch einige Programmiererfahrung und genaue Kenntnisse der Funktionsweise von rkhunter.

Der Bin /, der bei Bedarf neu geschrieben wird, um Programmänderungen zu berücksichtigen; Im Allgemeinen kann eine Datei ersetzt werden oder Dateien können vorübergehend erstellt werden und nach einem Neustart geändert werden oder verschwinden. Dies kann die rkhunter-Software austricksen.

Es gibt eine Zeile, in der Software / Updates oder Antimalware einem Rootkit ähnelt, und ich glaube, dass dies eine davon ist.

Die von Ihnen verwendete Methode ist nur dann gefährlich, wenn sie ein Programm oder eine Datei ändert, die den Betrieb des Computers irgendwie beeinflusst. Manchmal sind wir in dieser Hinsicht schlechter als unsere Maschinen. Es ist wirklich unfair, dies für Ihren Computer zu beweisen, so wie ich es könnte, wenn es meins wäre. Ich würde wissen, die Warnungen und Prüfsummen dokumentieren und notieren, wann immer es eine Änderung gab.