AWS WAFのログの見方について

AWS WAFのログは、Webサイトやアプリケーションに届いたリクエストに対して、AWS WAFがどのように判定したかを確認するためのログです。

主に、以下のような場面で使います。

• なぜ特定のアクセスがブロックされたのか知りたい
• 正規ユーザーが403エラーになった原因を調べたい
• 攻撃元IPや攻撃対象URLを確認したい
• AWS Managed Rulesがどのように反応しているか確認したい
• ルールをブロック運用にしてよいか判断したい
• 誤検知が起きていないか確認したい

AWS WAFログを見るときは、すべての項目を最初から細かく読む必要はありません。

まずは、どのリクエストが、どのルールに一致し、最終的に許可・ブロックされたのかを把握することが重要です。

AWS WAFログで最初に見るべき項目

AWS WAFログはJSON形式で出力されます。

項目は多いですが、最初に見るべきポイントはある程度決まっています。

action

action は、AWS WAFがそのリクエストに対して最終的に適用した終端アクションを示します。

主に確認するのは、リクエストが許可されたのか、ブロックされたのかという点です。

代表的なアクションには、以下のようなものがあります。

• ALLOW
• BLOCK
• CAPTCHA
• CHALLENGE

ここで特に重要なのは、BLOCK になっているログです。

BLOCK になっている場合、そのリクエストはAWS WAFによって遮断されています。

そのため、403エラーの調査や誤検知の確認では、まず action を見てブロックされているかどうかを確認します。

ただし、注意点があります。

AWS WAFのルールアクションには COUNT もありますが、Countはリクエストを止める終端アクションではなく、評価を継続する非終端アクションです。

そのため、Count運用中のルールを確認するときは、単純に action だけを見るのではなく、後述する ruleGroupList、nonTerminatingMatchingRules、labels などもあわせて確認する必要があります。

terminatingRuleId

terminatingRuleId は、そのリクエストに対して最終的な判定を行ったルールを示す項目です。

たとえば、あるアクセスがブロックされていた場合、terminatingRuleId を見ることで、どのルールが原因でブロックされたのかを確認できます。

よくある例としては、以下のようなものがあります。

• Web ACLのデフォルトアクション
• 自分で作成したカスタムルール
• AWS Managed Rulesのルールグループ
• レートベースルール
• IP制限ルール
• 地理的一致ルール

ただし、AWS Managed Rulesを使っている場合、terminatingRuleId だけでは詳細な原因が分からないことがあります。

たとえば、AWS Managed RulesのCommon Rule Setに引っかかっていることは分かっても、その中のどの個別ルールに一致したのかまでは、terminatingRuleId だけでは判断しにくい場合があります。

その場合は、ruleGroupList や labels を確認します。

terminatingRuleType

terminatingRuleType は、最終的に判定したルールの種類を示します。

たとえば、通常のルールなのか、マネージドルールグループなのか、レートベースルールなのかを確認できます。

この項目を見ることで、ブロックの原因が自作ルールなのか、AWS Managed Rulesなのかを切り分けやすくなります。

特に誤検知調査では、まず以下のように考えると整理しやすいです。

自作ルールでブロックされている場合は、自分たちの条件設定を見直します。

AWS Managed Rulesでブロックされている場合は、どのマネージドルール内のどの個別ルールが反応したのかをさらに確認します。

httpRequest.clientIp

httpRequest.clientIp は、AWS WAFが認識したクライアントIPアドレスです。

攻撃元IPや、正規ユーザーのアクセス元IPを調べるときに使います。

たとえば、特定のユーザーから「サイトにアクセスできない」「403になる」と問い合わせがあった場合は、そのユーザーのIPアドレスをもとにAWS WAFログを確認します。

また、同じIPから大量にブロックされている場合は、Botや脆弱性スキャンの可能性があります。

ただし、CloudFront、ALB、プロキシ、CDNなどを経由している構成では、アプリケーションログで見えるIPとAWS WAFログの clientIp が一致しない場合があります。

そのため、必要に応じて X-Forwarded-For などのヘッダー情報や、各サービスのアクセスログもあわせて確認することが重要です。

httpRequest.country

httpRequest.country は、アクセス元IPをもとに判定された国コードです。

国別にブロック数を確認したい場合や、特定国からの攻撃が多いかどうかを調べるときに使います。

たとえば、日本国内向けのサイトにもかかわらず、海外から管理画面やログイン画面へのアクセスが大量にある場合は、地理的一致ルールの導入を検討する材料になります。

ただし、国判定はIPアドレスベースです。

VPNやプロキシを使われると、実際の利用者の所在地とは異なる国として見える場合があります。

そのため、国別ブロックは便利ですが、過信しすぎないことが大切です。

