DEIM Forum 2013 F5-1

ルールセットの構造化に基づく侵入検知システムの高速化

Dong xinming† 立岩 佑一郎† 片山 喜章† 高橋 直久†

†名古屋工業大学大学院情報工学研究科〒466-8555 愛知県名古屋市昭和区御器所町

E-mail: †dong@moss．elcom．nitech．ac．jp, { tateiwa,katayama,naohisa}@nitec．ac．jp

あらまし 侵入検知システムは，パケットが到着すると，すべてのルールの条件を調べる．マッチング操作によ

り，パケットがルールの条件を満たすことが分かると，警告を出すなど，そのルールで指定されたアクションを実

行する．ルール数が多くなると，マッチング操作の時間が増大して，パケット到着に追い付かないなどの問題が生

じることがある．本稿では，マッチング操作回数を減少させて上記問題を解決する高速化手法を提案し，その実現

法について述べる．提案手法は，ルール間の空間的関係に基づいて，ルールセットを構造化し，実行順序を表す順

序木（実行木と呼ぶ）を生成するルールコンパイラと，実行木を解釈・実行するインタープリターからなる．

キーワード ルールセット構造化，空間的関係，Snort，侵入検知システム高速化

1. はじめに

インターネットの不正アクセスやウィルス等によ

る被害の拡大に伴い，近年では侵入検知システム (IDS)

の重要性が増している．これら IDS は，監視対象のネ

ットワークに一定の安全対策が施されていることを前

提にして，不正アクセス，悪意を持つパケットを検出

している．しかし大規模なネットワークにおいて IDS

を実際に運用してみると，以下のような問題が生じる

場合がある．

問題１： IDS のパケット処理プロセスでは，ルール

の検査結果によらず，全てのルールを検査する．この

ため，ルールの数が増すにつれて，パケット検査動作

にかかる時間が増加する．このため，ネットワークが

高速になると，到着パケットに対して検査が間に合わ

なくなることがある．

問題２：ルールセットには，大量なルールが存在す

るので，管理者が全部のルールの意味を理解し，ルー

ル間の関係を把握するのは困難である．特に，ルール

セットを更新して，新しいルールを追加したときに，

そのルールが元からあるルールに対して与える影響を

把握するのは，困難である．

本稿では， IDS として広く使われている snort のルー

ルセットをベースにして，侵入検知システムのルール

の構成を定める．上記問題を解決するため，ルール間

の空間的関係を解析しルールセットを構造化して，ル

ール間の関係を明示するとともに，無駄な検査を取り

除くことにより高速化する，高速実行侵入検知システ

ムを提案する．

2. 準備

2.1 侵入検知システム

Snort はオープンソースのネットワーク型 IDS であ

る． Snort では，図１に示すようなルールセットを用

いる．パケットが到着すると，すべてのルールを調べ

て，パケットのヘッダとペイロードがルールの条件指

定を満たすと，そのルールで指定された，警告やログ

記録などのアクションを実行する．

図１ Snort ルールの例

Snort は，高機能であり，ルールでヘッダ及びペイロ

ードに対して様々な条件指定を記述できるようにして

いる．提案システムでは，ルール解析の第一歩として，

snort のルールについて，ヘッダフィールドに対するレ

ンジマッチングとパイロードに対する文字列マッチン

グを含む，最小限の条件指定に絞って，検討する．

提案システムのルールは，図２に示すように，条

件（ r．Cond）とアクション (r．Action)からなる．条件

は (r．Cond)からなる，そして (r．Cond)がヘッダに対す

る条件 (r．CondH)とペイロードに対する条件 (r．CondP)

からなる．r．CondH で規定するヘッダフィールドを表

１に示す．

表１ r.CondH で指定するヘッダフィールド

r. CondH は次の式で表す．

r.CondH=(a0≤k0≤b0)∧(a1≤k1≤b1)∧(a2≤k2≤b2)

∧(a3≤k3≤b3)∧(a4≤k4≤b4)∧(a5≤k5≤b5).

k0～k5は，パケットの表１に示すヘッダフィールド

の値である．

ペイロードの値に対する条件は，ひと組の（Content,

Offset, Depth）で指定される条件のみである．すなわ

ち， r.CondPは，文字列Contentおよび，ペイロード内

の文字列の位置を指定する整数値Offsetとdepthからな

る３つ組により，次のように表す．

r.CondP = (Content,Offset,depth)．

図３に，提案システムのルールセットの例を示す．

図２ 提案システムのルールの構成

図３提案システムルールセットの例

た と え ば ， 図 ３ の ル ー ル セ ッ ト で ，

$HOME_NET=123.45.67/24 のとき， r0.Action=Alert．

r0.CondH=(tcp ≤ k0 ≤ tcp) ∧ ((123.45.67.0>k1) ∨

(k1>123.45.67.255))∧ (0≤k2≤65535)∧ (123.45.67.0≤k4≤

123.45.67.255)∧(0≤k5≤65535) ，

r.CondP = (|16 03|,0,2)となる．

各ルールのアクションを実行するか否かの判断は，

Snort と同様にする．すなわち，ルール r に対して，到

着パケットのヘッダ部が r．CondH を満たし，ペイロ

ードが r．CondP を満たすと， r．Action を実行する．

上記の例では，パケットヘッダの k0～K5 の値が上記

の式を満たし，ペイロード部の最初の２バイトが，

｜16 03｜のとき，警告を発する．

2.2 用語と関数の定義

Rs ：全ルール集合

P0 ：全パケット集合

P(r)：ルールｒの条件を満たすパケットの集合

（P(r) ∈P0）

TR は空間的関係である

TR＝{equal,inside,overlap,contain,disjoint}

EI ＝ {equal,inside} OC ＝ {overlap,contain} D ＝

{disjoint}

TR(r i, r j, t)はルール ri,rj(∈Rs)間の空間的関係

TR(r i, r j)∈{equal,inside,overlap,contain,disjoint}

TR(ri,rj): ルール ri,rj（∈Rs）間の空間的関係

p∈P0 を到着パケットとすると， r∈Rs に対して，

以下の関数 match(p,r.Cond)を実行することをパケット

マッチングと呼ぶ．

match(p,r.Cond) = T (p が r.Cond を満たす場合 )

F(そうでない場合 )

ヘッダに対する条件 (r.CondH)とペイロードに対す

る条件 (r.CondP)についても，同様に以下の関数を定義

する．

matchH(p,r.CondH) = T (p のヘッダ部の値が r.CondH

を満たす場合 )

F(そうでない場合 )

matchP(p, r.CondP) = T (p のヘッダ部の値が r.CondP

を満たす場合 )

F(そうでない場合 )

関数 match()により，P(r)は，次式で定義される．

P(r) = {p∈P0 | match(p,r.Cond)=T, r∈Rs}．

TR(ri,rj)を，ファイアウォールのフィルタ間の空間的

関係 [1]と同様に，を P(ri)と P(rj)の包含関係により，

次式のように定義する．

3. 提案システム

3.1. 高速化へのアプローチ

Snort では，総てのルール r∈Rs に対して，以下の①

～②を行う．

①match(p,r．Cond)を実行する．

②match(p,r．Cond)=T のとき，r．Action を実行す

る．

ここで，match(p,r．Cond)=T（または F）のとき，必

ず match(p,r i)=T となる ri,あるいは必ず match(p,rj)=F

となる rj が存在する場合には， r を r i,r j に先行させる

と，ri,rj に対してパケットマッチングをせずに，Action

を実行すべきかを決定できる．すなわち，ルールの実

行順序を適切に制御することにより，パケットマッチ

ングの回数を減らすことが可能になる．

本稿では，この点に着目して，パケットマッチング

の回数ができるだけ少なくなるように，Rs を構造化し

た実行木を生成するルールコンパイラと，実行木を解

釈実行するインタプリターからなる snort 高速実行シ

ステムを提案する．

3．2 提案システムの構成

提案システムは，図４に示すように，プリプロセッ

サ，空間的関係解析機能，ルール分類機能，実行木生

成機能からなるルールコンパイラとインタプリターで

ある．

図４ 提案システムの構成

（１）プリプロセッサ

