AWS環境でWebアプリケーションのセキュリティを強化するためにAWS WAFを導入する企業が増えています。便利なサービスですが、誤検知という課題が残ります。
AWS WAFの誤検知によって通常のWeb利用者がWebサイトやWebシステムにアクセスできなくなるため、顧客の不信感やクレームを招いてしまいやECサイトだった場合は売上機会の損失に直結してしまうので、誤検知の対策は必須です。
この記事では、AWS WAFの誤検知における基礎知識から誤検知発生時の対応方法までわかりやすく解説します。
目次
AWS WAFの誤検知とは？
AWS WAFを導入することによってWebアプリケーションのセキュリティを強化できますが、誤検知という課題も発生します。
またAWSマネージドルールを利用する場合でも、誤検知発生時の対応は自社で実施する必要があります。誤検知の対応に追われてしまうというケースも少なくないので、対応プロセスを事前に把握することが重要です。
ここではAWS WAFにおける誤検知について解説していきます。
誤検知とは？その影響も解説
誤検知は、正常な動きや通信を不正アクセスとして誤って判定することです。誤検知によって通常のWeb利用者がWebサイトやWebシステムにアクセスできなくなるため、顧客の不信感やクレームを招いてしまい、売上機会の損失にもつながります。
とはいえ、WAFのルールを緩めすぎると、セキュリティの確保が難しくなるため、セキュリティと誤検知回避の間に適切なバランスを取ることが重要です。
AWSマネージドルールと誤検知
AWSマネージドルールは、AWSが提供しているAWS WAFで利用するプリセットされたルールセットです。AWSマネージドルールを利用することで、OWASP Top 10に含まれる一般的なサイバー攻撃を対策できます。
ただし、あくまでも「汎用的」なルールセットなので、AWSマネージドルールは個別のWebアプリケーションやAWS利用者の特徴に特化したものではありません。そのため、アプリケーションの特性によっては誤検知が頻繁に発生してしまう可能性があります。
AWSマネージドルールの仕様上、個々のルールの内部詳細が開示されておらず、直接的なチューニングもできません。それゆえ誤検知を回避するために、AWSマネージドルールの個別ルールを無効にしたり、後述するラベル機能やスコープダウンステートメントなどAWS WAFの機能を活用したりして対応していく必要があります。
AWS WAF誤検知の対応方法①：除外ルールの作成
AWS WAFのラベル機能を活用し、誤検知があったルールを特定して除外ルールを作成することで誤検知を回避することができます。
ラベル機能とはルールにマッチした場合にアクセスに対してラベルを付与できる機能です。AWSマネージドルールによって検知・遮断された通信にはルールごとのラベルが付与されます。
そのラベルを確認することで誤検知を起こしたルールを特定することができます。それに基づいて除外ルールを作成することで誤検知に対応できます。
AWS WAFのラベル機能について詳しくはこちらの記事：
なお、この方法はあくまでも一例となり、設定状況によって対応方法が異なる場合があります。自社の設定を確認のうえ、ご自身の責任で設定・実行していただくようお願いします。
誤検知のあったルールを特定
AWSマネージドルールによって検知・遮断された通信にはラベルが付与されます。そのラベルを確認することで、どのルールセットのどのルールが誤検知を起こしているのかを把握できます。
下記はラベルの一例です。誤検知された通信に付与されたラベルだと仮定します。
awswaf:managed:aws:core-rule-set:EC2MetaDataSSRF_BODY
末尾の部分（EC2MetaDataSSRF_BODY）が誤検知を起こしたルールの名前で、その手前の部分（core-rule-set）はルールが属するルールセットのことです。
この例の場合、マネージドルールのコアルールセットの「EC2MetaDataSSRF_BODY」というルールが誤検知の原因となっています。
誤検知のあったルールをカウントモード（COUNT）に変更
誤検知を起こしたルールを特定したあと、当該ルールをカウントモード（COUNT）に変更します。
具体的にはAWS WAFのルール一覧画面から該当するルールを見つけ、そのRule action（ルールアクション）をCOUNTに切り替えます。例えば下記のようです。
上記の例であれば、EC2MetaDataSSRF_BODYというルールをカウントモードに変更します。このルールにより通信の遮断がなくなり、検知のみとなります。
除外ルールをカスタムルールとして作成
EC2MetaDataSSRF_BODYというルールをカウントモードにしたため、たとえ不正通信がこのルールによって検知したとしても遮断しません。本来EC2MetaDataSSRF_BODYというルールで防御できた不正アクセスが防げなくなるわけなので、危険な状態になります。
この状況を回避するのに除外ルールの作成が必要です。ここでは、URIパスにtest/contactを含む通信のみを許可するケースを例として除外ルールの作成方法について説明します。
まずルール一覧ページから「Add rules」と「Add my own rules and rule groups」をクリックしてカスタムルールを追加します。
そしてルールの検知条件（ステートメント）にANDを使って2つの条件を設定します。
1つ目の条件は通信に検知ルールのラベルが付いていること。この場合、Match ScopeをLabelにし、Match Keyに「awswaf:managed:aws:core-rule-set:EC2MetaDataSSRF_BODY」を入力します。
2つ目の条件は通信のURI pathが/test/contact以外であること。URI pathが/test/contact以外のものを遮断したいので、NOTステートメントを利用して、下記のように条件を設定します。
設定内容を改めて確認して、問題がなければこのルールを保存します。カスタムルールの名前は基本自社の規則や習慣に則り変更しても構いませんが、除外ルールであることがわかるようなルール名にするのがおすすめです。
この例の場合、冒頭にExclusionを付けて、ルール名をExclusion_EC2MetaDataSSRF_Bodyにします。
除外ルールの優先度を調整
除外ルールが正常に動作するにはまずマネージドルールを実行しなければなりません。そのため、除外ルールの優先順位をマネージドルールより低くする必要があります。
具体的にはAWS WAFのルール一覧画面から、除外ルールのPriority値（プライオリティ）をマネージドルールより大きくします。AWS WAFではPriority値の順番に応じてルールを実行する仕組みとなっていて、0は最も優先度が高く、そして数字が大きければ大きいほど実行の優先度が低くなります。
これで除外ルールの設定は完了で、誤検知の対応ができました。
AWS WAFの誤検知の対応方法②：ALLOWルールの作成
SQLインジェクション攻撃やクロスサイトスクリプティング（XSS）攻撃などのルールステートメントを用いたルールの誤検知に対応するには、ALLOWルールを作成して当該通信を許可する方法もあります。
ただし、ALLOWルールに合致したすべての通信がAWS WAFを通過できてしまうので、この方法を利用する場合細かい検証や調整が必要となります。
ここではALLOWルールの作成による誤検知の対応方法について詳しく解説します。
誤検知があったルールと文字列を特定
まずは誤検知の原因となるルールや文字列を特定します。ここでは、AWSドキュメントに公開されるAWS WAFのSQLインジェクションの検出ログを誤検知のログとして使って解説を行います（一部修正あり）。
{
"timestamp": 1576280412771,
"formatVersion": 1,
"webaclId": "arn:aws:wafv2:ap-southeast-2:999999999999:regional/webacl/STMTest/1EXAMPLE-2ARN-3ARN-4ARN-123456EXAMPLE",
"terminatingRuleId": "STMTest_SQLi_XSS",
"terminatingRuleType": "REGULAR",
"action": "BLOCK",
"terminatingRuleMatchDetails": [
{
"conditionType": "SQL_INJECTION",
"sensitivityLevel": "HIGH",
"location": "HEADER",
"matchedData": [
"10",
"AND",
"1"
]
}
],
まず、ログ内の”action”フィールドを確認ください。誤検知が発生した場合、”action”フィールドは”BLOCK”となります。仮に”COUNT”の場合、誤検知の原因は別のルールの可能性があるので、再調査の必要があります。
次は“terminatingRuleId”フィールドに記載された誤検知したルールのIDを確かめます。誤検知を引き起こしたルールIDをこちらで確認できます。併せて”matchedData”フィールドの内容をチェックし、どの文字列が誤検知を引き起こしたかを確認します。
例えば上記の検知ログの場合、誤検知となったルールのIDは “STMTest_SQLi_XSS”で誤検知となった文字列は”10″、”AND”と”1″です。
誤検知があった文字列を許可（ALLOW）するルールを追加
誤検知を起こしたルールと文字列を特定できたあと、誤検知した文字列を許可するカスタムルールを追加します。
カスタムルールの追加はAWS WAFのルール一覧画面から設定できます。ルール名は自社のルールにしたがって自由に設定できますが、ステートメントに関しては下記のように選択をします。
- 「If a request」は「matches the statement」にします。
- 「Inspect」は「All query parameters」にします。
- 「Match type」は「Contains string」にして「String to match」の空欄に先ほど特定した文字列を入力します。
- 「Action」を「ALLOW」にします。
上記の設定を完成したあとルールを公開して、カスタムルールの追加が完了となります。このカスタムルールによって通信に”10″、”AND”と”1″が含まれる通信がAWS WAFを通過できるようになるので、誤検知を解消できます。
カスタムルールの追加方法について詳しくはこちらの記事：
追加したルールを、誤検知があったルールより高い優先度に設定
新しいカスタムルールを公開したあとに、ルールの優先度を調整しなければなりません。優先度がAWSマネージドルールより低い場合、新しいカスタムルールが機能しない可能性があります。
ルールの優先度はAWS WAFのルール一覧画面の「Move up」と「Move down」ボタンで設定できます。
新しいカスタムルールの優先度をAWSマネージドルールより高く設定すると、誤検知の対応が完了となります。
新しいルールを適用する前にはまずカウントモード
AWS WAFの誤検知を回避するにはカウントモードの活用が大事です。カウントモード（COUNT）とは、通信を遮断せずに該当ルールに合致するアクセスの内容を記録するモードです。
新しい検知ルールを設定する際に、まずはカウントモードでルールの検証を行い、問題がなければブロックモード（BLOCK）に切り替えて実際にサイバー攻撃の遮断を開始することをおすすめします。
カウントモードの活用によって、新しい検知ルールによる誤検知リスクを低減することができます。
まとめ
AWS WAFはWebアプリケーションのセキュリティを強化するのにとても有効なサービスですが、誤検知という課題があります。
誤検知とは正常な通信を不正アクセスとしてAWS WAFが誤って判断し遮断してしまう現象です。通常のWeb利用者がWebサイトやWebシステムにアクセスできなくなるため、顧客の不信感やクレームを招いてしまい、売上機会の損失に直結してしまうためきちんとした誤検知対策が必須です。
誤検知に対応するためには除外ルールを作成する方法があります。AWS WAFのラベル機能を活用して誤検知を起こしたルールを特定し除外ルールを追加することで誤検知を回避することができます。また、誤検知された通信内容をALLOWルールとして作成し許可する方法もあります。
ただし、いずれにせよ誤検知対応にはセキュリティにおける専門知識が必要です。社内にセキュリティエンジニアがいない場合やリソースが足りない場合、WAF自動運用サービス「WafCharm」の利用がおすすめです。
WafCharmを導入した場合、検知ルールのカスタマイズをWafCharmが行います。また誤検知やトラブルが発生した場合でもWafCharmの日本語サポートが追加のルールを作成して適用するので安心してAWS WAFを運用することが可能です。
WafCharmの詳細についてはこちらの資料でご確認できます。
