WAFとは？仕組み・種類・導入判断を情シス向けに整理

WAFとは、Webアプリケーションに届くHTTPリクエストの中身を検査し、SQLインジェクションやクロスサイトスクリプティングのような攻撃を遮断する仕組みです。Web Application Firewallの略で、「ワフ」と読みます。通信の宛先ポートやIPアドレスを見るファイアウォールとは違い、URLのパラメーターやフォームの入力値といった、アプリケーションが受け取る中身そのものを見ます。

この記事では、WAFが何を見て何を止めるのかを、オープンソースのWAFエンジン（ModSecurity）とOWASP Core Rule Set（CRS）を検証用のコンテナで動かした結果をもとに説明します。そのうえで、種類の選び方、置き場所、誤検知との付き合い方、導入を急ぐべきサイトと後回しでよいサイトの見分け方を、情シスが判断に使える形で整理します。

WAFとは：何を見て、何を止めるのか

WAFが検査するのは、リクエストのURL・クエリ文字列・ヘッダー・Cookie・本文（フォームやJSON）です。HTTPSの通信は暗号化されているので、WAFはTLSを終端した後、つまり復号した平文を見られる位置に置く必要があります。検証では、nginxにModSecurityとCRSを組み込んだ公式コンテナをバックエンドの前に置き、次のリクエストを送りました。

一方、WAFには原理的に止められない攻撃があります。他人の注文番号をURLに入れて閲覧できてしまう認可の不備（IDOR）は、リクエストの形が正常と区別できません。フィッシングで盗まれた正しいID・パスワードでのログイン、クーポンを何度も使えてしまうといった業務ロジックの欠陥も同じです。WAFは「形のおかしい入力」を止める道具で、アプリケーションの脆弱性の修正や、認証の強化の代わりにはなりません。

判定の仕組み：シグネチャ・異常スコア・許可リスト

多くのWAFは、既知の攻撃パターン（シグネチャ）に一致したら遮断する「ネガティブセキュリティモデル」を土台にしています。CRSはこれを1行ごとの即時遮断ではなく、得点の合計で判断します。一致したルールの重大度に応じて点数が加算され（CRITICALなら5点）、合計が閾値（既定は5点）に達したところで、最後の判定ルール949110が遮断します。検証のSQLインジェクションは942100の1件で5点となり、ちょうど閾値で止まりました。パストラバーサルは5つのルールが重なって30点です。

この方式の利点は、1つのルールが軽く誤反応しても、それだけでは遮断しないように調整できることです。CRSには「パラノイアレベル」（1〜4）があり、上げるほど検査するルールが増え、攻撃の見逃しは減りますが、誤検知は増えます。既定は1で、一般的な業務サイトはまず1のまま運用し、金融や管理画面のように誤検知の手間より見逃しの損失が大きい部分だけを上げる、という使い分けが現実的です。

反対の考え方が、許可したものだけを通す「ポジティブセキュリティモデル」です。APIのように受け付ける値の形式が決まっているなら、OpenAPIの定義に沿わないパラメーターや型を拒否する設定のほうが、シグネチャより確実に効きます。クラウド型のWAFでは、これに加えてIPアドレスごとのレート制限や、ボットの判定も同じ画面で設定できるのが一般的です。公開済みの脆弱性に対し、アプリの修正が間に合うまでの間だけ該当のパターンを遮断する使い方は「仮想パッチ」と呼ばれます。

WAFとファイアウォール・IPSの違い

3つは置き換えではなく層の違いです。443番を開けたWebサーバーでは、ファイアウォールは443番への通信をすべて通すので、その先の中身を見るのがWAFの役目になります。逆に、WAFを入れてもSSHやデータベースのポートが外に開いていれば意味がないので、ポートの絞り込みはファイアウォールで先に済ませます。

WAFの種類：クラウド型・ソフトウェア型・アプライアンス型

