Ying-Dar Lin, Chih-Wei Jan, Po-Ching Lin and Yuan-CHeng Lai
Designing an Integrated Architecture for Network Content Security Gateways
IEEE Computer, Vol.39, No.11, pp.66--72, 2006
http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/mags/co/&toc=comp/mags/co/2006/11/rytoc.xml
■概要
複数のセキュリティシステム(ソフトウェア)を単一のゲートウェイ(計算機)にインストールするとプロセス間ならびにカーネル/ユーザ空間とのやりとりでオーバーヘッドが発生する．よってソフトウェア構成を改良し、緊密に統合することでオーバーヘッドを減らし、スループットの向上を試みた．
ということで，セキュリティソフトウェアを改良/構成変更し、それらを緊密に統合してみた結果，スループットがあがったよという話．Open Sourceツール群を用いたUTM(Unified Threat Management: 統合脅威管理)の一実装例とその性能評価と思えば良いかな?
■問題
- 計算機の処理能力の向上に伴い，複数の機能を一つのゲートウェイ上にて処理させる事が可能になりつつある．が，その一方で，メーカーはそれをしたがらない．
- 特定機能に特化したデバイスや機器にするのは信頼性やスケーラビリティの点で優れるが，似たような機器を多数管理する事は膨大なコストになる．
-この領域の研究者の興味は，性能向上である．
-その一方で機能の統合を試みる研究者が少ない
-Astaro Security GatewayやFortinetのFortiGate series, L7 Networkのfirewallなどは複数の機能を統合した製品を提供しているが，内部はブラックボックスであり，中の仕組みを知る方法はない．
- よって本研究では，著名な5つのオープンソースのコンテンツセキュリティシステムの統合によるスループットの向上を試みた．
導入したOpen sourceツールは以下の通りである
1. Snort (http://www.snort.org/)
2. ClamAV (http://www.clamav.net/)
3. SpamAssassin (http://spamassassin.apache.org/)
4. amavisd (http://www.ijs.si/software/amavisd)
5. DansGuardian (http://dansguardian.org)
計算機にこれらのシステムを単にインストールしただけの状態(loosely integrated)と，本論文で提案する統合型システム(tightly integrated)とで性能評価を行うとともに，その結果からどこにオーバーヘッドがあるかを特定する
■ Loosely integrated Architecture
オーバヘッドが多い
- Snortはlibpcap経由でデータを受け取るのに対し，E-mailとWebはTCP Stackからネットワークデータを取得している．またこのどちらもがカーネルとユーザ空間でやりとりする必要があるため，そこでオーバーヘッドが生じる
- メールのコンテンツ確認は，以下のオーバーヘッドがある
1. 4回のカーネル/ユーザ空間のやりとり
2. 2回のプロセス間通信
3. 1回のプロセス起動
4. 1回のRAM Diskへのアクセス
- またこの他にamavisdとDansGuardianはプロセスforkする．
■ Tightly integrated Architecture
これらの処理を統合し，プロセス間通信やカーネル/ユーザ空間のやりとりを最小限にした．またprocess forkを防ぐため，threadとIO multiplexingを使用した．さらにSnortは共有ライブラリとし，他のパッケージからその機能を利用できるようにした．
- 共有ライブラリとしてのSnort
共有ライブラリとし，他のアプリケーションからその機能を使用できるようにした．これを利用し，Snortの機能をPacket-Captureプログラムに組み込んで，特定のアプリ/サービスに特化していない攻撃(DoS攻撃など)の検知および防御に対処可能にするような拡張も可能である．
-amavisdのスタンドアロン化
SMTPの処理を行なわせるため，amavisdをスタンドアロン化し，またスケーラビリティ向上のためmultithread化した．select()コールのかわりにthread化した理由は，並列度が下がらないようにするためである．
またClamAVはdaemonモードで動作させることでウィルスパターンの読み込み時間を削減し，SpamAssassinはメモリに常駐させた．またamavisdはSnortの機能を利用しており，不正侵入の検知を可能にしている．
-Webfd
処理速度をあげるために，DansGuardianのかわりにWebfdを利用した．またDansGuardianをライブラリ化し，その機能をWebfdから利用可能にした．またcheckmeという関数がWebfdにはあり，ある統計処理によって得られる値が既定の閾値を超えると通信をブロックする仕組みになっている．
Webfdにはキャッシュ機能がない．シンクライアント等はDiskがないのでその点で問題は発生しないが，キャッシュはある方がよい．今後の課題である．
■ Packet flows
結果としてHTTP,SMTPともにカーネル/ユーザ間のやりとりは1回．
プロセス間通信はSMTPのみで1回になり，オーバヘッドは削減できた．
■ Integration Cost
- 将来的にOpen Sourceのシステムが更新されても，本システムが適応できるようにすべきである．が，OSS側のAPIに大幅な変更がなければ，それは問題なく適用できるはずである．
■ Benchmark Results
■ External benchmarks
HTTPのベンチマークは，WebBench(http://www.veritest.com/bencmarks/webbench/default.asp)を使用し，そのスループットを測定した．
SMTPのベンチマークは，Postal(http://www.coker.com.au/postal)というツールをもとに改良を加えた．これをmail clientとして動作するようにし，かつ添付ファイルに対応できるようにして測定に使用した．メールのサイズは一行の文字列と添付ファイルで合計1MBとした．またその中にはspamやvirusも混ぜ込んだ．
◎ HTTP test results
Webフィルタリングの性能は，コンテンツのサイズに比例した．
Webfdにはキャッシュ機能がないので，公平性確保のためSquidのキャッシュ機能もOffにした．
結果としては，webfdのスループットはsquidの倍になった．
Snortによるコンテンツチェック分の性能劣化も，webfdの方がDansGuardianの場合より少なかった．
◎ SMTP test results
amavisdの導入でスループットは極端に劣化した．
antispamやantivirusの処理はスループットを劣化させるが，amavisdによる劣化を考えれば，対した影響ではない．
tightly integratedの方がスループットは良かった．
■ Internal benchmarks
- HTTPの各内部処理の評価:
gettimeofday()関数やgprofで処理時間を測定
Chariotでトラフィックを生成し，fragrouteでフラグメント化させSnortにパケットの再構成を強制した
- SMTPの各内部処理の評価:
amavisdに実装されているログ機能を利用した．
◎ HTTP test results
1. HTTP requestにおける評価
BannedRegExpURL関数が処理時間の60%以上を占めている
BannedURLとBannedSiteで残りのうちの24%の処理時間を使用
データベースはBannedRegExpURLの方が，他の2つの関数のデータベースよりもはるかに小さいのだが，こういう結果になった．
スループットをより求めるのであれば，BannedRegExpURLは機能をOffにすべき．
2. HTTP responseにおける評価
Content確認処理が90%以上の処理時間を占める
これは不正侵入の分野で知られている結果と同じ結果となった．
3. SnortのHTTP processにおける評価
String matchingの処理が一番時間がかかる．
TCP reassemblyは予想よりも処理時間は小さく，検知においてはボトルネックにならない
◎ SMTP test results
新しいアーキテクチャーでは，ウィルススキャンをメモリ上で動作させているので，ウィルスパターンの読み込み時間が削減され，またamavisdがメールサーバのかわりにproxyとして動作しているので，メールサーバが行っている処理の分が削減されているはずなのだが，amavisdがメールの受信と転送をすることで，その処理時間がメールサーバで実行するのと比較して，それぞれ21%と62%も増加してしまった．これらは新しいボトルネックである．
またメールは，事後処理の前に一旦保存されなければならず，またその後にdecoding, decompression そしてウィルススキャンとスパムスキャンの処理が行われるが，それらの処理はすべてRAM Diskにアクセスして行われる事になるため，結果としてSMTPのスループットはHTTPよりも大幅に低くなるという結果になった．
■ 結論
-プロセス間やカーネル/ユーザ間のオーバーヘッドを減らすため，複数のソフトウェアコンポーネントを統合した
-Webフィルタでは83%，ウィルスとスパムフィルタはおよそ倍のスループット改善が実現できた
-新しいセキュリティゲートウェイにおけるボトルネックは，Webフィルタではstring matchであり，メール処理ではRAM Diskへのアクセスであることがわかった．それらはそれぞれ，処理時間の48%と62%を占めている．
- このアーキテクチャは他のプロトコルのProxyにも拡張可能
この論文の参考文献には，コンテンツセキュリティや不正侵入検知の性能向上に関する論文が挙げられているので，興味がある方は見るべきであろう．
Posted by z at December 22, 2006 08:49 PM