8. Security Considerations (セキュリティに関する考慮事項)
8.1. UNICODE
悪意を持って不正な形式にされた可能性のある有効な Unicode は syslog メッセージの問題です ([UNICODE-TR36] を参照)。たとえば, メッセージは良性のメッセージのように見えるように作成される可能性がありますが, デコード後には悪意のあるコンテンツが含まれます。これを防ぐために, アプリケーションはセクション 6.3.3 で義務付けられているように "shortest form" (最短形式) でメッセージをエンコードしなければなりません (MUST)。また, これらのメッセージをデコードするアプリケーションは, いずれかの文字を操作する前にエンコーディングが "shortest form" であることを確認しなければなりません (MUST)。
8.2. Control Characters (制御文字)
PARAM-VALUE は制御文字を含む可能性があります。これは Unicode で表現できる任意の情報の受け渡しをサポートするために必要な機能です。ただし, これは syslog メッセージが一部のディスプレイデバイスに特別な意味を持つ文字を含むことができることも意味します。たとえば, キャリッジリターン文字を使用して端末ディスプレイ上のメッセージの以前に表示された部分を上書きし, セキュリティ関連のメッセージや変更を隠す可能性があります。また, コンテンツの表示方法に影響を与える可能性のある制御文字が存在し, これも誤った表現の可能性を許します。
仕様は syslog アプリケーションが PARAM-VALUE で制御文字を発行すべきではない (SHOULD NOT) ことを推奨します。syslog アプリケーションが制御文字を使用する場合, コレクターまたはリレーでメッセージを解釈できない可能性があります。また, 制御文字はログメッセージの閲覧者を混乱させたり誤解させたりする可能性があります (MAY)。syslog メッセージを受信する syslog アプリケーションは, 制御文字をフィルターするか, 表示する前に無害な文字に置き換えることが推奨されます (RECOMMENDED)。
同様のリスクが MSG フィールドにも存在します。MSG の文字セットはそれほど厳格ではありませんが, syslog メッセージの MSG 部分でも同様の予防措置を講じることが推奨されます (RECOMMENDED)。
8.3. Message Truncation (メッセージの切り詰め)
この仕様は準拠するトランスポート受信者が 480 オクテットまでの長さのメッセージを受け入れることができることを義務付けています。トランスポート受信者は 2048 オクテットまでの長さのメッセージを受け入れることができるべきです (SHOULD)。これらの最小必要長を超えるものは許容されますが, オプションです。送信者は常に望む任意の長さのメッセージを送信できます。ただし, メッセージはトランスポート受信者によって切り詰められるか, より低い最大メッセージ長機能を持つデバイスを含むリレーチェーンを通過しなければならない場合があります。この切り詰めはメッセージの意味を変更したり, 重要な情報を削除したりする可能性があります。これにより意味のあるログ分析を実行することも困難になる可能性があります。
切り詰めの確率はメッセージ長を 480 オクテット未満に保つことで大幅に削減できます。同時に, 実装は少なくとも 480 オクテットのメッセージを受け入れることができなければならず (MUST), 2048 オクテットのメッセージを受け入れることができるべきです (SHOULD)。それを超えるものは裁量です。
8.4. Replay (リプレイ)
Syslog メッセージ伝送は, 単独では, 受信されたメッセージが実際に送信されたメッセージであること, またはメッセージが自称送信者からのものであることさえも保証しません。暗号検証が行われても, 悪意のある観察者は有効なメッセージを記録し, 後の時刻にそれらをリプレイする可能性があります。これにより, 受信者は特定のイベントがメッセージが最初に送信された時刻とは異なる時刻に発生したと信じる可能性があります。せいぜい, これはマシンの状態の不正確な分析を引き起こす可能性があります。最悪の場合, これは不要な是正措置をトリガーする可能性のある誤った警報を引き起こしたり, 是正措置をトリガーすべきだった真の警報をマスクしたりする可能性があります。
8.5. Reliable Delivery (信頼できる配信)
syslog はシンプレックスプロトコルであるため, デフォルトでは配信の保証を提供しません。悪意のある観察者は転送中にメッセージを単に削除したり, 受信者がすべてのメッセージを受け入れることができないほど多くのトラフィックを生成したりすることができます。配信の保証を提供する syslog トランスポートを構築することは可能ですが, そのような構成はこの文書の範囲外です。syslog の信頼できるトランスポートに関する詳細情報は [RFC3195] にあります。
メッセージはリレーを介してリレーされている間に削除または転送されることも可能です。たとえば, リレーは特定の重大度または特定のオリジネーターからのすべてのメッセージを削除するように設定または侵害される可能性があります。
8.6. Congestion Control (輻輳制御)
Syslog メッセージは輻輳制御を提供しないプロトコルを使用して送信される可能性があります。これによりメッセージの損失とネットワーク輻輳が発生する可能性があります。これを防ぐために, 使用されるトランスポートプロトコルは輻輳制御を提供すべきです (SHOULD)。輻輳制御機能はトランスポートプロトコルに依存します。
8.7. Message Integrity (メッセージの完全性)
この仕様は, メッセージが中間者によって変更, 削除, または注入されないことを保証するネイティブな手段を提供しません。セキュリティに敏感な syslog 通信はメッセージの完全性を提供するトランスポートを使用することが推奨されます (RECOMMENDED)。メッセージの完全性は暗号署名の使用を含む様々な手段を通じて達成できます。ただし, これらのメカニズムはこの仕様では説明されておらず, トランスポートプロトコルに依存します。
8.8. Message Observation (メッセージの観察)
単独では, この仕様はメッセージにネイティブな機密性を提供しません。syslog のシンプレックスな性質のため, 伝送への物理的または電子的アクセスを持つ誰かがメッセージに含まれる情報を盗聴することは容易です。したがって, syslog メッセージは悪意のある行為者によって観察される可能性があります。セキュリティに敏感な syslog 通信はメッセージの機密性を提供するトランスポートを使用することが推奨されます (RECOMMENDED)。
8.9. Inappropriate Configuration (不適切な設定)
Syslog メッセージは機密情報を含むことができます。たとえば, syslog メッセージはネットワークトポロジー, システム設定, またはユーザー ID に関する情報を含む可能性があります。この情報は攻撃者に有用である可能性があります。Syslog メッセージは機密情報 (例: パスワード) を含むべきではありません (SHOULD NOT)。ただし, 何が機密情報を構成するかの包括的なリストを定義することは不可能です。syslog 経由で送信される情報の機密性の適切性はローカルポリシーの問題です。ローカル管理者は MSG フィールドの任意の情報がこの仕様によって保護されていないことを理解することが重要です。
オペレーターは, コンテンツが適切に匿名化されているか他の手段で保護されていない限り, 機密情報を伝達するために syslog を使用すべきではありません (SHOULD NOT)。これは以下を含む多数の方法を通じて行うことができます:
- TLS などの機密チャネルを介して syslog メッセージを送信する
- 機密情報を削除するためにメッセージを事前フィルタリングする
- 保護されたネットワーク環境内でのみ syslog を使用する
8.10. Forwarding Loop (転送ループ)
syslog リレーチェーンでは, 設定エラーにより転送ループが発生する可能性があります。たとえば, リレー A がリレー B にメッセージを転送するように設定され, リレー B がリレー A にメッセージを転送するように設定される可能性があります。そのようなループはリソースの枯渇やその他の問題を引き起こす可能性があります。実装はそのようなループを検出し, 検出された場合は通知を発行するように試みるべきです (SHOULD)。ループを検出する 1 つの方法は, 各リレーでチェックできるオリジネーター固有の識別子をメッセージに含めることです。たとえば, origin SD-ID がこの目的に使用される可能性があります。
8.11. Load Considerations (負荷に関する考慮事項)
実装者とオペレーターは syslog メッセージの生成, 送信, リレー, および収集に関連するパフォーマンス特性と負荷要因を考慮する必要があります。syslog は通常運用監視, デバッグ, およびセキュリティ分析に使用される情報を伝達する手段として使用されるため, syslog メッセージを送信する行為自体が運用上の問題やセキュリティ脆弱性を作成しないことが重要です。
たとえば, 過度な量の syslog メッセージはトランスポートネットワークの容量を圧倒する可能性があります。同様に, リレーまたはコレクターは処理できるよりも速い速度でメッセージを受信した場合に圧倒される可能性があります。このようなリソースの枯渇は失われたメッセージ, 遅延したメッセージ, またはサービス拒否をもたらす可能性があります。Syslog 実装はシステムとネットワークに課す負荷を制限するための適切な制御を持つべきです (SHOULD)。
8.12. Denial of Service (サービス拒否)
Syslog トランスポートプロトコルはサービス拒否攻撃を検出して処理できるべきです (SHOULD)。受信者は誤設定または攻撃のいずれかにより, メッセージであふれさせられる可能性があります。syslog 受信者はメッセージを受け入れる速度を制限する機能を持つことが推奨されます (RECOMMENDED)。また, 受信者は未承認の送信者または疑わしいコンテンツを持つメッセージを拒否するためにメッセージをフィルタリングする機能を持つことが推奨されます (RECOMMENDED)。