私はいくつかをグーグルで検索し、見つかった最初の2つのリンクをチェックアウトしました。
彼らはそのような警告の場合に私が何をすべきかについて言及していない:
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/which
についてリラックスする
/bin/which OK
d)ファイル/bin/which
を/etc/rkhunter.conf
としてSCRIPTWHITELIST="/bin/which"
として配置する
e)ファイル/usr/bin/lynx
に関する警告については、rkhunter --propupd /usr/bin/lynx.cur
でチェックサムを更新します
Q2:このような警告は正しい方法で解決できますか?
debsums
を使用することは、1つの重大な欠陥がある非常に賢いアイデアです。/bin/which
などのルート所有ファイルを上書きする場合、could/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プロセスに深く統合する必要があります。
いいえ、これはルートキットが追跡するようなものなので、このようなものをホワイトリストに登録しません。
ズバ、ホワイトリストのアイデアは悪いものです。あなたとあなたのアンチマルウェアに見えるはずのチェック対象のファイルの割り当てを解除しますが、そのアイデアは使用されますが、メッセージの表示は無害です。代わりにライトスルーを作成できますか? \で始まる\ linesの行に沿ったどこかは無視されます。しかし、それはある程度のコーディング経験とrkhunterの仕組みに関する詳細な知識が必要です。
Bin/whichは、プログラミングの変更に対応するために必要なときに書き換えられます。一般に、1つのファイルが置き換えられるか、ファイルが一時的に作成され、再起動後に変更または消失することがあります。これにより、rkhunterソフトウェアがだまされる可能性があります。
ソフトウェア/アップデートまたはマルウェア対策がルートキットに似ている行がありますが、これらはその1つだと思います。
使用する方法は、コンピューターの動作に何らかの形で(に作用する)プログラムまたはファイルを変更する場合にのみ危険です。その点で、マシンよりも悪い場合があります。あなたのコンピュータでこれを証明することは、私がそうすることができるように、本当に不公平です。警告とチェックサムを文書化して文書化し、変更があったときはいつでもメモします。