Azure Front Door WAF が実際の攻撃スキャンを防いだ記録

Azure Front Door Premium と Web Application Firewall（WAF）をどこまで導入するかは、今でも悩みます。個人サイトに対しては大きな固定費ですし、平常時は防御効果が見えにくいからです。

しかし、2026年9月13日、Memolog に対して自動化された脆弱性スキャンが行われました。WAF は危険と判定した 373件をエッジでブロックし、その通信をオリジンへ到達させませんでした。

この記事では、Memolog がどのような構成で通信を防ぎ、通知後に何を調査したのかを振り返ります。また、WAF がなかった場合に考えられた被害を、確認済みの事実と分けて整理します。

目次

• 先に結論
• Memolog の入口を守る構成
• 今回起きたこと
• 観測できた WAF block の日別傾向
• どの WAF ルールが防いだのか
• 通知を受けて調査したこと
• WAF を通過したリクエストと 404
• WAF がなかった場合に考えられた被害
• Azure Monitor と Sentinel の役割
• AFD と WAF をどこまで入れるか
• 今回の経験から改善したいこと
• まとめ
• 参考資料

先に結論

今回の調査で確認できたことは、次のとおりです。

• 単一のパブリック IP アドレスから、秘密ファイル、設定ファイル、既知の脆弱性、コマンド実行経路などを探す自動スキャンが行われた
• Azure Front Door WAF が危険と判定した 373件をブロックした
• そのうち 32件は /api/ を対象としていた
• ブロックされた 373件は、Azure Static Web Apps や Azure Functions のオリジンへ到達していなかった
• WAF に一致しなかった一部のリクエストは後段へ転送されたが、存在しない API は 404 Not Found、静的パスは 404 | Memolog の共通 HTML で終了した
• 秘密情報の取得、意図しないアプリケーション処理、データアクセス、侵害は確認されなかった
• 同じ送信元による WAF block は、確認した 02:45 UTC 以降の時間帯には継続していなかった

WAF がすべてのリクエストを止めたわけではありません。しかし、攻撃パターンに一致した通信をオリジンの手前で止め、危険な処理が実行される機会を減らしました。

今回の一番の学びは、WAF は「導入したから安心」という製品ではなく、アプリケーションの防御と組み合わせて、攻撃が脆弱性へ到達する確率とオリジンの負荷を下げる層だということです。

Memolog の入口を守る構成

