目次
1. はじめに
2021年4月1日 JST にボットコントロール機能が AWS WAF にリリースされました。
一般的に普及しているボットをコントロールする機能で余計なリソースの消費を抑えたり、過剰なアクセスによるダウンタイムを引き起こすことを防いだり、サイト管理者が望んでいないアクセスを制御することが期待できます。検索エンジンのクローラ等の許可したいアクセスはブロックしないように制御することも可能です。Bot mitigation の機能は無いので、無名な悪質ボットから短時間の高負荷アクセスを防ぐといったことはできません。
設定方法と WafCharm との併用について解説します。
2. Web ACL への設定方法
ボットコントロール機能はマネージドルールとして提供されます。
AWSがこれまで公式でリリースしているマネージドルールと異なり、ボットコントロールはプロビジョニング費用(10.00 USD / 月)が発生するのでご注意ください。
※費用の詳細は公式情報を確認してください。
https://aws.amazon.com/jp/waf/pricing/
「 Add rules 」から「 Add managed rule groups 」を選択します。

「 AWS managed rule groups 」を選択し、「 Bot Control 」の Action を変更します。
他の AWS マネージドグループと異なり「 Paid rule groups 」となっており有償であることが明示されています。

画面下の「 Add rules 」で適用します。

次に希望のルール順に変更して「 Save 」で完了です。

Bot Control では専用のモニタリング画面が用意されているので、ボットの検知状況だけを確認することが可能です。

3. ルール一覧
| ルール名 | 概要 |
| CategoryAdvertising | 広告系ボット |
| CategoryArchiver | アーカイブ系ボット |
| CategoryContentFetcher | コンテンツ取得系ボット |
| CategoryHttpLibrary | HttpLibrary 利用 |
| CategoryLinkChecker | リンクチェッカー系ボット |
| CategoryMiscellaneous | その他 |
| CategoryMonitoring | 監視ツール |
| CategoryScrapingFramework | ScrapingFramework 利用 |
| CategorySearchEngine | 検索エンジンボット |
| CategorySecurity | SecuirtyScanner |
| CategorySeo | SEO ボット |
| CategorySocialMedia | ソーシャルメディア系ボット |
| SignalAutomatedBrowser | 自動化されたブラウザ |
| SignalKnownBotDataCenter | ボットのインフラとして利用されるデータセンタを srcip とするボット |
| SignalNonBrowserUserAgent | ブラウザの UserAgent ではない UserAgent |
4. 許可や拒否の運用方法
各ルールのアクションの変更
ボットコントロールのルールは複数のルールで構成されています。BLOCK したくないルールについては COUNT に変更することが可能です。Web サイトや事業の特性によっては有用なボットも存在しますので、COUNT で導入しログを監視しながら BLOCK 設定していくのが良いかと思われます。
※公式のルール情報
https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-list.html

ラベルによる制御
ラベルについても新しくリリースされた機能で、ルールに関連付けられているアクションに関係なく、WAF ルールがリクエストに一致したときに、ウェブリクエストに説明ラベルを追加する機能です。さらに、このラベルを利用したルールを作成することが可能です。
今回のボットコントロールにはラベルが適用されていて、利用することが可能です。
※以下ラベルは一部です。

