WAFでDDoS攻撃を防ぐ完全ガイド｜選び方から設定まで徹底解説

2025年11月07日作成

コラム

WAF（Web Application Firewall）は、L7 DDoS攻撃に対する最も効果的な防御手段の一つです。しかし、「導入したけれど設定が分からない」「誤検知が多くて困る」といった課題を抱える企業が少なくありません。WAFの真価を発揮するには、適切な製品選定と最適な設定が不可欠です。本記事では、WAFがDDoS攻撃を防ぐ技術的メカニズムから、Cloudflare、AWS WAF、Akamaiなど主要5社の詳細比較、レート制限やカスタムルールの具体的な設定方法まで、実践的に解説します。さらに、CDNとの統合やSIEM連携など、他のセキュリティ対策との効果的な組み合わせ方も紹介。技術者はもちろん、セキュリティ投資を検討する経営層にも役立つ内容です。

WAFでDDoS攻撃を防ぐ仕組み

WAFの基本アーキテクチャ

WAF（Web Application Firewall）は、Webアプリケーションの前面に配置され、HTTP/HTTPSトラフィックを検査・制御するセキュリティ装置です。従来のファイアウォールがネットワーク層（L3/L4）で動作するのに対し、WAFはアプリケーション層（L7）で動作し、より高度な攻撃を防御できます。

WAFの配置パターンには大きく3つのタイプがあり、それぞれに明確な特徴があります：

配置タイプ	メリット	デメリット	適用シーン	代表製品
クラウド型	導入容易（30分で完了）、スケーラブル、初期投資不要、自動アップデート	レイテンシ増加（5-20ms）、データ転送の懸念、カスタマイズ制限	中小企業、Webサービス、グローバル展開	Cloudflare、Akamai、Imperva
オンプレミス型	低レイテンシ（1ms以下）、完全制御、データローカル保存、高度なカスタマイズ	初期投資大（500万円〜）、運用負荷高、スケーリング困難	大企業、金融機関、政府機関	F5 BIG-IP、Fortinet、Palo Alto
ハイブリッド型	柔軟性高、段階移行可、リスク分散、ベストオブブリード	複雑性増大、コスト高、管理ポイント複数	エンタープライズ、マルチクラウド環境	Barracuda、Radware

クラウド型WAFは、DNSの設定変更だけで導入でき、グローバルに分散したエッジサーバーで攻撃を吸収します。例えば、Cloudflareは世界275都市以上にデータセンターを持ち、最大3.8TbpsのDDoS攻撃を防御した実績があります。一方、トラフィックが外部を経由するため、機密データを扱う企業では懸念材料となることもあります。

オンプレミス型WAFは、自社データセンターに物理アプライアンスまたは仮想アプライアンスとして導入します。完全なコントロールが可能で、複雑なカスタムルールや独自のセキュリティポリシーを実装できます。ただし、専門知識を持つエンジニアの確保と、24時間365日の運用体制が必要です。

ハイブリッド型は、平常時はオンプレミスWAFで処理し、大規模攻撃時にクラウドWAFにオフロードする構成です。多層防御アーキテクチャの一環として、最も柔軟性の高い選択肢ですが、設計と運用の複雑性が課題となります。

L7 DDoS攻撃への防御メカニズム

WAFがL7 DDoS攻撃を防御する際の詳細な処理フローを理解することで、効果的な設定が可能になります。以下、リクエストが到達してから応答するまでの各段階を解説します：

リクエスト受信とパース

WAFは受信したHTTPリクエストを即座に解析します。HTTPヘッダーの構造検証、使用メソッド（GET、POST、PUT等）の確認、Content-Typeの整合性チェック、ペイロードサイズの確認を行います。この段階で、不正な形式のリクエストや異常に大きなヘッダー（Slowloris攻撃の兆候）を検出し、即座にブロックします。また、User-Agentの分析により、既知のボットやスクレイピングツールを識別します。
レート制限チェック

次に、多層的なレート制限を適用します。IP アドレスごとの秒間リクエスト数、セッションIDごとのアクセス頻度、特定URLパスへの集中度を計算し、閾値を超えた場合は一時的または永続的にブロックします。例えば、ログインページへのアクセスは1秒間に3回まで、APIエンドポイントは1分間に100回までといった細かな制御が可能です。さらに、Sliding Windowアルゴリズムにより、バースト的なトラフィックと継続的な攻撃を区別します。
パターンマッチング

シグネチャベースの検知により、既知の攻撃パターンを識別します。SQLインジェクション、XSS、CSRFなどの攻撃シグネチャと照合し、悪意のあるペイロードを検出します。正規表現を使用した柔軟なパターンマッチングにより、新しい攻撃手法にも対応可能です。OWASP ModSecurity Core Rule Set（CRS）のような業界標準のルールセットを基盤とし、自社環境に合わせてカスタマイズします。
振る舞い分析

