WAF の誤検知とは?なぜ重要で、どのように対処できるのか?

投稿日

はじめに

Web サイトや Web アプリケーションを攻撃から守ることは、ますます重要になっています。サイバー攻撃のニュースは、軽度の被害から深刻な損害まで、毎月のように報じられています。2025年4月には、英国の小売業者 Marks & Spencer が攻撃を受け、推定4億ドルの売上損失を招きました。

こうした執拗な脅威に対処し、リスクを管理する最も効果的な方法は何でしょうか。

Web サイトや Web アプリケーションにとって最善の防御アプローチは、複数の独立した防御層を組み合わせて利用することです。これは「タマネギの層」にたとえられます。防御の一つの層を突破されても、中心にあるアプリケーションを守るために、その外側にはまだ複数の層が機能し続けているのです。

Diagram showing defense in depth, where inbound attacks are repelled by multiple layers of defense.

WAF の追加: メリットとデメリット

メリット

Web アプリケーションファイアウォール (WAF) は、重要な防御層の一つです。WAF は Web トラフィックのフローを監視し、悪意のある可能性のあるトラフィックを検出してプロアクティブにブロックします。公開されている Web サイトやアプリが攻撃者にとっての「狙いやすい標的」となるのを防ぐことができます。インターネット上で公開されているすべての Web サービスは、WAF を導入すべきです。多くのセキュリティ基準 (PCI DSS など) や組織には、WAF による防御を義務付ける厳格なセキュリティポリシーが存在します。

デメリット

WAF の導入によるセキュリティ上の利点が非常に大きいにもかかわらず、落とし穴はあるのでしょうか?

気を付けなければならないのは、WAF が提供するセキュリティルールやチェックを追加することで、誤検知 (false positive) が発生する可能性があるということです。これは、WAF の背後にある Web サービスの通常の動作を妨げることにつながります。誤検知は、ユーザーにも、それを修正するエンジニアにも苦痛をもたらし、まるで「モグラ叩き」のような終わりのない作業になることがあります。

このブログでは、WAF を使用する際の誤検知の問題について説明し、Progress LoadMaster 360 の強化された WAF 機能を使用して誤検知を簡単に軽減する方法を紹介します。次のようなトピックを取り上げます。

  • 誤検知とは何か?
  • 誤検知が問題となるのはなぜか?
  • 誤検知はどのように解決できるのか?
  • LoadMaster 360 の強化された WAF 機能はどう役立つか?

誤検知とは何か?

Progress Kemp LoadMaster に組み込まれている WAF も含め、WAF の基本的な処理の流れは同じです。ユーザーから受信した各 HTTP リクエストに対して、一連のルールが順に実行されます。これらの「WAF ルール」は、それぞれ異なる悪意ある挙動や異常な挙動を検出するように設計されています。

WAF ルールの例としては、以下のようなものがあります:

  • リクエストに Host ヘッダーが欠けていないか? (Web リクエストの標準的な要素)
  • リクエストが 不審なファイルタイプにアクセスしようとしていないか? (例:.bat、.conf、.ini)
  • リクエストに SQL コマンドが含まれていないか? (SQL インジェクション攻撃の可能性)

正当な HTTP リクエストであれば、WAF の検知ルールを問題なく通過し、無害なものと見なされます。その場合、WAF はその正当なリクエストを受け入れ、次のようにアプリケーションサーバーへと処理を進めることができます。

Diagram showing a legitimate request passing through a set of WAF detection rules, which all show ‘green’ and the request is ‘Accepted’.

 

では、正当なリクエストが WAF の検知ルールに一致してしまった場合はどうなるでしょうか?これは誤検知、False Positive、と呼ばれるエラーで、誤ったルールによって正当なリクエストが潜在的に悪意のあるものと見なされ、WAF によって拒否される可能性があります。

一連のWAF検出ルールを通過する正当なリクエストを示す図で、そのうちの1つは誤検知を示す「赤」を示し、リクエストは「拒否」を示しています。」 class=

