Skip to content
Ecliptic Wiki

WAFは安心を買う装置ではない

securityweb-securitywafoperation

Published Updated

はじめに

Section titled “はじめに”

WAF(Web Application Firewall)はWebサービスのセキュリティを高めるために使用される装置の一般名称です。WAFそのものの説明は割愛します。WAFはトラヒックがアプリケーションに到達する前に既知攻撃、スキャン、異常な入力、過剰なアクセスをドロップすることができる強みがあり、採用事例も多数あります。しかしWAFを導入・運用するときに本当に難しいのは、装置の導入そのものではなく

この遮断ルールは正常なユーザーを止めないのか（誤遮断がないのか） 止めた場合、誰が、どの根拠で、どこまで事業影響を受け入れるのか

ということです。WAF関連の情報は、導入手順やルールセットの説明に寄りやすい傾向があると感じています。市場に薄いのは、WAFを入れた後に残る「説明責任」と「誤遮断時の事業判断」を正面から扱う記事だと考えました。一連の主張はWAFを否定するものではありません。WAFの価値を過小評価せず、同時に「安心を買った」と誤解しないための前提を作り、かつ最も効果的にWAFを活用するためのヒントとして、導入前の意思決定、運用設計、顧客説明、インシデント時の戻し判断の助けになれば幸いです。

本稿の内容は市場に情報が薄い領域であり、あくまで私自身の経験と理解から構成されています。正確な情報は各組織の専門家へ確認願います。 　　　次の記事 --->

次のシナリオを考えてみましょう。

仮想シナリオ： ECサイトのセキュリティを高めたい

Section titled “仮想シナリオ： ECサイトのセキュリティを高めたい”
  1. WAF導入と検知モード運用

この組織では事業インパクトの大きなECサイトのセキュリティを向上させるためにWAF装置の導入を決定し、具備された推奨セットを最も低い感度で有効化することにしました。 セキュリティ担当に相談したところ「まずは検知モード（遮断実行なしのモード）にて様子を見てから、遮断に切り替えましょう」とアドバイスを受け1か月間様子を見ました。 定常的に検知（遮断候補）が1時間あたり60件ほど発生しているものの、セキュリティ担当からは「あくまでサービスの性質によりますので、システム運用担当でご判断ください。」と言われ、明確な判断根拠が決定できませんでした。加えて、何がわかれば様子を見たことになるのか、遮断して問題ないもしくは変更が必要な条件は明確に示されず、結局システム運用担当が頭をひねって決めるしかありませんでした。 マネージャーはこの遮断候補数があまり大きな数ではないと主観で判断し、本番環境へWAFの遮断モード切替を決定、本番環境への変更適用を実行しました。 念のため監視モニタでHTTPレスポンスステータスコード403の件数を監視することにしました。 定常アクセス件数全量は1時間あたり6万件、検知モードで検知されている件数（遮断候補の件数）が件数が1時間あたり60件だったので、403件数の閾値にはその5倍の300件を設定しました。その後、遮断モードで3か月運用して特に問題は発生しませんでした。

  1. インシデント発生～アクション

このECサイトで最もトラヒックが多くなる年に1度のイベントの日、開始時刻の午前10時を超えてしばらくして監視モニタが鳴り、HTTPレスポンスステータス403件数の異常が検知されました。401（認証エラー）, 404（NotFoundエラー）のモニタは正常でした。 確認すると定常値の約100倍ペースである10分あたり6000件のトラヒックがステータスコード403で遮断されていました。 加えてお客様からも「画面に403という文字が表示されている」「スマホアプリが真っ白になっている」「ログインに失敗してマイページに入れない」との申告が発生し、緊急体制の確立が宣言されました。 イベントに備えた体制は確保していたものの、WAFによる遮断が異常値を示すことは想定外だったため、急ぎWAFに詳しいセキュリティ担当の招集を行いました。セキュリティ専門担当からは以下の見解が示されました。 「システムログからわかることは、ステータスコード 403 のログ件数が平時より明らかに多いことと、ログに記録された範囲では正常トラヒックと乖離した特徴は見いだせないこと。攻撃を受けているのかもしれないし、誤遮断を起こしているのかもしれない。」 続けて、ネクストアクションとして以下の選択肢が示されました。

  • 選択肢1: 短期のサービス継続性を優先し、WAFの遮断モードを解除する。それによりWAFによる403遮断影響を解消する。
  • 選択肢2: 攻撃を受けている前提でトラヒックの分析を行う。ただしログからは不正アクセスの兆候が見えず、アプリケーションの業務性質と仕様を踏まえた検討をする必要があるため、システム構成図、アプリケーション仕様書等の判断根拠になる資料を準備してほしい。この作業にはお互いに情報共有と議論が必要で、事象収束までには少なくとも3時間はかかる見込み。

