Suricata規則編寫——經常使用關鍵字

本篇轉載自：http://blog.csdn.net/wuyangbotianshi/article/details/44775181

1.簡介

如今的NIDS領域snort一枝獨秀，而suricata是徹底兼容snort規則的多線程IDS，不管在效率仍是性能上都超過原有的snort，這個系列主要針對suricata的規則中的一些關鍵字進行了解和學習，參考suricata的文檔，連接爲爲：https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Suricata_Rules

2.基本關鍵字

所謂的基本關鍵字是指不對檢測結果形成影響的關鍵字，也就是常說的Meta-Settings，雖然對匹配結果沒影響，可是這些關鍵字每每對於檢測結果的顯示、規則的解釋、版本等有着重要的做用。

首先來看一條用來檢測CVE-2015-0235的規則，這條規則包含了msg、sid、reference、classtype、rev、gid這些基本關鍵字，這些關鍵字對於規則的匹配並無任何影響：

2.1 msg （message）

msg關鍵字是經過這條規則檢測出問題，而後顯示在日誌中的內容，做爲這條規則最主要的解釋。msg的格式爲：

sid:number;

在上述規則的表現爲：

2.3 rev (Revision)

rev字段每每和sid字段一塊兒使用，用於標註針對這條規則的版本，每修改一次rev數值加1，格式爲：

rev:number;

在上述規則中的表現爲：

2.4 gid （Group id）

gid表示這條規則所屬的組，若是不指定默認爲1，上述規則中格式表示所屬組的id號爲3：

gid:3;

在上述規則中表現爲：

2.5 classtype

classtype用於對規則進行分類及匹配的優先級進行指定。這個定義通常是在classification.conf文件中指定，定義格式依次是短類型名，簡短描述，匹配優先級：

config classification:shortname,short description,priority

上述規則中的類型爲cuurent-event，這個類型的定義以下，而最終顯示在匹配日誌中的是中間的short description字段，而在規則中寫的是shortname字段：

config classification: current-event,Current_event, 9

在上述規則中的表現爲：

2.6 reference

reference字段代表這條規則相關信息所在url，一條規則可使用屢次reference，格式爲：

reference: url, www.info.nl

定義引用的地方則是在reference.config配置文件中，紅框中表示的就是有cve編號的引用格式：

因此只要在規則中寫上以下字段，引用的url就是http://cve.mitre.org/cgi-bin/cvename.cgi?name=2015-0235：

reference:cve,2015-0235;

2.7 priority

priority字段表示此條規則或class的匹配優先級，即便在classification.config文件中指定了每一個class的priority，仍是能夠在規則中從新制定priority字段進行覆蓋，格式以下：

priority:1;

該字段的值範圍從1-255，在suricata中數字越小表示優先級越高，也就是說若是兩條規則都能匹配，則優先匹配priority字段小的規則。

2.8 metadata

metadata字段沒有在上述規則中出現，主要緣由是當suricata遇到metadata字段便會忽略這個字段的值，還能在規則中使用是爲了兼容以前的snort規則。

3.有效字段匹配關鍵字（Payload）

所謂的有效字段關鍵字在英文中就是payload，由於不想翻譯成難懂的載荷因此姑且暫時這個麼說。說白了就是對流量數據包中的實際須要傳輸的內容進行檢測，好比你打開網頁，數據包中的payload即是網頁中看到的內容的代碼。

3.1 content

content關鍵字在suricata規則中很是重要，大部分規則都要使用這個關鍵字來匹配數據包中的內容，其格式以下：

content:".......";

content中的內容是按字節匹配的，能匹配ASCII碼從0-255的字節，可打印字符好比a-z能夠直接寫，而某些特殊符號或是不可打印的字符則須要使用十六進制來表示。以下：

|0a|和|0A| 表示空格，十六進制表示時不區分大小寫
|61| 表示字母a
|21| 表示!
b 表示字母b
B 表示字母B(直接寫a-z的字符則區分大小寫)
|61|b 表示字母ab，十六進制描述能夠和字符混着寫

若是沒有在content後面指定其餘相關的關鍵字，那麼suricata便會在整個payload字段中搜索content的內容。好比content:"abC";會在整個payload中搜索abC字符，而若是是像下面這麼寫，則表示payload字段中前三個字符爲abC，前第四個字符並非abCD，也就是第四個字符不爲D：

content:"abC"; content:!"abCD";

由於現成寫例子不是很方便也不具備表明性，所以在後面的例子展現中將會直接引用suricata文檔中的圖片和內容進行更爲清晰的描述，圖例爲，從上到下依次爲規則匹配、規則不匹配、在payload中匹配的部分，在payload中不匹配的部分：

3.2 nocase