ボットコントロールでの利用方法としては特定のルールから特定のパターンを除外することができます。JSONでのイメージがわかりやすいかと思いますので以下を確認してください。
※前提条件として対象のルール(ラベルをつけるルール)をCOUNTにする必要があります。その後続(マネージドルールの後続)ルールにラベルマッチルールを作成します。
{
"Rule": {
"Name": "match_rule",
"Statement": {
"AndStatement": {
"Statements": [
{
"LabelMatchStatement": {
"Scope": "LABEL",
"Key": "awswaf:managed:aws:AWSManagedRulesBotControlRuleSet:bot:category:monitoring"
}
},
{
"NotStatement": {
"Statement": {
"LabelMatchStatement": {
"Scope": "LABEL",
"Key": "awswaf:managed:aws:AWSManagedRulesBotControlRuleSet:bot:name:pingdom"
}
}
}
}
]
}
},
"RuleLabels": [],
"Action": {
"Block": {}
}
}
}
CategoryMonitoring というルールに該当した場合に pingdom のラベルが付いているもの以外をBLOCKするというルールを作成することで、pingdom を BLOCK 対象から除外しています。
NotStatement の内容は既存のstatementも利用できるため、文字列一致条件を利用したルールやIPアドレスを利用したルールを使用した除外も可能です。
マネージドルールの ScopeDownStatement を利用した絞り込み
こちらも新しくリリースされた機能でマネージドルール自体に条件を付与することができるようになりました。ログインページのみ対象や特定の国以外を対象にするなどができます。
こちらも JSON 形式で確認してみましょう。
{
"Name": "AWS-AWSBotControl-Example",
"Priority": 5,
"Statement": {
"ManagedRuleGroupStatement": {
"VendorName": "AWS",
"Name": "AWSManagedRulesBotControlRuleSet",
"ExcludedRules": [
{
"Name": "CategoryVerifiedSearchEngine"
},
{
"Name": "CategoryVerifiedSocialMedia"
}
]
},
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "AWS-AWSBotControl-Example"
},
"ScopeDownStatement": {
"ByteMatchStatement": {
"SearchString": "login",
"FieldToMatch": {
"UriPath": {}
},
"TextTransformations": [
{
"Priority": 0,
"Type": "NONE"
}
],
"PositionalConstraint": "CONTAINS"
}
}
}
}
マネージドルールに複合条件として ScopeDownStatement が付与されて、文字列一致条件で URI に login が含まれるという条件がついています。言い換えると URI に login が含まれないものは除外されていることになります。文字列一致条件を NotStatement で条件を逆にすることもできます。
カスタムヘッダーを利用した除外
カスタムヘッダー機能も新しくリリースされた機能でルールに合致した際にカスタムヘッダー を付与する機能です。ボットコントロールのルールの前提に特定の条件にマッチするルールを作り、カスタムヘッダー を付与します。そのヘッダーを利用して ScopeDownStatement の条件にNotStatementで紐づければ除外することが可能です。
例
- ユーザーエージェントに「googlebot」が含まれる場合、ヘッダー名: x-bypass-secret に値: exclude を付与する。アクションは COUNT に設定。
- ボットコントロールルールに ScopeDownStatement を付与して、ヘッダー名: x-bypass-secret に値: exclude が入っている場合という文字列一致条件を NotStatement で付与する。
2 のルールの JSON での記載例
{
"Name": "AWS-AWSBotControl-Example",
"Priority": 5,
"Statement": {
"ManagedRuleGroupStatement": {
"VendorName": "AWS",
"Name": "AWSManagedRulesBotControlRuleSet",
"ExcludedRules": [
{
"Name": "CategoryVerifiedSearchEngine"
},
{
"Name": "CategoryVerifiedSocialMedia"
}
]
},
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "AWS-AWSBotControl-Example"
},
"ScopeDownStatement": {
"NotStatement": {
"Statement": {
"ByteMatchStatement": {
"SearchString": "exclude",
"FieldToMatch": {
"SingleHeader": {
"Name": "x-bypass-secret"
}
},
"TextTransformations": [
{
"Priority": 0,
"Type": "NONE"
}
],
"PositionalConstraint": "EXACTLY"
}
}
}
}
}
}
複数の機能リリースがあり、特にマネージドルールで除外設定が対応可能なパターンが増えました。
設定例は AWS の公式情報にもありますのでご確認ください。
https://docs.aws.amazon.com/waf/latest/developerguide/waf-bot-control-examples.html
5. WafCharm との併用
ボットコントロール機能を検証したところ、WafCharm ルールと併用しても問題ないことを確認いたしました。ボットのアクセスにお困りの方は是非併用してみてください。
6. おわりに
WCU 50 で利用できることを考えると、とてもコストパフォーマンスが良いルールかと思います。似たような条件を独自に文字列マッチ条件で作成すると WCU を大量に消費することになります。費用が別途発生する点は気になりますが、導入はおすすめです。
まずは COUNT 状態で適用してどの程度のアクセスがあるか確認してみましょう。
特定の対象者に向けたサイトの場合は、そもそもボットのアクセスが不要な場合もあるので最初から BLOCK でも問題ないかもしれません。
検索クローラーだけ許可など、サイトの方針に応じてカスタマイズすることで余計なリソースを使われることもなくなります。
URI を絞るなど特定のアクセスパターンを除外する方法は、AWS WAF でも複数用意されていますが設定は少々難しいかと思われます。新たに登場した Bot Management Console でアクセス監視しながら、「robots.txt」などでクローラーを制御するのが最も簡易な方法かもしれません。AWS WAF に慣れていて、かつご利用の Web ACL で WAF Capacity Unit に空きのある方は、ルールを作成してカスタムヘッダーで制御することも可能です。