マネージャーは選択肢1を採用し、本番環境に対してWAF遮断モードの解除を決定。セキュリティ担当の招集や議論、本番環境への変更適用の手順書準備と承認フローの準備も含め、変更適用が完了したのは事象検知から約3時間後、13:00でした。 これで当日の影響は終息しました。

タネあかし

Section titled “タネあかし”

a. 今回想定したシナリオ

  • 定常的に誤遮断は1時間あたり6件（全体比0.01%）発生していた。発生箇所はログイン認証時のプロキシ機能を提供するマイクロサービスであった。
  • 検知モード運用では不正・正常の区別がつかないためこの少数の誤遮断予定は検知・考慮されなかった。遮断モード切替後の期間では、お客様はリトライによって事象解消し、不具合申告も上がっていなかった。
  • イベント開始後10分のトラヒックペースは定常時の100倍、10分あたり100万件になり、誤遮断は600件発生していた。件数が増加したこと、イベントに関心を持つユーザが不便を感じたことから申告が初めて発生した。
  • 加えて、イベントに関心を持つ攻撃者がスキャンツールにより10000件ほどのアクセスを実行した。認証エンドポイントにPOSTペイロードとして不正値を送信する性質の攻撃で、リクエストURL,ユーザーエージェント,IPアドレスなどログに記録される値に不自然な点はなかった。この多くが検知された結果、アラートが発報した。

b. 対応の問題点

  • 監視モニタが 403 ログ件数の異常を検知したときにどうするのか、アクションが決まっていなかった。
  • トラヒックがWAFで遮断されたとしても正常・問題なしとする基準が定められていなかった。少しの誤遮断も許さない空気があった。
  • 実際には攻撃を受けているのに、誤遮断か攻撃かを見抜けずサービス継続を優先した結果、逆に攻撃者に入口を開けてしまった

このシナリオで示したかったことは次のことです。

  • WAFはシグネチャをある程度チューニングできるものの、ヘッダ・HTTPリクエストのペイロード程度しか見えない通常のシステムログでは、不正かどうかを断定することが困難です。
  • いざ遮断事象が発生したとしても、それを説明可能にすることは困難です。運よく稚拙な攻撃で明らかな場合は誤遮断なしの判断ができますが、正常リクエストと見分けがつかない場合は判断ができません。
  • シグネチャの調整には「そのアプリケーションがどんなペイロードを正常通信で受信するか」という業務知識が必須です。
  • 導入支援を外部に委託したとしても、アプリケーションの業務性質、事業インパクトをもとに遮断を許容し、責任をとるのは運用担当になります。

特に大規模なサービスになるほど、組織では「正常なユーザが誤遮断されていないのか」という点が気にされ、なおかつ「不正な攻撃ははじきたい」という要求が発生します。上記のシナリオでお示ししたように、WAFは装置としてネットワーク経路に入っているだけでは全く足りず、組織における事業判断、業務知識、専門スキル、すべてそろってやっと運用のフィジビリティが生まれる、運用ハードルの高いものであるということを前提に置きます。本稿・周辺の稿ではWAF導入を検討されている、もしくは導入済み、どちらの立場の方にも有用な情報となればと思い執筆いたしました。

WAFは業務仕様を知らない

Section titled “WAFは業務仕様を知らない”

WAFはリクエストを見て、攻撃らしさや異常らしさを判断します。リクエストパス、ヘッダ、Cookie、クエリパラメータ、ボディ、IP、国、ASN、TLS fingerprint、振る舞いなどを材料にします。Google CloudのWAF製品であるCloud Armorなら、許可、拒否、リダイレクト、流量制限、レートリミット、事前構成WAFルールなどを利用できます。重要なのはWAFは業務仕様を知らないということです。あるサービスでは、自由入力欄にHTML断片が入ることは攻撃に見えます。一方別のサービスでは、それはCMS、テンプレート編集、教材、コード共有、問い合わせ本文として正常かもしれません。多くのWAF（注1）は「攻撃パターンに似ている」という検知はできますが、「このユーザーがこの画面でこの値を入れることは業務上正当である」という判断はできません。ここに、WAF運用の最初の壁があります。

