PC-UN*Xのキャプチャリング性能

**PC-UN*Xのキャプチャリング性能**

１．はじめに

侵入検知システムをPCベースで構築することはそれほど珍しくありません．実際にSnort http://www.snort.org のようにフリーの侵入検知ソフトウェアとLinuxなどのPC-UN*Xを組み合わせることにより，簡単に実現可能ですし，これらによって侵入検知システムの構築と運用を請け負うベンダーさえも存在します．また，商用の侵入検知システムもPCベースのものが珍しくありません．

さて，果たしてそれらPCベースによるネットワーク監視システムは，確実に総てのネットワークトラヒックを監視しているのでしょうか？

この疑問は職場のネットワーク上で侵入検知システムとして Snort(http://www.snort.org) を走らせたときに持ちました．ネットワークレンジに対してポートスキャンをかけられたのですが，Snortのアラートはすべてのコンピュータを示していません．ことのきSnortのキャプチャ性能を疑い，今回の性能測定となりました．

実はSnortの性能も測定したのですが，とある事情から今回はtcpdumpの測定結果を紹介します．

さらに今回は RedHatLinux7.3 と OpenBSD3.2 の2種類のOSにおける違いも測定してみることにしました．

２．システムの構成

擬似トラヒックの発生と，トラヒック発生状況の観測に，Finiar社製(旧Shomiti社)のSS HybridAnalyzerを利用しました．この機器はトラヒックの発生，および計測部分にASICを利用することで，Fast Ethernetフルラインレートに対応する性能を持ちます．

テストベッドとなるPCは以下のような市販パーツによって組み上げられています．

CPU	Pentium4 1.7GHz
MotherBoard	ASUS P4T i82850 FSB400MHz
Memory	256MByte
HDD	IBM DPTA-353750
NIC	Intel Ether Pro100(i82557) x 2

またOSにはRedHat Linux 7.3とOpenBSD 3.2を利用しました．

今回の実験ネットワークは，Finiarが持つ２つの計測用ポートＡＢのうちポートＡをトラヒック発生専用，ポートＢを観測用として，100BASE-TXのリピータハブを挟んで接続しました．(下図参照)

これにより，実験ネットワーク上で発生するトラヒックのロスを，ポートＢに到達するトラヒックにより知ることができます．

そしてテストベットをリピータハブに接続し，FiniarのポートＡで発生させたトラヒックをキャプチャします．

３．計測方法

擬似トラヒックとしてTCP SNMPでIP Source/Destination Addressはそれぞれ0.0.0.0を設定された擬似TCPパケットを使用します．この擬似TCPパケットを，フレーム長64，128，512，1024，1518バイト長で，50%から100%の間でネットワーク帯域使用率で発生させ，テストベット上でのキャプチャリング数を計測します．

４．計測結果

計測結果は非常に興味深い物でした．RedHatLinuxでのテストベットでは，フレーム長64バイトで，60%の帯域(約59.8～60.5Mbps)時に性能が極端に落ち込みます．この時50万フレームを発生させて，取得できたのはわずかに250程度です．OpenBSDでも80%の帯域時に同様の現象がみられます．

またハードウェアが原因であることを疑い，全く別なハードウェア構成(VIA C3866MHz+RTL8139D)でも計測しましたが，帯域の違いはあれ同様の極端な性能低下が観測されました．

* 本現象については現在調査中です．

この性能低下時は，キーボードからの入力も受け付けず，まるでOSがフリーズしているかのような振る舞いを見せます．これは不思議なことにtcpdumpを走らせてなくても，このトラヒックを発生させることで発生します．おそらくドライバとカーネル周辺に問題があるのでしょう．

それから念のため実ネットワーク上でフレーム長の使用状態を計測したのが下図です．ネットワークに依存するでしょうが，少なくとも理化学研究所のネットワークにおいては全体の10%ほどが64バイト長のフレームによって構成されているようです．

このネットワークのトラヒックは通常50～80Mbpsあたりを推移しており，時々90Mbpsを越えることもあります．強引な計算ですが，平均トラヒックを70Mbpsとすれば，10%の7Mbpsは64バイト長のフレームであると言えるでしょう．

５．まとめ

10Mbps前後での測定は未だ行っておりませんが，この程度であれば通常はトラヒックの取りこぼしを心配する必要は無いのかもしれません．しかし前述した集中的なポートスキャンのように短いフレームが大量に発生する状況での取りこぼしは避けられないことを覚悟してください．

次回は，さまざまな長さのフレームから構成されたトラヒックを発生させて，取りこぼしの測定をしてみることにしましょう．

続く．．．．．たぶん