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

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

WAFとは

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

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

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

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

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

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

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

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

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

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

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

3つの導入形態

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

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

選び方の3つの基準

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

1. 運用開始までの期間と費用

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

2. 設定の自由度

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

3. 導入後の運用の負担

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

運用で気をつけること

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

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

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

よくある質問