本記事では、エージェント導入直後から利用できる機能の動作と、関連する初期設定を紹介します。
はじめに
みなさんこんにちは。
Wazuhは、エージェントを導入した直後から多くの機能を利用できます。
今回は、導入直後から利用できる機能と、それらに関連する初期設定を確認します。
▼前回までの記事はこちら
【初心者向け】最短で構築!Wazuh公式OVAで検証環境を作る方法(VirtualBox)
【初心者向けWazuh第2弾】Windows&Linuxにエージェントを導入してログ収集を開始する方法(←本記事の前提)
【初心者向けWazuh第3弾】Wazuh公式OVAで構築した検証環境を最新版へアップグレードする方法
この記事を読むと分かること
- エージェント導入直後から利用できる主な機能
- 各機能の確認方法
- 各機能の初期設定
- 実運用でカスタマイズが必要な理由
本記事は、Wazuh, Inc.のオンラインドキュメント「User manual」を参考に作成しています。
本記事に関するお問い合わせは、弊社のお問い合わせフォームよりご連絡ください。記事の作成にあたっては正確な記述に努めていますが、本記事の内容に基づく運用結果について、弊社では一切の責任を負いかねます。あらかじめご了承ください。
作業環境と前提条件
今回使用する環境
前回までの記事に引き続き、以下の環境を使用します。
- Wazuhサーバー:Wazuh v4.14.7(VirtualBox上の仮想マシン)
- 監視対象Windows:Windows Server 2025(評価版)
- 監視対象Linux:Ubuntu 24.04 LTS
- 作業端末:Wazuh Web UIにアクセス可能で、監視対象WindowsへRDP接続、監視対象LinuxへSSH接続できる任意のコンピューター
前提条件
本記事の前提条件は以下のとおりです。
- 第2弾までの構築が完了していること
- エージェントのステータスがactiveであること
- Wazuh Web UIにログインできること
エージェント導入直後から利用できる主な機能
本記事では以下の機能を紹介します。
| No | 機能 | 概要 |
|---|---|---|
| 1 | ログ収集 | Windowsのイベントログ、Linux Journalログ・Syslogを収集 |
| 2 | ファイル整合性監視(FIM) | ファイルの追加・削除・変更を検知 (Windowsの場合は、レジストリキーの追加・削除・変更も検知) |
| 3 | 構成評価(SCA) | セキュリティ設定を評価 |
| 4 | インベントリ情報 | OS、ハードウェア、ソフトウェア情報を収集 |
| 5 | 脆弱性検出 | インストール済みソフトウェア情報と脆弱性情報(CVE)を照合 |
ⓘ 補足
上記の機能は、エージェントを導入した直後から利用できますが、実運用では収集対象ログの追加や除外、監視対象ファイルの変更など、環境に応じたカスタマイズを行うことが一般的です。
各機能の動作を確認する
- 収集されたログを確認する(Threat Hunting)
- ファイル変更を検知する(File Integrity Monitoring)
- 構成評価結果を確認する(Configuration Assessment)
- 収集されたインベントリ情報を確認する(IT Hygiene)
- 検出された脆弱性情報を確認する(Vulnerability Detection)
収集されたログを確認する(Threat Hunting)
Wazuhでは、エージェント導入直後からWindowsおよびLinuxの認証ログが収集されます。
ここでは、ログイン失敗イベントがどのように表示されるのかを確認します。
- エージェントをインストールした監視対象コンピューターに対して、誤ったパスワードでログインを試行します。
- Windows:RDP接続し、誤ったパスワードでログインを試行
- Linux:誤ったパスワードでSSH接続を試行
- Wazuh Web UIにログインします。
- 「☰」→「Threat intelligence」→「Threat Hunting」を選択します。
- 「Dashboard」タブ画面の「Authentication failure」に認証失敗イベントの数が表示されます。値が0以外になっていることを確認し、クリックします。

フィルター条件が設定されます。 - 「Events」タブを選択し、イベント詳細を確認してみてください。

