オープンソースのウェブアプリケーションファイアウォール（WAF）であるModSecurityの最新版ではCore Rule Set（CRS）がサポートされるようになった。CRSはウェブアプリケーションに見つかったセキュリティ上の脆弱性の危害から保護するためのルールを定義するのに利用できる。今回ModSecurityプロジェクトチームがリリースしたこのファイアウォールフレームワークのバージョン2.5.10には、他にも平行テキストマッチング、Geo IP解決、クレジットカード番号検出、コンテンツ挿入への対応、自動ルール更新、スクリプティングといった機能も含まれている。
ModSecurityではセキュリティフィルタの作成、攻撃の特定、安全な入力の検証を手動でおこなうことができる。またLua言語による新しいAPIも備え、ウェブアプリケーションを安全にするための複雑なロジックを実装するプラットフォームをディベロッパに提供する。
ModSecurity Core Rulesはイベントベースのプログラミング言語で先月バージョン2.0がリリースされた。Core Rulesはトランザクションのどんなステップでも確認できたり、複雑なロジックを作るためにルールを組み合わせたりすることができる。他の侵入検知システム（IDS）や侵入防御システム（IPS）では既知の脆弱性についてのシグニチャを指定するやり方を採用するが、Core Rulesは非独自のルールをベースにする。これにより、大抵は独自コードを含んでいるウェブアプリケーションを、よくあるセキュリティ脆弱の危害から守ることができる。Core Rulesフレームワークではウェブアプリケーション保護のために次のようなテクニックを用いている。
- HTTP保護 - HTTPプロトコル違反を検出したり、ローカルでの利用ポリシーを定義する
- 一般的なウェブ攻撃に対する防御 - 一般的なウェブアプリケーションセキュリティ攻撃を検出する
- 自動検出 - ボット、クローラ、スキャナ、そのほかの悪意ある活動を検出する
- トロイに対する防御 - トロイの木馬のアクセスを検出する
- エラー偽装 - サーバから送るエラーメッセージを偽装する
InfoQはBreach Security社のアプリケーションセキュリティリサーチ主任でありModSecurityのプロジェクトリードでもあるRyan Barnett氏とインタビューをおこない、ModSecurityのこれら新機能と他のウェブアプリケーションファイアウォール製品との比較について聞いた。
ModSecurityフレームワークは他のウェブアプリケーションファイアウォール製品、特にCisco、Imperva、Breachのようなハードウェア機器を基本とした製品と比較してどうでしょうか。
オープンソースであるModSecurityと他の商用製品との違いは数多くあります。
まずハードウェア機器とソフトウェアシステムとの違いです。ModSecurityはソフトウェアのウェブアプリケーションファイアウォール（WAF）エンジンで、Apacheモジュールとなっています。そのため、上流にある別のデバイス上にあるものではなく、対象となるウェブサーバ自体に内蔵されます。しかしApacheの設定をしてリバースプロキシにすることで、ModSecurityを上流においたようなことも実現できます。
ソフトウェアWAFの利点については、大規模にスケール配備する場合、外部のハードウェアデバイスを使うと水平スケールすることになりますが、WAF機能をもったウェブサーバを分散させる方がより現実的です。WAFを内蔵する利点には、SSL復号をおこなう必要がないということもあります。ウェブサーバでプリプロセスをおこなってModSecurityにデータを渡すことができるからです。
ソフトウェアWAFの欠点は、機能的なメリットは、商用であることとオープンソースであることの違いです。ModSecurityは複雑なロジックが可能となる先進的なルール言語とLUA APIを持っています。ネガティブセキュリティ（既知の不正入力を探索する）もポジティブセキュリティ（既知の正常な入力のみを許可する）も構築することが可能です。このやり方の一番の制限はModSecurityがこれらのルールを自動作成できず、手動で作成しないといけないことです。このためには2つシナリオのどちらかである必要があります。
- ウェブサーバの制限で新しいソフトウェアを追加できない場合には使えません
- サーバのローカルリソースを消費します
- レイテンシの影響 - 多くの商用WAF製品は、スニッフィングモードで作動してHTTPトランザクションへのアクセスや視覚化をおこなえます。これによりインラインで展開した際のレイテンシの影響をのぞくことができます
A. ウェブアプリケーションが頻繁に変更されない
または
B. ポジティブセキュリティについて脆弱性のスキャニングした結果を活用できる
Bのやり方を既知への問題の実質的なパッチとして利用することに関してModSecurityは大変適しています。ハイエンドの商用WAFであれば自動学習や自動プロファイリングの仕組みを持っていて、これらのポジティブセキュリティのプロファイルを作成したり、クライアントとウェブアプリのインタラクションで予期されるものを学習したりできます。
ネットワークルータはウェブサーバ（Apache）よりもセキュリティ管理に優れているでしょうか。
それは場合によります。セキュリティポリシーの実施、ログの解析、レポーティングを一カ所でおこなえるのはいいことです。ただ技術的な面からいえば、実際に守られているウェブアプリケーションと同じところでデータを評価しているのが確実であることは重要なことですから、アプリケーションの内部あるいはその近くにあることは理想的といえます。このことで誤りの起きる確率を減らすことができます。
ModSecurityはMicrosoft IISのようなApache以外のウェブサーバでも動くのでしょうか。
今のところできません。しかしロードマップでは計画されています。第一の目標はModSecurityをISAPIフィルタとしてIISにプラグインできるようにすることです。
Core Rule Setの新機能と、それがどのようにディベロッパやウェブ管理者がウェブアプリケーションを脆弱性から守るのに役立つかを具体的に教えてもらえますか。
新しいCore Rules Set（CRS）には多くのアップデートが含まれています。
- クロスサイトスクリプティング（XSS）、SQLインジェクション、リモートファイル挿入（Remote File Inclusion）といった攻撃への防御
- Snortシグネチャ - Emerging ThreatsのサイトにあるSnortシグネチャを変換した大量のルールセットを含み、今後もBreach Security Labsから定期的に新しいシグネチャを提供します
- 協調可能なルール - 協調的な操作が可能になり、どのルールがマッチするか、マッチが可能な箇所、どのペイロードがマッチするか、それらをすべてのCRSルールで指定するための変数が使用可能です
- 異常性のスコアリング - 各ルールについて全体的な異常性のスコアが計測され、ユーザはどれくらいの閾値が対象となるサイトにとって適切かを選ぶことができます
- 容易な例外処理 - ユーザがルール自体を編集しなくてもCRSチェックをオーバライドして独自の例外を追加することができるようになりました
ウェブアプリケーションファイアウォールを探しているネットワーク管理者やディベロッパが心に留めておくべきベストプラクティスなどはありますか。
OWASP Best PracticesのUse of Web Application Firewallsドキュメントを見ましょう。これには、どのようなとき/いつ/どのようにWAFが組織にとって有益となるかを評価した膨大な情報が含まれています。
WASC Web Application Evaluation Criteria（WAFEC）ドキュメントも見ましょう。このドキュメントにはさまざまなWAF機能の概要が書かれています。その中からみなさんにとって重要な機能をピックアップし、WAF評価の基準にするとよいでしょう。
WAFが収集したデータを元にした事故対応プロセスを設けましょう。HTTPトラフィックを確認することができるので、以前なら見逃していたあらゆることを見つけることができるでしょう。そして新しいデータに基づき対応範囲を拡大するような計画をしておく必要があります。
ModSecurityプロジェクトの今後のロードマップはどうなっているでしょうか。
長期的には、ModSecurityを単体完結型のライブラリにしてどんなアプリケーションにもプラグインできるようにしたいと考えています。Breach SecurityはOpen Information Security Foundation（OISF）のプロジェクトに活発に参画していて、新しいネットワーク侵入検知システムをつくっています。これからはHTTPエンジンにも取り組むつもりです。この作業の成果はModSecurity開発にも取り込まれるでしょう。