【12/18】WAF の検知を最適化するためのポリシーチューニング

第 14日目は、SOC サービス開発エンジニア 佐藤華織の記事です。第 12日目で触れた WAF のポリシーチューニングについて紹介します。

---

今回は、WAF のチューニングをテーマに少しだけ書きたいと思います。まず、WAF のチューニングを簡単に言うと、導入箇所に合わせてセキュリティポリシーを設定することです。

Web サイトには様々な特性があります。広く公開されていて不特定多数からのアクセスがある会社やお店のサイト、特定の組織・会員でのみ利用されるサイト、何でも投稿できるサイト、特定のデータを投稿するサイト…… などなど挙げたらキリがありませんが、Web サイトの使われ方・作り方など Web サイトの特性によって、通信の特性も異なります。

WAF を導入しても通信の特性に合わせたチューニングができていないと、そのサイトでは正常とされている通信も WAF で誤検知してしまうケースが多々あります。それは、誤検知をしてしまうようなシグネチャ・ルールを有する WAF が悪いのではなく、WAF を効果的に機能させるために WAF を運用する側の人間が正しく WAF を設定していないことが主な原因です。

WAF のシグネチャには、攻撃コードそのものを検知させるものもあれば、攻撃で利用される文字列や攻撃をするための調査通信など直接的な攻撃ではないが攻撃に繋がるような通信を検知させるものもあります。攻撃にはいろいろなパターンがあるため、それらのパターンをくまなく引っ掛けられるように、WAF が有するシグネチャ群にはたくさんのアプローチで攻撃を検知する仕組みが用いられています。ただ、それをそのまま利用してしまうと WAF を効果的に利用することができません。

みなさんもスマートフォンを購入したら初期設定のまま使い続けますか？ スマートフォンを作ったメーカー側は、広くいろんな人に購入してほしい思いもあるのでしょう、あんな機能やこんな機能も搭載しているのかもしれませんが、使用者は自分の使いやすいように特定の機能を OFF もしくは ON にしたり、便利なアプリをインストールしたりしますよね。せっかく購入したスマートフォンを最大限有効に使用するために使用者の生活習慣、趣味などに合わせてカスタマイズしていると思います。

誰かにとっては便利な機能やアプリケーションでも、また違う誰かにとっては不要な機能、アプリケーションだったりします。それと同じように、WAF も保護する対象に合わせて、セキュリティポリシー（シグネチャ群）のカスタマイズ＝チューニングが必要になります。適切なチューニングを行うために、弊社 WAF サービスではチューニングレポートというものを提供しています。

では、そのチューニングというのは、以下のステップで進めます。

• WAF を導入したあと一定期間収集します。
• 検知ログを分析し、レポートにまとめ、シグネチャの設定内容（ブロックするか、無効にするか）を提案します。
• そのレポート結果から WAF に設定するシグネチャをお客さま（もしくは Web アプリの構築ベンダ）にて正常通信であるか否かを判断し、シグネチャの設定内容を決定していいただきます。

分析では、何万件ものログを見ることが多いです。1つのシグネチャで数千件検知することは珍しくなく、そのようなシグネチャが複数検知されていたりします。それら 1つ 1つのシグネチャの検知ログを人の目で見ています。既知の攻撃通信を見つけることは比較的簡単ですが、保護対象の Web サイトにとって正常な通信を検知してしまっているのでは？と誤検知の精査をするためにもログを眺め、その Web サイトがどのような目的で利用されているのか推測しています。正常通信の誤検知になりそうな例を 2つほど挙げてみます。

Web アプリケーションへの攻撃の 1つで有名な SQL インジェクション攻撃があります。Web サイト上にユーザからの入力を受け付けるフォームがある場合、そのフォーム内に不正な SQL 文を入力し、送信することで攻撃を行います。この SQL 文にはいくつかパターンがあり、WAF もその様々なパターンに対応したシグネチャがあります。

通常は SQL インジェクション攻撃と見なされる文字列でも、偶然の一致で悪意のない通信が検知されることもあります。例えば、ログイン画面で以下のように実装されていた場合、

SELECT user_id FROM account_table WHERE user_id=’ユーザID’ password=’パスワード’

UserID/Password を入力するフォームに以下のような文字を入力します。

‘ OR ‘1’ = ‘1’ --

そのとき、Web サーバを通してデータベースサーバには以下のような SQL 文が送られます。

SELECT user_id FROM account_table WHERE user_id=’ ‘ OR ‘1’ = ‘1’ -- ’ password=’’

ここで、以下のような Web メールを利用したユーザのメール文を見てみましょう。

SQL インジェクションと友達に送った Web メール、2つの通信で Web サーバに送られる文字に同じ文字が含まれます。それは、「’」と「OR」です。この文字があれば WAF が検知するという単純なものではありませんが、その他複合的な条件が一致した場合には、悪意のない通信も検知してしまうときがあります。

次に、もっと簡単な誤検知例「強制ブラウジング」。攻撃者は様々なパスを推測してアクセスし、機密情報などが含まれる公開すべき情報ではないディレクトリ・ファイルに対してアクセスを試みます。ディレクトリ・ファイルに対して適切なアクセス制御をしていない場合、アクセスに成功され情報が漏えいします。例えば、「etc」、「test」、「sample」などなど。このようなディレクトリ・ファイルには機密情報や非公開情報が入っているのではないか、と推測が容易です。

ただ、「sample」というページは一般的なURLにも使われていそうな単語ですよね。商品のサンプルページなどで「http://www.example.com/item/sample」というページはありそうです。この場合も、単純にこの単語だけで WAF が検知するかは別ですが、これらの例のように WAF が保護する Web サイトがどのように利用されているのかを通信傾向から推測し、誤検知を1つでも減らすために分析を行い、チューニングレポートして提供しています。

今回は誤検知を排除するためのチューニングにスポットを当てましたが、誤検知ばかりではなく、ちゃんと攻撃通信もたくさん検知しています。それらから Web サーバ・Web アプリケーションを守るために昨日のブログにもある通り、脆弱な状態にしておかない、適切なアクセス制御を行う、などの Web サーバ側のセキュリティ対策を図り、その上で適切にチューニングした WAF を利用し、多重防御でリスクの低減を図りましょう！