WAF に頼りすぎない
 AWS WAF 運用術
 
 市川悠人 @ テックタッチ株式会社 
 Meguro Sec #1 2025/02/07


自己紹介
 名前：市川悠人/izzii
 所属：テックタッチ株式会社
 職種：セキュリティ、SRE
 趣味：登山！ボルダリング！
 X: ahneahneahne


自己紹介
 大学院：ゲノムインフォマティクス
 仕事１：ERP の AI エンジニア
 仕事２：WAF の事業部長 
 仕事３：DAP の SRE
 
 文字列をいじる仕事をしてきてる？
 WAF の提供側の経験があります！ 


テックタッチ株式会社の紹介
 プログラミング不要でブラウザで動くあらゆるサービスの UX の拡張が行える
 DAP (Digital Adaptation Platform) サービスを提供しています。
 


テックタッチ株式会社の紹介


WAF に頼りすぎない。と言っておきながら
 ２重で使ってます！
 App ALB Fargate AWS WAF … agent WAF

WAF に頼りすぎるって何？
 
 攻撃の見極め 攻撃のハンドリング 両方を WAF に依存しすぎている状態

WAF に頼りすぎるって何？
 
 攻撃の見極め 攻撃のハンドリング 両方を WAF に依存しすぎている状態 WAF の運用を難しくしている

WAF に頼りすぎてしまうのはなぜ？
 
 WAF の外側と内側について、
 知らない || コントロールできないことが原因
 AWS WAF アプリケーション インターネット

WAF に頼りすぎてしまうのはなぜ？
 
 WAF の内側をコントロールできるなら、 
 頼りすぎなくて済む。 
 AWS WAF インターネット App Fargate

WAFに頼りすぎない運用とは


攻撃者にとってヒントが少ないのはベター
 しかし分業的ソフトウェア開発では外形的なヒントが一切ないのは非効率
 攻撃に対してどのレスポンスを返す？


200 OK
 400 Bad Request
 403 Not Allowed
 etc.
 404 Not Found
 500 Internal Server Error 
 無視している？悪用成功した？
 ナイスブロック！
 ナイスブロック？それともDB まで行った？
 例外処理に失敗した？
 攻撃文字列にどのレスポンスを返す？
 受信者目線での「攻撃」は送信者目線では、
 スキャニングである場合が大半 https://attack.mitre.org/techniques/T1595/ 


攻撃文字列にどこでレスポンスを返す？
 WAF
 Multiplexer
 Validator
 Business Logic
 403 Not Allowed
 404 Not Found
 DB
 400/422 ..
 500 Internal Server Error 
 404 Not Found
 ナイスブロック！
 ナイスブロック！
 ナイスブロック！


攻撃文字列にどこでレスポンスを返す？
 
 メリ
 デメ
 (AWS) WAF
 正規表現が使える
 プロのルールを利用できる 
 早くない 
 リクエストサイズ制限がある 
 Multiplexer
 （ミドルウェア、プロキシ） 
 2分探索で早い 
 ホワイトリスト方式限定 
 脆弱性を含みうる
 Validator
 （アプリケーション）
 正規表現が使える
 ホワイトリスト方式限定 
 作るのはあなた 
 https://aws.amazon.com/jp/about-aws/whats-new/2024/03/aws-waf-larger-body-inspections-regional-r esources/

非専門家の API Protection 運用
 App
 世間、自社への攻撃動向を元にルールを更新
 （ある程度 managed）
 攻撃を 400, 404, etc. で返せるようにコードを更新
 検知されたが通過した攻撃


WAF log にステータスコードは載らない
 2025-01-23T10:11:23 
 /.env
 rule001 で遮断しました 
 2025-01-23T10:11:23 
 /api/users
 rule002 で検知しました 
 通しました
 2025-01-23T10:11:23 
 /api/users
 500
 123ms
 紐づけたい！
 AWS WAF log
 App log
 https://docs.aws.amazon.com/waf/latest/developerguide/logging-fields.html

custom header を用いて攻撃であることを伝える
 GET /api/users
 Accept: application/json
 X-amzn-waf-my-custom-header: foo
 GET /api/users
 Accept: application/json
 label match を使って COUNT 対象のリクエ ストにカスタムヘッダーをつけます。丁寧に ルールとヘッダーバリューの対応づけをして いくと WCU は比較的嵩みます。ザックリで も案外運用は周ります。
 https://docs.aws.amazon.com/waf/latest/developerguide/customizing-the-incoming-request.html https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-label-match-examples.html

https://dev.classmethod.jp/articles/update-securityhub-matchdetails-for-regex/ application log に BODY は載らないのが普通
 waf log にも載らない
 
 実は少しの間 WAF log の正規表現ルールで検知した文字列の詳細がログに記録 されていました。
 しかし気がついたらドキュメントごと機能が消えていました。。
 
 アプリケーションで出力する（常に全て出力するのは一般的ではない）か
 脆弱性診断で妥協するか。
 BODY の扱いは難しい..


WAFに頼ろう


プロ任せでいいものはプロ任せ
 
 どういった文字列が攻撃か？
 という判断は WAF およびルールに任せてしまおう
 AWS WAF インターネット App Fargate

非常事態には超頼もしい
 
 Log4j のシグネチャはコロコロと変わり続けていました。
 最新のルールを信頼せよ。
 AWS WAF インターネット App Fargate

ミドルウェアを理解して使えていますか？
 WAF Multiplexer Validator Business Logic 403 Not Allowed 404 Not Found 怖いねー DB 400/422 .. 500 Internal Server Error 404 Not Found 怖いねー ナイスブロック！ ナイスブロック！ ナイスブロック！ ミドルウェアが脆弱性を含んでいたり、 脆弱な設定にしていたり

テイクノートメッセージ
 - アプリケーションで攻撃を防ぐという選択肢も持ちましょう。
 - 攻撃か否かの判断は WAF(ルール)に任せましょう。
 - 攻撃の遮断はアプリケーションと分担しましょう。
 - custom header を利用してステータスコードと検知を並べましょう。
 - matchdetails によって BODY が見れるようになるかも？現状はアプリケーションで出 力するしかない。
 - あなたの設定や知識は完璧ではないので WAF に頼りましょう。


宣伝
 弊SREの同僚が書籍を出版しました。
 AWS でのメジャーな IaC ツール、
 CDK と terraform の比較が詳細に書かれていま す。
 IaC ツールは色々な選択肢が出てきていますが、 比較論に目を通すことで技術選定の目を鍛えら れるのでは？