質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

88.83%

【WAF】正常な通信を誤検知した時の対応フローについて

解決済

回答 2

投稿 編集

  • 評価
  • クリップ 5
  • VIEW 2,378

kohenro19

score 49

■依頼
WAFの導入に当たり、正常な通信を誤検知した時の対応フローを検討し、以下の通りまとめました。
対応フローは、まったくの初心者を除き、ある程度ITスキルの基礎を有した方でも対応できるような内容を目指しております。
有識者の皆様に、以下の対応フローの問題点や、ほかによい方法など様々なアドバイスを賜りたいです。

■誤検知時の対応フロー案
1) 誤検知を引き起こしたシグネチャーがブロックする攻撃名を確認する
ex) OSコマンドインジェクション

2) 以下のサイトで、攻撃名のCWE-を入力して、WEBサーバで使われるプログラム(ex. PHP, Java等)の脆弱性がないか確認する。
ex) CVE-2016-6631

http://jvndb.jvn.jp/search/index.php?mode=_vulnerability_search_IA_VulnSearch&lang=ja

3) 該当する脆弱性があれば、影響するシステムのバージョンを把握する
ex) phpMyAdmin 4.6.4 未満の 4.6.x、phpMyAdmin 4.4.15.8 未満の 4.4.x、phpMyAdmin 4.0.10.17 未満の 4.0.x

4) WAFで保護するWEBサーバがphpMyAdminを使用しているか、WEBサーバの構築業者に確認する

5) 4)の回答がyesの時、WEBサーバのphpMyAdminのバージョンが「影響するシステム」のバージョン範囲内であるか、WEBサーバの構築業者に確認する

6) 5)の回答がyesの時、誤検知を引き起こしたシグネチャーを無効にする
※シグネチャーを無効にしたときのリスクと対策についてWEBサーバの構築業者に説明する

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 2

checkベストアンサー

+4

良いか悪いかで言うと、まったく駄目と言わざるを得ないですね。
ご提案のフローですと、サーバーに該当の既知の脆弱性がなければシグネチャを無効化するようにしておられるようです。しかし、既知の脆弱性については原則としてバージョンアップや設定変更などで予め対応しておくべきです。WAFに期待したいのは、

  • プラットフォームソフトウェアに新たに発見された脆弱性
  • 自ら開発した(させた)アプリケーションの脆弱性

であり、これらはご検知が見つかった時点では既知となっていないわけです。
したがって、「この環境にはOSコマンドインジェクション脆弱性がないからOSコマンドインジェクションのシグネチャは無効化しても大丈夫」と判断しても、その後新たにOSコマンドインジェクション脆弱性が発見されたタイミングでは、WAFが対応できないことになります。そういう場面こそWAFに働いて貰いたいわけです。
なので、shoko1さんが既に指摘されているように、プロに任せた方がよろしいかと思います。


コメントいただいた内容に対して、長くなりますので、回答本文に追記いたします。

誤検知で業務影響で出ているのにWAF側で何も対応しない訳にはいかないと思います。

その通りです。なので基本的に誤検知のでるシグネチャは無効化しますが、

まず、サイト全体にわたって当該シグネチャを無効化するかどうかを検討します。
通常シグネチャが誤検知するのは特定ページ(URL)だけですので、WAFにもよるでしょうが該当URLだけ無効化できれば、無効化による防御力低下を緩和できます。

次に、シグネチャ無効化による防御力低下が許容範囲かどうかを確認します。

たとえば、たまたまStruts2の脆弱性に対するシグネチャが誤検知していて、当該サイトでStruts2を使っていない場合であれば、そのシグネチャを無効化することによる防御力低下は無視できます。
また、SQLインジェクション脆弱性のシグネチャ(の一つ)が誤検知していても、当該サイトでSQLを使っていない場合は同様です。

