WAF Dojoとは。AWS WAFのルールを書く練習ゲームを小さな会社の目線で整理

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。今回は、GitHubのnishikawaakira/waf-dojoを紹介します。本物の攻撃を受けながら、AWS WAFのルールを書いて練習するゲームです。

私が保存していたブックマークの1つで、README日本語版を読みました。WAFという名前は聞くけれど、自分で設定したことはない。そんな経営者や担当者の目線で整理します。私の過去記事にある、知らないことが穴になる、標準で足りるなら自作しない、確かめることと変えることを分ける、という考えを、WAFのルールの練習に重ねて読みました。

読む順番は、WAFとは何か、練習の舞台、ラボ41問、誤ブロック、運用演習、試す前の3つ、最後にAIエージェントに頼んでよい線です。私はWAF Dojoを動かしていません。作者自身のREADMEの説明として読んでいます。

nishikawaakira/waf-dojo のREADME（ゲームの目的の話）

本物の攻撃を防ぎながら AWS WAF を学ぶ、ハンズオンのトレーニングゲームです。

今回はGitHubのリポジトリ、nishikawaakira/waf-dojoを取り上げます。作者はAkira Nishikawaさんです。私が保存していたブックマークで、README日本語版を読みました。

冒頭の一文は、READMEが自分で言っている紹介です。本物の攻撃を防ぎながらAWS WAFを学ぶ、ハンズオンの練習ゲームということ。WAFは、Webサイトの前に立って、怪しい通信だけを止める門番です。

AWS WAFは、その門番の仕組みのAWS版です。

学びの流れは、順に進む段になっています。1つ目はチュートリアル。これから来る攻撃の中身（リクエスト例）と設定手順が画面に出るので、見ながらWeb ACLを設定します。

Web ACLは、WAFのルールを束ねた物です。

2つ目はゲームモードです。チュートリアルをクリアすると解放されて、攻撃の概要だけが説明されます。防ぐルールは自分で考えます。

3つ目がスコアで、攻撃をどれだけブロックできたかと、一般ユーザーをどれだけ誤ってブロックしたかで採点し、ランキングに出ます。一人でも、複数人でも遊べるそうです。

スコアの式は、100 × 攻撃のブロック率 ×（1 − 誤ブロック率）です。ヒントを見ると0.8倍になります。チュートリアルは各70点以上でクリア、それ以外は各100点満点で、80点以上が「こなした」扱いです。

ここが要だと私は読みます。止めるだけでは満点になりません。普通の人の通信を止めすぎても、点が下がる作りです。誤ブロックは、普通の人の通信を攻撃と見間違えて止めてしまうことです。

動作や効果の説明は、作者自身のREADMEによるものです。私はWAF Dojoを動かしていません。

読みながら思い浮かべたのは、自社のサイトの前に門番は立っているのか、立っているなら誰がルールを決めたのか、という2つです。発注先に聞ける質問かな、と思っています。

nishikawaakira/waf-dojo のREADME（ダミーアプリの話）

どのリクエストにも 200 を返すダミーアプリ。4xx が返ってきたら WAF がブロックしたと判定できます。

READMEによると、練習の舞台はダミーのECサイトです。どのリクエストにも200を返すアプリなので、4xxが返ってきたら、WAFが止めたと判定できます。

構成を順に見ます。ブラウザからLambda Function URL、つまりゲーム画面とAPIにつながります。

trafficgenという攻撃役が、シナリオどおりに攻撃リクエストと一般ユーザーのリクエストを混ぜて、ALBに送ります。ALBは、通信を振り分ける入口です。

結果を採点して、DynamoDBに保存します。

送信先は、Terraformが設定した自分のALBだけです。

攻撃リクエストは、実際の攻撃の形だけを再現した無害なもので、外部の宛先にはattacker.exampleなどの予約ドメインを使うと、READMEは説明しています。

