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配合这些关键字能够更加快速有效地对流量进行匹配。