# WAFとは？できること・できないことと3つの導入形態

WAF（Web Application Firewall）で防げる攻撃と防げない攻撃、アプライアンス型・ソフトウェア型・サービス型の違い、選び方、仮想パッチとしての使い方と運用の注意点を、IPAとOWASPの資料をもとに解説します。

WAF（Web Application Firewall、ワフ）は、Webアプリケーションへの通信を検査して、脆弱性を狙った攻撃を検知・遮断する仕組みです。IPAは、WAFをWebアプリケーションの脆弱性を悪用した攻撃から守る対策の一つとしつつ、脆弱性による被害の「緩和策」と位置づけています。つまり、脆弱性そのものを直す対策の代わりではなく、修正が間に合わないあいだの被害を抑える層です。

<Points>

- WAFは主にHTTP/HTTPSの通信を検査し、シグネチャ（攻撃の定義）に当てはまる通信を検知・遮断する
- 導入形態はアプライアンス型・ソフトウェア型・サービス型の3つ。費用・設定の自由度・運用の手間で選ぶ
- 導入すればすべての攻撃を防げるわけではない。脆弱性の修正と組み合わせ、設定の見直しを続ける

</Points>

## WAFとは

通常のファイアウォールは、IPアドレスやポート番号で通信を許可・拒否します。Webサイトへの攻撃の多くは、許可されている443番ポートへのHTTPSリクエストの中身に仕込まれるため、それだけでは止められません。WAFはリクエストの中身を見て、[SQLインジェクション](/sql-injection/)や[XSS](/xss/)のような攻撃のパターンを探します。

OWASPの仮想パッチのチートシートは、検査の考え方を2つに分けています。

<Compare>
<Column title="ネガティブセキュリティモデル">

- 既知の攻撃を検知するルールの集まり
- 早く導入できる
- 回避されやすい

</Column>
<Column title="ポジティブセキュリティモデル" tone="accent">

- 正しい入力の特徴を定義する（許可リスト）
- 当てはまらないものは拒否する
- OWASPが推奨する方式

</Column>
</Compare>

ネガティブモデルのルールの例として、OWASP CRS（Core Rule Set）があります。CRSは、ModSecurityや互換のWAFで使える汎用的な攻撃検知ルールの集まりです。

## WAFで防げること・防げないこと

IPAの「Web Application Firewallの導入に向けた検討項目」は、WAFはWebサイトを守るのに有効だが、すべての攻撃から守れるものではないとして、次の点を挙げています。

<Figure title="WAFの検知の範囲" source="IPA「Web Application Firewall(WAF)の導入に向けた検討項目」">

| 項目 | 内容 |
| --- | --- |
| 検査する通信 | 一般的なWAFはHTTPとHTTPSだけを監視する |
| 検知できない例 | SSHを使ったサーバーへの不正アクセス、FTPを使った不正なファイルアップロードの試み |
| 新しい攻撃 | 対応するシグネチャがベンダーから提供されるか、運用者が作るまで検知できない |
| 既存のシグネチャ | 過去の脆弱性に似た攻撃や、独自開発アプリの脆弱性なら検知できる場合もある |

</Figure>

また、ベンダーが公開するシグネチャを使うには、WAF製品のサポートが続いている必要があります。

WAFが検知するのは、リクエストの形で見分けられる攻撃です。たとえば[IDOR](/idor/)のように、正しい形のリクエストで他人のIDを指定するだけの攻撃は、通信の中身だけでは正規の操作と見分けにくく、アプリケーション側の認可チェックで防ぐ必要があります。

## 修正が間に合わないときの効き目

IPAの資料は、2017年のApache Struts2の脆弱性（S2-045）を例に、WAFが役立つ場面を説明しています。

<Flow
  title="S2-045の公表から被害までの主な流れ（日本時間）"
  caption="IPAの資料の時系列から主な事象を抜粋"
  steps={[
    { label: "2017年3月6日 19時ごろ", note: "Apacheが脆弱性の情報を公開" },
    { label: "3月7日 午前", note: "中国のWebサイトでPoC（攻撃コードの例）が公開" },
    { label: "3月7日 17時ごろ", note: "日本国内で攻撃を検知" },
    { label: "3月7日中", note: "WAFベンダーから攻撃を遮断できるシグネチャが公開" },
    { label: "3月8日 5時ごろ", note: "国内の支払いサイトへの攻撃が発生" },
  ]}
/>

IPAは、ソフトウェアの更新を公開当日に行うことや、短期間で脆弱性を修正することは難しく、急速に広がる悪用に追いつけないと指摘しています。そのうえで、WAFを導入して適切に運用していれば、こうした場面で被害を水際で食い止められる可能性があるとしています。

OWASPは、脆弱なコードを変えずに既知の脆弱性への攻撃を検知・遮断する層を「仮想パッチ」と呼んでいます。開発者の手が足りない、利用者が変更できない外部製品である、開発を外部に委託している、といった理由でコードをすぐ直せない場面を想定したものです。ただしOWASPも、仮想パッチは脆弱性そのものを取り除かず、コードの修正と両立させるものだとしています。

## 3つの導入形態

IPAは、WAFの製品・サービスを3つに大別しています。

<Figure title="WAFの導入形態" source="IPA「Web Application Firewall(WAF)の導入に向けた検討項目」">

| 形態 | 仕組み | 主な利点 | 主な注意点 |
| --- | --- | --- | --- |
| アプライアンス型 | 専用の機器を組織のネットワークに置き、Webサーバーへの通信を通過させて検査する | Webサーバーに負荷をかけない。検知条件を細かく設定できる | 調達費用が高い傾向。ネットワーク構成の変更と自前の運用が必要 |
| ソフトウェア型 | WebサーバーにWAFのソフトウェアを入れて検査する | 専用機器が不要。ネットワーク構成の変更が不要 | サーバーの処理性能に影響しうる。更新と設定の見直しが必要 |
| サービス型 | 外部のWAF事業者のサーバーを経由させて検査する | 導入までの期間が短い。シグネチャの更新を事業者が行う | 設定できる項目が事業者に依存する。通信量が多いと割高になりうる |

</Figure>

IPAは、小規模な組織や運用の人員を用意できない組織でサービス型が選ばれていること、WAFを標準で提供するレンタルサーバー事業者も増えていることにも触れています。

## 選び方の3つの基準

IPAは、製品・サービスを選ぶ基準として次の3点を挙げています。

<Steps>
<Step title="運用開始までの期間と費用">

被害を受ける前に備えるなら導入期間を長めに取れますが、被害が出た後にそれ以上の被害を防ぐ目的なら、短期間で導入したい場合が多いとしています。一般に、期間はサービス型が最も短く、アプライアンス型が最も長いと考えられています。

</Step>
<Step title="設定の自由度">

どのサーバーへの通信を監視するか、どのシグネチャを有効にするかを設定できるかという観点です。独自のサービスを提供していて誤検知が多い場合は、検知対象の調整が必要になります。

</Step>
<Step title="導入後の運用の負担">

形態によっては、シグネチャの更新や有効にするシグネチャの調整が導入後も必要です。社内に担当者を置けない場合は、運用を専門の事業者に委託することも検討できます。

</Step>
</Steps>

## 運用で気をつけること

IPAは、WAFで被害の可能性は下げられるものの、攻撃を検知・遮断し、利用者に悪影響を与えないためには、適切な設定と定期的なメンテナンスが必要だとしています。検知した通信が本当に攻撃だったかを、運用者が確かめる必要がある場合もあります。

<Note tone="caution">

いきなり遮断を有効にすると、正規の利用者のリクエストまで止めてしまうことがあります。OWASPは、仮想パッチを最初は「ログのみ」の設定で入れ、正常な通信を止めないことを確かめてから遮断に切り替えるよう勧めています。

</Note>

導入後も、次の点を定期的に確かめます。

- シグネチャとWAF本体が更新されているか
- 誤検知で止まっている正規のリクエストがないか
- Webサイトの機能追加に合わせて検査の設定を見直したか
- 検知のログを誰がいつ確認するか決まっているか

## よくある質問

### Q. WAFを入れれば脆弱性の修正は不要ですか？

不要にはなりません。IPAは、Webサイトに脆弱性が見つかった場合は、ソフトウェアの修正などの根本的解決と、WAFの導入などの保険的対策の両面から検討するよう勧めています。

### Q. 正規のリクエストが止められたらどうしますか？

誤検知です。IPAは、独自のサービスを提供していて誤検知が頻発する場合は、検知対象の調整が必要になるとしています。止まったリクエストとそれに当てはまったシグネチャをログで確かめ、そのURLやパラメーターに限って除外するなど、範囲を絞って調整します。設定できる項目は製品やサービスによって異なるため、選ぶ段階で確かめておきます。

### Q. 小さなサイトでもWAFは必要ですか？

自社で開発したアプリや、更新をすぐに適用できないソフトウェアを公開しているなら、検討する価値があります。運用の人員を用意できない場合は、サービス型や、レンタルサーバーが標準で提供するWAFが選択肢になります。

出典: [IPA「Web Application Firewall 読本」](https://www.ipa.go.jp/security/vuln/waf.html)、[IPA「Web Application Firewall(WAF)の導入に向けた検討項目」（PDF）](https://www.ipa.go.jp/archive/files/000072484.pdf)、[OWASP Virtual Patching Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Virtual_Patching_Cheat_Sheet.html)、[OWASP CRS](https://coreruleset.org/)