AWS WAFによるブロックについて

AWS WAFによるブロックとは、AWS WAFに設定されたルールにWebリクエストが一致し、そのリクエストが保護対象のアプリケーションやWebサイトへ到達する前に遮断されることです。

AWS WAFは、CloudFront、Application Load Balancer、API Gateway、AppSync、Amazon Cognito、App Runner、Verified Access、AWS Amplifyなどの前段に設置して利用できます。

ユーザーやbotから送られたHTTPまたはHTTPSリクエストを検査し、設定された条件に応じて、許可、ブロック、カウント、CAPTCHA、Challengeなどのアクションを実行します。

たとえば、問い合わせフォームにSQLインジェクションのような文字列が含まれていたり、短時間に大量のアクセスが発生したり、匿名プロキシや評判の悪いIPアドレスからアクセスがあったりすると、AWS WAFのルールに一致してブロックされることがあります。

AWS WAFのブロックは、セキュリティ対策として有効です。

一方で、設定内容によっては正規ユーザー、検索エンジンのクローラー、広告審査bot、外部SaaSのWebhookなどを誤ってブロックしてしまうこともあります。

そのため、AWS WAFを運用する際は、単にルールを強くするだけでなく、ログを確認しながら適切にチューニングすることが重要です。

AWS WAFでリクエストが処理される仕組み

Web ACLでリクエストを評価する

AWS WAFでは、保護対象リソースにWeb ACLを関連付けます。

Web ACLとは、どのようなリクエストを許可し、どのようなリクエストをブロックするかを定義するルールセットのようなものです。

Web ACLには複数のルールを設定できます。

各ルールには、リクエストを検査する条件と、その条件に一致した場合のアクションを設定します。

基本的な流れは以下の通りです。

ユーザーまたはbot
  ↓
CloudFront / ALB / API Gateway など
  ↓
AWS WAFのWeb ACL
  ↓
ルール評価
  ↓
Allow / Block / Count / CAPTCHA / Challenge
  ↓
保護対象のアプリケーション

リクエストはWeb ACL内のルールによって評価されます。

AWS WAFでは、ルールはpriorityの小さい順に評価されます。

終端アクションと非終端アクション

AWS WAFのアクションには、評価を終了させるものと、後続ルールの評価を続けるものがあります。

代表的なアクションは以下です。

アクション	種類	内容
Allow	終端アクション	リクエストを許可し、保護対象へ転送する
Block	終端アクション	リクエストをブロックする
Count	非終端アクション	リクエストを記録するが、評価は続行する
CAPTCHA	条件により終端または非終端	CAPTCHAトークンの状態に応じて処理が変わる
Challenge	条件により終端または非終端	Challengeトークンの状態に応じて処理が変わる

Allow または Block に一致した場合、その時点でAWS WAFの評価は終了します。

つまり、あるルールでブロックされたリクエストは、後続のルールでは評価されません。

一方、Count はリクエストを記録するだけで、ブロックも許可も確定しません。

そのため、新しいルールを導入する前の検証や、誤検知の確認によく使われます。

CAPTCHAとChallengeの挙動

AWS WAFには、CAPTCHA と Challenge というアクションもあります。

CAPTCHA は、ユーザーにパズルなどの認証を求めるアクションです。

Challenge は、ブラウザに対してサイレントな検証を行うアクションです。

これらは、リクエストに有効なトークンがあるかどうかによって挙動が変わります。

有効なトークンがある場合は、Count に近い非終端処理として扱われ、後続ルールの評価が続きます。

有効なトークンがない場合は、評価を終了し、CAPTCHAまたはChallengeのレスポンスを返します。

そのため、通常のブラウザユーザーであれば通過できるケースでも、APIクライアント、Webhook、外部bot、ヘッドレスブラウザなどは通過できず、実質的にブロックされたように見えることがあります。

AWS WAFでブロックされる主な原因

AWS Managed Rulesに一致している

AWS WAFでブロックが発生する代表的な原因が、AWS Managed Rulesへの一致です。

AWS Managed Rulesは、AWSが提供するマネージドルールグループです。

一般的なWeb攻撃や不審なリクエストを検知するためのルールがあらかじめ用意されており、Web ACLに追加するだけで利用できます。

代表的なルールグループには、以下のようなものがあります。

