WAFとは何か — 普通のFWと何が違う？個人サイトにも必要？を噛み砕いて解説
TL;DR
WAF（Web Application Firewall）は、Webサーバーに届くリクエストの中身を検査して、不正な攻撃パターンをブロックするサービス・装置です。通常のファイアウォール（FW）は「どのIPが、どのポートに接続するか」しか見ません。WAFはその先、HTTPの中身まで見ます。
- 個人サイトにも要る？ → WordPressや問い合わせフォームを動かしているなら、あったほうがよいです。Cloudflare WAFのFreeプランならDNSを向けるだけで即日有効化できます
- WAFは万能ではない → アプリのバグ・認証の設計ミスはWAFでは防げません。多層防御の一部として扱うのが正しい使い方です
- 現実解 → 個人〜中小規模はクラウドWAFから始める一択です
WAFとは何か — 通常FWとの違い
ファイアウォール（FW）は長年ネットワーク防御の基本として使われてきました。ただFWが見ているのは「どのIPアドレスが、どのポートに来たか」だけです。Webサーバーは外部からアクセスされるためにHTTPS（443番ポート）を開けていますが、そのポートを通ったリクエストの中身までFWは検査しません。
WAFはここを補います。HTTPリクエストのヘッダー・URLのパラメータ・フォームの送信内容・Cookieまで中身を解析して、攻撃パターンと一致するものを遮断または記録します。
| 比較軸 | 通常ファイアウォール（FW） | WAF |
|---|---|---|
| どの層を見るか | L3〜L4（IP・TCP/UDP） | L7（HTTP/HTTPS） |
| 判断のもと | IPアドレス・ポート番号 | リクエストの本文・ヘッダー・クエリ文字列 |
| 防げる脅威 | 不正ポートアクセス・ポートスキャン | SQLi・XSS・CSRF・コマンドインジェクション等 |
| 防げない脅威 | アプリ層の攻撃全般 | ゼロデイ・ロジックバグ・認証欠陥 |
「個人サイトにも要る？」への直接の答え
結論から言うと、WordPressや問い合わせフォームを動かしているなら入れたほうがよいです。
理由は、Webサイトへの自動攻撃スキャンは規模に関係なく来るからです。攻撃者は特定のサイトを狙うのではなく、脆弱性がありそうなパターンを機械的に総当たりします。WordPress管理画面への総当たりログインや、プラグインの既知脆弱性を狙ったスキャンは、開設直後から飛んでくることがあります。
ただし「入れないと即アウト」というわけでもありません。静的サイト（HTMLだけで動くブログ等）はサーバー側で実行されるコードがほぼなく、攻撃の入口自体が小さいです。動的なアプリやフォームを動かしているかどうかが、判断の分かれ目になります。
WAFが防げる代表的な攻撃
SQLインジェクション（SQLi）
SQLって何？ サーバーのデータベース（住所録のような保管庫）に命令を送るための言語です。ログイン情報や投稿内容はデータベースに保存されていて、SQLで取り出したり書き込んだりしています。
SQLインジェクションは、ログインフォームや検索欄にSQL命令を紛れ込ませてデータベースを不正操作する攻撃です。脆弱なアプリでは、入力欄に ' OR '1'='1 のような文字列を入れることで、パスワードなしでログインできてしまうことがあります。WAFはリクエスト内にSQL予約語や危険な文字列の組み合わせを検出してブロックします。
クロスサイトスクリプティング（XSS）
コメント欄やURLパラメータに<script>タグを埋め込み、閲覧者のブラウザ上で悪意のあるスクリプトを実行させる攻撃です。成功するとセッションCookieが盗まれたり、フィッシングページへ誘導されたりします。WAFはHTMLタグや特殊文字のエスケープ漏れを検出してフィルタリングします。
CSRF（クロスサイトリクエストフォージェリ）
CSRF（シーサーフ）って何？ ログイン中のユーザーに、本人が意図しないHTTPリクエストを送らせる攻撃です。罠サイトを開くだけで、バックグラウンドで別サービスへの操作（送金・設定変更等）が実行される、という仕組みです。
WAFはRefererヘッダー（どこから来たリクエストか）などを検査して不審なリクエストを弾きます。ただしCSRFはアプリ側のトークン実装と組み合わせるのが基本で、WAFだけに頼るものではありません。
パストラバーサル（ディレクトリトラバーサル）
URLや入力値に ../../etc/passwd などの相対パス記号を埋め込み、公開を意図しないシステムファイルを読み取る攻撃です。WAFはパス文字列に ../ が含まれるリクエストを検出してブロックします。
OSコマンドインジェクション
ユーザー入力をシェルコマンドとして実行するアプリの欠陥を突く攻撃です。WAFはシェルで意味を持つ特殊文字（;・|・&など）の危険な組み合わせを検出します。
WAFの検知方式：シグネチャ型とふるまい検知型
シグネチャ型（ルールベース）
シグネチャって何？ ウイルス対策ソフトで言う「ウイルス定義ファイル」と同じ概念です。「このパターンが来たら攻撃とみなす」というルール集です。
既知の攻撃パターンをルールとして登録し、リクエストと照合してブロックする方式です。OWASP ModSecurity Core Rule Set（CRS）が代表例で、SQLiやXSSのパターンが数百件以上定義されています。既知の攻撃に強く処理が速い反面、ルールに存在しない新しい攻撃や、パターンを意図的に変形した攻撃は見逃す可能性があります。
ふるまい検知型（アノマリ検知）
正常なトラフィックのベースラインを学習し、そこから外れたリクエストを異常とみなす方式です。未知の攻撃にも対応できる反面、誤検知（後述）が増えやすいです。クラウドWAFの上位プランで採用されることが多いです。
実用上はシグネチャ型を基盤に、ふるまい検知で補完する構成が標準的です。
WAFの設置場所：クラウド型・アプライアンス型・ホスト型
クラウド型WAF
インターネットとオリジンサーバーの間にリバースプロキシとして挿入する形態です。Cloudflare WAF・AWS WAF・Fastly Next-Gen WAFが代表例で、DNSを向け直すだけで導入できます。インフラ管理コストが低く、個人〜中小規模ではこれが現実解になります。
Cloudflare WAFでBotをブロックする設定の詳細はこちら
アプライアンス型WAF
専用ハードウェアをデータセンターに設置する形態です。大規模エンタープライズや、インターネットに直接つながらないオンプレミス環境で使われます。イニシャルコストが高く、専門の運用担当が必要です。
ホスト型WAF（ソフトウェア型）
WebサーバーのモジュールとしてインストールするタイプでModSecurityが代表例です。設定の自由度が高い分、管理コストも高く、VPSや専用サーバーを自分で管理している環境が対象です。
| 形態 | 導入コスト | 運用コスト | 向いている規模 |
|---|---|---|---|
| クラウド型 | 低い | 低〜中 | 個人〜中規模 |
| アプライアンス型 | 高い | 高い | 大規模エンタープライズ |
| ホスト型（ModSecurity等） | 中 | 中〜高 | 自前VPS管理者 |
誤検知（False Positive）とチューニング
誤検知（False Positive）って何？ WAFが「攻撃だ」と判断してブロックしたが、実際は正規のリクエストだった、という状態です。
WAFを導入すると、正規のリクエストが誤ってブロックされることがあります。コードを含む記事投稿フォームや、SQLを扱う管理画面のURLパラメータがシグネチャに引っかかるのが典型的なケースです。
誤検知への対処はこの順番で進めます。
- まず検知モード（Detection/Monitor）で稼働させる — ブロックせずにログだけ記録します。Cloudflare WAFでは「ログ」アクション、AWS WAFでは「カウント」モードに相当します
- ログを分析する — どのルールが、どのリクエストを捕捉しているかを確認します
- 例外（Exclusion）ルールを追加する — 特定のURLパス・パラメータ・ユーザーエージェントに対して該当ルールを無効化します。ルール全体をオフにするのではなく、スコープを絞って例外化するのが原則です
- 段階的にブロックモードへ切り替える — 例外設定が固まってからブロックに昇格させます
チューニングは継続的な作業です。アプリケーションを変更するたびに誤検知が再発する可能性があるため、デプロイ後はWAFのログを確認する習慣をつけます。
WAFは万能ではない — 多層防御の考え方
WAFがあれば安全、という理解は危険です。WAFが防げないケースを整理します。
- アプリロジックの脆弱性: 認証バイパス・IDOR（不適切な直接オブジェクト参照）・ビジネスロジック欠陥はWAFには見えません。アプリ側の実装で対処します
- ゼロデイ攻撃: シグネチャが存在しない新種の攻撃はすり抜ける可能性があります
- 正規ユーザーによる不正操作: 正常なリクエスト形式で行われる操作はWAFで区別できません
- 暗号化されたC2通信: マルウェアが感染後に行う外部通信はWAFのスコープ外です
多層防御（Defense in Depth）って何？ 「一つの対策に頼らず、複数の防御を重ねる」という考え方です。城に例えると、外堀・城壁・内堀・城門と複数の防壁を組み合わせるイメージです。WAFは外堀の一つにすぎず、それだけでは守り切れません。
WAFは多層防御の一層として機能しますが、以下と組み合わせてはじめて実効性が高まります。
- アプリケーションのセキュアコーディング（入力バリデーション・プリペアドステートメント等）
- 依存ライブラリの定期的な脆弱性スキャン
- 適切な認証・認可設計
- ログ監視とインシデント対応手順の整備
導入の現実解：クラウドWAFから始める
個人〜中小規模のWebサービスであれば、クラウドWAFから始めるのが現実的です。
Cloudflare WAF（Free〜Pro） は、DNSをCloudflareに向けるだけで有効化できます。FreeプランでもOWASP準拠のマネージドルールセットが適用され、基本的なSQLi・XSS対策はカバーされます。Proプラン（月額$20）以上でカスタムルールの柔軟度が上がり、誤検知のチューニングがしやすくなります。
AWS WAF はALB・CloudFront・API Gatewayと連携しやすく、AWSインフラで完結している場合の選択肢になります。ルール単位・リクエスト単位の従量課金のため、トラフィックが増えると費用も増える点を念頭に置きます。
どのサービスを選ぶにしても、最初の一週間は検知モードで稼働させてログを確認し、誤検知がないことを確認してからブロックモードに移行するのがリスクを抑えた進め方です。
まとめ
| 項目 | 要点 |
|---|---|
| WAFの役割 | HTTPリクエストの中身を検査し、Webアプリ層の攻撃をフィルタリングする |
| 通常FWとの違い | FWはIP・ポート制御。WAFはアプリ層（L7）の攻撃パターンを検知する |
| 個人サイトに要る？ | WordPress・フォームを動かしているなら入れたほうがよい |
| 代表的な防御対象 | SQLi・XSS・CSRF・パストラバーサル・OSコマンドインジェクション |
| 検知方式 | シグネチャ型（既知パターン照合）＋ふるまい検知型（異常検出）の組み合わせが標準 |
| 設置形態 | クラウド型が導入コスト最低。個人〜中規模ならまずここから |
| 誤検知対策 | 検知モード→ログ分析→例外設定→ブロックモードの順で移行する |
| WAFの限界 | ロジック脆弱性・ゼロデイ・認証欠陥は防げない。多層防御の一部として扱う |
| 現実解 | Cloudflare WAF FreeまたはPro。DNSを向け直すだけで即日有効化できる |