Posted inセキュリティ

LinuxでのWazuh SIEM/XDR構築：一元化されたセキュリティ管理とActive Responseの設定

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

脅威検知アプローチの比較：単一ホストのログ vs. SIEM/XDR

深夜2時、高負荷アラートによってスマートフォンが激しく鳴り響きました。分散型ボットネットがエッジAPIゲートウェイに対して15,000件以上のリクエストを一斉に浴びせかけていたのです。本番環境がダウンするパニックの中、SSHで6つのノードにログインして未加工の /var/log/auth.log をgrepしようとするのは、運用上の悪夢でしかありません。このインシデントから得た教訓はシンプルです。「孤立したログファイルだけでは、現代のサーバーフリートを保護することはできない」ということです。

Linuxインフラを保護する際、多くのチームは通常、以下の3つの可視化・インシデント対応モデルのいずれかに依存しています。

  • 分散型のローカルスクリプト運用（Fail2ban & Logrotate）： 個々のサーバー上で実行され、ローカルログを解析してファイアウォールの遮断ルールを挿入します。5分程度でセットアップできますが、複数のノードにまたがる組織的な攻撃を把握することはできません。
  • 従来の集中型ログ集約（ELK / Loki）： すべてのログ行をElasticsearchやGrafana Lokiクラスターに送信します。アプリケーション障害のデバッグには適していますが、検知ルールやステートマシン、脅威インテリジェンスのパイプラインを一から構築する必要があります。
  • オープンソースSIEM/XDR（Wazuh）： 集中ログ管理、リアルタイムのファイル整合性監視（FIM）、脆弱性スキャン、コンプライアンス監査を統合します。さらに重要な点として、ホストレベルで攻撃者を直接阻止する双方向のActive Responseを備えています。

Wazuh運用のメリットとデメリット

Wazuhはエンタープライズグレードの検知機能を提供しますが、事前のキャパシティプランニングが必要です。

メリット

  • 自動化されたActive Response： ルールにマッチした瞬間、iptables/nftables によるIP遮断、不正侵入されたアカウントのロック、不正プロセスの強制終了などの修復スクリプトを即座に実行します。
  • 統合されたセキュリティテレメトリ： システム監査イベント、ルートキットアラート、パッケージ脆弱性のCVE、MITRE ATT&CKのマッピングを1つの統合ダッシュボードにまとめます。
  • 豊富な標準ルールセット： Linuxのシステムコール、Dockerコンテナ、Nginx、Apache、OpenSSH、AWS/GCPの監査ログをカバーする4,000以上の事前設定済みルールが付属しています。

デメリット

  • リソースフットプリント： Wazuh IndexerとDashboardはOpenSearch上で動作します。マネージャーノードには最低4GB〜8GBのRAMが必要となるため、5ドルの低スペックVPSインスタンスには重すぎます。
  • チューニングの手間： デフォルトのルールセットは負荷の高いサーバーで過剰なアラートを発生させやすいため、ワークロードに合わせてホワイトリストルールを調整する必要があります。

推奨アーキテクチャ構成

中小規模の構成（監視対象ノード1〜100台）では、単一ホストのWazuhセントラルノードで軽量なエンドポイントエージェントを管理することで、複雑なクラスター管理を行わずに信頼性の高い分離環境を実現できます。

  • セントラルマネージャーノード： Ubuntu 22.04または24.04 LTS、4 vCPU、8GB RAM、50GB以上のNVMe/SSDストレージ。
  • エンドポイントエージェントノード： C言語ベースの軽量エージェントを実行するLinuxサーバー。各デーモンのリソース消費はCPU 1%未満、RAM約35MB〜50MBに収まります。
  • マネージャー側のファイアウォール受信ポート： TCPポート 1514（エージェントイベント通信）、TCPポート 1515（エージェント登録サービス）、TCPポート 443（HTTPS Web UI）。

実装ガイド：マネージャー、エージェント、Active Responseのデプロイ

ステップ1：Wazuhオールインワンマネージャーのインストール

専用のセントラルサーバー上で、公式のインストールアシスタントを実行します。このスクリプトにより、TLS証明書の生成とともにWazuh Manager、OpenSearch Indexer、Web Dashboardが自動プロビジョニングされます。