ALBにはWeb ACLを1つしか付けられません。そのため、プレイヤーごとにALBとWeb ACLを1つずつ作ります。人数が増えるほど、用意する物も増える作りです。

もう1つ、JA4の練習があります。JA4は、接続元ソフトの指紋です。

ブラウザ（Chrome、Firefox、Safari）と攻撃ツールで、TLSのClientHelloを作り分けているので、指紋で見分ける練習ができます。

JA4はHTTPSでしか計算されないため、ALBはHTTPS（443）で受けます。

ドメインがなくても動くように、自己署名証明書をACMにインポートしていて、秘密鍵はTerraformのstateに入る、とREADMEは書いています。

CloudFrontの検査上限（既定16KB・最大64KB）を体験するための、プレイヤー専用のCloudFrontとWeb ACLも作られます。

enable_cloudfront = falseで、作らないこともできます。

ここまで作り込む理由は、本番を触らずに、止めることと止めすぎることを両方確かめるためだと、私は読みます。経営者の目線なら、本番の前に練習場がある、という安心感に近いかな、と思います。

nishikawaakira/waf-dojo のREADME（脆弱性対応ラボの話）

新しい脆弱性が出たときに、自分でルールを作れるようになることを目標にしています。

READMEの狙いは、新しい脆弱性が出た時に、自分でWAFのルールを作れるようになることです。脆弱性は、ソフトの弱点のことです。

ラボは、「〜という脆弱性が出ました。こういう条件で防げるようです。ルールを作ってください」という形の問題です。全部で41問あります。

Level 1は、勧告どおりに書く11問です。Log4Shell、Spring4Shell、Shellshockなどが並びます。

Level 2は、勧告をWAFに翻訳する15問で、PHP-CGI（CVE-2024-4577）、Citrix ADC、FortiOSなどです。

Level 3は、防ぎ方の情報なしで、PoCから自分で導く問題。Level 4は、マネージドルールとWAFの限界です。

一度挑戦すると、模範解答のルールJSONと解説が見られます。Level 2・3の多くには、ありがちな失敗ルールとその理由も付くそうです。

身につくこととして、READMEは、攻撃の本質を見抜くこと、検査対象の選び方、正規化、誤検知の回避などを挙げています。誤検知は、正規の通信を攻撃と見間違えることです。

AI氣道『PHPの脆弱性で企業が今日確認する3つと制作会社に聞く5つの質問』より

「知らないこと自体が、いちばん大きな穴になると私は見ています。」

自分のサイトが何で動いているかを知らないことが穴になるという考えを、私は『PHPの脆弱性で企業が今日確認する3つと制作会社に聞く5つの質問』で書いています。

発注先に任せている会社で、私が引っかかるのは、自社のサイトが何で動いているかを、意外と知らないままでいる所なんです。判明した時に、使っている場所を見つけて更新できる状態を、ふだんから作っておく。

自分のサイトの更新の窓口、すぐ言えますか？

WAF Dojoの、勧告を読んでルールにする練習は、その確かめ方を手で覚える練習として読めると、私は考えます。私はこのラボを解いていません。

nishikawaakira/waf-dojo のREADME（誤ブロックと見直しの話）

新しい攻撃を止めるだけでなく、既存ルールの見直しも求められます。

READMEが言う既存ルールの見直しは、前に作ったルールが、後の場面で普通の通信を止めてしまうことへの備えです。

チュートリアルで作ったルールはそのまま残るので、ゲームモードのステージ4・5で、誤ブロックの原因になります。

ゲーム4は、XSSのルールが編集者を止めてしまう場面です。XSSは、Webの入力欄から仕込む攻撃です。例外の作り方、ルールの優先度、既存ルールの見直しが学べます。

ゲーム5は、ログインの総当たりと社内NATが重なる場面で、しきい値の設計がテーマです。社内NATは、同じ接続元から多くの人が来るように見える状況です。

Level 4は、マネージドルールが正規の通信を止めた時に、保護を保ったまま直す問題です。マネージドルールは、AWSなどが用意した既製のルールです。

