ソリューション

マクニカネットワークスが取り扱う製品で、皆様の課題を解決します

マクニカラボ便り アーキテクチャの違いが2製品の明暗を分ける! 徹底検証でわかった“UTM”性能レポート

マクニカラボ便り

「マクニカラボ便り」は、ちょっとやってみたい検証や、このテクノロジー、こう使ってみたらどうなる?など、マクニカネットワークスのエンジニアが気になった製品や技術について、ディープな検証や評価を行い、面白かったら皆さんにも公開しようという、ちょっと気まぐれなコーナーです。

第三回のチャレンジとして取り上げるのは、ファイアウォール機能を中心に、アンチウイルスやURLフィルタリング、IPS/IDPなど各種セキュリティ機能をゲートウェイにて提供するアプライアンス「UTM(統合脅威管理)」。性能が疑問視された一昔前のUTMが現在はどこまで進化したのか、具体的にその性能を検証します。

【今回のチャレンジ】

一昔前までは「アンチウイルス機能を有効にするとスループットが激落ちで使い物にならないでしょ。」とか「結局、UTM機能は全部OFFにしてファイアウォールとして使っていますよ。(泣)」といった声が多かったUTM。そのような過去から比べると、製品性能が随分向上し、UTMを使うことによる導入・管理コストの低減に注目が集まるようになっています。そこでマーケットを代表する2つの製品に対して、スループット測定、遅延測定、そしてアンチウイルスの検知率測定といった3種類のテストを実施してみました。

テスト対象機器

今回、テスト対象としたUTM製品は以下の2製品です。SonicWALL社のNSA-E5500と、もう一方はマーケットを代表する某UTMメーカーの製品で、ほぼ同価格帯の売れ筋モデルを選択しました。なお、今回のテストはいわゆる「出来レース」的にシナリオを設定したのではなく、極めて客観点的な立場から全くの同一条件においてテストしたことを最初に申し上げておきます。

SonicWALL NSA E5500
標準価格 : \2,700,000(UTMライセンス込)
カタログスペック : 850Mbps (UTM機能有効時)

SonicWALL NSA E5500

マーケットを代表する某UTM製品
標準価格 : SonicWALL NSA E5500とほぼ同価格帯
カタログスペック : 160Mbps (UTM機能有効時)

マーケットを代表する某UTM製品

テスト内容

上記2製品に対し、以下の3種類のテストを行いました。なお全てのテストにおいて、IPS(侵入防御)機能、アンチウイルス機能、そしてアンチスパイウェア機能を有効化しています。

テストその1 - スループット測定テスト

Spirent社の負荷生成装置であるAvalanche2900を使って、機器の限界性能としてスループット(http)を測定しました。

テストその2 - 遅延測定テスト

パケットが機器の入口のインターフェースに到達してから、出口のインターフェースを出るまでの間に、機器内部を通過するのにかかった時間をミリ秒のオーダで測定しました。

テストその3 - ウイルス検知率測定テスト

弊社で設置しているハニーポットで最近収集した770個のウイルス検体を用い、ウイルスの検知率を測定しました。

テスト構成

テストその1 - スループット測定テスト

構成は図1のように、UTM側で1Gbpsの物理ポートを4つ使用し、片道で最大2Gbps(上り下りの合計だと4Gbps)まで測定可能なテストベッドを構築しました。

図1.スループット測定テスト

図1.スループット測定テスト

テストその2 - 遅延測定テスト

構成は図2のように、UTMの両端をL2スイッチで挟み、両端のポートをミラーリングすることで、UTMに入るパケットと出るパケットの両方を1台のPCでパケットキャプチャ(tcpdump)できるようにしました。両端でキャプチャされたパケットのタイムスタンプを引き算することで、UTM内部を通過するのにかかった時間(ミリ秒)を計測しました。

図2.遅延測定テストの構成

図2.遅延測定テストの構成

テストその3 - ウイルス検知率測定テスト

構成は図3のように、Webサーバ上に770個のウイルス検体を置き、wgetを使ってUTM経由でウイルス検体の取得を試みました。

図3.ウイルス検知率測定テストの構成

図3.ウイルス検知率測定テストの構成

テスト結果

テストその1 - スループット測定テスト

まずは、パケットサイズを小さくすることでスループットがどのくらい低下するか見てみました。パケットサイズを小さくするために、Avalancheの設定で、徐々にMTU値を小さくしました。結果は図4の通りです。なお、httpで取得するコンテンツは、5kバイトのASCIIコンテンツを用いました。

