Zeek（ゼーク）入門｜ネットワーク通信ログを自動解析して侵入の痕跡を可視化する実践ガイド

ネットワーク上で何か不審なことが起きている気がするのに、「どこを見ればいいかわからない」——情シスの方からよく耳にする悩みです。ファイアウォールのログやSIEMのアラートを眺めていても、「誰がいつどこへ接続したか」を詳細に追いかけるには限界があります。

そこで力を発揮するのが、Zeek（ゼーク）というオープンソースのネットワークセキュリティ監視フレームワークです。米国DHS（国土安全保障省）や防衛関連機関でも活用されており、国内でも大手企業やSOC（セキュリティオペレーションセンター）での採用実績が増えています。

この記事では、Zeekの仕組み・インストール手順・実際のログの読み方まで、現場で使えるレベルで解説します。ネットワーク型IDSとの違い、C2通信やDNSトンネリングの検出方法、情シス1人体制でも運用できるポイントまで網羅します。

Zeekとは？他のネットワーク監視ツールとの違い

Zeekは2013年まで「Bro」という名称で知られていたオープンソースのネットワーク解析フレームワークです。単純なパターンマッチングによるシグネチャ型IDSとは根本的にアプローチが異なります。

Zeekの主な特徴
・プロトコルの自動解析: HTTP、DNS、SSL/TLS、FTP、SMBなど40以上のプロトコルを自動的にパースし、構造化ログとして記録する
・通信の「文脈」を保存: 通信の内容そのものではなく「誰がいつどのホストへ接続し、何バイト転送したか」というメタデータを蓄積する
・スクリプトによる拡張性: Zeek独自のスクリプト言語でカスタム検知ルールを記述できる
・シグネチャ非依存: 既知のマルウェアシグネチャがなくても、異常な振る舞い（多数の外部IPへのDNSクエリ等）を検出できる

Suricata・Snortとの違い

SuricataやSnortはシグネチャマッチング型のIDSで、既知の攻撃パターンに対してリアルタイムアラートを出すことに優れています。一方Zeekは、ネットワーク通信のメタデータを構造化ログとして記録することに特化しています。両者は競合ではなく補完関係にあり、実際の現場ではSuricataでリアルタイムアラートを出しつつ、Zeekでコンテキストログを蓄積する組み合わせが定番です。

NetFlow/IPFIXでのトラフィック可視化と組み合わせると、「量の異常（NetFlow）」と「通信内容の文脈（Zeek）」の両面からネットワークを監視できます。

攻撃者が残す痕跡とZeekが検知できる脅威

現代の攻撃者は、ファイアウォールを通過した後に内部ネットワークをゆっくりと偵察し、横移動（ラテラルムーブメント）を繰り返します。このプロセスでは、「正常に見えるが文脈がおかしい通信」が大量に発生します。ログを記録し続けるZeekは、この足跡を事後に追いかける際に特に力を発揮します。

Zeekが効果的な攻撃パターン
・DNSトンネリング: 攻撃者がDNSクエリにデータを埋め込んでC2（コマンドアンドコントロール）通信を行う手口。Zeekのdns.logを分析すると、クエリの異常な長さや高頻度のNXDOMAINが浮かび上がる（DNSトンネリングの詳細解説はこちら）
・不審なSSL/TLS接続: 自己署名証明書を使ったC2通信や、JA3フィンガープリントによるマルウェア通信の識別
・内部スキャン・横移動: 短時間に多数のホストへSSHやRDPを試行する動きをconn.logで検出
・DGA（ドメイン生成アルゴリズム）: マルウェアがランダムに生成するドメインへの大量クエリを、NXDOMAINの集計で発見
・大容量のアウトバウンド転送: データ窃取（データエクスフィルトレーション）の兆候となる大量の外向き通信をconn.logで可視化

Zeekのインストールと基本設定

1. 動作環境と前提条件

