WAF(Web Application Firewall)の役割と必要性

連載 [第7回] :

2017年12月20日(水)

WAFとその役割

世の中におけるインターネットの拡大に大きな役割を果たしてきたものが「Webサーバ」と「Webアプリケーション」である点は、多くの方々に同意いただけるでしょう。現在皆さんが訪問するWebページやモバイルアプリなどはWebアプリケーションなくして成立しないといっても過言ではありません。

このWebアプリケーションと呼ばれるものにはさまざまなものが含まれますが、以下にいくつか例を示します。

インターネットバンキング
オンライントレード
Web開発フレームワーク
Webコンテンツ管理システム

これらの進化によって豊富なコンテンツと機能を持った高度なWebシステムを短期間で容易に作成できる一方で、内包するセキュリティの問題(ライブラリの脆弱性、脆弱な標準設定など)もまた継承されるという現実は見過ごされがちです。例えば、脆弱なモジュールを有した開発フレームワークで作成されたWebアプリケーションも脆弱なものとなってしまうのです。また、脆弱なWeb開発フレームワークやWebコンテンツ管理システムが広く使われることは攻撃者にとっても非常に魅力的で、効率的に攻撃を行なうための格好のポイントとなってしまいます。

このような背景から、ネットワークファイアウォールなどと同様にWebアプリケーションに特化したセキュリティ対策の必要性から生まれた概念が「WAF(Web Application Firewall)」です。

WAFと他のネットワークセキュリティ機器との保護機能の違い

ネットワークをベースにしたセキュリティ機器の代表的なものとして、「ファイアウォール」や「IPS(Intrusion Prevention System)」などが挙げられます。これらによる保護だけでは不十分なのでしょうか。保護対象となるレイヤや機能を比較しながら、WAFとの違いを明確にしたいと思います。

ネットワークファイアウォール

ここでは「次世代ファイアウォール」と呼ばれるものではなく、従来型のファイアウォールを例に挙げます。一般にファイアウォールはネットワーク層(OSIレイヤ1-3)、プロトコル層(OSIレイヤ4-6)を保護対象とします。つまり特定のIPアドレスから／宛て、あるいは特定のプロトコルやポートから／宛ての通信を検知してポリシーベースで許可／遮断することが役割です。言い換えると「これら通信の“中身”については考慮しない」というのが基本的な考え方で、入口／出口の扉を管理していると言えます。

IPS

かつては「IDS(Intrusion Detection System)」と呼ばれていたものからブロック機能(Prevention)をより強化したものがIPSと呼ばれています。ネットワーク層の一部、IPやTCP、UDPなどプロトコル層を包含しつつアプリケーション層(OSIレイヤ7)の一部も保護対象とします。一般的にアプリケーション層を保護する方法としては、あらかじめ決められたパターンをシグネチャなどの形式で配布したうえで、パターンに合致した通信を検知／遮断するというものです。

これらに対し、WAFは原則Web通信に特化したセキュリティ製品です。SMTPやNTP、TELNETなどHTTP以外のプロトコルに対する攻撃から保護する手段は基本的に有していません。そのためWAFを導入すればすべてのネットワーク上の脅威が排除できるわけではない一方、WAFでなければ実現できないWebアプリケーション特有の脅威からの保護機能も数多くあります。その技術的な特徴をいくつか挙げてみましょう。

Webセッション情報の維持・追跡

多くのWAFではWebセッションの開始から終了までを一連の「セッション」という単位で保持して追跡できます。これはTCP通信におけるセッションとは異なり、Webアプリケーションにアクセスしてログインする、カートに商品を移動して購入する、ログアウトするといった一連の流れすべてを把握できるということを意味します。一般的なファイアウォール、IPSではすべてのWebセッション情報を維持／追跡するのには不向きですが、Webに特化したWAF製品だからこそ実現できます。

豊富な表現力

主にIPSにおいては、特定の通信パターンをカスタムポリシなどとして独自に作成できます。しかしHTTP以外のプロトコルも保護対象とするIPSでは、一般的にWeb特有の詳細な情報を組み込むことは困難です。WAFにおいては前述したようなログインの成功／失敗、リクエストにおけるUser-Agent等ヘッダの有無や中身など豊富な条件を組み合わせてより詳細なカスタムポリシを作成できます。

Webアプリケーション特有の攻撃への対応

以下に代表されるようなWebアプリケーションを狙った攻撃の中でも、特に高度な攻撃はすべてをIPSなどで対応することは困難です。Webへの攻撃を前提とした多くのWAFでは当初からこれらの攻撃に対抗できるよう設計されており、また検知を回避するような試みにもある程度の耐性を有しているのが一般的です。

パラメータ改ざん
セッションハイジャック
クッキー改ざん
XML/SOAPへの攻撃

これらのことから、他のネットワークセキュリティ製品とWAFは競合するものではなく、むしろ多くの点で補完しあう、共存する存在と言えます。

図1：ネットワークファイアウォール／IPS／WAFそれぞれの保護対象レイヤ

導入方式、技術的違いに基づいた分類