ルール単位のCount上書きと、ラベル一致で直します。Countは、止めずに数えるだけの設定です。

題材は、Core rule setのSizeRestrictions_BODY、NoUserAgent_HEADER、GenericRFI_QUERYARGUMENTSなどです。

Bodyの検査上限も題材です。8KBの壁（ALBは8KB固定）と、CloudFrontで16KBの壁を64KBまで広げる体験が用意されています。

AI氣道『Lambda×EFS×SQLiteの構成を解説。AWSのサーバー代はEFS代が中心』より

「私なら、EFS で節約する前に、RDS で足りない所がどこかを先に調べます。標準で足りるなら、自作しません。」

標準で足りるなら自作しないという考えを、私は『Lambda×EFS×SQLiteの構成を解説。AWSのサーバー代はEFS代が中心』で書いています。

10月17日、メールと公式の窓口の読者を同じ人にまとめる仕組みを、自作の受け口を含む6つの手順で作り込んでいました。

そのあとツールの公式ヘルプを見たら、メールフォームとサンキューページのボタンだけの標準の手順があったんです。同じ目的に、道が2本ありました。

私の読みです。マネージドルールで足りる所は、自作しない。足りない所を言葉にできたら、そこだけ自分で書く。READMEのLevel 4は、その足りない所を言葉にする練習だと、私は読みます。

nishikawaakira/waf-dojo のREADME（実戦テストの話）

ラボの模範解答を写しただけでは通りません。

READMEの実戦テストは、ラボで学んだ攻撃の、まだ見せていない亜種が来るテストです。ラボの模範解答を写しただけでは通りません。答えの暗記では足りない作りです。

その前に、運用演習が2問あります。本番の運用と同じように、まずCountのルールで偵察します。偵察は採点なしです。そのあと、WAFログを調べてから本番に臨みます。

1問目は、誤検知の犯人探しです。XSS対策のルールに一致してしまう、取引先のメールテンプレート同期を、ログから見つけて例外にします。2問目は、ログからボットを特定せよ。

リスト型攻撃のボットのJA4を、Logs Insightsで/loginへのリクエストを集計して見つけます。JA4は、接続元ソフトの指紋です。

実戦テストは3問です。Log4Shellの変異体、パストラバーサル総まとめ、開けてはいけない扉。攻撃の詳細と模範解答は非公開です。

AI氣道『Tailscaleのセキュリティ確認方法｜初心者が設定を変えずに調べる5項目』より

「確かめることと、変えることは、別の承認として分けておきます。」

確かめることと変えることを別の承認に分ける考えを、私は『Tailscaleのセキュリティ確認方法｜初心者が設定を変えずに調べる5項目』で書いています。

10月28日、Tailscaleの公式ブログの発表を見て、その日のうちにAIに頼んで、自分のMacを確かめました。設定は一つも変えていません。

確かめられたのはMac 1台だけで、ほかの9台は未確認と書いて残しました。9台をたぶん同じだろうで埋めると、どこまで見たのか自分で分からなくなるからです。

確認が終わってから、誰が、どの端末で、何を変えるかを決めて、変えることについて別に承認を取ります。READMEの、Countで偵察してから本番、という順番と同じ向きだと、私は読みます。

nishikawaakira/waf-dojo のREADME（ライセンスの話）

ソースコードは公開していますが、利用に条件があるため、オープンソースライセンスではありません。

ソースコードは公開されているけれど、利用に条件があるのでオープンソースライセンスではない、とREADMEは言います。試す前に読む所を、順に見ます。

まず要件です。必要なものは、Go 1.26以上、Terraform 1.6以上、管理者に近い権限のAWS認証情報です。Terraformは、AWSの環境をコードで作る道具です。

デプロイはmake deployで、テスト、Lambdaのビルド、terraform applyの順に進みます。

READMEは、デプロイ先のAWSアカウントを、aws sts get-caller-identityで必ず確認するよう書いています。