httpRequest.uri

httpRequest.uri は、アクセスされたURLのパスを示します。

AWS WAFログを見るうえで非常に重要な項目です。

どのURLが攻撃対象になっているか、どのページで誤検知が発生しているかを確認できます。

特に注意して見るべきパスには、以下のようなものがあります。

• WordPressのログイン画面
• WordPressのxmlrpc.php
• 管理画面
• ログインページ
• APIエンドポイント
• 問い合わせフォーム
• 検索ページ
• .envなどの機密ファイルを狙ったパス
• phpMyAdminなどの管理ツールを探すパス

特定のURLに対して短時間に大量アクセスがある場合、Botやスキャンの可能性があります。

また、正規ユーザーが特定ページで403になる場合は、そのURIでWAFルールが反応していないか確認します。

httpRequest.args

httpRequest.args は、URLのクエリ文字列を示します。

SQLインジェクションやXSSなどの攻撃は、クエリ文字列に不審な文字列が含まれることがあります。

たとえば、検索フォームや絞り込み機能、商品ページ、APIのパラメータなどは攻撃対象になりやすいです。

以下のような文字列が含まれている場合は、攻撃の可能性があります。

• SQL文のような文字列
• scriptタグ
• JavaScriptイベント属性
• ディレクトリトラバーサルのような文字列
• OSコマンドを連想させる文字列
• 認証回避を狙ったような条件式

ただし、正規の入力内容がWAFルールに誤検知されることもあります。

たとえば、問い合わせフォームにHTMLタグや記号を含む文章が入力された場合、XSS対策ルールに引っかかる可能性があります。
また、技術系サイトや管理画面では、SQLやコード断片を正規の入力として扱う場合もあります。

そのため、args を見るときは、攻撃らしいかどうかだけでなく、正規ユーザーの自然な操作かどうかも確認することが重要です。

httpRequest.headers

httpRequest.headers には、リクエストヘッダーが含まれます。

特に見ることが多いのは、User-Agent、Host、Referer、X-Forwarded-For、Content-Type などです。

User-Agentを見ると、Bot、クローラー、スクリプト、脆弱性スキャナーらしきアクセスを判断しやすくなります。

たとえば、curl、python-requests、sqlmap、niktoのようなUser-Agentが大量に出ている場合は、自動化されたアクセスや攻撃ツールの可能性があります。

ただし、User-Agentは簡単に偽装できます。

そのため、User-Agentだけで安全・危険を判断するのではなく、アクセス頻度、URI、IP、国、リクエスト内容などと組み合わせて確認します。

ruleGroupList

ruleGroupList は、ルールグループの評価結果を確認するための項目です。

特にAWS Managed Rulesを使っている場合、この項目が重要です。

AWS Managed Rulesでは、ルールグループ単位でWeb ACLに追加します。

しかし、実際に検知するのは、そのルールグループ内にある個別ルールです。

そのため、ログを見るときは、単に「AWS Managed Rulesに引っかかった」と見るのではなく、どの個別ルールに一致したのかを確認する必要があります。

たとえば、Common Rule Setに引っかかっている場合でも、原因は以下のように異なります。

• リクエストサイズが大きすぎる
• SQLインジェクションらしき文字列がある
• XSSらしき文字列がある
• 不正なヘッダーがある
• 既知の攻撃パターンに一致している

原因が違えば、対応方法も変わります。

そのため、AWS Managed Rulesによるブロックを調べるときは、terminatingRuleId だけでなく ruleGroupList も確認することが重要です。

nonTerminatingMatchingRules

nonTerminatingMatchingRules は、リクエストを終了させなかったものの、一致したルールを確認するための項目です。

たとえば、Countルールに一致した場合などに確認します。

AWS WAFでは、ルールに一致しても必ずそこで評価が終了するわけではありません。

Countのような非終端アクションでは、リクエストを止めずに、後続のルール評価が続きます。

そのため、Count運用中のルールの挙動を確認したい場合は、action だけでなく nonTerminatingMatchingRules も重要です。

labels

labels は、AWS WAFのルールがリクエストに付与したラベル情報です。

AWS Managed Rulesでは、検知内容に応じてラベルが付くことがあります。

ラベルを見ることで、どのカテゴリのルールに反応したのかを把握しやすくなります。

たとえば、以下のような観点で確認できます。

• Common Rule Set系の検知か
• SQLインジェクション系の検知か
• XSS系の検知か
• 既知の悪意ある入力か
• Bot関連の検知か
• 匿名IPやプロキシ関連の検知か

ただし、labels だけで原因を完全に判断できるとは限りません。

実際の調査では、terminatingRuleId、ruleGroupList、httpRequest.uri、httpRequest.args、httpRequest.headers などもあわせて確認します。

