WAF 「SOLVDEFENCE OnSite（ソルブディフェンス・オンサイト）」

Web Alerter に関する質問

Q1. 攻撃を検知するための原理・理論にはどのようなものが利用されているのでしょうか。

A1. SOLVDEFENCEの不正アクセス防御機能「WebAlerter」は、IIS5,6,7それぞれのバージョンに最適なアーキテクチャを採用しています。
IIS5では「ISAPIフィルタ」をIIS6では「ISAPIエクステンション」、IIS7では「ネイティブモジュール」といったように、お客様の既存のアプリケーション環境の設定を変更することなく、導入いただける機構となっています。
WebServerに対するHTTP/HTTPSリクエストは、Webアプリケーションにリクエストが渡される前にWebAlerterによって、ヘッダ、データ部分の全てが検証されます。
WebAlerterでは、ビルトインデコーダによってデコードされたHTTPリクエストを、ヒューリスティックエンジンによる構文解析と、シグネチャによる解析を組合せ、検知/防御を行います。
エンジン及びシグネチャファイルを含むモジュール全体の自動更新機能により、新種の攻撃に順次対応していきます。
エンジンは内部的に定めた脅威値を加算方式で加点して,その脅威値が一定レベルを超えた場合にロギングを行い、さらに一定値を超えるとリジェクトする。という動きをとります。

Q2. ビルトインデコーダの効果と仕組みについて解説してください。

A2. 攻撃者は、ファイアーウォールやIDS（侵入検知システム）の識別パターンを回避するために、特殊なエンコード方式を複数回組み合わせてHTTPリクエストを構成します。
この際、UTF-7,UTF-8,UTF16,16進表記方式等が多く使用されますが、一般的に、汎用的な文字変換フィルタでは、複数のエンコードがかけられている文字列から攻撃コードを抽出する事は困難と言われています。
シグネチャのみに頼った検出方式では、これらの軽微な特徴の変化に追随するために多くのシグネチャメンテナンスコストを必要とします。
WebAlerterのビルトインデコーダは、攻撃スクリプトの抽出に最適化された「完全自社製の高速デコーダ」であり、攻撃者が最終的にサーバに投入しようとする攻撃スクリプトデータを取り出すことができます。

Q3. SSLによる暗号化通信(https)を行なっている場合でも、問題なく防御が可能ですか？
（httpの時と比べ、できることの差異はありますか？）

A3. SSLでも問題ありません。
WebAlerterは、IISによって復号化された後のデータに対して評価を行います。
また、HTTP/HTTPSともに出来ることの差異はございません。

Q4. Windows上で動かしているApacheの防御も可能ですか？

A4. IIS以外のWebサーバの防御をすることはできません。
基本構造として、IIS専用のAPI（ISAPIおよびIIS Module）を採用しているためIISに対するアクセスのみが検証対象になります。
尚、JSP/サーブレット（Apache/Tomcat)を、IISをフロントエンドとして動作させるケースでは、適切にTomcat ISAPIリダイレクタを構成することによりWebAlerterの防御下でTomcatを動作させる(※)ことができます。

※IIS6.0 Extension ,IIS7.0Moduleで運用される場合のみ動作します。製品仕様上、IIS5.0およびIIS6.0のIIS5.0互換モードでは、TomcatリダイレクタとSOLVDEFENCE WebAlerter Filterは共存動作できません。

Q5. 攻撃を検知しアラームをあげるだけでなく、自動防御も可能ですか？

A5. はい。自動防御します。HTTPリクエストを構文解析し、脅威値を加点方式で評価します。
一定以上の脅威値を持つリクエストは、ログをとり、さらに脅威値が高いものはリジェクトされます。

Q6. インターネットからの自動更新について教えてください。また、その頻度はどのくらいですか？

A6. 一日一回、NECネクサソリューションズのデータセンターで稼動しているヘッドクォータサーバに、HTTPで自動接続して、最新版のモジュールが公開されていれば、それを自動的にダウンロードして管理者にメール通知します。
管理者は、IISを再起動してもよいタイミングでコンソールから「今すぐアップデートを実行」ボタンをクリックしてモジュール更新します。
規定では、上記のように更新処理には管理者の手動クリックが必要ですが、完全自動化することも可能です。
しかし、原則アップデートにはIISの再起動が伴うため、ダウンロードまでを自動化し、最終的な更新は手動で行うことを推奨します。
更新頻度は不定期ですが、半年に1，2回程度とお考えください。

Q7. シグネチャとエンジンによる検出の2種類があるようですが、それぞれの特徴を教えてください。

A7. 基本的にはエンジンによる不正アクセスの解析がメインですが、シグネチャによる検出も行っています。
シグネチャには流行している既知の攻撃（ワームやスクリプトキディの間でよく使われるExploit 等）を掲載しており、ヒューリスティックエンジンの補助的な働きをするものです。
シグネチャによって検知されたものは、件数のみがカウントされるためレポートメールのスリム化の効果があります。また、検知スピードの向上にも繋がります。

