【ITニュース解説】FortiGate denied traffic never reaches the Wazuh dashboard. Rule 81618 is level 1.

システムを安全に運用するために、セキュリティデバイスから出力される「ログ」を監視することは非常に重要である。ログはシステムで何が起こったかを示す記録であり、セキュリティ侵害の兆候やシステム異常を発見するための手がかりとなる。しかし、せっかく出力されたログも、適切に集約・分析されなければその価値は半減してしまう。

今回取り上げるのは、企業でよく使われるファイアウォールの一種である「FortiGate」から出力されるログが、セキュリティ監視ツールである「Wazuh」のダッシュボードに正確に表示されないという具体的な問題と、その解決策についての話題である。Wazuhは、様々なシステムやデバイスからログを集め、そこからセキュリティ上の脅威や異常を検知・分析するための「SIEM（Security Information and Event Management）」と呼ばれる種類のツールの一つで、システムエンジニアを目指す上では知っておきたい重要なツールである。

この問題のポイントは大きく分けて二つある。一つ目は、FortiGateが「通信拒否」した際のログがWazuhのダッシュボードに表示されないという点だ。本来、通信拒否のログは、外部からの不正なアクセス試行や、内部からの不適切な通信をブロックしたことを示す重要な情報であり、セキュリティ運用上、必ず把握しておくべき内容である。しかし、この重要な情報がWazuhに届いても、デフォルトの状態ではアラートとして表示されないという状況が発生していた。

この問題の背景には、Wazuhがログを処理する際の「レベル」という概念が関わっている。Wazuhでは、受け取ったログに対して事前に定義された「ルール」を適用し、そのルールの重要度に応じて「レベル」を割り当てる仕組みになっている。例えば、管理者のログイン失敗といったイベントには「レベル4」が割り当てられ、これは比較的緊急度の高いイベントとして扱われる。一方、今回のFortiGateの通信ログは、Wazuhの「ルール81618」によって一律に「レベル1」として分類されていた。Wazuhの標準設定では、レベル3未満のログは、たとえシステムに記録されていても、ユーザーが確認できるアラートとしては表示されない仕組みになっている。このため、通信拒否という重要な情報であるにもかかわらず、レベル1と判定されたログはユーザーの目に触れることがなかったのだ。これは、たとえ火事が起こっていても、警報機のサイレンの音量が小さすぎて誰も気づかないような状況に例えることができるだろう。

もう一つの問題は、FortiGateがログを送信する際の「形式」が原因で、ログに含まれる「送信元IPアドレス（srcip）」の情報が壊れてしまうというものだ。FortiGateは通常、「キー=値」という形式でログを出力する。これは、例えば「srcip=192.168.1.1」「action=deny」のように、情報の内容（キー）とその具体的な値がセットになった、読みやすい形式である。しかし、特定の環境で「CSV形式」という、データをカンマ（,）で区切って並べる形式でログを送信するように設定すると、問題が発生する。

Wazuhは、ログを受け取ると、その内容を解析するために「デコーダー」という機能を使用する。このデコーダーは、デフォルトではスペースで区切られた「キー=値」形式のログを正しく読み込むように設計されている。ところが、ログがCSV形式で送られてくると、デコーダーは「srcip」という情報に続いて現れるカンマを区切りと認識せず、次に現れるスペースまでを「srcip」の値として誤って読み込んでしまうのだ。具体的には、「srcip=192.168.1.5,dstip=192.168.1.99,...」というログが送られてきた場合、デコーダーは「srcip」の値として「192.168.1.5,dstip=192.168.1.99」という不正確な情報を抽出してしまう。

このような誤ったIPアドレス情報では、Wazuhが持つ「GeoIP（IPアドレスから地理的な位置情報を特定する機能）」や、「同一送信元からの連続攻撃を検出する機能」、さらには「不正なアクセス元を自動的にブロックするファイアウォール連携機能」などが正しく動作しなくなる。これは、住所が間違っているために宅配便が届かない、という状況とよく似ている。セキュリティ監視において、送信元IPアドレスは攻撃元を特定する上で非常に重要な情報であり、この情報が破損することは、セキュリティ分析の精度を著しく低下させることになる。

これらの問題を解決するために、具体的な対策が二つ提案されている。

一つ目の、通信拒否ログが表示されない問題への対策は、Wazuhのルール設定を変更することである。Wazuhには、既存のルールを変更したり、新しいルールを追加したりするための「ローカルルール」という仕組みがある。このローカルルールファイル（/var/ossec/etc/rules/local_rules.xml）に新しいルール「ID:100210」を追加する。この新しいルールは、既存のルール81618で検出された通信ログのうち、「action="deny"」つまり通信が拒否されたものだけを抽出し、そのログのレベルを「5」に引き上げるというものだ。これにより、Wazuhのデフォルト設定であるレベル3の閾値を超え、通信拒否ログがセキュリティアラートとしてWazuhのダッシュボードに表示されるようになる。この際、ルール内で「action」というフィールドを指定する際には、「<action>deny</action>」という形式を使用することが重要である。「<field name="action">deny</field>」という形式では、Wazuhマネージャーが起動せず、全てのログ監視が停止してしまうという深刻なエラーが発生する可能性があるため、注意が必要だ。

二つ目の、CSV形式によるIPアドレス破損問題への対策は、FortiGate側でのログ送信フォーマット設定を変更することである。具体的には、FortiGateのコマンドラインインターフェース（CLI）を使って、Syslog送信設定のフォーマットを「デフォルト」に戻す。これは、「config log syslogd setting」という設定画面で「set format default」というコマンドを実行することで可能となる。この設定変更により、FortiGateはWazuhのデコーダーが正しく解析できる「キー=値」形式でログを送信するようになるため、送信元IPアドレスなどの情報が破損することなく、正確にWazuhに取り込まれるようになる。

これらの対策を適用することで、FortiGateが拒否した通信のログがWazuhのダッシュボードでレベル5のアラートとして明確に表示されるようになり、破損していた送信元IPアドレスも正確に解析されるようになる。これにより、システム管理者は、どのような不正なアクセスがブロックされたのか、どのIPアドレスから攻撃が試みられたのかといった重要なセキュリティ情報を正確に把握し、迅速な対応を取ることが可能になる。セキュリティ運用において、ログはシステムの「目」や「耳」のようなものであり、そのログが正確に、そして適切な重要度で表示されることは、システムの健全性を保つ上で不可欠である。今回の事例は、システム間の連携において、ログの「形式」や「重要度」の扱いに注意を払うことの重要性を教えてくれる良い教訓だと言えるだろう。