はじめに
こんにちは、MSPチームの村上です。
昨今、Webアプリケーションに対して、ビジネスに悪影響を与える悪性ボットによる攻撃が増えています。
さらに最近のBot攻撃は非常に巧妙です。一つのIPアドレスからの攻撃ではなく、大量な幅広いユニークなIPアドレスを使い、
まるで人間がサイトを見ているかのように全体をクロールしてくることもあります。
今回は、以下ののケースを想定してマネージドルールとカスタムルールを組み合わせたBot対策を検証していきます。
今回の想定ケース
- サイト全体をスクリプトなどでクロールしてくるBot攻撃
- 一つのIPアドレスではなく、複数のIPアドレスに分散している
- 攻撃元は特定の国（今回は検証のため日本）
- 攻撃元の国はビジネス上重要な国になるため通常のアクセスはブロックしてはならない
このような条件の場合、DDoS攻撃対策や、単純な国のアクセスをブロックするだけではカバーできなくなります。
そこで、今回はAWSが用意しているマネージドルールとカスタムルールを組み合わせてこれらの条件をクリアします。
設定概要
WAFの設定内容は、AWSBotControlRuleSetのマネージドルールで監視し、カスタムルールでアクセスを判定する流れを設定します。
① 監視 ・・・AWSManagedRulesBotControlRuleSetをCountモードに設定し、「Botかどうか」のラベルを貼る
② 判定 ・・・カスタムルールで「特定の国」×「特定のラベル」の条件を作成する
③ 実行 ・・・カスタムルールで「Challenge」or「CAPTCHA」モードでBotかどうかを判別させる
ポイント
今回WAFの設定をする上でポイントがいくつかあるので紹介します。
ポイント①：AWSManagedRulesBotControlRuleSetの検査レベルは「Target」を使用する
AWSManagedRulesBotControlRuleSetのマネージドルールには検査レベルに「Common」と「Target」があります。
Commonは一般的なBotを防ぐのに対し、Targetは一般的な保護機能に加え、自己識別を行わない高度なボットに対するターゲットを絞った検出機能も追加されます。
今回の想定ケースのように、複数のIPアドレスに分散していてサイト全体を巧妙にクロールしてくるような攻撃は、単純なルールでは見破れません。
そこで「Target」を有効にすることで、ブラウザ特有の挙動（トークンの保持など）を厳密にチェックし、高度なBotに「怪しい」というラベルを貼れるようになります。
ポイント②：マネージドルール（AWSManagedRulesBotControlRuleSet）は「Count（監視）」に設定する
検査レベルをTargetにして有効にするとデフォルトでは「Block」や「Challenge」になっている項目もありますが、ここではあえてすべての項目で「Count」に設定します。
ここでのマネージドルールの役割は「止めること」ではなく、後のカスタムルールで使うための「ラベルを貼ること」に専念してもらいます。
ポイント③：カスタムルールで「ラベルの有無」と「国」を組み合わせる
実際に判定を実施するカスタムルールでは「上記でカウントされた（ラベルが付与された）条件 ＋ アクセス元の国」というルールにすることで、今回の想定ケースがカバーされます。
今回の場合、スクリプトなどで動いているBotになりますので、トークンを保持しているかどうかをカウントする「TGT_TokenAbsent」のルールで付与されたラベルを対象にします。
また、どのルールを対象するかを変更することで様々な条件のアクセスがカスタマイズできます。
例えば、AIのBotからのアクセスをブロックしたい場合は「CategoryAI」のルールになります。
このようにAWSManagedRulesBotControlRuleには様々なルールがあります。
詳しくは以下のドキュメントをご参照ください。
Bot Control のルールリスト
検証してみた
①AWSManagedRulesBotControlRuleの設定
まずはルール一つ目のAWSManagedRulesBotControlRuleを以下の設定値にします。
- バージョン・・・4.0
- 検査レベル・・・Target
- カテゴリ・・・全てCount
②カスタムルールの設定
次に実際にアクセスを制御するカスタムルールを以下の設定値にします。
- アクション・・・Challenge（今回は検証のためCAPTCHAに設定）
- ルール名・・・任意の名前
- ステートメント①・・・国の指定（今回は日本を設定）
- ステートメント②・・・ラベルの有無（今回はTGT_TokenAbsentに設定）
ステートメントに関してはAND条件で設定します。
AWS WAFのルール設定は以上です。次に動作確認をします。
③動作確認
まずはカスタムルールを外した状態でアクセスします。
次にカスタムルールをWeb ACLにアタッチしてアクセスします。
今回はアクションを「CAPTCHA」にしたため、通常のアクセスでも認証画面が表示されました。
これを「Challenge」にした場合、サイレントチャレンジを実行して、クライアントセッションがボットではなく、ブラウザであることを検証することができるようになります。
まとめ
今回は、AWS WAFの「AWSManagedRulesBotControlRuleSet」と「カスタムルール」を組み合わせた、柔軟性の高いボット対策を検証しました。
今回使用した「TGT_TokenAbsent」以外にも、AIボットや特定のクローラーなど、防ぎたい対象に合わせてラベルを切り替えるだけで、様々なシナリオに対応できると思います。
どなたかの参考になれば幸いです。
簡単30秒