Q8. ネットワーク型WAF（ハードウェアタイプ）のWebアプリケーションファイアウォールと比較した場合の利点は？

A8. ネットワーク型は、プラットフォームに依存しない、複数サーバ上のソフトウェア管理が不要などのメリットがありますが、導入や運用にコストがかかるのがデメリットです。
ホスト型の特徴は、

1. ネットワーク環境を変更する必要がありません。
2. 障害の影響をホストに限定できます。
3. プラットフォームが限定されてしまうものの、その分安価です。

また、SOLVDEFENCEの最大の特徴としては、WAF機能だけにとどまらず、改ざん検知やログスキャン機能を利用することができます。

Q9. ヒューリスティックエンジン搭載アルゴリズムについて解説してください。

A9. V3.1.2（2010年4月）現在、下記をはじめとする、14種類のエンジンパターンで構成しています。

• XSS_CHECK_EX（XSS脆弱性の試行を検出）
• SQL_INJECTION_PROTECT_EX（SQLインジェクションによる攻撃を検出）
• ENCODE_CHECK_EX（不正エンコードを検出）

Q10. 「LENGTH_LIMITTER」で設定する文字列の長さはURLで表示される文字列の長さ以外に考慮すべき値があるでしょうか。
（たとえば、スペースは%20で置換した長さで計算する、メソッドの文字列数、POSTで渡されるストリームバッファの文字数等）

A10. LengthLimitterは、URL+QueryStringおよびHTTPヘッダの長さが設定値を超えた場合に検出し、POSTデータを含みません。
この検証は、デコード前のRAW-DATAに対して評価されるため、「%20」は3文字としてカウントします。

Q11. 1つのリクエスト中に、Threat=1およびThreat=5 の2種類の情報が含まれていた場合、1+5=6で、このリクエストは防御されるのでしょうか？

A11. 基本的には加算されて評価されますが、先に評価されたものがリジェクト対象であった場合には、その時点でリジェクトされそれ以降は評価されません。

Q12. RDS設定では[拡張設定]にてログ記録に関する脅威値の下限設定が変更できますが、
（1）これはヒューリスティックエンジンに関するサマリログ、詳細ログの両方の出力抑制に影響するものでしょうか？
（2）この設定は共通既知シグネチャーのサマリログ出力にも影響するでしょうか？
ｖ3.1.0未満のバージョンでは、RDS設定の「拡張設定」に従来あったログ記録に関する脅威値の下限設定がありましたが、新バージョンでは見当たりません。どのように設定すればよいですか？

A12. （1）両方に影響します。
（2）影響します。ログ出力関連の処理はリクエスト毎に保持している検査結果のThreatと比較した上で出力するか迂回するかを決定します。よって個々のログ出力を個別に制御することはできません。

V3.1.0以降では、ログ出力処理そのものが、共通のThreat値ではなく、アクション設定に紐づけられる形になりました。これにより、特定のアクションだけログを取るというカスタマイズの他、通過するがログだけは取る、などの柔軟な設定が可能となっています。

Q13. 単なるパターンマッチングフィルタなのですか？

A13. 違います。昨今のアタックで用いられている不正エンコード形式のアタックであっても検出可能であり、リクエスト文字列中の脅威度(Threat)をポイント評価するエンジンを内蔵しています。
これによりHTTP要求がアタックとして構成されているのか、単なるデータ部のパターンなのかを適正に判別します。

Q14. WebAlerterによって除外されたアクセスをIISのログに出力することはできないのでしょうか。

A14. IIS5およびIIS6において、Web Alerterはアタックやワームからのアクセスを別のログファイルに記録するようになっているためできません。
IIS7の場合は、以下のような識別文字列がIISのログファイルに出力されます（設定で識別文字列の出力を抑止することもできます）。
*Request_is_rejected_and_unexecuted.(by_SOLVDEFENCE_WebAlerter)*

Q15. cmd.exeに対してのアクセスが一部WebAlerterのフィルタで処理されていないようです。なぜですか？

A15. これはIISが内部でURLをマッピングする段階で処理がリジェクトされるためです。
即ち、WebAlerterの検出処理に入る前に除外されていることになります。
このようなIISのセキュリティ機能やURLScanが検出した不正アクセスはHTTPステータスコード(404_NotFound)でIISのログファイルに記録されます。

Q16. アタックを受けた時点で随時レポート出力できませんか？

A16. アタックを受けた時点でその都度メールを発行する形式の場合、昨今のインターネットの状況を考慮すると、膨大な量のメールを管理者へ送信することになってしまいます。
Webコンソールの更新間隔は、任意に設定できますので、リアルタイムな監視を実施するには、Webコンソールを使用してください。
警告メールはリジェクトできたものの集計結果としてご利用ください。
コンテンツ改ざん時のチェックはコンテンツリカバー（別機能）にて対応しています。コンテンツリカバーの警報メールは、改ざん実行時に即時発行します。
V3.1.0以降では、ログ出力処理そのものが、共通のThreat値ではなく、アクション設定に紐づけられる形になりました。これにより、特定のアクションだけログを取るというカスタマイズの他、通過するがログだけは取る、などの柔軟な設定が可能となっています。