イベント行の虫眼鏡アイコンをクリックすると、イベントの詳細情報が表示されます。
Windowsエージェントでは、ログオン失敗を示す Event ID 4625が収集されていることを確認できます。
Linuxエージェントでは、sshdによる認証失敗のログが収集されていることを確認できます。
このイベントに関連するMITRE ATT&CKや各種コンプライアンス要件も確認できます。
ⓘ 補足
Wazuhは収集したログを解析し、条件に一致したログをアラートとして記録します。
本記事では詳細な説明を割愛しますが、詳細画面ではルールレベルやルールIDなども確認できます。これらについては別の記事で解説する予定です。
ファイル変更を検知する(File Integrity Monitoring)
Wazuhでは、エージェント導入直後から重要ファイルやディレクトリの変更を監視しています。
ここでは実際にファイルを変更し、どのように検知されるのかを確認します。
ⓘ 補足
監視対象のディレクトリについては、後ほどエージェントの設定ファイルで確認します。まずは、ファイル変更を検知できることを確認してみましょう。
- エージェントを導入したコンピューターでファイルを変更します。Windows
- RDPで接続します。
%PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs\Startupフォルダにテキストファイルを作成します。💡 ヒント
Startupフォルダはプログラムの自動起動設定に利用されるため、マルウェアの永続化によく悪用されます。このため、初期設定ではリアルタイム監視の対象に設定されています。%WINDIR%\System32\drivers\etcフォルダにテキストファイルを作成します。💡 ヒント
上記のフォルダも初期設定で監視対象に設定されていますが、リアルタイム監視の対象ではありません。そのため、変更内容は定期スキャン実行時に検出されます。
Linux
- SSHで接続します。
- 次のコマンドを実行し、テスト用ファイルを作成します。
sudo touch /etc/wazuh_fim_test.txt💡 ヒント
/etcはLinuxの主要な設定ファイルが格納されるディレクトリであり、初期設定で監視対象に設定されています。
- 「☰」→「Endpoint security」→「File Integrity Monitoring」を選択します。
- 「Dashboard」ページが表示されます。
- 「Events」タブを選択し、イベントの詳細情報を確認します。Windowsの
Startupフォルダに作成したファイルに関するイベントが表示されていることを確認します。
一方で、Windowsの%WINDIR%\System32\drivers\etcフォルダや Linux の/etc/wazuh_fim_test.txtに関する変更イベントは、すぐには表示されません。💡 ヒント
Windowsの Startupフォルダはマルウェアの永続化に悪用されやすいため、初期設定でリアルタイム監視の対象となっています。その他の監視対象ディレクトリは定期スキャン方式で監視されます。初期設定では12時間ごとにスキャンが実行されるため、変更内容は次回のスキャン時に検出されます。ⓘ 補足
「Events」タブ画面では、ルールレベルやルールIDなどの情報も確認できます。ルールレベルやルールIDについては、別の記事で解説する予定です。 - 「Inventory」タブ画面では、監視対象ファイルを確認することができます。
「Inventory」タブを選択し、「Select agent」をクリックしてエージェントを選択します。
監視対象ファイル(Windowsの場合はレジストリも含む)の一覧が表示されます。
行をクリックすると、監視対象ファイルの詳細情報を確認できます。
ⓘ 補足
Windowsの Startupフォルダ以外で実施したファイル変更イベントを確認したい場合は、次回スキャン実行後にもう一度「File Integrity Monitoring」画面を確認してください。
構成評価結果を確認する(Configuration Assessment)
Wazuhでは、エージェント導入直後から構成評価(Security Configuration Assessment: SCA)が実行されます。
ここでは、構成評価結果を確認してみましょう。
ⓘ 補足
構成評価(Security Configuration Assessment: SCA)とは、システムの設定をセキュリティベストプラクティスと照らし合わせて評価する機能です。
- 「☰」→「Endpoint security」→「Configuration Assessment」を選択します。
- 「Dashboard」タブ画面にCISベンチマークに基づく評価結果が表示されます。
Passed、Failed、Not applicable の件数およびScoreを確認してみてください。
💡 ヒント
右上のエージェント名のリンクをクリックすると、画面に表示させるエージェントを選び直すことができます。
- 各チェック項目をクリックすると、チェックの詳細情報が表示されます。
チェック条件、修復方法、関連するコンプライアンス要件などの情報を確認できます。
💡 ヒント
チェック結果が Failed の項目について、Remediation(修復方法)セクションで説明されている対応を実施し、評価結果の変化を確認してみてください。
ⓘ 補足
構成評価のチェック項目はカスタマイズできます。
また、評価結果は「システムが危険であること」を示すものではなく、セキュリティベストプラクティスとの適合状況を示すものです。組織の要件によっては、Failedと判定された項目をあえて無効化している場合もあります。
収集されたインベントリ情報を確認する(IT Hygiene)
Wazuhでは、エージェント導入直後からハードウェア構成やインストール済みソフトウェアなどの情報を定期的に収集します。
ここでは、どのようなインベントリ情報が収集されているのかを確認してみましょう。
- 「☰」→「Security operations」→「IT Hygiene」を選択します。
- 「Dashboard」タブ画面に収集されたインベントリ情報の概要が表示されます。