注1: ここで挙げるWAF運用の難しさにおいては、Google Cloud, AWS, Azure, セルフホストソフトウェア型製品など、比較的一般的かつ安価なWAF製品を指して述べています。 エンタープライズ向けの高度なWAF製品の一部（e.g. Cloudflare, Akamai, radwareが提供するもの）はAIやマネージドルールによる高度な自動シグネチャ調整の機能が具備されており、この課題はライセンス費用とトレードオフで解消されることもあります。ただし本質的な難しさは変わりません。シグネチャがグローバルで適用されていれば、個々のテナントはそれらを選ぶことはできるがシグネチャ自体のチューニングは考慮されていない、と考えるべきです。これらエンタープライズ向け製品の導入に当たっても本稿の指摘を踏まえて営業担当・エンジニアから製品仕様の情報を引き出し、慎重に検討する必要があります。

誤遮断ゼロを説明するのは難しい

Section titled “誤遮断ゼロを説明するのは難しい”

多くのWAF製品では、トラヒック遮断時に適用されたポリシー、ルール、シグネチャ情報が出ます。 それでも

  • この403は不正な攻撃を止めたのか。
  • それとも正常ユーザーの正常な入力を止めたのか。

はわからないことが多くあります。なぜなら、通常のシステムログにはリクエストボディの情報が出せず、かつそこを突いた攻撃を受ける場合があるからです。仕様によってはリクエストボディの可視化ができる場合もありますが、顧客情報やパスワード、TOKEN等を含みうる領域のため機密情報保護の観点から推奨されません。多くの大企業では社内規定でこの領域の情報は最高機密指定であり、ログ出力自体を禁止されている、もしくは出すことを審査で通したとしてもセキュリティ管理・監査レベルが引き上げられ面倒なことになるといった事情があると推測しています。つまり、観測できる情報を増やすと公開・保管リスクが増える、情報を絞ると判断文脈が不足するという性質を持ちます。WAFの難しさはこの両方を同時に扱うことにあります。

検知モードは安全証明ではない

Section titled “検知モードは安全証明ではない”

検知モード（遮断を実行せず検知したことをログにも残すモード。Google CloudのCloud Armorにおけるpreviewモード）は有用です。お客様影響を出さず、ログ上で「このルールなら何が遮断候補になるか」を見ることができます。 ただし、検知モードで1か月間問題が見えなかったとしても、それは将来の正常通信が遮断されない証明ではありません。言えるのはせいぜい、

  • その期間、そのトラヒック、そのログ可視性、その判断体制では、大きな問題が見えなかった。

ということです。本番環境ではお客様の任意入力やランダムなTOKENなど、初めて出る入力があります。イベント時だけ公開されるページのアクセス、本番環境の特定顧客だけが使うパラメータ、外部連携、Webhook、古いクライアントなど、ランダム性の高い挙動は検証環境で再現されないことがあります。 つまり本番環境は入力空間が非常に広く、検証で拾いきることが難しいという性質を持ちます。検知モードは安全証明ではなく、発見手段の一つにすぎません。

WAFルールもアプリケーションも変わる

Section titled “WAFルールもアプリケーションも変わる”

WAFは一度設定したら終わりではありません。例えばWAF製品の事前構成ルールセットは更新されます。Cloud Armorが使用するOWASP CRSのルールセットも、偽陽性とチューニングを前提にしています。 そのWAF製品のベンダ側のシグネチャ更新により、過去に問題なかった入力が将来も同じとは限りません。同時に、アプリケーションも変わります。新機能やフォーム項目の増加、JSON構造の変更、外部連携が増える、ユーザー生成コンテンツの性質が変わるなどです。その変化のたびに、過去の検証や運用で得られた誤遮断軽減の一定の保証が崩れ、本質的には検証環境での網羅試験、本番環境での検知モードでの運用が必要となります（これは別に述べますが、組織の責任・線引きの問題です）。 業務・セキュリティ知識をもつ人材を常時抱え続け、試験の必要性が発生した時に開発メンバ・統制メンバ含め多数の人員稼働が発生することを踏まえ予算を確保できるのか、というのがサービス運用組織判断になります。 つまり、WAF導入は「設定」ではなく「運用」であるということです。

L7 DDoSでも同じ問題が起きる

Section titled “L7 DDoSでも同じ問題が起きる”