Q17. 新規の拒否文字列（ローカルシグネチャ）はどのような場合に設定するのですか？

A17. システムオブジェクトや、特定のURLへのアクセスを個別に抑止したい場合や、新たにセキュリティホールが発見された時の緊急拒否を設定する場合です。
一つの例として、DBのテーブル名やカラム名を設定することがあります。
POSTデータやクエリストリングに、本来リクエストに含まれるはずのないテーブル名やカラム名が含まれていた場合、それを悪意あるHTTPリクエストとして除外することができます。

Q18. インストール時にOSの再起動が必要ですか？

A18. 必要ありません。ただし、IISのサービス(IISADMINおよびこれに依存するサービス)については再起動が必要です。
オートアップデートの際には、IISの全てのバージョンにおいて、IISのサービス再起動が必要になります。これは、ロードされたISAPIエクステンションおよびネイティブモジュールを、一度パージ（破棄）して、再ロードする必要があるためです。

Q19. フィルタを動作させるということから、CPU負荷が気がかりです。

A19. 1リクエストあたりのCPU負荷としては、数行のHTMLを表示するだけのActiveScriptページを実行させた場合よりも低い値となっています。複数のスレッドを並行処理する構造になっていますので、同時アクセスにより極端に性能低下するということはありません。
また、ログ出力に際してはサービスプログラムとして常駐しているS4Web Alerterサービスがキャッシュ機能を持っており、1アクセス単位でログファイルのI/Oをブロックしないように実装しております。
Webアップローダー等、数メガバイト規模の巨大ファイルを取り扱う必要のあるリクエストにおいても、その検査負荷は実用上の問題がないように配慮されております。

Q20. 除外対象の不正アクセスに対し、HTTPステータス403以外を返却したいのですが。

A20. 機能ツールプロパティのアクション設定で、任意のファイルやURLを返却する設定を行ってください。

Q21. WebAlerterをインストールした後、404NotFoundが頻発します。 一部のトップページなど静的ページは表示可能なのですが。

A21. IIS6において、ISAPIエクステンションを手動で追加した場合、設定によってはこの問題が発生することがあります。
ワイルドカードアプリケーションマッピングを追加するダイアログの「ファイルの存在を確認する」にチェックが入っている場合、動的にリンク先を生成するアプリケーションにおいて、404が返却されてしまいます。
これは、ISAPIエクステンションの仕様となります。動的にリンク先を生成するアプリケーションをご利用の場合は、上記のチェックはOFFにしてください。

Q22. 導入直後のFalsePositive（正規のリクエストを誤検知すること）を抑止したいのですが、回避策はありますか？

A22. 検知しても除外しない評価期間を設けることで誤検知を抑止できます。
ツールプロパティの「アクション設定」を変更することで、ログのみを取得するようにします。

1. SOLVDEFENCEコンソールを開きます。
2. 左側のInstallFunctionからWebAlerterを選択します。
3. ツールボタンをクリックして、機能ツールプロパティを開きます。
4. アクション設定を選択します。
5. アクション名「Default」を選択して、編集ボタンをクリックします。
6. アクション名の下にある「有効」のチェックボックスをOFFにして無効にしてOKをクリックします。
7. アクション名「LogOnly」を選択して、編集ボタンをクリックします。
8. Threat値の上限を「10」に変更してください。
9. OKを押して、機能ツールプロパティ画面を閉じます。
10. APLYボタンをクリックして、設定を保存します。

上記設定後、一定期間運用してFalsePositiveがあればチューニングを実施します。誤検知がなくなったことを確認したら、アクション設定を既定値に戻して本来の運用を開始してください。

※上記評価期間中は、攻撃を検知しても防御することはできません。

Q23. 【V3.1.0およびV3.1.1固有の問題】
V3.1.0およびV3.1.1アップデートすると、V3.0.Xでは通過していたリクエストが除外されてしまう（V3.1.2以降では従来通りの水準に変更しています）。

A23. V3.1.1以降のバージョンにおいて複数のアクションを設定できるようになりましたが、従来（V3.0.4まで）はロギングだけで除外しなかったThreat=5のものを既定でブロックするようになっています。よりセキュアな設定を試行した結果ですが、従来どおり（V3.0.4以前）の水準に戻す場合は、以下の設定によりブロックされないようになります。
アクション[Default]のThreat値下限を変更。

1. SOLVDEFENCEコンソールを開きます。
2. 左側のInstallFunctionからWebAlerterを選択します。
3. ツールボタンをクリックして、機能ツールプロパティを開きます。
4. アクション設定を選択します。
5. アクション名「Default」を選択して、編集ボタンをクリックします。
6. Threat値下限を「5」から「6」に変更してください。
7. OKを押して、機能ツールプロパティ画面を閉じます。
8. APLYボタンをクリックして、設定を保存します。

ページの先頭へ戻る