rkhunterはiノードの変更を警告しますが、ファイルの変更日は変更しません

8

Centos 6を実行しているいくつかのシステムで、rkhunterがインストールされています。私は毎日cronを実行してrkhunterを実行し、電子メールで報告しています。

私は次のようなレポートを頻繁に受け取ります。

---------------------- Start Rootkit Hunter Scan ----------------------
Warning: The file properties have changed:
        File: /sbin/fsck
        Current inode: 6029384    Stored inode: 6029326
Warning: The file properties have changed:
        File: /sbin/ip
        Current inode: 6029506    Stored inode: 6029343
Warning: The file properties have changed:
        File: /sbin/nologin
        Current inode: 6029443    Stored inode: 6029531
Warning: The file properties have changed:
        File: /bin/dmesg
        Current inode: 13369362    Stored inode: 13369366

私が理解していることから、rkhunterは通常、スキャンされたファイルの変更されたハッシュや変更の日付をレポートするので、実際の変更はないと思います。

私の質問：マシン上でiノードを変更する（ext4を実行する）可能性のある他のアクティビティはありyumますか？これは通常のセキュリティ更新の一部としてこれらのファイルに本当に定期的（週に1回）の変更を加えていますか？

centos yum rkhunter

— ニック・コットレル
ソース

8

ファイルの更新は、多くの場合、同じディレクトリに新しいファイルを書き込んでから、古いファイルの上にファイルの名前を変更することによって行われます。この方法は通常、パッケージマネージャーを介してインストールされたすべてに適用されますが、他の理由で更新された場合でも、実行可能ファイルとライブラリに対して実行された更新にも適用されます。

この方法でファイルを更新すると、ファイルを開くプロセスで古いファイルまたは新しいファイルが取得され、ファイルで変更された内容が表示されなくなります。つまり、ファイルが更新されるたびに、実際には同じ名前の新しいファイルが作成されるため、iノード番号が変更されます。

これが、これらのファイルに新しいiノード番号が付けられた理由だと思います。

セキュリティ更新が原因の1つである可能性があります。しかし、私がFedora Core 1で最初に観察した別の可能性があり、それはある時点でそれをCentosに組み込むことができたでしょう。

実行可能ファイルとライブラリは事前にリンクされているため、より速く起動し、より少ないメモリを使用できます。このプロセスの間、ロードアドレスはランダム化され、セキュリティの脆弱性の悪用が少し難しくなります。cronジョブは、新しいランダム化されたアドレスで定期的にプロセスを繰り返し、すべての事前リンクされた実行可能ファイルとライブラリを更新します。

— カスパード
ソース

2

うん、プリリンクはここで最も可能性の高い説明のようです。

— マイケルハンプトン

これを処理する良い方法はありますか？実行するcronがある場合rkhunter --propupd、ハックを逃してrkhunterのすべてのポイントを無効にすることができますよね？

— Nic Cottrell 2014年

1

@NicholasTolleyCottrellはrpm、最初にprelink実行可能ファイルの整合性を検証して処理し、次にprelink引数付きで実行可能ファイルを呼び出して、事前リンクされた実行可能ファイルからの入力による事前リンクを元に戻し、標準出力に出力します。次にrpm、その出力の整合性をチェックできます。そのアプローチをに適用できるかどうかはわかりませんrkhunter。

— kasperd 2014年

1

ジャンプしないチェックサムを取得する方法については、linuxquestions.org / questions / linux-security-4 / …のこのスレッドを参照してください。私はcronベースのツールとしてrkhunterから離れました。便利なチェックがたくさんありますが、誤検知のチェックをオフにできないので、メールで送信されたレポートを無視することに慣れているので、必要な場所に注意を向けてもほとんど役に立ちません。それでも、手動で実行するツールとして時々役立つ場合があります。

— mc0e 14

2

私が見つけたもう1つのオプションは、これらのプロパティテストを完全に無効にすることでした。行を編集/etc/rkhunter.confして探し、次のようにDISABLE_TESTS変更した場合：

DISABLE_TESTS="suspscan hidden_procs deleted_files packet_cap_apps apps properties"

propertiesテストでは、ファイルハッシュの偽陽性をチェックして返すものです。

— ニック・コットレル
ソース

1

変更されたiノード番号は通常、ファイルが置き換えられたことを意味します。あなたが言うように、予想されるアップデートが原因である可能性があります。それらのファイルのmd5sumsが配布されたバージョンのものと一致することを確認します。他に同等のシステムがある場合は、それと比較するのが最も簡単かもしれません。

rkhunterで受け入れられた回答を確認してください。ファイルプロパティの変更が報告されていますが、それらのバイナリがどのパッケージからのものであるかを確認する方法について、yumによって更新されていることはわかりません。

これらのバイナリが、変更された別のバイナリの問題のために更新されたディストリビューションからのものであったとしても、驚くことではありませんが、リストしたバイナリは変更されていない新しいバージョンのパッケージに含まれていました。レポートには、コンテンツが変更されたバイナリも表示されましたか？

— mc0e
ソース

いいえ、実際には、ファイルのプロパティが変更されたことだけを受け取ったようです。内容は変更されていません。

— Nic Cottrell

-1

ドライブをより大きなドライブに複製し、異なるiノード番号のファイルの警告を受けました。システムからrkhunterを削除して再インストールし、iノード番号の変更に関する警告なしにスキャンを再実行しました

— ウィル・スミス
ソース