プリプロセッサは Snort ルールセットからルールを簡

単化し，ルールコンパイラが利用できる格式になる．

（２）空間的関係解析機能

総てのルールの組み合わせに対して，ルール間の空間

的関係 TR(ri,rj)を求める．

たとえば，図 1 に示したルールセットでは，

TR(r0,r1)=contain, TR(r0,r2)=contain,

TR(r0,r3)=contain, TR(r0,r4)=disjoint,

TR(r0,r5)=disjoint,

（３）ルール分類機能

ルール r0 とルール集合 R が与えられたとき，ルール

間の空間的関係を用いて，r∈R を以下のルール集合に

分類する．

RTT(R,r0) = {r∈R |(∀p∈P 0) match(p,r0．Cond)=T ⇒

match(p,r．Cond)=T}

RTF(R,r0) = {r∈R |(∀p∈P 0) match(p,r0．Cond)=T ⇒

match(p,r．Cond)=F}

RTX(R,r0) = R - RTT(R,r) - RTF(R,r)

RFT(R,r0) = {r∈R |(∀p∈P 0) match(p,r0．Cond)=F ⇒

match(p,r．Cond)=T}

RFF(R,r0) = {r∈R |(∀p∈P 0) match(p,r0．Cond)=F ⇒

match(p,r．Cond)=F}

RFX(R,r0) = R – RFT(R,r0) – R

FF(R,r0)

たとえば，図 1 に示したルールセットでは， RTT

(R,r0)={}，RTF(R,r0)={r4,r5}，RTX(R,r0)={r1,r2,r3}，

RFT(R,r0)={}，RFF(R,r0)={r1,r2,r3}，RFX(R,r0)={r4,r5}

となる．

（４）実行木生成機能

ル ール r0 とルール集合 R が与えられたとき，

RTT(R,r0)， RTX(R,r0) ，RFT(R,r0)， RFX(R,r0) を用い

て，ルールをノード，ルール間の実行順序関係をリン

クとし，r0 を根とする順序木（実行木と呼び，ET(r0)

と表す）を生成する．ノードは，以下の属性と 0 から

２本のリンクを持つ．

r．uncond 無条件実行フラグ(T またはＦ)

r．succT match(p,r．Cond)=T の場合の後続ルール

r．succF match(p,r．Cond)=F の場合の後続ルール

r．uncond=T は，無条件に r．Action を実行するこ

とを表し，r．uncond=F は，match(p,r．Cond)=T のと

きに r．Action を実行することを表す． r．succT=r．

succF=NULL は，後続ルールが無いことを表す．r1=r．

succT≠NULL，r2=r．succF≠NULL のとき，ノード r は，

後続ノード r1 と r2 へのリンクを持つ．

たとえば，図３に示したルールセットでは，実行木

は図５のようになる．

図５ ルール実行木の例

（５）インタプリター

実行木のインタプリターは，実行木 ET(r0)が与えら

れると，以下の手順に従って，ルールの実行を制御す

る．

Step1 r=r0

Step2 match(p,r．Cond)を実行する．

Step3-1 match(p,r．Cond)=T のとき，Step4 に行く．

Step3-2 match(p,r． Cond)=F のとき， r=r． succF

Step5 に行く．

Step4 r．Action を行う．r=r．succT

Step5 r=NULL のとき，終了．

Step6 r．uncond=T のとき Step4 に行く．そうでな

いとき Step2 に行く．

ルールコンパイラの各機能の実現法については，以

下の各章で述べる．

4. 空間的関係解析機能の実現法

4.1. ルール間の空間的関係

ルールｒの条件を満たすパケットの集合 P(r) （∈P0）

は，次式で表される．

P(r) = {p∈P0 | match(p,r．Cond)=T, r∈Rs}

= {p ∈ P0 | (match(p,r ． CondH)=T) ∧ (match(p,

r.CondP)=T), r∈Rs}

このため，ルール r i,r j（∈Rs）間の空間的関係 TR(ri,rj)

は ， ヘ ッ ダ の 値 に 基 づ く ル ー ル 間 の 空 間 的 関 係

TRH(r i,r j)とペイロードの値に基づくルール間の空間的

