rkhunter:警告をさらに処理する正しい方法?


8

私はいくつかをググって、それが見つけた2つの最初のリンクを調べました:

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

彼らはそのような警告の場合に私が何をすべきかについて言及していません:

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:さまざまな種類の警告に対処する方法を説明する拡張されたHowToはありますか?

そして2番目の質問。私の行動はこれらの警告を解決するのに十分でしたか?

a)疑わしいファイルが含まれているパッケージを見つけるには、たとえば、ファイル/ bin / whichのdebianutilsです

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

b)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)/bin/whichOKと思うようにリラックスする

/bin/which                                                                    OK

d)ファイル/bin/whichを次の/etc/rkhunter.confように配置するにはSCRIPTWHITELIST="/bin/which"

e)警告については、/usr/bin/lynxチェックサムを更新するファイルについてrkhunter --propupd /usr/bin/lynx.cur

Q2:このような警告を正しく解決できますか?


US CERT-UNIXまたは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.
侵害

回答:


3

を使用することにdebsumsは、1つの大きな欠陥がある非常に巧妙なアイデアがあります。たとえば、rootが所有するファイルを上書きすると、更新されたチェックサムで書き換え/bin/whichられる可能性があり/var/lib/dpkg/info/*.md5sumsます。私が見る限り、Debian / Ubuntuの署名に戻る監護の連鎖はありません。ライブファイルの信頼性を確認するための非常に簡単で非常に迅速な方法であるため、これは本当の恥です。

実際にファイルを検証するには、そのdebの新しいコピーをダウンロードし、内部control.tar.gzを抽出してから、そのmd5sumsファイルを見て実際のと比較する必要がありますmd5sum /bin/which。それは苦痛なプロセスです。

ここで最も起こりそうなことは、いくつかのシステム更新(ディストリビューションのアップグレードさえも)があり、rkhunterにプロファイルの更新を要求していないことです。rkhunterは、どのファイルがどのようなものであるかを知る必要があるので、システムアップデートはそれを混乱させます。

安全なものがわかったら、実行sudo rkhunter --propupd /bin/whichしてファイルの参照を更新できます。

これは、rkhunterの問題の1つです。信頼できる署名されたパッケージがインストールされたときに、rkhunterがファイルへの参照を更新するように、debプロセスに深く統合する必要があります。


そして、いや、私はこのようなことをホワイトリストに載せません。なぜなら、これは、まさにルートキットが追いかけるようなものだからです。


オリありがとうございました。説明をありがとうございましたが、実際的な解決策または回避策をお勧めします。別の報奨金を開きます。必要なものが得られない場合は、あなたの回答に賞金を割り当てます。OK?)
zuba

1

ズバ、ホワイトリストのアイデアは悪いものです。それはあなたとあなたのアンチマルウェアに見えるはずであるチェックされるべきファイルの割り当てを解除しています、しかしアイデアは使われます、そしてメッセージを見るのは無害です。代わりにライトスルーを作成できますか?\で始まる\ linesの行に沿ったどこかは無視されます。しかし、これにはコーディングの経験と、rkhunterの仕組みに関する深い知識が必要です。

bin /これは、プログラミングの変更に対応するために必要なときに書き換えられます。一般に、1つのファイルが置き換えられるか、ファイルが一時的に作成され、再起動後に変更または消失する可能性があります。これにより、rkhunterソフトウェアがだまされる可能性があります。

ソフトウェア/アップデートまたはマルウェア対策がルートキットに似ている行がありますが、これらはその1つだと思います。

使用する方法は、コンピュータの動作に何らかの影響を与える(作用する)プログラムまたはファイルを変更する場合にのみ危険です。時々私たちはその点で私たちのマシンよりも悪いです。あなたのコンピュータでこれを証明することは、それが私のものである場合と同じように、質問するのは本当に不公平です。私は知っていて、警告とチェックサムを文書化し、変更があったときはいつでもメモしておきます。


1
はい、/ bin /をホワイトリストに登録することは悪い考えです
zuba
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.