nocase關鍵字是用來修飾content字段的，在content字段後加上nocase表示content中的內容不區分大小寫，好比下面這個例子：

content: 「abc」; nocase;

3.3 depth

depth也是修飾content的關鍵字，表示從payload開始多少個字節與content中的內容進行匹配，格式以下表示的是匹配’abc’：

depth:3;

3.4 offset

與depth不一樣的是offset是從payload開頭先偏移指定字節再對content進行匹配，下圖表示的是從開頭偏移3字節，從第四字節開始匹配字符串」def」：

offset也能夠和depth一塊兒使用，以下表示匹配第4-6三個字節是否爲」def」：

content; "def"; offset:3; depth:3;

3.5 distance

distance表示從上一個content匹配的末尾偏移指定數量字符再進行本次的content匹配。以下所示，第一次匹配」abc」以後的位置在字符’d’處，distance爲0表示不偏移，直接從’d’開始匹配’def’：

不只如此，有時不一樣的distance值結果可能相同，好比下面這個例子，不管是在」abc」以後偏移0仍是4或是中間的任意一個整數，都能匹配到後面的」def」，由於distance並無對後面的匹配長度作任何限制：

除此以外distance因爲是相對於上一次的匹配結果的位置偏移，因此他的值能夠是負數：

3.6 within

within也是一個修飾content的關鍵字，他表示從上一個content匹配位置以後的指定字節內對當前的content進行匹配，within的值不能爲0。下面這個例子比較清楚的描述了within的用法，匹配完」abc」以後位置在’d’處，從’d’開始的3字節內對」def」進行匹配，而」fgh」明顯已經超出了3字節的偏移：

一樣，within也能夠和distance一塊兒使用，以下所示匹配完」abc」，distance:1向後移動1字節從’d’開始的4個字節之內匹配’def’：

3.7 isdataat

isdataat關鍵字是用來判斷指定偏移處的字符是不是數據。下面是兩個例子，第一個表示從payload開頭偏移512個字節的地方是否爲數據，第二個則表示從上一次匹配完成以後偏移50字節的地方是否爲數據：

isdataat:512;
isdataat:50, relative;

在官方文檔中還指出在isdataat關鍵字前也可使用否認量詞定義的content，好比content:!'abc';isdataat:8, relative;，只不過目前的版本還沒有對其支持，做者表示在從此的版本中會加入。

3.8 dsize

dsize是用來檢測數據包中的payload長度是否在符合要求的範圍內，這樣能夠有效的組織一些緩衝區溢出的攻擊。格式以下：

dsize:min<>max;
dsize:[<|>]<number>;

來看兩個例子，第一個表示payload的長度在200-400字節之間，第二個表示不能超過300字節：

dsize:200<>400;
dsize:<300;

而dsize關鍵字並非全部場景下都能使用，當使用基於tcp的協議好比http的時候，常常會把超長的數據包分割成多個符合長度的數據包，這樣一來dsize只能在開啓了PAF（protocol aware flushing）以後纔有做用。

3.9 replace

replace關鍵字是用來替換匹配到的content中的字符，下面這個表示將匹配到的」abc」替換成」def」：

 

3.10 pcre

pcre關鍵字使用PCRE來匹配payload中的內容，用法通常是首先使用content匹配到指定字符串，而後根據pcre對相應的payload進行正則匹配，格式爲：

pcre:"/<regex>/opts";

詳細的應用參考： 
https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Pcre_(Perl_Compatible_Regular_Expressions)

3.11 fast_pattern

suricata對只有一個content關鍵字的規則使用多模匹配，而對於多個content的規則就對最長對複雜的一個進行多模匹配，而fast_pattern則能夠改變這個情況，若是在較短較簡單的content字段後加上fast_pattern關鍵字則會優先匹配這個content，有時這種方法能夠有效提高效率。

下面這個例子就是這種狀況，若是第二個content沒有fast_parttern關鍵字的話便會先去匹配」User-Agent:」，而這個在數據包中的出現頻率是遠遠高於」Badness」的，這樣就會致使大量的多餘時間浪費到無用的匹配上，使用了fast_pattern以後便大大提升了匹配的效率：

content:」User-Agent|3A|」;
content:」Badness」; distance:0; fast_pattern;

不只如此，fast_parttern還支持部分content多模匹配，好比下面這個例子，表示從content的第8字節開始以後的4字節進行多摸匹配以提升效率：

content: 「aaaaaaaaabc」; fast_pattern:8,4;

4.小結

本文的內容比較基礎，主要是兩部分：1.與匹配無關但與顯示匹配結果緊密相關的基礎關鍵字；2.content關鍵字以及各類修飾content的關鍵字的用法，content配合這些關鍵字能夠更加快速有效地對流量進行匹配。