ルールグループ	主な検知対象
Core rule set	一般的なWeb攻撃や異常なリクエスト
SQL database	SQLインジェクション系の攻撃
Known bad inputs	既知の危険な入力パターン
Linux / Unix / Windows OS	OSコマンド実行やファイルアクセスを狙う攻撃
Amazon IP reputation list	評判の悪いIPアドレス
Anonymous IP list	VPN、プロキシ、Torなどの匿名アクセス
Bot Control	botらしいアクセス
Account Takeover Prevention	ログイン攻撃や認証情報リスト攻撃

AWS Managed Rulesは便利ですが、サイトの仕様によっては誤検知が起こることがあります。

たとえば、問い合わせフォームにコード断片を入力できるサイト、開発者向けサービス、BtoB向けの技術問い合わせフォームなどでは、ユーザーが入力した文字列がSQLインジェクションやXSSのパターンに似ていると判定される場合があります。

カスタムルールに一致している

AWS WAFでは、独自のカスタムルールを作成できます。

カスタムルールは柔軟に設定できる一方で、条件が厳しすぎると正規アクセスまでブロックしてしまう可能性があります。

よく使われるカスタムルールには、以下のようなものがあります。

ルールの種類	内容
IP制限	特定のIPアドレス以外をブロックする
国制限	特定国以外からのアクセスをブロックする
URI制限	/admin や /wp-login.php などへのアクセスを制限する
User-Agent制限	空のUser-Agentや特定botをブロックする
Headerチェック	特定のヘッダーがないリクエストをブロックする
サイズ制限	リクエストボディやクエリ文字列が大きい場合にブロックする
Rate-based rule	一定時間内に大量アクセスした送信元を制限する

たとえば、管理画面を守る目的で /wp-admin へのアクセスを制限した場合、社内メンバーのIP変更、VPN利用、海外出張などによって正規ユーザーもアクセスできなくなることがあります。

Rate-based ruleで制限されている

Rate-based ruleは、一定期間内のリクエスト数がしきい値を超えた場合に、対象のリクエストをブロックまたは制限するルールです。

DDoS対策、スクレイピング対策、ログイン試行の抑制、APIの過剰利用対策などに使われます。

たとえば、以下のような設定が考えられます。

5分間で2,000リクエストを超えたIPアドレスをブロックする

ただし、現在のAWS WAFでは、Rate-based ruleの評価ウィンドウは固定ではありません。

1分、2分、5分、10分などから選択でき、5分はデフォルトの評価ウィンドウです。

Rate-based ruleでは、正規ユーザーが巻き込まれることもあります。

たとえば、社内ネットワークから複数人が同じサイトにアクセスしている場合、AWS WAFからは同一のグローバルIPアドレスから大量アクセスしているように見えることがあります。

その結果、社内からのアクセスだけが403になることがあります。

また、広告配信直後、テレビ放映後、キャンペーン開始直後などにアクセスが急増した場合、悪意のないアクセスであってもRate-based ruleに一致する可能性があります。

IP reputationやAnonymous IPに一致している

AWS WAFでは、評判の悪いIPアドレスや匿名化されたアクセス元を検知するルールを利用できます。

たとえば、以下のようなアクセス元が対象になる場合があります。

・過去に不正アクセスに使われた可能性のあるIPアドレス
・VPN
・プロキシ
・Tor
・ホスティング事業者のIPアドレス
・匿名化サービス経由のアクセス

このようなルールは、不正アクセスやbot対策として有効です。

一方で、正規ユーザーがVPNや企業プロキシを利用している場合、誤ってブロックされることがあります。

特にBtoBサイトでは、企業ネットワークやセキュリティ製品を経由したアクセスが匿名プロキシのように見えることがあります。

そのため、IP reputation系やAnonymous IP系のルールを使う場合は、ブロックログを確認しながら慎重に調整する必要があります。

Bot Controlに一致している

AWS WAF Bot Controlを利用している場合、botと判定されたリクエストがブロック、カウント、Challengeなどの対象になることがあります。

Bot Controlは、スクレイピング、クレデンシャルスタッフィング、コンテンツ収集、在庫確認botなどの対策に役立ちます。

一方で、以下のような正規のbotや外部サービスが影響を受けることがあります。