最後に、機械学習ベースの振る舞い分析を実施します。正常なユーザーの行動パターンをベースラインとして学習し、異常な振る舞いを検出します。例えば、人間には不可能な速度でのページ遷移、JavaScriptを実行しないアクセス、マウス移動やキーボード入力の欠如などを総合的に評価し、ボット確率スコアを算出します。スコアが閾値を超えた場合、CAPTCHAチャレンジや一時ブロックなどの対策を実行します。

防御技術の詳細

WAFが実装する主要な防御技術について、その仕組みと効果を詳しく解説します：

レート制限（Rate Limiting）- トラフィック流量の精密制御: 単位時間あたりのリクエスト数を制限する最も基本的な防御手法です。**Token Bucketアルゴリズム**では、一定速度でトークンが補充されるバケツを用意し、リクエストごとにトークンを消費します。バケツが空になるとリクエストを拒否します。**Sliding Windowアルゴリズム**は、過去N秒間のリクエスト数を継続的に計算し、より精密な制御を実現します。**Fixed Windowアルゴリズム**は実装が簡単ですが、ウィンドウ境界でのバースト攻撃に脆弱です。nginx設定例：`limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;`により、IPアドレスごとに秒間10リクエストに制限できます。適切な設定により、正常なユーザーに影響を与えずに攻撃を防げます。
IPレピュテーション - グローバル脅威インテリジェンスの活用: 世界中から収集された**脅威情報データベース**と照合し、悪意あるIPアドレスを事前にブロックします。Cloudflareは1日あたり**1000億件以上のリクエスト**を分析し、リアルタイムでIPレピュテーションを更新しています。レピュテーションスコアは0-100で評価され、過去の攻撃履歴、ボットネット参加、オープンプロキシ利用、地理的位置などの要素から算出されます。スコア30以下は即座にブロック、30-50はチャレンジ実施、50-70はレート制限強化といった**段階的な対応**が可能です。ただし、共有IPアドレス（企業NAT、公衆Wi-Fi）での誤検知には注意が必要で、定期的なホワイトリスト更新が不可欠です。
チャレンジレスポンス - 人間とボットの識別: **JavaScript Challenge**は、ブラウザでJavaScriptコードを実行させ、計算結果を返すことで正当性を検証します。単純なボットの99%以上を排除できます。**CAPTCHA**（Completely Automated Public Turing test to tell Computers and Humans Apart）は、画像認識や音声認識により人間であることを証明させます。最新の**reCAPTCHA v3**は、ユーザー操作なしでリスクスコアを算出し、UXを損なわずにボット検出が可能です。**デバイスフィンガープリンティング**では、ブラウザの種類、画面解像度、インストール済みプラグイン、タイムゾーンなど数十の要素から固有のデバイスIDを生成し、異常なアクセスパターンを検出します。これらを組み合わせることで、誤検知率を0.01%以下に抑えながら、攻撃の95%以上を防御できます。

WAFの種類と選び方

主要WAF製品の詳細比較

2025年現在、主要なWAFベンダー5社の製品を、技術面、コスト面、運用面から詳細に比較します。各社とも独自の強みを持っており、要件に応じた適切な選択が重要です：

製品名	月額費用	DDoS防御能力	特徴機能	API	サポート	導入実績
Cloudflare WAF	$20〜$200	無制限（実績3.8Tbps）	Bot Management、Page Rules、Workers統合	REST API完備	24/7（Enterpriseプラン）	2700万サイト
AWS WAF	$5〜+従量課金	Auto Scaling対応	AWS統合、Managed Rules、Shield Advanced連携	AWS SDK完全対応	AWS Support契約による	100万以上のAWSアカウント
Akamai Kona Site Defender	$3,000〜	2Tbps以上	Edge Computing、Adaptive Security Engine、Bot Manager	Open API 2.0	Premium 24/7	Fortune 500の半数以上
Imperva Cloud WAF	$59〜$599	10Gbps〜無制限	Advanced Bot Protection、Account Takeover Protection	REST API v2	24/7 SLA 99.99%	6,200社以上
Barracuda WAF	$99〜$999	カスタマイズ可能	機械学習エンジン、Active DDoS Prevention、SSL Offloading	REST API	Standard/Premium選択	15万社以上

Cloudflare WAFは、即座に導入可能で、DNSの切り替えだけで5分で保護を開始できます。無料プランでも基本的なDDoS対策が可能で、有料プランでは高度なBot Managementや、エッジでコードを実行できるWorkersとの統合により、カスタムロジックの実装が可能です。グローバルなCDNネットワークを活用し、レイテンシの削減とパフォーマンス向上を同時に実現します。

