【re:invent 2025】AWS WAF の誤検知回避 - カスタムルールのテクニックを学ぶ (NET-301参加レポート)

カミナシでソフトウェアエンジニアをしているいちび(@itiB_S144)です。 12月1日から12月5日にかけて開催されていたAWS re:invent に参加してきました！日本に帰ってきて時差ボケもだいぶ治ってきました。

最終日に参加した以下のセッションについてレポートします。

NET301 Hands-on AWS WAF: Troubleshooting attack scenarios

セッション詳細として記載されていた内容は以下です。

Suspicious of an activity spike? Seeing odd traffic patterns? Introduced a new AWS WAF rule and want to make sure it is operating as it should? Join this session for a walkthrough of a day in the life of a security engineer operating AWS WAF, reviewing dashboards, exploring data in the logs, and building new dashboard widgets to make your life easier. You must bring your laptop to participate.

Type: Builders' session Level: 300 – Advanced

このセッションでは AWS WAF を COUNT モードで透過的に設定したあと、どのように BLOCK モードに移行するかと細かいルールの制御について学びました。多少 AWS WAF のルールのチューニングをしたことがありましたが、ヘルスチェックはブロックせずに透過させる、高価なルールは後回しにする、などいろいろなテクニックを学ぶことができるセッションでした。

なぜこのセッションを受けようと思ったか

AWS WAF のチューニングについては以前 JAWS Festa 2025 にて登壇をさせていただいたことがあります。

speakerdeck.com

この登壇では WAF の誤検知をきっかけにチューニングを試したものの、複雑性が高く継続的にメンテをしていくことが難しく、細かいチューニングに限界があったためアプリケーション側で API のパラメータを変更することで対応をしたという発表をしました。
実際にこのチューニングをするのはどういう時が適切なのか、どう設定するとよさそうかなどの話をしたく本セッションに参加しました。

セッションレポート

本ワークショップでは AWS 環境内にホスティングされた Web サイトに対して COUNT モード(透過)で適用された WAF のマネージドルールである Managed Core Rule が紐づいています。どうやらサイトに対して 5xx エラーを引き起こす通信がかなりの量来ているようです。通信の内容を確認しながら不要な通信をブロックしていくのが本セッションでやることです。

流れ

本ワークショップでは以下の流れで通信を調査し、WAF のルールを調整していきます。しっかりと「ブロックしていいか、してはいけない通信か」調査するステップがワークの中に組み込まれており、実践でも活用できそうです。

通信のログを確認
- Protection Packs (web ACLs) のダッシュボード
  不要なメソッドが叩かれていることをダッシュボードから確認
- CloudWatch Log Insights を用いてログを調査
  Amazon Q に質問しながらログをクエリしました
ブロックする通信を選定し、ルールを決める
AWS WAF にカスタムルールを加え、ブロック

適用したWAFのルール一覧

優先順位	ルール種別	ルール名 (例)	目的・挙動
1	Custom	`label_valid_route53`	Route 53 からの通信を識別し、「検証済み」ラベルを貼る
2	Custom	`rbr_catchall`	同一のユーザーから一定のリクエスト数を越えたアクセスをブロック。ただし 1. のラベルが貼られている通信は除外
3	Managed	`AWS-AWSManagedRulesCommonRuleSet`	マネージドなルールセット
4	Custom	`block_bad_method`	サイト内で利用していない「DELETE」メソッドを一律ブロック

これらのルールの中で特に面白かった「1. label_valid_route53」について紹介します。

WAF のログを見ると User-Agent が Route53 から来ていることがわかる通信がたくさんきています。このサイトでは Route53 のヘルスチェック機能を用いているようです。

一定のリクエスト数を越えたアクセスをブロックする「2. rbr_catchall」というルールを作成しましたが、もしこのルールによって Route53 からのヘルスチェック通信がブロックされてしまうと大きな事故につながりかねません。いまのところブロックされてはいないようですが、ルールを回避できるようにします。

「2. rbr_catchall」が誤ってブロックしないように “ラベル” を貼るカスタムルールを作成します。 WAFのログから Route53 の通信の User-Agent は "Route53HealthCheck" であることがわかっています。しかしながらUser-Agent は簡単に偽装できてしまうため、これだけでルールを作るのはよくなさそうです。なので Route53 のヘルスチェックを飛ばす IP アドレスの範囲から通信がきているかも確認します。

「User-AgentがRoute53HealthCheck」かつ「Route53のIPリストからの通信」にラベルをつけるルールは以下のようになります。

ワークショップではしれっと Route53 のヘルスチェックを行う IP リストが出てきましたが、これはデフォルトで用意されているものではありません。必要な場合は以下の記事を参考に自動でリストを更新する仕組みを作ることで作成できるとのことです。

aws.amazon.com

Route53 のヘルスチェック通信にラベルをつけることができたので以降のルールからこのラベルが貼られている通信を検査から除外することで誤ってヘルスチェックの通信がブロックされることがなくなりました。

もしヘルスチェックがブロックされてしまっていたら… いつの間にか待機系に通信が流れてしまっていたりなどの事故が発生しかねなかったのでこれでひとまず安心です。

思ったこと、まとめ

User-Agent を見ているときにはこれでブロックするのか？？？偽装できるぞ？？？と思いながらワークショップを進めていましたが後々 IP アドレスリストと組み合わせて検査しているのをみて納得できました。
「1つ目のルールで検証してラベルを貼る → 後続のルールでラベルを見て判断する」というパターンは AWS WAF の調整で広く汎用的に使えるテクニックだと改めて実感しました。

Builders Session では講師と一緒のテーブルに座ったメンバーと話しながらセッションを進めていきます。質問があれば適宜できたため自分の WAF の使い方について相談することもできました。
以前私の行った「WAFでの調整をやめてアプリケーション側で対応する」について相談したところ、WAFのマネージドなルールは常にアップデートされていくためアプリケーション側でできるならそのほうがよいよと教えていただくことができ、自分の判断に自信を持つことができました。

おまけ - コスト最適化の観点からルールの順番を考える

ワークショップの中で何度かルールの適用順番を入れ替えたタイミングがありました。
以降のルールで使われる「ラベルをつける」であれば可能な限り早めのルールで適用しておく必要がありますが、rbr_catchall の優先度を上げたときになぜ順番を入れ替えているのか講師の方に伺ったところ「コストを抑えるため」と教わりました。

Bot Control など WAF のルールによってはリクエスト単位における料金が高かったりします。可能な限り高額なルールは後回しにし安いルールで可能な限り通信をブロックして流すといいよとのことです。
ルール毎の料金について意識がなかった自分としては目からウロコでした。
これを受けるとワークショップ内では「4. block_bad_method」のルールがだいぶ後ろに有りましたがこれも上にあげてもよさそうだなと思いました。