図4.スループット測定テスト結果(MTU値変更によるスループットへの影響 図4.スループット測定テスト結果(MTU値変更によるスループットへの影響)

図4.スループット測定テスト結果
(MTU値変更によるスループットへの影響)

図をご覧になってわかる通り、イーサネットの最大MTU値(1500)の場合、SonicWALLのスループットは1.2Gbps以上とカタログスペックの850Mbpsを大きく上回りました。一方、某UTM製品の場合、最大でも60Mbpsを下回り、カタログスペックの160Mbpsには遠く及ばない結果となりました。

次に、httpで取得するコンテンツサイズを変更することによるスループットの変化を調べました。結果は図5の通りです。なお、MTU値は1500バイトとし、コンテンツはASCIIコンテンツを用いました。

図5.スループット測定テスト結果(コンテンツサイズ変更によるスループットへの影響) 図5.スループット測定テスト結果(コンテンツサイズ変更によるスループットへの影響)

図5.スループット測定テスト結果
(コンテンツサイズ変更によるスループットへの影響)

図をご覧になってわかる通り、コンテンツサイズを大きくするとともにスループットも上がっています。SonicWALLの場合、コンテンツサイズが50kバイト以上においては、下りのスループットが2Gbpsのラインスピードを超えたため計測不可能でした。某UTM製品の場合、先ほどの5kバイトのコンテンツを用いたシナリオでは、カタログスペックの160Mbpsに届きませんでしたが、コンテンツサイズを30kバイトまで大きくすることで、ようやくカタログスペックのスループットを出すことができました。

テストその2 - 遅延測定テスト

まず、遅延を測定した箇所の解説をします。遅延を測定したポイントは図6に示す通り、コンテンツの最終バイトを含んだパケットがUTMを通過するのにかかった時間です。某UTM製品の場合、図6の左図に示すように、プロキシとして動作するため、クライアントとのコネクションを確立し、HTTPリクエストを受け取った後にサーバとのコネクション確立を開始します。そしてサーバからのコンテンツ受信時、全てのコンテンツを受信し終わり、UTM内部でファイルとして再構成して検査してからクライアント側へ返し始めます。よって、コンテンツサイズが大きくなるに従い、遅延も大きくなると予想されます。一方、SonicWALL製品の場合、プロキシとしてではなく、図6の右図に示すように、受け取ったパケットを、パケット単位で検査して転送しているため、コンテンツ全てを受け取って再構成する必要はないため、遅延が小さいと予想できます。

図6.遅延測定テスト検定

図6.遅延測定テスト検定

このような想定のもと、テストした結果が図7の通りです。テストは同じシナリオを3回実行し、その平均値(図中の赤字)をテスト結果として採用しました。また、コンテンツサイズを変化させることによる遅延の変化を調べました。図をご覧になってわかる通り、某UTM製品の場合、ASCIIコンテンツのサイズが5kバイトから200kバイトへと大きくなるに従い、遅延も約1ミリ秒から42ミリ秒へと増大しています。一方、SonicWALLの場合、ASCIIコンテンツのサイズに関係なく、遅延は全て1ミリ秒以内に収まっています。3MBのバイナリコンテンツでテストしたときは、もっと差が表れ、某UTM製品では236ミリ秒(1秒の約4分の1)まで遅延が増大した一方、SonicWALL製品の場合は2.6ミリ秒とごく小さい遅延に収まりました。

図7.遅延測定テスト結果 図7.遅延測定テスト結果

図7.遅延測定テスト結果

テストその3 - ウイルス検知率測定テスト

テスト結果は、図8の通りとなりました。SonicWALL製品が770個のウイルスのうち695個を検知し、某UTM製品の検知率68%を大きく上回り90%以上の検知率という結果でした。なお、某UTM製品ではデフォルトでは14,401個のシグネチャ(2009/11/11時点)が適用されていますが、パフォーマンスを犠牲にすることによって適用シグネチャ数を約220,000個に増やすことができます。そこで、同様のテストを行ったところ検知率が78%まで改善しましたが、SonicWALLの検知率には及びませんでした。ちなみに、同じウイルス検体を使ってパソコンにインストールさているSymantecAntivirusでの検知率を調べたところ、98.8%でした。

図7.遅延測定テスト結果

図8.ウイルス検知率測定テスト結果

考察

今回、2製品について性能テストを行ったわけですが、両製品のアーキテクチャの違いが顕著にスループットと遅延に表れたと思います。
某UTM製品の場合、プロキシとして動作している仕様上、UTM自身がソケットを開いて、クライアントやサーバと通信しなければならないので、どうしてもCPUやメモリに対するオーバヘッドが大きくなります。一方、SonicWALLのようなアーキテクチャは、従来のファイアウォールのように、セッションテーブルによる管理だけで、自身でソケットを開く必要がないため、オーバヘッドが小さくて済む分スループットを稼げます。

またアンチウイルス機能の検査の方法に関しても、両製品で大きな違いがあることが今回のテストで分かりました。それは、ファイル単位で検査するか、パケット単位で検査するかの違いです。某UTM製品の場合、ダウンロードするコンテンツ(ファイル)が3MBあれば、それを全てUTMへダウンロードし終わって、ファイルとして完成しないとウイルス検査ができません。よって、コンテンツサイズが大きくなればなるほど遅延も大幅に大きくなります。ちなみに、今回テストした某UTM製品には、ウイルス検査可能なコンテンツの最大サイズは10MBという制限があり、それ以上のサイズのコンテンツはウイルス検査せずに通してしまう仕様であることが分かりました。一方、SonicWALLの場合、パケット単位でウイルスチェックするため、遅延も小さく、コンテンツのサイズにも制限はありません。

一般に、「スループットが良い」、「遅延が少ない」と速さばかりを謳っているセキュリティ製品は、肝心のセキュリティ機能(どれだけ多くの脅威をブロックできるか)が二の次になっているケースが多く見受けられますが、今回のテスト結果では違いました。スループット、及び遅延測定で勝ち星をあげたSonicWALL製品の方が、高いウイルス検知率を示しました。ちなみに、米国のNETWORK WORLDが各社UTM製品のウイルス検知率をテストした結果が下記参考URLに出ていますが、弊社のテスト結果と近いものでした。

今回は、スループット、遅延、ウイルス検知率という3点に絞って評価を行いましたが、本2製品をトータルで比較検討するには、他にも、IPS機能の攻撃防御率、ログやレポート出力といった運用面などの観点からの評価もまた必要であると思います。またUTMに関して執筆する機会があれば、その辺りのテストも行い、結果を共有したいと考えています。

いつか見た景色 from Staff's Albums