中小規模の組織で最初に検討するのはクラウド型です。ルールの更新を事業者に任せられ、DDoS対策やレート制限も同じ画面で扱えるからです。ソフトウェア型は費用を抑えられ、閉じたネットワークでも使えますが、誤検知の調整とルールの更新を自分たちで回す体制が前提になります。ModSecurityは現在OWASPのプロジェクトとして開発が続いており、Go言語で書かれた互換エンジンのCorazaもあります（執筆時点）。

WAFはどこに置くべきか：ロードバランサーとの順序とオリジンの保護

置き場所の原則は2つです。1つはTLSを終端した後の平文を検査できること、もう1つはWAFを迂回してアプリケーションに届く経路が残っていないことです。AWSを例にすると、AWS WAFは独立した機器として経路に挟むのではなく、CloudFrontやALB（Application Load Balancer）、API Gatewayに関連付けて使います。ALBに関連付けた場合、ALBは転送先に振り分ける前にWAFの判定を受けます。CloudFrontとALBを組み合わせるなら、WAFはCloudFront側に付け、ALBはCloudFrontからの通信しか受けないように制限する構成が一般的です。

CDN型のWAFで多い失敗が、オリジンサーバーのIPアドレスへ直接アクセスされる迂回です。DNSの過去の記録や、証明書の発行記録、メール送信のヘッダーからオリジンのアドレスが知られると、攻撃者はWAFを通らずにアプリケーションへ届きます。オリジンのファイアウォールでCDN事業者のIPアドレス帯以外からの443番を拒否するか、外向きの接続だけでつなぐトンネル方式にして、オリジンの受信ポートをそもそも開けない構成にします。

クラウド型のWAFには、検査するリクエスト本文のサイズに上限があるものがあります。たとえばAWS WAFをALBに関連付けた場合、本文の検査対象は先頭の8KBまでです（執筆時点）。上限を超えた部分をどう扱うか（検査せず通す、遮断する）はルールごとに設定できるので、大きなJSONやファイルを受け付けるAPIでは、超過分が素通りしていないかを必ず確かめてください。

WAFの弱点：誤検知とその直し方

WAFの運用で一番手間がかかるのは、正規の利用者を止めてしまう誤検知です。検証では、問い合わせフォームの本文に「昨日のSQLの例です: SELECT name FROM users WHERE id = 1 UNION SELECT password FROM admins」と書いて送信すると、SQLインジェクションを探すルール942190と942270が発火して10点になり、403で拒否されました。SQLについて質問したいだけの利用者にとっては、フォームが壊れているのと同じです。

直し方の原則は、ルール全体を止めるのではなく、「どのURLの、どの項目で、どのルールを」外すかまで絞ることです。CRSでは次のように書けます。

# /contact の comment 欄だけ、誤検知した2つのSQLiルールの検査対象から外す
SecRule REQUEST_URI "@beginsWith /contact" \
    "id:1001,phase:1,pass,nolog,\
    ctl:ruleRemoveTargetById=942190;ARGS:comment,\
    ctl:ruleRemoveTargetById=942270;ARGS:comment"

この除外を入れると、同じ文面の問い合わせは200で通るようになりました。一方、同じ文面を /search に送った場合や、/contact の別の項目（name）に入れた場合は、引き続き403で止まりました。さらに、前置きの文章を消してSQL文だけを送ると、今度は別のルール942100が発火して403になりました。除外したのは2つのルールだけなので、ほかの検査は生きているということです。除外は「発火したルール番号をログで確かめ、その番号とその項目だけを外す」を守れば、守りを大きく崩さずに済みます。

誤検知の報告を受けて、WAFを丸ごと検知のみに戻したり、パラノイアレベルとは無関係にルールのカテゴリ全体（SQLインジェクション全般など）を無効にしたりするのは避けてください。除外の範囲が広がるほど、攻撃がそのまま通る穴になります。除外の設定には、理由と追加した日、確認した人をコメントで残し、半年ごとに見直します。