AWS WAFは、AWSエコシステムとのシームレスな統合が最大の強みです。CloudFormationによるInfrastructure as Code、CloudWatchによる詳細な監視、Lambda@Edgeとの連携による動的なルール適用が可能です。従量課金制のため、小規模から始めて段階的に拡張できます。AWS Shield Advancedと組み合わせることで、L3/L4/L7の包括的な防御を実現します。

Akamai Kona Site Defenderは、エンタープライズ向けの最高峰WAFです。独自のAdaptive Security Engineにより、誤検知を最小化しながら高い検知率を実現。Edge Computingプラットフォームとの統合により、WAFロジックをエッジで実行し、オリジンサーバーの負荷を大幅に削減します。高額ですが、ミッションクリティカルなシステムには最適です。

Imperva Cloud WAFは、ボット対策に特化した機能が充実しています。Advanced Bot Protectionは、良性ボット（検索エンジン等）と悪性ボットを高精度で識別し、ビジネスへの影響を最小化します。Account Takeover Protectionにより、アカウント乗っ取りを防ぐ専門機能も提供。中規模企業に最適なバランスの良い製品です。

Barracuda WAFは、オンプレミスとクラウドの両方で展開可能な柔軟性が特徴です。独自の機械学習エンジンにより、ゼロデイ攻撃にも対応可能。SSL Offloading機能により、暗号化/復号化の処理をWAFで行い、Webサーバーの負荷を軽減します。中堅企業向けの手頃な価格設定も魅力です。

選定基準と評価ポイント

WAF選定において考慮すべき評価軸を、優先順位付けして解説します：

1. 防御性能 - 攻撃を確実に止める能力: 最大防御容量は、想定される攻撃規模の**2倍以上**を確保すべきです。一般的な企業なら10Gbps、大規模サービスなら100Gbps以上が目安です。レート制限の粒度も重要で、IP単位だけでなく、**セッション、ユーザー、API キー単位**での制御が可能か確認します。カスタムルールの柔軟性は、自社特有の攻撃パターンに対応するため不可欠です。正規表現、地理的位置、時間帯、HTTPヘッダーなど、**複数条件の組み合わせ**が可能か評価します。誤検知率は1%以下が理想で、機械学習による自動チューニング機能があると運用負荷を削減できます。
2. 導入・運用コスト - TCOの正確な把握: 初期費用には、ライセンス費用、導入支援費用、既存システムの改修費用が含まれます。月額費用は、**基本料金＋従量課金**の構造を理解し、トラフィック量やルール数による追加費用を見積もります。隠れコストとして、帯域幅料金（特にクラウドWAF）、SSL証明書費用、ログストレージ費用にも注意が必要です。3年間のTCO（Total Cost of Ownership）を計算し、オンプレミスとクラウドを比較します。一般的に、月間10TBを超えるトラフィックがある場合、オンプレミスの方がコスト効率が良くなる傾向があります。
3. 運用性 - 日々の管理負荷: 管理画面の使いやすさは、**インシデント対応の速度**に直結します。直感的なダッシュボード、リアルタイムの攻撃可視化、ワンクリックでの緩和措置が可能か確認します。自動化対応として、Terraform、Ansible、Puppetなどの**IaCツール対応**は必須です。ログ分析機能では、詳細なフィルタリング、カスタムクエリ、レポート生成が可能か評価します。アラート設定の柔軟性、Slack、PagerDuty、メールなどへの**通知連携**も重要です。定期レポートの自動生成により、経営層への報告も効率化できます。
4. 拡張性・統合性 - 将来を見据えた選択: API対応は、**DevOpsパイプライン**への統合に不可欠です。REST API、GraphQL、WebSocketのサポート状況を確認します。[SIEM](/security/networking/ddos/column/multilayer-defense/)連携では、Splunk、QRadar、ArcSightなどとの統合実績を評価します。CDN統合により、パフォーマンスとセキュリティの両立が可能か確認します。マルチクラウド対応は、AWS、Azure、GCPなど**複数クラウドでの一元管理**が可能か評価します。コンテナ環境（Kubernetes、Docker）での動作保証も、モダンなアーキテクチャでは重要な要素です。

企業規模別の推奨構成

企業規模と要件に応じた最適なWAF構成を提案します：

スタートアップ（〜50名）：Cloudflare Pro（月額$20）＋基本ルールセット
初期投資を抑えながら、実用的な防御を実現。5分で導入可能で、技術者が少なくても運用可能。Page Rulesで重要なページを優先保護。
中小企業（50-300名）：AWS WAF（月額$100-500）＋ AWS Managed Rules ＋カスタムルール
AWSインフラを活用し、スケーラブルな防御体制を構築。中小企業向け対策として、コストパフォーマンスに優れる。
中堅企業（300-1000名）：Akamai Kona または Imperva Cloud WAF（月額$3,000-10,000）＋ SOC連携
24時間監視体制と組み合わせ、高度な攻撃にも対応。Bot対策やAPI保護など、専門機能を活用。
大企業（1000名〜）：ハイブリッド構成（オンプレミス＋クラウド）＋専任セキュリティチーム
F5 BIG-IPなどのオンプレミスWAFを基盤とし、大規模攻撃時はクラウドWAFにオフロード。エンタープライズ向け多層防御を実現。