誤検知が問題となるのはなぜか?

ユーザーエクスペリエンスの低下

誤検知が引き起こす最も直接的な問題は、ユーザーエクスペリエンスの悪化です。例えば、オンラインストアで「注文を送信」ボタンを押した途端に「403 Access Denied(アクセス拒否)」エラーが表示され、先に進めなくなる状況を想像してみてください。これは非常に苛立たしい体験です。誤検知によってリクエストがブロックされると、本来のユーザーが必要な操作を行うことを妨げてしまいます。

Diagram showing a mock-up app malfunctioning and returning “Access Denied”.

不満を抱いたユーザーはクレームを出すかもしれません。その結果、関係者からの圧力により、根本的な問題を解決するために WAF を無効化、あるいは撤去するよう求められる可能性があります。しかし、そのような対応はユーザビリティのためにセキュリティを大きく犠牲にすることを意味します。

アラート疲労

WAF が多数の誤検知を発生させると、本物の攻撃はそのノイズに埋もれてしまいます。これにより、重要なセキュリティインテリジェンスが失われてしまう恐れがあります。さらに、誤検知ばかりを頻繁に通知する WAF は「誤報が多い」と認識され、運用チームやセキュリティチームがアラートを軽視するようになるのは自然な流れです。その結果、実際の攻撃が見逃されるリスクが高まります。

Mock-up of an alert from a WAF showing “287 unread alerts.

コンプライアンス (機密情報)

誤検知の原因は、多くの場合ユーザーが入力するデータです。例えば、ユーザー名、パスワード、配送先住所などが該当します。WAF ルールが誤ってそのような入力にマッチしてしまうと、該当データが WAF のログファイルに書き込まれます。つまり、パスワードや住所などの情報がプレーンテキストで記録されてしまうのです。これは GDPR、CCPA、PCI DSS などのデータ保護規制に違反する可能性があるため、誤検知は放置せず、発生を防ぐ必要があります。

誤検知を引き起こし、ログに記録されてしまった個人情報の例:

Screenshot of a WAF log line example.

誤検知はどのように解決できるのか?

音量を下げる:誤検知を無視してもいいのか?

できるだけシンプルで摩擦の少ない方法を目指して、一部の商用 WAF ベンダーは誤検知の問題に対して、ほとんど無視するというアプローチを取っています。これは通常、報告を控える (完全にブロックされるイベントでない限りルール一致を表示しない) ことや、WAF の感度を低く設定する (リクエストが多数のルールに一致しない限りブロックしない) といった形で実施されます。

これにより、静かで手間の少ない運用が可能になりますが、セキュリティが弱くなり、攻撃の検出が困難になります。また、誤検知を隠すことで、調査や修正が難しくなります。

Oscilloscope-style diagram showing a noisy signal and a quiet signal.

ノイズを消す:誤検知を完全に解消する

最も効果的でセキュアなアプローチは、誤検知が発生したときに「チューニングによって取り除く」ことです。検知ルールが誤って一致し、誤検知が発生した場合は、必ず調査すべきです。

例えば、誤検知を引き起こしているルールが、対象の Web アプリケーションに関係のないものである場合 (例:アプリで PHP は使用していないのに、PHP インジェクション検知ルールが適用されている)、そのルールは無効化できます。すると、そのルールが生み出していたノイズ、つまり誤検知は即座に消えます。

誤検知が Web アプリケーションの特定の部分でのみ発生し、それ以外では問題なく機能している場合、そのルールを問題が起きる箇所だけで無効化できます。もし /webstore/quote-form だけで問題が起きているなら、そこだけ対象から外せば誤検知は解消されます。

特定のユーザー入力が繰り返し誤検知を引き起こしている場合もあります。例えば、ユーザーが自由に配送メモを書いて送信できるフリーテキストボックスがあるとしましょう。この場合、そのテキストボックスを問題を起こすルールから除外する (あるいは、全ルールから完全に除外する) ことで、誤検知を取り除けます。