最近ではWAF製品にDDoS攻撃対策機能がバンドルされることが増えてきたため、これについても少し触れます。詳細には別のページで述べます。SQLインジェクション（SQLi）やクロスサイトスクリプティング（XSS）だけでなく、L7 DDoSやHTTP floodでも、同じく前述の問題が出ます。たとえばIPアドレス単位で厳しいレートリミットをかけると、企業NAT、学校、イベント会場、モバイル回線、プロキシ配下の正常ユーザーを巻き込み遮断する事故が発生する可能性があります。 また、JA3/JA4のようなTLS fingerprintもユーザーIDではありません。リクエストパス、ヘッダ、Cookieで絞っても、マルウェアに感染した多数の一般の機器をボットネットとして使用する近年の攻撃では値が分散してしまい、キーとしての意味が薄くなります。 キーごとに一定のリクエスト回数制限を設けるレートリミットは強力ですが、正規ユーザーと攻撃者を業務文脈込みで完全に分けるものではありません。 ボリュームベースで「単一リクエスト元」、もっと言うと「単一ユーザ」を区分することが価値を持つDDoS攻撃遮断の状況において、IPアドレス、JA3フィンガプリントなど、静的なキーをもってこれを特定することが難しい、というのが遮断閾値設定の難所になります。 DDoS攻撃対策についてはそこにフォーカスした記事シリーズで別途詳細に記述します。

WAFが有効な場面

Section titled “WAFが有効な場面”

WAFが無価値という意味ではありません。むしろ価値がある場面をはっきりさせるために、以下の活用意図を示します。

場面WAFの価値
既知攻撃やスキャンを減らしたい説明可能性の高い事前構成シグネチャや手組のシグネチャを選べば、定常ノイズを安全に前段で落とせる
緊急時に攻撃の特徴量が掴めた正常ユーザの巻き込み覚悟で、IP、国、ASN、path、UA、headerで一括遮断できる
低リスク領域に強めのルールを入れたい誤遮断時の影響が小さい範囲で厚くできる
脆弱性修正まで時間を稼ぎたい仮想パッチとして使える
バックエンド課金やリソース枯渇を抑えたい(DDoS)アプリに届く前に落とせる

なぜこれらが有効かというと、組織が事前に「これらのルールによる遮断は誤遮断かどうかの確認をする必要がない、問題ないものとする」と決めやすいからです。もしくはモニタ検知閾値を上げ、よっぽどのことがなければ発報しないのもよいでしょう。そうなれば監視モニタではこれらの 403 遮断のログは除外でき、運用を増やさずにWAFの恩恵を得られます。 一方で、次の期待は危ういです。

期待危うい理由
誤遮断ゼロを保証したい未来の正常通信を完全には列挙できない
WAFを入れればアプリ脆弱性が解決する本質対策はアプリ側の入力検証・認可・出力処理
検知モードで問題がなければ将来も安全検知モードは観測済みトラヒックの確認にすぎない
外注すれば判断責任が消える業務上の正当性と事業影響の判断は利用組織に残る

導入前チェック

Section titled “導入前チェック”

WAFを入れる前に、最低限これを決める必要があるでしょう。

  1. どのパス / API / 資産を守るのか。逆にどこは守らないことにするのか。
  2. 誤遮断時の事業影響を誰が判断するのか。
  3. 検知モード期間に、重要導線のトラヒックが観測されるのか。
  4. 遮断モード切替後に遮断増加が観測されたら、誰がどのように切り戻し判断するのか。
  5. WAF装置のシグネチャ更新とアプリリリースによる遮断挙動変更のタイミングをどのように追うのか。

まとめ

Section titled “まとめ”

WAFは魔法ではなく、攻撃者と正規ユーザーを業務文脈込みで完全に見分ける装置ではありません。アプリケーションの前段で大きな粒度で通信を捨てるための強力な制御点です。緊急時の一時緩和、定常スキャンの削減、低リスク領域の防御といった場面でのバックエンド保護に価値があります。ただし、誤遮断なく本気のL7 exploitやDDoSだけを都合よく止める装置ではありません。件数はさておき、実務において誤遮断は発生するものととらえて運用するべきです。 重要なのは、WAFをどのリスクを下げるために、どの事業影響を受け入れて、どの範囲に適用するのか。導入によって享受できる攻撃リスク軽減メリットと誤遮断増大リスクを、提供サービス業務・事業インパクトの文脈で評価し決定することが重要です。

参考資料

Section titled “参考資料”

　　　次の記事 --->