- System、Software、Processes などのタブを切り替え、収集されているインベントリ情報を確認してみてください。
- System:OS、CPU、メモリ、ディスクなどのシステム情報
- Software:インストール済みソフトウェア、パッケージ、バージョン情報(WindowsではKBやブラウザ拡張)
- Processes:プロセス情報
- Network:IPアドレスやネットワークインターフェース情報
- Identity:ユーザー、グループ情報
- Services:サービス情報
ⓘ 補足
インベントリ情報は、脆弱性検出機能の基礎データとしても利用されています。
検出された脆弱性情報を確認する(Vulnerability Detection)
Wazuhでは、エージェント導入直後から影響を受ける可能性のある脆弱性を検出できます。
ここでは、検出された脆弱性情報を確認してみましょう。
ⓘ 補足
Wazuhは、エージェントから収集したソフトウェアやパッケージの情報と脆弱性情報を照合し、影響を受ける可能性のある脆弱性を検出します。
脆弱性情報を最新の状態に保つためには、Wazuh Managerがインターネットへ接続できることを推奨します。インターネットへ接続できない環境では、最新の脆弱性情報を手動で更新する必要があります。
- 「☰」→「Threat intelligence」→「Vulnerability Detection」を選択します。
- 「Dashboard」タブ画面で、検出された脆弱性の概要を確認します。
重大度(Critical、High、Medium、Low)ごとに集計表示されます。
- 「Inventory」 タブを選択します。
影響を受けるパッケージ名、重大度、CVE識別番号などを確認できます。
また、CVE識別番号のリンクをクリックするとWazuh CTIページが表示され、対象の脆弱性に関する詳細情報を確認できます。
ⓘ 補足
脆弱性情報は、エージェントが収集したOSパッケージやインストール済みソフトウェアの情報と、Wazuh Managerが保持する脆弱性情報(CVE)を照合して検出されます。
各機能の設定を確認する
ⓘ 補足
Wazuh ManagerおよびWazuh Agentには多数の設定項目がありますが、本記事では、今回紹介した機能に関連する主な設定のみを紹介します。各設定項目の詳細については、Wazuh公式ドキュメントを参照してください。
まずは、Wazuh ManagerとWazuh Agentの設定ファイルの場所を確認しておきましょう。
| 対象 | 設定ファイル |
|---|---|
| Wazuh Manager | /var/ossec/etc/ossec.conf |
| Windows Agent | C:\Program Files (x86)\ossec-agent\ossec.conf |
| Linux Agent | /var/ossec/etc/ossec.conf |
💡 ヒント
Wazuh Managerの設定ファイルは、Wazuh Web UIからも確認できます。
「☰」→「Server management」→「Settings」→「Edit configuration」→「Edit ossec.conf of manager」を開きます。
ログ収集の設定
ログ収集は、Wazuh Agentの localfile 設定によって制御されています。
実際に ossec.conf ファイルを開き、localfile の定義を確認してみましょう。
今回確認したログイン失敗イベントには、次の設定が関係しています。
Windows
Windowsでは、次の設定によって Security イベントログを収集し、ログイン失敗イベントを検知します。
<localfile>
<location>Security</location>
<log_format>eventchannel</log_format>
<query>Event/System[EventID != 5145 and EventID != 5156 and EventID != 5447 and
EventID != 4656 and EventID != 4658 and EventID != 4663 and EventID != 4660 and
EventID != 4670 and EventID != 4690 and EventID != 4703 and EventID != 4907 and
EventID != 5152 and EventID != 5157]</query>
</localfile>
ⓘ 補足
デフォルト設定では、Security ログに加えて、Application ログおよび System ログも収集対象として定義されています。
Linux
Linuxでは、次の設定によって Journal ログを収集し、ログイン失敗イベントを検知します。
<localfile>
<log_format>journald</log_format>
<location>journald</location>
</localfile>
ⓘ 補足
デフォルト設定では、Journal ログに加え以下の情報が定期的に収集されています。
・ ディスク使用率(df)
・ LISTENポート情報(netstat)
・ ログイン履歴(last)
・ パッケージ管理ログ(/var/log/dpkg.log)
⚠ 注意
収集対象となるログやコマンドは、OSやWazuhのバージョンによって異なる場合があります。
ファイル整合性監視(FIM)の設定
ファイル整合性監視(FIM)は、syscheck 設定によって制御されています。
<syscheck>
...
</syscheck>
syscheck では、監視対象のディレクトリや監視方法を定義します。
Windows
Windowsでは、Startupフォルダがリアルタイム監視の対象となっており、ファイルの作成や変更が即座に検知されます。
<directories realtime="yes">%PROGRAMDATA%\Microsoft\Windows\Start Menu\Programs\Startup</directories>
その他のディレクトリの多くは、<frequency> で指定された間隔で定期的にスキャンされます。
<frequency>43200</frequency>
初期設定では 43,200 秒(12時間)ごとにスキャンが実行されます。
💡 ヒント
Windowsでは重要なレジストリキーも監視対象となっています。
Linux
Linuxでは、重要なシステムディレクトリが監視対象として定義されています。
<directories>/etc,/usr/bin,/usr/sbin</directories>
<directories>/bin,/sbin,/boot</directories>
これらのディレクトリは定期スキャン方式で監視されており、変更内容はスキャン実行時に検出されます。
ⓘ 補足
初期設定の監視対象はあくまで一例です。実運用では、監視対象ファイルやディレクトリを追加・変更し、環境に応じてカスタマイズすることが一般的です。
構成評価(SCA)の設定
構成評価(SCA)は、sca 設定によって制御されています。
<sca>
<enabled>yes</enabled>
<scan_on_start>yes</scan_on_start>
<interval>12h</interval>
<skip_nfs>yes</skip_nfs>
</sca>
初期設定では、12時間ごとに構成評価が実行されます。
構成評価機能では、CISベンチマークなどのポリシーに基づいてOSの設定を評価します。
💡 ヒント
OSに応じたSCAポリシーファイルが自動的に適用されます。
ⓘ 補足
実際のチェック内容は、エージェントに含まれる SCA ポリシーファイルによって定義されています。
例えば、Windows Server 2025では C:\Program Files (x86)\ossec-agent\ruleset\sca\cis_win2025.yml
Ubuntu 24.04 では /var/ossec/ruleset/sca/cis_ubuntu24-04.yml
が利用されます。
インベントリ情報収集の設定
インベントリ情報収集は、syscollector 設定によって制御されています。
<wodle name="syscollector">
<disabled>no</disabled>
<interval>1h</interval>
<scan_on_start>yes</scan_on_start>
<hardware>yes</hardware>
<os>yes</os>
<network>yes</network>
<packages>yes</packages>
<ports all="yes">yes</ports>
<processes>yes</processes>
<users>yes</users>
<groups>yes</groups>
<services>yes</services>
<browser_extensions>yes</browser_extensions>
<!-- Database synchronization settings -->
<synchronization>
<max_eps>10</max_eps>
</synchronization>
</wodle>
syscollector では、収集対象や収集間隔を設定できます。
初期設定では、次の情報が定期的に収集されます。
- OS情報
- ハードウェア情報
- ネットワーク情報
- インストール済みソフトウェア情報
- 実行中プロセス
- ユーザー情報
- グループ情報
- サービス情報
- ブラウザ拡張情報
これらの情報は、IT Hygieneの画面で確認できます。
脆弱性検出の設定
脆弱性検出は、Wazuh AgentとWazuh Managerの両方の設定によって制御されています。
まず、Wazuh Agentの syscollector 設定によってインストール済みソフトウェア情報が収集されます。その後、Wazuh Managerの vulnerability-detection 設定によって、収集した情報と脆弱性情報が照合されます。
<vulnerability-detection>
<enabled>yes</enabled>
<index-status>yes</index-status>
<feed-update-interval>60m</feed-update-interval>
</vulnerability-detection>
ⓘ 補足<feed-update-interval>60m</feed-update-interval> は、脆弱性情報フィードの更新間隔を表しています。脆弱性情報フィードとは、ソフトウェアやパッケージとCVEの対応情報をまとめたデータです。初期設定では、60分ごとに最新の脆弱性情報を取得します。
機能と設定の対応表
ここまで紹介した機能と設定の対応をまとめます。
本記事で紹介した機能とその設定
| 機能 | 設定 |
|---|---|
| ログ収集 | localfile |
| ファイル整合性監視(FIM) | syscheck |
| 構成評価(SCA) | sca |
| インベントリ情報収集 | syscollector |
| 脆弱性検出 | syscollector + vulnerability-detection |
その他の初期設定
本記事では取り上げていませんが、初期設定には以下の機能も定義されています。
| 機能 | 設定 | 概要 |
|---|---|---|
| ルートチェック | rootcheck | ルートキット検知や不審な設定の検査 |
| 自動応答 | active-response | アラートに応じた自動対処 |
| CIS-CATとの連携 | cis-cat | 初期設定では無効 |
| Osqueryとの連携 | osquery | 初期設定では無効 |
まとめ
今回は、初期設定のWazuhでもログ収集、ファイル整合性監視(FIM)、構成評価(SCA)、インベントリ情報の収集、脆弱性検出といった機能を利用できることを確認しました。
また、それぞれの機能がどの設定によって制御されているのかも確認しました。
Wazuhでは導入直後から多くの機能を利用できますが、実運用では環境や運用方針に応じたカスタマイズが必要になります。まずは今回確認した内容を参考に、活用したい機能を整理し、少しずつ調整してみてください。
本記事が、Wazuhの初期設定を理解し、監視設計を検討する際の参考になれば幸いです。
次回予告:エージェントを導入できない機器を監視する
今回の記事では、Wazuh Agentを利用した監視を紹介しました。
しかし、実際の環境にはエージェントを導入できない機器も存在します。
次回は、Syslogを利用して、エージェントを導入できない機器のログをWazuhで監視する方法を紹介します。
Wazuhの導入・運用を検討している方へ
本記事で紹介したように、Wazuhは初期設定のままでも多くの機能を利用できます。しかし、実運用では監視対象ログの追加や除外、監視対象ファイルの選定、構成評価ポリシーの調整など、環境に応じた監視設計が必要になります。
これらの作業は、OSS版(セルフホスト)とWazuh Cloudのどちらを利用する場合でも必要になります。
一方で、Wazuh Cloudを利用すると、Wazuh サーバーの構築・保守、アップグレード、バックアップなどの運用負荷を軽減できます。
「まずはWazuhを試してみたい」「運用基盤の管理負荷を抑えたい」という場合は、Wazuh Cloudも選択肢の一つです。
実際の機能や運用イメージを確認したい方は、無料トライアルを活用してみてください。
Wazuh製品紹介ページ
Wazuhの特長や機能については、以下の製品紹介ページをご参照ください。
Wazuh Cloud無料トライアル
Wazuh Cloudの無料トライアルについては、以下よりお気軽にお問い合わせください。