# サイレントインストールアシスタントのダウンロードと実行
curl -sO https://packages.wazuh.com/4.9/wazuh-install.sh
sudo bash ./wazuh-install.sh -a

スクリプトの実行が完了すると、Web UIのURL（https://<YOUR_MANAGER_IP>）とともに、admin ユーザーの生成された認証情報が表示されます。これらをコピーして、すぐにパスワードマネージャーに保管してください。

3つのコアサービスがすべてアクティブで正常に動作していることを確認します。

sudo systemctl status wazuh-manager wazuh-indexer wazuh-dashboard

ステップ2：エンドポイントサーバーへのWazuhエージェントのデプロイと登録

監視対象となる任意のLinuxサーバーにSSHでログインし、公式エージェントパッケージをインストールします。

# WazuhのGPGキーとAPTリポジトリを追加
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && sudo chmod 644 /usr/share/keyrings/wazuh.gpg

echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | sudo tee /etc/apt/sources.list.d/wazuh.list
sudo apt-get update

# マネージャーのプライベートIPを直接指定してエージェントをインストール
sudo WAZUH_MANAGER='192.168.1.100' apt-get install wazuh-agent

# エージェントサービスを有効化して起動
sudo systemctl daemon-reload
sudo systemctl enable --now wazuh-agent

30秒以内に新しいエンドポイントが登録され、Wazuhダッシュボード上で Active として表示されます。

ステップ3：Active Responseによる自動IP遮断の設定

Active Responseは、Wazuhに実用的な防御力をもたらします。エージェントが不審な挙動を検知すると、ローカルで自動修復を即座に実行します。ここでは、SSH認証の連続失敗を検知した際に、攻撃元IPを30分間自動で遮断するようWazuhを設定します。

Wazuh Manager ホスト上で /var/ossec/etc/ossec.conf を開きます。

sudo nano /var/ossec/etc/ossec.conf

<ossec_config> ブロックを探し、以下のコマンドおよびactive-responseルールを追加します。

<!-- 組み込みのfirewall-dropスクリプトを参照 -->
<command>
  <name>firewall-drop</name>
  <executable>firewall-drop</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

<!-- SSHブルートフォースのアラートグループでfirewall-dropを発動 -->
<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_group>authentication_failed|authentication_failures</rules_group>
  <timeout>1800</timeout> <!-- 攻撃元IPを30分間ブロック -->
</active-response>

新しい検知ロジックを適用するためにマネージャーを再起動します。

sudo systemctl restart wazuh-manager

ステップ4：リアルタイムファイル整合性監視（FIM）の有効化

攻撃者は不正アクセスに成功した後、ドキュメントルートにWebシェルを配置したり、システムバイナリを改ざんしたりすることがよくあります。FIMはファイルのチェックサムを追跡し、不正な変更を検知してアラートを出します。

監視対象のエージェントノード で /var/ossec/etc/ossec.conf を編集し、重要なディレクトリをリアルタイムで監視するように設定します。

<syscheck>
  <disabled>no</disabled>
  <frequency>3600</frequency>
  <directories realtime="yes" check_all="yes" report_changes="yes">/etc,/var/www,/usr/bin,/usr/sbin</directories>
</syscheck>

ファイルシステムのイベント監視を開始するためにエージェントを再起動します。

sudo systemctl restart wazuh-agent

ステップ5：アクティブディフェンスのテストと検証

レスポンスチェーンを検証するために、外部IPアドレスからエージェントに対してSSHログインの失敗を5回シミュレートします。その後、対象エージェント上でActive Responseのログをリアルタイムで監視します。

sudo tail -f /var/ossec/logs/active-responses.log

しきい値に達すると、スクリプトによってファイアウォールの一時遮断エントリが追加されるのが確認できます。

/var/ossec/active-response/bin/firewall-drop add - 203.0.113.45 1718929200.12845 5716

最後に、Wazuhダッシュボードを開いて Security Events に移動します。関連付けられたイベントグラフ、ルールレベル、MITRE戦術タグ、そしてフリート全体で実行された正確な修復ログが反映されていることを確認できます。

Share:
Tags: