今回は、WAF(Web Application Firewall)についてご紹介したいと思います。
WAFの解説サイトは多くありますが、WAFは、理論としては分かっていても、実際に触ってみないと具体的にどういったものなのか分かりづらい製品かと思います。弊社のWAFを検討されているお客様からも「WAFとIPSの違いがいまいち分からない」といった声をよく頂きます。
そこで、 WAFの具体的な仕組み、製品の種類/特長、チューニング、WAFの効果について、 SOCベンダーの観点も交えてご紹介します。

WAFの対象範囲

まずは一般的な説明からとなってしまいますが、Webアプリケーションを外部からの攻撃から守るためのセキュリティ製品は、主に、ファイアウォール、IPS、WAFが挙げられます。それぞれ、役割・対象範囲が異なっています。

図1.各機器の対象レイヤー/プロトコル例

ファイアウォールは、機能としてはIPアドレスとポート番号によるフィルタリングで、許可するものを通します。
IPSは、対象とするプロトコルや製品(OS、各種ソフトウェア)は幅広く、アプリケーション層に対しては主にシグネチャマッチングで攻撃を検知します。
WAFは、こちらも主にシグネチャマッチングで攻撃を検知しますが、名前の通りWebアプリケーションに対する攻撃の検知が専門で、HTTP上での攻撃を対象としています。ただし、対象製品の観点から見ると、 Webアプリケーションだけではなく、HTTP経由で攻撃できるソフトウェア(apache等のWebサーバ製品やTomcat等のAPサーバ製品等)やOS等の脆弱性も対象としているWAFも多くあります。

WAFとIPSの違い

WAFとIPSは、HTTP上の攻撃を検知/遮断するという点で機能が重複しており、どちらを導入したらいいのか、両方必要なのか、判断が難しいかと思います。
IPSは、様々なプロトコル/製品を対象としているため、Webサーバ以外のサーバも公開しているような環境では、幅広く防御することができます。また、システム内部間の通信を検知/遮断する用途としても利用できます。
しかし、Webアプリケーションを防御対象とした際に、IPSでもWebアプリケーション向けのシグネチャが多く提供されており、WAFとの具体的な違いが分かりづらいかと思います。
シグネチャは、攻撃コードに含まれる文字列を定義したものです。
WAFとIPSのシグネチャには、大まかに以下のような違いがあります。

図2.シグネチャの違い

例として、とあるWebアプリケーションにRCE(リモートコード実行)の脆弱性があるとします。
特定のパス・パラメータに対してコマンドを入力すると、コマンド実行ができてしまうというものです。

図3.シグネチャの検知箇所例

図3の例は、この脆弱性を利用して、スクリプトをダウンロードして、権限変更し、実行を試みる攻撃コードです。
IPSの場合は、この脆弱性に特化したシグネチャのため、検知条件はパス(/example/example.php)とパラメータ(cmd)を組み合わせたものとなります(IPS①)。
WAFの場合は、コマンドの部分で検知します。wget(WAF①)、chmod (WAF②) 、sh (WAF③)の3種類のシグネチャで検知します。このようにシグネチャが汎用的な作りとなっているため、新しい脆弱性が公開された際にも既存のシグネチャで検知できることが多くありますし、独自開発したアプリケーションにも対応できるようになっています。

ただし、IPSでも、SQLインジェクションやXSS等を対象とした、特定の脆弱性に依存しない汎用的なシグネチャが提供されている製品も多くあります。また、WAFでも、各種ソフトウェア製品の特定の脆弱性を対象としたシグネチャを提供している製品もあり、ややこしいところではあります(さらに、WAF製品の中にはシグネチャマッチングではない独自のロジックで検知するものもあります)。

シグネチャの違いをさらに深掘りすると、検知傾向や運用の観点で以下のような差異があります。
Webアプリケーションに対する防御という観点では、WAFの方が特化しているため、IPSよりもより多くの攻撃を検知できる可能性があります。ただし、WAF/IPSの効果を最大限に発揮できるよう運用する場合は、WAFの方が運用負荷は高くなる傾向があります(MBSD-SOCで扱っている製品の観点からのため、製品や運用の仕方、サイトの仕様等にもよります)。

表1.シグネチャの違いによる検知傾向・運用の差異

特性が異なるため、一概にどちらの方がよいというわけではなく、システムの構成、予算等を総合的に検討して選定することになるかと思います。

製品による機能・シグネチャの違い

表1ではIPSとの違いとして比較しましたが、WAF製品の中でも色々な機能や特色があります。
大まかに以下の２パターンに分けることができます(これらの中間のような製品もあります)。
これらの違いは、防御性能だけでなく、運用にも大きく影響してきます。

図4.機能/運用の違い

「高機能タイプ」の方が、より多くの攻撃を検知できる可能性が高く、Webアプリケーションの仕様に合わせて柔軟な対応ができます(本来WAFはサイトの仕様に合わせて適切にチューニングすべき)。しかし、そのためには高度なスキルが必要で、運用工数も多くかかります。また、製品自体も高価です。
「シンプルタイプ」は、クラウド型に多く、サービス/製品によっては何も運用しなくてよいものもあります。逆にいえば、サービス内でポリシーが共通のため汎用的に遮断できるシグネチャしかない(遮断しているのでアラートログから影響確認する必要がない)、誤遮断してサービスに影響が出ても対応がしずらい、等といった懸念があります。しかし、安価なものが多くあります。
そのため、どちらがいいというわけではなく、これも、必要な機能、運用体制、守るべき資産に対するコスト等を考慮して選定するのがよいかと思います。

製品による構成の違い

構成面においては、大きく、クラウド型、アプライアンス型、ホスト型に分かれます。
システム全体の構成や費用、導入の難易度等を考慮して選択することになるかと思われます。

図5.WAFの構成例

図5は構成の一例です。
クラウド型は、既存システムにWAFを追加したい時に、構成の変更がないため(DNS変更のみ)導入が容易です。
オリジン側では、ファイアウォールで送信元IPアドレスをクラウドWAFからのみ許可するよう制限します。また、クラウドWAFはリクエストのHostヘッダーを見てオリジンに転送するものが多いかと思われますが、これにより、IPアドレス指定で無差別にアクセスしてくるスキャンを全て防御することができる、といった効果もあります。これだけでも非常に多くの攻撃から防御することができます。
「シンプルタイプ」のサービスが多くありますが、SOC付、DDoS防御/CDN機能も持つ高機能なサービス等、様々なものがあります。

アプライアンス型は、WAF専用機や、ロードバランサー上で稼働するものがあります。
SSLアクセラレータも兼ねる場合はここでTLSを終端するため、WebサーバはSSL/TLSの攻撃は直接受けない構成となります。
「高機能タイプ」の製品が多くあります。

ホスト型は、サーバにインストールする構成のため、リバースプロキシとして実装できる製品もあります。
こちらも「高機能タイプ」寄りですが、オンプレに導入したいけれどシステムの規模が小さく高価なアプライアンス機器は不要、といった場合等、活用範囲は様々あるかと思われます。

シグネチャチューニング

チューニング不要がコンセプトのWAF製品/サービスを除いて、基本的にWAFはチューニングが必要となります。
WAFのシグネチャ数は製品によって様々ですが、数百から数千のシグネチャが提供されており、これらの各シグネチャに対して遮断/検知、有効/無効のチューニング設定を行い、ポリシーを作成します。
メーカーからデフォルトポリシーが提供されている製品が多くありますが、WAFの検知傾向はサイトの仕様によって本当に様々ですので、適切にチューニングすることが望ましいです。

チューニングは、検知傾向を確認しながら、一例ではありますが以下のような観点で行います。

■遮断/検知
正規の通信を遮断しないように、攻撃のみ検知するシグネチャを遮断設定にします。
メーカーとして検知精度が高いと評価されているシグネチャでも、サイトの仕様によって誤検知することもあるため、実際に検知傾向を確認しながら判断することが望ましいです。例えば、CMSを利用しているサイトではXSSを検知するシグネチャで誤検知することが多くありますし、入力されたメールアドレスで思いも寄らない誤検知をすることもあります。

