4月にBot Controlがリリースされましたのでその紹介です。 aws.amazon.com
Bot ControlはWAFのマネージドルールとして新しく加わったルールです。今回追加されたBot ControlはウェブリクエストからBotか判定し、ルールに設定したAction(Allow or Block or Count)を行うことができます。
それ以外にもAWS WAFにはIP制限、レートベース、独自ルールに基づいた制限を行うことができたり、マーケットプレイスで提供されているマネージドルールを利用することが可能です。
実際にどんなものか触ってみたかったので、クラメソさんのこちらの記事を参考にしながら設定をしてみました。 dev.classmethod.jp
設定手順については先述のブログを参照していただくとわかりやすいのでこのブログでは省きます。
WAF -> ALB -> ElasticBeanstalk
検証ではこのような構成になっています。
動作確認のため、ブログで紹介されていたPageSpeed Insightを使ってEBで作成されたURLにリクエストを流します。
このようにBot、Non Botのリクエストが可視化されます。
このキャプチャの上のグラフではルールにマッチした場合にAllowになったのかBlockになったのか可視化しています。下のグラフではBotがどのカテゴリに分類されたのか可視化しています。
PageSpeed Insightはカテゴリcontent_fetcher
に属していました。
Browse bot activityのグラフではUserAgentごとのリクエストが可視化されています。
用語について
Bot Controlの設定でいくつか気になった用語があったので調べてみました。
ScopeDown Statement
ルールの評価を行う前に指定した条件のチェックを行う機能。 ScopeDown Statementが設定されている場合、ルールの評価の前のScopeDown Statementの評価が行われるのでリクエストをより具体的に絞り込み時に利用する。 docs.aws.amazon.com
Label
ルールにマッチした場合につけることができるメタデータ。CloudWatchのメトリクスのnamespaceにLable名のnamespaceを作り、Lable毎に集計したり、特定のLable名がついたリクエストにのみ別のルールを適用することができる。 例えばWebACLのルールがこのようになっていた場合、最初のルールはBot Controlのマネージドルールが評価されます。その後にtest-label-2のルールが評価されるのですが、test-label-2のルールは以下のようになっています。
Statement 1
にあるようにLabelを条件にしてどのようなActionを実行するか設定しています。このように前のルールの条件で特定のLabelがついていた場合のみルールにあるActionを適用させることが可能です。
またこのようにLabelでCloudWatch メトリクスにデータを送ることも可能です。
一点気になったのですが、Lableで評価する場合は前のルールの評価をBlock以外にしておく必要があるんじゃないかと思っています。前のルールでBlockにした場合、次のルールの評価がされない動作をした気がします(ちょっと自信がない)もし詳しい方がいたらコメントいただけるとありがたいです。
ルールの評価順について docs.aws.amazon.com
Override Action
理解が怪しいのですが、ルールグループのActionをCountに書き換える機能。 先述のLabelの箇所で気になっていたルール評価でBlockした場合に次のルールの評価がされない?と書いたのですが、このOverride Actionを使えば、対象のルールグループのActionをCountに書き換えるので、ルールの評価が続行されると思います。
With this option, the rules in the rule group run as specified by the rule group configuration. The first rule that matches a web request and that has a rule action of allow or block terminates the rule group evaluation and returns the allow or block action for the rule group. At this point, the web ACL override changes the returned rule group action to count and then continues processing any other rules and rule groups that are configured in the web ACL. So, processing inside the rule group works according to the rule group's rule configurations, up to the first rule that matches and has a termination action setting.
Google先生により翻訳すると以下のような日本語になりました。おそらく理解はあってそうです。
このオプションを使用すると、ルールグループ内のルールは、ルールグループ構成で指定されたとおりに実行されます。Web要求に一致し、許可またはブロックのルールアクションを持つ最初のルールは、ルールグループの評価を終了し、ルールグループの許可またはブロックアクションを返します。この時点で、Web ACLオーバーライドは、返されたルールグループアクションをカウントに変更してから、WebACLで設定されている他のルールおよびルールグループの処理を続行します。したがって、ルールグループ内の処理は、ルールグループのルール構成に従って機能します。
まとめ
Bot対策の相談をされたときにいいアイディアがなかったのですが、Bot Controlがリリースされたのでこれは良さそうと思い、紹介してみました。
Botのリクエストをカテゴリ分けしてくれるのでどういう種類のBotからリクエストが来ているのか知れるので便利だと思います。
Bot Control以外にもカスタムレスポンスに対応していたりなど、嬉しいアップデートがあったことも知れてよかったです:)
Bot Controlに限らずWAFのルールはいきなり本番にBlockで投入してしまうと予期せぬ障害を生みかねません。誤検知の危険があるので、まずはCountで設定してみて、想定通りのルール評価をしているかしっかりチェックするのが大事だと思います。
またマネージドルールはルールを考える必要がなく楽ではありますが、ブラックボックスなルールでもあります。そのため、どういう条件になっているかわからないので誤検知したときに原因を突き止めにくいと思います。CSCさんが提供しているWaf Charmのようなマネージドルールの管理をサポートしてくれるツールもあるので(CSCさんの提供しているマネージドルールに限る)合わせて検討するのがよいと思います。
それではよいGWを!
See you next time:)