AWS WAFの誤検知はなぜ発生する？要因や解消方法を解説

WAFにおける誤検知

攻撃表面が複雑化する昨今、WAFはWebサービスの運用に重要なセキュリティ対策の一つです。
AWSを利用する際にも、Amazon EC2やAmazon API GatewayでホスティングされたWebサービスをAWS WAFで守る構成は一般的になっています。
ところが適切なルール設定をしていないと誤検知が増えてしまいます。本コラムでは、誤検知が増えてしまう要因や、より良い運用を目指していくうえで誤検知を減らしていくことの重要性、どのように誤検知を減らすのかについて解説します。参考になれば幸いです。

分かりやすさのために一言で誤検知と書いていますが、以降は明確に分けて話を進めます。

誤検知の分類

• 検知漏れ
  • 検知すべき悪性のリクエストを検知できない
• 過検知
  • 正常なリクエストを悪性として検知してしまう

両者の違いを整理し、AWS WAFではどのようなアプローチが取れるのかを具体的に説明していきます。

検知漏れが発生する主な要因

検知漏れとは、検知すべき悪性のリクエストを見つけ出せなかったことを言います。
このコラムではWAFのルールで検知できなかったものを指します。例えば、AWS WAFでルールを設定したが、ブロック・カウントに関わらずどのルールにも検知できなかった場合です。

AWSマネージドルールの選定不足

検知漏れが発生する要因の一つが、選択したAWSマネージドルールの不足です。
AWSマネージドルールはユーザーに代わりAWSがルールの管理をしてくれますが、自組織のWebサービスにどのルールが必要なのかは自分たちで選ばなければなりません。選んだルールが不足していれば、攻撃者による悪意のあるリクエストを検知することなく、Webサービスを危険にさらすことになります。

AWSのドキュメントでは、AWSマネージドルールグループごとにどのような検知を行うのかが記載されています。
不足を補うのであれば、まずは細かい個々のルール単位よりも、ルールグループ単位でどのようなユースケースに対応しているのかを確認し、要・不要を判断するのがいいでしょう。
特にWAFの導入当初では、ルールが多すぎるよりも不足している方が攻撃に気づけないためにリスクが高くなります。多すぎたルールについては後から不要なルールを削除すれば問題ないと割り切り、一時的にログを多くとる戦略も考えられます。

関連記事：AWS WAFのAWSマネージドルールについて選定ポイントと重要性を解説

カウントモードの対象が大きい

正常なリクエストがAWSマネージドルールによってブロックされてしまった場合、一般的にはそのルールのアクションをカウントモードにして運用を行います。
この時にルールごとカウントモードにすることが適切でない場合があります。

よくあるパターンとしては、AWSManagedRulesCommonRuleSet(コアルールセット (CRS) マネージドルールグループ)のSizeRestrictions_BODYなどです。このルールは8KB以上のリクエストのボディを検知します。
Webサービスにファイルアップロード機能などを持つ場合に、このルールがブロックしてしまうので、カウントモードにすることがあります。

ただ単にルールをカウントモードにしてしまうと、同じ保護パック内のすべてでこのルールでのブロックができなくなってしまいます。
実はこのSizeRestrictions_BODYはAWS WAFの検査仕様に深く関連するルールとなっていて、AWS WAFは一定サイズ以上のリクエストに対する検査に制限があります。
具体的には、Application Load Balancer(ALB)ではリクエストのボディが8KBまでを検査対象にすることができますが、あふれ出た部分については検査しません。例えば、ALBとAWS WAFの組み合わせでは、8KB以内に悪意のある攻撃コードが含まれていれば、AWS WAFは検知しブロックすることが可能です。しかし、8KB以降に攻撃コードがあった場合には攻撃があったことさえ気づけません。

このようにルールをカウントモードにすることで生じるリスクを考えたうえで、設定を変更する必要があります。

過検知が発生する主な要因

過検知とは、正常なリクエストを悪性として検知してしまうことを言います。
検知漏れと同じく、本コラムではブロック・カウントに関わらずWAFで検知したものを扱います。過検知の影響としては、正常なリクエストをブロックすることによるサービス影響や、日ごろの運用の中で精査しきれないほどの大量のログが出てしまうなどがあります。

ブロックモードへ移行する際の確認漏れ

過検知の要因はいくつか考えられますが、その一つにはルールをカウントからブロックに移行する際の事前の確認漏れが挙げられます。
通常、ルールを新たに追加した際には、カウントモードで誤遮断が発生しないかを確認した後にブロックモードへ移行しますが、この事前の確認が甘いと正常通信がブロックされてしまい、サービスに影響を与えてしまいます。

注意点としては、必ずしも新規のルール追加でのみ発生するわけではありません。

• サーバー側に変更があったために、今までブロックで問題なかったが、正常通信を誤遮断するようになってしまった。
• マネージドルールの更新に伴い、今まで検知されなかったものが過検知されてしまった。

こういった要因がいくつかあります。クラウドは変わりやすい特性を持っています。特性を十分に把握したうえでWAFのルール運用に臨むのも重要なポイントです。

確認漏れを抑えるポイント

確認漏れを抑えるためには、一例として以下のようなポイントを押さえましょう。

正常通信の網羅性を高める

よく使われるサービスだけでなく、サービスを網羅的に確認する必要があります。
例えば、E2EテストをWAFを入れた状態で実施することで、あまり利用されないサービスを含めてカウントモードによるログを取得することができます。リクエストのサイズに対するルールなどもあるので、色々なパターンを試すことが重要です。

