本記事は、当社がWebサイトの保守とサーバー監視サービス「Previento」の運用で、WAF・ファイアウォールの設定と、すり抜けた攻撃の検知を扱う中で整理した内容をもとにしています。特定の製品を推奨するものではなく、方式の違いとして説明します。
なぜ混同されるのか
WAF（Web Application Firewall）の名前に「ファイアウォール」が含まれているため、「ファイアウォールの高機能版」「どちらか一方を入れればよい」と理解されがちです。実際には、2つは見ている場所が違います。ファイアウォールは「誰が、どの口（ポート）に来たか」を見て、WAFは「口を通ったあとの手紙の中身」を読みます。
この違いを押さえると、「ファイアウォールがあるのにサイトが改ざんされた」「WAFを入れたのにデータベースから情報が抜かれた」といった事故が、なぜ起きるのかが分かります。どちらも、自分の見ていない場所で起きた攻撃には無力だからです。
ファイアウォールとは——通信の「宛先と口」を見る
ファイアウォールは、通信の送信元・宛先のIPアドレスと、ポート番号を見て、通すか止めるかを決める仕組みです。Webサーバーなら「80番と443番（HTTP/HTTPS）は誰からでも通す」「22番（SSH）は社内のIPからだけ」「3306番（MySQL）は外部から一切通さない」といったルールを書きます。通信の中身は見ません。
形はいくつかあります。オフィスやデータセンターの出入口に置くネットワーク型（UTMと呼ばれる製品の多くもこれに含まれます）、AWSなどクラウドのセキュリティグループ、サーバーのOSに備わるホスト型（Linux の ufw・nftables、Windows Defender ファイアウォール）です。クラウド上のサーバーなら、セキュリティグループがファイアウォールの役割を担います。
- 防げるもの——SSHやデータベースへの外部からの総当たり、公開していないサービスへの到達、特定の国やIPからの通信、内部ネットワーク間の不要な通信
- 防げないもの——80番・443番を開けている限り、そこを通るWebの攻撃（SQLインジェクション・XSS・脆弱性のあるプラグインへの要求）はすべて通ります。ファイアウォールにとっては「正当なWebの通信」だからです
WAFとは——Webの通信の「中身」を見る
WAF は、ファイアウォールが通した80番・443番の通信について、HTTP要求の中身（URL・パラメータ・ヘッダー・本文）を検査します。「UNION SELECT が含まれる」「<script> が含まれる」「../ を連ねている」「User-Agent が攻撃ツールの名前」といった既知のパターン（シグネチャ）に一致した要求を、Webサーバーに届く前に止めます。
こちらも形は3つに分かれます。
| 方式 | 置き場所 | 向いているケース | 注意点 |
|---|---|---|---|
| クラウド型 | DNSを切り替え、CDN事業者などのネットワークを経由させる（リバースプロキシ型） | 公開Webサイト・EC全般。サーバーを触らずに導入でき、CDNのキャッシュも使える | DNSの切り替えが必要。元のサーバーのIPを隠さないと迂回される |
| ホスト型 | Webサーバーにモジュールとして導入（ModSecurity など） | 自社でサーバーを管理している。クラウドを経由させたくない | ルールの更新と誤検知の調整を自分で行う。サーバーの負荷が少し増える |
| アプライアンス型 | 専用機器をネットワークに設置 | 多数のサイトを社内のデータセンターで運用している | 機器の購入と保守費用。中小規模では過剰になりやすい |
- 防げるもの——SQLインジェクション、XSS、パストラバーサル、OSコマンド・インジェクション、脆弱性スキャナ、既知のプラグイン脆弱性を突く要求の多く。ログイン画面への総当たりも、回数制限の機能で抑えられます
- 防げないもの——正しいIDとパスワードでのログイン（盗まれたものでも「正常」）、注文番号を1ずつ変えて他人のページを見る連番IDの総なめ、設置されてしまったWebシェルへの通常の形のアクセス、シグネチャに無い新しい手口、そしてWebを経由しないデータベースへの直接接続やSSH経由の侵入
比較表：防げる攻撃・防げない攻撃
| 観点 | ファイアウォール | WAF |
|---|---|---|
| 見ている層 | ネットワーク層（IPアドレス・ポート） | アプリケーション層（HTTPの中身） |
| 判断の材料 | 送信元・宛先・ポート・方向 | URL・パラメータ・ヘッダー・本文のパターン |
| 主に防ぐ攻撃 | SSH・DBへの外部からの総当たり、非公開サービスへの到達、不要な内部通信 | SQLインジェクション、XSS、パストラバーサル、脆弱性スキャン、プラグイン脆弱性 |
| 防げない攻撃 | 80/443を通るWebの攻撃すべて | 正規認証でのログイン、連番IDの総なめ、Webシェルへの通常アクセス、新しい手口、DB直接接続 |
| 導入形態 | ネットワーク機器、クラウドのセキュリティグループ、OSの機能 | クラウド型（DNS切替）、ホスト型（モジュール）、アプライアンス |
| 誤検知 | ほぼ無い（ルールが単純） | 起きる。正常な入力が攻撃パターンに似ていると止まる |
| 運用の手間 | ルールは安定。開けるポートを増やさない規律が要る | ルール更新、誤検知の除外設定、検知ログの確認 |
表を見ると分かるとおり、2つは重なっていません。ファイアウォールが「口」を絞り、WAFが口を通ったWebの中身を検査する、という役割分担です。代表的な攻撃手法とログに残る痕跡は、別の記事で10種類を整理しています。
どちらが必要か——結論は「両方＋監視」
「どちらが必要か」という問いには、ファイアウォールは前提、公開Webサイトがあるなら WAF も入れる、が答えになります。順番に考えると次のとおりです。
- サーバーを持っているなら、ファイアウォールは必ず——SSHとデータベースのポートを外部から閉じるだけで、総当たりとDB直接接続という2つの大きな入口が消えます。クラウドならセキュリティグループを「必要な通信のみ」に絞ることが同じ意味を持ちます
- 公開Webサイト・ECがあるなら、WAFを——WordPressやPHP製のサイトには、脆弱性スキャンとプラグイン脆弱性を突く要求が毎日届きます。入口で止めることで、サーバーまで届く攻撃を大きく減らせます。小規模サイトならクラウド型が導入しやすい選択です
- WAFを入れても、更新と設定は続ける——WAFはシグネチャに無い手口を止められません。PHP・CMS・プラグインをサポート内に保ち、管理画面にIP制限をかけ、設定ファイルやバックアップを公開領域に置かない、という基本は変わりません
- すり抜けた攻撃に気づく層を置く——正規のパスワードでのログイン、連番IDの総なめ、Webシェルへのアクセスは、どちらも止められません。ここに監視の層が要ります
当社では、Webサーバーの守りを「入口（ファイアウォール・WAF）」「認証」「公開範囲・権限」「監視」の4層で考えています。4層の全体像と、稼働中のシステム別の組み合わせ方は、AIサイバー攻撃対策サービスのページでケーススタディ形式にまとめています。
すり抜けた攻撃に、AIのログ監視で気づく
WAFを導入すると、管理画面に毎日数百件の「遮断しました」が並びます。当社がお客様のサイトを保守する中で何度も見てきたのは、この件数を毎日通知しても、数週間で誰も見なくなることです。遮断された攻撃は、もう終わった話だからです。本当に知りたいのは「止められなかった1件」です。
そこで当社は、WAFとは別に、Webサーバー・DBサーバーのログを24時間読み取り、次のような「成功の兆候」を判定する監視を置いています。
- 攻撃への成功応答——WAFをすり抜けた攻撃の文字列を含む要求に、そのページのふだんより明らかに大きい応答が返った。設定ファイルの要求に 200 が返った
- 失敗の連続のあとの成功——ログインの失敗が続いた同じIPから、成功（302・
Accepted password）が出た。WAFは「正しいパスワード」を止められない - 公開ディレクトリのファイルの変化——アップロード領域に
.phpが新しく置かれた。Webシェルは、置かれたあとのアクセスがWAFには正常に見える - 同じIPの時系列——「偵察 → 攻撃 → 成功の兆候 → 大量取得」を同じIPでつなぎ、1件の「侵害の疑い」として通知する
判定の中で当社がつまずいたのは「成功」の見分け方でした。当初は攻撃の文字列に 200 が返れば成功の疑いとしていましたが、WordPress のサイト内検索のようにどんな文字列にも 200 を返すページで誤検知が多発しました。応答サイズをふだんと比べ、決め手のないものは「要確認」に留める、という調整を経て、通知を「本当に見るべきもの」に絞れるようになりました。この監視を担うのが、当社の「Previento（プレビエント）」です。
導入でよくある失敗
- 検知モードのまま運用している——誤検知を恐れて「記録するだけ」のモードで入れたまま、遮断に切り替えるのを忘れる。入れた直後は検知モードで誤検知を洗い出し、除外設定をしたうえで遮断モードへ移すのが手順です
- 誤検知で業務が止まる——問い合わせフォームにHTMLタグを含む文章を書くと止まる、CMSの編集画面で記事が保存できない、など。除外ルールを置く対象を「管理画面の特定の機能」に絞ると、守りを弱めずに回避できます
- 元のサーバーのIPが公開されたまま——クラウド型WAFは DNS を経由させる方式のため、サーバーのIPが直接分かれば迂回されます。ファイアウォールでWAF事業者のIP以外からの80/443を閉じて、迂回を防ぎます
- 「WAFがあるから」と更新を止める——サポート終了のPHPや古いプラグインを、WAFを理由に放置する。シグネチャに無い手口は通ります。PHP製サイトの更新と設定強化は、WAFとは別に必要です
- ログを誰も見ない——遮断件数だけを眺め、すり抜けたものを見ていない。前の節の「成功の兆候」を見る仕組みを、人の目かサービスで置きます
よくある質問（FAQ）
- Q. WAFがあれば、ファイアウォールは不要ですか？
- A. いいえ。ファイアウォールはIPアドレスとポートの単位で「どの通信を通すか」を決める土台で、SSHやデータベースのポートを外部から閉じるのはファイアウォールの役割です。WAFはWebの通信（HTTP）の中身だけを検査します。WAFはファイアウォールの代わりではなく、ファイアウォールが通した80番・443番の通信をさらに検査する追加の層です。
- Q. WordPressのサイトにWAFは必要ですか？
- A. 公開しているWordPressサイトには、入れておくことをおすすめします。WordPressはプラグインの脆弱性を狙った攻撃とログイン画面への総当たりが機械的に届くため、既知の攻撃パターンを入口で止めるWAFの効果が大きいからです。ただしWAFを入れても、本体・プラグインの更新と、管理画面へのアクセス制限は必要です。
- Q. WAFを入れるとサイトの表示は遅くなりますか？
- A. クラウド型（リバースプロキシ型）のWAFは、CDNと一体で提供されるものが多く、キャッシュの効果で表示が速くなることもあります。サーバーにインストールするホスト型は、ルールの数に応じてサーバーの負荷が増えますが、通常のWebサイトの規模で体感できる差が出ることはまれです。導入後に応答時間を計測して確認するのが確実です。
まとめ
ファイアウォールは通信の「宛先と口」を見て、SSHやデータベースへの外部からの到達を閉じる土台です。WAFは口を通ったWebの通信の「中身」を見て、SQLインジェクションや脆弱性スキャンを入口で止めます。2つは重なっておらず、公開Webサイトがあるなら両方が必要です。
ただし、正規のパスワードでのログイン、連番IDの総なめ、設置済みのWebシェルへのアクセスは、どちらにも止められません。すり抜けた攻撃の「成功の兆候」をログから見分ける監視の層を置いて、初めて守りがつながります。
当社では、ファイアウォール・WAFの設計と設定から、AIによるログ監視（Previento）までを、稼働中のシステムに合わせて組み合わせるAIサイバー攻撃対策サービスを提供しています。「WAFは入れたが、これで足りているのか分からない」という段階のご相談も歓迎です。