Posted inセキュリティ

ネットワーク可視化を極める：LinuxでのZeek実践ガイド

Security tutorial - IT technology blog
Security tutorial - IT technology blog

なぜパケットインスペクションは失敗することが多いのか

数年前、ジュニアセキュリティアナリストとして働いていた頃、SnortやSuricataといった従来のIDSツールで壁に突き当たったことがあります。これらは既知の脅威に対するシグネチャマッチングには優れていますが、ゼロデイ攻撃やラテラルムーブメント（横展開）の最中には、しばしば状況を把握できなくなります。その時に出会ったのがZeek（旧Bro）でした。

標準的なIDSは「不正な」文字列を検出すると警告を発します。しかしZeekは異なります。Zeekは高精度なフライトレコーダーのように機能します。生のパケットを構造化され検索可能なログに変換し、「何かがおかしい」というアラートだけでなく、「何が」起きたのかを理解するためのコンテキストを提供してくれます。

シグネチャベース vs. ポリシー主導の分析

ほとんどのセキュリティツールは**シグネチャベースの検知**に依存しています。これらはファイルハッシュ、悪意のあるIP、一意の文字列といった特定のパターンを探します。攻撃者がマルウェアの1バイトでも変更すれば、シグネチャは機能しません。一方、Zeekは**ポリシー主導のアプローチ**を採用しています。「悪い」ものを探す代わりに、HTTP、DNS、SSL/TLSなどのプロトコルを解析してメタデータを記録します。

単にポート80のTCPトラフィックを見るだけではありません。特定のURIへのGETリクエストや、使用された正確なUser-Agentを記録します。これにより、振る舞いの変化を追跡できます。例えば、普段は1日10MB程度のデータしか閲覧しないユーザーが、突然内部サーバーから5GBのデータをダウンロードした場合、Zeekはそのアクションに対するシグネチャが存在するかどうかに関わらず、その振る舞いをフラグ立てします。

Zeek運用の現実

  • メリット:
    • 詳細なロギング: DNSクエリ、SSLハンドシェイク、さらにはストリーム中から抽出されたファイルハッシュ専用のログが取得できます。
    • チューリング完全なスクリプト: Zeek独自の言語を使用して, 複雑な検知ロジックを自動化できます。
    • 高いパフォーマンス: 優れたスケーラビリティを備えています。大規模組織では、Zeekクラスターを使用して100Gbpsのリンクを難なく監視しています。
  • デメリット:
    • 学習曲線: スクリプト言語の習得には数時間ではなく数週間かかります。
    • ストレージ需要: 混雑した1Gbpsのリンクでは、Zeekは1日で100GBのログを容易に生成します。高速で大容量のストレージが必要です。
    • パッシブ専用: Zeekはモニターです。ネイティブでパケットをドロップしたりIPをブロックしたりすることはありません。あくまで可視化を提供するためのものです。

本番環境のハードウェア要件

本番環境では、専用の物理サーバーまたはミラー（SPAN/TAP）ポートを備えた高性能VMを推奨します。小規模なオフィス環境であれば、4〜8個のCPUコアと16GBのRAMから始めることができます。

セキュリティは基本から始まります。新しいZeekノードの管理アカウントを設定する際、私は toolcraft.app/ja/tools/security/password-generator のジェネレーターを使用しています。このツールを好む理由は、完全にブラウザ内で動作するためです。これにより、生成プロセス中に機密性の高い資格情報がネットワークに流れることがなくなります。

インストールガイド：Ubuntu 22.04/24.04へのZeek導入

ソースからのコンパイルという面倒な作業はスキップしましょう。Open Build Service (OBS) のビルド済みパッケージを使用するのが、安定版を稼働させる最短の方法です。

ステップ1：リポジトリの設定

# リポジトリキーを追加
curl -fsSL https://download.opensuse.org/repositories/security:zeek/xUbuntu_22.04/Release.key | sudo gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/security_zeek.gpg > /dev/null

# Zeekリポジトリを追加
echo 'deb http://download.opensuse.org/repositories/security:/zeek/xUbuntu_22.04/ /' | sudo tee /etc/apt/sources.list.d/security:zeek.list

