はじめに
JP-Secure社が本年2月に、廉価なホスト型WAFとしてSiteGuard Liteを販売開始すると発表しています。このβ版を入手して評価しましたので、その内容を報告します。商用製品の紹介ですので、以下に「重要情報の告知」を示します。
- HASHコンサルティング株式会社および徳丸浩（以下、単に徳丸浩と記述）は、SiteGuard Liteβ版の評価プログラムに申し込み、β版を無償で提供されている
- 徳丸浩はβ版提供以外に金品その他の提供を受けていない
- 本稿執筆時点でJP-Secure社とアフィリエイト契約はなく、その予定もない
- 評価結果をブログに書くことはJP-Secure社の了解を受けており、執筆内容の制約は受けていない
SiteGuard Liteとは
SiteGuard Liteは、JP-Secure社がApacheのモジュールとして提供するホスト型WAFで、今年2月から販売開始されます。JP-Secureには元々フル版のSiteGuardがありますので、SiteGuard Liteはその名の通り廉価版という位置づけなのでしょう。SiteGuardのラインナップ比較を下表に示します。| SiteGuard | SiteGuard for Server | SiteGuard Lite | |
| 配置方式 | ネットワーク型 | ホスト型 | ホスト型 |
| 実装形態 | Proxy | Proxy | Apacheモジュール |
| シグネチャ検査 | ○ | ○ | ○ |
| ホワイトリスト検査 | ○ | ○ | |
| Cookie暗号化 | ○ | ○ | |
| セッション管理 | ○ | ○ | |
| クローキング | ○ | ○ | |
| ライセンス費用 | 178万円 | 79万円 | 約30万円 |
SiteGuard Liteはシグネチャ検査に特化することで価格を下げた廉価版と言うことになります。
インストール
SiteGuard Liteは商用製品ですのでバイナリでの提供となります。Red Hat Enterprise Linux 4/5/6あるいはCentOS 4/5/6が動作可能ディストリビューションとなっています。筆者としてはUbuntu上でも動作確認してもらえるとありがたいと思いましたので、JP-Secure社にはそう要望しています。rpmによるインストールは基本的には以下の3コマンドです。
# rpm -Uvh siteguardlite-1.00-beta.i386.rpm
# cd /opt/jp-secure/siteguardlite/
# ./setup.sh
最後のsetup.shはApacheの各種パスなどを指定するものです。その他、SE Linux用のポリシーを必要に応じて適用します。
今回の検証では、Centos6.2を用いました。apacheをyumでインストールした環境では、上記setup.shの実行は、リターンキーを何回か押すだけで終わりました。
使ってみる
それでは、さっそくSiteGuard Liteを用いて各種の攻撃を防御してみましょう。防御対象には、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方」（以下、徳丸本）の脆弱なサンプル44-001.php(同書P120)を用いました。ファイル名はbooks.phpとしました。ソースの冒頭を以下に引用します。
<?php
session_start();
header('Content-Type: text/html; charset=UTF-8');
$author = $_GET['author'];
$con = pg_connect("host=localhost dbname=wasbook user=postgres password=wasbook");
$sql = "SELECT * FROM books WHERE author ='$author' ORDER BY id";
$rs = pg_query($con, $sql);
?>
// 以下略
このスクリプトにはSQLインジェクション脆弱性があります。それをSiteGuard Liteで防御してみましょう。以下は、徳丸本のP121に登場する「個人情報を盗み出す」攻撃です。
http://example.jp/books.php?author='+and+cast((select+id||':'||pwd+from+users+offset+0+limit+1)+as+integer)>1--以下のようにブロックされています。
しかし、これは典型的な攻撃だから当然のようにブロックするでしょうね。以下、いくつかのトピックスを見てみましょう。
(1)ApacheKillerとhashdosはデフォルトで防御
ApacheKillerとhashdosのexploitをかけてみたところ、デフォルト設定でブロックしました。
(2)「完璧なWAF」はどうか
一頃、WAF業界で話題になった「完璧なWAF」に出てくる攻撃についても評価しました。
仮にscriptをブラックリストに指定したとしましょう。それでもまだ不十分です。<IMG>タグでXSSが発動することをご存じでしょうか？プログラムなどでは<IMG>タグは画像添付に必須であり、WAFで禁止することは難しいのが実情で、ブラックリスト方式の課題となっています。という箇所についてですが、XSS Cheat Sheetに出てくるimg要素によるXSSの攻撃パターンのうちの一つが以下です。
http://example.jp/books.php?author=jav%09ascript:alert('XSS');これについても、きちんとブロックしています。
次に、SQLインジェクションについてはどうでしょうか。「完璧なWAF」からunion selectに関するくだりを引用します。
SQLインジェクション対応の駄目な例として挙げられるのは、複文などの直接攻撃しか考慮していないケースです。簡単に言うと、master..execなどの直接攻撃のみ禁止しているWAFは甘く、union selectなどのunionインジェクションを考慮したWAFはまだマシであると言えます（攻撃者の観点が分かっているという意図でマシと記載しました）。マシなWAFは「union select」は考慮するが、「union/**/select」はほとんどのWAFは通り抜けるということですが、SiteGuard Liteはどうでしょうか。
このブラックリストを通り抜けるにはコメントを使用します。たとえば、union/**/selectではどうなるでしょうか? 残念ながらほとんどのWAFは通り抜けてしまいます。
試してみると、
- union select … 通り抜ける
- union/**/select … ブロックする
(3)ライザムーン(LizaMoon)攻撃は防げるか
次に、これも一頃話題になった「新しいタイプのSQLインジェクション攻撃」であるライザムーン攻撃ではどうでしょうか。ライザムーンの特徴である(1)数値型項目に対するシングルクォートを用いない攻撃、(2)MS SQL Serverに対するセミコロンのない複文の特徴を持つ以下のパラメータで試しました。
author=17871+update+employee+set+number%3DREPLACE(cast(このパターンでも、SiteGuard Liteはブロックしました。
ModSecurityとの比較
ここで、SiteGuard LiteのライバルとなるであろうModSecurityとの比較を試みます。ModSecurityの最新版2.6.3とCore Rule Set(CRS)2.2.3の組み合わせと比べてみました。実は、今まで挙げてきた攻撃パターンは、ModSecurity（+CRS）もすべてブロックします。こう書くと、「では、無償のModSecurityでもよいのではないか」と思いそうですが、そうではありません。ModSecurityは「止めるべきでない」リクエストも止めてしまいます。つまり、過剰検知(False Positive)が多いのです。
たとえば、ModSecurityは「union select」という並びが入力にあるとブロックしますが、それだけでなく、「unionselect」や「unionAAAselect」もブロックします。すなわち、unionという単語の後のどこかにselectがあると、ブロックされます。
そのような例としてGoogle検索で適当に探した文を以下に示します。以下を入力として与えても、ModSecurityはブロックします。
Providing a credit union is a valuable benefit, and at Southern Select CCU, it will not cost your company a thing.
出展: http://www.southernselectccu.com/JoinUs.aspx (won'tをwill notに変更)次に、ライザムーン攻撃についてもModSecurityはブロックしますが、以下の単純なパターンでもModSecurityはブロックしてしまいます。
author=17871+update極めつきとして、ModSecurityは以下もブロックします。
author=夏目漱石CRSには標準で「英数字以外が4文字連続するとブロック」というルールがあるからです。
さすがにこれでは使えないので、ModSecurityのチューニングとして、過剰検知のルールを無効化してみましょう。
まず、上記をブロックしているルールをModSecurityの監査ログから探します。以下が該当します。
SecRule "ARGS" "@rx \\W{4,}" "phase:2,log,capture,t:none,t:urlDecodeUni,block,id:960024,rev:2.2.3,msg:'SQL Character Anomaly Detection Alert - Repetative Non-Word Characters',logdata:%{tx.0},setvar:tx.anomaly_score=+%{tx.warning_anomaly_score},setvar:tx.sql_injection_score=+1,setvar:tx.msg=%{rule.msg},setvar:tx.%{rule.id}-WEB_ATTACK/RESTRICTED_SQL_CHARS-%{matched_var_name}=%{tx.0}"
このルールをコメントアウトしてもいいですが、別の方法として、id=960024を無効にすると言うルールを追加しましょう。この方が、ルールのメンテナンス性が良くなります。
SecRuleRemoveById 960024
このチューニングは、後述の性能評価のために必要でした。
一方、SiteGuard Liteでも同様のチューニングが必要になるケースはあり得ます。その場合、WebのGUIからログを確認して、対応するルールの無効化や監視のみへの変更も、Web GUIから可能です。今回の評価では、SiteGuard Liteのチューニングはせず、デフォルト設定で使用しています。
さて、前述のように、ModSecurityとCRSの組み合わせは防御能力は高いように見えるものの、過剰検知が多いのでチューニングなしには使えないのです。過剰検知が多いのはModSecurity本体というよりはCRSの問題ですが、さりとて、CRSを使わないとなるとルールを買ってくるか、自分で作ることになります。すなわち、ModSecurityは無償とはいえ、導入には手間が掛かるということです。
一方、ModSecurityのメリットはなんでしょうか。ことカスタマイズに関しては、ModSecurityの方が優れています。ModSecurity自体はWAFを作るための開発ツールととらえることができます。たとえば、アカウントロック機能をModSecurityで実現することも可能です。しかし、ModSecurity上の複雑なルール作成は大変ですし、ModSecurity本体のバージョンアップに伴い従来動いていたルールが動かなくなる可能性もあります。そのようなModSecurityのバージョンアップの大変さについては、IPAが公開している「WAF読本」のP70～P71にも記載されています。
ということで、ルールの自由度という点ではModSecurityが優れていますが、その自由度を使いこなすのは中々大変であると考えます。
性能評価
次に、性能の評価をしてみました。サーバーマシンのスペックを以下に示します。4年前に19,800円で購入した格安サーバーです。DELL PowerEdge/SC440
CPU:Pentium Dual-Core 2GHz
メモリ 3.6Gバイトを割り当て
VMware Server上で評価
負荷テストにはApache Benchを用い、以下のコマンドラインを用いました（同時接続=50、リクエスト数=1000）。WAFに負荷をかけるために、余分なパラメータを追加しています。
ab -c 50 -n 1000 "http://example.jp/books.php?author=Shakespeare&zip=113-8663&addr=%E6%9D%B1%E4%BA%AC%E9%83%BD%E6%96%87%E4%BA%AC%E5%8C%BA%E6%9C%AC%E9%A7%92%E8%BE%BC2-28-8&tel=03-1234-5678"結果を以下に示します。
| WAFなし | SiteGuard Liteあり | ModSecurityあり | |
| 秒間リクエスト数 | 30.05 | 29.94 | 27.56 |
| 相対性能 | 100% | 99.6% | 91.7% |
ModSecurityが少し遅いものの、あまり差はありません。その理由は、アプリケーションが遅いため、相対的にWAFの遅延が見だたなくなっているからと予想されます。
そこで、先のスクリプトをチューニングすることにします。ボトルネックは、DB接続をコネクションプールしていないことと予想されるため、pg_connectをpg_pconnectに変更してabをかけました。
結果を以下に示します。高速化されたため、リクエスト数を1万にしています。
| WAFなし | SiteGuard Liteあり | ModSecurityあり | |
| 秒間リクエスト数 | 365.34 | 284.85 | 127.80 |
| 相対性能 | 100% | 78.0% | 35.0% |
スクリプトが10倍以上高速になったことにより、WAFのオーバーヘッドが目立ち始めましたが、それでも2割ちょっと遅くなるだけで済むというのは、許容できる範囲ではないかなと思いました。4年前の2万円弱のサーバーで280リクエスト/秒出せるのであれば、通常の応用には十分ですし、アプリ側が遅い場合は、1番目の例で見たようにWAFのオーバーヘッドはさらに目立たなくなるからです。ModSecurityはCRSを全部有効にしているために遅いとも考えられるため、性能という観点からもルールのチューニングが有効でしょう。ただし、Webサーバーの性能に余裕がある場合には、上記性能劣化は許容できると思います。
他のWAFとの使い分けの考察
SiteGuard Liteの購入を検討する際にもっとも比較されるのは、SaaS型のWAFサービスでしょう。単純に価格だけ見れば、SiteGuard Liteの方が安く見えます。SaaS型のWAFサービスの相場は、初期設定10万円程度、月額3万～という感じだと思いますが、初年度で元が取れそう…というのは錯覚で、SaaSの方は導入費と運用費が込みですので、単純に比較するわけにはいきません。
また、SaaS型WAFサービスだと応答の遅延を気にされるユーザが多いようですが、SiteGuard Liteのようなホスト型のWAFは、遅延の影響はもっとも受けにくい形態になります。
このように、性能上の特徴とトータルコストを勘案して、導入するWAF製品・サービスを選定することになります。
守るべきWebサーバーの数が非常に多い場合は、複数台のWebサーバーを一台のWAFで守れるならば、SiteGuard Liteではなく、ネットワーク型のSiteGuard（フル版）の方が安くなる可能性があります。
感想
私は3年半前に「三重苦を乗り越えてWAFが普及するための条件とは」という記事を書いて、以下のように結論づけました。実運用に影響を与えない程度の控えめなブラックリストをチューニングして、それを全パラメータ共通で使用する。そうすれば、手間も掛らないし、機械化されたSQLインジェクション攻撃程度であれば十分な効力がある。それでも運用に影響が出るパラメタもある(ブログや掲示板など)が、そのパラメタだけはブラックリスト検査を除外して、その代わりしっかり脆弱性検査をして対策もアプリ側でとっておけばよい。【中略】SiteGuard Liteは、3年半に出現を予告した製品が、ようやく世の中に出てきたように私には見えましたw
また、WAFの低価格化は必須だ・・・というより、ホワイトリスト機能を使わないのであれば、安いWAFで十分だ。
そんな訳で、弊社（HASHコンサルティング株式会社）は今までセキュリティ製品の販売は手がけていませんでしたが、SiteGuard Liteは初めて「この製品なら売りたい」と思いました。
まとめ
SiteGuard Liteのβ版について評価しました。SiteGuard Liteはシグネチャ検査に機能を絞った廉価版WAFですが、XSSやSQLインジェクションについては十分な防御性能と速度を持ちます。
インターネットがとても物騒な状況にある今、とくにSQLインジェクション対策としてWAFの導入は有効であり、その有力な選択肢としてSiteGuard Liteが挙げられると考えます。
[PR]
WAFの選定・導入に関する相談はHASHコンサルティング株式会社まで。
「安全なWebアプリケーションの作り方」DRMフリーのPDFによる電子版もあります。
0 件のコメント:
コメントを投稿