WAF

概要

WAF（Web Application Firewall）は、Webアプリケーションの手前に立ち、届く HTTP リクエストの中身を検査して、攻撃とみなしたものを遮断する防壁です。URLやヘッダ、クエリパラメータ、POSTボディまで開いて「このパラメータに SQL の断片が混ざっていないか」「スクリプトタグが仕込まれていないか」といったアプリケーション層の観点で判定するのが特徴で、SQLインジェクションやXSSのような、アプリの実装の隙を突く攻撃への防御層として使われます。

名前に「ファイアウォール」とありますが、従来のファイアウォールとは見ている層が違います。従来型（ネットワークファイアウォール）は OSI参照モデルでいう L3/L4、つまりIPアドレスとポート番号を見て「どこからどこへの通信を通すか」を判断します。しかしWebサービスは443番ポートを全世界に開けて成り立つものなので、攻撃も正規アクセスも同じ港から入ってきます。L7（アプリケーション層）でリクエストの中身まで読まなければ区別できない — その役割を担うのがWAFです。

なぜ生まれたか

2000年代、Webアプリケーションが爆発的に増えると、攻撃の主戦場はネットワークからアプリケーションの実装へ移りました。SQLインジェクションもXSSも、プロトコル上は完全に正当なHTTPリクエストであり、ポートとIPしか見ないネットワークファイアウォールには素通しです。本来の対策はアプリのコードを直すことですが、現実には「脆弱性は見つかったが修正のリリースまで数週間かかる」「保守が終わった古いシステムやパッケージ製品で、そもそもコードに手を入れられない」という状況が至るところにありました。

コードを直せるまでの間、既知の攻撃パターンだけでも手前で堰き止められないか — この需要に応えて、HTTPを理解して中身を検査する専用の防壁としてWAFが生まれました。クレジットカード業界のセキュリティ基準 PCI DSS が「コードレビューまたはWAF」を要件に挙げたことも普及を後押しし、現在ではクラウド事業者やCDN事業者がマネージドサービスとして提供する、Web公開の標準装備になっています。

詳細

判定の仕組み — シグネチャとルール

WAFの中核は検知ルールです。古典的かつ主流なのがシグネチャ（既知の攻撃パターン）ベースの方式で、「SQLの構文断片」「ディレクトリトラバーサルに特有の文字列」「スクリプト注入の典型形」といったパターン集合とリクエストを照合します。事実上の標準ルールセットが OWASP CRS（Core Rule Set）で、OWASP Top 10 に代表される主要な攻撃カテゴリを広くカバーし、オープンソースのWAFエンジン ModSecurity 系や各クラウドのマネージドWAFで採用されています。動作モードには、検知したら即遮断するブロックモードと、記録だけして通すディテクション（監視）モードがあり、後述する誤検知対策として、導入時はまず監視モードで観察するのが定石です。

近年はこれに、レピュテーション（悪性と知られたIPからのアクセス遮断）、ボット判定、異常スコアリング（複数の弱いシグナルを合算して閾値超えで遮断）、機械学習による正常トラフィックからの逸脱検知などが組み合わさり、レート制限機能を同梱する製品も一般的です。

どこに置くか — 配置の型

WAFは通すべきトラフィックの通り道に置く必要があるため、配置はリバースプロキシの考え方と地続きです。代表的な型は3つあります。アプライアンス／ソフトウェア型は自前のネットワーク内のリバースプロキシとして（あるいはWebサーバのモジュールとして）動かす形。クラウド／CDN統合型は、DNS の向き先を事業者のエッジに切り替えるだけで、世界中に分散した CDN の入口でWAF検査を受けられる形で、現在の主流です。エッジで攻撃を落とせるため自社インフラに負荷が届かず、DDoS攻撃対策と一体で提供されることが多いのも利点です。なお、WAFが中身を検査するには TLS を一度終端して復号する必要があるため、WAFは HTTPS の終端点（またはその内側）に置かれます。

運用の主戦場 — 誤検知との付き合い方

WAF運用の最大の難所は誤検知（false positive）、つまり正当なリクエストを攻撃と誤判定して遮断してしまうことです。ルールは「攻撃によく現れるパターン」を見ているだけなので、SQLについて議論する掲示板の投稿、コード片を含む問い合わせフォーム、JSON に混ざる記号列などが平気で引っかかります。誤検知はそのままユーザーにとっての障害なので、放置すれば「WAFのせいで正規機能が壊れる」ことになり、逆に怖がってルールを緩めすぎれば検知漏れ（false negative）が増える — この綱引きがWAF運用の本質です。

実務の定石は、まず監視モードで一定期間流し、ログを見ながら自サイトの正常トラフィックに合わない ルールへ除外設定（特定パスの特定パラメータだけ検査を外す、など）をチューニングしてからブロックモードに切り替えることです。導入して終わりの「置き物」ではなく、アプリの変更のたびに誤検知が新たに生まれうる、継続的な運用対象だと理解しておく必要があります。

WAFは万能ではない — 位置づけを間違えない

最後に最も重要な位置づけの話です。WAFはパターンに一致する既知の攻撃を落とす装置であって、アプリケーションの脆弱性そのものを消すわけではありません。エンコードの工夫などでルールをすり抜ける攻撃（WAFバイパス）は常に研究されており、また認可の不備やビジネスロジックの欠陥のように「リクエスト単体はどこまでも正常に見える」タイプの脆弱性は、原理的にWAFでは守れません。

したがって本筋はあくまでアプリ側の修正 — プレースホルダによるSQL組み立て、出力エスケープ、CSP のようなブラウザ側の防御層 — であり、WAFの正しい役割は「修正が届くまでの時間稼ぎ」と「多層防御の一層」です。脆弱性が公表されてからパッチを当てるまでの窓を仮想パッチ（該当攻撃だけ狙い撃ちで遮断するルール）で塞ぐ、という使い方はまさにWAFの真骨頂です。「WAFを入れたから安全」ではなく「WAFがあるから、直すまでの間も戦える」と捉えるのが、防御側としての正しい距離感です。