今日、世の中には数多くの商用／OSSのWAFが存在しますが、その導入方式や技術的な違いは多岐にわたり、導入担当者を悩ませています。ここでは、それらをいくつかの切り口で分類してみたいと思います。

1. 検知方式における違い

ブラックリスト方式
あらかじめ問題のある文字列などのパターンを定義しておき、合致した通信を検知したら警報やブロックなどを行なう方式です。パターンの更新頻度や記述容易性などで区別されるのが一般的である一方、完全にパターンに一致しない疑わしい通信に関しては通過させることもあります。
ホワイトリスト方式
あらかじめ正しいとみなした通信を定義しておき、合致しない通信を検知したら警報やブロックなどを行なう方式です。頻繁に更新されないアプリケーションでは有効である一方、頻繁に更新される場合ではホワイトリストの更新そのものが大きな運用負荷になることもあります。

2. 導入方式における違い

オンプレミス型
従来型のデータセンター内に設置された保護対象サーバを守るため、同じようにデータセンター内にデバイス(物理や仮想アプライアンス)を設置する方式です。AWSやMicrosoft Azure、Google Cloud Platformなどのパブリッククラウド上にWAFインスタンスとして導入する場合も広義ではこちらに分類されることもあります。一般的に、後述するクラウド型と比較して幅広く詳細に設定できる傾向があります。
クラウド型
オンプレミス型と異なり、利用者が物理／仮想アプライアンスを保有することなく各事業者が提供する巨大なネットワークをリバースプロキシとして経由させWAF機能の提供を受ける方式です。機器調達が不要なことから短期間で容易に導入できる一方、細かい設定面でオンプレミス型に劣る、サービス事業者の品質に大きく依存するなどの点も特徴として挙げられます。

3. 導入形態における違い

ネットワーク型

エンドポイントとWebサーバの経路上に機器を配置する形態です。代表的な形態として、以下のものがあります(図2)。

リバースプロキシ型
Webサーバの前面にリバースプロキシとして配置します。ネットワーク構成の見直し、冗長性の確保やパフォーマンスへの影響などを考慮する必要があります。
モニタ(スニファ)型
スイッチのミラーポートなどからトラフィックを取得します。実トラフィックへの影響をほとんど与えない一方、悪意あるトラフィックの遮断動作は限定的で、ベストエフォートとなります。
ブリッジ(インライン)型
Webサーバとエンドポイントの間でブリッジとして透過的に配置します。エンドポイントからWAFの存在は意識されず、遮断動作に優れる一方でWAFによる遅延、冗長性の確保などを考慮する必要があります。

図2：オンプレミスWAF－ネットワーク型の導入形態

ホスト型

Webサーバにエージェントなどのソフトウェアをインストールする形態です。Webサーバに対するアドオンモジュールなどで提供されていることが多く、また一般にネットワーク構成を考慮する必要がないため、導入自体は比較的容易と言えます。一方でWebアプリケーションへのパフォーマンスの影響を事前に十分考慮したうえで検討する必要があります。

OSSにおける代表的なWAF

WAFも他のセキュリティ製品と同様に、商用だけでなくOSSでも非常に優れたものが多く存在します。これらを活用することで、商用製品に劣らないレベルにまでセキュリティレベルを高めることができます。

ModSecurity
当初はApache Web Server向けのモジュールとして開発された、歴史があり、最も有名なOSSのWAFと言っても過言ではないでしょう。現在ではApache Web Serverだけでなく、IISやNginxなどの対応Webサーバも拡張されているホスト型、モジュールタイプのWAFです。現在はTrustwave SpiderLabsが運営しており、各種ルールはCRS(Core Rule Set)という名前で提供されています。OWASPオープンコミュニティでは有志による開発が行われており、新たな脅威に対するCRSが継続的に提供されています。
Naxsi
Nginx向けに開発されたOSSとして提供されるホスト型、モジュールタイプのWAFです。ホワイトリスト型のアプローチを採用しており、“シグネチャによらない”点は特にユニークと言えます。
WebKnight
IIS向けに開発されたホスト型、モジュールタイプのWAFです。ISAPIフィルタとして動作します。

WAFの課題と将来

現在でもWAFと言うと、誤検知に代表される導入と運用の煩雑さを不安視している方が多く、その結果「導入に踏み切れない」という声をよく耳にします。しかしWebアプリケーションへの攻撃というものが最初に出現し、それに対抗すべくWAFという概念が誕生してからすでに長い歳月が経過しており、技術的には十分“枯れた”ものとなりつつあります。これまでのようにオンプレミス型の独立した製品として有償で提供されるだけでなく、ホスティング事業者などからオプションメニューとして提供されることもあり、WAFは以前よりも一般化してきている印象があります。

従来のように単純にPCのWebブラウザでアクセスするWebページだけでなく、APIアクセスのセキュリティ、増え続けるボットトラフィックへの対応など、WAFが必要とされる領域は広がり続けています。eコマースなどが先陣を切ってこぞってWAFの導入に踏み切ったのもいまは昔の話。ここで改めてWAFを再評価してみてはいかがでしょうか。