データを認証するようにログアグリゲーターを構成するにはどうすればよいですか？
背景：リモートログ集約はセキュリティを向上させる方法と見なされています。一般に、これは、システムを侵害した攻撃者がログを編集または削除して、フォレンジック分析を妨害するリスクに対処します。私は一般的なログツールのセキュリティオプションを研究してきました。
しかし、何かがおかしいと感じています。一般的なリモートロガー（rsyslog、syslog-ng、logstashなど）を構成して、着信メッセージが本当にホストから発信されていることを認証する方法がわかりません。ある種のポリシー制約がなければ、あるログ発信者が別のログ発信者に代わってメッセージを偽造する可能性があります。
Rsyslogの作成者は ログデータの認証について警告するため ：
最後の注意点：transport-tlsは、送信者と受信者の間の接続を保護します。メッセージ自体に存在する攻撃から必ずしも保護するわけではありません。特にリレー環境では、メッセージは悪意のあるシステムから発信された可能性があり、無効なホスト名やその他のコンテンツがメッセージに挿入されています。そのようなものに対するプロビジョニングがない場合、これらのレコードは受信者のリポジトリに表示される可能性があります。 -transport-tlsはこれを防ぎません（ただし、適切に使用すると役立つ場合があります）。 syslog-transport-tlsはホップバイホップのセキュリティを提供することに注意してください。エンドツーエンドのセキュリティを提供せず、メッセージ自体を認証しません（最後の送信者のみ）。
したがって、フォローアップの質問は次のとおりです。ある程度の信頼性を提供する、適切で実用的な構成（rsyslog、syslog-ng、logstashなどの一般的なログツール）は何ですか？
または...誰もログデータを認証しない場合、なぜそうではない？
-
（余談：議論/比較する際に、 RFC 5424：セクション4.1：展開シナリオの例 -からのいくつかの図または用語を使用すると役立つ場合があります（例：「オリジネーター」vs「リレー」vs「コレクター」）
これは素晴らしい質問です。
私はlogstashを使用して、あなたが提案しているようなことを達成します。 logstash（またはlogstash-forwarder）を使用してログを中央収集システムに送信し、logstash構成を追加して、メッセージにキーフィールドを追加します。その値は、各サーバーに固有の長いランダムな文字列です。
次に、受信側で、対応するルールを追加して、特定のホストのキーがそのホスト名に期待するものと一致しないメッセージを破棄（またはアラート）することができます。
これは防弾ではありませんが、正しい方向への確かな一歩です。
これに使用する正しいことは、マシンクライアント証明書を使用したTLSです。
rsyslogは2008年頃からこれを行っており、優れた手順があります： http://www.rsyslog.com/doc/v8-stable/tutorials/tls_cert_summary.html
これらのことが進むにつれて、プロセスは非常に簡単です。
- CAを設定する
- ログを取得するすべてのコンピューターに証明書を発行します
- その認証を使用するようにrsyslogを構成します
そうすると、コンピュータが相互になりすますことができなくなり、証明書がないと誰もログサーバーにログインできなくなります。
あなたはすでにそれを見つけたようですが、あなたはまだ彼らの警告について心配しています。私はそれについてあまり心配しません。ログインジェクションは確かに重要ですが、アプリケーションを介したインジェクションやロギングプロセスへのインジェクションなど、多くのことがあります。認証されたrsyslogは、誰かがアプリケーションソフトウェアでログインジェクション攻撃を行った場合、あなたを保護しませんが、何も保護しません。アプリケーションを修正するだけでそれを助けることができます。これにより、なりすましログから保護されます。
他の警告は、リレーを使用しないことで簡単に軽減できますが、とにかく行う理由はほとんどありません。リレーがなく、rsyslogサーバーのgtls接続ドライバーに対してx509/nameオプションを使用する場合は、問題はありません。
Gtls config docも参照してください： http://www.rsyslog.com/doc/v8-stable/concepts/ns_gtls.html