私が過去に経験した例では、バランサーがクッキーに100%という値をセットしていて、これがWAFで誤検知した例があります。100%はパーセントエンコード(URLエンコード)として見た場合不正な値だからという理由です。しかし、当該サイトはクッキーにはセッションIDしか入っておらず、不正なパーセントエンコードによる攻撃はできないだろうという判断から当該シグネチャは単に無効化しました。何らかの理由で無効化では不安な場合は、(1)ホワイトリストによるチェックを追加する、(2)クッキー値が「100%」という値の場合のみ当該シグネチャを無視するというルールを追加する、等の運用が考えられます。

また、当該脆弱性のシグネチャが複数あり、そのうちの一つのみが誤検知している場合は、他のルールで十分守れると判断すれば、当該シグネチャを単に無効化します。

また、CMSのサイトによくありますが、特定シグネチャが管理者ページで誤検知するが、当該ページはBASIC認証で保護されていて外部からの攻撃は想定しなくて良い場合は、管理者ページ全体で当該シグネチャを無効化するという作戦も考えられます。

最後に、上記のような無効化戦略が使えない場合はやっかいです。
私の経験では、フランス語を扱うサイトで、語尾が「'or」で終わるフランス語単語が誤検知する例がありました。これは単に無効化は危険だと思われたので、当該シグネチャを無効化する代わりに、ORを含む攻撃を防御し、かつ誤検知しないカスタムシグネチャを追加しました。

このように、誤検知対処はケースバイケースであり、フローチャートにより機械的に対応することは難しいのではないかと考えます。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/07/05 23:30 編集

    ockeghem様

    ご回答ありがとうございます。

    私もockeghem様のご意見に賛同で、
    既知の脆弱性についてはWEBサーバ側でバージョンアップや設定変更すべきだと思います。
    しかし、タイミングや金銭的な理由などの諸事情でWEBサーバ側ですぐに対応できない場合もあります。
    そのような状況で、WAFの誤検知でページが閲覧できない問題が発生した時、シグネチャーを無効化せざるをないと思います。
    しかし、単純にシグネチャーを無効化するのでなく、
    JPNICなど脆弱性情報を確認し、WEBサーバ管理者にシグネチャー無効化による影響する義務はあると思います。
    脆弱性がコーディングに起因するものであれば、影響範囲を明確にするのは難しいと思いますが、
    アプリケーションに起因するのであれば、バージョン確認だけである程度影響範囲を絞れると思います。

    誤検知で業務影響で出ているのにWAF側で何も対応しない訳にはいかないと思います。
    プロに任せたほうがいいと仰っていましたが、
    プロも誤検知があった時シグネチャーの無効化などチューニングされていると思います。
    実際の現場で異なっていましたら、申し訳ございません。
    shoko1様が、WAFはFirewallと同じというニュアンスでご説明されていましたが、
    Firewallも正常な通信がブロックされたら、リスクを許容してルールを追加しますよね。

    WAFもFirewallと同様にリスクや影響範囲を理解して、シグネチャーを無効化など対応をする必要があると思います。

    キャンセル

  • 2017/07/06 10:31

    伝わらなかったようですが、「セキュリティ技術者」がリスクを許容して設定できるのは当然で、それと同じことをフローを用意した程度では「ある程度ITスキルの基礎を有した方」には無理で、そんな運用ではWAFの費用対効果がでないと書いたつもりです。

    キャンセル

+2

「ある程度ITスキルの基礎を有した方」がどの程度と想定されているのかにもよりますが、WAFのシグネチャ調整はその程度の方には難しいと思われます。WAFのFがFirewallで、Firewallを設定・運用できるスキルと考えるとわかりやすいかもしれません。

WAFは適切な運用を前提とするソリューションで、その体制が維持できないのであれば組織内導入は難しいです。だからこそクラウド型やマネージド型のWAFが存在して、それなりに売れているという現状があります。
セキュリティ技術者の有無でどのWAFソリューションを選定するかを考えた方が費用対効果があると思われます。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 88.83%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る