このように体系的に作業し、ノイズとなる誤検知をチューニングして取り除くことで、最終的に残るのは実際の攻撃だけです。これらは明確に見えるようになり、適切に調整された WAF で簡単にブロックできるようになります。

Oscilloscope-style diagram showing a noisy signal and a clear signal.

誤検知の修正: トラディショナルなアプローチ

誤検知を解消するための WAF ルールのチューニングは、ログファイルを確認し、誤検知を見つけて修正するというプロセスです。典型的な戦略としては、まず最も重大な誤検知から解決することです。見つけ出し、完全に修正し、そしてこの作業を繰り返します。

理想的には、この初期のチューニング作業は隔離されたテスト環境で行われ、実際の攻撃を誤って誤検知と判断してしまうリスクを排除するのが望ましいです。ただ、時間やリソースの制約から現実にはそれが難しく、運用開始直後から実トラフィックで作業せざるを得ないことも少なくありません。

本物の誤検知を見極めるには、ある程度の経験が必要です。役立つ判断材料には以下のようなものがあります。

  • トリガーされたルール(頻繁に誤検知を起こすか、まれか)
  • 発信元の IP アドレス (予想されるアドレスか?所在地はどこか?)
  • アクセスされたリソース (正当な場所に見えるか?不審な場所か?)
  • アクセス時間 (業務アプリケーションが営業時間中にアクセスされたか、午前4時など異常な時間か)

こうした情報から誤検知と判断できた場合は、新しいディレクティブや新しいルールを書いて、問題を起こしているルールの動作を調整します。この際は、正規のトラフィックを通過させつつ、WAF に新たな穴を開けて攻撃を素通りさせないよう、できる限り保守的に対応することが理想です。

高性能な誤検知対応ツール: LoadMaster 360

LoadMaster 360 プラットフォームには、強化された WAF レポート機能とツール群が搭載されています。これは、WAF の誤検知を特定し解消するプロセスを、より迅速かつ容易にするために特別に設計されています。

時間を節約するスマートフィルター

誤検知のチューニングプロセスを開始する段階で、WAF のログデータは一連のスマートフィルターを通して事前にフィルタリングされます。これにより可能な限り自動化し、負担を大幅に軽減します。WAF イベントの大部分はフィルターで除外され、人間のオペレーターが確認すべき、誤検知の可能性が高い候補だけが残ります。

次のような例があります。

Screenshot of the LoadMaster 360 stats panel.

1584件の WAF イベントを手動で確認し、判断を下すことを想像すると、とても不可能に思えます。ですが、LoadMaster 360 のスマートフィルターを適用した結果、人間による確認が必要な誤検知の可能性があるイベントはわずか13件に絞り込まれました。13件という数は、1584件 (あるいは83,000件以上) に比べて、はるかに現実的な出発点になります。

自動ルールチューナー

LoadMaster 360 WAF は、誤検知が見つかった際に正しい指示を自動生成することで、チューニングを簡単にします。この自動化により高度な技術知識は不要となり、専門家でなくても WAF の設定を扱えるようになります。

Screenshot of the LoadMaster 360 rule exclusion panel.

自動ルールチューナーには、様々なオプションと機能が含まれています。

LoadMaster WAF と LoadMaster 360

ロードバランサーでパブリック Web トラフィックを処理しているなら、Web アプリケーションのセキュリティ体制を強化するために、LoadMaster WAF と、LoadMaster 360 の強化された WAF 機能を検討してみてはいかがでしょうか。

投稿日

Andrew Howe

Andrew Howe は、プログレスの Web アプリケーションファイアウォールの専門家です。自由でオープンソースなソフトウェアに情熱を注いでおり、世界中の Web アプリケーションを保護することを目的としたオープンソースのセキュリティプロジェクト「OWASP CRS」の開発者としても活動しています。イギリスのサウサンプトン在住で、アート系映画、クラシックなシンセポップ/ディスコミュージック、そしてテーブルトップゲームの愛好家でもあります。