要約

  • Zeekのconn.logが示すのは、設定された一台のセンサーが受け取ったトラフィックから導いた接続像であり、各パケットの完全な記録ではない。
  • 長期に検証できる結論には、元ログとスキーマ、Zeekの版、スクリプト、観測点、フィルター、時計、損失情報、同じuidを持つ関連ログが必要だ。

省略することで見えるようにした

Paxsonが1998年に発表したBroの論文は、システムを二つの役割に分けていた。イベントエンジンはフィルター済みのパケット列を上位のネットワークイベントへ縮約する。ポリシースクリプトのインタープリターは、そのイベントを各組織の安全方針に照らして解釈する。観測の仕組みと対応の判断を切り離す設計だった。

高負荷の回線をリアルタイムで監視するには、この縮約が欠かせない。同時に、縮約は証拠の射程を決める。読みやすい一行の前には、ネットワーク上の位置、インターフェース、キャプチャフィルター、ヘッダー検査、状態管理、読み込まれたスクリプトがある。ログはその連鎖の出力であって、通信そのものではない。

初期論文はパケット損失を中心的な問題として扱った。監視側の処理が追いつかずバッファが尽きれば、その後のパケットが落ちる。失われた一個こそ侵入を識別する材料かもしれない。また、攻撃者が監視手法を知り、回避や過負荷を試みる前提も置いた。センサーの稼働状態は、証拠とは別の運用指標ではない。何を知り得たかを決める条件である。

列名の後ろにある「センサーが」を補う

現在のZeek文書によれば、conn.logは主としてレイヤー3と4の活動、すなわち誰が誰と、いつ、どれだけの時間、どのプロトコルで通信したかを記録する。TCPだけでなくUDPも扱う。UDPとICMPでは「connection」をパケットの流れという意味で使うため、TCPセッションと同じ状態概念を期待してはいけない。

tsはZeekが最初に見たパケットの時刻である。経路全体でそれ以前のパケットが存在しなかったという証明ではない。uidはZeek内で接続を一意に結び付け、DNS、HTTP、TLSなどの別ログを横断するための鍵になる。端点が合意した識別子ではない。

conn_stateは観測から得た状態の要約だ。S0は接続試行を見たが応答を見なかった状態、SFは正常な確立と終了を見た状態を表す。拒否、リセット、片側だけの終了を示す値もある。片方向しか通らない観測点、遅れて起動したプロセス、損失中のセンサーなら、同じ端点間のやり取りを別の状態に分類し得る。

historyもパケット列ではない。大文字は発信側、小文字は応答側のイベントを示し、SYN、SYN-ACK、ACK、データ、FIN、RST、ギャップ、再送などを文字へ圧縮する。一方向につき一度しか残さない種類があり、回数を対数的に表す種類もある。接続の形を素早く読むには優れるが、完全な順序と個数を持たないため、文字列からPCAPを復元することはできない。

数値にも計算方法がある。TCPのorig_bytesとresp_bytesはシーケンス番号から求められ、大きな接続などでは不正確になり得る。durationには、片方向が閉じた後の新しいペイロードを伴わない末尾パケットの一部が入らないが、historyには現れる場合がある。パケット数やIPバイト数は接続サイズ解析器を有効にした場合だけ記録される。local/remote判定はSite::local_nets次第だ。空欄はネットワーク上の不在ではなく、設定上の未定義かもしれない。

観測者の状態を同時に調べる

missed_bytesは内容のギャップで失われたバイト数を示す。ゼロ以外なら通常、プロトコル解析は失敗するが、損失前に一部の解析が終わっていることもある。capture_loss.logはTCPシーケンス番号の飛びを検出し、欠けたトラフィックをキャプチャ損失と推定する。方法が明示されているからこそ、指標の強みと限界を分けられる。

reporter.logには、トラフィック処理や計算資源に関する内部の警告とエラーが残る。対象時間の接続ログだけを読むのではなく、損失推定、警告、再起動、フィルター変更、インターフェース状態を重ねる必要がある。

missed_bytesがゼロでも、ミラーポートより上流の欠落、非対称経路、除外フィルター、監視開始前の空白は否定できない。一方、損失が記録されたからといって全列を捨てる必要もない。不確実性を時刻、方向、観測点、処理段階に限定して記述すれば、使える事実まで曖昧にせずに済む。

一行ではなく、再検証できる一式を残す

数か月後の事故調査、懲戒、訴訟、保険、規制報告に使うなら、元のログと正確なスキーマ、Zeekの版、読み込んだスクリプトと主要設定、センサーの回線上の位置とインターフェース、キャプチャフィルター、時刻源と測定したずれを保存する。同じ時間帯のcapture_loss.log、reporter.log、同一uidのプロトコルログも一緒にする。

プライバシーと保存方針が許せば、改変不能なPCAPの区間、または管理下の保存先を検証できるハッシュを添える。PCAPにも観測点、snap length、損失、保管履歴があるため絶対視はできない。それでも、圧縮された推論をより低い層の観測と照合できる。

PCAPがない場合は、その事実を明記する。「この位置のZeekセンサーが、この設定で観測し要約した」と書けばよい。証拠の範囲を狭めることは、結論を弱めることではない。

スキーマの保存も重要だ。現在の文書はip_protoがZeek 7.1で追加されたと記す。スクリプトは列を増やし、記録動作を変えられる。版やヘッダーがなければ、将来の解析器が古い列に新しい意味を与えてしまう。

情報源