AWS WAFログを見る基本的な流れ

AWS WAFログを確認するときは、次の順番で見ると原因を追いやすくなります。

まずブロックされたかどうかを確認する

最初に見るべきなのは、そのリクエストがAWS WAFによってブロックされたかどうかです。

action が BLOCK であれば、AWS WAFがそのリクエストを遮断しています。

正規ユーザーから「403になる」と問い合わせがあった場合、該当時刻付近のログを確認し、そのユーザーのIPやアクセス先URIが BLOCK になっていないかを調べます。

もしWAFログに該当するブロックがなければ、403の原因はAWS WAF以外にある可能性があります。

たとえば、以下のような原因も考えられます。

• CloudFrontの設定
• ALBのルール
• アプリケーション側の認可エラー
• Webサーバーのアクセス制限
• WordPressなどのプラグイン
• S3やCloudFrontの権限設定
• 別のセキュリティ製品

AWS WAFログは重要ですが、403の原因が必ずWAFとは限りません。

どのルールが反応したか確認する

次に、terminatingRuleId を確認します。

ここを見ることで、どのルールが最終的にリクエストをブロックしたのかを確認できます。

自作ルールが原因であれば、そのルールの条件を見直します。

AWS Managed Rulesが原因であれば、さらに ruleGroupList や labels を確認します。

特にマネージドルールの場合、ルールグループ名だけで判断するのは危険です。

必ず、どの個別ルールが反応したのか、どのようなリクエスト内容だったのかを確認します。

リクエスト内容を確認する

ルールが分かったら、次にリクエストの中身を見ます。

特に重要なのは、以下の項目です。

• クライアントIP
• 国
• URI
• クエリ文字列
• HTTPメソッド
• ヘッダー
• User-Agent
• Referer

たとえば、SQLインジェクション系のルールでブロックされている場合は、クエリ文字列やリクエスト本文にSQLのような文字列が含まれていないか確認します。

XSS系のルールでブロックされている場合は、scriptタグやJavaScriptイベント属性のような文字列が含まれていないか確認します。

サイズ制限系のルールでブロックされている場合は、リクエストボディ、Cookie、ヘッダーなどが大きすぎないか確認します。

正常なアクセスか攻撃かを判断する

AWS WAFログを見る目的は、単に「どのルールに引っかかったか」を知ることではありません。

最終的には、そのアクセスが正規のアクセスなのか、攻撃なのかを判断する必要があります。

攻撃の可能性が高い例としては、以下があります。

• 存在しない管理画面を大量に探している
• WordPressではないサイトにwp-login.phpへアクセスしている
• .envやwp-config.phpなど機密ファイルを探している
• SQLインジェクションらしき文字列を送っている
• 短時間に大量のログイン試行をしている
• 複数の脆弱性探索パスにアクセスしている
• User-Agentが攻撃ツールらしい
• 同じIPから大量のブロックが発生している

一方で、誤検知の可能性がある例としては、以下があります。

• 正規ユーザーがフォーム入力時にブロックされた
• 管理画面の更新処理だけがブロックされた
• 特定のAPIリクエストだけがブロックされた
• ファイルアップロード時だけブロックされた
• 長いCookieや大きなリクエストでサイズ制限に引っかかった
• 技術的な文字列を入力するフォームでSQLiやXSS扱いされた

攻撃か誤検知かを判断するには、ログだけでなく、アプリケーションの仕様やユーザーの操作内容も確認することが重要です。

AWS WAFログの出力先ごとの見方

AWS WAFログは、主に以下の出力先に保存できます。

• CloudWatch Logs
• Amazon S3
• Amazon Data Firehose

どこに出力しているかによって、ログの見方や分析方法が変わります。

CloudWatch Logsで見る場合

CloudWatch LogsにAWS WAFログを出力している場合、CloudWatch Logs Insightsを使って検索・分析できます。

CloudWatch Logsは、直近の障害調査や誤検知調査に向いています。

たとえば、以下のような調査に便利です。

• 直近でブロックされたリクエストを確認する
• 特定IPのアクセスを確認する
• 特定URLのブロック状況を確認する
• どのルールでブロックが多いか確認する
• 正規ユーザーの403原因を調べる

CloudWatch Logsを使う場合は、ロググループ名に注意が必要です。

AWS WAFログ用のロググループ名は、通常 aws-waf-logs- で始める必要があります。

また、Web ACLと同じリージョン、同じアカウントにロググループを用意する必要があります。

CloudFront用のWeb ACLはグローバル扱いですが、ログ設定ではリージョンの扱いに注意が必要です。

CloudWatch Logsは即時確認に便利ですが、ログ量が多い場合はコストや検索時間にも注意が必要です。