・検索エンジンのクローラー
・広告審査bot
・SEOツールのクローラー
・外部監視ツール
・MAツールやCRMの連携bot
・Webhook送信元
・ヘッドレスブラウザを使ったテストツール

特にWebマーケティングに関係するサイトでは、広告審査botや検索エンジンクローラーを誤ってブロックすると、広告審査、クロール、インデックス、LP表示確認などに影響する可能性があります。

AWS WAFでブロックされたときの見え方

403 Forbiddenが返る

AWS WAFでリクエストがブロックされると、多くの場合、ユーザー側には 403 Forbidden として表示されます。

CloudFront経由の場合は、以下のようなメッセージが表示されることがあります。

403 ERROR
The request could not be satisfied.
Request blocked.

また、構成によっては単純に以下のように表示されることもあります。

403 Forbidden

ただし、AWS WAFではカスタムレスポンスを設定できます。

そのため、必ずしも標準の403画面になるとは限りません。

設定によっては、独自のエラーページ、任意のレスポンスヘッダー、別のステータスコードを返すことも可能です。

アプリケーションログに残らないことがある

AWS WAFは、保護対象リソースの前段でリクエストを評価します。

そのため、AWS WAFでブロックされたリクエストは、アプリケーションに到達しません。

結果として、アプリケーション側のアクセスログやエラーログには該当リクエストが残らないことがあります。

たとえば、ユーザーから「フォーム送信時に403が出た」と問い合わせがあったにもかかわらず、アプリケーションログにフォーム送信の記録がない場合は、アプリケーションの手前で止まっている可能性があります。

この場合、CloudFront、ALB、API Gateway、AWS WAFのログを確認する必要があります。

AWS WAFのブロック原因を調査する方法

まずAWS WAFによるブロックか確認する

403エラーが発生したからといって、必ずAWS WAFが原因とは限りません。

403は、アプリケーション側の認可エラー、CloudFrontの設定、S3の権限設定、ALBの設定、API Gatewayの認証設定などでも発生します。

そのため、最初に確認すべきことは、該当リクエストが本当にAWS WAFでブロックされているかどうかです。

確認すべき観点は以下です。

確認項目	内容
発生日時	いつ発生したか
アクセスURL	どのURLで発生したか
HTTPメソッド	GET、POST、PUTなど
アクセス元IP	どのIPアドレスからのアクセスか
User-Agent	ブラウザ、bot、外部ツールの種類
エラー画面	403、Request blockedなどの表示
アプリログ	アプリケーションに到達しているか
WAFログ	同時刻にBLOCKログがあるか

アプリケーションログに記録がなく、AWS WAFログに BLOCK が残っている場合は、AWS WAFで止められている可能性が高くなります。

WAFログを確認する

AWS WAFのブロック原因を調べるうえで、もっとも重要なのがWAFログです。

AWS WAFログには、リクエストの内容、実行されたアクション、最終的に一致したルール、アクセス元IP、URI、クエリ文字列、ヘッダー情報などが記録されます。

ログの出力先としては、CloudWatch Logs、Amazon S3、Amazon Data Firehoseなどを利用できます。

主に確認すべきログ項目は以下です。

ログ項目	確認する内容
timestamp	リクエストが処理された時刻
action	ALLOW、BLOCK、COUNT など
terminatingRuleId	最終的に評価を終了させたルール
terminatingRuleType	ルールの種類
ruleGroupList	一致したルールグループ
httpRequest.clientIp	アクセス元IPアドレス
httpRequest.country	アクセス元の国
httpRequest.uri	アクセス先URI
httpRequest.args	クエリ文字列
httpRequest.httpMethod	HTTPメソッド
httpRequest.headers	User-Agentなどのヘッダー
labels	AWS WAFが付与したラベル
ruleMatchDetails	SQLiやXSSなど一部ルールの一致詳細

特に重要なのは、action と terminatingRuleId です。

action が BLOCK であれば、AWS WAFによってブロックされています。

terminatingRuleId を見ると、どのルールが最終的にリクエストを止めたのかを確認できます。

terminatingRuleIdを確認する

terminatingRuleId は、ブロック原因を調べるうえで非常に重要です。

たとえば、以下のような値が確認できることがあります。

