はじめに
AWS WAFを導入したものの、こんな悩みはないでしょうか。
- 結局どこを見ればいいの？
- ブロックされたけど、それが何の攻撃なのか分からない
AWS WAFが出力するデータの中で、最も基本的かつ重要な指標が 「Allowed（許可）」と「Blocked（ブロック）」 です。そして、Blockedの中身を正しく理解するには、AWS Managed Rulesの各ルールグループが何を検出しているのかを知る必要があります。
本記事では、この2つの軸を中心に深堀りしていきます。
1. Allowed vs Blocked ― まずここを見る
1-1. 確認方法
WAFマネジメントコンソールの 「Traffic Overview」 から、AllowedとBlockedの推移を確認できます。時間範囲でのフィルタリングも可能です。
また、CloudWatchメトリクスとしても取得可能です。AWS WAFは AWS/WAFV2 名前空間で AllowedRequests と BlockedRequests のメトリクスを提供しています（AWS WAF metrics and dimensions）。
AWS公式の「Security Automations for AWS WAF」でも、Allowed vs Blockedはモニタリングダッシュボードの推奨指標として記載されています（Build monitoring dashboard）。
1-2. AllowedとBlockedが意味するもの
| アクション | 意味 |
|---|---|
| Allowed | WAFの全ルールを通過し、バックエンドに到達したリクエスト |
| Blocked | いずれかのルールに合致し、WAFが遮断したリクエスト（403応答） |
ここで重要なのは、Blockedはルールに合致した結果であるという点です。Blockedの件数だけを見ても「何が起きたか」は分かりません。どのルールがブロックしたかを確認して初めて、その意味が分かります。
2. AWS Managed Rulesの深堀り
AWS Managed Rulesは、AWSの脅威研究チームが管理するルールグループの集合です。ルールの追加・更新もAWSが行うため、利用者はルールの定義を自分で書く必要がありません。
以下、公式ドキュメント（AWS Managed Rules rule groups list）に基づいて、主要なルールグループを解説します。
2-1. IP Reputation（IPレピュテーション）ルールグループ
AWSManagedRulesAmazonIpReputationList（WCU: 25）
リクエストの中身ではなく、送信元IPアドレスで判定するルールグループです（IP reputation rule groups）。ボットや攻撃者を入口で遮断する「水際対策」として機能します。
| ルール名 | 概要 | デフォルトアクション |
|---|---|---|
| AWSManagedIPReputationList | 悪意のある活動に積極的に関与しているIPをブロック。AmazonのMadPotなどの脅威インテリジェンスツールから収集 | Block |
| AWSManagedReconnaissanceList | AWSリソースに対する偵察行為を行っているIPをブロック | Block |
| AWSManagedIPDDoSList | DDoS活動に関与しているIPを検出 | Count |
注意点：DDoSルールのデフォルトアクションはBlockではなくCount
AWSの公式ドキュメント「Best Practices for DDoS Resiliency」（AWS WAF – IP reputation）では、このルールが「悪意のあるリクエストフラッドの90%以上をブロックする」と記載されています。しかし、実際にBlockするには明示的なアクションオーバーライドが必要です。
つまり、デフォルトのまま運用している場合、DDoSに関与するIPからのリクエストはBlockedにカウントされず、Allowedとして通過しています。IP Reputationルールのブロック件数を見る際は、この仕様を意識する必要があります。
補足：ラベル（Label）の仕組み
公式ドキュメントには、IP Reputationルールグループが「リクエストにラベルを付与する」という記載があります（Web request labeling）。ラベルとは、ルールがリクエストにマッチしたとき、そのリクエストに付与される一時的なメタデータ（タグのようなもの）です。
ラベルはWeb ACLの評価中だけ存在し、後続のルールに情報を受け渡すために使われます。
リクエスト着信
↓
ルール1（IP Reputation） → マッチ → ラベル付与
↓ ※アクションがCountの場合、評価は続行
ルール2（CRS） → ラベルを参照して判定できる
↓
ルール3（カスタムルール） → ラベルを参照して判定できる
↓
Web ACL評価終了 → ラベル消滅「デフォルトがBlockのルールにラベルは意味があるのか？」と疑問に思うかもしれません。ラベルが活きるのは主に以下の2つの場面です。
- アクションをCountにオーバーライドした場合：WAF導入直後のテスト期間など、意図的にBlockをCountに変更することがあります。この場合リクエストは通過しますが、ラベルが付与されているため、後続のカスタムルールで「IP Reputationに該当した かつ 管理画面（/admin）へのアクセス」のような複合条件でBlockするといった柔軟な制御が可能になります。
- CloudWatchメトリクスでの監視：Blockの場合でもラベルはCloudWatchメトリクスとして記録されるため、どのルールに該当したかの内訳を監視できます。
ラベルはIP Reputationに限らず、AWS Managed Rulesの各ルールグループが付与します。「単一ルールでは実現できない複合的な判定」を可能にする仕組みとして理解しておくと、WAFのチューニング時に役立ちます。
2-2. Baseline（ベースライン）ルールグループ
AWSManagedRulesCommonRuleSet（CRS）（WCU: 700）
OWASP Top 10を含む広範な脆弱性に対する保護を提供する、最も基本的なルールグループです（Baseline rule groups）。
WCU 700と容量が大きい分、検査範囲も広く、「広く浅く」多数の攻撃パターンをカバーします。含まれるルールを攻撃カテゴリ別に分類すると：
| 攻撃カテゴリ | 含まれるルール（例） | 検査対象 |
|---|---|---|
| Bad Bot検出 | UserAgent_BadBots_HEADER | User-Agentヘッダ（nessus, nmap等のスキャナ） |
| サイズ制限 | SizeRestrictions_QUERYSTRING, _BODY, _URIPATH, _Cookie_HEADER | クエリ文字列（2,048B）、ボディ（8KB）、URI（1,024B）、Cookie（10,240B） |
| SSRF（EC2メタデータ） | EC2MetaDataSSRF_BODY, _COOKIE, _URIPATH, _QUERYARGUMENTS | EC2メタデータエンドポイントへの不正アクセス試行 |
| LFI（ローカルファイルインクルージョン） | GenericLFI_QUERYARGUMENTS, _URIPATH, _BODY | ../../ 等のパストラバーサル |
| RFI（リモートファイルインクルージョン） | GenericRFI_QUERYARGUMENTS, _BODY, _URIPATH | http://, ftp:// 等の外部URL埋め込み |
| XSS（クロスサイトスクリプティング） | CrossSiteScripting_COOKIE, _QUERYARGUMENTS, _BODY, _URIPATH | スクリプト実行パターンの検出 |
| 危険な拡張子 | RestrictedExtensions_URIPATH, _QUERYARGUMENTS | .log, .ini 等のシステムファイルへのアクセス |
CRSのブロック件数が多い場合、さまざまな種類の攻撃が混在している可能性があります。内訳を把握するにはWAFログの分析が必要です（後述）。
AWSManagedRulesKnownBadInputsRuleSet（WCU: 200）
既知の重大な脆弱性を突くリクエストパターンをブロックします。
| ルール名 | 対象脆弱性 |
|---|---|
| Log4JRCE_HEADER / _QUERYSTRING / _BODY / _URIPATH | Log4j脆弱性（CVE-2021-44228, CVE-2021-45046, CVE-2021-45105）。${jndi:ldap://...} パターンを検出 |
| JavaDeserializationRCE_HEADER / _BODY / _URIPATH / _QUERYSTRING | Javaデシリアライゼーション攻撃。Spring Core / Cloud Function RCE（CVE-2022-22963, CVE-2022-22965）を含む |
| Host_localhost_HEADER | Hostヘッダに localhost を指定するリクエスト |
| PROPFIND_METHOD | XMLオブジェクト窃取を目的としたPROPFINDメソッド |
| ExploitablePaths_URIPATH | web-inf 等の攻撃対象パスへのアクセス |
Log4jやSpring4Shellは発見から数年が経過していますが、攻撃ツールに組み込まれて今なお継続的に悪用されています。このルールグループのブロック件数がゼロでないことは、インターネット上でこれらの攻撃が依然として行われている証拠です。
2-3. Use-case Specific（ユースケース固有）ルールグループ
AWSManagedRulesSQLiRuleSet（WCU: 200）
SQLデータベースを狙った攻撃パターンを検出します（Use-case specific rule groups）。
| ルール名 | 検査対象 |
|---|---|
| SQLi_QUERYARGUMENTS / SQLi_BODY / SQLi_COOKIE / SQLi_URIPATH | AWS WAF組み込みのSQLインジェクション検出（感度：Low） |
| SQLiExtendedPatterns_QUERYARGUMENTS / _BODY | 上記でカバーされない追加のSQLiパターン |
アプリケーションがSQLデータベースと連携している場合、このルールグループのブロック件数は特に注目すべき指標です。
AWSManagedRulesLinuxRuleSet（WCU: 200）
Linux固有の脆弱性を狙った攻撃を検出します。主にLFI攻撃に対応し、/proc/version のようなOSの機密ファイルへのアクセス試行をブロックします。
AWSManagedRulesUnixRuleSet（POSIXルール）（WCU: 100）
POSIX/Unix系OSを狙ったコマンドインジェクション攻撃を検出します。echo $HOME や echo $PATH のようなシェルコマンド実行の試行をブロックします。
AWSの公式ドキュメントでは、LinuxルールとPOSIXルールは併用が推奨されています：
「You should use this rule group in conjunction with the POSIX operating system rule group.」
2-4. ルールグループの全体像
ここまで解説したルールグループを俯瞰すると、各グループには明確な役割分担があります。
| カテゴリ | ルールグループ | 判定基準 | 主な防御対象 |
|---|---|---|---|
| IP Reputation | AmazonIpReputationList | 送信元IP | 既知の悪意あるIP、偵察、DDoS |
| Baseline | CommonRuleSet（CRS） | リクエスト内容 | OWASP Top 10全般（XSS, LFI, SSRF等） |
| Baseline | KnownBadInputsRuleSet | リクエスト内容 | 既知の重大脆弱性（Log4j, Spring4Shell等） |
| Use-case | SQLiRuleSet | リクエスト内容 | SQLインジェクション |
| Use-case | LinuxRuleSet | リクエスト内容 | Linux固有のLFI |
| Use-case | UnixRuleSet | リクエスト内容 | POSIX コマンドインジェクション |
Blockedの件数を見るとき、どのルールグループがブロックしたかを確認することで、「何の攻撃がどれだけ来ているか」を把握できます。
3. Blockedの急増を検知した場合
Allowed vs Blockedの推移を見ていて、Blockedの急増を検知した場合の深堀り手順を解説します。
※あくまで当方のやり方ですので、ご参考まで
Step 1: ピークの時間帯を絞り込む
マネジメントコンソールの「Action Totals」を「Blocked」でフィルタリングすることができます。
この段階で異常値（例：特定の日付のみBlockedが急増など）を見つけた場合は、次のステップに移行します。
Step 2: どのルールがブロックしたかを特定する
マネジメントコンソールの「Requests terminated by managed rule groups」を各ルールでフィルタリングすることができます。
この方法で「どのルールのブロックが急増しているか」を把握することができます。
- KnownBadInputsRuleSet のブロック急増 → Log4jやJavaデシリアライゼーション攻撃の波
- CommonRuleSet のブロック急増 → XSS・LFI・SSRF等の多様な攻撃
- SQLiRuleSet のブロック急増 → SQLインジェクション攻撃
- AmazonIpReputationList のブロック急増 → 既知の悪意あるIPからの大量リクエスト
前章で解説した各ルールグループの役割を理解していれば、ブロック件数の変動に対して技術的な根拠を持った解釈が可能になります。
ちなみに、そのマネージドルールが特定の期間でどれだけブロックしたのかの確認は、以下コマンドで把握可能です。
例
対象：AWS-AWSManagedRulesCommonRuleSet
期間：2026/02/01~2026/02/28の一か月間
aws cloudwatch get-metric-statistics \
--namespace AWS/WAFV2 \
--metric-name BlockedRequests \
--dimensions \
Name=WebACL,Value=waf-acl \
Name=Region,Value=ap-northeast-1 \
Name=Rule,Value=AWS-AWSManagedRulesCommonRuleSet \
--start-time 2026-02-01T00:00:00Z \
--end-time 2026-03-01T00:00:00Z \
--period 2419200 \
--statistics Sum \
--region ap-northeast-1Step 3: 詳細を確認する（必要な場合）
Step1~2で紹介したようなケースでは、マネージドルールがブロックしているので特に対応は不要です。
リクエストの詳細を確認したい場合は、以下「Sample Request」から確認可能になります。
ただし取得できるサンプルは3時間以内のもにに限るので注意が必要です。
3時間以上前のデータを分析するには、事前にWAFログを有効化しておく必要があります。ログの出力先はCloudWatch Logs / S3 / Data Firehoseから選択でき、Athena等で分析可能です（Logging AWS WAF web ACL traffic）。
Step 4: 正常/異常を判断する
深堀りの結果から、以下のいずれかを判断します。
- 攻撃と判断する場合：送信元IP、アクセス先パス、リクエスト内容を根拠として記録し、WAFが正しくブロックしていることを確認
- 誤検知と判断する場合：該当ルールのチューニング（スコープダウンステートメントの追加やルールアクションのオーバーライド等）を検討
経験談として、「AWS-AWSManagedRulesCommonRuleSet」の「SizeRestrictions_BODY」は緩和されがちかと思います。
このルールは8KBを超えるリクエストボディをブロックします。画像のアップロードが必要なアプリケーションですと正規トラフィックでも余裕で引っかります。
そのため、一時的にこの項目をオーバライドし、新規カスタムルールを作成し、そのルールで新たなサイズ制限をする。といった対応が必要になるかと思います。
まとめ
AWS WAFの分析では、Allowed vs Blockedの推移を起点に、Managed Rulesの各ルールグループが「何を」「なぜ」防御しているかを理解することが重要かと思います。ルールグループの役割を把握していれば、ブロック件数の変動に対して技術的な根拠を持った解釈ができるようになります。