WAF(Web Application Firewall)入門

入門 | 10分 で読める | 2026.05.02

公式ドキュメント

この記事の要点

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 GroupCloudflare 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 アドレス
RequestHTTP メソッド、URL、ヘッダー、ボディ
Rule IDマッチしたルール ID
ActionBlock / 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

ネットワークファイアウォールとの併用で、ネットワーク層 + アプリケーション層の多層防御を実現できます。

参考リソース

この技術を体系的に学びたいですか?

未来学では東証プライム上場企業のITエンジニアが24時間サポート。月額24,800円から、退会金0円のオンラインIT塾です。

メールで無料相談する
← 一覧に戻る