WAFを「どこでHTTPを止めるか」で理解する：SiteGuard・ModSecurity・WAPPLES・AWS WAFの違い

はじめに

WAF（Web Application Firewall）を調べていると、同じ「WAF」という名前なのに、かなり違う製品が出てくる。

例えば次のようなものだ。

• Apache に組み込んで使う SiteGuard Server Edition
• OSS の WAF エンジンである ModSecurity
• 専用機器や仮想アプライアンスとして置く Penta Security WAPPLES
• AWS のマネージドサービスである AWS WAF

最初は「全部 WAF なら、何が違うのか」が分かりにくい。

結論から言うと、理解するときの軸はかなり単純である。

HTTP リクエストを、アプリケーションへ到達するまでの「どこ」で検査・遮断するのか。

この記事では、WAF をこの配置場所の違いから整理する。

---

1. そもそも WAF は何を見ているのか

一般的なネットワークファイアウォールは、主に IP アドレスやポート番号などを見て通信を制御する。

一方 WAF は、HTTP/HTTPS の中身を見て Web アプリケーションへの攻撃を検知・遮断する。

例えば、次のような攻撃が対象になる。

• SQL Injection
• Cross-Site Scripting（XSS）
• OS Command Injection
• Directory Traversal
• Local File Inclusion
• 不審な Bot
• HTTP Flood などの一部の L7 DoS

OWASP も WAF を、HTTP アプリケーションに対してルールを適用する Application Firewall と説明している。

参考: OWASP - Web Application Firewall

例えば、次のようなリクエストが来たとする。

GET /users?id=1%27%20OR%20%271%27=%271

WAF は URI、Query String、Header、Body などを検査し、ルールに一致すればアプリケーションへ到達する前に遮断できる。

重要なのは、WAF は「Web アプリケーションの前に置く箱」だけを意味するわけではないという点だ。

---

2. WAF は「製品名」ではなく、配置方法がいくつもある

ざっくり分けると、次のような構成がある。

種類	代表例	WAF が動く場所
ホスト型	SiteGuard Server Edition	Web サーバー上
OSS WAF エンジン	ModSecurity	Web サーバー / Proxy
アプライアンス型	WAPPLES	Web サーバーの前段
仮想アプライアンス型	WAPPLES SA	VM / Cloud 上の前段
クラウドマネージド型	AWS WAF	AWS の保護対象リソースと連携

イメージするとこうなる。

Internet
   |
   v
[ Cloud / Appliance WAF ]
   |
   v
[ Apache / Nginx ]
   |
   +-- Host WAF
   |
   v
[ PHP / Java / Node.js ]
   |
   v
[ Database ]

つまり、同じ WAF でも HTTP リクエストの処理経路のどこに割り込むか が違う。

---

3. SiteGuard Server Edition：Web サーバー自身に WAF を入れる

SiteGuard Server Edition は、EG セキュアソリューションズが提供するホスト型 WAF である。

公式には Apache、Nginx、IIS に対応している。

参考:

• SiteGuard Server Edition - 推奨動作環境
• SiteGuard Server Edition - ディレクティブによる設定

Apache の場合、イメージは次のようになる。

Internet
   |
   v
+----------------------------+
| EC2 / Physical Server      |
|                            |
|  Apache                    |
|   |                        |
|   +-- SiteGuard            |
|   |    HTTP request 検査   |
|   |                        |
|   v                        |
|  PHP / Application         |
+----------------------------+

Web サーバーの中でリクエストを検査するため、WAF 専用の別サーバーや物理アプライアンスを前段に置かなくても導入できる。

SiteGuard Server Edition は、攻撃パターンを定義したシグネチャを中心に HTTP/HTTPS リクエストを検査する。

例えば Apache へのリクエストが、

Client
  |
  v
Apache
  |
  v
SiteGuard による検査
  |
  +-- 攻撃と判定 --> Block
  |
  +-- 正常と判定 --> PHP

という流れになる。

👉 SiteGuard は Apache の外側にある別のファイアウォールではなく、Apache などの Web サーバー側で動作するホスト型 WAF と考えると分かりやすい。

「Apache モジュールとして動く」とは

ここは、アプライアンス型 WAF との違いを理解するうえで重要である。

SiteGuard Server Edition の Apache 版は、別のネットワーク装置を 1 台追加するのではなく、Apache のモジュールとして Web サーバーのリクエスト処理に組み込まれる。