Zeekはインラインではなくミラーポート（SPANポート）からトラフィックをキャプチャするパッシブ監視が基本です。スイッチのSPANポートか、ネットワークタップ経由でZeekサーバーにトラフィックを流す構成を取ります。通信の遮断・変更はしないため、既存ネットワークへの影響なしに導入できます。

・OS: RHEL/Rocky Linux 8/9、Ubuntu 20.04/22.04 LTS
・CPU: 1Gbps環境で最低4コア（監視帯域に応じてスケールアップ）
・メモリ: 8GB以上推奨
・NIC: 管理用とキャプチャ用の2枚構成が理想。キャプチャ用NICはプロミスキャスモードに設定

2. Rocky Linux 9へのインストール

# OpenSUSE Build ServiceのZeekリポジトリを追加
sudo rpm --import \
  https://download.opensuse.org/repositories/security:/zeek/RHEL_9/repodata/repomd.xml.key

sudo curl -o /etc/yum.repos.d/security:zeek.repo \
  https://download.opensuse.org/repositories/security:/zeek/RHEL_9/security:zeek.repo

# Zeekのインストール（LTS版）
sudo dnf install -y zeek

# バージョン確認
zeek --version

# 監視に使うNICのインタフェース名を確認
ip link show

3. 監視インタフェースと内部ネットワークの設定

# /etc/zeek/node.cfg — 監視インタフェースを指定する
[zeek]
type=standalone
host=localhost
# SPANポートに接続したNICを指定（デフォルトのeth0から変更する）
interface=eth1

# /etc/zeek/networks.cfg — 内部ネットワークのCIDRを定義する
# （内部/外部の区別が正確になり、ログの可読性が上がる）
192.168.0.0/16      Private IP space
10.0.0.0/8          Private IP space
172.16.0.0/12       Private IP space

4. Zeekの起動と動作確認

# zeekctlで設定を適用して起動する
sudo zeekctl deploy

# 動作状態を確認する（running と表示されればOK）
sudo zeekctl status

# ログが生成されているか確認する
ls -lh /opt/zeek/logs/current/

# リアルタイムでconn.logを確認する
tail -f /opt/zeek/logs/current/conn.log | zeek-cut ts id.orig_h id.resp_h id.resp_p proto

Zeekのログ構造と侵入痕跡の読み方

Zeekはデフォルトで `/opt/zeek/logs/current/` 配下にログを生成します。1時間ごとにローテーションされ、gz形式で圧縮アーカイブとして保存されます。

主要ログファイル一覧
・conn.log: すべての通信セッション（送受信元IP/ポート、プロトコル、バイト数、接続時間）
・dns.log: DNSクエリとレスポンス（クエリ名、応答コード、TTL、解決済みIPアドレス）
・http.log: HTTPリクエスト（メソッド、URI、User-Agent、レスポンスコード）
・ssl.log: SSL/TLSハンドシェイク（証明書情報、JA3ハッシュ、SNI）
・files.log: HTTP/SMBなど経由で転送されたファイルのハッシュ値とMIMEタイプ
・weird.log: 異常なプロトコル挙動（解析できない通信、仕様外のパケット）

1. 怪しいDNSクエリを探す（DGA・DNSトンネリング検出）

# zeek-cutコマンドでフィールドを絞り込む

# クエリ名が50文字を超えるもの（DGAやDNSトンネリングの疑い）を抽出
cat /opt/zeek/logs/current/dns.log | \
  zeek-cut ts id.orig_h query | \
  awk 'length($3) > 50 {print}' | sort | head -20

# NXDOMAINが多い内部ホストを集計（DGAマルウェアの特徴）
cat /opt/zeek/logs/current/dns.log | \
  zeek-cut id.orig_h rcode_name | \
  grep NXDOMAIN | sort | uniq -c | sort -rn | head -10

2. 不審な外部接続と長時間セッションを探す

# 接続先の外部IPを集計（上位の接続先を把握する）
cat /opt/zeek/logs/current/conn.log | \
  zeek-cut id.orig_h id.resp_h id.resp_p proto | \
  grep -v "^192\.\|^10\.\|^172\." | sort | uniq -c | sort -rn | head -20