Memolog では、公開通信の入口を Azure Front Door Premium に集約しています。静的コンテンツは Azure Static Web Apps、/api/* は Azure Functions へ転送します。

この構成は WAF だけで完結しているわけではありません。Managed Identity、OIDC、Azure Policy、独立した security log、Microsoft Sentinel などを含む取り組み全体は、FinOps と GDPR から始めた Memolog のセキュリティ改善で整理しています。

WAF ポリシーは Detection ではなく Prevention mode です。Microsoft の公式ドキュメントでは、Detection mode は一致した request を記録するだけなのに対し、Prevention mode は設定された action を実行すると説明されています。Block action の場合、WAF 自身が client へ応答し、request を origin へ転送しません。

Memolog では WAF の block response を 429 に設定しています。また、検索 API、公開 read API、公開 write API、status API ごとに rate limit を分けています。

もう 1 つ重要なのが、オリジンの直接アクセス制限です。WAF があっても、攻撃者が Azure Functions の既定 hostname を直接呼べれば Front Door を迂回できます。Memolog の Function App は Azure Front Door の backend service tag と Front Door ID を使って入口を制限し、通常の通信が Front Door を通るようにしています。

今回起きたこと

2026年9月13日 02:38:27〜02:39:14 UTC（日本時間 11:38:27〜11:39:14）の約 47秒間に、単一の送信元から多数の探索 request が届きました。

探索対象には、次のような path が含まれていました。

• .env や cloud credential など、誤って公開されることがある秘密ファイル
• .git や Terraform state など、構成や credential の手掛かりになるファイル
• path traversal や local / remote file inclusion
• Windows / Unix command injection
• SQL injection
• 存在しない command execution API

これは Memolog の実装を理解した上で特定の脆弱性を狙ったというより、インターネット上の Web site に対して既知の path と payload を広く試す、自動化された脆弱性スキャンと考えるのが自然です。

送信元 IP の WHOIS 上の割り当て先は Google LLC でした。ただし、ここから分かるのは Google Cloud 系の network から通信された可能性までです。正規利用者による scan、侵害された VM や container、漏えいした account、proxy などをこちらの log だけで区別することはできません。IP の所有組織と実際の攻撃者を同一視しないことも、調査では重要です。

観測できた WAF block の日別傾向

今回の調査をきっかけに、直近 1 か月の日別傾向も確認しました。ただし、Front Door Access Log と WAF Log が保存されているのは、2026年9月12日 14:29 JST 以降の約 2日分だけでした。9月12日より前を 0件として扱う根拠がないため、グラフには実際に観測できた 2日間だけを示します。

集計では、WAF Log の行数ではなく tracking reference を使って request を一意に数えました。また、GitHub Actions の Hot Topics i18n check が公開 API を全件確認した際の rate limit block 5件は、node User-Agent、対象 path、適用 rule を Access Log と突き合わせて除外しています。

この範囲では、block が発生した日は 1日でした。9月13日の 376件のうち 373件が 11:38 JST ごろの 47秒間に集中し、272種類の path を探索していました。/fetch、/proxy、/.env などが含まれており、少数の URL を繰り返す負荷試験よりも、既知の脆弱な endpoint や秘密 file を広く探す自動スキャンの特徴が強く表れています。

一方で、この 2日間だけでは週次や月次の増減傾向は判断できません。今後も同じ定義で記録を蓄積し、少なくとも 1 か月分の連続した Log が揃ってから、発生日数、request 数、送信元数、探索 path の変化を再評価する必要があります。

どの WAF ルールが防いだのか

今回の block を最終的に実行したのは、Bot Manager ではなく Microsoft Default Rule Set 2.1 の 949110 でした。

949110 は Inbound Anomaly Score Exceeded を示します。これは個別の攻撃 signature ではありません。request が複数の managed rule に一致すると anomaly score が加算され、その合計が block threshold に達したときに最終的な block を実行する rule です。

今回、score の加算に関係した主な検知は次のとおりでした。

1 つの request が複数 rule に一致するため、rule match 数を合計して「攻撃 request 数」とみなすことはできません。今回の 373件は、access log と WAF の最終 block action を基準に数えています。

Bot Manager 1.1 も unknown bot や攻撃 tool の可能性を示す rule に一致していましたが、Memolog では一部を Log action にしています。今回の主な役割は自動通信の分類と記録であり、最終 block の根拠は Default Rule Set の anomaly scoring でした。

通知を受けて調査したこと

最初に届いたのは、Azure Monitor の Severity 1 alert でした。Log Analytics に保存された Front Door WAF log を 5分ごとに確認し、15分間に /api/ の Block が 1件でもあれば発報する設定です。

調査は次の順番で行いました。

1. alert の発火時刻と query を確認する
2. WAF log から action、request URI、client IP、rule、tracking reference を確認する
3. 同じ時間帯の Front Door access log と突き合わせる
4. block 件数、API 対象件数、送信元数、最初と最後の時刻を集計する
5. block された request に origin URL が記録されていないことを確認する
6. WAF を通過した response の status、route、origin URL、response size を確認する
7. 秘密ファイルに見える path の response body が、実データではなく共通 404 HTML であることを確認する
8. Azure Activity Log と Service Health から、同時刻の設定変更や Azure 障害がないことを確認する
9. 02:45 UTC 以降に同じ送信元から block が継続していないことを確認する

調査に使った KQL の考え方を簡略化すると、次のようになります。実際には hostname、時間範囲、tracking reference なども使って request 単位で照合します。

AzureDiagnostics
| where Category == "FrontDoorWebApplicationFirewallLog"
| extend WafAction = tostring(action_s)
| extend RequestUri = tostring(requestUri_s)
| extend RequestPath = tostring(parse_url(RequestUri).Path)
| where WafAction =~ "Block"
| summarize
    BlockedRequests = count(),
    ApiBlockedRequests = countif(RequestPath startswith "/api/"),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated)

最終的に、WAF が block した 373件は origin 到達 0件でした。API を対象にした block は 32件です。同時刻に Front Door や WAF の構成変更はなく、Azure 側の service incident も確認されませんでした。

WAF を通過したリクエストと 404

WAF は「存在しない URL をすべて拒否する装置」ではありません。既知の攻撃 pattern や構成した custom rule に一致しない request は、通常どおり route 判定へ進みます。

今回も、一部の request は WAF を通過しました。その後の動作は、静的 path と API path で異なります。

404 は rate limit ではありません。Memolog では WAF の block response を独自に 429 へ設定しているため、rate limit と今回の managed rule による block はどちらも client からは 429 に見えます。原因を区別するには、WAF log の rule と action を確認する必要があります。存在しない endpoint が返したのは 404 です。

静的 site では、存在しない秘密ファイル風の path に HTTP 200 が記録されたものもありました。status だけを見ると情報漏えいを疑いますが、response body を確認すると、すべて同じ 404 | Memolog の HTML でした。Static Web Apps の fallback によって HTTP status と表示内容が一致していなかったためです。

この経験から、HTTP status だけで侵害や情報漏えいを判断してはいけないことも分かりました。route、origin 到達、content type、response size、実際の body を合わせて確認する必要があります。

WAF がなかった場合に考えられた被害

ここからは、今回実際に起きた被害ではなく反実仮想です。WAF がなかったからといって、必ず侵害されていたわけではありません。

今回 WAF を通過した存在しない API が 404 で終わったように、アプリケーション、framework、hosting platform の検証も防御として機能します。公開物に秘密情報が含まれておらず、脆弱な endpoint も存在しなければ、同じ scan がすべて後段へ届いても侵害には至りません。

それでも、WAF がない場合には次の risk が高まります。

1. 誤公開した秘密情報が取得される

build artifact に .env、credential、source map、repository metadata、Terraform state などが誤って含まれていた場合、単純な HTTP request だけで取得される可能性があります。WAF は誤公開そのものを直しませんが、既知の探索 pattern を edge で遮断する追加防御になります。

2. 未修正の脆弱性へ payload が届く

framework や application に file inclusion、path traversal、command injection、SQL injection などの脆弱性が存在すれば、payload が処理系まで届きます。成功した場合は、file の読み取り、data の改ざん、remote code execution、credential 取得、ほかの resource への横展開につながる可能性があります。

3. API と依存 service の負荷が増える

侵害に失敗しても、すべての request が Functions、Storage、database、外部 API まで到達すれば、実行回数、transaction、telemetry、scale-out が増えます。高コストな検索や集計 endpoint を繰り返し呼ばれると、可用性低下や cloud cost の増加につながります。

4. 攻撃者に追加の情報を与える

404、401、403、500 の違い、header、response body、処理時間などから、存在する endpoint、technology、認証方式、内部 error を推測される場合があります。WAF で既知の攻撃 request を共通 response にできれば、後段の挙動を観測される機会を減らせます。

つまり今回 WAF が減らしたのは、確定した 1 つの被害ではなく、攻撃 payload が脆弱性や高コスト処理へ接触する機会です。防御が成功した事例では「起きなかった被害」を証明できないため、この線引きを保つ必要があります。

Azure Monitor と Sentinel の役割

今回の流れに Microsoft Sentinel は直接参加していません。

Sentinel は WAF の次に自動的に呼ばれる段階ではありません。Analytics Rule を構成し、WAF block の直後に同じ送信元から成功した API request がある、Entra ID や Storage でも異常がある、threat intelligence と一致するといった複数 signal を相関させるときに力を発揮します。

今回のように、WAF が block し、後段の異常や情報漏えいが確認されなかった事象をすべて Sentinel Incident にすると、日常的な internet scan で Incident が増えすぎます。

役割分担は、防御は WAF、運用通知は Azure Monitor、複合的な侵害兆候の相関と Incident 管理は Sentinelと考えると整理しやすくなります。

AFD と WAF をどこまで入れるか

今回の経験だけで、すべての個人 site や小規模 system に Azure Front Door Premium が必要だとは考えていません。費用、守る data、公開 API、origin の防御、運用できる log を合わせて判断する必要があります。

まず SKU の境界として、Azure Front Door Standard でも custom WAF rule と rate limit は利用できます。一方、今回 block した Default Rule Set 2.1 や Bot Manager のような Microsoft managed rule set は Premium の機能です。既知の攻撃 pattern の保守を Microsoft に任せたいかどうかが、Standard と Premium を分ける重要な判断材料になります。

Premium は Standard より固定費が大きいため、静的 site だけを守るために一律で選ぶのではなく、公開 API、認証、扱う data、origin を非公開化する要件と合わせて判断します。価格は変更されるため、検討時点の Azure Front Door の料金と Azure Pricing Calculatorで確認します。SKU の詳しい比較は、Azure Front Door Standard と Premium の違いを整理するにまとめています。

WAF を導入する場合も、最初から強く block すればよいわけではありません。Microsoft は Detection mode で traffic と false positive を確認し、必要な tuning を行ってから Prevention mode にすることを案内しています。

また、次の対策は WAF の有無に関係なく必要です。

• secret や不要な file を deploy artifact に含めない
• server と dependency を更新する
• input validation と authorization を実装する
• origin への直接アクセスを制限する
• Managed Identity と最小権限を使う
• diagnostic settings を有効にし、access / WAF log を保存する
• alert を受けた後の調査手順を用意する

WAF は脆弱性修正の代わりではありません。複数の防御層のうち、internet と application の間で request を落とす層です。

今回の経験から改善したいこと

今回の防御は成功しましたが、監視設定には改善点がありました。

現在の Azure Monitor alert は、15分間に /api/ の WAF block が 1件でもあると Severity 1 になります。internet に公開した service では単発の scan は珍しくないため、block に成功しただけの事象を常に最上位 severity にする設定は過敏です。

今後は、次のように signal を分けるのが妥当だと考えています。

• WAF block 単体は Severity 2 または 3 とし、件数、継続時間、送信元数で threshold を調整する
• WAF を通過した疑わしい 2xx、API の 5xx、latency、Storage failure を高い severity にする
• WAF block と Entra ID、Functions、Storage、threat intelligence の異常が重なった場合に Sentinel Incident を作る
• Static Web Apps の soft 404 を見直し、status と body の意味を一致させる
• tracking reference を軸に WAF log と access log を照合する query を runbook 化する

防御製品の導入だけでなく、通知の精度と調査可能性まで含めて初めて運用できる WAF になると実感しました。

まとめ

Azure Front Door WAF は、Memolog に届いた自動脆弱性スキャンのうち、危険と判定した 373件を edge で block しました。block された通信は origin へ到達せず、後段の API や data access を実行する機会を減らしました。

一方で、WAF を通過した request は application 側の 404 や静的 site の fallback で終了しました。秘密情報流出や侵害は確認されていません。これは WAF だけで守ったのではなく、routing、hosting platform、application、origin 制限を重ねた結果です。

平常時は、WAF の固定費や運用負担だけが目につきます。今回、実際に internet から探索を受けて初めて、攻撃を origin の手前で止めること、止めた記録を残すこと、記録から被害の有無を説明できることに価値があると実感しました。

WAF を入れるか迷ったときは、「攻撃が来るか」ではなく、攻撃 payload が後段まで届いたときに何を失うか、どれだけ負荷がかかるか、あとから調査できるかで判断するのがよさそうです。

参考資料

Microsoft 公式ドキュメント

• Azure Web Application Firewall on Azure Front Door
• Azure Front Door WAF DRS rule groups and rules
• Tune Azure Web Application Firewall for Azure Front Door
• Monitoring data reference for Azure Front Door

Memolog 内の関連記事

• Azure Front Door Standard と Premium の違いを整理する
• FinOps と GDPR から始めた Memolog のセキュリティ改善