AWSManagedRulesCommonRuleSet
AWSManagedRulesSQLiRuleSet
AWSManagedRulesKnownBadInputsRuleSet
AWSManagedRulesAmazonIpReputationList
AWSManagedRulesAnonymousIpList
AWSManagedRulesBotControlRuleSet
RateLimitRule
CustomBlockRule

それぞれの意味は以下のように考えられます。

terminatingRuleIdの例	想定される原因
CommonRuleSet	一般的なWeb攻撃や異常なリクエスト
SQLiRuleSet	SQLインジェクション風の入力
KnownBadInputs	既知の危険な文字列
IPReputationList	評判の悪いIPアドレス
AnonymousIpList	VPN、プロキシ、Torなど
BotControl	bot判定
RateLimitRule	リクエスト数の超過
CustomBlockRule	独自に作成したカスタムルール

terminatingRuleId が分かれば、原因の大枠を把握できます。

そのうえで、URI、クエリ文字列、POST body、User-Agent、IPアドレス、国、ヘッダーなどを確認し、なぜそのルールに一致したのかを絞り込みます。

ruleMatchDetailsは常に出るわけではない

WAFログには ruleMatchDetails という項目があります。

これは、SQLインジェクションやクロスサイトスクリプティングなど、一部のmatch rule statementにおいて、一致した詳細を確認するための項目です。

ただし、すべてのルールで ruleMatchDetails が出るわけではありません。

そのため、ブロック原因を調べる際は、ruleMatchDetails だけに頼るのではなく、以下を総合的に確認する必要があります。

・action
・terminatingRuleId
・ruleGroupList
・labels
・httpRequest.uri
・httpRequest.args
・httpRequest.headers
・httpRequest.clientIp
・httpRequest.country

よくあるブロック事例と対処法

問い合わせフォームがブロックされる

問い合わせフォームや資料請求フォームでは、自由入力欄の内容がAWS WAFに検知されることがあります。

たとえば、以下のような文字列が入力されると、SQLインジェクションやXSSのように見える場合があります。

<script>
select * from users
union all
../
cmd.exe

開発会社、SaaS企業、BtoBサービス、セキュリティ関連サービスなどでは、ユーザーが技術的な質問やコード断片をフォームに入力することがあります。

その結果、本来は正規の問い合わせであっても、AWS WAFによりブロックされることがあります。

対処法としては、まずWAFログでどのルールに一致したかを確認します。

そのうえで、フォーム全体を無条件に許可するのではなく、対象URI、HTTPメソッド、検査対象、ルールを絞って調整します。

たとえば、以下のような考え方が現実的です。

・/contact のPOSTだけ影響を確認する
・該当Managed RuleをCountにして検証する
・特定のサブルールだけアクションを上書きする
・必要に応じてscope-down statementで対象を絞る
・アプリケーション側の入力検証も併用する

重要なのは、サイト全体でSQLiやXSSのルールを無効化しないことです。

誤検知が起きた箇所だけを最小限の範囲で例外化することが、安全な運用につながります。

WordPress管理画面にログインできない

WordPressサイトでは、以下のようなパスがAWS WAFの制限対象になることがあります。

/wp-login.php
/wp-admin/
/xmlrpc.php

管理画面への不正ログインやブルートフォース攻撃を防ぐ目的で、これらのパスを制限するのは有効です。

しかし、設定によっては正規の管理者もログインできなくなる場合があります。

特に、IP制限、国制限、Rate-based rule、Bot Control、Anonymous IP listなどを組み合わせている場合は注意が必要です。

対処法としては、以下が考えられます。

・管理者の固定IPを許可する
・VPN経由のアクセスに統一する
・/wp-login.php と /wp-admin/ の条件を分ける
・/wp-admin/admin-ajax.php を安易にブロックしない
・xmlrpc.php は必要性を確認したうえで制限する

特に /wp-admin/admin-ajax.php は、管理画面だけでなくフロント側の機能でも使われることがあります。

安易にブロックすると、フォーム、検索、絞り込み、カート機能などに影響する可能性があります。

社内からのアクセスだけ403になる

社内ネットワークからのアクセスだけが403になるケースもあります。

原因としては、以下が考えられます。

・社内のグローバルIPがIP reputation系のルールに一致している
・社内プロキシがAnonymous IPとして扱われている
・複数人のアクセスが同一IPに集約され、Rate-based ruleに一致している
・国判定やIP制限に引っかかっている
・VPN経由のアクセスが想定外の国やIPとして判定されている