■有効/無効
対象サイトで使用していないソフトウェア等に関連するシグネチャについて、もし検知/遮断不要であれば無効化します。
攻撃を全く検知せず正規通信だけ過剰検知するようなシグネチャもあったりしますので、それらも無効化します。
サイトの仕様によっては、ログインする度に検知してしまう等、無効化しないとログ量が膨大になってしまう場合もあります。
ただし、一度無効化してしまうと、以降は検知傾向を確認できなくなってしまうため、慎重に判断する必要があります。

悩ましいのは、攻撃の検知に非常に有効なのに誤検知もするシグネチャの扱いです。
遮断できないため、検知したらアラート確認/影響確認が必要ですが、検知量が多いと運用負荷が高くなります。
特定のURLやパラメータ等を指定して検知除外できるWAF製品もあるため、誤検知内容によっては活用できます。

チューニングは、WAFの初期導入時だけでなく、シグネチャ追加やサイト仕様の変更、攻撃傾向の変化に対応するため、継続的に実施する必要があります。
しかしながら、実際に実施するとなると非常に高度なスキルが要求されます。
MBSD-SOCでは、各シグネチャを熟知したアナリストが、独自に開発したチューニングツールも活用してチューニング案をご提案しています。

WAFの効果

実際の環境下においては、どういった時に「WAFがあってよかった！」となるのでしょうか。
Webサイトは色々なソフトウェアで構成されています。

　①独自に開発したアプリケーション
　②オープンソース/パッケージ等の各種製品(CMS等)
　③Webアプリケーションを構成する言語/フレームワーク
　④Webアプリケーションが稼働するミドルウェア
　⑤OS

①については、WAFを導入しているようなサイトであれば、開発時にSQLインジェクションやXSS等に対してしっかり対策していると思われますし、脆弱性診断の指摘事項に対しても対応すれば、実際にはほぼ脆弱性はないというケースが多いのではないかと想定されます。とはいえ、日々のコンテンツやアプリケーションの改修で新たに脆弱性が出てしまう可能性はありますし、診断の指摘にすぐにアプリ改修できない場合等にも暫定策として有効です。

②～⑤については、こちらも日々脆弱性修正されていますので、最新バージョンを使用すれば、基本的には脆弱性はない想定です。
しかし、脆弱性はある日突然公開されます。
攻撃者は、SHODAN等のツールを使用すれば、どのサイトで脆弱性対象のソフトウェアが使用されているかすぐに簡単に調べることができてしまいます。
最近は脆弱性の公開からすぐに攻撃が始まるケースが多くあります。
サイト管理者が、適切に構成管理し、定期的にリリース状況を確認していても、対応方法を検証してバージョンアップ日時を調整して・・・、とやっていると、その間に攻撃を受けてしまう可能性があります。

図6.サイト管理者と攻撃者のタイムライン

しかし、WAFを導入していれば、新しく公開された脆弱性に対しても、既存のシグネチャで検知/遮断できる可能性があります。
MBSD-SOCの検知実績でも、脆弱性公開から程なくして攻撃が開始されたがWAFで遮断できていた、といったことが多くあります。最近の事例では、 Atlassian「Confluence」に、OGNLインジェクションによるRCEの脆弱性があることが2021年8月25日に公開されましたが、MBSD-SOCでは9月1日から攻撃を観測し始めました(国内で注意喚起が行われたのはこの後)。
このような、しっかり対策していても、時間的に攻撃者優位でどうしようもないケースがWAFの恩恵を大きく得られる部分かと思われます。
(WAFを導入していても、恒久対策としてパッチ適用はお願いします！)

さいごに

MBSD-SOCでは、2021年8月に、F5社のNGINX App Protect(NAP)を監視サービスのラインナップに加えました。
NAPは、NGINX Plusにモジュールを追加する形式のホスト型WAF製品で、BIG-IP AWAFと同等の機能を備えています。
先日ラインナップに加わったCloudflare WAFと合わせて、MBSD-SOCでは様々なWAF製品に対応しています。
WAFの選定や監視、運用でお困りの際には、是非MBSD-SOCへご連絡ください。