规则机制的引入
--------------
从初始的设计来看，Bro
NIDS的实现方法是类似于NFR，实现一个脚本解析引擎，向用户提供完整编程接口，用户通过编写脚本来分析网络流量，这样的设计可以使用户有极大的灵活性，理论上可以实现足够精细的分析和处理。但是脚本的编写、调试、维护却是一个相当麻烦的过程，需要耗费相当多的时间，而且对于大多数基于单包的攻击检测并不需要编写复杂的脚本，因此Bro
0.8以后的版本中引入了规则引擎，支持通过指定报文的特征来检测网络事件。报文特征定义存放在规则文件中，Bro在启动时可以根据配置加载规则文件（如何打开规则支持及加载规则文件见《Bro
NIDS的安装与配置》），对符合特征定义的报文告警。
规则文本的格式
--------------
Bro的规则定义采用简单的纯文本形式，单个规则的定义格式如下：
signature
id
{
规则选项列表
}
“signature”字串为规则定义的关键字，起始于每个规则定义块的头部，id为本规则定义的唯一标记字串，花括号内为规则相关的各个选项的具体定义，各个选项定义之间是且的关系。每个选项定义一般占据一行，每行的格式根据选项类型的不同有如下两种：
a.
选项名 操作符 参数值列表
b. 选项名 参数值列表
c. 选项名
模式
规则的操作符和选项
------------------
Bro支持的操作符有：
"="  大于等于
""   大于
"="  
等同于"=="
"=="  等于
"!="  不等于
对于不同的选项名对应有不同的参数值集，比如对应"ip-proto"选项名，其允许的参数值为"ip"、"tcp"、"udp"、"icmp"，有的选项名允许指定以逗号分隔的多个参数值，之间是或的关系。
模式是用于匹配的目标串，一般来说可以是正则表达式。
目前Bro支持的选项分为两类：条件与动作。条件又分为四类：头部、内容、依赖关系、上下文。
头部条件：用于通过检查报文的协议类型、端口、地址等从报文头部中可以抽取出来的信息来过滤。目前预定义的很常用的选项名主要有：
ip-proto
含义：IP包内封装的协议类型
格式：ip-proto
操作符 参数值列表
允许的参数值：ip, tcp, udp,
icmp
ip-options
含义：IP包头选项
格式：ip-options 参数值列表
允许的参数值：lsrr,
lsrre, rr, ssrr
src-ip
含义：IP包的源地址
格式：src-ip 操作符
参数值列表
允许的参数值：IP地址，可以带子网标记
dst-ip
含义：IP包的目的地址
格式：dst-ip 操作符
参数值列表
允许的参数值：IP地址，可以带子网标记
src-port
含义：TCP或UDP包的源端口
格式：src-port
操作符 参数值列表
允许的参数值：端口数值
dst-port
含义：TCP或UDP包的目的端口
格式：dst-port 操作符
参数值列表
允许的参数值：端口数值
对于IP头中其它头字段可以使用header选项名，指定数据在header中的偏移和长度来进行匹配：
header
proto[偏移:长度] 操作符 参数值
因此 header ip[16:4] == 1.2.3.4/16, 5.6.7.8/24
等价于
dst-ip == 1.2.3.4/16,
5.6.7.8/24
内容条件：用于通过检查报文的净载来过滤。目前支持的选项名有：
payload
含义：TCP或UDP包的净载
格式：payload
模式
允许的参数值：正则表达式
payload-size
含义：TCP或UDP包的净载长度
格式：payload-size
操作符 参数值
允许的参数值：正整数的数字
http
含义：HTTP协议报文的净载
格式：http
模式
允许的参数值：正则表达式
ftp
含义：FTP协议报文的净载
格式：ftp
模式
允许的参数值：正则表达式
finger
含义：FINGER协议报文的净载
格式：finger
模式
允许的参数值：正则表达式
依赖关系条件：用于关联同一会话内的几个规则，在一个规则内引用其他规则的结果。目前支持的选项名有：
requires-signature
含义：需要依赖某个其他的规则返回的结果为真
格式：requires-signature
[!]id
允许的参数值：规则ID串，限于同一会话内，前导“!”字符的话表示依赖的那个规则返回结果需要为假
requires-reverse-signature
含义：需要依赖某个同一会话内匹配相反方向数据的其他规则返回的结果为真
格式：requires-reverse-signature
[!]id
允许的参数值：规则ID串，限于同一会话内，前导“!”字符的话表示依赖的那个规则返回结果需要为假
上下文条件：用于测试规则匹配时的上下文情况。目前支持的选项名有：
tcp-state
含义：检查规则匹配时TCP会话是否处理所指定的状态
格式：tcp-state
参数值列表
允许的参数值：established, originator, responder,
stateless
eval
含义：执行某个策略脚本提供的函数，获取返回的成功或失败标记
格式：eval
策略脚本的某个函数名
允许的参数值：已加载的策略脚本的某个功能函数名，返回成功或失败
same-ip
含义：检查IP包的源目的地址是否相同
格式：same-ip
允许的参数值：不需要参数
动作选项：当规则的条件选项全部匹配上后，应该执行的动作。目前只支持一种选项名：
event
含义：产生告警事件
格式：event
msg
允许的参数值：msg为传递到日志中的字符串
规则实例：
signature s2b-356-5
{
  ip-proto == tcp
  dst-port ==
21
  event "FTP passwd retrieval attempt"
  tcp-state
established,originator
  payload
/.*[rR][eE][tT][rR]/
  payload
/[\x20\x09\x0b\/.]*passwd[\x20\x09\x0b]*[URL=http://hackbase.com/News/hk/#]$[/URL]/
  requires-reverse-signature !
ftp_server_error
}
此规则匹配发往TCP/21端口的客户端请求中是否包含试图获取passwd文件的命令操作，而且服务器返回成功，那么规则生成告警，在日志中记录"FTP
passwd retrieval
attempt"。
Bro规则的特点
-------------
与新版的Snort相比，Bro的规则在内容条件类的匹配选项（payload,
payload-size等）并没有什么特别的，新版Snort提供的匹配选项相较以前有了很大的改进，通过引入相对位移和按包内数据实时跳转匹配的机制，Snort其实变通地实现了部分协议解码能力，具体细节可参考《Snort
2.x数据区搜索规则选项的改进》一文。所以单从内容条件类的匹配选项来看，Bro规则选项的灵活性远不如Snort，但是Bro提供的依赖关系及上下文相关的选项则体现出Bro规则更有意义的高级特性。
requires-signature
依赖性选项使关联同一会话中并不在同一个报文中的多个攻击必须的几个请求序列成为可能。
eval
上下文选项可以使规则调用策略脚本中预定义的功能函数，由此可以扩展出几乎无限制的功能。
以上两点在《Bro：一个开放源码的高级NIDS系统》文中有例子。
requires-reverse-signature
依赖性选项使关联同一会话的请求和回应成为可能:
例如：
--------------------------------------------------------------------------
signature
s2b-654-13 {
  ip-proto == tcp
  dst-port ==
25
  event "SMTP RCPT TO overflow"
  tcp-state
established,originator
  payload /((^)|(\n+))[rR][cC][pP][tT]
[tT][oO][\x20\x09\x0b][^\n]{300}/
  requires-reverse-signature !
smtp_server_fail
}
signature smtp_server_fail
{
        ip-proto ==
tcp
        src-port ==
25
        payload
/.5[0-9][0-9]../  # 5xx permanent
failure
        tcp-state
established
}
--------------------------------------------------------------------------
此规则检测带超长参数的RCPT命令并检查服务器的回应，如果服务器不是回应错误的话则生成告警。这类直接的关联可以极其方便地判断一个攻击及其结果。
规则相关的几个支持策略脚本
--------------------------
在配置Bro使能规则匹配支持时，需要指定加载几个必要的策略脚本，主要有如下4个：
signatures.bro
处理规则得到匹配后的操作，根据每个规则所设置的对应动作不同，执行各种操作，比如产生告警、写入日志、记录数据、执行其他预定功能等。
sig-functions.bro
预定义一些根据报文内容判断应用程序类型及版本和其他的简单功能，这些功能函数可能在规则文本中通过
eval 选项被调用到。比如规则匹配到一个针对IIS服务器的溢出攻击，在规则中可以调用 isIIS
功能检查一下目标是否为IIS服务器，如果不是，那么目标并不受攻击影响，可以不产生报警，这样可以有效降低次要告警的数量。
sig-action.bro
一个告警ID与相应应该采取动作的对应表，不在表里的规则按默认设置的动作处理，如果要求对一个规则采取特别的动作，可以在表里添加相应的条目。
sig-addendum.sig
定义一些经常可能会被其他规则引用到的一些匹配情况，比如通过检查HTTP、SMTP、POP等常见网络协议的服务程序回应码来判断请求是否成功的规则，那么其他很多检测CGI攻击的规则可以引用这些预定义的规则来大致确认攻击的结果，根据情况不同采取不同的动作。
用户还可以编写自己的策略脚本来进行扩展出许多功能，甚至根据流量和连接情况检测到某些未知攻击，这些需要我们掌握Bro最复杂也是最灵活的工具策略脚本，这一系列的下一篇将会介绍它。