この場合、まず社内からアクセスしたときのグローバルIPアドレスを確認します。

次に、WAFログで該当IPの BLOCK ログを探し、どのルールに一致しているかを確認します。

対処法としては、社内IPを許可リストに追加する方法があります。

ただし、全サイトを無条件で許可するのではなく、管理画面や社内利用ページなど、必要な範囲に限定する方が安全です。

広告審査botや検索エンジンクローラーがブロックされる

AWS WAFの設定によっては、広告審査botや検索エンジンクローラーがブロックされることがあります。

Webマーケティングの観点では、この影響は非常に重要です。

広告審査botがLPを確認できない場合、広告審査に落ちたり、リンク先不承認になったりする可能性があります。

検索エンジンのクローラーが継続的にブロックされる場合、クロールやインデックスに影響する可能性もあります。

ただし、User-Agentだけを見て許可するのは危険です。User-Agentは簡単に偽装できるためです。

対策としては、以下のような方法を検討します。

・WAFログで実際にブロックされているbotを確認する
・Search Consoleなど外部ツールのエラーも確認する
・User-AgentだけでなくIPや挙動も確認する
・必要なbotだけを限定的に許可する
・広告LPや重要ページだけ条件を調整する
・Bot Controlのラベルを活用して制御する

APIやWebhookがブロックされる

APIやWebhookもAWS WAFでブロックされることがあります。

WebhookのPOST bodyには、JSON、署名、トークン、URL、特殊文字列などが含まれます。

これらがWAFルールに一致すると、外部サービスからの正規通信であってもブロックされる可能性があります。

また、APIやWebhookは通常のブラウザとは異なり、CAPTCHAやChallengeを通過できません。

そのため、APIパスにCAPTCHAやChallengeを適用すると、正規の外部連携が失敗することがあります。

対処法としては、以下が考えられます。

・Webhook用のパスを明確に分ける
・送信元IPが固定されている場合は許可リストを使う
・Webhook署名をアプリケーション側で検証する
・APIパスではCAPTCHAやChallengeを避ける
・対象URIやHTTPメソッドでscope-downする
・該当Managed Ruleの影響をCountで検証する

WebhookやAPIはビジネス上重要な連携に使われることが多いため、WAFログだけでなく、外部サービス側の送信履歴や失敗ログもあわせて確認すると原因を特定しやすくなります。

AWS WAFのブロックを解除・緩和する方法

Countモードで影響を確認する

誤検知が疑われる場合、いきなりルールを無効化するのではなく、まず Count に変更して影響を確認する方法があります。

Count にすると、リクエストはブロックされませんが、ルールに一致したことはログやメトリクスで確認できます。

新しいManaged Ruleを導入する場合や、既存ルールの影響を調査する場合は、まず Count で様子を見るのが安全です。

ただし、Managed Ruleの場合、AWSが提供するルールそのものを変更するわけではありません。

Web ACL内で、そのルールグループや個別ルールのアクションを上書きする形になります。

Scope-down statementで対象を絞る

Scope-down statementを使うと、ルールの評価対象を絞ることができます。

たとえば、Bot Controlをサイト全体に適用するのではなく、ログインページや会員登録ページだけに適用する、といった設定が可能です。

例としては、以下のような使い方があります。

・/login にだけBot Controlを適用する
・/api/search にだけRate-based ruleを適用する
・POSTリクエストだけ特定ルールの対象にする
・特定の国からのアクセスだけ追加検査する

Scope-down statementを活用すると、セキュリティ対策を維持しながら、誤検知の範囲を抑えやすくなります。

個別ルールのアクションを上書きする

AWS Managed Rulesでは、ルールグループ全体を使いながら、特定の個別ルールだけを Count に変更するなどの調整ができます。

たとえば、以下のような運用が考えられます。

AWSManagedRulesCommonRuleSet 全体は有効にする
ただし、特定のサブルールだけ Count にする

これにより、Managed Rule全体を無効化せず、問題のあるルールだけを調整できます。

誤検知対応では、ルールグループを丸ごと外すよりも、個別ルール単位で調整する方が安全です。

IP allow listを使う

信頼できるアクセス元が明確な場合は、IP allow listを使う方法があります。

たとえば、以下のようなケースでは有効です。