導入判断：WAFが要るサイト、後回しでよいサイト

WordPressのサイトでCDNのWAFを有効にする具体的な設定は、WordPressサイトのセキュリティ対策で扱っています。「脆弱性診断で指摘が出たから、とりあえずWAF」という判断もよくありますが、WAFで止まるのは診断で見つかった脆弱性のうち入力の形で判別できるものだけです。認可の不備などは、アプリケーション側で直す計画と並行させてください。

小さく始める導入手順

1. 対象の棚卸し：公開しているWebアプリケーションのホスト名、オリジンのIPアドレス、ログインやフォームのURLを一覧にする。
2. 検知のみで開始：遮断せずログだけを取るモード（ModSecurityなら SecRuleEngine DetectionOnly、クラウド型ならカウントやログのみの動作）で2週間ほど動かす。
3. ログの確認と除外：発火したルールを、URLと項目ごとに集計する。正規の操作で発火しているものだけを、前述の範囲を絞った除外で外す。
4. 遮断に切り替え：問い合わせ窓口に「403の画面が出たら連絡を」と伝えたうえで遮断を有効にし、1週間は403の件数を毎日見る。
5. 迂回経路の確認：オリジンのIPアドレスへ直接アクセスできないことを、社外の回線から確かめる。以後はポートの棚卸しと一緒に定期的に確認する。

5の確認は、自社が管理するオリジンのIPアドレスに対して、社外の回線から443番に接続できるかを見るだけで十分です。ポートの確認方法はnmapでのポートの棚卸しにまとめています。

よくある質問

WAFとは何ですか？

Webアプリケーションに届くHTTPリクエストの中身を検査し、SQLインジェクションやXSSなどの攻撃を遮断する仕組みです。Web Application Firewallの略で「ワフ」と読みます。CDNやクラウドのサービスとして使うクラウド型と、Webサーバーに組み込むソフトウェア型が主流です。

WAFとファイアウォールの違いは何ですか？

ファイアウォールは送信元・宛先のIPアドレスやポートで通信を許可・拒否し、443番を開けたら中身は見ません。WAFはその443番を通ってきたHTTPの中身、つまりURLのパラメーターやフォームの入力値を見て、攻撃のパターンを遮断します。役割が違うので、両方を組み合わせて使います。

WAFはどこに置くべき？ALBとどっちが先？

TLSを終端した後の平文を検査でき、WAFを迂回する経路がない位置に置きます。AWS WAFは機器として経路に挟むのではなく、ALBやCloudFrontに関連付けて使い、ALBは振り分けの前にWAFの判定を受けます。CloudFrontを使うならそちらに付け、ALBはCloudFrontからの通信だけを受ける設定にします。

WAFの弱点は何ですか？

認可の不備や業務ロジックの欠陥、盗まれた正しい認証情報でのログインなど、リクエストの形が正常なものは止められません。正規の入力を遮断する誤検知の調整も必要です。オリジンへ直接アクセスされると迂回され、クラウド型では本文の検査サイズに上限がある点にも注意します。

まとめ

WAFは、復号したHTTPの中身を見て、形のおかしい入力を止める層です。CRSのように得点の合計で判断する方式では、発火したルール番号がログに残るので、誤検知は「URL・項目・ルール番号」まで絞って除外できます。置くときはTLS終端の後であることと、オリジンへの迂回経路を塞ぐことを確認し、導入は検知のみの期間から始める。認可の不備や盗まれた認証情報は別の対策で守る、という線引きを最初に関係者と共有しておくと、WAFへの過度な期待による事故を防げます。

次に読む

• Cloudflare Tunnel（cloudflared）で自宅サーバーをポート開放なしで公開する
• nginxでリバースプロキシを構築する：複数サービスの振り分け・WebSocket・ヘッダー設定