概念的には次のように考えればよい。

Client
  |
  | HTTPS / HTTP
  v
+--------------------------------------+
| Apache                               |
|                                      |
|  接続を受ける                        |
|      |                               |
|      v                               |
|  HTTP request を解釈                 |
|      |                               |
|      v                               |
|  SiteGuard が request を検査         |
|      |                               |
|      +-- Block --------------------+  |
|      |                            |  |
|      v                            |  |
|  Handler / PHP / Reverse Proxy    |  |
|                                   |  |
+-----------------------------------|--+
                                    |
                              Error response

つまり、SiteGuard は Apache より前にある独立したネットワークホップではない。

👉 Apache が HTTP リクエストを処理する流れの中に WAF 検査が入る。

公式資料でも、Apache 版では httpd.conf や .htaccess から、検査の ON/OFF、監視モード、シグネチャ除外、接続元 IP による除外、ログ出力先などを設定できると説明されている。

これは、SiteGuard が Apache の設定・リクエスト処理とかなり密接に統合されるタイプの WAF であることを示している。

参考: SiteGuard Server Edition - ディレクティブによる設定

HTTPS の中身はどうやって見るのか

「HTTPS なら暗号化されているのに、Apache 内の WAF はどうやって SQL Injection を見るのか」と疑問に思うかもしれない。

Apache 自身で TLS を終端している場合、概念的には次の流れになる。

Client
  |
  | TLS で暗号化
  v
Apache / mod_ssl
  |
  | TLS を復号
  v
HTTP request
  |
  v
SiteGuard / ModSecurity
  |
  v
Application

WAF が検査するのは、TLS の暗号文そのものではなく、Web サーバー側で復号され、HTTP として処理されるリクエストである。

ALB や CloudFront などで TLS を終端している構成では、バックエンドへ HTTP で渡すのか、再度 HTTPS にするのかで経路は変わる。ただし、WAF が HTTP の中身を検査するには、どこかの地点で TLS が終端されている必要がある。

メリット

• ネットワーク構成を大きく変えずに導入しやすい
• Web サーバー単位で保護できる
• 商用製品としてシグネチャや管理機能、サポートが提供される

注意点

WAF の検査処理も同じホスト上で行うため、Web サーバー側の CPU / メモリなどのリソースを使用する。

また、Web サーバーが複数台になれば、それぞれへの導入・設定・運用を考える必要がある。

---

4. ModSecurity：WAF の「エンジン」

ModSecurity は OWASP が管理する OSS の WAF エンジンである。

もともとは Apache HTTP Server のモジュールとして開発されたが、現在は Apache 以外の環境でも利用できる。

参考: OWASP ModSecurity

ここで重要なのは、

ModSecurity と攻撃検知ルールは別物

という点だ。

ModSecurity が「HTTP を検査するエンジン」だとすると、実際に「何を攻撃と判断するか」を定義する代表的なルールセットが OWASP Core Rule Set（CRS） である。

ModSecurity
   |
   +-- WAF Engine
   |
   +-- OWASP CRS
        |
        +-- SQL Injection
        +-- XSS
        +-- LFI / RFI
        +-- Protocol Attack
        +-- その他の攻撃検知ルール

OWASP CRS は ModSecurity や互換 WAF 向けの汎用的な攻撃検知ルールセットとして提供されている。

参考: OWASP CRS

Apache で考えると、概念的には次のようになる。

Internet
   |
   v
+-----------------------------+
| Apache                      |
|                             |
| ModSecurity                 |
|    +                        |
| OWASP CRS                   |
|    |                        |
|    +-- Request inspection   |
|                             |
| Application / PHP           |
+-----------------------------+

mod_security は Apache 標準機能ではない

名前から Apache 標準モジュールのように見えるが、ModSecurity は Apache 本体に標準搭載された WAF ではなく、別途導入するモジュールである。

ModSecurity 2.x では、Apache 側では代表的に次のようにモジュールをロードする。

LoadModule security2_module modules/mod_security2.so

つまり Apache にとっては、mod_ssl や mod_proxy などと同じように request lifecycle に参加する追加モジュールの 1 つとして動く。

参考: ModSecurity Reference Manual - Installation for Apache

ModSecurity は Apache のどこで動くのか

ModSecurity 2.x は、Apache の request cycle に対して 5 つの processing phase を持つ。