大量ログを長期保存して分析したい場合は、S3やAthenaの利用も検討します。

Amazon S3で見る場合

S3にAWS WAFログを保存している場合は、長期保存や大量ログ分析に向いています。

S3に保存したログは、Athenaを使ってSQLのように分析できます。

そのため、月次レポート、攻撃傾向分析、国別・IP別・URL別の集計などに適しています。

S3に出力する場合、バケット名は aws-waf-logs- で始める必要があります。

また、原則としてWeb ACLを管理している同じアカウントのS3バケットを使用します。

S3に保存されるログは、一定間隔で出力され、圧縮された形式で保存されます。

そのため、手動で確認する場合は、圧縮ファイルを展開して中身を見る必要があります。

S3保存は、以下のような用途に向いています。

• 長期保管
• Athenaによる分析
• セキュリティレポート作成
• QuickSightなどでの可視化
• SIEMとの連携
• 監査証跡の保管

一方で、リアルタイムに近い調査にはCloudWatch Logsの方が扱いやすい場合があります。

Amazon Data Firehoseで見る場合

Amazon Data Firehoseは、AWS WAFログをS3、外部サービス、SIEMなどへ配送したい場合に使います。

ログをそのまま保存するだけでなく、セキュリティ監視基盤に連携したい場合に便利です。

Data Firehoseを使う場合も、delivery stream名は aws-waf-logs- で始める必要があります。

また、Web ACLと同じアカウント、同じリージョンに作成する必要があります。

CloudFront用のWeb ACLの場合は、Firehoseをus-east-1に作成する必要がある点に注意します。

Data Firehoseを使う場合は、ログ量に対して配送能力が足りているかも確認が必要です。

トラフィックが多いサイトでは、WAFログの量も多くなるため、Firehose側のスループットや配送失敗の有無を監視します。

CloudWatch Logs Insightsでよく確認する内容

CloudWatch Logs Insightsを使う場合、目的に応じて見るべき内容が変わります。

ここではコードは省略し、どのような観点で確認するべきかを整理します。

直近でブロックされたリクエストを確認する

まずは、直近で BLOCK されたリクエストを確認します。

見るべき項目は以下です。

• 時刻
• アクション
• ブロックしたルール
• クライアントIP
• 国
• URI
• クエリ文字列
• ヘッダー
• ラベル

この確認によって、現在どのようなアクセスがWAFに止められているのかを把握できます。

誤検知調査でも、攻撃調査でも、最初はこの確認から始めるのが基本です。

どのルールでブロックが多いか確認する

次に、ルール別のブロック数を確認します。

特定のルールだけブロック数が多い場合、そのルールが攻撃を多く検知している可能性があります。

一方で、誤検知を多く出している可能性もあります。

たとえば、Common Rule Setによるブロックが極端に多い場合は、その中のどの個別ルールが反応しているかをさらに確認します。

ルール別のブロック数を見ることで、優先的に調査すべきルールを判断できます。

攻撃元IPを確認する

IP別にブロック数を確認すると、攻撃元らしきIPを見つけやすくなります。

同じIPから大量にブロックされている場合、以下のような可能性があります。

• Botアクセス
• 脆弱性スキャン
• ブルートフォース攻撃
• スクレイピング
• 不正ログイン試行
• APIへの過剰アクセス

ただし、IPアドレスだけで永久ブロックを判断するのは注意が必要です。

クラウドサービス、VPN、企業プロキシ、モバイル回線などでは、複数ユーザーが同じIPを共有している場合があります。

そのため、IPをブロックする場合は、影響範囲を確認したうえで慎重に行います。

攻撃対象URLを確認する

URI別にブロック数を見ると、どのページやエンドポイントが狙われているか分かります。

特に、以下のようなURLが多い場合は注意が必要です。

• ログインページ
• 管理画面
• APIエンドポイント
• WordPress関連パス
• 設定ファイルを狙ったパス
• データベース管理ツールを探すパス
• 存在しない脆弱性探索パス

攻撃対象URLを把握すると、WAFルールだけでなく、アプリケーション側の対策も検討しやすくなります。

たとえば、ログインページへの攻撃が多い場合は、レート制限、多要素認証、CAPTCHA、IP制限などを検討できます。

国別の傾向を確認する

国別にブロック数を確認すると、どの地域から攻撃が多いかを把握できます。

日本国内向けサイトで海外からの攻撃が多い場合は、地理的一致ルールを検討することがあります。

ただし、国単位でのブロックは慎重に行うべきです。

海外在住の正規ユーザー、海外出張中のユーザー、海外の検索エンジンや監視サービスなどに影響する可能性があります。

そのため、いきなりブロックするのではなく、まずはCountモードで影響を確認するのが安全です。

