Posted inセキュリティ

LinuxへのArkimeのデプロイ：セキュリティインシデント調査のためのフルパケットキャプチャ

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

午前2時47分。SIEMがアラートを発報した——本番データベースサーバーから不審なアウトバウンドトラフィックが検出された。SSHで接続し、netstatを確認しても、怪しいものは何も見えない。接続はすでに切れていた。パケットレベルのデータがなければ、手探り状態で調査するしかない。

まさにこのシナリオが、私が重要なすべてのネットワークセグメントでArkimeを稼働させている理由だ。深夜にサーバーがSSHブルートフォース攻撃を受けてから、セキュリティはあらゆるセットアップチェックリストの最優先事項になった——「初期設定」とはもはやファイアウォールのログを確認するだけでなく、フルパケットキャプチャの構築を意味する。

ログは何が起きたかを教えてくれる。パケットは正確にどのように起きたかを教えてくれる。

アプローチ比較：フルパケットキャプチャの選択肢

tcpdump + ローテーションpcapファイル

手軽なキャプチャの定番ツール。シンプルで、あらゆる環境で使用でき、依存関係もない。

tcpdump -i eth0 -w /pcap/capture-%Y%m%d%H%M%S.pcap -G 3600 -z gzip

3日後にインシデントが発覚し、午前3時に200GBの圧縮pcapファイルを手動でgrepするまでは問題ない。インデックスもない。セッションビューもない。あるのは大量の圧縮ファイルだけだ。

Wireshark / tshark（ヘッドレス）

tsharkはヘッドレスで継続的なキャプチャが可能だが、Wiresharkは本質的にGUI分析ツールだ。インデックスもなく、REST APIもなく、チームがアクセスできるWebインターフェースもない。大規模な長期保存を前提とした設計ではない。

Zeek（旧称Bro）

Zeekは非常に低いオーバーヘッドで豊富なメタデータを抽出する——接続ログ、DNS、HTTP、TLS、ファイルハッシュなど。ログはSIEMに直接取り込めるため、セキュリティチームに重宝される。しかし、アナリストが「C2ビーコンの正確なバイト列を見せてくれ」と尋ねた途端、Zeekは沈黙する。ペイロードを破棄しているからだ。セッション再構築もpcapエクスポートもできない。

Arkime（旧称Moloch）

Arkimeはすべてをキャプチャする——生のパケットをインデックス化されたフォーマットで保存し、オンデマンドでpcapの断片をダウンロードできるWebUIで検索可能だ。フルpcap保存とOpenSearchまたはElasticsearchによるメタデータインデックスを組み合わせている。大規模企業のSOCや政府系ネットワーク防衛チームがこの理由でArkimeを採用している。

メリットとデメリット

tcpdump / 生pcap

  • メリット：セットアップ時間ゼロ、あらゆるLinuxマシンで動作、短時間の目的を絞ったキャプチャに最適
  • デメリット：大規模での検索機能なし、ファイル間の手動相関分析が必要、セッション再構築不可

Zeek

  • メリット：非常に軽量、豊富なプロトコル解析、SIEM取り込みに対応した構造化ログ
  • デメリット：ペイロード保存なし、フォレンジック用セッション再構築不可、詳細なパケット分析には補完ツールが必要

Arkime

  • メリット：インデックス化されたメタデータ付きフルパケット保存、強力なクエリ言語を持つWebUI、TCPセッション再構築、自動化用REST API、大規模な政府機関・企業SOC環境での実績
  • デメリット：高いリソース要件（OpenSearchバックエンド）、セットアップの複雑さ、大きなストレージコスト——1Gbpsでのフルpcapは1時間あたり約450GBのストレージを消費する

トレードオフは明確だ：パケットレベルで攻撃者の行動を正確に再構築する必要があるなら、このリストの中でArkimeだけが実際にそれを実現できる。

推奨セットアップ

ホームラボや小規模SOC環境の場合：

  • キャプチャサーバー：4コア、16GB RAM、2TB以上のストレージ（pcapにはHDDで十分）
  • OpenSearch 2.x——ラボでは同一ホスト、本番環境では別クラスター
  • Arkime 5.x——現在の安定版リリース
  • ネットワークタップまたはSPANポートでキャプチャインターフェースにトラフィックを送信

1Gbpsの本番リンクを監視する場合、計算が大幅に変わる：

  • キャプチャサーバー：8コア以上、32GB RAM、IPアドレスなしの専用キャプチャNIC
  • OpenSearchクラスター：3ノード × 8GBヒープ
  • ストレージ：保持ポリシーを設定した10TB以上（予算に応じて通常7〜30日間）

私自身のセットアップはシンプルな構成で——16GB RAMの古いi7ワークステーションでホームラボのVLANをキャプチャしている。ファイアウォールのログでは完全に見逃していたであろう、侵害されたIoTデバイスがアウトバウンドにビーコンを送信する事例を2件検出した。

実装ガイド

ステップ1：OpenSearchのインストール

ArkimeはメタデータストアとしてOpenSearch（またはElasticsearch 7.x）が必要だ。Ubuntu/Debianの場合：