Phase	名前	主に見られるもの	タイミング
1	Request Headers	URI、Header、Cookie など	Request Header 読み込み直後
2	Request Body	Form、JSON、XML、Upload など	Request Body 読み込み後
3	Response Headers	Status、Response Header など	Response Header 送信前
4	Response Body	HTML / JSON などのレスポンス本文	Response Body 送信前
5	Logging	Transaction 全体	Logging 直前

公式リファレンスでは Phase 1 は Apache が Request Header を読み終えた直後の post-read-request で処理される。

Phase 2 は、Request Body を読み終えたあとに動く。アプリケーション向けの入力検査の多くはここで行われる。

参考: ModSecurity Reference Manual - Processing Phases

Apache の処理と重ねると、概念的にはこうなる。

Client
  |
  v
Apache receives request
  |
  v
+--------------------------------------+
| Phase 1: Request Headers             |
|  Host / User-Agent / URI / Cookie    |
+--------------------------------------+
  |
  v
Request Body を読む
  |
  v
+--------------------------------------+
| Phase 2: Request Body                |
|  Form / JSON / XML / Upload          |
+--------------------------------------+
  |
  v
PHP / Java / Reverse Proxy / Handler
  |
  v
Application generates response
  |
  v
+--------------------------------------+
| Phase 3: Response Headers            |
+--------------------------------------+
  |
  v
+--------------------------------------+
| Phase 4: Response Body               |
+--------------------------------------+
  |
  v
Client
  |
  v
+--------------------------------------+
| Phase 5: Logging                     |
+--------------------------------------+

ここから分かるのは、ModSecurity は単純に、

Apache -> ModSecurity -> PHP

という 1 回だけの直列処理ではないということだ。

Request を受け取る途中と、Application が Response を返した後の両方に検査ポイントを持てる。

例えば Phase 1 なら Header を早い段階で拒否できる。

SecRule REQUEST_HEADERS:User-Agent "BadBot" \
    "id:1001,phase:1,deny,status:403"

POST Body まで見たいなら Phase 2 を使う。

SecRule ARGS "(?i:select.+from)" \
    "id:1002,phase:2,deny,status:403"

※ 上のルールは processing phase を理解するための単純化した例であり、本番の SQL Injection 対策としてそのまま使うものではない。実運用では OWASP CRS などの体系化されたルールセットを利用する。

👉 WAF が Apache の中で動くというのは、「PHP の直前に 1 回だけチェックする」という意味ではない。少なくとも ModSecurity では、Apache の request / response lifecycle の複数地点へ処理を差し込める。

Apache で使う ModSecurity のバージョンに注意

ModSecurity には大きく v2 系と v3 系がある。

v3 では WAF エンジン本体が libmodsecurity として Web サーバーから分離され、Apache や Nginx などから Connector を介して呼び出す構造になった。

Apache
  |
  v
ModSecurity-apache Connector
  |
  v
libmodsecurity v3

ただし、OWASP ModSecurity の Apache Connector 公式 README は、現時点で Apache Connector v3 を production ready ではないとしており、Apache HTTP Server では ModSecurity v2.9.x を推奨している。

参考: ModSecurity v3 Apache Connector

👉 「ModSecurity は v3 が新しいから Apache でも v3 を使えばよい」と単純には言えない。Apache と組み合わせる場合は、この実装状況を確認する必要がある。

SiteGuard と ModSecurity は何が違うのか

ここは混同しやすい。

	SiteGuard Server Edition	ModSecurity
提供形態	商用製品	OSS
主な役割	WAF 製品一式	WAF エンジン
ルール	ベンダー提供シグネチャ	CRS 等を組み合わせる
サポート	ベンダーサポート	OSS / 商用サポートを別途検討
Apache 内で動作	できる	できる

👉 「Apache に WAF を入れる」という構成だけを見ると似ているが、製品としてルールや運用機能まで含めて提供される SiteGuard と、ルールエンジンとしての ModSecurity では立ち位置が違う。

CRS を入れれば終わりではない

WAF では誤検知（False Positive）が問題になる。

例えば、正常な入力値の中に攻撃パターンに似た文字列が含まれていると、WAF が誤って遮断することがある。

そのため、本番環境では、

検知モード
   |
   v
ログ確認
   |
   v
誤検知の除外・ルール調整
   |
   v
遮断モード

のように段階的に導入することが多い。

WAF は入れた瞬間に完成するものではなく、アプリケーションに合わせたチューニングも運用の一部である。

---

5. WAPPLES：Web サーバーとは独立した WAF