User-Agentを確認する

User-Agentを見ると、自動化ツールやスキャナーによるアクセスを見つけやすくなります。

ただし、CloudWatch Logsでは httpRequest.headers が配列形式になっているため、User-Agentだけを集計するには少し工夫が必要な場合があります。

手軽に確認する場合は、まずヘッダー全体を表示して目視で確認します。

継続的にUser-Agent別の分析をしたい場合は、S3とAthena、Firehose、Glue、Lambdaなどを使って分析しやすい形に整える方法もあります。

User-Agentは偽装可能なので、それだけで判断するのではなく、IP、URI、アクセス頻度、リクエスト内容と組み合わせて確認します。

誤検知を調べるときの見方

AWS WAFを運用していると、正規ユーザーのアクセスが誤ってブロックされることがあります。

誤検知調査では、攻撃調査とは少し違った視点が必要です。

ユーザーのIPと発生時刻を確認する

まず、正規ユーザーが403になった時刻とアクセス元IPを確認します。

問い合わせ内容にIPアドレスが含まれていない場合は、アプリケーションログ、ALBログ、CloudFrontログなどから該当アクセスを探します。

そのうえで、同じ時刻・同じIPのAWS WAFログを確認します。

該当する BLOCK ログがあれば、AWS WAFが原因の可能性が高くなります。

該当するログがなければ、AWS WAF以外の原因も疑います。

どのルールでブロックされたか確認する

次に、terminatingRuleId、terminatingRuleType、ruleGroupList、labels を確認します。

自作ルールでブロックされている場合は、条件が厳しすぎないか確認します。

AWS Managed Rulesでブロックされている場合は、ルールグループ内の個別ルールを確認します。

たとえば、問い合わせフォームでブロックされている場合、XSS関連ルールやサイズ制限ルールが反応している可能性があります。

APIでブロックされている場合、リクエストボディやヘッダー、Content-Typeなどが原因になっていることがあります。

リクエスト内容が正規の操作か確認する

ログ上では攻撃のように見えても、実際には正規の操作である場合があります。

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

• 問い合わせ内容にHTMLタグが含まれていた
• 技術系フォームにSQL文やコード例が入力された
• 商品検索で特殊文字が使われた
• JSONリクエストの構造がWAFルールに反応した
• Cookieが大きすぎた
• ファイルアップロード時のリクエストがサイズ制限に引っかかった
• 管理画面の更新処理が攻撃パターンに似ていた

誤検知かどうかは、WAFログだけでは判断できない場合があります。

アプリケーションの仕様や、ユーザーが実際に行った操作もあわせて確認します。

いきなりルール全体を無効化しない

誤検知が起きた場合でも、すぐにAWS Managed Rules全体を無効化するのはおすすめできません。

ルール全体を無効化すると、本来防げていた攻撃まで通してしまう可能性があります。

対応としては、次の順番が安全です。

まず、どの個別ルールが原因かを特定します。

次に、そのルールがどのURIや操作で誤検知しているかを確認します。

そのうえで、対象範囲をできるだけ限定して例外を作ります。

たとえば、サイト全体でルールを外すのではなく、特定のフォーム、特定のAPI、特定の管理画面だけ例外化する方が安全です。

また、本番でいきなりブロック解除するのではなく、Countモードで影響を確認する方法もあります。

攻撃調査で見るべきパターン

AWS WAFログでは、攻撃の種類ごとに見るべきポイントがあります。

SQLインジェクションの疑いがある場合

SQLインジェクションの疑いがある場合は、クエリ文字列、リクエストボディ、URI、検知したルールを確認します。

特に、検索ページ、ログインフォーム、商品詳細ページ、APIなどは狙われやすいです。

以下のような特徴がある場合は、SQLインジェクションの可能性があります。

• SQL文のような文字列が含まれている
• 認証回避を狙ったような条件式がある
• データベース名やテーブル名を探るような文字列がある
• 時間差攻撃を狙うような関数名が含まれている
• User-Agentが攻撃ツールらしい
• 同じIPが複数パラメータに攻撃文字列を送っている

SQLインジェクションらしきアクセスがブロックされている場合、WAFが機能している可能性が高いです。

ただし、アプリケーション側でもプレースホルダや入力検証などの基本対策が必要です。

WAFはあくまで防御層の一つであり、アプリケーションの脆弱性対策を代替するものではありません。

XSSの疑いがある場合

XSSの疑いがある場合は、クエリ文字列、フォーム入力、リクエストボディ、ヘッダーなどを確認します。

以下のような特徴がある場合は、XSSの可能性があります。