・社内固定IPからの管理画面アクセス
・監視ツールの固定IP
・外部SaaSのWebhook送信元IP
・パートナー企業の固定IP

ただし、IP allow listは慎重に運用する必要があります。

IPアドレスが変更されるとアクセスできなくなる可能性があります。

また、広すぎる範囲を許可すると、WAFの保護を迂回されるリスクがあります。

そのため、IP allow listを使う場合は、対象URLやHTTPメソッドも組み合わせて、許可範囲を最小限にすることが重要です。

カスタムレスポンスを設定する

AWS WAFでブロックされた場合、標準では403が返ることが多いですが、カスタムレスポンスを設定することもできます。

たとえば、以下のような対応が可能です。

・独自のエラーメッセージを表示する
・任意のレスポンスヘッダーを追加する
・別のステータスコードを返す

ただし、セキュリティ上の理由から、ブロック理由を詳しく表示しすぎるのは避けるべきです。

攻撃者に対して、どのルールに引っかかったのか、どの条件を回避すればよいのかを知らせてしまう可能性があるためです。

ユーザー向けには、必要最低限の案内に留めるのがよいでしょう。

AWS WAFを安全にチューニングするポイント

ルールを無効化する前にログを確認する

AWS WAFで誤検知が起きた場合、すぐにWAFを無効化したり、Managed Ruleを丸ごと外したりするのは避けるべきです。

まずはWAFログを確認し、以下を特定します。

・どのリクエストがブロックされたか
・どのIPアドレスからのアクセスか
・どのURIで発生したか
・どのHTTPメソッドか
・どのルールがブロックしたか
・同様のブロックがどれくらい発生しているか
・本当に正規リクエストか

原因が分からないまま設定を緩めると、本来防ぐべき攻撃まで通してしまう可能性があります。

例外設定は最小限にする

AWS WAFのチューニングでは、例外設定をどこまで絞れるかが重要です。

避けたい対応は以下です。

・WAF全体を無効化する
・Managed Ruleグループを丸ごと無効化する
・サイト全体でSQLiやXSSの検査を外す
・広範囲のIPアドレスを許可する
・User-Agentだけで重要botを許可する

望ましい対応は以下です。

・特定URIだけ対象から外す
・特定HTTPメソッドだけ条件を変える
・特定のサブルールだけCountにする
・特定IPからの管理画面アクセスだけ許可する
・Rate-based ruleの対象範囲を限定する
・APIやWebhook用のパスだけ別ルールにする

例外設定は、できるだけ狭く、具体的に作ることが重要です。

本番反映前にCountで検証する

新しいルールを本番環境に導入する場合は、最初から Block にするのではなく、まず Count で影響を確認するのが安全です。

Count にして一定期間ログを確認すれば、どのような正規リクエストがルールに一致するのかを把握できます。

特に以下のような場合は、Countでの検証が有効です。

・新しいManaged Ruleを追加する
・Bot Controlを導入する
・Rate-based ruleを追加する
・国制限を導入する
・フォームやAPIに関係するルールを変更する
・広告キャンペーン前にLPの挙動を確認する

マーケティング影響も確認する

AWS WAFの設定は、セキュリティだけでなくマーケティングにも影響します。

特に以下の領域では注意が必要です。

・広告LP
・SEO
・問い合わせフォーム
・資料請求フォーム
・会員登録フォーム
・決済ページ
・サーバーサイドGTM
・Webhook
・外部計測ツール
・MA / CRM連携

たとえば、フォーム送信がWAFでブロックされている場合、ユーザーは問い合わせを完了できません。

広告LPが広告審査botから見えない場合、広告配信に影響する可能性があります。

検索エンジンのクローラーが継続的にブロックされる場合、クロール状況に影響する可能性があります。

AWS WAFを運用する際は、CloudWatchメトリクスやWAFログだけでなく、Google Search Console、広告管理画面、アクセス解析、フォーム送信数、CVRなどもあわせて確認するとよいでしょう。

AWS WAFのブロック調査で確認すべきチェックリスト

技術面のチェックリスト

AWS WAFでブロックが疑われる場合は、以下を確認します。

