ルールヘッダには、パケットが何者なのか、どこから来たか、どんなものか、 といったことを定義する情報や、ルールで指定された属性のパケットが 姿を現した際に、何を行うかといった定義を行う情報が含まれます。 ルール内の最初の項目はルールアクションです。ルールアクションは、ルールの基準に 合致するパケットを検知した場合、どのような動作を行うべきかをSnortに伝えます。 Snortにはalert, log, pass, activate, dynamicの5つの有効なデフォルトアクションが 用意されています。
さらに独自のルールタイプを定義して、単一または複数の出力プラグインを それらに関連づけることもできます。また、Snortルール内のアクションと してそのルールタイプを利用できます。
次の例では、tcpdumpのみに記録するタイプを定義します。
ruletype suspicious
{
type log output
log_tcpdump: suspicious.log
}
この例では、syslogとMySQLデータベースに記録するルールタイプを定義します。
ruletype redalert
{
typealert output
alert_syslog: LOG_AUTH LOG_ALERT
output database: log, mysql, user=snort dbname=snort host=localhost
}
ルール内の次のフィールドはプロトコルです。現在、Snortが不審な挙動に対 して解析を行うプロトコルとしてはtcp, udp, icmp, ipの4つのプロトコルが あります。将来、ARP, IGRP, GRE, OSPF, RIP, IPXといったプロトコルが 追加されるでしょう。
ルールヘッダの次の部分では、指定されたルールのIPアドレスおよびポート番号の 情報に対応しています。anyキーワードは全アドレスを定義するために利用できます。 Snortはルールファイル中のIPアドレスに対するホスト名の問い合わせを行うことは できません。アドレスは、連続した数字から構成されるIPアドレス、もしくは CIDR[3]ブロック形式で指定します。CIDRブロックはルールの IPアドレスとルールに沿って検査される全パケットのネットマスクを示します。
/24のCIDRブロックマスクはClass Cネットワークを意味し、/16はClass Bネッ トワークを意味し、/32は特定のマシンのアドレスを意味します。例えば、 192.168.1.0/24というアドレスとCIDRの組み合わせは、192.168.1.1から 192.168.1.255までの連続したアドレス空間を意味しています。宛先アドレスに この指定を利用する全ルールは、範囲内のどのアドレスに対してもマッチする ことになります。CIDR表記は、わずかな文字数で大きなアドレス空間を指定 できる優れた省略表記法といえます。
図1では、送信元IPアドレスは全コンピュータに 対応し、宛先IPアドレスはClass Cネットワークの192.168.1.0に対応する ように設定されています。
IPアドレスに適用可能な演算子として、否定演算子が用意されています。 この演算子はSnortに、列記されたIPアドレス以外の全IPアドレスに対応する よう指示します。否定演算子は ! を付けて表記します。たとえば、 最初の例に簡単な修正を加えて、図4に示したように 否定演算子を使って、ローカルネットワークの外部を起点とする 全トラフィックに対してアラートを発動できます。
alert tcp !192.168.1.0/24 any -> 192.168.1.0/24 111 \
(content: "|00 01 86 a5|"; msg: "external mountd access";)
このルールでは、内部ネットワーク以外が送信元で、宛先アドレスが 内部ネットワークのTCPパケットを意味します。
さらに、IPアドレスのリストを指定することもできます。IPリストは コンマ区切りのIPアドレスとCIDRブロックを角括弧で囲んで指定します。 ただし、現在のところIPリスト内のアドレスとアドレスの間にスペースを 入れることはできません。動作するIPリストの例については、 図5をご参照ください。
alert tcp ![192.168.1.0/24,10.1.1.0/24] any -> \
[192.168.1.0/24,10.1.1.0/24] 111 (content: "|00 01 86 a5|"; \
msg: "external mountd access";)
ポート番号は全ポート指定、固定ポート指定、範囲指定、否定といった 様々な方法で指定できます。``any''は全ポート指定を意味するワイルド カード値です。固定ポート指定はportmapperの111番、telnetの23番 あるいはhttpの80番などのように単一のポート番号で表されます。 範囲指定は範囲演算子:で表されます。たとえば図??で示したように、範囲演算子を様々な意味を持つよう 数多くの方法で適用できます。
log udp any any -> 192.168.1.0/24 1:1024 log udp任意のポート番号から、宛先ポート番号の範囲が1〜1024番のトラフィック
log tcp any any -> 192.168.1.0/24 :6000任意のポート番号から、6000番以下のポートに送信されるTCPトラフィックを 記録する
log tcp any :1024 -> 192.168.1.0/24 500:1024番以下の特権ポートから、500番以上のポート番号へ送信されるTCPトラフィックを 記録する
ポート番号の否定は否定演算子!を利用して指示します。否定演算子は(無を 意味することになるanyを除き)他のルールタイプの全てに適用できます。 たとえば、いくぶんひねくれた理由でX Windowポートを除く全記録を 取りたい場合は、図7のようにしてください:
log tcp any any -> 192.168.1.0/24 !6000:6010
方向演算子``->''は、ルールが適用されるトラフィックの方向を表します。 方向演算子の左側にあるIPアドレスとポート番号はトラフィックが送られたと 考えられる送信元ホスト、方向演算子の右側にあるアドレスとポート情報は 宛先ホストを意味します。
さらに、``<>''で表記される双方向演算子もあります。この演算子は左右どちらアドレス、 ポート番号が送信元または宛先のどちらでもよいことを現します。これは、telnetや POP3セッションのような通信を記録・解析する場合に便利です。telnetセッションを 両方向から記録するために双方向演算子を使った一例を図8に 示します。
なお、``<-''演算子は存在しませんのでご注意ください。1.8.7より前のバージョンの Snortでは、方向演算子に対する適切なエラーチェック機能を実装していなかったため、 多くの人々が誤ったトークンを利用していました。ルールの読み込みの整合性を 確保するため、``<-''は存在しません。
log tcp !192.168.1.0/24 any <> 192.168.1.0/24 23
注: ActivateおよびDynamicルールは、徐々にタギングに道を譲り、廃止 される方向にあります。Snortの将来のバージョンでは、activate/dynamicルールは 改良されたタギング機能によって完全に置き換えられるでしょう。詳細については、 第2.3.32節をご参照ください。
activate/dynamicルールの組み合わせはSnortに強力な機能をもたらします。一連の パケットに対してあるルールのアクションが実行された際に、そのルールをきっかと して別のルールを呼び出すことが可能です。これは、特定のルールが呼び出された際、 その結果に基づいてSnortを動作させたい場合に非常に役立ちます。
activateルールは *必須*オプションフィールドとしてactivatesフィールドが ある点を除けば alert ルールのように動作します。dynamicルールはlogルールと 同様に機能しますが、オプションフィールドとしてactivated_byフィールドがある 点が異なります。また、dynamicルールにはもう1つの必須フィールドとしてcount フィールドが必要です。
activateルールはalertそっくりですが、特定のネットワーク上のイベントが 発生した場合にルールを追加指定できます。dynamicルールはlogルール そっくりですが、特定のactivateルールIDが存在するときに有効化される 点で異なります。
総括すれば、activate/dynamicルールは図??のようになります。
activate tcp !$HOME_NET any -> $HOME_NET 143 (flags: PA; \
content: "|E8C0FFFFFF|/bin"; activates: 1; \
msg: "IMAP buffer overflow!\";)
dynamic tcp !$HOME_NET any -> $HOME_NET 143 (activated_by: 1; count: 50;)
これらのルールはIMAPのバッファオーバーフローを検知した場合、アラートを 出力し、$HOME_NETの外部から$HOME_NET内の143番ポート宛てに入ってくる 最初の50パケットを収集するように指示します。バッファオーバーフローが仕組まれ、 (訳注:攻撃が)成功してしまった場合、同じサービスポート宛てに送信 される次の(およそ)50パケットの中に有用なデータが含まれる可能性は非常に高い ため、後々の解析のためにこれらのパケットを収集する価値が十分にあります。