関係 TRＰ (r i,r j)により，以下のように求められる．

以下の各節に，TRH(r i,r j)と TRＰ (r i,r j)の計算法につ

いて述べる．

4.2. TRH

(r i,rj)の計算法

まず、プリプロセッサを利用し、Snort ルールセット

からルールを簡単化し，ルールコンパイラが利用でき

る格式になる．

ルール r において，ヘッダの値に対する条件（ r．

CondH）は，ヘッダの m 個のキーフィールドの値

Ki(i=0,1,… ,m-1)に対する条件式で表される．ここでは，

次式のように，各キーフィールドの値の満たすべき範

囲により，条件を指定するものとする．

matchH(p,r.CondH)= (a0≤K0≤b0)∧(a1≤K1≤b1)∧……∧

(am-1≤Km-1≤bm-1)．

まず，第ｖキーフィールドの値 Kｖに基づくルール

r i と r j の空間的関係 TRHｖ (r i,r j)を求める．TRHｖ (r i,r j)は ,

r i の条件 (a i, v≤Kv≤b i,v)と rj の条件 (a j,v≤Kv≤b j, v)で指定さ

れる Kv が満たすべき値域の包含関係により，以下のよ

うになる．

第 0 キーフィールドから第 v-2 キーフィールドの v-1

個のキーフィールドの値に基づくルール r i と r j の空間

的関係を TRHv-2(r i,r j)としたとき，v 個のキーフィール

ドの値に基づく空間的関係 TRHv-1(r i,r j)は，次式で表さ

れる．

(１ ) v=1 の場合

TRH0(r i,r j) = TRH0(r i,r j)

(２ ) v≧2 の場合

4.3. TRP の計算法

4.3.1. ルールの分割

本稿では，ペイロードの値に対する条件のうち，ひ

と組の（Content, Offset, Depth）で指定される条件のみ

を考える．その他の条件については，ルール間の空間

的関係の計算では無視する．このため，たとえば，ル

ールｒが，その他の条件を含む場合に，本来，TR(r0, r)

≠overlap であるにも関わらず TR(r0,r)＝overlap となる

ことがある．これは，ｒが RTX(R,r0)と RFT(R,r0)の両方

の要素となり，実行木が大きくなる原因となる．

以下では， r.CondP = (Content,Offset,depth)と表す．

今，r.CondP =(content,offset,depth)で，content の長さ

が n とする．このとき，ルール r i を，以下の条件部を

持つ s（= depth-offset-n）個のルール r i0, r i1,…, r is-1 に

分割する．このように分割によりできたルールの集合

を Ri={r i0,r i1,…,r is-1}と表し，r ik∊Ri を r i の子ルール，r i

を r ik の親ルールと呼ぶ．

r i,0 .CondP = (content,offset+1,offset+1+n),

r i,1.CondP = (content,offset+2,offset+2+n),

……

r i, s-1.CondP=(content,offset+(depth-offset-n), depth)

ルール r i と子ルール r ik に対して，以下の式が成立す

る．

matchP(p, r i.CondP)⇒matchP(p, r ik.CondP),∀r ik∊Ri

同様に，r j を分割してできるルール集合 R j={r j0,r j1…

… r jt -1}について，以下の式が成立する．

matchP(p, r j.CondP)⇒matchP(p, rjk.CondP),∀r jk∊Rj

4.3.2. 子ルール間の空間的関係の計算

まず文字列の関係を定義する．ここで，長さｘの文

字列 S1 と長さｙの文字列 S2 を考える．このとき，文

字列 S1 が，長さ i，m， (x-i-m)の文字列 S11,S12,13 から

なるとし， S2 は長さ j,m,(y-j-m)の文字列 S21,S22,S23 か

らなるとする．文字列 S1 と S2 に対して，以下の６つ

の関数を定義する．

Scon(S1,S2)=T ((S1=S22)∧(m=x))

