Wazuh 4.14.7 と Suricata 8.0.2 で商用 XDR 相当の Linux SIEM をコードで管理する実践ガイド。JA4 検知、MITRE ATT&CK タグ付きルール、アクティブレスポンスによる自動遮断、Kubernetes DaemonSet 配布、EPS 見積りまで、私の本番運用経験を踏まえて解説します。
最終更新：2026年8月30日
Wazuh 4.14 と Suricata 8 を組み合わせれば、コミット可能な YAML と数百行の XML ルールだけで、商用 XDR 相当の Linux SIEM を自前運用できる。Wazuh 4.14.7（2026年7月29日リリース）が eBPF ベースの whodata FIM と MITRE ATT&CK タグ付きルールを提供し、Suricata 8.0.2（2025年11月）が JA4/JA4+ フィンガープリントと HTTP/2 ネイティブ解析を担う。私は複数の本番環境でこの構成を CI/CD パイプライン化し、ゼロタッチで検知ルールと閾値を配布してきた。本ガイドでは、単なるインストール手順にはとどまらず、パイプラインに組み込むための構成ファイル、Kubernetes デプロイ、EPS チューニング、そして誤検知を落とし込む実運用ノウハウまでを一気通貫で解説していく。ちなみに、この記事の内容はすべて私が本番運用で踏んだ罠を反映している。
eve.json を組み込み JSON デコーダで直接解析するため、カスタムデコーダは不要で、local_rules.xml に MITRE タグ付きルールを追加するだけで良い。firewall-drop と組み合わせれば、Suricata 検知イベントから nftables による自動遮断まで数秒でクローズループが完結する。bootstrap.memory_lock: true を必須とし、EPS 5,000 を超えるならインデクサをクラスタ化する。alert / flow / dns / tls 以外を絞り込むだけで、analysisd キュー枯渇と誤検知ノイズを 70% 以上削減できる。2026年時点、オープンソースで HIDS・NIDS・SIEM・XDR を単一スタックに統合できる現実解は、実質 Wazuh + Suricata の組み合わせだけだ。CrowdStrike や SentinelOne のような商用 XDR に比べて機能は劣るものの、規模の小さいプラットフォームチームでも自前運用でき、コミット可能な YAML と XML でルールをバージョン管理できるという DevSecOps 上の利点は代え難い。私は3年ほど、月間 EPS 15,000 規模のインフラでこの構成を運用してきたが（正直に言えば途中で Zeek への乗り換えを検討した時期もあった）、結局のところライセンス費ゼロで MITRE ATT&CK 準拠のカバレッジを維持できている。
Wazuh 側の強みは、エージェント一つで ログ収集・ファイル完全性監視 (FIM)・脆弱性スキャン・SCA (Security Configuration Assessment)・アクティブレスポンスを担える点にある。一方の Suricata は Zeek と並ぶ二大 OSS NIDS だが、Zeek がスクリプト志向でルール共有エコシステムが分散しているのに対し、Suricata は Emerging Threats や PT Rules と互換性があり、そのまま Wazuh の 0475-suricata_rules.xml でパースできる。過去に SELinux と AppArmor を比較したように（SELinux vs AppArmor 徹底比較参照）、選定基準は「ルール資産の再利用性」と「運用の自動化難易度」に尽きる。この2つの観点で Wazuh + Suricata に勝る OSS スタックは、今のところ存在しない。
Wazuh は4つのコアコンポーネント Manager / Agent / Indexer / Dashboard から成る。Manager はエージェントからのイベントを受信・デコード・ルール適用し、Indexer（OpenSearch フォーク）に書き込む。Dashboard（OpenSearch Dashboards フォーク）が可視化を担う。4.14.x では Filebeat が Manager と Indexer の間の橋渡し役だが、5.0 では Filebeat が廃止され Manager からネイティブに Indexer へ書き込む設計に変わる。移行を見据えて 4.14.7 で先にコンフィグを整理しておくのが望ましい。
Wazuh 4.14.7（2026年7月29日）の主な新機能は次のとおりだ：
一方 Suricata 8.0.2（2025年11月6日）で加わった JA4/JA4+ は、TLS ClientHello に加えて QUIC の握手も指紋化できる。C2 の暗号化通信検知精度が上がるため、必ず有効化しておきたい。7.x を使い続ける場合でも 7.0.12 以降を選び、http2.header ではなく http.header を使うようルールを更新しておく。
| 要素 | Wazuh 4.14.7 | Wazuh 5.0（ベータ） | Suricata 8.0.2 |
|---|---|---|---|
| リリース日 | 2026年7月29日 | 2026年後半 GA 予定 | 2025年11月6日 |
| ログ転送 | Filebeat 経由 | Manager → Indexer 直結 | eve.json（ローカル） |
| クラスタ | オプション | デフォルトで有効 | マルチスレッド (worker/autofp) |
| FIM 実装 | eBPF whodata (Linux) | 同左＋機能拡張 | 該当なし |
| 暗号化通信検知 | ルールで対応 | ルールで対応 | JA4 / JA4+ 標準搭載 |
| MITRE ATT&CK | 拡張ルールセット同梱 | 同左 | ルール側でタグ付け |
本番導入では Manager / Indexer / Dashboard を別ホストに分離するのが原則だが、PoC や小規模検証なら all-in-one で問題ない。最低 4 vCPU / 8GB RAM を推奨する。以下はワンショットスクリプトの例だ。実運用ではこの手順を Ansible の Wazuh 公式ロールに置き換え、Terraform で IaC 化しておく。
# /opt/ansible/roles/wazuh-manager/tasks/install.yml から抜粋
# Wazuh 4.14.x を Ubuntu 24.04 LTS にインストール
- name: GPG キーを取り込む
ansible.builtin.get_url:
url: https://packages.wazuh.com/key/GPG-KEY-WAZUH
dest: /usr/share/keyrings/wazuh.gpg
mode: '0644'
- name: リポジトリ追加
ansible.builtin.apt_repository:
repo: "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main"
filename: wazuh
state: present
- name: Manager / Indexer / Dashboard をピン留めインストール
ansible.builtin.apt:
name:
- wazuh-manager=4.14.7-1
- wazuh-indexer=4.14.7-1
- wazuh-dashboard=4.14.7-1
update_cache: true
state: present
allow_downgrade: trueOISF の PPA から最新の Suricata 8.x を導入する。Ubuntu 24.04 では標準リポジトリの Suricata が古いバージョンに固定されているため、必ず PPA を追加する。JA4 は既定では無効化されているので、suricata.yaml の outputs.tls.ja4 と outputs.quic.ja4 を yes に設定する。
#!/usr/bin/env bash
# Suricata 8.0.2 セットアップ（Ubuntu 24.04）
set -euxo pipefail
add-apt-repository -y ppa:oisf/suricata-stable
apt-get update
apt-get install -y suricata=1:8.0.2-* jq
# ルールセット取得（Emerging Threats Open）
suricata-update update-sources
suricata-update enable-source et/open
suricata-update
# JA4 と community-id を有効化
cat >/etc/suricata/conf.d/z-ja4.yaml <<'YAML'
outputs:
- eve-log:
enabled: yes
filetype: regular
filename: /var/log/suricata/eve.json
community-id: yes
types:
- alert:
metadata: yes
tagged-packets: no
- flow
- dns:
query: yes
answer: yes
- tls:
extended: yes
ja4: yes
ja3: no # JA3 は JA4 に統合するため無効化
- quic:
ja4: yes
YAML
systemctl restart suricata
suricata --build-info | grep -E 'JA4|HTTP/2'この構成で eve.json に ja4.hash フィールドが出力される。攻撃者が使う Cobalt Strike / Sliver / Havoc の JA4 ハッシュは公開 IoC が数十件程度あるため、後述の Wazuh ルールでマッチングさせる。Emerging Threats のルール数を抑えたい場合は、disable.conf で SID 単位に re: パターンで除外できる。ここでの選定精度が SIEM 全体の信号対雑音比を決める。
Suricata と同居する Wazuh Agent の /var/ossec/etc/ossec.conf に localfile ブロックを追加するだけで良い。Syslog 経由で送るとヘッダが JSON を包み込み、Wazuh の JSON デコーダが失敗するため、必ずローカルファイル読み取りを使う。
<!-- /var/ossec/etc/ossec.conf -->
<ossec_config>
<localfile>
<log_format>json</log_format>
<location>/var/log/suricata/eve.json</location>
<!-- テスト用に fim ラベルを付ける -->
<label key="source">suricata</label>
</localfile>
</ossec_config>組み込みルールは /var/ossec/ruleset/rules/0475-suricata_rules.xml にあり、alert.severity と alert.category で分岐する構造になっている。パースが効いているかは /var/ossec/bin/wazuh-logtest にサンプル JSON を貼り付けて確認する。
組み込みルールで拾いきれない検知は /var/ossec/etc/rules/local_rules.xml に追加する。ここでは Cobalt Strike っぽい JA4 と、Suricata の Trojan カテゴリを ATT&CK T1071 (Application Layer Protocol) と関連付ける例を示す。if_sid でベースルール 86601（Suricata JSON デコード成功）を継承するのがポイントだ。
<!-- /var/ossec/etc/rules/local_rules.xml -->
<group name="suricata,ids,mitre,">
<!-- 1. Trojan カテゴリで severity 1 → 高優先度 -->
<rule id="100200" level="12">
<if_sid>86601</if_sid>
<field name="alert.severity">^1$</field>
<field name="alert.category">Trojan</field>
<description>Suricata: 高深刻度 Trojan 通信 $(src_ip) -> $(dest_ip)</description>
<mitre>
<id>T1071</id>
</mitre>
<group>attack,pci_dss_11.4,gdpr_IV_35.7.d,</group>
</rule>
<!-- 2. 既知の C2 JA4 ハッシュにマッチ -->
<rule id="100201" level="14">
<if_sid>86601</if_sid>
<field name="tls.ja4">^t13d1516h2_8daaf6152771_b0da82dd1658$</field>
<description>Cobalt Strike ライクな JA4 指紋を検出 ($(src_ip))</description>
<mitre>
<id>T1071.001</id>
<id>T1573</id>
</mitre>
</rule>
<!-- 3. 1分間に5回以上のスキャン挙動を相関 -->
<rule id="100202" level="10" frequency="5" timeframe="60">
<if_matched_sid>100200</if_matched_sid>
<same_source_ip />
<description>同一 IP から Trojan 系イベント連続検出</description>
<mitre>
<id>T1595</id>
</mitre>
</rule>
</group>これらのルールは Git 管理し、Wazuh Manager のプロビジョニング時に Ansible / GitHub Actions で /var/ossec/etc/rules/ にデプロイして systemctl restart wazuh-manager を呼ぶ。私は Wazuh のルール構文を Pull Request でレビューするために、wazuh-logtest をラップした CI スクリプトを用意している：
# .github/workflows/wazuh-rules-lint.yml
name: wazuh-rules
on: [pull_request]
jobs:
logtest:
runs-on: ubuntu-24.04
container: wazuh/wazuh-manager:4.14.7
steps:
- uses: actions/checkout@v4
- name: ルールを配置
run: cp -r rules/*.xml /var/ossec/etc/rules/ && /var/ossec/bin/wazuh-control start
- name: サンプルログでルール発火を検証
run: |
for f in tests/fixtures/*.json; do
expect=$(basename "$f" .json)
got=$(cat "$f" | /var/ossec/bin/wazuh-logtest | grep 'Rule id:' | awk '{print $3}' | tr -d "'")
[ "$got" = "$expect" ] || { echo "FAIL: $f expected=$expect got=$got"; exit 1; }
done検知だけで終わらせないのが XDR の要件だ。Wazuh のアクティブレスポンスは、<command> と <active-response> を組み合わせて、特定ルール発火時にエージェント側でスクリプトを起動させる仕組みだ。付属の firewall-drop は Linux では iptables / nftables を叩いてソース IP をブロックしてくれる。設定は次のとおり：
<!-- Manager 側 ossec.conf -->
<command>
<name>firewall-drop</name>
<executable>firewall-drop</executable>
<timeout_allowed>yes</timeout_allowed>
</command>
<active-response>
<disabled>no</disabled>
<command>firewall-drop</command>
<location>local</location> <!-- 発火エージェントで実行 -->
<rules_id>100201,100202</rules_id>
<timeout>600</timeout>
</active-response>より高度な運用では、Wazuh の Webhook を Slack / PagerDuty へ流し、SOAR（Shuffle 等）でチケット起票と自動対応を分岐させる。nftables ルールセット自体の設計については、nftables Linux ファイアウォール実践ガイドで扱った内容と組み合わせるとよい。
コンテナ化されたワークロードでは、Wazuh Agent を DaemonSet としてすべてのノードに配布し、Suricata は hostNetwork: true のサイドカー Pod でノード NIC を AF_PACKET キャプチャさせるのが定番構成だ。eBPF ランタイムセキュリティ実践ガイドで紹介した Falco / Tetragon と併用すれば、ネットワーク・プロセス・システムコールの3レイヤーを同時にカバーできる。
# wazuh-agent-daemonset.yaml（抜粋）
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: wazuh-agent
namespace: security
spec:
selector: { matchLabels: { app: wazuh-agent } }
template:
metadata: { labels: { app: wazuh-agent } }
spec:
hostNetwork: true # eve.json を hostPath で共有
hostPID: true
containers:
- name: agent
image: wazuh/wazuh-agent:4.14.7
env:
- { name: WAZUH_MANAGER, value: "wazuh-manager.security.svc" }
- { name: WAZUH_REGISTRATION_SERVER, value: "wazuh-manager.security.svc" }
- { name: WAZUH_REGISTRATION_PASSWORD, valueFrom: { secretKeyRef: { name: wazuh-registration, key: password } } }
volumeMounts:
- { name: suricata-logs, mountPath: /var/log/suricata }
- { name: var-ossec, mountPath: /var/ossec }
resources:
requests: { cpu: 100m, memory: 256Mi }
limits: { cpu: 500m, memory: 512Mi }
volumes:
- name: suricata-logs
hostPath: { path: /var/log/suricata, type: DirectoryOrCreate }
- name: var-ossec
hostPath: { path: /var/lib/wazuh/agent, type: DirectoryOrCreate }Suricata サイドカーは af-packet.threads をノードの物理コア数の半分程度に設定し、cluster-type: cluster_flow でフロー単位に分散させる。EKS では CNI が VPC 直結の eth0 を使うため、Ingress / Egress の両方向をキャプチャできる。Fargate は hostNetwork が使えないため、この構成は EC2 ノード限定になる点に注意する。
Wazuh Indexer は OpenSearch フォークなので、ヒープサイズと bootstrap.memory_lock、シャード数の3点が性能の8割を決める。Wazuh Indexer のチューニングガイドに沿って、ヒープは物理 RAM の 50% かつ最大 32GB とする。EPS が 5,000 を超えるなら Indexer を3ノード以上のクラスタにし、1インデクスあたり shards = ceil(daily_gb / 30GB) を目安に設計する。私が運用してきた指針を表にした：
| 環境規模 | EPS 目安 | Indexer 台数 | ヒープ / 台 | 1日あたりインデクスサイズ |
|---|---|---|---|---|
| PoC (all-in-one) | < 500 | 1 | 4 GB | ~2 GB |
| 小規模本番 | 500 - 2,000 | 1 - 2 | 16 GB | 10 - 30 GB |
| 中規模 | 2,000 - 8,000 | 3 | 32 GB | 60 - 150 GB |
| 大規模 | 8,000 - 25,000 | 5+ (dedicated master 別途) | 32 GB | 200 GB+ |
Manager 側では analysisd.event_threads と syscheck.max_eps を負荷に合わせて調整し、キュードロップ（events dropped）が出ていないかを /var/ossec/queue/ の使用率と Prometheus エクスポータで監視する。時刻同期 (chrony) は必須で、Suricata と Manager の時刻が数秒でもズレるとルール frequency と timeframe が誤動作する。Suricata 公式ドキュメントと MITRE ATT&CK フレームワークを定期的にチェックし、新しい戦術・技法にルールを追随させる運用を DevSecOps パイプラインに組み込むのが、この構成を長く使い続けるコツだ。監査要件と併走するなら、Lynis・OpenSCAP 実践ガイドのスコアリング指標と Wazuh の SCA モジュールを掛け合わせて、コンプライアンス報告を自動生成すると良い。
Wazuh は SIEM を基盤としつつ、エージェントによる EDR 相当機能（FIM、SCA、脆弱性検知、アクティブレスポンス）と Suricata や Zeek などとの NIDS 連携、クラウド API 連携を組み合わせることで XDR に必要な多層検知を実現できます。商用 XDR に比べて自動応答プレイブックの完成度は劣りますが、Suricata + アクティブレスポンス + Webhook を組めば実運用可能な XDR として機能します。
不要です。Suricata の eve.json は Wazuh 組み込みの JSON デコーダで自動的にパースされ、alert.severity や tls.ja4 といったフィールドはそのままルール条件に使えます。/var/ossec/ruleset/rules/0475-suricata_rules.xml が既定でシグネチャベースの分岐を提供しているため、追加するのは local_rules.xml のカスタムルールだけで十分です。
まず suricata.yaml の outputs.eve-log.types から不要なイベントタイプ（stats、fileinfo、拡張 HTTP）を除外します。次に threshold.config で誤検知しやすい SID に suppress を適用し、必要に応じて disable.conf で ET Open ルールを SID 単位に無効化します。この2段構えで平均 60〜70% のログ量削減が可能です。
Wazuh 5.0 では Filebeat が廃止され Manager がネイティブに Indexer へ書き込む設計になるため、Filebeat 依存の外部連携（Logstash パイプラインなど）は事前に見直す必要があります。またクラスタがデフォルト有効化されるので、シングルノードでの運用を続ける場合も <cluster> ブロックの設定を明示する必要があります。ベータ版で本番投入は推奨されないため、4.14.7 で運用を安定させながら段階的に準備するのが安全です。
EPS 500 未満の PoC や小規模検証であれば all-in-one で問題ありませんが、本番では必ず分離してください。Indexer は 32GB クラスのヒープを確保するため、同居させると analysisd のイベント処理と OpenSearch のインデクシングが同じ CPU / メモリを奪い合い、キュードロップが発生します。EPS 2,000 を超えたら Indexer は最低3ノードのクラスタに切り替えます。