Penta Security（ペンタセキュリティ）の WAPPLES は、Web Application / API Protection 製品である。

現在は WAF だけでなく API や Bot なども含めた WAAP（Web Application and API Protection）として位置付けられている。

参考: Penta Security - WAPPLES

WAPPLES の特徴は、Apache の中にモジュールとして入れるのではなく、Web サーバーとは独立した装置として配置できることである。

例えば Reverse Proxy 構成なら、

Internet
   |
   v
+----------------+
| WAPPLES        |
| WAF / WAAP     |
+----------------+
   |
   v
+----------------+
| Apache/Nginx   |
| Web Server     |
+----------------+
   |
   v
Application

となる。

公式には Reverse Proxy、Inline、HA など複数の構成に対応している。

ハードウェア型 WAPPLES

物理アプライアンスとしてデータセンターやオンプレミス環境に配置する。

Internet
   |
   v
Router / Firewall
   |
   v
[ WAPPLES Appliance ]
   |
   v
Web Server群

Web サーバー群の前段に集約して配置できる点が、各 Web サーバーへ導入するホスト型 WAF との大きな違いになる。

WAPPLES SA

WAPPLES SA は Software Appliance、つまり仮想アプライアンス版である。

Penta Security の公式情報では AWS、Azure、Google Cloud などのクラウド環境や、KVM、VMware、Hyper-V などの仮想環境に対応している。

参考: Penta Security - WAPPLES SA

Cloud / Virtual Environment

        Internet
           |
           v
   +----------------+
   | WAPPLES SA     |
   | Virtual WAF    |
   +----------------+
       |       |
       v       v
    Web #1   Web #2

👉 SiteGuard / ModSecurity が Web サーバーの中に入るのに対して、WAPPLES は Web サーバーとは独立した WAF 層を作るという違いがある。

---

6. AWS WAF：AWS リソースと関連付けるマネージド WAF

AWS WAF は AWS が提供するマネージド型 WAF である。

Web ACL にルールを定義し、CloudFront、Application Load Balancer、API Gateway などの保護対象リソースに関連付ける。

参考:

• AWS WAF - What is AWS WAF?
• How AWS WAF works

例えば ALB を保護する場合、論理的には次のように考えられる。

Internet
   |
   v
+----------------------+
| AWS WAF Web ACL      |
|                      |
| - Managed Rules      |
| - IP Set             |
| - Rate Based Rule    |
| - Custom Rule        |
+----------------------+
   |
   v
+----------------------+
| ALB                  |
+----------------------+
   |
   v
ECS / EC2
   |
   v
Application

ただし、AWS WAF という EC2 インスタンスや仮想アプライアンスが ALB の前に存在するわけではない。

Web ACL を AWS リソースに関連付け、保護対象リソースに届く HTTP(S) リクエストを AWS WAF が検査するというマネージドサービスである。

AWS の現在のコンソールでは Web ACL を含む設定を Protection Pack と表現する画面もあるが、基礎概念として Web ACL と Rule を理解しておけばよい。

Web ACL と Rule

AWS WAF では、Web ACL の中に Rule を設定する。

Web ACL
 |
 +-- AWS Managed Rules
 |
 +-- IP Set Rule
 |
 +-- Rate Based Rule
 |
 +-- SQL Injection Rule
 |
 +-- XSS Rule
 |
 +-- Custom Rule

Rule に一致したリクエストに対して、

• Allow
• Block
• Count
• CAPTCHA
• Challenge

などのアクションを設定できる。

Managed Rules

AWS WAF では、自分で全ルールを書く必要はない。

AWS Managed Rules や AWS Marketplace の Managed Rule Group を利用できる。

AWS WAF
 |
 +-- 自作ルール
 |
 +-- AWS Managed Rules
 |
 +-- Marketplace Managed Rules

ここは ModSecurity + CRS と少し似ている。

• ModSecurity：WAF エンジン
• CRS：攻撃検知ルール
• AWS WAF：マネージド WAF
• Managed Rule Group：AWS WAF に組み込む管理済みルール群

もちろん内部実装は別物だが、「エンジンとルールを分けて考える」という意味では理解しやすい。

---

7. 4者を「HTTP をどこで止めるか」で比較する

最も重要な違いを表にするとこうなる。

	SiteGuard	ModSecurity + CRS	WAPPLES	AWS WAF
