Snort的README文件都存放在/usr/local/share/doc/snort/目录下，并且已经以README.ipv6形式分好类以供查阅。

1.READERME.alert_order

1.1

Snort 会将抓取IP，ICMP，TCP，UDP协议的流量网络信息的头部存入数据库中，分别对应的表为iphdr,icmphdr,tcphdr,udphdr。hdr也就是header的意思。
　　举个例子，如果只使用了如下这一条规则：
alert tcp 192.168.1.151 any -> 192.168.1.7 80 (msg:"PROTOCOL-TCP PACKAGE DETECTED"; sid:1000012; rev:1;)
　　这就是抓取了一条tcp的流量，Snort会将此条流量的信息不仅存入tcphdr表，而且也会存入iphdr表。
　　同理，规则中如果写ICMP的话，icmphdr和iphdr都会有对应包的头部信息,但是tcphdr不会有，因为他们根本没关系。
　　再举个例子，也是假设只是用了如下这一条规则。
alert ip 192.168.1.151 any -> 192.168.1.7 any (msg:"PROTOCOL-IP PACKAGE DETECTED"; sid:1000013; rev:1;)
　　虽然规则中过滤的是ip，但是查询数据库，发现还是会把tcp，icmp都会记录。
　　通过上面这两个例子我们就会发现，不管规则中过滤的是哪个协议，Snort会把这个包的中用到的所有协议（上面提到的四种之内）记录在数据库中。

1.2

如果遇到如下这种怎么办

alert icmp 192.168.1.151 any -> 192.168.1.7 any (msg:"PROTOCOL-ICMP PACKAGE DETECTED"; sid:1000011; rev:1;)
alert tcp 192.168.1.151 any -> 192.168.1.7 80 (msg:"PROTOCOL-TCP PACKAGE DETECTED"; sid:1000012; rev:1;)
alert ip 192.168.1.151 any -> 192.168.1.7 any (msg:"PROTOCOL-IP PACKAGE DETECTED"; sid:1000013; rev:1;)

三种协议都有，到底匹配哪个？
测试从192.168.1.151ping192.168.1.7，本应该只发4个icmp包，但是在数据库的event表中看到了8个，查看其signature，发现icmp和ip的两条规则都触发了。

signature表

event表

上图中，第二列是cid，第三列是signature，发现同一时间触发了12,9两个，12是我自定义的ip那条规则的sig，9是icmp。
同时又看到iphdr和icmphdr表也同时都用8条数据，告警也多了8条，所以说一个ping命令，触发了ip和icmp的两条规则。
我又测试了从192.168.1.151访问192.168.1.7web网页，也同时触发了12和13这两条规则，不再赘述。

1.3

下面是协议相同的情况：
查看/usr/locale/share/doc/snort/README.alert_order帮助文件，

[root@localhost snort]# more README.alert_order 
ALERT ORDERING
--------------

The Snort 2.0 detection engine changes how the ordering of rules
affect which alerts fire.  Before Snort 2.0, knowing which alerts would fire
first was determined by the position of the rule during initialization.
If the rule was read before another rule, then the rule that was read first
would be the alert that was logged.

This has all changed with the 2.0 detection engine.  There are now two stages
that determine which alerts will fire for a packet.  Ideally, Snort would have
the ability to log all alerts in a packet, but the current output modules do
not allow for this.

The first stage in the 2.0 detection engine is rule set selection.  Depending
on the rule set that is selected, different alerts may be generated.  The
rule sets are select first by transport protocol and then by characteristics
within the specific transport protocol:

  * TCP/UDP:  selection based on source and destination ports
  * ICMP:     selection based on ICMP type
  * IP:       selection based on IP transport protocol (if not TCP/UDP/ICMP)

Each protocol also has a generic rule set associated with it.  This provides
for the case where a packet does not match any unique properties of the
transport protocol.

