問題:整合性を保証する必要があるファイルのコレクション(ソースコードなど)があります。ファイルが破損しているかどうかは気にしません(複数のバックアップを簡単に作成できます)。ファイルが調整されていないことを確認したいだけです。
今、(おそらく)侵害されているシステムにコレクションを保存するとします。ファイルが調整されないようにするために、私ができることの1つは、ソースコードファイルのチェックサム(SHA256など)を外部システムに保存することです。システムが本当に危険にさらされたら、ファイルを(これがセキュリティ違反にならないように十分に注意して)別のシステムに転送し、チェックサムを確認します。チェックサムが一致する場合、ファイルは(ほとんどの場合)安全です。
ただし、このアプローチでは、チェックサムを保存する安全な外部システムが必要です。さらに悪いことに、チェックサムは調整される場合があります。チェックサムが調整されていないことを確認できれば、その外部システムにすべてのファイルを保存して(スペースに問題がないと想定)、ファイルが調整されないようにすることができます。
重要な何かを見逃しましたか?ファイルの整合性を保証するシステムを作成できますか?または、ファイルのコレクションの単純な暗号化で十分ですか?
まず第一に、セキュリティの観点から、破損および改ざんされたファイルは同じ。完全性はもはや与えられません。限目。どちらの場合も、バックアップが必要です。
チェックサムは良いアプローチです。お気づきのように、ファイルを保存しているシステムが危険にさらされている場合、セキュリティ対策が損なわれないようにするために外部(つまりtrusted)システムが必要です。外部システムでチェックサムを使用する代わりに、ファイルに署名して署名を保存するか、プレーンなSHA256の代わりにHMACを使用できます。これにより、攻撃者がファイルに変更を加えた場合に、署名/チェックサムを偽造することができなくなり、何らかの改ざんに気付くことができます。
どちらの場合も、外部マシンに格納する必要がある秘密(秘密鍵またはHMAC鍵)は1つだけです。また、シークレットにアクセスできる任意のマシンから整合性チェックを実行できます(ファイル自体に保存できるため、チェックサムのリストは必要ありません)。
HMAC(またはその他の鍵ベースのハッシュアルゴリズム)と署名アルゴリズムの実装はいくつかあります。ニーズに最もよく適合するものは、環境によって異なります。
簡単な解決策は、同じ場所にあるデジタル署名されたファイルにチェックサムを保存することです。
署名に使用する秘密鍵の制御を保持している限り、その鍵にアクセスすることなく、ファイルセット全体の整合性を簡単に確認できます。
このようなものは [〜#〜] pgp [〜#〜] で実装するのは簡単です。
要件を正しく理解している場合:
解決策は私には明らかであるように見えます。これは、おそらく要件に何かを見落としたことを示唆しています。しかし、すでにバックアップがあります-したがって、すでにチェックサムを持っています(またはバックアップから簡単に計算できます)。
場所Aが侵害された場合、場所Aからファイルを取得する必要はありません(そして、それらのチェックサムを比較する)-バックアップを取るだけです!
たとえば、wordpress Webサイト(phpファイル、画像ファイル、および.sqlバックアップファイルのコレクションです)を持っています。毎日午前12時にファイルをバックアップしています。サイトが侵害された場合、マルウェアに感染したり、バックアップから復元したりするだけです。
バックアップの履歴が適切である限り(たとえば、30日程度)、感染が発生したときよりもいつでも前に戻ることができます。たとえば、攻撃者はindex.php
ファイル。 30日以上前に戻ってファイル履歴を確認し、感染がいつ発生したかを把握し、最後の「正常な」バックアップから復元することができました。
最初の質問の問題は、ローカルシステムのみを使用してローカルシステム上のファイルの整合性を確立しようとしていたことでした。
推論に欠けているのは冗長性の重要性だと思います。チェックサムの保存に信頼できる外部システムまたは外部メディアに依存する必要がある場合は、ファイルを保存して整合性を忘れないでください。そのシステムまたはメディアはとにかく信頼されるからです。問題は、システムやメディアを信頼する必要はないが、「冗長性」、つまり、複数の異なるシステムで同時にデータが危険にさらされる可能性が低いという事実を信頼する必要があることです。メディア。
だからあなたがしなければならないのはこれです:
diff computed_checksums.txt stored_checksums.txt
を実行します。整合性に問題がなければ、diffは違いを報告しません。他のシステムまたはメディア、B、Cなどについても同じようにします。sha256sum checksums_stored_on_A.txt
など)を計算し、B、Cなどで同じことを行います。結果のチェックサムが同じ場合、すべてのチェックサムファイルが同じ。それらが信頼できるのは、さまざまなシステムやさまざまなメディアで同じようにすべてが侵害されている可能性は低いという事実を信頼しているからです。結果の1つ以上のチェックサムが他のチェックサムと異なることが判明した場合は、もちろん、実際に安全なバックアップと侵害されたバックアップを見つける必要があります。いくつかのメモ:
感染したシステム。感染したシステムを使用してファイルを管理したり、外部メディアを接続したり、チェックサムを計算したりする場合、この方法は理論的には動作することが保証されていません。まったく信頼できるため、コマンドsha256sum
でも危険にさらされる可能性があります。または、cp
、または一般的にbashなどです。感染したシステムに関連する問題の可能性を減らすには、整合性を確認します異なるシステムで、おそらく異なるOSを実行している、など。
チェックサムを検証しています。diff computed_checksums.txt stored_checksums.txt
ではなくsha256sum -c stored_checksums.txt
を使用してチェックサムをチェックするのはなぜですか?これは、sha256sum -c stored_checksums.txt
がstored_checksums.txt
にリストされているファイルをチェックするだけであり、バックアップ内のすべてのファイルに対応するチェックサムがあることを確認できないためです。つまり、悪意のあるファイルがバックアップにaddedされている場合、sha256sum -c stored_checksums.txt
を使用してそれを知ることはできません。一方、diff
でmyメソッドを使用すると、追加されたファイルが表示されます。計算されたチェックサムには含まれますが、保存されているチェックサムには含まれません。