aws-waf-bot-scraping-defense
運営する文化アーカイブ系サイトに対するボットスクレイピングを、AWS WAFのGeo block・IPset・JA3 fingerprint・UA blockを段階的に組み合わせて遮断した記録です。
awswafcloudfrontsecuritysparqlga4
台本(フルテキスト)
動画の掛け合いを書き起こしたものです。音声を再生しづらい場合はこちらをお読みください。
オープニング
- AWS WAF でボットスクレイピングを止めた記録
- GA4 → ログ → 段階的ブロックの流れ
- めたん
- こんにちは。今日はAWS WAFを使ってボットスクレイピングを止めた記録のお話をしましょう。
- ずんだもん
- ボットスクレイピング...? なんだか難しそうなのだ。
- めたん
- 公開している文化アーカイブのサイトに、自動化された大量アクセスが来ていたんです。
- ずんだもん
- それは困るのだ...
- めたん
- GA4で異常値を見つけたのが入り口で、そこから段階的に対処していった話を紹介しますね。
- ずんだもん
- 段階的に...? どういう手順だったのだ?
GA4の異常値で発覚
- PV ≒ Sessions ≒ Users で階段が潰れる
- Singapore 集中、Chrome on Windows、24h フラット
- ずんだもん
- GA4でどんな異常があったのだ?
- めたん
- PVとSessionsとUsersが、ほぼ同じ値になっていたんです。
- ずんだもん
- あー、人なら一人で複数ページ見るから、PVのほうが大きくなるはずなのだ。
- めたん
- そうなんです。さらに国別を見ると、Singaporeから9割以上のアクセスが来ていました。
- ずんだもん
- 日本語サイトなのに、Singaporeから9割...? あやしいのだ。
- めたん
- ブラウザはChrome on Windowsを名乗っていて、24時間休まず巡回している感じでした。
- ずんだもん
- 明らかに自動化されているのだ...
WAFログで攻撃の正体を可視化
- JA3 fingerprint が標準で記録される
- 数千 IP / 30 分の極めて分散したスクレイピング
- めたん
- 次にWAFログをCloudWatch Logs Insightsで集計しました。
- ずんだもん
- ログから何がわかったのだ?
- めたん
- SGからは数千IPが来ていて、1IPあたりはrate-limitの閾値の数%以下しか送っていませんでした。
- ずんだもん
- そんなに分散してるのだ...これは捕まえにくそうなのだ。
- めたん
- しかもJA3 fingerprintを見ると、特定のハッシュが圧倒的に多くて、同じツールから来ていることがわかったんです。
- ずんだもん
- JA3、って何なのだ?
- めたん
- TLSのClient Helloから計算したフィンガープリントで、IPを変えてもツールを変えない限り同じ値になるんですよ。
rate-limitではヒットしない
- 1 IP あたり閾値の数% 以下で、原理的に rate-limit では無理
- 閾値を下げると正規利用が誤発火
- ずんだもん
- rate-limitの閾値を厳しくすればいいんじゃないのだ?
- めたん
- それも考えたんですが、SPARQLクライアントや企業のNAT経由の正規利用に誤発火するリスクが高いんです。
- ずんだもん
- なるほど、善良な利用者まで弾いてしまうのだ...
- めたん
- 1IPあたりが閾値の数%以下しか来ていないので、rate-limitでは原理的に無理でした。
- ずんだもん
- じゃあ別のアプローチが必要だったのだ?
- めたん
- IPレンジでブロックを試したんですが、攻撃者は隣の/16レンジにすぐpivotしてくるんです。
- ずんだもん
- それはモグラ叩きだ...
Geo blockで根本停止
- Singapore 在住の正規利用者は統計的にごく少数
- 副作用が小さいなら Geo block が最もクリーン
- めたん
- 結局、SingaporeをGeo blockでまるごと弾く判断にしました。
- ずんだもん
- 国まるごと弾くのは大胆なのだ...
- めたん
- 日本語の文化アーカイブなので、SG在住の正規利用者は統計的にごく少数なんです。
- ずんだもん
- 副作用が小さいなら、一気に止められるのだ。
- めたん
- 伝搬完了後、SGからのアクセスは概ね遮断されました。日本の正規利用者への影響もなく、モグラ叩きが収束しています。
- ずんだもん
- スッキリ止まったのだ!
ピボット: USへの再来とJA3 + UAブロック
- 同じ JA3 が US から再来 — IP を変えても効くシグナル
- AI 学習・SEO 解析クローラーは UA で一括ブロック
- めたん
- ところが翌日、USからのアクセスが急増していたんです。
- ずんだもん
- 攻撃者が国を変えてきたのだ...?
- めたん
- しかもJA3がSGの時とぴったり同じだったんです。攻撃ツールがIPを変えただけで再来していました。
- ずんだもん
- JA3って、そういう時に効くのだね。
- めたん
- ええ、JA3が一致する分はそれ自体をBlockルールにしました。IPやUAを変えても、TLSスタックが同じなら効き続けます。
- ずんだもん
- 比較的安定したシグネチャになるのだ。
- めたん
- あわせてGPTBotやCCBotなど、宣言済みのAIクローラーもUAで一括ブロックしました。
翌日、CNへのpivot
- ヘッドレスブラウザ駆動 → JA3 多様、JA3 Block は効率が悪い
- 同じ論理で Geo block CN を実施
- めたん
- さらに翌日、今度はCNからのアクセスが急増していて、これがまた違う性質だったんです。
- ずんだもん
- 違う性質...? どんなふうに違ったのだ?
- めたん
- ヘッドレスブラウザで実Chromeを立ち上げて、NuxtのJSチャンクを毎リクエストで全部ダウンロードしていたんです。
- ずんだもん
- それだとJA3が多様になるのだ?
- めたん
- そうなんです。広域分散でJA3 Blockでは効率が悪いので、CNもGeo blockする判断にしました。
- ずんだもん
- SGと同じ論理だ。
- めたん
- ええ、伝搬後はCNもほぼ遮断されて、総トラフィック量が6倍以上削減されました。
学びとまとめ
- Geo block は汎用性が高い、JA3 は IP より安定
- 観測 → 仮説 → 検証 → 監視のサイクルを回す
- めたん
- 今回の対応で印象に残ったのは、Geo blockの汎用性ですね。
- ずんだもん
- ツールの違いを問わず一律遮断できるから...?
- めたん
- そうです。あと、JA3 fingerprintはIPより安定したシグナルとして使えるのも学びでした。
- ずんだもん
- ログ基盤の重要性も感じたのだ。
- めたん
- ええ、CloudWatch Logs Insightsで多軸集計が即座にできる粒度・保持期間で運用しておくのが要ですね。
- ずんだもん
- 観測、仮説、検証、監視のサイクルですね!
- めたん
- その通りです。次の波が来ても、同じ枠組みで対処できるはずです。