• scriptタグのような文字列がある
• JavaScriptイベント属性のような文字列がある
• javascriptスキームのような文字列がある
• Cookieを読み取ろうとするような文字列がある
• HTMLタグや特殊文字が不自然に含まれている

ただし、正規ユーザーがHTMLやコードを入力するサービスでは、誤検知も起こりやすくなります。

たとえば、技術系ブログ、CMS、問い合わせフォーム、コード投稿機能、管理画面などでは、XSS対策ルールが正規入力に反応することがあります。

その場合は、対象機能の仕様を確認したうえで、必要に応じて限定的な例外設定を検討します。

WordPress攻撃の疑いがある場合

WordPressサイトでは、AWS WAFログに以下のようなアクセスが多く出ることがあります。

• ログイン画面への大量アクセス
• xmlrpc.phpへのアクセス
• wp-admin配下へのアクセス
• wp-config.phpを狙ったアクセス
• プラグイン脆弱性を探すアクセス
• テーマファイルを探すアクセス

WordPressを使っていないサイトにも、これらのパスへのアクセスが来ることがあります。

これは、Botがインターネット上のサイトを機械的にスキャンしているためです。

WordPressを使っていない場合は、これらのアクセスはほぼ攻撃や探索と考えてよいでしょう。

WordPressを使っている場合は、ログイン画面の保護、xmlrpc.phpの制限、管理画面のIP制限、レート制限、多要素認証なども検討します。

.envや設定ファイル探索の疑いがある場合

.env、設定ファイル、バックアップファイル、管理ツールへのアクセスは、よくある攻撃パターンです。

以下のようなパスへのアクセスが多い場合は、機密情報を探すスキャンの可能性があります。

• .env
• wp-config.php
• config.php
• backup.zip
• database.sql
• phpmyadmin
• adminer
• git関連ファイル

通常、これらのファイルは外部からアクセスできる場所に置くべきではありません。

WAFでブロックすることも重要ですが、そもそもWeb公開ディレクトリに機密ファイルが存在しないか確認することも重要です。

レート制限に引っかかっている場合

レートベースルールを設定している場合、短時間に大量アクセスしたIPがブロックされることがあります。

レート制限に引っかかっている場合は、以下を確認します。

• 同じIPからどれくらいのアクセスがあるか
• どのURIに集中しているか
• ログイン画面やAPIに集中していないか
• 正規ユーザーや監視サービスではないか
• クローラーやBotのアクセスではないか
• 閾値が厳しすぎないか

レート制限はBot対策に有効ですが、閾値が厳しすぎると正規ユーザーや外部サービスまでブロックする可能性があります。

特に、企業プロキシや学校、公共Wi-Fi、モバイル回線などでは、多数のユーザーが同一IPに見える場合があります。

Count運用中のログの見方

AWS WAFでは、新しいルールをいきなりBlockにせず、まずCountで様子を見る運用がよくあります。

Countは、ルールに一致したリクエストを記録しつつ、ブロックはしない設定です。

これにより、以下を事前に確認できます。

• どれくらいのリクエストがルールに一致するか
• 正規ユーザーが影響を受けそうか
• 特定のURIで誤検知が発生していないか
• Blockに変更しても問題なさそうか
• ルールの条件が広すぎないか

ただし、Countは非終端アクションです。

そのため、最終的な action だけを見ても、Countルールに一致したことが分かりにくい場合があります。

Count運用中のログを見るときは、以下の項目を確認します。

• nonTerminatingMatchingRules
• ruleGroupList
• labels
• excludedRules
• overriddenAction
• terminatingRuleId
• httpRequest

特にAWS Managed Rulesの個別ルールをCount overrideしている場合は、ログの見え方に注意が必要です。

単純に「actionがCOUNTかどうか」だけで判断するのではなく、どのルールが非終端で一致したのかを確認することが重要です。

CAPTCHAとChallengeのログの見方

AWS WAFでは、Bot対策としてCAPTCHAやChallengeを使うことがあります。

これらは、通常のBlockとは少し考え方が異なります。

CAPTCHA

CAPTCHAは、ユーザーに画像認証などの操作を求める仕組みです。

リクエストに有効なトークンがない場合、AWS WAFはCAPTCHAを要求します。

有効なトークンがある場合は、評価が継続されることがあります。

そのため、CAPTCHA関連の調査では、単純に action だけでなく、CAPTCHAのレスポンス情報も確認します。

Challenge

Challengeは、ブラウザやクライアントに対して自動的な検証を行う仕組みです。

CAPTCHAよりもユーザー操作を求めにくい形でBot判定を行いたい場合に使われます。

Challengeも、トークンの状態によって評価が終了する場合と継続する場合があります。

確認時の注意点

CAPTCHAやChallengeを使っている場合は、以下を確認します。

