この記事の要点
• WAF(Web Application Firewall)は HTTP/HTTPS トラフィックを検査し、Web アプリへの攻撃を防ぐ
• SQL インジェクション・XSS・RCE など L7 攻撃をシグネチャと振る舞い検知で防御
• 運用モードは検知(Detect)とブロック(Block)があり、段階的に導入可能
WAF とは
WAF(Web Application Firewall)は、Web アプリケーションへの攻撃を防ぐために、HTTP/HTTPS トラフィックの中身を検査するセキュリティ機構です。ネットワークファイアウォールが IP・ポート・プロトコルを見るのに対し、WAF はアプリケーション層(L7)のペイロードを検査します。
なぜ必要か: SQL インジェクションや XSS などの Web アプリ攻撃は、ポート 80/443 の正常な HTTP 通信として見えるため、ネットワークファイアウォールでは防げません。WAF が HTTP の中身を検査して攻撃を検出・ブロックします。
ネットワークファイアウォールと WAF の違い
| 項目 | ネットワークファイアウォール | WAF |
|---|---|---|
| 検査する層 | L3/L4(IP・ポート) | L7(HTTP/HTTPS の中身) |
| 検査内容 | 送信元 IP、ポート、プロトコル | URL、パラメータ、Cookie、HTTP ヘッダー、リクエストボディ |
| 防げる攻撃 | ポートスキャン、DDoS(ネットワーク層) | SQL インジェクション、XSS、RCE、パストラバーサル |
| 位置 | ネットワーク境界 | Web サーバーの前(リバースプロキシ型)またはサーバー内(エージェント型) |
| 典型例 | iptables, AWS Security Group | Cloudflare WAF, AWS WAF, ModSecurity |
[クライアント]
↓
[ネットワークファイアウォール](L3/L4 でチェック)
↓
[WAF](L7 で HTTP の中身をチェック)
↓
[Web サーバー]
ポイント: ネットワークファイアウォールは「誰からのアクセスか」を、WAF は「どんなリクエストか」をチェックします。両方を併用するのが現代の標準構成です。
WAF が防ぐ主な攻撃
WAF は OWASP Top 10 に挙げられる Web アプリの代表的な脆弱性を防ぎます。
| 攻撃種類 | 内容 | WAF の検知方法 |
|---|---|---|
| SQL インジェクション(SQLi) | SQL クエリに不正な文字列を挿入してデータベースを操作 | SQL 構文のパターンマッチ(' OR 1=1-- など) |
| クロスサイトスクリプティング(XSS) | JavaScript コードを埋め込みユーザーのブラウザで実行 | <script> タグや javascript: の検出 |
| リモートコード実行(RCE) | サーバー上で任意のコマンドを実行 | system(), eval() などの関数呼び出しパターン |
| パストラバーサル | ../../etc/passwd などでファイルシステムに不正アクセス | ../ の連続や絶対パスの検出 |
| コマンドインジェクション | OS コマンドを注入して実行 | ; rm -rf /, ` |
| XXE(XML External Entity) | XML パーサーを悪用して内部ファイルを読み取り | <!ENTITY> の外部参照パターン |
| SSRF(Server-Side Request Forgery) | サーバーから内部リソースへアクセス | 内部 IP(127.0.0.1, 169.254.*)へのリクエスト検出 |
SQL インジェクションの例
# 攻撃リクエスト
GET /user?id=1' OR '1'='1 HTTP/1.1
Host: example.com
# WAF の検知
Pattern Match: ' OR '1'='1
Action: Block
XSS の例
# 攻撃リクエスト
POST /comment HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
text=<script>alert('XSS')</script>
# WAF の検知
Pattern Match: <script>.*</script>
Action: Block
ポイント: WAF はあくまで追加の防御層です。アプリケーション側でも入力検証・エスケープ・プリペアドステートメントなどの基本対策が必須です。
WAF の検知方式
WAF は大きく分けて2種類の検知方式を使います。
1. シグネチャベース検知
既知の攻撃パターン(シグネチャ)をデータベースに持ち、リクエストとマッチングします。
| 利点 | 欠点 |
|---|---|
| 既知の攻撃を高精度で検出 | 未知の攻撃(ゼロデイ)は検出できない |
| 誤検知(False Positive)が少ない | シグネチャの更新が必要 |
| 動作が軽量 | 難読化された攻撃に弱い |
# シグネチャの例
Rule ID: 1001
Pattern: /(\bunion\b.*\bselect\b|\bselect\b.*\bunion\b)/i
Description: SQL Injection - UNION SELECT
Action: Block
2. 振る舞い検知(異常検知)
正常なトラフィックのベースラインを学習し、異常なパターンを検出します。
| 利点 | 欠点 |
|---|---|
| 未知の攻撃も検出可能 | 誤検知(False Positive)が多い |
| ゼロデイ攻撃に対応 | 学習期間が必要 |
| 難読化された攻撃も検出 | 処理コストが高い |
# 振る舞い検知の例
Baseline: /api/user へのリクエストは平均 100 文字
Anomaly: 今回のリクエストは 5000 文字 → 攻撃の可能性
Action: Alert
実践メモ: 主要な WAF はシグネチャベースと振る舞い検知を組み合わせて使います。Cloudflare WAF や AWS WAF は、OWASP Core Rule Set(CRS)というオープンソースのシグネチャセットを採用しています。
WAF の運用モード
WAF には大きく分けて2つの運用モードがあります。
| モード | 英語名 | 動作 | 用途 |
|---|---|---|---|
| 検知モード | Detection / Monitor | 攻撃を検出してログに記録するが、ブロックはしない | 導入初期、誤検知の確認 |
| ブロックモード | Prevention / Block | 攻撃を検出したら通信を遮断 | 本番運用 |
段階的な導入フロー
1. 検知モード(1-2 週間)
→ ログを確認、誤検知(False Positive)を洗い出し
2. 除外ルール(Whitelist)を設定
→ 正当なリクエストを誤検知しないように調整
3. ブロックモードに移行
→ 本番環境で攻撃を実際にブロック
4. 継続的な監視・チューニング
→ 新しい攻撃パターンに対応
注意: いきなりブロックモードで導入すると、正規ユーザーのリクエストが誤検知でブロックされる可能性があります。必ず検知モードで動作確認してから移行してください。
WAF のデプロイ形態
WAF は配置場所によって3種類に分類されます。
| 形態 | 配置場所 | 利点 | 欠点 | 典型例 |
|---|---|---|---|---|
| リバースプロキシ型 | サーバーの前段(クラウド / オンプレ) | アプリ変更不要、複数サーバーを一括保護 | ネットワーク構成の変更が必要 | Cloudflare WAF, AWS WAF, F5 |
| エージェント型 | Web サーバー内(Apache/nginx モジュール) | サーバー内部で検査、暗号化後のトラフィックも検査可 | サーバーごとに設定が必要、性能影響 | ModSecurity |
| DNS ベース型 | DNS で WAF プロバイダーに転送 | 設定が簡単(DNS 変更のみ) | プロバイダー依存、オンプレでは使えない | Cloudflare(DNS 変更) |
リバースプロキシ型 WAF
[クライアント]
↓
[WAF](リバースプロキシとして動作)
↓
[Web サーバー]
- Cloudflare WAF: DNS を Cloudflare に向けるだけで導入可能
- AWS WAF: CloudFront または ALB の前段に配置
- Azure WAF: Application Gateway または Front Door に統合
エージェント型 WAF(ModSecurity)
# nginx に ModSecurity をインストール
sudo apt install libnginx-mod-security2
# nginx 設定
modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/main.conf;
[クライアント]
↓
[nginx + ModSecurity](サーバー内で検査)
↓
[アプリケーション]
ポイント: リバースプロキシ型は複数のサーバーを一括で保護でき、管理が楽です。エージェント型は暗号化後のトラフィックも検査できますが、サーバーごとに設定が必要です。
主要な WAF サービス比較
| サービス | タイプ | 特徴 | 料金 |
|---|---|---|---|
| Cloudflare WAF | リバースプロキシ(DNS) | グローバル CDN と統合、OWASP CRS、マネージドルールセット | $20/月〜(Pro プラン) |
| AWS WAF | リバースプロキシ(ALB/CloudFront) | カスタムルール柔軟、Managed Rules 利用可、AWS 統合 | $5/ルール + リクエスト課金 |
| Azure WAF | リバースプロキシ(Application Gateway) | OWASP CRS、Azure 統合、DDoS Protection と連携 | $0.443/時間(Application Gateway 込み) |
| Akamai Kona Site Defender | リバースプロキシ(CDN) | エンタープライズ向け、高度な振る舞い検知 | エンタープライズ価格(要問い合わせ) |
| ModSecurity | エージェント(Apache/nginx) | オープンソース、自由度が高い、OWASP CRS 利用可 | 無料(運用コストあり) |
Cloudflare WAF の設定例
# Cloudflare ダッシュボード → Security → WAF
Managed Rules:
- OWASP ModSecurity Core Rule Set: On
- Cloudflare Managed Ruleset: On
Custom Rules:
- Block requests with "union select" in query string
- Rate Limiting: 100 req/min per IP
AWS WAF の設定例
{
"Name": "SQLInjectionRule",
"Priority": 1,
"Statement": {
"SqliMatchStatement": {
"FieldToMatch": {
"QueryString": {}
},
"TextTransformations": [
{
"Priority": 0,
"Type": "URL_DECODE"
}
]
}
},
"Action": {
"Block": {}
}
}
実践メモ: Cloudflare WAF は無料プランでも基本的な DDoS 対策がありますが、WAF のマネージドルールは有料プラン(Pro 以上)が必要です。AWS WAF はルールごとに課金されるため、小規模なら低コストで導入できます。
WAF のルール種類
| ルール種類 | 内容 | 例 |
|---|---|---|
| Managed Rules | プロバイダーが管理する既製ルールセット | OWASP CRS, Cloudflare Managed Rules |
| Custom Rules | 自分で作成するカスタムルール | 特定 URL へのアクセス制限、独自のパターンマッチ |
| Rate Limiting | 特定条件でのリクエスト数制限 | IP あたり 100 req/min、URL あたり 10 req/sec |
| IP Reputation | 既知の悪意ある IP からのアクセスをブロック | スパムボット、Tor 出口ノード、VPN |
| Geo-blocking | 特定国からのアクセスを拒否 | 日本以外からのアクセスをブロック |
Custom Rule の例(AWS WAF)
# /admin/* への日本以外からのアクセスをブロック
Rule:
- URI Path starts with "/admin/"
- AND Country NOT IN ["JP"]
Action: Block
Rate Limiting の例(Cloudflare)
# 同一 IP から 10 秒間に 20 リクエスト以上でブロック
Rate Limiting Rule:
- Threshold: 20 requests per 10 seconds
- Action: Block for 600 seconds
- Match: URI Path contains "/api/"
ポイント: Managed Rules は既知の攻撃を広くカバーしますが、アプリケーション固有のロジックは Custom Rules で対応します。例えば「ログイン失敗を 5 回繰り返したら 10 分間ブロック」などです。
WAF のログと監視
WAF は攻撃を検出・ブロックしたらログに記録します。
ログに記録される情報
| 項目 | 内容 |
|---|---|
| Timestamp | リクエスト日時 |
| Client IP | 送信元 IP アドレス |
| Request | HTTP メソッド、URL、ヘッダー、ボディ |
| Rule ID | マッチしたルール ID |
| Action | Block / Allow / Challenge |
| Signature | 検出された攻撃パターン |
Cloudflare WAF ログの例
{
"ClientIP": "203.0.113.45",
"ClientRequestHost": "example.com",
"ClientRequestMethod": "GET",
"ClientRequestURI": "/user?id=1' OR '1'='1",
"EdgeStartTimestamp": "2026-05-01T12:34:56Z",
"RuleID": "100001",
"Action": "block",
"RayID": "7a1b2c3d4e5f6g7h"
}
AWS WAF ログの例
{
"timestamp": 1714568096000,
"httpRequest": {
"clientIp": "203.0.113.45",
"uri": "/user",
"args": "id=1' OR '1'='1",
"httpMethod": "GET"
},
"action": "BLOCK",
"ruleGroupList": [
{
"ruleGroupId": "SQLInjectionRule",
"terminatingRule": {
"ruleId": "SQL_Injection_QUERYSTRING",
"action": "BLOCK"
}
}
]
}
実践メモ: WAF ログは SIEM(Security Information and Event Management)に転送して、攻撃傾向の分析やアラート設定を行うのが推奨です。AWS WAF なら CloudWatch Logs、Cloudflare なら Logpush を使います。
誤検知(False Positive)への対処
WAF は正規のリクエストを攻撃と誤認識することがあります。
誤検知の例
# 正規のリクエストだが SQL パターンにマッチ
GET /search?q=select+a+union+of+ideas HTTP/1.1
↑
"select" "union" が SQL キーワードとして検出
対処方法
| 方法 | 内容 |
|---|---|
| 除外ルール(Whitelist) | 特定の URL やパラメータを検査対象から除外 |
| ルールのチューニング | シグネチャの閾値を調整 |
| 検知モードで様子見 | Block せず Detect のみにして様子を見る |
# Cloudflare WAF の除外ルール例
Disable Rule:
- Rule ID: 100001 (SQL Injection)
- URI Path contains "/search"
注意: 誤検知を避けるために WAF を無効化しすぎると、本来の攻撃を見逃します。最小限の除外ルールで対応し、定期的に見直してください。
まとめ
WAF は Web アプリケーションへの攻撃を防ぐ L7 ファイアウォールです。
| 項目 | 内容 |
|---|---|
| 検査内容 | HTTP/HTTPS の中身(URL、パラメータ、Cookie、ヘッダー) |
| 防げる攻撃 | SQL インジェクション、XSS、RCE、パストラバーサルなど |
| 検知方式 | シグネチャベース + 振る舞い検知 |
| 運用モード | 検知モード(ログのみ)→ ブロックモード(本番) |
| 主要サービス | Cloudflare WAF, AWS WAF, Azure WAF, ModSecurity |
ネットワークファイアウォールとの併用で、ネットワーク層 + アプリケーション層の多層防御を実現できます。
参考リソース
- OWASP - Web Application Firewall
- OWASP ModSecurity Core Rule Set (CRS)
- Cloudflare - What is a WAF?
- AWS - AWS WAF Documentation
- ModSecurity - Official Documentation