ルールオプションはSnort不正侵入検知エンジンの心臓部で、力強さと柔軟性に 使いやすさを兼ね備えています。すべてのSnortルールオプションはセミコロン ``;''文字で区切られます。また、ルールオプションはコロン``:''でキーワードと 引数を区切ります。
msgルールオプションはログ取得およびアラートエンジンに、パケットダンプと 共に出力すべき、またはアラートに対して出力すべきメッセージを伝えます。 このルールオプションはシンプルな文字列で、区切り文字を表示する際 (たとえば、セミコロン``;'')にエスケープ文字としてを 利用します。さもなれば、Snortのルール構文解析系を混乱させてしまいます。
msg: "<message text>";
logtoオプションはこのルールをきっかけとしてSnortが記録したパケットを 特別なログファイルに記録するよう設定します。このオプションは特に、NMAP によるアクティビティ、HTTP CGIスキャンなどから得られるデータを結合する 場合に便利です。ただし、Snortがバイナリ形式のログ取得モードで動作して いる場合には、本オプションは機能しませんのでご注意ください。
logto:"filename";
このルールオプションは、検査の対象となる特定のTTL(time-to-live)値を 検査するために利用します。実施される検査では完全に一致した場合に のみ合格となります。このオプションキーワードは本来traceroute試行の 検知を目的としたものでした。
ttl:<number>;
tosキーワードを使うことで、IPヘッダ中のTOSフィールドの特定の値を チェックすることができます。実施される検査では完全に一致した場合に のみ合格となります。
tos: <number>;
このオプションキーワードは、IPヘッダフラグメントIDフィールドが一致して いるかどうかを検査するために利用します。一部のハッキングツール(と その他のプログラム)はこのフィールドを様々な目的のために利用します。 たとえば、31337という値は一部のハッカーの間で非常に人気があります。 この値や他のハッカー番号と呼ばれる番号を検査するためにシンプルな ルールを適切に設定することで、ハッカーに対抗することができます。
id: <number>;
パケット内にIPオプションが存在する場合、本オプションはソースルーティングのような ある特定のオプションを検索します。このオプションに対して有効な引数は次の通りです。
最もよく監視対象となるIPオプションは、ストリクトソースルーティングおよび ルーズソースルーティングです。これらは広い範囲で使われているインターネット アプリケーションでは利用されていません。このオプションでは、ルール毎に 単一のオプションのみを指定できます。
ipopts: option;
このルールはIPヘッダ内のフラグメントおよび予約ビットを検査します。 Reserved Bit(RB)、More Fragments(MF)ビット、Don't Fragment(DF)ビットの 3ビットをチェックすることができます。これらのビットは様々な組み合わせ でチェックすることができます。特定のビットを表すために、次の値を利用 できます。すなわち * R - Reserved Bit * D - DF ビット *M - MFビットです。
また、指定されたビットに対する論理的な一致条件を定義するために修飾子を 利用できます。すなわち、 * ― ALLフラグ。指定されたビットに値が設定されており、なおかつ他に値が設定されている場合 ** ― ANYフラグ。指定されたビットのどれかに値が設定されている場合 * ― NOTフラグ。指定されたビットに値が設定されていない場合 です。
fragbits: <bitvalues>;
alert tcp !$HOME_NET any -> $HOME_NET any (fragbits: R+; \
msg: "Rerserved bit set!";)
dsizeオプションはパケットペイロードサイズを検査するために利用します。 このオプションにはどんな値でも指定でき、値の範囲や限界を示すために 大なり記号``>''、小なり記号``<''も指定できます。たとえば、特定の サービスがある大きさのバッファを持っていることが分かっている場合、 バッファオーバーフローの企みを監視するためにこのオプションを 利用できます。このオプションはペイロード内容のチェックよりも 遥かに高速にバッファオーバーフローを検査できるという利点も 備えています。
また、値の範囲をチェックするためにこのオプションを利用できます。 たとえば、dsize:400<>500はすべてのパケットのペイロード部分から 400〜500バイトを返します。
これらのチェックはストリーム再構築済みパケットに対しては 常に偽の値を返します。
dsize: [<>]<number>[<><number>];注: >と<演算子はオプションです。
contentキーワードは、Snortの最も重要な機能のうちの1つです。このキーワードを 利用すれば、ユーザはパケットペイロード内の特定の内容を検索するルールを設定し、 そのデータに基づく対応策を呼び出すことができます。contentオプションの パターンマッチが行われる場合、常にBoyer-Moore法によるパターンマッチ関数が 呼び出され、パケットの内容に対して(かなり計算量の多い)検査が実施されます。 引数であるデータ文字列に合致するデータが、パケットのペイロード内のいかなる 部分にでも含まれる場合は、この検査が合格となり、残りのルールオプションの 検査が実行されます。この検査は大文字と小文字を区別する点に 留意してください。
contentキーワードに対するオプションデータはいくぶんか複雑です。この キーワードではテキストとバイナリデータが混在できます。バイナリデータは 一般にパイプ(|)文字で囲まれ、バイトコードで表記されます。バイトコードは バイナリデータを16進数で表現する方法で、複雑なバイナリデータを記述できる するための優れた省略表記法といえます。 図11はSnortルールにテキストとバイナリデータが 混在している例を示したものです。
なお、1つのルール内に複数のcontentルールを指定できますので、誤検出 (false positives; 偽陽性)がより少ないルールを書けます。
contentルールにおいては、下記の文字をエスケープする必要がありますので ご注意ください。
: ; \ "ルールの先頭に!を設定すると、指定された内容を含まないパケットに 対してアラートが出力されます。これは特定のパターンに一致しないパケットに 対してアラートを出力するルールを記述する際に便利です。
content: [!] "<content string>";
alert tcp any any -> 192.168.1.0/24 143 (content:"|90C8 C0FF FFFF|/bin/sh"; \
msg:"IMAP buffer overflow!";)
alert tcp any any -> 192.168.1.0/24 21 (content: !"GET"; depth: 3; nocase; \
dsize: >100; msg: "Long Non-Get FTP command!";)
offsetルールオプションは、contentオプションキーワードを利用するルールの 修飾子として利用します。本キーワードは、パターンマッチ機能の検索開始 位置をパケットのペイロードの先頭から変更します。この機能はペイロードの 最初の4バイト内にコンテンツ検索の対象となる文字列が決して検知されない 場合にCGIスキャン検知ルールのような事象に対して非常に効果的です(訳注: CGIスキャンのペイロードの先頭にはHEAD / HTTP/1.0..のような文字列が 必ず存在すると考えられるため、これらを検索対象としない設定です)。 ただし、offset値を厳格に設定にすると、攻撃を見逃す恐れがありますので ご注意ください。また、このルールオプションキーワードはcontentルール オプションと併用する必要があります。content、offset、depth 検索 ルールを組み合わせた例については、図??をご参照ください。
offset: <number>;
depthはcontentルールオプションのもう1つの修飾子です。この修飾子は contentパターンマッチ機能において、検索対象の先頭から検索を行う 終端(search depth)を定義する。この修飾子は、与えられた一連の コンテンツに対し、想定される検索対象を越える非効率的な検索を抑制する 際に役立ちます(つまり、Web向きのパケット内のcgi-bin/phfを検索する 場合に、最初の20バイト以降のペイロードを検索するために時間を 無駄にする必要はおそらくなくなります!)。content, offset, depth 検索ルールを組み合わせた例については、図??をご参照ください。
depth: <number>;
alert tcp any any -> 192.168.1.0/24 80 (content: "cgi-bin/phf"; \
offset: 3; depth: 22; msg: "CGI-PHF access";)
nocaseオプションはcontentルール内の大文字と小文字を区別しないようにするため 利用します。このオプションはルールにおいて単体で指定され、パケットの ペイロードと比較されるASCII文字は大文字・小文字関係なく扱われます。
nocase;
alert tcp any any -> 192.168.1.0/24 21 (content:"USER root"; \
nocase; msg: "FTP root user access attempt";)
このルールはTCPフラグが一致するかについて検査します。現在、Snortでは 9種類のフラグ変数に対応しています。
指定されたフラグに対するマッチング定義を指定できる論理演算子も用意されています:
ECNのように以前の予約ビット1番、2番と共に送信されるSYNパケットといった セッション開始パケットに対応できるルールを書くには、オプションマスクを 指定する必要があります(訳注: ECNはRFC3168で定義されたネットワークの混雑 状況を明示的に相手に伝える仕組みで、ECNのCWRフラグとECEフラグは以前、 予約フラグだった領域を利用している。以前のSnortにはECNフラグの処理に 問題があった。詳細については[6]を参照のこと)。 フラグ値S,12を検知するルールの場合、予約ビットの値に関係なく SYNパケットを検知できます。
flags: <flag values>[,mask value];
alert any any -> 192.168.1.0/24 any (flags: SF,12; msg: "Possible SYN FIN scan";)
このルールオプションはTCPシーケンス番号を照会するものです。基本的に、 このオプションはパケットが静的なシーケンス番号セットを含んでいるか どうかを検知しますので、滅多に利用されることはありません。 このオプションは万全を期して盛り込まれたものです。
seq: <number>;
ackルールオプションキーワードはTCPヘッダの応答確認(acknowledge)フィールドを 照会するものです。このルールはNMAP[1, 2] TCP pingを 検知するという実用的な目的を担っています。NMAP TCP pingはネットワークホストが 動作しているかを確認するために、このフィールドの値をゼロにしたTCP ACKフラグ付き パケットを送信します。この活動を検知するためのルールを図16に 示します。
ack: <number>;
alert any any -> 192.168.1.0/24 any (flags: A; ack: 0; msg: "NMAP TCP ping";)
このルールオプションはTCPウィンドウサイズを照会します。このオプションは 静的なウィンドウサイズをチェックします。この機能により、バックドアの類が ハードコーディングされたウィンドウサイズの値を利用する場合に、TCPウィンドウ サイズオプションを利用して特定の値をチェックできます。
window:[!]<number>;
このルールはICMPタイプフィールドの値を検査します。このルールでは、 フィールド内の数値が設定されます。設定できる値の一覧については、 Snortに含まれるdecode.hファイル、またはICMPのリファレンスを参照 してください。 なお、注目すべき点としては、DoS攻撃やフラッド攻撃で時折利用される 無効なICMPタイプの値を検知できるよう、範囲外の値を設定できることが 挙げられます。
itype: <number>;
icodeルールオプションキーワードはitypeルールとほぼ同様、ルールに数値を 設定するだけで、Snortは指定されたICMPコードの値を含むトラフィックを すべて検知します。また、不審なトラフィックを検知するために、範囲外の 値も設定できます。
icode: <number>;
sessionキーワードはバージョン1.3.1.1で追加された機能で、TCPセッションから ユーザのデータを抽出するために利用します。ユーザがtelnet、rlogin、ftp、 あるいはWebセッションにおいてユーザが何を入力しているかを確認する場合に 非常に便利です。sessionルールのオプションとして、printableとallの2つの キーワードが引数として利用できます。printableキーワードはユーザが通常 閲覧したり、入力できるデータのみを出力します。allキーワードはprintable キーワードで出力できない文字列を16進数に変換します。この機能を利用すると Snortの性能低下を招く恐れがあるため、高負荷環境での利用は避けた方が よいでしょう。後処理用バイナリ(tcpdump形式)のログファイルの方がお勧めです。 telnetセッション記録ルールのよい例として、図17を ご参照ください。
session: [printable|all];
log tcp any any <> 192.168.1.0/24 23 (session: printable;)
icmp_idオプションは、ICMP ECHOパケットの特定のICMP IDの値を 検査します。一部の[84]隠密チャネル(covert channel)を用いる プログラムは静的なICMPフィールドを通信時に利用するため、このルールが 役立ちます。この特殊なプラグインは、[85]Max Version氏による stacheldraht(訳注:DDoS攻撃ツール)検知ルールを実現するために開発されましたが、 様々な潜在的攻撃を検知する際においても間違いなく役立つでしょう。
icmp_id: <number>;
icmp_seqオプションは、ICMP ECHOパケットの特定のICMPシーケンス番号の値を 検査します。一部の[84]隠密チャネル(covert channel)を用いる プログラムは静的なICMPフィールドを通信時に利用するため、このルールが 役立ちます。この特殊なプラグインは、[85]Max Version氏による stacheldraht(訳注:DDoS攻撃ツール)検知ルールを実現するために開発されましたが、 様々な潜在的攻撃を検知する際においても間違いなく役立つでしょう。 (すでにお気付きかもしれませんが、このフィールドに関する情報は icmp_idの説明とほぼ同じものです。)
icmp_seq: <number>;
このオプションはRPCリクエストを調査し、アプリケーション、プロシージャ、 プログラムバージョンを自動的にデコードし、これらの3つの変数が一致すれば 合格したことを示します。オプションの形式はアプリケーション、 プロシージャ、バージョンです。プロシージャおよびバージョン番号については ワイルドカード*が指定できます。
rpc: <数値, [数値|*], [数値|*]>;
alert tcp any any -> 192.168.1.0/24 111 (rpc: 100000,*,3;\
msg:"RPC getport (TCP)";)
alert udp any any -> 192.168.1.0/24 111 (rpc: 100000,*,3;\
msg:"RPC getport (UDP)";)
alert udp any any -> 192.168.1.0/24 111 (rpc: 100083,*,*; msg:"RPC ttdb";)
alert udp any any -> 192.168.1.0/24 111 (rpc: 100232,10,*;
msg:"RPC sadmin";)
respキーワードは、Snortのルールにマッチしたトラフィックに対して フレキシブル・レスポンス(FlexResp - 柔軟性に富んだ応答)を実行します。 FlexRespコードによって、Snortは目障りなコネクションを動的に切断 できます。このモジュールに対しては以下の引数が有効です:
rst_snd - 送信側ソケットにTCP-RSTパケットを送信します
rst_rcv - 受信側ソケットにTCP-RSTパケットを送信します
rst_all - 両方向にTCP-RSTパケットを送信します
icmp_net - 送信側にICMP_NET_UNREACHを送信します
icmp_host - 送信側にICMP_HOST_UNREACHを送信します
icmp_port - 送信側にICMP_PORT_UNREACHを送信します
icmp_all - 送信側に上記のICMPパケットをすべて送信します
対象ホストに複数のレスポンスを組み合わせて送信することができます。 複数の引数はコンマで区切ってください。
resp: <resp_modifier[, resp_modifier...];
フレキシブル・レスポンスの使用の際には、細心の注意を払ってください。 次のようなルールを定義しただけで、Snortは簡単に無限ループ状態に陥って しまいます。
alert tcp any any -> 192.168.1.1/24 any (msg: "aiee!"; resp: rst_all;)通常のネットワークトラフィックを妨害することも簡単にできてしまいます。
alert tcp any any -> 192.168.1.0/24 1524 (flags: S; \ resp: rst_all; msg: "Root shell backdoor attempt";) alert udp any any -> 192.168.1.0/24 31 (resp: icmp_port,icmp_host; \ msg: "Hacker's Paradise access attempt";)
content-listキーワードを利用すると、複数のcontentの文字列をわずか1つの contentオプションで指定できるようになります。図20に 示した通り、検索対象となるパターンはcontent-listファイルに一行づつ記述する 必要があります。このように記述しない場合には、contentの文字列すべてが 標準のcontentディレクティブに対する引数として扱われてしまうことになります。 このオプションはreactキーワードの基準となります。
# adult sites "porn" "porn" "adults" "hard core" "www.pornsite.com"
content-list: <file_name>;
この機能を利用することにより、ネットワークトラフィックを生成する ループ状態に容易に陥ってしまう危険性があることを警告しておきます。
フレックス・レスポンス(FlexResp)を基にしたreactキーワードは、 Snortルールに合致したトラフィックに対する柔軟なリアクションを 実現します。基本的なリアクションは、New York Times、Slashdot、 あるいはもっと重要な問題―つまりNapsterやポルノサイトのような ユーザがアクセスしようとしているサイトをブロックすることです。
FlexRespコードによって、Snortは目障りなコネクションを動的に切断、 もしくはブラウザに対して視覚的な通知を送信できます(warn修飾子は 近日中に提供されます)。この通知には独自の注釈を含めることが できます。このオプションで利用できる引数(基本的な修飾子)は 下記の通りです。
複数の引数を追加する場合にはコンマで区切ります。reactキーワードは オプションリストの最後に記述してください。
react: <react_basic_modifier[, react_additional_modifier]>;
alert tcp any any <> 192.168.1.0/24 80 (content: "bad.htm"; \
msg: "Not for children!"; react: block, msg;)
referenceキーワードを利用すれば、ルールに外部の攻撃識別システムへの リファレンスを含めることができます。現在、このプラグインは固有のURLの他に、 特定のシステムもいくつかサポートしています。この機能は出力プラグインに 対し、生成されるアラートに関するより詳細な情報を提供するために利用します。
また、sidに基づいてアラートの説明に索引を付加するシステムについては、 http://www.snort.org/snort-db/も 必ず確認してください(第2.3.27参照)。
| システム | URL プリフィックス |
| Bugtraq | http://www.securityfocus.com/bid/ |
| CVE | http://cve.mitre.org/cgi-bin/cvename.cgi?name= |
| Arachnids | http://www.whitehats.com/info/IDS |
| McAfee | http://vil.nai.com/vil/dispVirus.asp?virus_k= |
| url | http:// |
reference: <id system>,<id>; [reference: <id system>,<id>;]
alert tcp any any -> any 7070 (msg: "IDS411/dos-realaudio"; \ flags: AP; content: "|fff4 fffd 06|"; reference: arachNIDS,IDS411;) alert tcp any any -> any 21 (msg: "IDS287/ftp-wuftp260-venglin-linux"; \ flags: AP; content: "|31c031db 31c9b046 cd80 31c031db|"; \ reference: arachNIDS,IDS287; reference: bugtraq,1387; \ reference: cve,CAN-2000-1574; )
sidキーワードはSnortのルールを識別するために利用します。この情報に 基づいて、出力プラグインが容易にルールを識別できるようになります。 使用例については図23をご参照ください。 sidの範囲は次にように割り当てられます。
sid-msg.mapというファイルに、Snortのルールidとmsgタグのマッピングが 含まれています。これは出力後の処理においてidからアラートメッセージを 割り当てる際に利用します。
sid: <snort rules id>;
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 \
(msg:"WEB-IIS File permission canonicalization"; \
uricontent:"/scripts/../.."; \
flags: A+; nocase; sid:983; rev:1;)
revキーワードはルールのリビジョンを識別するために利用します。 リビジョンとSnortのルールIDを併用することで、シグネチャと解説を 最新の情報に更新できます。利用例については、図23を ご参照ください。
rev: <revision integer>
classtypeキーワードは、攻撃の種類別に優先度に基づいてアラートを 分類します。ユーザは各タイプのルール分類ごとに優先度を指定できます。 また、分類されたルールにはデフォルト優先度セットが設定されます。
classtype: <class name>;ルール分類はclassification.configファイルで定義されます。 この設定ファイルは以下の構文を利用します。
config classification: <class name>,<class description>,<default priority>Snortに含まれる標準の分類を表2に示します。 標準の分類は現在、3つのデフォルトの優先度に従って順序付けられています。 デフォルトルールセットにおいて、優先度1は最も深刻度の高い優先度レベルで、 優先度4はもっとも低いレベルです。
| Classtype | Description |
| attempted-admin | Attempted Administrator Privilege Gain |
| attempted-user | Attempted User Privilege Gain |
| shellcode-detect | Executable code was detected |
| successful-admin | Successful Administrator Privilege Gain |
| successful-user | Successful User Privilege Gain |
| trojan-activity | A Network Trojan was detected |
| unsuccessful-user | Unsuccessful User Privilege Gain |
| web-application-attack | Web Application Attack |
| Classtype | Description |
| attempted-dos | Attempted Denial of Service |
| attempted-recon | Attempted Information Leak |
| bad-unknown | Potentially Bad Traffic |
| denial-of-service | Detection of a Denial of Service Attack |
| misc-attack | Misc Attack |
| non-standard-protocol | Detection of a non-standard protocol or event |
| rpc-portmap-decode | Decode of an RPC Query |
| successful-dos | Denial of Service |
| successful-recon-largescale | Large Scale Information Leak |
| successful-recon-limited | Information Leak |
| suspicious-filename-detect | A suspicious filename was detected |
| suspicious-login | An attempted login using a suspicious username was detected |
| system-call-detect | A system call was detected |
| unusual-client-port-connection | A client was using an unusual port |
| web-application-activity | access to a potentially vulnerable web application |
| Classification | Description |
| icmp-event | Generic ICMP event |
| misc-activity | Misc activity |
| network-scan | Detection of a Network Scan |
| not-suspicious | Not Suspicious Traffic |
| protocol-command-decode | Generic Protocol Command Decode |
| string-detect | A suspicious string was detected |
| unknown | Unknown Traffic |
alert tcp any any -> any 80 (msg:"EXPLOIT ntpdx overflow"; \
dsize: >128; classtype:attempted-admin; priority:10 );
alert tcp any any -> any 25 (msg:"SMTP expn root"; flags:A+; \
content:"expn root"; nocase; classtype:attempted-recon;)
priorityタグは影響度のレベルをルールに割り当てます。classtypeルールは、 priorityルールで上書きできるデフォルトの優先度を割り当てます。分類ルールと 併用した場合の例については、図24をご参照ください。 単独の利用例については、図25をご参照ください。
priority: <priority integer>;
alert TCP any any -> any 80 (msg: "WEB-MISC phf attempt"; flags:A+; \
content: "/cgi-bin/phf"; priority:10;)
uricontentルールを利用すれば、リクエストのuri部分のみを検索対象と することができます。この機能によって、サーバのデータファイルからの誤検知を 発生させることなく、攻撃のリクエスト部分のみを検索できるようになります。 この機能に対するパラメータについては、第2.3.9節のcontentルール オプションをご参照ください。
このオプションは、第2.4.1節に指定されたHTTPデコーダと 連動して機能します。
uricontent:[!]<content string>;
tagキーワードを利用すれば、ルールが呼び出した単一のパケットだけではなく、 それ以外のログも取れるようになります。いったんルールが呼び出せれると、 送信元ホストや宛先ホストに関係している付加的トラフィックに``タグ''が 付加されます。タグが付けられたトラフィックは応答コードや攻撃後の トラフィックの解析を可能にするために記録されます。 ``タグ''付きアラートは通常のアラートと同様、同じ出力プラグインに送信 されますが、これらの特別なアラートを適切に処理するのは出力プラグインの 責任となります。ただし、現在のところ、第2.5.7節のデータ ベース出力プラグインは``タグ''付きアラートを適切に処理できません。 利用例については、図26をご参照ください。
tag: <type>, <count>, <metric>, [direction]
alert tcp !$HOME_NET any -> $HOME_NET 143 (flags: A+; \
content: "|e8 c0ff ffff|/bin/sh"; tag: host, 300, packets, src; \
msg: "IMAP Buffer overflow, tagging!";)
alert tcp !$HOME_NET any -> $HOME_NET 23 (flags: S; \
tag: session, 10, seconds; msg: "incoming telnet session";)
ip_protoキーワードを利用すれば、IPプロトコルヘッダに対する照会が 可能になります。名前を用いて指定できるプロトコルの一覧については、 /etc/protocolsをご参照ください。ルール内でIPプロトコルを指定する 方法にご注意ください。
ip_proto:[!] <name or number>;
alert ip !$HOME_NET any -> $HOME_NET any \
(msg: "IGMP traffic detected"; ip_proto: igmp;)
sameipキーワードを利用すれば、送信元IPが宛先IPと同じかどうかを 検査できます。
sameip;
alert ip $HOME_NET any -> $HOME_NET any (msg: "SRC IP == DST IP"; sameip;)
このモジュールは現在開発中のため、実運用環境のルールセットで 利用すべきではありません。したがって、これを利用してアラートが 設定された場合、エラー状態が引き起されてしまいます。
flowルールオプションはTCPストリーム再構築機能と組み合わせて利用します (第2.4.5節参照)。このオプションを利用すれば、特定の トラフィックフローの方向に限定してルールを適用できるようになります。
この結、ルールをクライアントまたはサーバにのみ適用できるようになります。また、 Webページを閲覧する$HOME_NET内のクライアントに関連したパケットを、 $HOME_NET内で稼働しているサーバのものと区別できるようになります。
establishedキーワードは、確立されたTCP接続を示すために 多くの場所で利用されてきたflags: A+を置き換えます。
flow:[to_client|to_server|from_client| \ from_server|established|stateless|no_stream|only_stream]}
alert tcp !$HOME_NET any -> $HOME_NET 21 (flow: from_client; \
content: "CWD incoming"; nocase; \
msg: "cd incoming detected"; )
alert tcp !$HOME_NET 0 -> $HOME_NET 0 \
(msg: "Port 0 TCP traffic"; flow: stateless;)
fragoffsetキーワードを利用すれば、10進数の値とIPフラグメントオフセット フィールドを比較できます。IPセッションの最初のフラグメントを全て捕捉 するためには、fragoffsetを0に設定した状態で、More fragmentsオプションを 検索し、fragbitsキーワードを利用する。
fragoffset:[<|>]<number>
alert ip any any -> any any \
(msg: "First Fragment"; fragbits: M; fragoffset: 0;)
rawbytesキーワードを利用すれば、デコードされたtelnetデータを正規化されていない データとして処理できます。この機能により、プリプロセッサと独立してtelnetの ネゴシエーションコードを検索できるようになります。このキーワードは、 前第2.3.9節のcontentオプションの修飾子として動作します。
rawbytes;
alert tcp any any -> any any (msg: "Telnet NOP"; content: "|FF F1|"; rawbytes;)
distanceキーワードは、Content(第2.3.9節参照)を利用した パターンマッチの間隔が少なくともNバイト空いていることを確認する content修飾子です。このキーワードはwithin(第2.3.40節)ルール オプションと共に利用します。
図32でリストアップされたルールは、ÄBCDE.{1}EFGH& uml;の正規表現に相当します。
distance: <byte count>;
alert tcp any any -> any any (content: "2 Patterns"; \
content: "ABCDE"; content: "EFGH"; distance: 1;)
withinキーワードは、Content(第2.3.9節参照)を利用した コンテンツマッチ間の間隔が多くともNバイト以下に維持されていることを 確認するcontent修飾子です。このキーワードはdistance(第2.3.39節) ルールオプションと共に利用します。
図33にリストアップされたルールは、ABCDEのマッチから 10バイト以内に検索対象を制限します。
within: <byte count>;
alert tcp any any -> any any (content: "2 Patterns"; \
content: "ABCDE"; content: "EFGH"; within: 10;)
byteフィールドを特定の値に対して(演算子を使って)検査します。2進数の値を 検査したり、代表的なバイトストリングを2進数の値に変換して、それらを検査 したりすることができます。
byte_test: <bytes_to_convert>, <operator>, <value>, <offset> \
[, [relative],[big],[little],[string],[hex],[dec],[oct]]
alert udp $EXTERNAL_NET any -> $HOME_NET any \
(msg:"AMD procedure 7 plog overflow "; \
content: "|00 04 93 F3|"; \
content: "|00 00 00 07|"; distance: 4; within: 4; \
byte_test: 4,>, 1000, 20, relative;)
alert tcp $EXTERNAL_NET any -> $HOME_NET any \
(msg:"AMD procedure 7 plog overflow "; \
content: "|00 04 93 F3|"; \
content: "|00 00 00 07|"; distance: 4; within: 4; \
byte_test: 4, >,1000, 20, relative;)
alert udp any any -> any 1234 \
(byte_test: 4, =, 1234, 0, string, dec; \
msg: "got 1234!";)
alert udp any any -> any 1235 \
(byte_test: 3, =, 123, 0, string, dec; \
msg: "got 123!";)
alert udp any any -> any 1236 \
(byte_test: 2, =, 12, 0, string, dec; \
msg: "got 12!";)
alert udp any any -> any 1237 \
(byte_test: 10, =, 1234567890, 0, string, dec; \
msg: "got 1234567890!";)
alert udp any any -> any 1238 \
(byte_test: 8, =, 0xdeadbeef, 0, string, hex; \
msg: "got DEADBEEF!";)
Byte_Jumpオプションは一定のバイト数を取り込んで、それらを数値表現に 変換し、(さらなるパターンマッチング/バイト検査を行えるようにするため) doe_ptrを指定された数値分、ジャンプさせるために利用します。 これにより、ネットワークデータ内で検知された数値を考慮した相対的な パターンマッチが可能になります。
byte_jump: <bytes_to_convert>, <offset> \
[, [relative],[big],[little],[string],[hex],[dec],[oct],[align]]
alert udp any any -> any 32770:34000 (content: "|00 01 86 B8|"; \
content: "|00 00 00 01|"; distance: 4; within: 4; \
byte_jump: 4, 12, relative, align; \
byte_test: 4, >, 900, 20, relative; \
msg: "statd format string buffer overflow";)