タグ付けされた質問 「syslog-ng」

背景：リモートログ集約は、セキュリティを向上させる方法の1つと見なされています。一般に、これは、システムを侵害する攻撃者がログを編集または削除して、フォレンジック分析を失敗させるリスクに対処します。一般的なログツールのセキュリティオプションを調査しています。 しかし、何かがおかしいと感じます。一般的なリモートロガー（rsyslog、syslog-ng、logstashなど）を構成して、受信メッセージが本当にホストから発信されたものであることを認証する方法がわかりません。なんらかのポリシーの制約がなければ、1つのログ発信者が別のログ発信者に代わってメッセージを偽造する可能性があります。 rsyslogの作者はログデータの認証について警告しているようです： 最後の注意点：transport-tlsは、送信者と受信者の間の接続を保護します。メッセージ自体に存在する攻撃から必ずしも保護するわけではありません。特にリレー環境では、メッセージは悪意のあるシステムから発信された可能性があり、無効なホスト名やその他のコンテンツがそのシステムに配置されています。そのようなものに対するプロビジョニングがない場合、これらのレコードは受信者のリポジトリに表示される可能性があります。-transport-tlsはこれから保護しません（ただし、適切に使用すると役立つ場合があります）。syslog-transport-tlsはホップバイホップのセキュリティを提供することに注意してください。エンドツーエンドのセキュリティは提供されず、メッセージ自体（最後の送信者のみ）は認証されません。 したがって、フォローアップの質問は次のとおりです。ある程度の信頼性を提供する（選択した一般的なログツール-rsyslog、syslog-ng、logstashなどの）良い/実用的な構成は何ですか？ または...誰もログデータを認証しない場合は、なぜですか？ - （余談：議論/比較では、RFC 5424のいくつかの図や用語を使用すると役立つ場合があります：セクション4.1：配備シナリオの例 -たとえば「発信元」対「リレー」対「コレクター」）

8 security  logging  rsyslog  logstash  syslog-ng 

ng 3.6.3のCentOS 6.6 64bitでのソースコンパイルから再生するために、デフォルトのrsyslogファイル名とログの場所をできるだけ複製するポインターまたはsyslog-ng.confの例があるかどうか疑問に思っていました。デフォルトのソースtarball /usr/local/etc/syslog-ng.confは、/ usr / local / etc / syslog-ng.confで次のもののみを提供します # Default syslog-ng.conf file which collects all local logs into a # single file called /var/log/messages. # @version: 3.6 @include "scl.conf" source s_local { system(); internal(); }; source s_network { udp(); }; destination d_local { file("/var/log/messages"); }; log …

1 centos  rsyslog  syslog-ng