F (その他）

Sins(S1,S2)=T: S2=S12∧m=y=True のとき

F (その他のとき）

Seql(S1,S2)=T: S1=S2∧m=x=y=True のとき

F (その他のとき）

Prefix(S1,S2)=T: S11=S23∧i=(y-m-j)>0=True のとき

F (その他のとき）

Suffix(S1,S2)=T: S13=S21∧j=(x-m-i)>0=True のとき

F (その他のとき）

missmatch(S1,S2)=T: Scon(S1,S2) ∧ Sins(S1,S2) ∧

Seql(S1,S2) ∧Prefix(S1,S2)∧Suffix(S1,S2)=Fails のとき

F (その他のとき）

r i． content の長さを lri， r j． content の長さを lrj と

す る ． 子 ル ー ル 同 士 間 に 重 な る 部 分 の 長 さ

d=Max(r i, s.depth , r j, t.depth)-Min(r i, s.offset, r j, t .offset)，子

ルール間の関係 TRP(r i,k r j, s)は，以下の式で表される．

4.3.3. 子ルールと親ルールの空間的関係の計算

子ルールと親ルールの関係を判断するため，まず子

ルール間関係を計算する．総ての子ルールにマッチす

るパケットの和集合は，親ルールにマッチするパケッ

ト集合になるので，子ルールにマッチするパケットの

集合と親ルールにマッチするパケットの集合の関係を

判断することができる．子ルールと親ルールの関係を

判断することが可能になる．

子ルール間の関係をまとめでルール間の関係が判断で

きる．

4.3.4. TRP(r i,rj)の空間的関係の計算

これよりペイロードの値に対する空間的関係を求

められる．

5. ルール分類機能の実現法

ルール分類機能はルール r0 に対して，総てのルール

と r0 の関係によって分類する．以下の式に沿って，ル

ールを分類する．

たとえば，図３ に示し たルールセット では， RTT

(R,r0)={}， RTF(R,r0)={r4,r5}， RTX(R,r0)={r1,r2,r3}，

RFT(R,r0)={}，RFF(R,r0)={r1,r2,r3}，RFX(R,r0)={r4,r5}

となる．

6. 実行木生成機能の実現法

6.1. 優先度の計算

ルール r(∈Rs)に対して，次式で表され集合 RNO のル

ール数をルール r の優先度といい，r．Priority で表す．

RNO= {r i∈Rs | TR(r,r i)≠overlap, ri≠r}

関数 maxPriorityRule(R)は，ルール集合 R⊆Rs が与

えられたとき，∀r i∈R に対して r．Priority≧r i．Priority

なる任意の r∈R を返す．

6.2. 実行木生成機能

以下の 2 つの関数 makeSeq(R)と makeTree(T)により，

実行木を生成する．

（１）makeSeq(R)

要素数 m のルール集合 R が与えられたとき，R のす

べてのルールを任意の順 r0,r1,… ,r i,… ,r j,… rm-1 に並べて，

先頭と最後尾のルール対 (r0,rm-1)を返す．m=0 のとき

(NULL,NULL)を返す．

このとき，makeSeq(R)はルール r i(i=0,1,… ,m-1)の属

性を以下のように設定する．

r i．uncond=T

r i． succT= NULL (m=0 または i=m-1 の場合 )

= r i+1 （その他の場合）

（２）makeTree(R)

makeTree(R)は，ルール集合 R⊆R s が与えられたとき，

R のすべてのルールからなる実行順序木を再帰的に構

成し，その根となるルール r を返す．

makeTree(R)の手順を以下に示す．

Step1 R=NULL のとき， r=NULL． Step6 に行く．

Step2 r = maxPriorityRule(R)． r．uncond=F．

Step3 R’= R-{r}． classify(R,r)により，RTT(R’ ,r)，

RTX(R’ ,r)，RFT(R’ ,r)，RFX(R’ ,r)を求める．

Step4-1 r2=makeTree(RTX(R’,r))．

Step4-2 (r1s,r1e)=makeSeq(RTT(R’,r))．

Step4-3 r1s=NULL のとき，r．succT=r2． そうでないと

き， r． succT=r1s, r1e． succT=r2．

Step5-1 r4=makeTree(RFX(R’,r))

Step5-2 (r3s,r3e)=makeSeq(RFT(R’,r))

Step5-3 r3s=NULL のとき，r．succF=r4． そうでないと

き， r． succF=r3s, r3e． succF=r4．

Step6 r を返し，終了．

7. プロトタイプシステム

提案システムのルールコンパイラと実行木インタ

ープリタのプロトタイプシステムを JAVA を用いて実

現した．実験では，snort ルールセットから６つのルー

ルセットを選択し，ルール構造を提案システムに合わ

せて簡単化して用いた．プロトタイプシステムにより，

各ルールセットをコンパイルし，実行木を作成した結

果を表６．１に示す．

表６．１実験結果 ル ー ル

セット

対 象 ル ー

ルの数

実 行 木 ノ

ード数

パケットは

マ ッ チ ン グ

の 必 要 な 平

均ノード数

実 行 木

最 大 深

さ

実 行 木 最

少深さ

実 行 木

平 均 深

さ

Net bi o

s

162 232 18. 6 35 10 22. 4

M ysq l 26 75 11. 6 17 4 12. 1

musi c 82

471 44. 8 81 3 45. 1

Dos 51

143 26. 7 50 2 26. 8

Rpc 100

100 10. 5 27 8 14. 2

Sca da 61

153 13. 6 26 7 15. 2

表６．１より，パケットマッチングに必要なノード

数は，全ルール数の 10～50％程度であることが分かる．

すなわち，snort と同様に全ルールに対してパケットマ

ッチングを行う場合に比べて，パケットマッチングの

回数が大幅に減少することが分かる．

1280

1923

1922

T F

T

1950

2015

1746

1732

575

576

577

580

581

582

584

586

587

1279

2017

579

578

585

583

1277

1959

1961

588

589

2092

574

1949

598

2014

1747

1733

1262

1263

1264

1267

1268

1269

1271

1273

2016

593

1265

1272

1270

591

1960

1962

1274

1275

F

T

1925

1951

2018

2019

2020

2022

1924

F

T

1926

1952

2019

2021

2023

2027

F

2025

T

2029

2031

2028

F

T

2026

2030

2031

1907

F

2094

T

1910

1908

F

T

2095

1909

1911

F

1951

T

1912

F

1958

T

1913

F

1915

T

1914

F

1916

T

599

F

1281

F

2088

F

2089

F

1962

F

2024

F

1964

F

1965

F

図６ルール実行順序木の例

8. おわりに

本稿では，ルール間の空間的関係に基づいて，ルー

ルセットを構造化し，実行順序を表す順序木（実行木

と呼ぶ）を生成するルールコンパイラと，実行木を解

釈・実行するインタープリターにより，侵入検知シス

テムを高速化する手法を提案した．提案手法では，

snort のルールの一部の条件だけを対象に，ルール間の

空間的関係を計算している．その他の条件に対する空

間的関係の計算は，今後の課題である．今後は以下４

つの方向に研究を展開していく．

（１）解析機能の向上

今回除外した Snort のルールのオプションについて，

解析可能な範囲を拡大する．

（２）インタプリタ機能の向上

ルール間の空間的な関係が不明なルールであって

も，解釈実行できるように，インタプリタ機能を拡張

する．これにより，実用的なルールを利用できるよう

にする．

（３）ルールセットの可視化

ルールセットの解析により求めた，ルール間の関係

を可視化して，ルールセットの管理を容易にする．

（４）高速性の評価

実ネットワークのトラヒックを用いて，提案方式に

よるパケットマッチングの減少による高速化について，

評価する．

謝辞

本研究の一部は，JSPS 科研費 23500084 の助成を受

けたものである．

参 考 文 献

[1] Subana Thanasegaran, Yuichiro Tateiwa, Yoshiaki

Katayama, Naohisa Takahashi Design and

Imple-mentation of Conict Detection System for

Time-Based Firewall Policies， JNIT，2011．

[2] 高橋直久 空間的解釈に基づくファイアウォール解析システムの研究， 電気通信普及財団研究調査報告書 No．24 P365-372

[3] 林經正 , 横山幹 , 高原厚 , 岩橋政 Snort を用い

た侵入防止システムの構築と侵入検知処理高速

化の検討， IPSJ，2010

[4] UML：http://www． snort．org/