web-dev-qa-db-ja.com

Tripwireレポートには、自宅でコンピューターをシャットダウンして休暇をとったときからの変更日が表示されます

Tripwireレポートには、自宅でコンピューターをシャットダウンして休暇をとったときの変更日が表示されます。これはどのようにして可能ですか？

これは多くの例の1つです。

Modified object name:  /lib/x86_64-linux-gnu/security/pam_systemd.so

  Property:            Expected                    Observed                    
  -------------        -----------                 -----------                 
* Inode Number         14155863                    14156649                    
* Modify Time          Do 12 Mai 2016 11:39:41 CEST
                                                   Do 01 Feb 2018 15:31:23 CET 
* CRC32                B5TykA                      B/R1Fi                      
* MD5                  Ag+rN14JZRydCT88KOuyuX      BAHe4c1qm712mqcpi1k+rI

2月1日、約1か月前にシャットダウンしたコンピューターの近くにいませんでした。別の月に戻ってきました。 2月には、ファイルに約3000の変更があります。 1500年1月の変更。私は1月6日から2月27日まで離れていました。

linuxids
6
user173381

システムログに他のトレースはありますか？誰かがシステムを完全にサニタイズしてログに何も表示されないことがまだTripwireを特定できないか、少なくともタイムスタンプを適切にリセットできないのは奇妙に思われます。

パッケージを更新してみて、更新されたファイルに、更新を実行したときのタイムスタンプ、または更新パケット内の元のファイルのタイムスタンプがあるかどうかを確認してください（これはWindowsで一般的であり、Linuxディストリビューションではそうではありません） 、しかしその一方で、あなたはあなたが使用しているディストリビューションを言わなかった）。

また、チェックサムを同じディストリビューションの既知の適切なバージョンのものと比較することもできます。

更新

pam_systemd.sowasが正式に更新され（少なくとも、私が確認した1つのシステム、Ubuntu 14.04-LTSで）、パッチは報告した日に公開されました。

-rw-r--r-- 1 root root 42864 Feb  1 16:01 /lib/x86_64-linux-gnu/security/pam_systemd.so

私はイタリアにいますが、システムクロックはUTCです。スペインにいる場合、ファイルは更新されましたお互いの30分以内。

したがって、誰かが少なくとも2回（1月に1回、2月に1回）コンピュータを起動し、ログインしたかどうかにかかわらず、システムが自動更新を実行したと思います。

ラップトップなのかデスクトップなのか、プラグインされているのかによって、それ自体がオンになった可能性さえあります（2週間に1回程度、または雷雨）、その後、何時間か非アクティブになった後、自動的にオフになりました。

3
LSerni

変更として検出されたファイルtripwireの作成時刻を確認します。これらは、ユーザーが実行したインストールプロセスまたはcronジョブの結果であることがわかります。

あなたのシステムがtripwireを知っている誰かによって海賊版にされたとしたら、そのような変更ログは見つかりません。あなたはむしろtripwireがアンインストールされているのを発見したでしょう。 tripwireメインキーが弱すぎるか、同じコンピューターに平文で保存されていない限り、内部tripwireデータベースを破壊して攻撃による変更を隠す既知の方法はありません（2つの可能性により、セキュリティを知っている人にとっては愚かである）。

0
dan

私はあなたが提案したいくつかのパッケージをアップグレードし、日付を比較しました。私はあなたが更新で言及したのと同じ結論に達しました：

Tripwireによる言及された日付は、パッケージが変更された日付に依存し、システムでアップグレードされた日付には依存しません。それでも本当に外部からの攻撃を考慮する必要があるのでしょうか？ 2月27日（私が戻ってきた日）以降のアップグレードで、それ以前のパッケージ変更日である可能性はありませんか？

私は誰にでもかなり目立たないので、誰もが私のラップトップを操作してインターネット経由で起動し、私のアパートに侵入することはほとんどないようです。

しかし、他の質問に答えるために、私のログは2月27日の開始時も空の場合もありません。

kernel log starts 27.feb
syslog starts 07.03
wtmp begins Thu Mar  1 23:31:40 2018
btmp begins Tue Mar 13 23:07:08 2018
auth.log starts 27.02
faillog is completely empty

あなたの次の質問への答えはubuntu 16.04です

ここでの抜粋は、アップグレード前のものです。

Modified object name:  /usr/bin/update-notifier

  Property:            Expected                    Observed                    
  -------------        -----------                 -----------                 
* Inode Number         525831                      529894                      
* Size                 57736                       57704                       
* Modify Time          Di 12 Apr 2016 12:44:15 CEST
                                                   Do 18 Jan 2018 13:42:58 CET 
* CRC32                A/JGJG                      D/hJue                      
* MD5                  A94qrwY3famFuyjNRqByy/      AIg7I1UyImK4SMXV/P3IVE

...そしてそれはアップグレード後のものです：

Modified object name:  /usr/bin/update-notifier

  Property:            Expected                    Observed                    
  -------------        -----------                 -----------                 
* Inode Number         525831                      527608                      
* Size                 57736                       57704                       
* Modify Time          Di 12 Apr 2016 12:44:15 CEST
                                                   Fr 02 Mär 2018 15:40:49 CET
* CRC32                A/JGJG                      DLot5B                      
* MD5                  A94qrwY3famFuyjNRqByy/      D6A8JWReWbockgtVM8p70R

..しかし、その攻撃者の理論をサポートするために、もう1つ問題があります。私は、ebayアカウントに、適度な強力なパスワードを持つエイリアンの携帯電話番号を見つけました。

ああ、結束が壊れたので直そうとしたが失敗した。別のユーザーを作成したところ、問題はありませんでした。

0
user173381