□ WAFログは有効になっているか
□ 該当時刻に action = BLOCK のログがあるか
□ terminatingRuleId は何か
□ Managed Ruleによるブロックか、カスタムルールによるブロックか
□ Rate-based ruleに一致していないか
□ CAPTCHA / Challengeの影響ではないか
□ アクセス元IPはどこか
□ アクセス元国はどこか
□ User-Agentは何か
□ URIはどこか
□ GETかPOSTか
□ クエリ文字列やリクエストボディに検知されやすい文字列がないか
□ アプリケーションログに該当リクエストが残っているか
□ CloudFront、ALB、API Gateway側のログと突き合わせたか

運用面のチェックリスト

技術面だけでなく、運用上の影響も確認します。

□ 正規ユーザーがブロックされていないか
□ 社内メンバーがアクセスできるか
□ 広告LPが正常に表示されるか
□ 広告審査botがブロックされていないか
□ 検索エンジンクローラーが継続的にブロックされていないか
□ フォーム送信数やCVRに急な変化がないか
□ Webhookや外部SaaS連携が失敗していないか
□ APIのエラー率が上がっていないか
□ 新しいルール導入後に403が増えていないか
□ 例外設定の範囲が広すぎないか

AWS WAFによるブロック対応の流れ

原因特定から改善までの基本フロー

AWS WAFでブロックが発生した場合は、以下の流れで対応すると安全です。

1. 403エラーの発生状況を確認する
2. AWS WAFによるブロックかどうかを確認する
3. WAFログで action = BLOCK を探す
4. terminatingRuleId を確認する
5. 対象URI、IP、User-Agent、メソッドを確認する
6. 正規リクエストか攻撃リクエストか判断する
7. 誤検知の場合は最小範囲で例外化する
8. 必要に応じてCountで検証する
9. 本番反映後にログとメトリクスを監視する
10. マーケティング指標への影響も確認する

重要なのは、「ブロックされて困っているからWAFを弱める」のではなく、「どのルールが、どのリクエストを、なぜ止めたのか」を確認したうえで調整することです。

避けるべき対応

以下のような対応は避けた方がよいです。

・原因不明のままWAFを無効化する
・Managed Ruleを丸ごと外す
・SQLiやXSSの検査をサイト全体で無効化する
・全IPを許可する
・User-Agentだけを信頼して許可する
・ログを見ずにRate limitのしきい値だけ上げる
・本番でいきなりBlock運用にする

これらの対応は、一時的に問題を解消できる場合がありますが、セキュリティリスクを高める可能性があります。

AWS WAFの調整は、原因を特定し、影響範囲を絞り、必要最小限の例外を作ることが基本です。

まとめ

AWS WAFのブロックはログ確認が重要

AWS WAFによるブロックは、Web ACLに設定されたルールにリクエストが一致し、AWS WAFがそのリクエストを遮断することで発生します。

主な原因は以下です。

・AWS Managed Rulesに一致した
・カスタムルールに一致した
・Rate-based ruleのしきい値を超えた
・IP reputation系のルールに一致した
・Anonymous IP系のルールに一致した
・Bot Controlによりbot判定された
・CAPTCHAまたはChallengeを通過できなかった
・Web ACLのルール順序やデフォルトアクションの影響を受けた

原因を特定するには、WAFログの確認が欠かせません。

特に action、terminatingRuleId、ruleGroupList、labels、httpRequest などを確認することで、どのルールがブロックしたのかを把握できます。

誤検知対応は最小範囲で行う

AWS WAFの誤検知が疑われる場合でも、WAF全体を無効化したり、Managed Ruleを丸ごと外したりするのは避けるべきです。

安全な対応としては、以下のような方法があります。

・Countモードで影響を確認する
・scope-down statementで対象を絞る
・個別ルールのアクションを上書きする
・特定URIやHTTPメソッドに限定して例外化する
・信頼できるIPだけを限定的に許可する
・APIやWebhookにはCAPTCHA / Challengeを適用しない

AWS WAFは、セキュリティを高めるための強力な仕組みです。

しかし、設定が適切でないと、正規ユーザー、広告審査bot、検索エンジンクローラー、外部SaaS連携まで止めてしまう可能性があります。

そのため、AWS WAFを運用する際は、セキュリティ対策とビジネス影響の両方を見ながら、ログに基づいて継続的にチューニングすることが重要です。

以上、AWS WAFによるブロックについてでした。

最後までお読みいただき、ありがとうございました。