本篇轉載自：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";
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配合這些關鍵字可以更加快速有效地對流量進行匹配。