Azure WAFのマネージドルール(DRS)の仕組みと動きを見てみる
はじめに
本記事では、Azure WAFのマネージドルールのDRS（デフォルトルールセット）を使った動きを見てみます！
Azure WAFとは
Webアプリを公開する時には、SQLインジェクションやクロスサイトスクリプティング（XSS）などの典型的な攻撃は想定が必要です。
そこで活用できるのがAzure WAF（Web Application Firewall）で、アプリの手前でリクエストを検査し、不正な通信を遮断します。
AzureではApplication GatewayとAzure Front DoorでWAFを簡単に有効化できます。
Azure WAFの2つのルールセット：CRSとDRS
WAFの運用には「どんな通信をブロックするか」という複雑なルールの作成・更新が欠かせませんが、AzureにはMicrosoftが管理・更新するマネージドルールが用意されています。
このルールセットを「オン」にするだけで、既知の攻撃パターンに対する防御が適用され、ルールの継続的なメンテナンス負担を大きく減らせます。
Azure WAFには、大きく分けてCRSとDRSという2つのルールセットが存在します。
-
CRS(Core Rule Set)
オープンソースプロジェクト「OWASP」が提供する業界標準のルールセットです。長年、多くのWAF製品でベースとして採用されてきました。 -
DRS(Default Rule Set)
MicrosoftがCRSをベースに、自社の知見を加えて独自にカスタマイズ・最適化したルールセットです。
現在、Azure WAFではDRSが主流となっており、従来のCRSを置き換えるものであると記載されています。
 |
|---|
DRS（既定のルールセット）の動き
DRS（Default Rule Set）の大きな特徴は、既定の判定方式として異常スコアリング（Anomaly Scoring）を採用している点です。（CRS/の一部バージョンも）
- 異常スコアリングによる誤検知の抑制
「1つのルールに当たったら即ブロック」ではなく、リクエスト内で見つかった複数の疑わしい挙動をスコアとして積み上げ、合計スコアが閾値（既定5点）以上になったときにブロック（Preventionモードの場合）するという動きをします。
単発の軽微なルールの検知だけで止めてしまうケースを減らし、誤検知を抑える工夫になっています。 - HTTPリクエストごとにブロック判定
ブロックの判定はHTTPリクエストごとに独立して行われます。ある通信がブロックされても、次の正常なリクエストには影響を与えません。 - 柔軟なカスタマイズ
特定のルールだけをスコアリングから外し、「Block（即ブロック）」や「Log（記録のみ）」といったアクションへ変更することも可能です。
DRSのスコア
スコアは各ルールの重大度に応じて加算され、ルールのスコアは2〜5で定義されています。
各ルールのスコアは以下のページで確認することができます。
例えば「SQLインジェクション攻撃」はルールIDが942150で、スコアはレベル5（5点）であることが確認できます。
 |
|---|
通信がルールにヒットした場合、ログでスコアを確認することができます。
WAF利用には「特定のSKU」が必要
Azure WAFを有効にするには、各サービスでWAF対応のSKUを選択する必要があります。
- Application Gateway: 「WAF v2」
- Azure Front Door: 「Premium」
- 「Standard」ではカスタムルールのみで、マネージドルールセット（DRS等）はPremiumが必要です。
試してみる
Application GatewayとWAFの展開
Application Gatewayを「WAF v2」で作成し、WAFポリシーを紐付けます。
ポリシーモードは「防止」（Preventionモード）を選択します。
 |
|---|
WAFポリシーは既定のルールセットでDRS2.1を選択します。
 |
|---|
作成されたWAFポリシーを開くと、設定中のポリシーモードが確認できます。
 |
|---|
DRS2.1が適用されていること、各ルールのアクションが異常スコアリング（Anomaly Scoring）になっていることが確認できます。
 |