• 正規ユーザーに過剰に表示されていないか
• Botらしいアクセスにだけ反応しているか
• トークンが有効な場合に正しく通過しているか
• 重要なページでユーザー体験を悪化させていないか
• APIや非ブラウザクライアントに影響していないか

特にAPIに対してCAPTCHAやChallengeを適用すると、クライアントが正常に処理できない場合があります。

適用範囲には注意が必要です。

AWS Managed Rulesのログを見るときの注意点

AWS Managed Rulesは便利ですが、ログを見るときには少し注意が必要です。

ルールグループ名だけで判断しない

AWS Managed Rulesでは、Web ACLにルールグループを追加します。

しかし、実際にはその中に複数の個別ルールがあります。

そのため、ログでAWS Managed Rulesが原因だと分かっても、それだけでは不十分です。

必ず、どの個別ルールが反応したのかを確認します。

同じCommon Rule Setでも、サイズ制限なのか、XSS系なのか、ヘッダー異常なのかによって対応方法が変わります。

labelsを確認する

AWS Managed Rulesでは、検知内容に応じてラベルが付与されることがあります。

ラベルを見ると、検知カテゴリを把握しやすくなります。

ただし、ラベルだけで完全に判断するのではなく、実際のリクエスト内容も確認します。

たとえば、SQLインジェクション系のラベルが付いていても、正規の入力としてSQL文を扱う画面であれば誤検知の可能性があります。

Count overrideの見え方に注意する

AWS Managed Rulesでは、個別ルールをCountに変更して様子を見ることがあります。

この場合、ログ上ではブロックとは異なる形で記録されるため、action だけを見ていると見落とす可能性があります。

Count overrideを使っている場合は、ruleGroupList、excludedRules、overriddenAction、nonTerminatingMatchingRules、labels などを確認します。

AWS WAFログでよくある調査シナリオ

正規ユーザーが403になる場合

正規ユーザーから「403エラーになる」と連絡があった場合は、まずAWS WAFが原因かどうかを確認します。

確認の流れは以下です。

まず、発生時刻を確認します。

次に、ユーザーのIPアドレスを確認します。

そのうえで、AWS WAFログで同じ時刻・同じIPのアクセスを探します。

該当するログがあり、action が BLOCK であれば、WAFが原因の可能性が高いです。

その後、どのルールでブロックされたかを確認します。

自作ルールなのか、AWS Managed Rulesなのか、レート制限なのかを切り分けます。

最後に、URI、クエリ文字列、ヘッダー、ラベルなどを確認し、攻撃なのか誤検知なのかを判断します。

特定IPから攻撃されているか調べる場合

特定のIPが怪しい場合は、そのIPのログをまとめて確認します。

見るべきポイントは以下です。

• 短時間に大量アクセスしているか
• 複数のURLを機械的に巡回しているか
• ログインページを何度も叩いているか
• SQLiやXSSらしき文字列を送っているか
• 存在しない管理画面を探しているか
• User-AgentがBotや攻撃ツールらしいか
• 国やネットワークが不自然か

ただし、IPだけで判断するのではなく、アクセス内容と頻度をあわせて確認します。

どの攻撃が多いか調べる場合

攻撃傾向を把握したい場合は、以下の観点で集計します。

• ルール別のブロック数
• IP別のブロック数
• 国別のブロック数
• URI別のブロック数
• User-Agent別の傾向
• 時間帯別のブロック数

これにより、どの攻撃が多いのか、どのページが狙われているのか、どの時間帯に攻撃が増えるのかを把握できます。

たとえば、ログインページへのアクセスが多いなら認証周りの強化を検討します。

APIへの大量アクセスが多いならレート制限を検討します。

特定国から明らかに不要なアクセスが多いなら、地理的一致ルールを検討します。

マネージドルールの誤検知を調べる場合

AWS Managed Rulesで誤検知が疑われる場合は、まずどのルールグループが反応しているかを確認します。

次に、その中のどの個別ルールが反応しているかを確認します。

そのうえで、以下を確認します。

• どのURIで発生しているか
• どのパラメータで発生しているか
• 正規ユーザーの操作か
• 管理画面やフォームなど特定機能だけで起きているか
• 攻撃リクエストと見分けられる条件があるか

誤検知対応では、対象範囲を限定することが重要です。

サイト全体でマネージドルールを無効にするのではなく、必要なパスや条件だけ例外化する方が安全です。

AWS WAFログを見るときの注意点

ログを有効化していないと詳細調査できない

AWS WAFのメトリクスだけでも、ブロック数や許可数の概要は確認できます。

しかし、どのIPが、どのURLに、どのようなリクエストを送り、どのルールでブロックされたのかを詳しく知るにはログが必要です。

本番環境では、AWS WAFログを有効化しておくことをおすすめします。