設定のポイント

レート制限の最適化

レート制限はWAFの最も基本的かつ重要な機能です。適切な設定により、正常なユーザーに影響を与えることなく、DDoS攻撃を効果的に防げます。

Nginxでの詳細な設定例：

# /etc/nginx/nginx.conf
http {
	# === ゾーン定義（メモリ領域の確保）===
	# IPアドレスごとのレート制限（10MBメモリで約16万IPを追跡）
	limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
	
	# セッションごとのレート制限
	limit_req_zone $cookie_sessionid zone=persession:10m rate=30r/s;
	
	# URIごとのレート制限
	limit_req_zone $uri zone=peruri:10m rate=100r/s;
	
	# User-Agentごとのレート制限（ボット対策）
	limit_req_zone $http_user_agent zone=peruseragent:10m rate=5r/s;
	
	# 複合キーによる制限（IP + URI）
	limit_req_zone $binary_remote_addr$uri zone=peripuri:20m rate=5r/s;
	
	server {
		listen 80;
		server_name example.com;
		
		# === 一般的なコンテンツ ===
		location / {
			# burst: 瞬間的なアクセス増を許容
			# nodelay: バースト分は即座に処理（キューに入れない）
			limit_req zone=perip burst=20 nodelay;
			limit_req zone=peruri burst=50;
		}
		
		# === APIエンドポイント（厳格な制限）===
		location /api/ {
			limit_req zone=perip burst=10 nodelay;
			limit_req zone=persession burst=30;
			
			# APIキーによる制限（ヘッダーから取得）
			set $api_key $http_x_api_key;
			limit_req zone=perapikey rate=100r/m;
			
			# エラーレスポンスのカスタマイズ
			limit_req_status 429;
			error_page 429 @rate_limited;
		}
		
		# === ログインページ（ブルートフォース対策）===
		location /login {
			# 非常に厳格な制限
			limit_req zone=perip rate=1r/s burst=2 nodelay;
			
			# 失敗回数のカウント
			limit_req zone=loginfail rate=3r/m;
		}
		
		# === 静的ファイル（緩い制限）===
		location ~* \.(jpg|jpeg|png|gif|css|js)$ {
			limit_req zone=perip burst=100 nodelay;
			expires 30d;
			add_header Cache-Control "public, immutable";
		}
		
		# === レート制限時のカスタムレスポンス ===
		location @rate_limited {
			default_type application/json;
			return 429 '{"error":"Rate limit exceeded","retry_after":60}';
		}
	}
}

エンドポイント別の推奨設定値：

エンドポイント	Rate	Burst	備考	対策目的
静的コンテンツ（画像、CSS、JS）	100/s	200	CDNキャッシュ可能	帯域幅攻撃防止
一般的なHTML	20/s	40	ページビュー想定	HTTPフラッド防止
API（認証済み）	10/s	20	処理負荷高	APIアビューズ防止
API（公開）	5/s	10	より厳格に	無差別攻撃防止
ログイン	1/2s	2	ブルートフォース対策最優先	パスワード攻撃防止
パスワードリセット	1/30s	1	メール送信負荷考慮	メールボム防止
検索	5/s	10	DB負荷考慮	DBサーバー保護
ファイルアップロード	1/s	2	ストレージ負荷	ストレージ攻撃防止

動的なレート調整も重要です。時間帯や曜日によってトラフィックパターンが異なる場合、cron jobでnginxの設定を動的に変更するスクリプトを実装します。

ジオブロッキングとIPホワイトリスト

地理的位置に基づくアクセス制御は、攻撃の大部分を事前に防ぐ効果的な手法です。

ジオブロッキング戦略 - ビジネスに影響しない範囲での制限: まず、自社のビジネス展開地域を明確にします。国内向けサービスなら、**日本以外からの管理画面アクセスをブロック**するだけで、攻撃の80%以上を防げます。ただし、海外出張や海外在住日本人を考慮し、**VPN経由のアクセスを許可**する例外ルールを設定します。高リスク国（統計的に攻撃が多い国）として、特定の国からのアクセスには**追加の認証**を要求します。CloudflareのようなサービスでWAF標準のGeoIPデータベースは**週次で更新**され、IPアドレスの地理的位置の精度は95%以上です。誤ブロック時の解除フローとして、メールでの申請→人間による確認→時限的なホワイトリスト登録という**段階的なプロセス**を確立します。
IPホワイトリスト管理 - 重要なアクセス元の確実な保護: ホワイトリストには、**社内IPアドレス**（本社、支社、データセンター）、**重要取引先**（パートナー企業、大口顧客）、**外部サービス**（決済代行、監視サービス、CDN）を登録します。IPアドレスは変更される可能性があるため、**月次での見直し**を必須とし、登録理由と有効期限を記録します。動的IPの場合は、**FQDNベースの許可**やVPNの利用を推奨します。[内部不正対策](/security/insider-physical/insider-threat/)の観点から、退職者のVPNアクセスは即座に無効化する仕組みも重要です。