複数人で遊ぶ時は、player_countで人数分のplayer1、player2が作られ、1人につきALBとWeb ACLが1つずつ用意されます。

プレイヤー専用のIAMユーザーは、自分のWeb ACLのルール変更などができて、他のプレイヤーの物は見ることも変えることもできない、IAMポリシーシミュレーターで確認済み、とREADMEは説明しています。

次に費用です。使っていない時もかかるのは、主にALBとAWS WAFです。遊び終わったらmake destroyで片付けます。最新の料金は、AWSの料金ページで確かめるのが確実です。

片付けの注意もあります。Web ACLのルールはTerraformの管理外です。コンソールで足したIPセットや正規表現パターンセットは、手で削除します。

最後にライセンスです。PolyForm Shield License 1.0.0で、個人の学習、企業・団体の社内研修、学校の授業では、自由に利用・改変できます。一方、競合する製品やサービスは不可です。

WAFの研修サービスや学習教材として販売・提供することはできず、お金を取らない提供でも競合にあたるとあります。有料の研修で使いたい時は、作者への相談です。

再配布の時は、ライセンス本文（またはURL）と、Required Notice:の行を一緒に渡します。

私の読みでは、動かす前に、誰の権限で、どこまで費用が発生して、どう片付けるか。この点を先に言えるかが、試すかどうかの分かれ目です。

nishikawaakira/waf-dojo のREADME（片付けの話）

遊び終わったら `make destroy` してください。

推測: ここからは、私の過去記事の考え方を、WAF Dojoの手順に重ねた読みを書きます。

1つ目の線は、読む・書くまでです。READMEの読み込み、手順の要約、費用が発生する場所の洗い出し、片付けの抜け漏れチェックは、AIエージェントに任せてよいと考えます。

コンソールで足したIPセットや正規表現パターンセットのように、手で削除するものの一覧づくりも同じです。ただ、どれを消すかの判断と削除の実行は人です。読むだけ、書くだけの仕事だからです。

2つ目の線は、変える操作です。make deployとmake destroy、管理者に近い権限のAWS認証情報を渡すことは、AIに任せず、人が決めます。確かめることと、変えることは別の承認。

第5章で書いた考え方のままです。

3つ目は、点検結果の読み方です。6月12日、私はAIに、今のシステム環境をフルチェックしてセキュリティを万全にするよう頼んで、使っている道具を点検しました。

パッケージ管理の道具（pnpm）で、脆弱性の警告が34件、深刻度の高いものが2件。更新して再点検すると、0件になりました。

ところが、点検のログに、WordPressのアプリ用パスワードが写っていたんです。漏れた前提で、再発行を最優先の項目に入れました。更新して0件になっても、別の場所に弱点が写っていることがあります。

警告の数だけでは、全部は見えません。

推測: WAFの練習でも同じだと思います。AIが、ルールを書いて100点が出たと報告してきても、その100点は練習場の中の話です。誰の権限で動かして、何が残るかは、人が見ます。

WAF Dojoは、本物の攻撃を受けながらAWS WAFのルールを書く練習ゲームです。READMEによると、チュートリアル、ゲームモード、脆弱性対応ラボ41問、運用演習、実戦テストと進み、採点は攻撃のブロック率と誤ブロック率の両方で決まります。

私の読みです。標準で足りる所、自分で書く所、書いたあとに普通の通信を止めていないか確かめる所。この区別で言えると、WAFのルールの話が見通しやすくなります。

試す前に、誰の権限で、どこまで費用が発生し、どう片付けるかを先に確かめます。今日選べるのは、2つのどちらかです。自社のサイトの前に何が立っているかを、発注先に1つ聞く。試すなら、費用の発生と片付けの手順を先に確かめる。

推測: AIエージェントには、読む・書くまでを頼み、deployとdestroyは人が決める。この線は、私の過去記事の考え方を重ねた読みです。

この記事で学んだことを誰かに教えて恩送りして学びを深めよう！