要約

  • RFC 3164が記録した運用では、PRIは読めるがTIMESTAMPが欠けるパケットに、リレー自身の現在のローカル時刻と、可能ならリレーが知る機器名またはアドレスを加えた。
  • 補完後もパケットは1024バイト以内でなければならず、超過分は末尾から切られた。文脈の追加が、元メッセージの重要な結論を消すことがあった。
  • 後の仕様は発生元、リレー、収集側、転送側の役割を整理したが、整ったヘッダーや完全なフレーム、TLSの相手認証だけで、メッセージの端から端までの来歴は証明できない。

ヘッダーの修復には、本文のバイトが使われた

RFC 3164は2001年、すでに普及していたBSD syslogの振る舞いを文書化した。メッセージを作るdevice、受け取って先へ送るrelay、受け取るが転送しないcollectorを区別する。送信側は、次の機械がリレーなのか収集装置なのかを知らなくてもよかった。

リレーは受信すると、まず山括弧内のPRIを調べ、次にTIMESTAMPの書式を確認した。両方が有効で、設定上その優先度を転送するなら、パケットを変更せず送らなければならない。この場合、時刻が正しいかを検証する義務はなく、HOSTNAMEがネットワーク上の送信元と一致するかも確かめなくてよい。書式の成立は、内容の真実性とは別だった。

PRIは有効だがTIMESTAMPがない、または書式が不正なら、リレーが介入する。PRIの直後に時刻と空白を挿入しなければならない。その時刻は元の出来事を復元したものではなく、リレー自身の現在のローカル時刻だった。さらに、分かるならリレーが認識している機器名を、分からなければIPアドレスをHOSTNAMEとして加えることが推奨された。残りの受信内容はCONTENTとして後ろへ続く。

ここで固定長の矛盾が現れる。RFC 3164はパケット全体を1024バイト以下とした。時刻や機器名を足したあと、リレーは長さを再確認し、1024バイトを超えればそこまで切り詰めなければならない。仕様自身が、元パケット末尾の重要情報を失う可能性を指摘している。

したがって補完は、空いている欄へ無償で情報を書く操作ではない。同じ予算の中で、リレーが付けた観測情報と発生元の本文が競合する。対象名、エラー番号、処理結果、あるいは否定を決める一語が最後にあれば、収集側には整った冒頭と結論のない記録が残る。

PRIまで欠けると、整形の負担はさらに増えた

PRIがない、または識別不能な場合、リレーは既定の優先度13を挿入し、時刻を加え、できればHOSTNAMEも加えた。受信した全体はCONTENTとして扱われる。ここでも完成品に同じ1024バイト制限がかかる。

一度整形されたパケットを次のリレーが受けると、有効なPRIとTIMESTAMPがあるため、そのまま転送できる。最終的な一枚だけを見ても、どの項目が発生元の記述で、どれが途中の補筆かは必ずしも分からない。切り落とされた末尾は、そもそも痕跡を残さないこともある。

旧式のTIMESTAMPは月、日、ローカル時刻を表す一方、年とタイムゾーンを持たなかった。収集側が保存時期から年を推定しても、年越しや遅延、時計のずれが残る。リレー時刻が直接示すのは、そのリレーがいつパケットを見たかであり、発生元でイベントが起きた時刻ではない。

境界を正確に数えても、以前の切断は見抜けない

2009年のRFC 5424は、originator、relay、collectorに加え、transport senderとtransport receiverを明示した。ヘッダーにはVERSION、TIMESTAMP、HOSTNAME、APP-NAME、PROCID、MSGIDが並び、構造化データも置ける。受信側は少なくとも480オクテットを受け入れ、2048オクテットまで扱えることが推奨された。

対応できる長さを超えた場合、受信側はペイロードを切り詰めることが推奨され、破棄も許される。切るなら必ず末尾からである。先頭の生存率は上がるが、途中でUTF-8や構造化データが壊れることはある。安全性の節は、攻撃者が切り詰めを利用して重要情報を隠せると警告し、重要事項を早い位置へ置くよう促した。

RFC 5425のTLS転送は、メッセージ長、空白、メッセージというオクテットカウントで境界を示す。複数のTLSレコードにまたがっても終端を判断できる。ただし、TLSで認証された転送相手の識別名が、メッセージ内のHOSTNAMEと対応するとは限らない。保護はホップ単位であり、内部の発生元主張を自動的に証明しない。

RFC 5426ではUDPデータグラム一つにsyslogメッセージ一つを入れるが、それは完全でも切り詰め済みでもよい。RFC 6587はTCP上のオクテットカウントと終端文字方式を記録した。どちらも今ある単位の境界を示すだけで、前のリレーが捨てたバイトを復元しない。

IANAのsyslog Parameters登録簿はfacility、severity、version、構造化データ識別子を解釈する手掛かりになる。番号の登録は、実装、設定、到達、保存、発生元の正しさを証明するものではない。

RFC 5424には任意のtimeQuality構造化データもある。発生元は、タイムゾーンを知っているか、時計が同期しているか、どの程度の精度だと考えるかを表せる。年もタイムゾーンもなかったRFC 3164の時刻より判断材料は増えるが、それでも発生元による申告である。収集側が独立に時計を検証したことにはならない。

UDPの最低受信能力も一律ではない。RFC 5426はIPv4受信側に480オクテット、IPv6受信側に1180オクテットまでの受信を要求し、すべてに2048オクテットまでを推奨する。最小MTUでの断片化を避けやすくする基準であり、大きなメッセージが経路を通り、実装に受理され、保存層に残ることを一括して保証する数ではない。

したがって、保存された長さがちょうど1024バイトであることだけから、RFC 3164型の切断を断定してはならない。最初からその長さだった可能性も、別の境界で短くなった可能性もある。仕様が示すのは機構であり、個別事案の帰属には前後のコピーと設定が要る。

出典