ただし、ログ量が多いとコストも増えるため、保存期間や出力先の設計も重要です。

ログに機密情報が含まれる可能性がある

AWS WAFログには、リクエストのURI、クエリ文字列、ヘッダーなどが含まれます。

サイトやアプリケーションの設計によっては、以下のような情報がログに残る可能性があります。

• メールアドレス
• ユーザーID
• 検索キーワード
• 認証トークン
• セッション情報
• 個人情報を含むパラメータ
• APIキーのような機密情報

そのため、ログの扱いには注意が必要です。

必要に応じて、ログのマスキング設定や、アプリケーション側のパラメータ設計を見直します。

WAFログだけで全体像は分からない

AWS WAFログは非常に重要ですが、WAFログだけですべてを判断できるわけではありません。

調査内容によっては、以下のログもあわせて確認します。

• CloudFrontログ
• ALBアクセスログ
• アプリケーションログ
• Webサーバーログ
• VPC Flow Logs
• CloudTrail
• GuardDuty
• 認証基盤のログ
• CMSやWordPressのログ

たとえば、WAFでは ALLOW になっていても、アプリケーション側で403や500が返っている場合があります。

また、WAFでブロックされる前段や後段で別の制御が働いている場合もあります。

そのため、障害調査やセキュリティ調査では、WAFログを中心にしつつ、必要に応じて他のログも確認します。

AWS WAF Classicとは区別する

AWS WAFには、現行のAWS WAFと、旧世代のAWS WAF Classicがあります。

ログ形式や設定方法が異なる部分があるため、記事や手順書を作成する場合は、どちらを前提にしているかを明記した方が親切です。

現在の環境で新しく運用する場合は、基本的に現行のAWS WAFを前提に考えることが多いです。

AWS WAFログの実務的な見方まとめ

AWS WAFログを見るときは、最初からすべての項目を細かく読む必要はありません。

まずは、以下の流れで確認します。

最初に確認すること

まず、リクエストがブロックされたのか許可されたのかを確認します。

次に、どのルールが判定したのかを確認します。

そのうえで、アクセス元IP、国、URI、クエリ文字列、ヘッダーを見ます。

AWS Managed Rulesが関係している場合は、ruleGroupList や labels を確認します。

Count運用中のルールを見る場合は、action だけでなく、非終端一致の情報も確認します。

誤検知調査で確認すること

誤検知調査では、まずユーザーのIPと発生時刻を確認します。

次に、該当するWAFログを探し、どのルールでブロックされたかを確認します。

その後、リクエスト内容が正規の操作として妥当かどうかを判断します。

誤検知である可能性が高い場合でも、ルール全体を無効化するのではなく、対象URIや対象条件を絞って例外化するのが安全です。

攻撃調査で確認すること

攻撃調査では、IP、URI、国、User-Agent、クエリ文字列、ブロックルールを確認します。

同じIPから大量アクセスがある場合や、存在しない管理画面、設定ファイル、WordPress関連パスを探している場合は、スキャンや攻撃の可能性があります。

SQLインジェクションやXSSのような文字列が含まれる場合も、攻撃の可能性が高いです。

ただし、正規の入力と攻撃文字列が似るケースもあるため、アプリケーション仕様と照らし合わせて判断します。

まとめ

AWS WAFログを見るときに重要なのは、どのリクエストが、どのルールに一致し、どのように処理されたかを順番に確認することです。

特に重要な項目は以下です。

• action
• terminatingRuleId
• terminatingRuleType
• ruleGroupList
• nonTerminatingMatchingRules
• labels
• httpRequest.clientIp
• httpRequest.country
• httpRequest.uri
• httpRequest.args
• httpRequest.headers

AWS WAFログを見る基本的な流れは、以下のとおりです。

まず、action でブロックされたかどうかを確認します。

次に、terminatingRuleId でどのルールが判定したかを確認します。

AWS Managed Rulesの場合は、ruleGroupList や labels で個別ルールや検知カテゴリを確認します。

そのうえで、IP、国、URI、クエリ文字列、ヘッダーを見て、攻撃か誤検知かを判断します。

また、Count、CAPTCHA、Challengeを使っている場合は、通常のBlockとはログの見方が少し変わります。

特にCountは非終端アクションなので、action だけではなく、nonTerminatingMatchingRules や ruleGroupList なども確認する必要があります。

AWS WAFログは、攻撃調査にも誤検知対応にも非常に役立ちます。

ただし、WAFログだけで全体像が分かるとは限りません。

必要に応じて、CloudFrontログ、ALBログ、アプリケーションログ、Webサーバーログなどもあわせて確認することが重要です。

以上、AWS WAFのログの見方についてでした。

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