AWS WAFでの地理的制限の実装例：

{
  "Name": "GeoBlockingRule",
  "Priority": 1,
  "Statement": {
	"AndStatement": {
	  "Statements": [
		{
		  "GeoMatchStatement": {
			"CountryCodes": ["CN", "RU", "KP", "IR", "SY"],
			"ForwardedIPConfig": {
			  "HeaderName": "X-Forwarded-For",
			  "FallbackBehavior": "NO_MATCH"
			}
		  }
		},
		{
		  "NotStatement": {
			"Statement": {
			  "IPSetReferenceStatement": {
				"ARN": "arn:aws:wafv2:ap-northeast-1:123456789012:regional/ipset/whitelist/xxx"
			  }
			}
		  }
		}
	  ]
	}
  },
  "Action": {
	"Block": {
	  "CustomResponse": {
		"ResponseCode": 403,
		"CustomResponseBodyKey": "geo-blocked-response"
	  }
	}
  },
  "VisibilityConfig": {
	"SampledRequestsEnabled": true,
	"CloudWatchMetricsEnabled": true,
	"MetricName": "GeoBlockingRule"
  }
}

カスタムルール作成のベストプラクティス

効果的なカスタムルールは、自社環境特有の脅威に対応するために不可欠です。以下、ルール作成の体系的なアプローチを解説します：

脅威分析フェーズ（1-2週間）

まず、過去3ヶ月分のアクセスログを分析し、攻撃パターンを特定します。Apache/Nginxのアクセスログから、異常なUser-Agent、頻繁にアクセスされる脆弱性スキャンパス（/admin、/phpmyadmin等）、特定時間帯の急激なトラフィック増加を抽出します。攻撃手法の詳細を理解し、自社が狙われやすいポイントを明確にします。正常トラフィックとの差異を統計的に分析し、誤検知を最小化する閾値を設定します。
ルール設計フェーズ（3-5日）

識別した脅威に対し、複数条件を組み合わせた複合ルールを設計します。例えば、「海外IPかつ深夜アクセスかつ管理画面へのPOSTリクエスト」といった条件の組み合わせです。ルールの優先順位は、影響度と頻度から決定し、Performance Impactの低い順に並べます。各ルールには、Block、Challenge、Count（監視のみ）といったアクションを定義し、段階的に厳格化します。
テスト実施フェーズ（1週間）

ステージング環境で全ルールをテストし、期待通りの動作を確認します。本番環境では、まずCountモード（ログのみ記録）で1週間運用し、誤検知率を測定します。誤検知が0.1%以下になったら、段階的にChallengeモード、Blockモードへ移行します。A/Bテストにより、パフォーマンスへの影響も評価します。
チューニングフェーズ（継続的）

運用開始後も継続的な改善が必要です。週次で誤検知ログをレビューし、ルールの微調整を行います。新しい攻撃パターンが発見されたら、24時間以内にルールを追加します。四半期ごとに全ルールを棚卸しし、不要なルールは削除してパフォーマンスを最適化します。
監視と改善フェーズ（継続的）

KPIとして、ブロック率、誤検知率、平均レスポンスタイム、CPU使用率を設定し、ダッシュボードで監視します。月次レポートで経営層に報告し、投資効果を可視化します。インシデント対応の経験を基に、ルールを継続的に改善します。

他のセキュリティ対策との連携

CDNとの統合設定

CDN（Content Delivery Network）とWAFの統合は、パフォーマンスとセキュリティの両立を実現する最良の方法です。

CDN+WAF構成パターンの詳細比較：

構成パターン	CDN配置	WAF配置	メリット	デメリット	適用シーン
CDN先行型	前段	後段（オリジン前）	キャッシュヒット率最大化、オリジン負荷最小	WAFは動的コンテンツのみ保護	静的コンテンツ中心のサイト
WAF先行型	後段	前段（最前面）	全トラフィックをWAFで検査、セキュリティ最優先	CDN効果限定、WAF負荷大	高セキュリティ要求環境
統合型	一体化	一体化	管理簡素化、レイテンシ最小	ベンダーロックイン、柔軟性低下	中小規模、シンプル構成希望
分散型	Edge	Edge	地理的に分散、最小レイテンシ	設定同期の複雑性、コスト増	グローバルサービス