wget -qO - https://artifacts.opensearch.org/publickeys/opensearch.pgp | \
  sudo gpg --dearmor -o /usr/share/keyrings/opensearch-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/opensearch-keyring.gpg] \
  https://artifacts.opensearch.org/releases/bundle/opensearch/2.x/apt stable main" | \
  sudo tee /etc/apt/sources.list.d/opensearch-2.x.list

sudo apt update && sudo apt install opensearch -y

JVMヒープを設定する——利用可能なRAMの半分に設定し、31GBを超えないようにする：

sudo nano /etc/opensearch/jvm.options
# 両方の行を設定する:
-Xms8g
-Xmx8g
sudo systemctl enable --now opensearch
# 起動確認:
curl -s http://localhost:9200/_cluster/health | python3 -m json.tool

ステップ2：Arkimeのインストール

# 最新バージョンは https://arkime.com/downloads を確認すること
wget https://github.com/arkime/arkime/releases/download/v5.3.0/arkime_5.3.0-1_amd64.deb
sudo dpkg -i arkime_5.3.0-1_amd64.deb

ステップ3：コンフィギュレーターの実行

sudo /opt/arkime/bin/Configure

インタラクティブなコンフィギュレーターは、キャプチャするインターフェース、OpenSearchのURL、管理者パスワードを尋ねる。/opt/arkime/etc/config.iniが生成される。後から手動で調整すべき主要な設定：

[default]
elasticsearch=http://localhost:9200
interface=eth1
pcapDir=/data/arkime/pcap
maxFileSizeG=12
maxFileTimeM=60
freeSpaceG=5%
# 回線速度に応じて調整:
pcapWriteMethod=simple
pcapWriteSize=2560

interfaceをキャプチャインターフェース——管理用NICではなく、SPANポートまたはネットワークタップに接続されたものに設定する。

ステップ4：データベースの初期化とサービスの起動

sudo /opt/arkime/db/db.pl http://localhost:9200 init

# 管理者ユーザーを作成
sudo /opt/arkime/bin/arkime_add_user.sh admin "管理者ユーザー" YOUR_STRONG_PASSWORD --admin

# キャプチャとビューワーを起動
sudo systemctl enable --now arkimecapture
sudo systemctl enable --now arkimeviewer

ブラウザでhttp://your-server:8005にアクセスする。1分以内に、Sessionsタブにセッションが表示され始める。

ステップ5：インデックス保持期間の設定

保持ポリシーを設定しなければ、OpenSearchは数日でディスクを食い尽くす。このISMポリシーは30日以上経過したインデックスを自動削除する：

curl -X PUT "http://localhost:9200/_plugins/_ism/policies/arkime-retention" \
  -H 'Content-Type: application/json' -d '{
  "policy": {
    "description": "30日より古いArkimeインデックスを削除",
    "default_state": "hot",
    "states": [{
      "name": "hot",
      "actions": [],
      "transitions": [{
        "state_name": "delete",
        "conditions": { "min_index_age": "30d" }
      }]
    }, {
      "name": "delete",
      "actions": [{ "delete": {} }],
      "transitions": []
    }]
  }
}'

インシデント発生時のトラフィック検索

Arkimeのクエリ言語こそが、このセットアップ全体の価値を高める。Sessionsビューでの例：

# 不審なIPへのすべてのトラフィックを検索
ip.dst == 185.220.101.45

# 悪意のあるドメインパターンに一致するDNSクエリ
dns.host == /.*evil-c2\.com/

# 大量のアウトバウンド転送 — データ外部流出の可能性
ip.dst != 10.0.0.0/8 && databytes > 10000000

# 組み合わせ: 不審なIP + 特定ポート + 時間範囲
ip.dst == 185.220.101.45 && port.dst == 4444 && starttime >= 2024-01-15T02:00

任意のセッションを右クリック→Download PCAPで生パケットをWiresharkに取り込める。内蔵パケットビューワーでブラウザ上でTCPストリームを再構築することも可能だ——ローカルツールは不要。インシデントレスポンスチームと画面を共有し、誰も何もインストールせずにセッションを一緒に確認できる。

UIのセキュリティ保護

ArkimeのWebインターフェースを公衆インターネットに晒してはならない。これは絶対条件だ：

# 管理VLANからのみArkime UIへのアクセスを許可
sudo ufw allow from 10.0.1.0/24 to any port 8005
sudo ufw deny 8005

# キャプチャインターフェースにはIPアドレスを割り当てない
# 攻撃対象のないプロミスキャスモード:
ip link set eth1 promisc on
ip link set eth1 up
# eth1にIPアドレスを割り当てないこと

チームアクセスには、ArkimeをWireGuard VPNまたは相互TLSを設定したnginxリバースプロキシの背後に置くこと。ポート8005を絶対にインターネットにポートフォワードしてはならない。

フルパケットキャプチャは安くない——ハードウェア、ストレージ、セットアップ時間のコストが積み重なる。しかし、午前2時に侵害を前にしているとき、素早く答えが必要だ。Arkimeがすでに稼働していれば、ネットワークから何が流出したかを正確に追跡するのに、数日ではなく数時間で済む。このトレードオフは毎回コストを正当化してきた。

Share:
Tags: