Application GatewayでどこまでWEB攻撃を防げるか検証してみた
目次
1. はじめに
2. 対象者
3. Application Gatewayとは
4. DRSとは
5. 検証環境の準備
6. 検証① SQLインジェクション
7. 検証② 不正なUser-Agent
8. 検証③ Web scan
9. まとめ
1. はじめに
こんにちは、iiiです。
「うちのWAF、結局何を防いでくれているんですか？」と聞かれたとき、即答できますでしょうか。
今回は、2026年1〜3月に実際に観測された攻撃の上位3種を取り上げ、Azure Application GatewayのWAF機能で「確実に」防げるのかを、実際にAzure環境を構築して画面付きで検証してみました。
株式会社サイバーセキュリティクラウドが提供するクラウド型WAF「攻撃遮断くん」「WafCharm」の検知データをもとにした2026年1〜3月のレポートによると、この3ヶ月間の攻撃検知数は累計で約7.1億件、1秒あたり平均約90回に達しています。瞬間的には1秒あたり約160回まで跳ね上がることもあり、公開されているWebサービスは常時何らかの攻撃に晒されている状態だと分かります。
攻撃種別の内訳を見ると、上位3つで全体の約67%を占めています。
- 1位：Web scan（脆弱性の探索行為）約46%
- 2位：SQLインジェクション 約11%
- 3位：不正なUser-Agentを用いたアクセス 約10%
出典： Webアプリケーションへのサイバー攻撃検知レポート2026（2026年1月〜3月）｜CyberSecurityTIMES
2. 対象者
本記事は以下のような方を対象にしています。
- WEBシステムを運用している担当者
- Application GatewayのWAF_v2を利用しているが、既定設定で何が防げているのか把握できていない方
- WAFのログ確認やルールのチューニングを担当している方
3. Application Gatewayとは
Azure Application Gatewayは、Webアプリケーション向けのL7（アプリケーション層）ロードバランサーです。Azure Load Balancerと違い、HTTP/HTTPSのリクエスト内容を見て振り分け先を決められるのが特徴です。
主な役割は次の通りです。
- リバースプロキシとしての振る舞い：クライアントからのリクエストを一度受け取り、設定したルールに従ってバックエンドに転送する
- パスベース・ホストベースのルーティング：/api/* は別のバックエンドプールへ、といった振り分けが可能
- SSL/TLS終端：証明書をApplication Gateway側で管理し、バックエンドとの通信を軽量化する
- VNet統合：仮想ネットワーク内に配置され、プライベートなバックエンドに直接到達できる
- オートスケール・ゾーン冗長：v2 SKUではトラフィック量に応じてインスタンス数を自動調整できる
このApplication GatewayにWAF機能を持たせたものが「WAF_v2」SKUです。Standard_v2とWAF_v2は基本性能が同じで、WAF_v2にのみWeb Application Firewallの機能が追加されています。
出典：
Azure Application Gateway v2とは｜Microsoft Learn
4. DRSとは
Application GatewayのWAF_v2には、Microsoftが管理するマネージドルールセットとして「Default Rule Set（DRS）」が用意されています。OWASP（Open Web Application Security Project）が公開しているCore Rule Set（CRS）をベースに、Microsoftが独自の保護ルールを追加したものです。検証時点（2026年8月）のDRS 2.2はOWASP CRS 3.3.4をベースに、SQLインジェクションやXSS、リモートコード実行など18のルールグループで構成されています。複数のルールへの一致度を積み上げて判定する「異常スコアリング」という仕組みを採用しており、単純な文字列一致より精度の高い判定ができます。
出典：
CRS and DRS rule groups and rules｜Microsoft Learn
5. 検証環境の準備
今回構築した検証環境の全体像は次の通りです。検証用クライアントからのリクエストはまずApplication Gatewayで受信され、そのリソース内で関連付けられたWAFポリシーによる検査を受けたうえで、バックエンドVMへルーティングされます。診断ログはLog Analyticsワークスペースに送信し、あとから確認できるようにしています。
図：検証環境の構成図
検証用のリソースグループ・VNetは、既存のものを利用しました。Application Gatewayは/24で専用のサブネットを作成する必要があるので注意が必要です。
バックエンドVMには、動作確認用に「HELLO」という文字列だけを返す簡易コンテンツを配置しています。
5-1 Application Gatewayの作成
手順1. Azure Portalで「Application Gateway」を検索し、「+作成」を選択する。
手順2. 「基本」タブで、アプリケーション ゲートウェイ名、リージョンを入力し、「レベル」で「WAF V2」を選択する。表示された「WAFポリシー」欄で「新規作成」を選択し、ポリシー名を入力して「OK」を選択する。「仮想ネットワークを構成する」で、既存の仮想ネットワークとサブネットを選択する。
手順3. 「フロントエンド」タブで、「フロントエンドIPアドレスの種類」が「パブリック」になっていることを確認し、「パブリックIPアドレス」で「新規追加」を選択して名前を入力する。
手順4. 「バックエンド」タブで「バックエンドプールの追加」を選択し、プール名を入力する。検証用のバックエンドVMをそのまま登録するため、「ターゲットなしでバックエンドプールを追加する」は「いいえ」のままにし、「ターゲットの種類」で「仮想マシン」を選択、「ターゲット」で既存の仮想マシンに関連付けられたネットワークインターフェイスを選択して追加する。
手順5. 「構成」タブの「ルーティング規則」列で「ルーティング規則の追加」を選択し、ルール名と優先順位を入力する。「リスナー」タブでリスナー名とフロントエンドIPを設定し、「バックエンドターゲット」タブでターゲットの種類を「バックエンドプール」にして、手順4で作成したプールと、新規のバックエンド設定を選択して追加する。
手順6. 「確認と作成」→「作成」を選択する。デプロイ完了まで数分待つ。
出典： チュートリアル: Azure portal を使用して Web アプリケーション ファイアウォールのあるアプリケーション ゲートウェイを作成する｜Microsoft Learn
5-2 WAFポリシーの防止モード切り替えとログ設定
WAFポリシーはApplication Gatewayの作成時にすでに作成・関連付け済みのため、ここでは残りの設定だけを行います。作成直後のWAFポリシーは既定で「検出」モード（ブロックせずログにのみ記録するモード）になっているため、今回の検証では「ポリシー設定」から「防止」モードに切り替えました。
また、ブロック結果をあとから確認できるよう、Application Gatewayの「診断設定」ブレードから「診断設定を追加する」を選択し、Log Analyticsワークスペースへ送るよう設定しました。
出典：
Application Gateway の WAF ポリシーを作成する｜Microsoft Learn
出典：
Azure Log Analytics を使用したログの調査｜Microsoft Learn
6. 検証① SQLインジェクション（全体の11%）
WAFポリシー作成時点で、マネージドルールとしてDRS 2.2（Azure マネージド OWASP ルール）が既定で有効になっています。今回はこの既定設定のまま、バックエンドのURLに対してSQLインジェクションの典型的なペイロードを付与したリクエストを送りました。
curl "https://<Application GatewayのパブリックIP>/?id=1' OR '1'='1"
通常のリクエストであればバックエンドVMが返す「HELLO」がそのまま返ってくるはずですが、このリクエストに対しては403 Forbiddenが返り、「HELLO」は返ってきませんでした。Application Gatewayの左メニュー「ログ」から時間範囲を絞り込んでレコードを確認したところ、RequestUri: /?id='1' OR '1'='1のリクエストに対してRuleId: 949110（Inbound Anomaly Score Exceeded、Total Score: 11）が記録され、Action: Blockedとしてバックエンドまで到達していないことを確認しました。
結論：Application Gatewayで防げる。 DRSはSQLインジェクションを主要な対象としており、既定設定を有効にしたまま防止モードに切り替えるだけで対応できることを確認しました。
7. 検証② 不正なUser-Agent（全体の10%）
続いて、既知の攻撃ツール由来のUser-Agentを付与したリクエストを送りました。DRS 2.2の18のルールグループ（SQLI、XSS、RCEなど）には、OWASP CRSにある「Scanner Detection」（既知のスキャナ・攻撃ツールのUser-Agentを検知するルールグループ）は含まれていません。実際にsqlmapのUser-Agentを付与してcurlを送ってみたところ、DRSの既定設定のままではブロックされず、バックエンドの「HELLO」がそのまま返ってくることを確認しました。
ここでカスタムルールを新規作成する前に、既存の管理ルールで対応できないかを確認しました。WAFポリシー作成時に有効化していたBot Manager Rule Setの「UnknownBots」カテゴリには、RuleId 300200「Tools and frameworks for web crawling and attacks」というルールがすでに存在しています。ただし既定のアクションは「ログ」のみで、検知はしていてもブロックはしていませんでした。
そこで、この300200のアクションを「管理されているルール」画面から「ログ」→「ブロック」に変更しました。
設定後、同じUser-Agentを付与したリクエストを再送しました。
curl -A "sqlmap/1.7.2" "https://<Application GatewayのパブリックIP>/"
この場合は「HELLO」は返らず403が返りました。WAFログを確認したところ、RuleSetType: Microsoft_BotManagerRuleSet、RuleId: 300200、Action: Blockedとして、User-AgentのDetailedData（{sqlmap/ found within [REQUEST_HEADERS:User-Agent:sqlmap/1.7.2]}）に一致し、カスタムルールを作成しなくてもリクエストがブロックされていることを確認できました。
結論：Application Gatewayで防げる。 ただし、DRSの既定設定だけでは防げず、Bot Manager Rule Setの該当ルールが既定でログのみの設定になっているため、アクションをブロックへ変更する対応が必要でした。カスタムルールを自作しなくても、既存のルールのアクションを上書きするだけで対応できることを確認しました。
8. 検証③ Web scan（全体の46%、最大シェア）
最もボリュームが大きいカテゴリですが、検証の難易度は一番高くなります。Web scanは攻撃者が無差別に脆弱性の有無を探る行為全般を指します。今回はこのうち、Bot Manager Rule Setの挙動を検証しました。WAFポリシー作成時に「ボット保護の追加」にチェックを入れていたため、Bot Manager Rule SetはDRS 2.2と合わせて既定で有効になっています。
一方、Bot Manager Rule Setは、Microsoftの脅威インテリジェンスフィード（既知の悪性ボット・IPアドレスのリスト）をもとに判定する仕組みで、判定基準そのものは非公開です。そのため、単発のcurlリクエストで「狙って再現する」ことはできませんでした。検証環境を約1日稼働させてログを継続的に確認したところ、RuleSetType: Microsoft_BotManagerRuleSet（バージョン1.1）に一致したレコードが231件記録されており、このうちRuleId: 100100に一致した119件はAction: Blockedとして実際にブロックされていました。一方、Unspecified identityやOther botsなど既知の悪性度が低いボット分類はAction: Matchedのみで、ブロックはされずログに記録されるだけでした。Bot Manager Rule Setは、ボット的なアクセスを一律にブロックするのではなく、脅威インテリジェンスで悪性と判定されたものだけを選んでブロックし、それ以外は可視化にとどめる段階的な仕組みになっていることが確認できました。
結論：既知の悪性ボットは防ぐことができたが、それ以外のボット的アクセスは検知止まりで「確実に」とまでは言い切れない。 脅威インテリジェンスで悪性と判定されたボットはBot Manager Rule Setでブロックできる一方、それ以外の分類のアクセスはログに記録されるだけでブロックされないことを、実機での検証を通じて確認しました。既知の脆弱性パスを狙った探索行為に対するDRSの挙動は、今回は個別に検証していません。
9. まとめ
2026年1〜3月に観測された攻撃のうち、上位3種（SQLインジェクション・不正なUser-Agent・Web scan）で全体の約67%を占めていました。このうちSQLインジェクションは、Application GatewayのDRS 2.2を有効にして防止モードに切り替えるだけで防げる一方、不正なUser-Agentへの対策はDRSの標準設定だけではカバーされておらず、既存ルールのアクションをブロックへ変更することで防げることが確認できました。最もボリュームの大きいWeb scanについては、今回検証できたのはBot Manager Rule Setの挙動のみで、脅威インテリジェンスで悪性と判定されたボットは防げる一方、それ以外のボット的アクセスやDRSによる脆弱性パス探索への対応は今回の検証範囲外です。
WAFは「設定すれば終わり」ではなく、ログを見ながら育てていくものだと、あらためて実感した検証でした。
