【目次】
1. はじめに
2022年5月にAzure WAFではCRS 3.2の一般公開が行われ、ファイアウォールログに出力される内容の詳細についてもCRS 3.1から更新されています。
今回は Azure WAF のファイアウォールログに記載される内容のバージョン間の違いを解説します。
2. ファイアウォールログ とは
ファイアウォールログは、Azure WAF で設定したルールとのマッチ状況が記録されるログです。
Web アプリケーション ファイアウォールが構成された Application Gateway の、検出モードまたは防止モードでログに記録された要求を表示することができます。
ファイアウォールログを有効にする方法については、下記のブログ記事をご参考ください。
Log Analytics を利用して Azure WAF で検知状況を確認する方法
3. ファイアウォールログの全体的な相違点
実際にWAFポリシーにCRS 3.1を適用したApplication Gatewayと、CRS 3.2を適用したApplication Gatewayからそれぞれファイアウォールログを出力し全体を比較したところ、項目に違いがありました。
CRS 3.1に含まれている以下2項目については、CRS 3.2のファイアウォールログには含まれていません。
- clientPort_s
- site_s
代わりに、CRS 3.2では以下の2項目が新しく追加されていました。
- ruleGroup_s
- engine_s
※上記は項目としては存在しますが、検知状況等によって内容の有無が異なる場合があります。
また、上記の他に各項目のデフォルトの並び順も変わっているようです。
4. ファイアウォールログに記載される内容の相違点
各項目に記載される内容についても、CRS 3.1とCRS 3.2の間で異なる部分があります。
※WafCharmをご利用の場合、CRSは無効化されているためカスタムルールに関する内容のみがログに出力される想定です。
CRSの無効化についてはWafCharm Azure 版の利用開始方法について「6. CRS の無効化」をご確認ください。
※各項目の説明については公式ドキュメントをご参考ください。
| 項目 | 3.1 | 3.2 |
|---|---|---|
| Message | ルール名やルールの優先順位が記載されます。 | 403エラーにてブロックされたことと、検知箇所が記載されます。 |
| priority_d | 空欄です。 | 検知したルールの優先順位が記載されます。 |
| ruleSetType_s | OWASP_CRSと記載されます。 | CRSでの検知の場合はOWASP CRS、カスタムルールでの検知の場合はCustomと記載されます。 |
| ruleSetVersion_s | WAFポリシーに適用されているCRSのバージョンが記載されます。 | CRSでの検知の場合はWAFポリシーに適用されているCRSのバージョンが記載され、カスタムルールでの検知の場合は空になります。 |
| ruleId_s | 検知したルールの優先順位が記載されます。 | 検知したルール名が記載されます。 |
| details_message_s | 検知内容の説明が記載されます。 | CRSルールで検知した場合、検知内容の説明が記載されます。 カスタムルールでの検知の場合は空欄です。 |
| details_data_s | 状況により記載の有無は異なりますが、検知内容の説明が記載される場合があります。 | CRSルールで検知した場合、検知箇所の説明が記載されます。 カスタムルールでの検知の場合は空欄です。 |
| details_file_s | ルールが含まれる構成ファイルの名前が記載されます。 | CRSルールで検知した場合、ルールが含まれる構成ファイルの名前が記載されます。 カスタムルールでの検知の場合は空欄です。 |
| details_line_s | イベントをトリガーした、構成ファイル内の行番号が記載されます。 | CRSルールで検知した場合、イベントをトリガーした、構成ファイル内の行番号が記載されます。 カスタムルールでの検知の場合は空欄です。 |
上記の通り、CRS 3.1の場合はMessageに記載される内容からルール名などの情報を確認する必要があります。
そのため、CRS 3.1でルール名ごとに検知状況を確認したい場合などは、クエリにてルール名をMessageからパースする必要があります。
CRS 3.2ではruleId_sにルール名、priority_dに優先順位など個別に情報が記載されるため、確認が容易になりました。
また、Messageには検知箇所が記載されるため、原因調査も行いやすいのではないでしょうか。
さらに、過去にAzure WAF でカスタムルールを Log アクションに変える方法にてファイアウォールログに記載されるaction_sがミスリーディングである点についてもご紹介しましたが、こちらもCRS 3.1とCRS 3.2では以下の通り記載内容に違いがありました。
CRSバージョン 3.1の場合
| カスタムルールのアクション Block |
カスタムルールのアクション Log |
カスタムルールのアクション Allow |
|
|---|---|---|---|
| WAFポリシー 防止モード |
Blocked | Blocked | Allowed |
| WAFポリシー 検知モード |
Detected | Detected | Detected |
CRSバージョン 3.2の場合
| カスタムルールのアクション Block |
カスタムルールのアクション Log |
カスタムルールのアクション Allow |
|
|---|---|---|---|
| WAFポリシー 防止モード |
Blocked | Log | Allowed |
| WAFポリシー 検知モード |
Detected | Log | Detected |
カスタムルールのアクションがLogとなっていれば、WAFポリシーが防止モードの場合でも実際はリクエスト自体は許可され、検知のみが行われる仕組みとなっていますが、CRS 3.1ではその場合でもaction_sに「Blocked」と記載されていました。
ファイアウォールログを参照した際にはリクエストがブロックされているようにも見えるため大変わかりづらかったのですが、CRS 3.2では「Log」と記載されるようになっており、実際のアクションとログに記載されるaction_sが一致しておりわかりやすくなっています。
5．おわりに
Azure WAF でのファイアウォールログに出力される内容のCRSバージョンごとの違いをご紹介しました。
ログを確認する際はぜひご参考ください。
なお、現時点では公式ドキュメント上にファイウォールログに出力される情報の詳細はありませんが、Application Gatewayの初期設定時に同時にWAFポリシーを作成した場合は自動的にCRS 3.2となり、後から当該Application GatewayのWAFポリシーをCRS 3.1のものに切り替えた場合でも、ログに出力される情報はCRS 3.2と同等の内容になるようでした。
ログに出力される情報の構成は、その時点でのWAFポリシーのCRSバージョンではなく、初期設定時のApplication Gatewayに紐づけられたWAFポリシーのCRSバージョンに依存するようです。