種類	ホスト型 WAF	OSS WAF	Appliance / Virtual Appliance	Cloud Managed WAF
主な配置	Web Server 内	Web Server / Proxy	Web Server 前段	AWS Resource と連携
Apache への導入	あり	あり	不要	不要
専用 WAF ノード	不要	構成次第	必要	AWS が管理
ルール管理	Vendor	CRS / 自前	Vendor	AWS / Marketplace / 自前
インフラ管理	自分	自分	自分	AWS
スケール時	各 Server を考慮	各 Server / Proxy を考慮	WAF 層をスケール	AWS サービス側
主な利用イメージ	既存 Web Server 保護	OSS で柔軟に構成	DC / On-Prem / Virtual Appliance	AWS ネイティブ構成

配置だけ並べるとさらに分かりやすい。

SiteGuard / ModSecurity

Internet
   |
   v
Web Server
+------------------+
| Apache           |
|  + WAF           |
|  + Application   |
+------------------+

WAPPLES

Internet
   |
   v
WAPPLES
   |
   v
Web Server
   |
   v
Application

AWS WAF

Internet
   |
   v
AWS WAF による検査
   |
   v
CloudFront / ALB / API Gateway
   |
   v
Application

👉 全部 WAF だが、WAF を動かす責任範囲と HTTP リクエストを止める位置が違う。

---

8. AWS WAF と SiteGuard を同時に使う意味はあるのか

ある。

WAF は必ずどれか 1 つだけ選ばなければならないわけではない。

例えば、

Internet
   |
   v
CloudFront
   |
   +-- AWS WAF
   |
   v
ALB
   |
   v
EC2
   |
   +-- Apache
       |
       +-- SiteGuard
       |
       +-- PHP Application

という多層防御も可能である。

AWS WAF で、

• 大量アクセス
• IP / Geo 条件
• Bot
• AWS Managed Rules

などを前段で処理し、さらに Web サーバー側でも SiteGuard や ModSecurity を使う、といった構成が考えられる。

ただし WAF を増やせば単純に安全性が 2 倍になるわけではない。

• ルールの二重管理
• 誤検知調査
• ログの相関
• 障害切り分け
• コスト
• レイテンシ

も増える。

👉 「何段入れるか」より、どの層で何を防ぐのかを決めることの方が重要になる。

---

9. WAF は脆弱性を直してくれるわけではない

ここも重要。

WAF が SQL Injection を遮断できたとしても、アプリケーションの SQL Injection 脆弱性そのものが修正されたわけではない。

脆弱な Application
        ^
        |
      WAF
        ^
        |
     Attacker

WAF が攻撃リクエストを止めているだけで、WAF を外せば脆弱性は残っている。

したがって、

❌ WAF を入れたから Parameterized Query は不要

❌ WAF を入れたから XSS 対策は不要

とはならない。

WAF は Secure Coding、脆弱性診断、パッチ適用などを置き換えるものではなく、アプリケーションの前に追加する防御レイヤーとして考えるのが適切である。

---

10. どの WAF を選ぶかではなく「どこに責任を持たせるか」

今回の 4 つを整理すると、

SiteGuard
  -> Web Server に WAF 機能を持たせる

ModSecurity + CRS
  -> OSS の WAF Engine + Rule Set を Web Server / Proxy で動かす

WAPPLES
  -> 独立した Appliance / Virtual Appliance に WAF 機能を持たせる

AWS WAF
  -> AWS の Managed Service に WAF 機能を持たせる

という違いになる。

製品名から覚えるより、

HTTP リクエストが Application に届くまでの、どの地点で検査されているのか

を見ると理解しやすい。

そして、その配置場所はそのまま運用責任にもつながる。

• Web Server に入れるなら、Web Server の更新・性能・台数を考える
• Appliance を置くなら、WAF ノードの可用性やネットワーク経路を考える
• Managed WAF を使うなら、Cloud Provider の仕組みの中で Rule / Log / Cost を管理する

WAF の違いは単なる「検知精度の違い」だけではない。

アーキテクチャそのものの違いである。

---

参考資料

• OWASP - Web Application Firewall
• OWASP ModSecurity
• OWASP Core Rule Set
• ModSecurity v3 Apache Connector
• ModSecurity Reference Manual - Processing Phases
• EGセキュアソリューションズ - SiteGuard Server Edition
• Penta Security - WAPPLES
• Penta Security - WAPPLES SA
• AWS - What is AWS WAF?
• AWS - How AWS WAF works