Webアプリケーションファイアウォール(WAF):機能と仕組み
SQLインジェクション、クロスサイトスクリプティング、ボット攻撃がWebアプリケーションを狙っているというアラートを見たことがあるでしょう。安全なコーディングと定期的なパッチ適用は不可欠ですが、常に十分とは限りません。Webアプリケーションファイアウォール(WAF)は、HTTPトラフィックを検査し、悪意のあるリクエストがアプリケーションに到達する前にブロックすることで、重要な防御層を追加します。この記事では、WAFが何をするのか、内部でどのように機能するのか、そして効果的に導入・調整する方法を説明します。
Webアプリケーションファイアウォールとは?
WAFは、Webアプリケーションとの間で送受信されるHTTP/HTTPSトラフィックを監視、フィルタリング、ブロックするセキュリティソリューションです。レイヤー3と4(IPとTCP)で動作する従来のネットワークファイアウォールとは異なり、WAFはレイヤー7、つまりアプリケーション層で動作します。HTTPメソッド、ヘッダー、Cookie、クエリ文字列、リクエストボディを理解します。これにより、ネットワークファイアウォールには通常のトラフィックに見える攻撃を検出してブロックできます。
WAFは一般的に以下から保護するために使用されます:
- SQLインジェクション(SQLi)
- クロスサイトスクリプティング(XSS)
- クロスサイトリクエストフォージェリ(CSRF)
- ファイルインクルージョンとパストラバーサル
- 既知のCMS脆弱性(例:WordPressプラグイン)
- 悪意のあるボット、スクレイパー、アプリケーション層でのDDoS
WAFの仕組み
大まかに言うと、WAFはクライアントとWebサーバーの間に位置します。リクエストが到着すると、WAFは一連のルールまたはポリシーに照らして検査します。リクエストが攻撃を示すルールに一致する場合、WAFはそれをブロック、ログ記録、またはクライアントにチャレンジを要求できます。そうでなければ、リクエストはアプリケーションに転送されます。
主な検出技術は3つあります:
- シグネチャベース: リクエストを既知の攻撃パターンのデータベースと比較します(例:クエリ文字列内の
UNION SELECT)。高速ですが、新しい攻撃を見逃す可能性があります。 - 異常ベース: 正常なトラフィック動作を学習し、逸脱をフラグします。ゼロデイ攻撃に優れていますが、誤検知を生む可能性があります。
- 評判ベース: IP評判、地理位置情報、脅威インテリジェンスを使用して既知の悪意のある行為者をブロックします。
ほとんどのWAFはこれらの方法を組み合わせています。たとえば、OWASP Core Rule Set(CRS)を備えたModSecurityは、シグネチャと異常スコアリングを使用して各リクエストに脅威スコアを割り当てます。スコアがしきい値を超えると、リクエストはブロックされます。
動作モード
WAFは主に2つのモードで動作します:
- 監視(または検出のみ)モード: 疑わしいリクエストをログに記録しますが、ブロックはしません。初期導入時にルールを調整し、正当なトラフィックを壊さないようにするのに役立ちます。
- ブロック(または防止)モード: ルールに違反するリクエストを積極的にブロックします。これが調整後の目標です。
一部のWAFはチャレンジモードも提供しており、疑わしいクライアントは続行する前にCAPTCHAまたはJavaScriptチャレンジを解決する必要があります。
導入オプション
WAFはいくつかの方法で導入でき、それぞれにトレードオフがあります:
| タイプ | 説明 | 長所 | 短所 |
|---|---|---|---|
| クラウドベース | CDNまたはクラウドベンダーが提供(例:Cloudflare、AWS WAF) | 簡単なセットアップ、自動スケーリング、DDoS保護付き | ルールの制御が少ない、レイテンシが追加される、コスト |
| ホストベース | Webサーバーにインストールされたソフトウェア(例:ModSecurity) | 完全な制御、余分なネットワークホップなし | サーバーアクセスが必要、メンテナンスのオーバーヘッド |
| ネットワークベース | サーバーの前にあるアプライアンスまたは仮想マシン | 集中管理、高性能 | 高価、スケーリングが複雑 |
多くのチームにとって、クラウドベースのWAFは始めるための最速の方法であり、ホストベースのWAFは特定のアプリケーションに対してより多くのカスタマイズを提供します。
探すべき主な機能
- ルールセット: OWASP Top 10および一般的なCMSプラットフォーム用の事前構築されたルール。
- カスタムルール: アプリケーションのロジックに基づいて独自のルールを書く機能。
- レート制限: 単一のIPまたはセッションからのリクエストを調整して、ブルートフォースとスクレイピングを防ぎます。
- ボット管理: 良いボット(検索エンジン)と悪いボットを区別します。
- ログとアラート: インシデント対応とコンプライアンスのための詳細なログ。
- API保護: REST/GraphQL APIのスキーマ検証と異常検出。
WAFの導入方法:ステップバイステップ
- 導入モデルを選択します。 インフラストラクチャとチームのスキルに基づいて、クラウド、ホスト、ネットワークベースを決定します。
- 監視モードで開始します。 WAFを検出のみモードで有効にし、ブロックせずにトラフィックをログに記録します。これにより、通常のパターンを理解できます。
- ログを分析し、ルールを調整します。 誤検知(正当なリクエストが攻撃としてフラグされる)を探し、ルールを調整するか例外を追加します。ログアナライザーを使用してWAFログを効率的に解析します。
- 段階的にブロックを有効にします。 信頼度の高いルール(例:既知のSQLiパターン)から始め、自信がつくにつれて徐々に有効にします。
- CI/CDと統合します。 Infrastructure as Codeを使用する場合、WAFルールをコードとして管理し、変更をバージョン管理およびレビューします。
- 監視と更新。 定期的にログをレビューし、ルールセットを更新し、アプリケーションの進化に合わせて調整します。
例:ModSecurityルール
クエリ文字列に../を含むリクエストをブロックする簡単なModSecurityルールです。これは一般的なパストラバーサル試行です:
SecRule ARGS "\.\./" \
"id:1001,phase:2,deny,status:403,log,msg:'Path Traversal Attempt'"
このルールはすべてのリクエスト引数(クエリ文字列、ボディ)を検査し、../が見つかった場合にリクエストを拒否します。本番環境では、OWASP CRSのようなより包括的なルールセットを使用します。
ベストプラクティスと落とし穴
- WAFだけに依存しないでください。 これは補完的な層です。安全なコーディングとパッチ適用は依然として不可欠です。
- 正当なトラフィックをブロックしないようにしてください。 ルールを慎重に調整し、誤検知を監視します。
- ルールを最新の状態に保ちます。 新しい脆弱性が定期的に出現するため、ルールセットの更新を購読します。
- APIも保護します。 現代のアプリはAPIを多用するため、WAFがそれらをカバーしていることを確認します。
- ログと監視。 WAFは、そのログから得られる洞察と同じくらいの価値しかありません。
FAQ
WAFは安全なコーディングを置き換えますか?
いいえ。WAFは多層防御の層です。多くの攻撃をブロックできますが、コードの脆弱性は依然として修正する必要があります。WAFは時間を稼ぎ、保護を追加しますが、安全な開発プラクティスの代わりにはなりません。
WAFはウェブサイトを遅くしますか?
はい、検査はある程度のレイテンシを追加します。クラウドWAFは通常数ミリ秒を追加しますが、ホストベースのWAFはルールの複雑さに応じてより多くを追加する場合があります。適切な調整とキャッシュにより影響を最小限に抑えることができます。
クラウドWAFと自己ホスト型WAFのどちらを選ぶべきですか?
クラウドWAFはセットアップとスケーリングが簡単で、専任のセキュリティスタッフがいないチームに最適です。自己ホスト型WAFはより多くの制御を提供し、大規模では安価になる可能性がありますが、メンテナンスが必要です。チームの専門知識と予算を考慮してください。
WAFログを分析する準備はできましたか?Nginx Log Analyzerを使用してトラフィックパターンを解析および視覚化し、WAFルールの調整と異常の迅速な発見を支援します。