「WAF」は2006年のネットサービス防御トレンドか?:スパム時代のサニタイズ開発手法(2/2 ページ)
従来のファイアウォールではWebアプリケーションを守り切れない。インターネット上のサービスに根ざす企業では、サイト稼働率が信頼のバロメーターだ。Webアプリケーションを使っているならば、WAFの導入が必須のものとなっている。
アプライアンスによるハードウェア実装
後述するソフトウェアWAF実装では、構築の手間や運用ノウハウなどすべてを把握することが要求される。この場合のメリットは、敷居が高いものの自由に設定することができるため、構築の際の技術力に応じて十分に機能を発揮してくれることだ。詳細は後述しよう。
一方で、平均的な機能がそろっていればいい、といったニーズにはハードウェア実装によるアプライアンス製品が人気となっている。ソフトウェア実装に比べ初期投資が高価であるが、ベンダー保証が受けられることや、WAFの機能だけで占有する機器のためパフォーマンスが期待できることが大きい。また、専用のGUI管理画面を用意するために、目的重視の運用ができることにも特徴がある。
そして日ごろの運用シーンを想像してほしい。いくら技術力に長けた構築や運用の管理者であっても、日々のメンテナンスに必要以上の手間を強いるようでは危険性を回避し続けられる体力があるかどうか? という懸念だ。このため、運用形態は極力シンプルにする必要があり、運用メンバーの多重化こそがシステム複雑化に対する課題かもしれない。
アプライアンスのメリットには運用の容易さも
概してソフトウェア実装によるWAFは、ほかのサービスと並行動作させることが多い。このためアプリケーションファイアウォールの機能だけにリソースを占有することが難しいことが多い。このため、専用のハードウェアを用意し、アプライアンス製品として機能させることには大きな意味があるのだ。また、アプライアンスならではのサポートと、付加機能にも期待できるだろう。
付加機能としては、第一に操作性が挙げられる。概してソフトウェア実装の場合には、GUIの運用画面を用意することが考えづらい。製品として出荷するならば必須だが、エンジニアが構築した環境であれば誰もが扱いやすい画面を用意することは後手になりがちだ。
このような理由からも、これまではWebアプリケーションファイアウォール導入の敷居が高かったといえる。しかし、本当に必要としているのは、専任のIT管理者が不在、比較的システムに多大なコストを掛けられない異業種のオンラインショッピングサイトなどだろう。アプライアンス登場は望まれていたものなのだ。
具体的な仕様を見ることでアプライアンスの実態を知ることができるはずだ。WAFのアプライアンスとして知られているF5ネットワークスジャパンの「TrafficShield」を例に特徴を見てみよう(関連リンク)。
TrafficShieldでは、次のような攻撃に対し効果を発揮する。これらの性能差は別として「機能性そのもの」はソフトウェア実装とほとんど変わりない。
- SQLインジェクション
- クロスサイトスクリプティング
- 強制ブラウジング
そして一番の特徴は、ハードウェア仕様にある。シリーズ中のモデル「TrafficShield 4100」では、2Uの筐体にデュアルCPUとしてAMD Opteronプロセッサ 242の1600MHzを2つ装備、10/100/1000カッパーに4つのポートを用意し、SSLアクセラレータ機能も搭載している。これらを最終的にソフトウェア実装するためには、後述するmod_securityと呼ぶモジュールインストールだけでは済まず、関連するハードウェア調達や暗号化設定などが伴うだろう。初期の構築であれば、場合によって週単位以上の時間を要するかもしれない。
また、TrafficShieldでは日本語の2バイトコードにも対応しており、オープンソース実装の多くが見落としがちな日本語の処理も予めセットアップされている。
インタビューに応じた同社のシニア プリセールス コンサルタントの伴崇博氏は、「米国では特に著名なサイトで数多く導入されている実績があります。国内でも注目されてきており、オンラインショッピングサイトや金融系などセキュリティに厳しいサイトでは特にニーズが高いでしょう」と指摘する。
F5ネットワークスジャパン、マーケティングマネージャの伊藤利昭氏からは、TrafficShieldによる既存のファイアウォールや不正侵入検知システム(IDS:Intrusion Detection System)では防げない優位さが強調された
次に、ハードウェア実装のWAFがどのような基盤で稼働しているかを判断するためにデベロッパー向け情報として、WAFのソフトウェア実装例を示しておこう。
WAFソフトウェア実装「mod_security」の場合
WAFにはソフトウェアレベルで実装するものがある。ここで挙げるのは、Webサーバのアドオンとして機能し、Webサーバソフトで定番「Apache」への追加によってWAFを実現する「mod_security」と呼ばれるモジュールだ。
mod_securityは下記のサイトにて配布されているオープンソースソフトウェアだ。
ここでは、より詳細なソースファイルからビルド手順は割合しよう。その効果を確認することで前述したハードウェア実装のWAFの基本機能を垣間見ることが目的だからだ。概ねハードウェア実装のWAFでも同じような処理をしているものと想像することができるだろう。
mod_securityの動作具合は、インストール後、自由に設定することができる。次のように、Webサーバソフト(Apache)の設定ファイル内に記述するのだ。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
上記の設定で注目すべきは、SecFilterEngine Onで機能をオンにして、SecFilterのここでは4行の定義内容でタグの無効化をしている点だ。「/etc/passwd」「<」「>」「\」「'」の5種類の指定が確認できる。
これらを感知した場合の挙動は、アクセスを拒否し(..... "deny,log,status:406")、ログを採取して処理を終える(/var/log/httpd/audit.logに保存)。この場合、アクセス元(ブラウザなど)には、HTTPレスポンス既定としてブラウザ判別が可能な406(Not Acceptable)のコードが返される。また、SecFilterでさらにフィルタリングルールを追加することができる。
以下に実行例の画面を示す。ここでの注目点は、CGIスクリプトへ制御が渡る前に、Webサーバソフトのレベルでアクセス元へエラーを返していることだ。
そして、mod_securityのログファイルには、以下のような拒否記録が確認できる。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
関連記事
- サーバの複雑さが変えたセキュリティ「サニタイズ」とは
- 巧妙化するネット地雷原の避け方
- あのCGIがクラックされてしまった理由
- Perlは悪くない――CGIセキュリティホールの落とし穴
- Cookieは悪くない――潜む漏えいパターンの真実
- セキュリティホールで問うこれからの常識
- ネットセキュリティの考え方が変わった理由
- 攻撃の標的がOSからアプリにシフト――SANS Institute報告書
- セキュリティを意識したネットワークシステム設計、5つのポイント
関連リンク
Copyright © ITmedia, Inc. All Rights Reserved.