多くの人が最初に戸惑うのが、「ZeekはIDS（侵入検知システム）なの？」という点です。答えは“半分そう、半分違う”。SnortやSuricataのような典型的なIDSは、「既知の悪いパターン（シグネチャ）」に一致したらアラートを出します。一方Zeekは、シグネチャ照合もできますが、本領は「観測した通信を、淡々と意味のあるログに書き起こす」こと。たとえば1本のHTTP通信から、アクセス先URL・ユーザーエージェント・応答コード・転送量などを抽出し、http.log に1行として残します。悪いと決めつける前に、まず“事実”を記録する。この姿勢が、後からの追跡（フォレンジック）と脅威ハンティングを支えます。

Zeekの真価は「3つのツールの役割分担」を知ると、はっきりします。下の表のとおり、Wireshark・Suricata・Zeekは“競合”ではなく“補完”の関係。とくにSuricataとZeekは併用するのが定番で、「既知の悪はSuricataで即アラート、振る舞いと記録はZeekで網羅」という組み合わせが、現代のNSMの王道です。

Zeekを動かすと、ディレクトリにたくさんの .log ファイルが生まれます。それぞれがプロトコルや観点ごとの“台帳”で、1行が1つの出来事（トランザクション）です。まずは代表的なログを押さえましょう。

この中で絶対の主役が conn.log です。ネットワーク上のあらゆる接続を1行ずつ記録する“背骨”で、ほかのログはここから枝分かれします。1行を読んでみましょう。

▲ duration（継続時間）や orig_bytes/resp_bytes（転送量）、conn_state（接続の状態：SF=正常終了、S0=応答なし、REJ=拒否 等）を見るだけで、通信の“性格”が浮かびます。

そして、すべてのログをつなぐ“背番号”が uid（ユニークID）です。1つの接続には固有のuidが振られ、同じuidが conn.log・http.log・files.log…に共通で現れます。だから「この怪しい接続（conn.log）は、どのURLへ行き（http.log）、どんなファイルを運んだか（files.log）」を、uidをたどるだけで串刺しに復元できる。これがZeekログの“魔法”です。

Zeekログの価値は、攻撃の“足跡”が構造化された形で残ることにあります。シグネチャに頼らず、「振る舞いの異常」から脅威を狩る（ハンティング）——これがNSMの醍醐味です。代表的な4つの着眼点を見ましょう。

こうした“狩り”は、特別なツールがなくても始められます。Zeekに付属する zeek-cut を使えば、巨大なログから必要な列だけを抜き出し、見慣れたコマンドで料理できます。下は「長時間つなぎっぱなしの接続＝C2ビーコン候補」を炙り出す例です。

▲ zeek-cut は“列の抜き出し”専用ツール。あとは sort や awk など使い慣れたコマンドと組み合わせるだけ。正規表現でのログ解析の発想がそのまま活きます。

ここまでは「Zeekが吐くログを読む」話でした。でもZeekの真骨頂は、独自のスクリプト言語を持ち、通信中に起きる“出来事（イベント）”に反応してロジックを走らせられることにあります。Zeekは通信を解析しながら、dns_request（DNS問い合わせがあった）、http_request（HTTP要求があった）、ssl_established（TLSが確立した）、connection_state_remove（接続が終わった）といったイベントを次々に発火させます。そこに「こういう出来事を見たら、こうする」という処理を書けるのです。

百聞は一見にしかず。下は「1時間を超える長時間接続を見つけたら、notice（注目イベント）に上げる」という、小さなZeekスクリプトです。

▲ event connection_state_remove(c) は接続が終わるたびに発火。c$duration（継続時間）を見て、1hr を超えたら NOTICE(...) で notice.log に記録します。これだけで“振る舞いベースの検知”が1つ完成です。

この“気づき”を束ねる仕組みが、Zeekの2つのフレームワークです。脅威ハンティングの現場では、この2つを押さえておくと一気に世界が広がります。

「自分でスクリプトを書くなんて難しそう」と感じるかもしれません。でも安心してください。Zeekには最初から、有用なスクリプトが大量に同梱されています（標準で多くのプロトコル解析や検知ロジックが有効）。さらにコミュニティが公開するパッケージ（zkg）を入れれば、書かずとも高度な検知を足せます。まずは「既存のスクリプトを読む・使う」ところから始め、慣れてきたら上の例のような小さな1本を書いてみる——これが王道の学び方です。なお、より軽量なZeekシグネチャ（パターン照合）の仕組みもあり、用途で使い分けます。

Zeekを学ぶ一番やさしい入口は、手元のパケットデータ（pcap）をオフラインで解析することです。Wiresharkで開いていたあの .pcap を、そのままZeekに渡してみましょう。サーバー構築は要りません。

▲ -r＝pcap読み込み（オフライン）、-i＝インターフェイス指定（ライブ）。同じZeekが、過去のpcap調査にも、常時監視にも使えます。

本格運用では、Zeekを「センサー」として、ネットワークの“通り道”に置きます。重要なのは設置場所。スイッチのSPANポート（ミラーポート）やネットワークTAPから通信の複製を受け取り、インターネットの出入口（境界）など、トラフィックが集まる“くびれ”に置くのが定石です。ここを押さえれば、最小のセンサーで最大の視界が得られます（この“キャプチャ位置”の考え方はWireshark実践ガイドと共通です）。導入の選択肢は、大きく3つです。

とくに学習でおすすめなのが、無料のセキュリティ監視向けLinux「Security Onion」です。Zeek・Suricata・Elasticスタック・可視化ツールが最初から組み合わさっており、検証環境に入れるだけで、プロのSOCに近いハンティング環境が手に入ります。Zeekの商用版としては、Zeek開発者たちが設立したCorelightのセンサーもあり、大規模環境で広く使われています。まずはSecurity Onion（または素のZeek＋pcap）で“触って慣れる”のが、遠回りに見えて最短です。

Zeekは“記録の達人”ですが、記録は使われて初めて価値になります。ここで効いてくるのが、これまでの記事で扱ってきた仲間たちです。ZeekのログをSIEM（Splunk等）へ流し込み、Sigmaで検知ルールを当てる——じつはSigmaにはZeekログ専用のログソース定義があり、「Zeekの conn.log や dns.log に対する検知ルール」をそのまま書けます。NSMの一連の流れを整理しましょう。

この流れの根っこにあるのが、NSMの大原則「予防は破られる前提で、見える化しておく」という考え方です（NSMを体系化したRichard Bejtlich氏の思想として知られます）。完璧に侵入を防ぎ切ることはできない——だからこそ、侵入されても“気づける”ように、ネットワークの出来事を記録し続ける。Zeekは、その“見える化”を最も豊かに実現する道具なのです。Velociraptorのようなエンドポイント可視化と組み合わせれば、“通信”と“端末”の両面から、攻撃を立体的に追えます。

ここまでに登場した言葉の“答え合わせ”として、用語集とFAQをまとめました。Zeekは奥が深い分野ですが、入口はこの記事の範囲で十分です。あとは安全な環境で手を動かしながら、少しずつ守備範囲を広げていきましょう。最初に conn.log を自分の目で読めたとき、ネットワークが“見える”感覚がきっとつかめます。

📖 用語集

❓ よくある質問（FAQ）

🧭 次に読む