It is important to note that every packet matches against a generic rule set,
since every unique rule set includes the generic rule set.  For example, if
a packet with a destination port of 80 is inspected, the rule set that
contains destination port 80 rules is selected, not the generic rule set.

The rule set selected is important.  In the second stage of the 2.0
detection engine, which rules get matched are determined by the rule set that
is selected.

Once a rule set is selected, two general types of rules are matched against.
These rules are content and non-content rules.  The content rules have
higher rule ordering priority over non-content rules, so if a content rule
matches a packet and a non-content rule matches a packet, the content rule
will always win.  If no content rules match, then the non-content rule that
is first in the file (the old snort way) will win.  This doesn't
apply when a unique rule set has been selected because the unique non-content
rules are first in the inspection order.  For example,  if an ICMP packet of
type 8 is inspected, two rules will match the packet.  One of the rules
is a generic ICMP Echo Request with no type indicated, and the other rule is
an ICMP Echo Request with a itype:8.  The itype:8 rule will always fire 
regardless of it's position in the rule file because it is the more unique
rule (since it has an itype:8).

-- Examples --

Which rule fires when there are two identical rules:

alert tcp any any -> any any ( msg:"foo1"; content: "foo"; )
alert tcp any any -> any any ( msg:"foo2"; content: "foo"; )

foo1 fires because it is first in the rules file.  This applies for all rules
(uricontent, content, no-content) that are exactly the same.  The first rule
in the rule files alerts.

Which rule fires when there are two rule with the same content, but one rule
has any any ports and the other has a specific port?

alert tcp any any -> any any ( msg:"foo1"; content: "foo"; )
alert tcp any any -> any 80 ( msg:"foo2"; content: "foo"; )

foo2 fires because it is considered a unique rule because it specifies a port
and gets put in the unique rule group for port 80.  foo1 is considered a 
generic rule because it has no specific port characteristics.

Which rule fires when a uricontent rule and a content rule both match a
packet?

alert tcp any any -> any 80 ( msg:"foo1"; content: "foo"; )
alert tcp any any -> any 80 ( msg:"foo2"; uricontent: "foo"; )

foo2 fires (as long as http_inspect is on) because uricontent rules are
matched against the packet first, and if there is a uricontent match then
this rule takes priority over content and no-content rules.

Which rule fires when a content rule and a no-content rule both match a
packet?

alert tcp any any -> any any ( msg:"foo1"; content: "foo"; )
alert tcp any any -> any any ( msg:"foo2"; )

foo1 fires because content rules are matched against a packet first, and if
there is a content match, then any no-content rules that match the packet
also will take a lower priority than any content rule that matches a packet.

Which rule fires when two content rules match a packet?

alert tcp any any -> any any ( msg:"foo1"; content: "foo"; )
alert tcp any any -> any any ( msg:"foo2"; content: "foobar";)

foo2 fires because the content rule with the longer content string takes
the higher priority.

Which rule fires when two ICMP rules match a packet?

alert icmp any any -> any any ( msg:"ICMP-No-iType"; dsize:>800; )
alert icmp any any -> any any ( msg:"ICMP-iType"; itype:8; dsize:>800;)

ICMP-iType fires because it has an 'itype' parameter, which specifies the
ICMP rule as unique ('itype' is the only parameter for ICMP rules that
specify uniqueness, otherwise it's considered generic).

经过做实验验证，发现只要是IP地址不同，就不算是一个规则。

测试规则

发现5188和5199是同一个包，5190和5191是同一个包。
也就是一个包一次传输被Snort记录了两次。说明了，只要两条规则中IP地址不同（any也算不同），这两条规则就都会匹配。
上面README.alert_order中的情况都是IP地址相同的前提下讨论的。

最后一个例子验证README.alert_order中的内容。
然而失败了。
还是和上个实验一样的结果。

让我们举个最极端的例子好不好。

只有sid不同的两条rule

signature表

event表

这说明了。只要sid不同，规则match到的话都会记录。
啊啊~~~README.alert_oder神坑。