設定の最適化ポイント：

CDN先行型では、キャッシュ可能なコンテンツ（画像、CSS、JS、静的HTML）をCDNで処理し、動的コンテンツのみWAFに転送します。これにより、WAFの負荷を80%以上削減できます。キャッシュキーの設計では、クエリパラメータやCookieの扱いに注意し、キャッシュ効率とセキュリティのバランスを取ります。

WAF先行型では、すべてのトラフィックがWAFを通過するため、包括的な保護が可能です。ただし、静的コンテンツもWAFで処理するため、適切なキャパシティプランニングが必要です。WAFでの検査後、X-WAF-Validatedなどのカスタムヘッダーを付与し、CDNでの処理を最適化します。

統合型のCloudflareやAkamai では、単一の管理画面でCDNとWAFを制御できます。Page RulesやEdge Workersにより、URLパターンごとに細かな制御が可能です。例えば、/api/*はWAF厳格モード、/images/*はCDNキャッシュ優先といった設定が簡単に実装できます。

SIEM/SOCとの連携

Security Information and Event Management（SIEM）やSecurity Operations Center（SOC）との連携により、組織全体のセキュリティ可視性を向上させます。

Fluentdを使用したログ転送設定例：

# /etc/fluentd/fluent.conf
# WAFログの収集設定

# ソース定義：WAFログファイルの監視
<source>
  @type tail
  path /var/log/waf/access.log
  pos_file /var/log/fluentd/waf-access.pos
  tag waf.access
  <parse>
	@type json
	time_key timestamp
	time_format %Y-%m-%dT%H:%M:%S.%NZ
  </parse>
</source>

# フィルター：ログの加工と enrichment
<filter waf.access>
  @type record_transformer
  enable_ruby true
  <record>
	# 攻撃の重要度を判定
	severity ${record["attack_score"] > 7 ? "high" : (record["attack_score"] > 4 ? "medium" : "low")}
	
	# イベントカテゴリの付与
	category ${record["rule_id"].start_with?("SQL") ? "sql_injection" : "general_attack"}
	
	# 地理情報の追加
	country ${record["client_country"]}
	
	# タイムスタンプの正規化
	@timestamp ${Time.parse(record["timestamp"]).iso8601}
	
	# 追加メタデータ
	waf_vendor "cloudflare"
	environment "production"
	
	# 攻撃タイプの分類
	attack_type ${
	  case record["rule_message"]
	  when /SQL/i then "sql_injection"
	  when /XSS/i then "cross_site_scripting"
	  when /RCE/i then "remote_code_execution"
	  when /traversal/i then "path_traversal"
	  else "unknown"
	  end
	}
  </record>
</filter>

# アラート用フィルター：重要なイベントの抽出
<filter waf.access>
  @type grep
  <or>
	<regexp>
	  key severity
	  pattern /high/
	</regexp>
	<regexp>
	  key attack_score
	  pattern /[8-9]|10/
	</regexp>
  </or>
</filter>

# 出力先1：Elasticsearch（SIEM）
<match waf.access>
  @type elasticsearch
  host siem.example.com
  port 9200
  index_name waf-logs-%Y.%m
  type_name _doc
  
  # バッファ設定
  <buffer time>
	@type file
	path /var/log/fluentd/buffer/waf-es
	timekey 60
	timekey_wait 10
	chunk_limit_size 5M
	queue_limit_length 100
  </buffer>
  
  # 認証設定
  user elastic
  password <%= ENV['ELASTIC_PASSWORD'] %>
  
  # SSL設定
  ssl_verify true
  ca_file /etc/ssl/certs/elastic-ca.pem
  
  # リトライ設定
  reconnect_on_error true
  reload_on_failure true
  request_timeout 15s
</match>

# 出力先2：Splunk
<match waf.access>
  @type splunk_hec
  host splunk.example.com
  port 8088
  token <%= ENV['SPLUNK_HEC_TOKEN'] %>
  
  # イベント形式
  format json
  sourcetype _json
  source waf
  
  # SSL設定
  use_ssl true
  ssl_verify false
  
  # バッファ設定
  <buffer>
	@type memory
	flush_interval 10s
	chunk_limit_size 1M
  </buffer>
</match>

# 出力先3：S3（長期保存用）
<match waf.access>
  @type s3
  aws_key_id <%= ENV['AWS_ACCESS_KEY_ID'] %>
  aws_sec_key <%= ENV['AWS_SECRET_ACCESS_KEY'] %>
  s3_bucket waf-logs-archive
  s3_region ap-northeast-1
  
  # パス設定
  path logs/waf/%Y/%m/%d/
  s3_object_key_format %{path}%{time_slice}_%{index}.%{file_extension}
  
  # バッファと圧縮
  <buffer time>
	@type file
	path /var/log/fluentd/buffer/waf-s3
	timekey 3600
	timekey_wait 10m
	chunk_limit_size 256m
  </buffer>
  
  # 圧縮設定
  store_as gzip
</match>

アラート設定と対応フロー：

SIEMでの相関ルールを設定し、以下の条件で自動アラートを発砲します：

単一IPから5分間で1000回以上のブロック
複数IPから同一URLへの協調攻撃パターン
SQLインジェクション試行の成功可能性検知
新規攻撃パターンの異常検知

アラート発生時は、重要度に応じて以下のアクションを実行：

Critical：即座にIPブロック、インシデント対応チーム召集
High：WAFルール自動強化、30分以内に手動確認
Medium：ログ記録、翌営業日に分析
Low：週次レポートで報告

DDoS専用製品との役割分担

WAFとDDoS専用製品の適切な役割分担により、多層防御体制を構築します：

L3/L4 DDoS対策（専用機器の役割）- ネットワーク層の防御: Arbor Networks、A10 Thunder TPS、Radware DefenseProなどの専用機器は、**ネットワーク層とトランスポート層**の攻撃を防御します。SYN Flood、UDP Flood、ICMP Floodなどのボリューム型攻撃に対し、**100Gbps以上**の処理能力で対応。パケットレベルでの高速フィルタリング、不正なパケットの即座廃棄、正常トラフィックのクリーニングを実施します。BGP Flowspecによる上流ISPでの防御連携も可能で、自社インフラに到達前に攻撃を緩和できます。
L7 DDoS対策（WAFの役割）- アプリケーション層の防御: WAFは**HTTPレイヤー**に特化した防御を提供します。HTTP GET/POST Flood、Slowloris、R.U.D.Y攻撃などのアプリケーション層攻撃を、リクエストの内容を解析して防御。[SSL/TLS通信の復号化](/security/web-api/cors-misconfig/)により、暗号化されたHTTPS攻撃も検知可能です。正規表現によるペイロード検査、セッション管理、Cookie検証など、きめ細かな制御を実現します。
統合運用のポイント - シームレスな連携: トラフィックフローは、**DDoS専用機器→WAF→Webサーバー**の順序が理想的です。エスカレーション基準として、L3/L4攻撃はDDoS専用機器で自動緩和、L7攻撃検知時はWAFに詳細分析を依頼する体制を確立。ログは**統一フォーマット（CEF、LEEF）**で収集し、SIEMで一元管理します。月次でのjoint訓練により、両チームの連携を強化し、[インシデント発生時](/security/networking/ddos/column/incident-response/)の対応速度を向上させます。

FAQ（よくある質問）

Q: WAFだけでDDoS攻撃は防げますか？: A: WAFは主にL7（アプリケーション層）のDDoS攻撃に効果的ですが、完全な防御には限界があります。L3/L4のボリューム型攻撃（SYN Flood、UDP Flood）に対しては、専用のDDoS対策機器やサービスが必要です。理想的な構成は、ISPレベルのDDoS対策、CDN、WAF、[ファイアウォール](/security/networking/)を組み合わせた多層防御です。WAF単体でも、HTTP FloodやSlowlorisなどのL7攻撃は効果的に防げますが、100Gbpsを超えるような大規模攻撃には、上流での対策が不可欠です。また、WAFの処理能力にも限界があるため、想定される攻撃規模に応じた製品選定が重要です。
Q: 無料のWAFでも効果はありますか？: A: 無料WAFでも基本的な防御効果は期待できます。例えば、Cloudflareの無料プランは、基本的なDDoS対策、OWASP Top 10への対応、SSL証明書を提供します。ModSecurityのようなオープンソースWAFも、適切に設定すれば商用製品に劣らない防御力を発揮します。ただし、無料版には制限があります：カスタムルールの数が限定的、サポートが受けられない、高度な機能（Bot対策、API保護）が使えない、SLAの保証がないなど。小規模サイトや個人ブログなら無料WAFで十分ですが、ビジネスクリティカルなサービスでは、[適切な投資](/security/networking/ddos/column/legal-insurance/)を検討すべきです。
Q: 誤検知で正常なユーザーがブロックされたら？: A: 誤検知は避けられない課題ですが、適切な対策で最小化できます。まず、新規ルールは必ず「検知モード」で1週間運用し、誤検知率を確認してから本番適用します。誤検知が発生した場合の対応フローを確立：(1)ユーザーからの報告受付窓口設置、(2)15分以内の一次対応、(3)ホワイトリスト即時追加、(4)根本原因の分析と改善。また、重要な取引先やVIPユーザーは事前にホワイトリスト登録し、CAPTCHA認証をスキップする設定も有効です。誤検知率は0.1%以下を目標とし、機械学習機能があるWAFなら、時間とともに精度が向上します。
Q: WAF導入後のパフォーマンス影響は？: A: WAFの種類により影響は異なりますが、一般的にクラウドWAFで5-20ms、オンプレミスWAFで1-5msのレイテンシ増加があります。ただし、CDN機能を持つクラウドWAFの場合、キャッシュ効果により全体的には高速化することもあります。パフォーマンスを最適化するには：(1)静的コンテンツはWAFをバイパス、(2)ルールの優先順位を最適化、(3)正規表現の効率化、(4)キャッシュの活用、(5)地理的に近いWAFロケーション選択。導入前後でベンチマークテストを実施し、影響を定量的に評価することが重要です。多くの場合、セキュリティ向上のメリットが、わずかなレイテンシ増加を上回ります。
Q: ログはどのくらいの期間保存すべき？: A: ログ保存期間は、コンプライアンス要件、ストレージコスト、分析ニーズのバランスで決定します。一般的な推奨期間：(1)リアルタイムログ：7日間（即座アクセス可能）、(2)短期保存：30-90日（圧縮してオンライン保存）、(3)長期アーカイブ：1-3年（コールドストレージ）。[PCI DSS準拠](/security/networking/ddos/column/legal-insurance/)が必要な場合は最低1年、金融機関は7年保存が求められることもあります。ログの種類別では、セキュリティインシデントは3年、アクセスログは1年、デバッグログは30日が目安です。S3 GlacierやAzure Archive Storageを活用すれば、長期保存コストを大幅に削減できます。
Q: WAFのバイパス攻撃への対策は？: A: 攻撃者は常にWAFを回避する手法を研究しているため、継続的な対策が必要です。一般的なバイパス手法と対策：(1)エンコーディング操作（URL、HTML、Unicode）→正規化処理の実装、(2)大文字小文字の混在→大文字小文字を区別しない検査、(3)HTTPパラメータ汚染→厳格なパラメータ検証、(4)IPスプーフィング→[TCP SYN Cookie](/security/networking/ddos/column/attack-methods/)の有効化、(5)時間差攻撃→セッション全体の監視。また、WAFベンダーが提供する最新シグネチャを定期的に適用し、[脆弱性診断](/security/web-api/penetration-testing/)で定期的に有効性を確認します。多層防御により、単一の防御をバイパスされても、他の層で検知・防御する体制を構築します。
Q: 複数のWAFを併用することは可能？: A: 技術的には可能で、実際に高セキュリティ環境では多段WAF構成が採用されています。例えば、クラウドWAF（第一層）で基本的な攻撃を防ぎ、オンプレミスWAF（第二層）で詳細な検査を行う構成です。メリットは、単一障害点の排除、ベンダー固有の脆弱性対策、検知率の向上です。デメリットは、管理の複雑化、レイテンシの増加、コストの上昇、トラブルシューティングの困難さです。併用する場合は、各WAFの役割を明確に定義し、ルールの重複を避け、ログを統合管理することが重要です。一般的には、1つの高品質なWAFを適切に運用する方が、複数の中途半端な設定より効果的です。

まとめ：WAFを最大限活用するために

WAFは、L7 DDoS攻撃に対する強力な盾となりますが、その効果は適切な選定と設定にかかっています。本記事で解説した要点をまとめます：

製品選定のポイント：

自社の規模と要件に合った製品を選択（過剰投資を避ける）
将来の成長を見据えたスケーラビリティの確保
既存インフラとの統合性を重視
TCOで総合的に判断

設定の最適化：

レート制限は段階的に厳格化（誤検知を最小化）
カスタムルールは自社環境に特化して作成
定期的なチューニングと見直しを実施
ログ分析による継続的改善

他システムとの連携：

CDNとの統合でパフォーマンスも向上
SIEMとの連携で組織全体のセキュリティ強化
DDoS専用対策との役割分担で多層防御

運用の要点：

24時間監視体制の確立
インシデント対応手順の明確化
定期的な訓練とスキル向上
最新脅威情報の継続的な収集

WAFは万能ではありませんが、適切に導入・運用すれば、DDoS攻撃による被害を大幅に削減できます。ネット・Wi-Fiの危険が増大する中、WAFは必須のセキュリティ対策となっています。

投資効果を最大化するためには、技術的な理解と継続的な改善が不可欠です。本記事が、皆様のWAF導入・運用の一助となれば幸いです。

【重要なお知らせ】

本記事は2025年時点の情報に基づいており、製品仕様や価格は変更される可能性があります
設定例は参考情報であり、実環境では十分なテストを実施してから適用してください
セキュリティインシデント発生時は、JPCERT/CC等の専門機関にご相談ください
WAFの設定変更は、必ず変更管理プロセスに従って実施してください
本記事の内容により生じた損害について、筆者および出版社は責任を負いかねます

更新履歴

2025年11月07日: 初稿公開