# 長時間セッションを検出（C2の特徴：低頻度・長時間のBeaconingを疑う）
# 3600秒（1時間）以上の接続を抽出する
cat /opt/zeek/logs/current/conn.log | \
  zeek-cut id.orig_h id.resp_h duration | \
  awk '$3 > 3600 {print}' | sort -t$'\t' -k3 -rn | head -10

3. 自己署名SSL証明書を使った通信を検出する

# ssl.logから自己署名証明書の通信を抽出する
# マルウェアのC2はしばしば自己署名証明書を使う
cat /opt/zeek/logs/current/ssl.log | \
  zeek-cut id.orig_h id.resp_h server_name validation_status | \
  grep "self signed" | sort | uniq -c | sort -rn

# JA3ハッシュでマルウェア通信のフィンガープリントを確認する
# JA3ハッシュはSSLクライアントの特性を表す（マルウェアごとに固有）
cat /opt/zeek/logs/current/ssl.log | zeek-cut id.orig_h ja3 ja3s | head -20

中小企業でも今日からできること

「いきなりZeekを本番に投入するのは難しい」という場合も、段階的なアプローチで無理なく始められます。

・ステップ1 ― SPANポートの設定から着手: コアスイッチのSPANポートを1つ有効にし、Zeekをミラーポート受信専用として接続する。通信の遮断・変更は一切せず、記録するだけなのでリスクゼロで始められる
・ステップ2 ― まずconn.logとdns.logを週1回確認: 全ログを網羅的に見る必要はない。「外部IPへの長時間接続」と「NXDOMAINが多い内部ホスト」の2点を確認するだけで、侵害の兆候の多くをカバーできる
・ステップ3 ― SIEMやWazuhへのログ転送: ZeekはJSON形式でログを出力できる。SIEMやWazuhに転送することで、NDR（ネットワーク検知・対応）に近い運用が情シス1人でも実現できる
・ステップ4 ― Zeekスクリプトでカスタム検知を追加: 自社ネットワーク固有の通信パターンをホワイトリスト化し、逸脱した際にアラートを出すカスタムスクリプトを追加していく

エンドポイント側の監視ツールであるFalco（eBPFによるLinuxランタイム脅威検知）と組み合わせると、ホスト内の不審なプロセスとネットワーク通信の両方を突き合わせたインシデント調査が可能になります。

よくある誤解と注意点

・「ZeekはアラートをリアルタイムでくれるIDS」は誤り: Zeekはログを記録するフレームワークです。リアルタイムのアラートを出すには、Zeekスクリプトを書くか、ログを外部SIEMに転送して相関分析ルールを設定する必要があります
・暗号化通信の限界: TLSで暗号化されたペイロードの中身はZeekでも解読できません。ただしssl.logのJA3ハッシュとSNI（サーバー名表示）で、マルウェアの通信特性を識別することは可能です
・ストレージ設計を事前に行う: 1Gbps環境で1日あたり数十GBのログが生成されることもあります。保存期間（30日以上を推奨）と保存先（NAS・クラウドストレージ）を導入前に設計しておいてください
・プライバシーへの配慮: Zeekログには社内ユーザーの通信先が記録されます。ログの取り扱いポリシー（アクセス権限・保管期間・利用目的）を社内規程として明文化しておくことが重要です
・キャパシティプランニング: 10Gbps以上の高速ネットワークでは、複数のZeekワーカーを起動する「クラスタ構成」が必要になります。まずは小規模なセグメントで試験導入し、負荷を測定してから本番展開に進むのが安全です

本記事のまとめ

Zeekは「攻撃者が通過した後の足跡」を記録し続けるツールです。侵害は発生した直後に気づけないことが多く、事後のフォレンジック調査でZeekのログが命綱になるケースが現場では珍しくありません。まずはSPANポートを1本有効にして、ログを蓄積するところから始めてみてください。