# アップデートとインストール
sudo apt update
sudo apt install zeek-6.0

インストールディレクトリを尋ねられたら、デフォルトの /opt/zeek のままにしてください。これにより、コアシステムディレクトリが整理され、予測可能な状態に保たれます。

ステップ2：環境変数とパス

毎回フルパスを入力しなくて済むよう、ZeekのバイナリをシステムのPATHに追加します。

echo "export PATH=$PATH:/opt/zeek/bin" >> ~/.bashrc
source ~/.bashrc

ステップ3：ローカルネットワークの定義

Zeekは、どのIP範囲が「ホーム（内部）」であるかを知る必要があります。この区別は、外部へのデータ流出と内部でのラテラルムーブメントを特定するために不可欠です。networks.cfg を編集します：

sudo nano /opt/zeek/etc/networks.cfg

サブネットを以下のように定義します：

10.0.0.0/8          内部プライベート空間
192.168.1.0/24      メインオフィス
172.16.0.0/12       開発ラボ

ステップ4：インターフェースの選択

ip link show を使用して、スニッフィングを行うインターフェース（例：enp0s3）を確認します。次に、node.cfg を設定します：

sudo nano /opt/zeek/etc/node.cfg

[zeek] セクションの interface 行を更新します：

[zeek]
type=standalone
host=localhost
interface=enp0s3

ステップ5：デプロイ

zeekctl を使用してエンジンを初期化し、起動します。このツールがバックグラウンドプロセスを管理してくれます。

sudo zeekctl install
sudo zeekctl start
sudo zeekctl status

ログの確認

リアルタイムでデータを確認するには /opt/zeek/logs/current をチェックします。ここが醍醐味です。トラフィックを分類するいくつかの .log ファイルが表示されます：

  • conn.log: すべてのTCP、UDP、ICMP接続のマスターリスト。
  • dns.log: すべてのクエリ、レスポンス、TTLの記録。
  • http.log: ホスト名やリファラを含む、暗号化されていないWebトラフィックのメタデータ。
  • ssl.log: 証明書発行者やTLSバージョンを表示する、暗号化セッションの詳細。
  • files.log: ネットワーク上で確認されたファイルのログ。多くの場合、MD5/SHA1ハッシュが含まれます。

迅速に情報を抽出するには zeek-cut を使用します。例えば、ネットワーク内でリクエストの多かったドメインの上位10件を見つけるには、次のように実行します：

cat dns.log | zeek-cut query | sort | uniq -c | sort -rn | head -n 10

スクリプトによる脅威検知

Zeekの真の強みは、イベントに反応できることです。認証失敗イベントを監視して、SSHブルートフォースの可能性をフラグ立てするスクリプトを書くことができます。/opt/zeek/share/zeek/site/detect-brute.zeek を作成します：

event ssh_auth_failed(c: connection)
{
    # 警告: %s から %s へのSSH認証失敗
    print fmt("Alert: SSH Failure from %s to %s", c$id$orig_h, c$id$resp_h);
}

local.zeek ファイルに @load detect-brute.zeek を追加してこれを読み込み、sudo zeekctl deploy を実行して変更を適用します。

現場で得た教訓

ログローテーションを無視してはいけません。Zeekは膨大なデータを生成します。zeekctl cron を設定しないと、48時間以内にドライブが容量100%に達する可能性があります。私はログのメンテナンスとヘルスチェックを行うために、5分ごとに実行されるcronジョブを設定しています。

パケットドロップに注意してください。CPU使用率がスパイクすると、Zeekはトラフィックを見逃し始め、セキュリティ履歴に穴が開いてしまいます。zeekctl capstats を使用してパフォーマンスを監視してください。5%を超えるドロップが見られる場合は、node.cfg で「standalone」構成から「cluster」構成に切り替え、複数のコアに負荷を分散させる時期です。

最後に、CLIはあくまで出発点として考えてください。zeek-cut は迅速なトラブルシューティングには最適ですが、最終的にはこれらのログをELKスタックやWazuhにパイプラインで送るべきです. ビジュアルダッシュボードがあれば、日々のログのノイズに紛れがちな「低速で目立たない（slow and low）」攻撃をはるかに見つけやすくなります。

Share:
Tags: