データを認証するようにログアグリゲーターを構成する方法

背景：リモートログ集約は、セキュリティを向上させる方法の1つと見なされています。一般に、これは、システムを侵害する攻撃者がログを編集または削除して、フォレンジック分析を失敗させるリスクに対処します。一般的なログツールのセキュリティオプションを調査しています。

しかし、何かがおかしいと感じます。一般的なリモートロガー（rsyslog、syslog-ng、logstashなど）を構成して、受信メッセージが本当にホストから発信されたものであることを認証する方法がわかりません。なんらかのポリシーの制約がなければ、1つのログ発信者が別のログ発信者に代わってメッセージを偽造する可能性があります。

rsyslogの作者はログデータの認証について警告しているようです：

最後の注意点：transport-tlsは、送信者と受信者の間の接続を保護します。メッセージ自体に存在する攻撃から必ずしも保護するわけではありません。特にリレー環境では、メッセージは悪意のあるシステムから発信された可能性があり、無効なホスト名やその他のコンテンツがそのシステムに配置されています。そのようなものに対するプロビジョニングがない場合、これらのレコードは受信者のリポジトリに表示される可能性があります。-transport-tlsはこれから保護しません（ただし、適切に使用すると役立つ場合があります）。syslog-transport-tlsはホップバイホップのセキュリティを提供することに注意してください。エンドツーエンドのセキュリティは提供されず、メッセージ自体（最後の送信者のみ）は認証されません。

したがって、フォローアップの質問は次のとおりです。ある程度の信頼性を提供する（選択した一般的なログツール-rsyslog、syslog-ng、logstashなどの）良い/実用的な構成は何ですか？

または...誰もログデータを認証しない場合は、なぜですか？

-

（余談：議論/比較では、RFC 5424のいくつかの図や用語を使用すると役立つ場合があります：セクション4.1：配備シナリオの例 -たとえば「発信元」対「リレー」対「コレクター」）

これは素晴らしい質問です。

私はlogstashを使用して、あなたが提案しているようなものを達成します。logstash（またはlogstash-forwarder）を使用してログを中央収集システムに送信し、logstash構成を追加して、メッセージにキーフィールドを追加します。その値は、各サーバーに固有の長くランダムな文字列です。

次に、受信側で、対応するルールを追加して、特定のホストのキーがホスト名に期待するものと一致しないメッセージを破棄（または警告）できます。

これは防弾ではありませんが、正しい方向への確かな一歩です。

これに使用する正しいものは、マシンクライアント証明書を使用したTLSです。

rsyslogは2008年頃からこれを行っており、すばらしい指示があります：http : //www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html

次のように、プロセスは非常に単純です。

1. CAをセットアップする
2. ログを取得するすべてのコンピュータに証明書を発行します
3. その認証を使用するようにrsyslogを構成する

次に、あなたのコンピュータは互いに偽装することができず、誰もあなたの証明書のいずれかなしであなたのログサーバーにログインすることはできません。

あなたはすでにそれを見つけたようですが、あなたはまだ彼らの警告について心配しています。私はそんなに心配しません。ログインジェクションは確かに重要ですが、アプリケーションを介したインジェクションやロギングプロセスへのインジェクションなど、多くのことです。認証されたrsyslogは、誰かがアプリケーションソフトウェアでログインジェクション攻撃を受けても保護しませんが、何もできません。アプリケーションを修正するだけでそれを助けることができます。これにより、なりすましのログから保護されます。

他の警告は、リレーを使用しないことで簡単に軽減できますが、とにかくこれを行う理由はほとんどありません。リレーがなく、rsyslogサーバーのgtls接続ドライバーにx509 / nameオプションを使用する場合、問題はありません。

gtls構成ドキュメントも参照してください：http ://www.rsyslog.com/doc/v8-stable/concepts/ns_gtls.html