Snort的README文件都存放在/usr/local/share/doc/snort/目錄下，并且已經(jīng)以README.ipv6形式分好類以供查閱。
1.READERME.alert_order
1.1
Snort 會(huì)將抓取IP，ICMP，TCP，UDP協(xié)議的流量網(wǎng)絡(luò)信息的頭部存入數(shù)據(jù)庫中，分別對(duì)應(yīng)的表為iphdr,icmphdr,tcphdr,udphdr。hdr也就是header的意思。
舉個(gè)例子，如果只使用了如下這一條規(guī)則：
alert tcp 192.168.1.151 any -> 192.168.1.7 80 (msg:"PROTOCOL-TCP PACKAGE DETECTED"; sid:1000012; rev:1;)
這就是抓取了一條tcp的流量，Snort會(huì)將此條流量的信息不僅存入tcphdr表，而且也會(huì)存入iphdr表。
同理，規(guī)則中如果寫ICMP的話，icmphdr和iphdr都會(huì)有對(duì)應(yīng)包的頭部信息,但是tcphdr不會(huì)有，因?yàn)樗麄兏緵]關(guān)系。
再舉個(gè)例子，也是假設(shè)只是用了如下這一條規(guī)則。
alert ip 192.168.1.151 any -> 192.168.1.7 any (msg:"PROTOCOL-IP PACKAGE DETECTED"; sid:1000013; rev:1;)
雖然規(guī)則中過濾的是ip，但是查詢數(shù)據(jù)庫，發(fā)現(xiàn)還是會(huì)把tcp，icmp都會(huì)記錄。
通過上面這兩個(gè)例子我們就會(huì)發(fā)現(xiàn)，不管規(guī)則中過濾的是哪個(gè)協(xié)議，Snort會(huì)把這個(gè)包的中用到的所有協(xié)議（上面提到的四種之內(nèi)）記錄在數(shù)據(jù)庫中。
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;)
三種協(xié)議都有，到底匹配哪個(gè)？
測(cè)試從192.168.1.151ping192.168.1.7，本應(yīng)該只發(fā)4個(gè)icmp包，但是在數(shù)據(jù)庫的event表中看到了8個(gè)，查看其signature，發(fā)現(xiàn)icmp和ip的兩條規(guī)則都觸發(fā)了。
上圖中，第二列是cid，第三列是signature，發(fā)現(xiàn)同一時(shí)間觸發(fā)了12,9兩個(gè)，12是我自定義的ip那條規(guī)則的sig，9是icmp。
同時(shí)又看到iphdr和icmphdr表也同時(shí)都用8條數(shù)據(jù)，告警也多了8條，所以說一個(gè)ping命令，觸發(fā)了ip和icmp的兩條規(guī)則。
我又測(cè)試了從192.168.1.151訪問192.168.1.7web網(wǎng)頁，也同時(shí)觸發(fā)了12和13這兩條規(guī)則，不再贅述。
1.3
下面是協(xié)議相同的情況：
查看/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).
經(jīng)過做實(shí)驗(yàn)驗(yàn)證，發(fā)現(xiàn)只要是IP地址不同，就不算是一個(gè)規(guī)則。
發(fā)現(xiàn)5188和5199是同一個(gè)包，5190和5191是同一個(gè)包。
也就是一個(gè)包一次傳輸被Snort記錄了兩次。說明了，只要兩條規(guī)則中IP地址不同（any也算不同），這兩條規(guī)則就都會(huì)匹配。
上面README.alert_order中的情況都是IP地址相同的前提下討論的。
最后一個(gè)例子驗(yàn)證README.alert_order中的內(nèi)容。
然而失敗了。
還是和上個(gè)實(shí)驗(yàn)一樣的結(jié)果。
讓我們舉個(gè)最極端的例子好不好。
這說明了。只要sid不同，規(guī)則match到的話都會(huì)記錄。
啊啊~~~README.alert_oder神坑。
