本記事では、前回Wazuh Web UIに表示されなかった独自形式のSyslogを題材に、
その原因の調査方法とカスタマイズ方法を紹介します。
はじめに
みなさんこんにちは。
前回の記事では、WazuhはSyslogを受信することで、
エージェントを導入できない機器のログも収集できることを確認しました。
しかし、独自形式のSyslogはWazuhサーバーで受信されているにもかかわらず、
Web UIに表示されませんでした。
今回は、そのSyslogをWazuhで分析できるようにしていきます。
ⓘ 補足
本記事はSyslogを題材にしていますが、Wazuh Web UIに期待するログが表示されない場合の調査やカスタマイズの考え方は、Syslog以外のログにも応用できます。
この記事を読むと分かること
- Wazuh Web UIに表示されないログを調査する方法
- Wazuhのデコーダーとルールの基本的な役割
- Wazuh Web UIでデコーダーとルールをカスタマイズする方法
ⓘ 補足
本記事では、Wazuh Web UIを使用したカスタマイズ手順を紹介します。
Wazuhサーバー上の設定ファイルを直接編集してカスタマイズしたい場合は、Wazuh社のオンラインドキュメントをご参照ください。
■ お問い合わせ・免責事項
本記事に関するお問い合わせは、弊社のお問い合わせフォームよりご連絡ください。記事の作成にあたっては正確な記述に努めていますが、本記事の内容に基づく運用結果について、弊社では一切の責任を負いかねます。あらかじめご了承ください。
作業環境と前提条件
今回使用する環境
本記事では、以下の環境で動作を確認しています。
- Wazuhサーバー：Wazuh v4.14.8（VirtualBox上の仮想マシン）
- Syslog送信元：以下のいずれかをご用意ください
- Windows
- Linux
- Syslog対応機器
ⓘ 補足
・ 本記事では執筆時点の最新版（v4.14.8）を使用しています。
・ アップグレード手順は第3弾を参照してください。
・ Syslog対応機器をお持ちでない場合は、PowerShellまたはloggerコマンドでテスト用のSyslogを送信できます。
・ WindowsとLinuxの両方を用意する必要はありません。
・ 可能であれば、エージェント未導入端末の使用をおすすめします。
・ Syslogを送信できるツールであれば、本記事で紹介する方法以外でも構いません。
前提条件
以下を満たしていることを前提とします。
ⓘ 補足
・ バージョンは問いませんが、v4.14.1以降を想定しています。
・ 第5弾で送信したテスト用Syslogを引き続き使用します。
作業の流れ
前回は、SyslogがWazuhサーバーまで正常に届いていることを確認しました。
今回は、独自形式のSyslogをWazuh Web UIに表示できるようにするための設定を行います。
（archives.jsonに保存されたログを確認）
↓
カスタムデコーダーを作成
（firewall_action や severity などのフィールドを抽出）
↓
カスタムルールを作成
（severity に応じてレベルを設定）
↓
Wazuh Web UIで確認
ログがWazuh Web UIに表示される仕組み
作業を始める前に、
Wazuhサーバーがログをどのように処理しているのかを
簡単に確認しておきましょう。
Wazuhサーバーは、
受信したすべてのログをそのままWeb UIに表示するわけではありません。
受信したログをまず「デコーダー」で解析し、
その後「ルール」で評価します。
デフォルト設定では、
アラートレベルが 3以上と評価されたログのみを
アラートとして保存し、
Wazuh Web UIに表示します。
↓
デコーダー
（ログを解析）
↓
ルール
（アラートレベルを評価）
↓
アラートとして保存
（アラートレベル3以上のログ）
↓
Wazuh Web UIに表示
ⓘ 補足
「デコーダー」は、受信したログから「ルール」での評価に必要な情報をフィールドごとに抽出します。
「ルール」は、「デコーダー」によって抽出された情報を評価し、アラートレベルや説明文などを設定します。
そのため、以下のようなログはWazuh Web UIに表示されません。
- デコーダーやルールによって適切に処理されなかったログ
- ルールによってアラートレベル 2以下と評価されたログ
ⓘ 補足
受信したすべてのログを保存すると、大量のログによって重要なセキュリティイベントが埋もれてしまいます。また、ストレージ使用量も増加します。そのため、Wazuhでは、デフォルトで一定以上の重要度を持つログ（アラートレベル 3以上のログ）のみをアラートとして保存する設定になっています。
アラートとして保存するアラートレベルの閾値は、ユーザーが変更できます。
表示されないSyslogの調査
まずは、前回Wazuhサーバーで受信されたにもかかわらず、
Wazuh Web UIに表示されなかった独自形式のSyslogを調査します。
Wazuhアーカイブ機能の有効化
表示されなかった原因を調査するため、
Wazuhのアーカイブ機能を有効化します。
Wazuhのアーカイブ機能を有効化すると、
受信したログがファイルに保存されるようになります。
ⓘ 補足
Wazuhのアーカイブ機能を有効にすると、Wazuhサーバーが受信するすべてのログがWazuhサーバー上のファイル（/var/ossec/logs/archives/archives.log、/var/ossec/logs/archives/archives.json）に保存されます。デフォルトではこの機能は無効化されています。
Wazuh Web UIにログインし、
「☰」→「Server management」→「Settings」→「Edit configuration」を選択します。
Manager configuration画面が開きます。
<global>セクションの<logall_json>を
<logall_json>yes</logall_json>に変更します。
ⓘ 補足
<logall_json>をyesにすると、受信したログがJSON形式でarchives.jsonに保存されます。
<logall>をyesにすると、受信したログがプレーンテキスト形式でarchives.logに保存されます。
本記事では、デコーダーやルールの処理結果を確認するため、JSON形式でログを保存できる<logall_json>のみを有効化します。詳細については、Wazuh社オンラインマニュアルの logall および logall_json オプションを参照してください。
「Save」を選択して保存し、「Restart Manager」を選択して再起動します。
「Confirm」を選択します。
Managerの再起動が完了したことを確認します。
これで、Wazuhサーバーが受信したSyslogはすべて/var/ossec/logs/archives/archives.json
に保存されるようになりました。
Syslogを再送信
前回と同じコマンドを実行し、
SyslogをWazuhサーバーへ送信します。
ⓘ 補足
アーカイブ機能を有効化したため、受信したSyslogは、/var/ossec/logs/archives/archives.json に保存されます。次の手順では、このSyslogを archives.json から確認します。
Windows（PowerShell）を使用する場合
$m="<14>$((Get-Date).ToString('MMM dd HH:mm:ss',[System.Globalization.CultureInfo]::InvariantCulture)) $env:COMPUTERNAME firewall: SYSLOG_TEST firewall_action=deny severity=high srcip=203.0.113.10 dstip=192.168.1.10 dstport=3389 protocol=tcp";$c=New-Object Net.Sockets.TcpClient('<WazuhサーバーIP>',514);$s=$c.GetStream();$b=[Text.Encoding]::UTF8.GetBytes($m+"`n");$s.Write($b,0,$b.Length);$s.Close();$c.Close()Linux（logger）を使用する場合
logger --rfc3164 -t firewall -T -n <WazuhサーバーIP> -P 514 "SYSLOG_TEST firewall_action=deny severity=high srcip=203.0.113.10 dstip=192.168.1.10 dstport=3389 protocol=tcp"archives.jsonを確認
archives.jsonの中から、今回送信したSyslogを検索します。
Wazuhサーバーで次のコマンドを実行します。
sudo grep "firewall: SYSLOG_TEST" /var/ossec/logs/archives/archives.json💡 ヒント
本記事と異なるメッセージを使用している場合は、grepオプションに送信したメッセージが見つかる条件を指定してください。
出力例（見やすく整形しています）
{
"timestamp": "2026-09-30T17:22:48.442+0900",
"agent": {
"id": "000",
"name": "wazuh-server"
},
"manager": {
"name": "wazuh-server"
},
"id": "1790756568.9350662",
"full_log": "Sep 30 08:22:33 WINDEMOSRV firewall: SYSLOG_TEST firewall_action=deny severity=high srcip=203.0.113.10 dstip=192.168.1.10 dstport=3389 protocol=tcp",
"predecoder": {
"program_name": "firewall",
"timestamp": "Sep 30 08:22:33",
"hostname": "WINDEMOSRV"
},
"decoder": {},
"location": "Syslog送信元IPアドレス"
}
full_log には、デコーダーの解析対象となるログメッセージが保存されています。
しかし、decoderが {} であることから、
このログメッセージに適用されたデコーダーが存在しないことが分かります。
このログをWazuhで分析するには、
必要な情報を抽出するカスタムデコーダーが必要です。
ⓘ 補足
デコーダーが実際に処理する内容は、full_logに記録されたログメッセージです。
Syslogのカスタムデコーダーを作成する際は、送信したSyslogメッセージそのものではなく、archives.json に記録された full_log の内容を基に設計してください。
WazuhはSyslogを受信すると、タイムスタンプやホスト名、プログラム名などをPre-decodingフェーズ（デコード前に実行される処理でユーザーによるカスタマイズはできません）で抽出します。
カスタムデコーダーの追加
デコーダーは、受信したログからルール評価に必要な情報を取り出すための設定です。
本記事では、full_logに記録されたログメッセージから
firewall_action や severity などの値を抽出する
カスタムデコーダーを作成します。
「☰」→「Server management」→「Decoders」を選択します。
「Add new decoders file」を選択します。
画面上部の入力エリアに、
作成するカスタムデコーダーのファイル名を入力します。
ここでは例として、
999_custom_firewall_decoders.xmlと入力します。
ⓘ 補足
ファイル名は任意ですが、用途が分かる名前を付けることをおすすめします。
カスタムデコーダーの作成には、既存のlocal_decoder.xmlファイルを使用することもできます。
その他の組み込みファイルは、Web UI上からは編集できません。既存のデコーダーをカスタマイズする手順については、本記事の対象外です。Wazuh社の公開ドキュメントをご参照ください。
画面中央の入力エリアにデコーダー定義を入力します。
今回は以下の内容をコピーして貼り付けてください。
<decoder name="custom-firewall-syslog">
<program_name>firewall</program_name>
<prematch>SYSLOG_TEST</prematch>
</decoder>
<decoder name="custom-firewall-syslog">
<parent>custom-firewall-syslog</parent>
<regex offset="after_parent">firewall_action=(\w+)</regex>
<order>firewall_action</order>
</decoder>
<decoder name="custom-firewall-syslog">
<parent>custom-firewall-syslog</parent>
<regex offset="after_regex">severity=(\w+)</regex>
<order>severity</order>
</decoder>
<decoder name="custom-firewall-syslog">
<parent>custom-firewall-syslog</parent>
<regex offset="after_regex">srcip=(\S+)</regex>
<order>srcip</order>
</decoder>
<decoder name="custom-firewall-syslog">
<parent>custom-firewall-syslog</parent>
<regex offset="after_regex">dstip=(\S+)</regex>
<order>dstip</order>
</decoder>
<decoder name="custom-firewall-syslog">
<parent>custom-firewall-syslog</parent>
<regex offset="after_regex">dstport=(\d+)</regex>
<order>dstport</order>
</decoder>
<decoder name="custom-firewall-syslog">
<parent>custom-firewall-syslog</parent>
<regex offset="after_regex">protocol=(\w+)</regex>
<order>protocol</order>
</decoder>
上記は、Sibling Decoders形式のデコーダーです。
Sibling Decoders形式は、フィールドごとに個別のデコーダーで値を抽出します。そのため、ログ中のフィールド順序が変化しても対応しやすいという特徴があります。
デコーダーの定義方法には、上記のSibling Decoders形式の他にTraditional log decoding形式も使用できます。Traditional log decoding形式では、1つの正規表現でログ全体を解析します。以下はサンプルです。
<decoder name="custom-firewall-syslog">
<program_name>firewall</program_name>
<prematch>SYSLOG_TEST</prematch>
</decoder>
<decoder name="custom-firewall-fields">
<parent>custom-firewall-syslog</parent>
<regex>firewall_action=(\w+) severity=(\w+) srcip=(\S+) dstip=(\S+) dstport=(\d+) protocol=(\w+)</regex>
<order>firewall_action,severity,srcip,dstip,dstport,protocol</order>
</decoder>
フィールドの順序が固定されている場合は Traditional log decoding形式でも問題ありませんが、フィールドの出現順序が変化する場合は Sibling Decoders形式をおすすめします。
各XML要素およびSibling Decoderの詳細については、Wazuh社オンラインドキュメントを参照してください。
「Save」を選択してファイルを保存します。
「Decoders Test」を選択し、
作成したカスタムデコーダーをテストします。
画面上部の入力エリアに
full_logの内容を貼り付けて「Test」を選択します。
画面下部にテスト結果が表示されます。
Phase 2の内容に注目してください。
作成したカスタムデコーダーでログが解析され、firewall_action や severity などのフィールドが抽出されていることが確認できます。
**Phase 2: Completed decoding.
name: 'custom-firewall-syslog'
dstip: '192.168.1.10'
dstport: '3389'
firewall_action: 'deny'
protocol: 'tcp'
severity: 'high'
srcip: '203.0.113.10'「Decoders Test」右上の「✕」を選択して画面を閉じます。
「Reload」を選択して、変更をWazuhサーバーに反映します。
これで、ログメッセージから
必要な情報をフィールドごとに抽出できるようになりました。
しかし、まだこのSyslogはWazuh Web UIに表示されません。
これは、まだ重要度（アラートレベル）が評価されていないためです。
次は、このログの重要度を評価するカスタムルールを作成します。
カスタムルールの追加
ルールは、デコーダーによって抽出された情報を評価し、
アラートレベルや説明文を決定するための設定です。
本記事では、severityの値に応じて
異なるアラートレベルを設定するカスタムルールを作成します。
「☰」→「Server management」→「Rules」を選択します。
「Add new rules file」を選択します。
画面上部の入力エリアに、
作成するカスタムルールのファイル名を入力します。
ここでは例として、
999_custom_firewall_rules.xml と入力します。
ⓘ 補足
ファイル名は任意ですが、用途が分かる名前を付けることをおすすめします。
カスタムルールの作成には、既存のlocal_rules.xmlファイルを使用することもできます。
その他の組み込みファイルは、Web UI上からは編集できません。既存のルールをカスタマイズする手順については、本記事の対象外です。Wazuh社の公開ドキュメントをご参照ください。
画面中央の入力エリアにルールを入力します。
今回は以下の内容をコピーして貼り付けてください。
このルールは、severityの値に応じて異なるレベルを付与します。
<group name="custom_firewall,">
<rule id="100500" level="0">
<decoded_as>custom-firewall-syslog</decoded_as>
<description>Custom Firewall Event</description>
</rule>
<rule id="100501" level="2">
<if_sid>100500</if_sid>
<field name="severity">low</field>
<description>Custom Firewall: Low severity event</description>
</rule>
<rule id="100502" level="5">
<if_sid>100500</if_sid>
<field name="severity">medium</field>
<description>Custom Firewall: Medium severity event</description>
</rule>
<rule id="100503" level="10">
<if_sid>100500</if_sid>
<field name="severity">high</field>
<description>Custom Firewall: High severity event</description>
</rule>
</group>
ⓘ 補足
カスタムルールのidには、Wazuh社オンラインドキュメントで記載されている通り100000～120000の範囲を使用するようにしてください。本記事では100500番台を使用します。詳細は Wazuh社オンラインドキュメントを参照してください。
「Save」を選択します。
「Ruleset Test」を選択し、
作成したカスタムルールをテストします。
「Clear session」を選択し、
セッションをクリアします。
「Confirm」を選択します。
画面上部の入力エリアに full_logの値を貼り付けて
「Test」を選択します。
画面下部にテスト結果が表示されます。
今回は、Phase 3の内容に注目してください。
作成したカスタムルールによってログが評価され、
level 10 のアラートが生成されることが確認できます。
**Phase 3: Completed filtering (rules).
id: '100503'
level: '10'
description: 'Custom Firewall: High severity event'
groups: '["custom_firewall"]'
firedtimes: '1'
mail: 'false'
**Alert to be generated.「Ruleset Test」右上の「✕」を選択して画面を閉じます。
「Reload」を選択して、変更をWazuhサーバーに反映します。
これで、Syslogメッセージの内容に応じて
アラートレベルを設定できるようになりました。
次は、実際にSyslogを送信し、
Wazuh Web UIに表示されることを確認します。
動作確認
もう一度Syslogを送信して、
Wazuh Web UIに表示されるようになったか確認してみましょう。
Syslogを再送信
今回は、severityの異なるログ（high、medium、low）を送信してください。
Windows（PowerShell）を使用する場合
severity の値を high → medium → low の順に変更し、
それぞれ送信してください。
$m="<14>$((Get-Date).ToString('MMM dd HH:mm:ss',[System.Globalization.CultureInfo]::InvariantCulture)) $env:COMPUTERNAME firewall: SYSLOG_TEST firewall_action=deny severity=high srcip=203.0.113.10 dstip=192.168.1.10 dstport=3389 protocol=tcp";$c=New-Object Net.Sockets.TcpClient('<WazuhサーバーIP>',514);$s=$c.GetStream();$b=[Text.Encoding]::UTF8.GetBytes($m+"`n");$s.Write($b,0,$b.Length);$s.Close();$c.Close()Linux（logger）を使用する場合
severity の値を high → medium → low の順に変更し、
それぞれ送信してください。
logger --rfc3164 -t firewall -T -n <WazuhサーバーIP> -P 514 "SYSLOG_TEST firewall_action=deny severity=high srcip=203.0.113.10 dstip=192.168.1.10 dstport=3389 protocol=tcp"💡 ヒント
今回のカスタムルールでは severity の値によって以下のように処理されます。
・low → level 2
・medium → level 5
・high → level 10
デフォルト設定では level 3 以上のログのみがアラートとして保存され、Wazuh Web UIに表示されます。
Wazuh Web UIで確認
送信したSyslogが Wazuh Web UI に表示されるかを確認してみましょう。
「☰」 → 「Explore」 → 「Discover」を選択します。
フィルター条件として、
location:<Syslog送信元IPアドレス> を指定し、
Search 欄に SYSLOG_TEST と入力して検索します。
これにより、本記事で送信したSyslogのみを表示できます。
以下は、結果を確認しやすくするために
表示項目を調整した画面例です。
severity が medium または high のSyslogは表示されていますが、
severity が low のSyslogは表示されていません。
Ruleset Testで表示されない理由を確認
severity が low のSyslogがWazuh Web UIに表示されない理由を、
Ruleset Test を使って確認しておきましょう。
「☰」 → 「Server management」 → 「Ruleset Test」を選択します。
画面上部の入力エリアに
今回送信した severity=low の Syslog メッセージを貼り付けて
「Test」を選択します。
画面下部にテスト結果が表示されます。
Phase 3 の内容に注目してください。
level が 2 であり、
「Alert to be generated.」が出力されていないことが確認できます。
severity=low のログもルールで評価されていますが、
アラートレベル（level）が 2 のため、
アラートとして保存されず、
Wazuh Web UI に表示されなかったことが分かりました。
ⓘ 補足Ruleset Testは、カスタムルールの編集画面（「Server management」→「Rules」の任意のカスタムルールの編集画面）から実行することもできます。また、コマンドラインから実行することも可能です。コマンドラインを使用する方法については、Wazuh社のオンラインドキュメントをご参照ください。
事後作業：Wazuhアーカイブ機能の無効化
動作確認が完了したら、
Wazuhアーカイブ機能を無効化しておきましょう。
ⓘ 補足
Wazuhアーカイブを有効化すると、監視対象のエンドポイントから収集されたログが保持され続けるため、Wazuhサーバーのストレージ使用量が増加します。通常の運用では、アーカイブ機能は無効化しておくことをおすすめします。
「☰」→「Server management」→「Settings」→「Edit configuration」を選択します。
<global>セクションの<logall_json>を
<logall_json>no</logall_json>に変更します。
「Save」を選択して保存し、
「Restart Manager」を選択して再起動します。
Managerの再起動が完了したことを確認します。
まとめ
今回は、独自形式のSyslogをWazuhで分析できるようにするための
調査方法とカスタマイズ方法を紹介しました。
本記事のポイントは以下のとおりです。
- Wazuhは導入直後に処理できない独自形式のログであっても、
デコーダーやルールをカスタマイズすることで分析できる - アーカイブ機能（
archives.json）を有効化すると、
Wazuhがデコーダーで処理するログメッセージ（full_log）を確認できる - デコーダーやルールのカスタマイズには、
Decoders TestやRuleset Testなどのテストツールを活用できる - Wazuh Web UIに表示されるかどうかは、
ルールによって設定されたアラートレベルに依存する
本記事の内容は、Syslogに限らず、
Wazuh Web UIに期待するログが表示されない場合の
基本的な調査手順として活用できます。
まずは archives.json を確認し、
デコーダーとルールのどちらに問題があるのかを切り分けましょう。
↓
archives.jsonで確認
↓
Decoders Test / Ruleset Test
（解析結果・評価結果を確認）
↓
デコーダーやルールをカスタマイズ
（必要に応じて修正）
次回予告：検知したイベントにどう気付く？アラート通知の設定
本記事では、Syslogをテーマにデコーダーでログを解析し、
ルールで重要度（アラートレベル）を設定する方法を紹介しました。
次回は、重要度（アラートレベル）が高いログを
メール、Slack、Microsoft Teams などで管理者へ通知する方法を紹介します。
Wazuh Cloud の利用を検討している方へ
Wazuh Cloud環境においても、本記事で紹介したデコーダーやルールのカスタマイズはユーザー自身で実施できます。
Wazuh Cloud環境で独自形式のSyslog監視を検討されている場合は、弊社までご相談ください。
Wazuh製品紹介ページ
Wazuhの特長や機能については、以下の製品紹介ページをご参照ください。
Wazuh Cloud無料トライアル
Wazuh Cloudの無料トライアルについては、以下よりお気軽にお問い合わせください。