|---|
WAFルールにヒットするリクエストを送信してみる
今回の環境はVNETにPrivate Application Gatewayを展開しています。
リクエストを送信するVMでは、ホスト名で接続できるように事前に/etc/hostsの設定を行っておきます。
echo '192.168.101.20 poc-appgw.intelnal' | sudo tee -a /etc/hosts
異常スコア2のリクエスト送信
ルールID920320(スコア2)にヒットするHTTPリクエストをcurlで送信してみると、HTTPレスポンスコード200が取得でき、WAFではブロックされません。
$ curl -v \
> -H 'User-Agent:' \
> "http://poc-appgw.intelnal/"
* Host poc-appgw.intelnal:80 was resolved.
* IPv6: (none)
* IPv4: 192.168.101.20
* Trying 192.168.101.20:80...
* Connected to poc-appgw.intelnal (192.168.101.20) port 80
> GET / HTTP/1.1
> Host: poc-appgw.intelnal
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 12 Jan 2026 13:25:49 GMT
< Content-Type: text/html
< Content-Length: 28
< Connection: keep-alive
< Server: nginx/1.24.0 (Ubuntu)
< Last-Modified: Mon, 12 Jan 2026 07:52:44 GMT
< ETag: "6964a84c-1c"
< Accept-Ranges: bytes
<
azpoc-agw-usw-vm-server-001
* Connection #0 to host poc-appgw.intelnal left intact
ルールID920320にヒットしたログが1件出力されています。
Actionは「Matched」で通信はブロックされていません。
 |
|---|
異常スコア3のリクエスト送信
ルールID920350(スコア3)にヒットするHTTPリクエストをcurlで送信してみると、こちらもHTTPレスポンスコード200が取得でき、WAFではブロックされません。
$ curl -v \
> "http://192.168.101.20/"
* Trying 192.168.101.20:80...
* Connected to 192.168.101.20 (192.168.101.20) port 80
> GET / HTTP/1.1
> Host: 192.168.101.20
> User-Agent: curl/8.5.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 12 Jan 2026 13:28:11 GMT
< Content-Type: text/html
< Content-Length: 28
< Connection: keep-alive
< Server: nginx/1.24.0 (Ubuntu)
< Last-Modified: Mon, 12 Jan 2026 07:52:44 GMT
< ETag: "6964a84c-1c"
< Accept-Ranges: bytes
<
azpoc-agw-usw-vm-server-001
* Connection #0 to host 192.168.101.20 left intact
ルールID920350にヒットしたログが1件出力されています。
Actionは「Matched」で通信はブロックされていません。
 |
|---|
異常スコア5のリクエスト送信
先ほどの2件のリクエストで試した2つのルール両方にヒットするHTTPリクエストを送信してみます。
合計スコアが閾値（既定5点）となるので、今度はHTTPレスポンスコード403となり、リクエストがブロックされます。
$ curl -v \
> -H 'User-Agent:' \
> "http://192.168.101.20/"
* Trying 192.168.101.20:80...
* Connected to 192.168.101.20 (192.168.101.20) port 80
> GET / HTTP/1.1
> Host: 192.168.101.20
> Accept: */*
>
< HTTP/1.1 403 Forbidden
< Server: Microsoft-Azure-Application-Gateway/v2
< Date: Mon, 12 Jan 2026 13:33:27 GMT
< Content-Type: text/html
< Content-Length: 179
< Connection: keep-alive
<
<html>
<head><title>403 Forbidden</title></head>
<body>
<center><h1>403 Forbidden</h1></center>
<hr><center>Microsoft-Azure-Application-Gateway/v2</center>
</body>
</html>
* Connection #0 to host 192.168.101.20 left intact
今度は、ログが3件出力されました。
1件目はルールID920320(スコア2)にヒットしたログです。
 |
|---|
2件目はルールID920350(スコア3)にヒットしたログです。
 |
|---|
3件は通信のブロックログです。
Actionが「Blocked」で、Messageが「Inbound Anomaly Score Exceeded (Total Score: 5)」となっており、スコアが閾値に達しているため通信がブロックされたことが確認できます。
 |
|---|
最後に
実際に試してみて、Azure WAFは設定がシンプルで、すぐにルールを適用でき、明らかに怪しいリクエストをブロックすることができました。
実際の運用時にはアノマリーを検知するためのメトリックやログのモニタリング設計を行う必要があります。
新しいバージョンのマネージドルールはリリースされた時のアップグレードは、手動で実施する必要があるのでこの辺りの考慮も必要になってきそうです。
Discussion