検証環境で精査した後に、本来環境へ適用する

これには2つの効果が期待できます。1つ目は検証環境でよく確認してから本番環境へ適用というステップを踏めることで、こちらは検証環境を用意する目的そのものです。

もう一つは検証環境はカウントモードの精査をするのにやりやすい環境を作りやすいためです。通常、本番環境は外部に広く公開されているため、絶えず攻撃者によるリクエストが届きます。検証環境であればリクエストできるクライアントを制限したり、制限できなくても正常通信を特定がしやすい状況を作りやすいはずです。こういったノイズが少ない環境を用いて、ブロックにしてもいいルールを精査しましょう。

カウントモードの時間を一定期間確保する

カウントモードで一定期間確保することでログを集めるアプローチです。リクエストの偏りが出てしまう可能性はあるので、他のアプローチも併用したいところですが、簡単に実施できることがメリットです。

不必要なルールが入っている

AWSマネージドルールの不足の反対で、今度は自組織に本来は不要なルールを追加してしまった場合です。
極端な例では「WebサーバーでLinuxを利用しているが、Windows用のルールも適用してしまった」場合です。この例では、恐らく精査しきれないほどの大量のログは出ないですし、誤遮断も少ないはずです。それでも確認不要なログが混入することで日ごろのログ確認作業の邪魔になることが考えられます。

対策も同様で、ルールグループ単位でどのようなユースケースに対応しているのかを確認し、要・不要を判断しましょう。
不足しているぐらいであれば、ルールが多くなる方がリスクは少なくなります。運用を通して、不要なルールの削減や調整を行うことが重要です。

上述のように誤ったルールを入れなければ避けられる問題だけではなく、どうしようもない場面も度々発生します。例えば、ルールグループ全体としては必要ですが、そのうちの一部のルールが不要である場合です。
AWSManagedRulesCommonRuleSet(コアルールセット (CRS) マネージドルールグループ)はベースラインルールグループの一つで、一般的な脅威に対応するルールです。このルールグループはAWS WAFを利用する場合にはまず検討してほしいルールグループの一つですが、汎用的に利用できる反面、自組織にそぐわないルールがある場合があります。例えば、NoUserAgent_HEADERというルールがありますが、これは単にUser-Agentが欠落しているリクエストを検知します。しかし、User-Agentがないだけでは検知したくないユーザーにとっては不要なルールになるので、カウントに設定することになります。この場合にもカウントで検知したログは出力されるので、結果としてこちらも日ごろのログ確認作業の邪魔になることがあります。

不必要なログを制限する方法

不必要なログを抑えるための完全な解決は難しいですが、方針としては3通りあります。

1.スコープダウンステートメントによる検査対象の制限

スコープダウンステートメントを利用することで、検査する対象を絞ることができます。スコープダウンステートメントとはルールの対象を絞ったり、反対に除外したい場合に利用できる機能で、この対象にマッチしないものはルールによる検査は行われず、ログにも出なくなります。条件に合えばスコープダウンステートメントを利用することで、不要なログを抑えることができます。

2.ラベルマッチステートメントでブロック

これも条件が合えば利用できるものです。単純にカウントにするのではなく、後段にラベルマッチステートメントを利用したルールを追加することでリクエストをブロックする条件を増やし、カウントモードでオリジンサーバーに届くリクエスト数を減らすというものです。例えば、NoUserAgent_HEADERについて、日本以外のリクエストはブロックしても問題ない場合には、「NoUserAgent_HEADERのラベルを持っていて、リクエスト元が日本でないリクエストをブロックする」というルールを作成できます。

3.運用でカバー

前述した2つ方法が利用できれば良いですが、たいていの場合で十分でなく、現実的には運用でカバーすることも多くあります。この場合には、NoUserAgent_HEADER単体ではログを監視しない、といった運用ルールを決め、ログ分析を行うなどが考えられます。

WAFエイドによるサポート

WAFエイドでは弊社から提供するカスタムルールの誤検知確認に加えて、追加のオプションでAWSマネージドルールグループの選定と調整も行っています。
WAFエイドを導入いただくことで、以下のような実運用に即した付加価値をご提供しています。

独自開発の検知ルール(シグネチャ)を追加してWAF製品の検知力を強化

一般的なマネージドルールではカバーしきれない脅威に対し、当社が独自に開発した検知シグネチャを追加します。これにより、攻撃検出の精度をさらに高めることが可能です。

お客様ごとの環境に応じたAWSマネージドルール選定支援

ご要望に応じて、業種・Webアプリの構成・通信パターンなどに基づいた最適なAWSマネージドルールの選定（オプション）を支援します。導入直後から過不足のないセキュリティ対策が実現できます。

ルール運用・管理のアウトソースが可能

WAFの導入はあくまでスタートです。運用フェーズでは、日々のログ監視やルールの調整など、継続的な対応が必要になります。WAFエイドをご活用いただくことで、そうした運用業務の多くを当社側で担い、お客様の負担を大幅に軽減することが可能です。

WAFの自動運用サービスWAFエイドの詳細はこちら

おわりに

本コラムでは誤検知が発生する要因やその影響、そして対応方針について解説しました。
誤検知はサービスへの影響や見つけるべき攻撃をスルーしてしまったり、運用への負担など様々な箇所へ影響を与えうるものです。つまり、誤検知を抑えることでサービスの安全性や継続性を高めることにつながります。本コラムが一助になれば幸いです。