AWS WAF Geo allowlist と ASN ベース IPSet でボット pivot に終止符を打った話
4月のSGスクレイピング攻撃止血後、HK/VN/ID/DEへとpivotされ続けた末、Geo allowlist + Tencent/Alibaba ASN ベースのIPSetに切り替えた実録
awswafcloudfrontsecuritylodsparqlga4
台本(フルテキスト)
動画の掛け合いを書き起こしたものです。音声を再生しづらい場合はこちらをお読みください。
オープニング
- SG Geo Block 後に HK/VN/ID/DE へ pivot
- Geo allowlist + ASN ベース IPSet に切り替えた実録
- うさぎ
- 今日はAWS WAFでのボット攻撃対策の続き、Geo allowlistとASNベースIPSetへの切り替えについて紹介するね。
- WhiteCUL
- 前回のシンガポールのGeo Blockで止血したのに、攻撃が再開したのですか？
- うさぎ
- そう。1週間後にHK、VN、ID、DEとpivotされ続けたの。GA4のリアルタイムでVietnamが異常に多いのを見て気づいたんだ。
- WhiteCUL
- GA4で気づいたのですか？
- うさぎ
- 日本語コンテンツのアーカイブでJapanが3番目というのは不自然でしょ。WAFログを確認したら3時間で15万リクエストの攻撃が来ていたの。
- WhiteCUL
- GA4ではその規模は見えないのですね。
攻撃の正体と3パターンの発信元
- 攻撃の 90% が SPARQL エンドポイントに集中
- クラウド集中型・residential 分散型・単一レンジ型の 3 パターン
- WhiteCUL
- 攻撃者は何を狙っていたのですか？
- うさぎ
- WAFログを分析したら、VN/HK/IDのリクエストの90%がSPARQLエンドポイントとSnorqlに集中していたの。Linked DataのRDFを全件吸い取ろうとしていたのよ。
- WhiteCUL
- 発信元はどんなパターンがありましたか？
- うさぎ
- HKはTencentのクラウドIPが集中、VNは1000以上のIPに分散したresidential型、IDはTelkom Indonesiaの単一レンジの3パターンがあったわ。
- WhiteCUL
- residential型はIPベースの対策が難しそうですね。
- うさぎ
- そうなの。residential proxyは各IPが数リクエストしか出さないから、IPベースのBlockは事実上不可能でGeo Blockしか手がないの。
default-deny + 45カ国allowlistへの切り替え
- 個別 Geo Block は whack-a-mole で構造的に勝てない
- 先進国 45 カ国の allowlist + default deny に転換
- WhiteCUL
- 個別に国をブロックし続ける戦略はどうだったのですか？
- うさぎ
- これは構造的に勝てないの。SG→CN→HK→VN→IDと来て次はIN、PH、BRあたりに行くだけ。whack-a-moleと同じよ。
- WhiteCUL
- それで方針を変えたのですか？
- うさぎ
- default-deny+先進国45カ国のallowlistに切り替えたの。日本・韓国・台湾・北米・欧州・大洋州・中東の計45カ国ね。
- WhiteCUL
- HKやSGも除外したのですか？
- うさぎ
- Tencent CloudやAWSのクラウドIPが攻撃元になっているため除外したの。技術的には先進国だけど、ボットインフラとしての悪用度の方が大きいと判断したわ。
ASNベースIPSetへの切り替え
- 観測 IP を手で列挙する方法は必ず漏れる
- BGP feed から ASN の全 prefix を取得するのが正解
- WhiteCUL
- allowlistだけでは不十分だったのですか？
- うさぎ
- US、DE、TW経由でもTencentやAlibabaのクラウドIPからSPARQLが叩き続けられていたの。GeoIP的には許可国でも実態はクラウド経由のスクレイピングだったのよ。
- WhiteCUL
- TencentのCIDRをIPSetに手動で追加したらどうなりましたか？
- うさぎ
- 18件追加したけど、30分後にDE経由でTencentの別のCIDRから攻撃が続いていたの。観測ベースで手動列挙するのは構造的に漏れるって痛感したわ。
- WhiteCUL
- 正しい方法は何ですか？
- うさぎ
- BGP feedから各ASNのannounced prefix全件を取得するの。TencentはAS132203で1547件、AlibabaはAS45102で514件。集約すると345件になったわ。
Oracle/VultrのASN予防追加と防御の現実
- Oracle Cloud・Vultr は予防的に ASN 追加
- 完全防御は構造的に不可能、96% が現実的な到達点
- WhiteCUL
- TencentとAlibabaの他にも対策しましたか？
- うさぎ
- Oracle CloudとVultrも予防的に追加したよ。両者は無料や激安で使えるから、スクレイピング専用クラウドに近い使われ方をするの。
- WhiteCUL
- HetznerやOVHは追加しなかったのですか？
- うさぎ
- 大学や研究機関がホストしているSPARQLクライアントなど、正規の利用例がある可能性が高いから観測ベースで追加する方針にしたの。
- WhiteCUL
- これで完全に防げるようになりましたか？
- うさぎ
- 完全防御は構造的に無理なの。TencentやAlibabaが新リージョンを別ASNで開くと漏れるし、residential proxyは原理的に切れない。今日の到達点は96%ね。
まとめ
- pivot 攻撃には allowlist + ASN ベース IPSet の二段防御
- BGP feed から ASN 全 prefix を取得するのが基本
- うさぎ
- 今日の学びをまとめると、Geo Blockを個別に追加するだけでは追いかけっこになるから、allowlist化が有効ということね。
- WhiteCUL
- IPSetもASNベースで組む必要があるのですね。
- うさぎ
- 観測ベースでCIDRを手で列挙するのは高確率で漏れるわ。RIPE StatなどのBGP feedから全prefixを取得して集約するのが正解よ。
- WhiteCUL
- GA4とWAFログを両方使う重要性もわかりました。
- うさぎ
- GA4はJSが実行されたセッションしか見えないから、APIスクレイピングの全容はWAFログで確認するのが必須よ。
- WhiteCUL
- ありがとうございました。