8. セキュリティに関する考慮事項
本節では syslog プロトコルのセキュリティに関する考慮事項を扱う。syslog を安全に展開するため、実装者と運用者はこれらの問題を認識しなければならない。
8.1. UNICODE
本仕様では、STRUCTURED-DATA に UTF-8 符号化を使用することを要求する。UTF-8 は Unicode 文字セット全体を符号化できる。
セキュリティ上の懸念:
- 表示上の問題: Unicode 文字には、他の文字と視覚的に類似するものがあり、なりすまし攻撃が可能になる場合がある。例えば、ラテン文字に似たキリル文字がある。
- 制御文字: Unicode には、表示または解析に影響する可能性がある多数の制御文字および書式文字が含まれる。
- 正準等価性: 異なる Unicode シーケンスが同じ視覚文字を表現する可能性があり、セキュリティフィルタを回避するおそれがある。
推奨事項:
- syslog メッセージを表示するアプリケーションは、適切な Unicode 処理およびサニタイズを実装するべきである。
- Unicode 文字列を正準形式に正規化することを検討する。
- 双方向テキストの問題を認識する。
- syslog メッセージに含める前に、利用者提供データを検証しサニタイズする。
8.2. 制御文字
syslog メッセージ内の制御文字は、表示の問題またはセキュリティ問題を引き起こす場合がある。
懸念事項:
- 端末制御シーケンスが表示出力を変更する場合がある。
- ヌルバイトにより、一部の実装では文字列が切り詰められる場合がある。
- 復帰および改行により、ログ解析が崩れる場合がある。
推奨事項:
- メッセージを表示する際は、制御文字をフィルタまたはエスケープする。
- 処理前にメッセージ内容を検証する。
- 構造化情報を自由形式テキストに埋め込む代わりに、構造化データ要素を使用する。
8.3. メッセージの切り詰め
送信中にメッセージが切り詰められた場合、重要な情報が失われる可能性がある。
セキュリティ上の影響:
- セキュリティに関連する詳細が削除される可能性がある。
- 切り詰めは relay ポイントまたはトランスポート境界で発生する場合がある。
- 攻撃者が切り詰めを悪用して悪意のある活動を隠すおそれがある。
推奨事項:
- 重要な情報はメッセージの先頭、最初の 480 オクテット以内に置く。
- 重要なメタデータには STRUCTURED-DATA を使用する。
- 必要に応じて、より大きなメッセージをサポートするトランスポートプロトコルを実装する。
- collector で切り詰められたメッセージを監視する。
8.4. リプレイ
syslog メッセージは攻撃者によって取得・再送される可能性がある。
攻撃シナリオ:
- 古いメッセージを再送して現在の活動を不明瞭にする。
- collector にリプレイメッセージを大量送信する（DoS）。
- 古いイベントを注入してフォレンジック分析を混乱させる。
推奨事項:
- 認証済みかつ暗号化されたトランスポート（TLS）を使用する。
- シーケンス番号（meta sequenceId）を含める。
- 正確なタイムスタンプを含める。
- メッセージ発信元の検証を実装する。
- 重複メッセージまたは順序外メッセージを監視する。
8.5. 信頼できる配信
本仕様は信頼できる配信を要求しない。メッセージが失われる場合がある。
セキュリティ上の影響:
- セキュリティイベントが記録されない可能性がある。
- メッセージの消失により攻撃が隠される可能性がある。
- 準拠要件を満たせない場合がある。
推奨事項:
- セキュリティに関連するメッセージには、信頼できるトランスポートプロトコル（TCP/TLS）を使用する。
- アプリケーション層でメッセージ確認応答を実装する。
- メッセージ消失を検出するためシーケンス番号を使用する。
- メッセージ消失の可能性を認識したセキュリティ監視を設計する。
- 重要なシステムでは冗長なロギング経路を検討する。
8.6. 輻輳制御
ネットワークの輻輳または処理の過負荷により、メッセージの消失または遅延が生じる可能性がある。
懸念事項:
- 攻撃時のメッセージバーストが失われる場合がある。
- 遅延したメッセージが順序どおりに届かない場合がある。
- リソース枯渇が重要なシステムに影響する可能性がある。
推奨事項:
- 送信者でレート制限を実装する。
- 輻輳制御を持つトランスポートプロトコルを使用する。
- キューの深さとメッセージ遅延を監視する。
- セキュリティに関連するメッセージを優先する。
- メッセージバーストを処理できるシステムを設計する。
8.7. メッセージ完全性
syslog は本質的にメッセージ完全性保護を提供しない。
脅威:
- メッセージが転送中に変更される可能性がある。
- 攻撃者が relay ポイントでメッセージを変更する場合がある。
- ネットワークエラーによりメッセージが破損する場合がある。
推奨事項:
- 完全性保護には TLS トランスポートを使用する。
- 必要に応じてエンドツーエンドのメッセージ署名を実装する。
- collector でメッセージ形式と内容を検証する。
- 不正な形式または疑わしいメッセージを監視する。
8.8. メッセージの観測
syslog メッセージには機密情報が含まれる場合がある。
プライバシー上の懸念:
- 個人情報が記録される場合がある。
- システムの詳細が攻撃者を助ける可能性がある。
- 業務上機密性の高いデータが露出する可能性がある。
推奨事項:
- 暗号化トランスポート（TLS）を使用する。
- 機密情報を除去するためメッセージをサニタイズする。
- collector にアクセス制御を実装する。
- 規制要件（GDPR、HIPAA など）を認識する。
- パスワード、鍵、その他の秘密を記録しない。
8.9. 不適切な構成
誤った構成はセキュリティ脆弱性を生む場合がある。
一般的な問題:
- 誤った collector へのメッセージ送信
- 信頼できないネットワークへの syslog サービスの公開
- 不十分なアクセス制御
- 不適切なメッセージフィルタリング
推奨事項:
- 構成検証を実装する。
- ファイアウォール規則を使用して syslog トラフィックを制限する。
- syslog インフラストラクチャを定期的に監査する。
- 本番以外の環境で構成変更をテストする。
- 構成標準を文書化する。
8.10. 転送ループ
メッセージ転送ループはリソース枯渇を引き起こす可能性がある。
懸念事項:
- メッセージが relay 間を無期限に循環する。
- ネットワークおよびシステムリソースが消費される。
- 正当なメッセージが失われる可能性がある。
防止策:
- ホップ数の上限を実装する。
- 転送ループを検出し、遮断する。
- relay トポロジーを慎重に設計する。
- relay の動作を監視する。
- relay でループ検出を実装する。
8.11. 負荷に関する考慮事項
大量のメッセージがシステムを圧倒する可能性がある。
問題:
- receiver または relay の枯渇
- 負荷時のメッセージ消失
- 性能低下
推奨事項:
- 想定負荷およびピーク負荷に対する容量計画を行う。
- レート制限を実装する。
- 効率的なメッセージ処理を使用する。
- システム性能を監視する。
- 必要に応じてインフラストラクチャをスケールする。
8.12. サービス拒否
syslog インフラストラクチャは DoS 攻撃に脆弱である。
攻撃ベクトル:
- 大量のメッセージによるフラッディング
- 不正な形式のメッセージを送信して receiver をクラッシュさせる
- 過剰なロギングによるストレージの消費
- relay インフラストラクチャを標的にする
緩和策:
- すべての層でのレート制限
- 入力検証
- リソースクォータ
- 冗長なインフラストラクチャ
- ネットワーク層の保護（ファイアウォール、IDS）
- 認証および認可