【目次】

  1. 1．はじめに
  2. 2．AWS WAF でアクセスが遮断された際の挙動
  3. 3．Application Load Balancer のアクセスログの形式
  4. 4．検索方法
  5. 5．アクセスログから確認できないこと
  6. 6．おわりに

1．はじめに

今回は AWS WAF での遮断状況を Application Load Balancer のアクセスログで確認する方法を説明していきます。
AWS WAF での遮断状況はログを出力すれば分かるのですが、ログの形式がアクセスログと比べて複雑なため、簡易的に影響のあった IP アドレスや検知数などを確認するのであればアクセスログでも十分です。

2． AWS WAF でアクセスが遮断された際の挙動

AWS WAF で遮断 ( BLOCK ) されると HTTP ステータス 403( Forbidden ) が返却されます。
AWS WAF のアタッチされたリソースが応答するので、 Web サーバ側のアクセスログには残りません。

公式情報
AWS WAF ルールアクション

3． Application Load Balancer のアクセスログの形式

アクセスログの内容の中で、 AWS WAF で遮断 ( BLOCK ) されたことを確認する為に重要な要素は actions_executed フィールドになります。
実行されたアクションが格納されるフィールドで 、 AWS WAF で遮断 ( BLOCK ) された場合、"waf" が最終アクションになります。

例
正常なログ

http 2020-08-12T02:14:17.638988Z app/XXXXXX/XXXXXX YYY.YYY.YYY.YYY:55048 YYY.YYY.YYY.YYY:80 0.013 0.003 0.000 200 200 475 355 "GET http://XXXXXXXXX HTTP/1.1" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.61 Safari/537.36" - - arn:aws:elasticloadbalancing:ap-northeast-1:XXXXXXXXXX:targetgroup/XXXXXXX/XXXXXXXXX "Root=1-5f335079-29e10ae582d659822c5ffab0" "-" "-" 0 2020-08-12T02:14:17.623000Z "waf,forward" "-" "-" "YYY.YYY.YYY.YYY:80" "200" "-" "-"

AWS WAF で遮断されたログ

http 2020-08-12T02:20:56.385481Z app/XXXXXX/XXXXXX YYY.YYY.YYY.YYY:55114 - -1 -1 -1 403 - 485 689 "GET http://XXXXXXXXX HTTP/1.1" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.61 Safari/537.36" - - arn:aws:elasticloadbalancing:ap-northeast-1:XXXXXXXXXX:targetgroup/XXXXXXX/XXXXXXXXX "Root=1-5f335208-f62c4c12b823cb9be8b8a8d8" "-" "-" -1 2020-08-12T02:20:56.331000Z "waf" "-" "-" "-" "-" "-" "-"

公式情報
Access logs for your Application Load Balancer

4．検索方法

２、３の内容から検索するポイントがお分かりいただけたかと思います。
検索時は

  • HTTP ステータスコード 403
  • actions_excuted フィールドに "waf" が現れる

両方の条件を満たすリクエストを探しましょう。
(HTTP ステータスコード 403 以外でも actions_executed フィールドにおいて
"waf" が最終アクションになるケースがあったため)

以下は対象のアクセスログから IP アドレスの個数を確認するクエリの例です。
(※) 403 だけだとステータスコード以外に文字列マッチするので
　　　前後にスペースやハイフンなどつけています。

例

$ grep " 403 - " access.log | grep '"waf"' | awk '{print $4}' | awk '{sub(":.*", "");print $0;}'  | sort | uniq  -c
   1775 XXX.XXX.XXX.XXX
      1 XXX.XXX.XXX.XXX
     48 XXX.XXX.XXX.XXX
      1 XXX.XXX.XXX.XXX
     12 XXX.XXX.XXX.XXX
     72 XXX.XXX.XXX.XXX
      1 XXX.XXX.XXX.XXX
     23 XXX.XXX.XXX.XXX
   1659 XXX.XXX.XXX.XXX

5．アクセスログから確認できないこと

アクセスログ単独では、 403 が AWS WAF で返却された事実しか記録されないため、検知した攻撃の対象のルールを知ることができません。
そのため、誤検知の対策の必要があれば AWS WAF のログで確認しましょう。

また、ルールによっては body 部分を検知対象としていることがありますが、 body 内容はアクセスログに出力されません。
AWS WAF のログでも AWS 独自のルール以外は検知した内容の出力もされない為、ユーザーが実施した対象のリクエストをヒアリングして再現テストをすること COUNT モードに変更して Web サーバ側で POST の内容を出力することなど、別途確認が必要になります。

6．おわりに

簡易的に、 AWS WAF で遮断された事を確認するのであれば Application Load Balancer のアクセスログで判別できることがおわかりいただけたかと思います。
ただし誤検知の対応まで行おうとすると WAF ログの仕組みを理解することも必要となります。
定期的な確認やなるべくリアルタイムでの確認が必要なケースでは Amazon Elasticsearch Service との連携で常時確認できる状態にすることもおすすめです。

Amazon Elasticsearch Service を使用して AWS WAF のログを分析
(本記事は AWS WAF Classic 環境における Amazon Elasticsearch Service との連携例です)

(※) CloudFront や API Gateway でもアクセスログの出力は可能です。
ある程度絞り込むという意味で HTTP ステータスコード 403 かつ CloudFront であれば x-edge-result-type, x-edge-detailed-result-type フィールド、API Gateway であれば context.wafResponseCode フィールドの内容を組み合わせましょう。