規(guī)則格式
特征/簽名在suricata中起著非常重要的作用。在大多數(shù)情況下，人們使用現(xiàn)有的規(guī)則集。
Suricata-Update規(guī)則管理中描述了安裝規(guī)則集的正式方法。
Suricata規(guī)則文檔解釋了所有關(guān)于特征/簽名的內(nèi)容。
規(guī)則/簽名由以下內(nèi)容組成：
action：確定特征/簽名匹配時會發(fā)生什么（圖1紅色字體）
header：定義協(xié)議、IP地址、端口和規(guī)則的方向（圖1綠色字體）
rule options：定義規(guī)則的細(xì)節(jié)（圖1藍(lán)色字體）
（備注：紅色字體是Action，綠色字體是header，藍(lán)色字體是rule options.）
在這篇文章中，我們將使用上面的簽名/規(guī)則作為示例，突出顯示簽名的不同部分。它是從新興威脅數(shù)據(jù)庫（EmergingThreats）中提取的簽名，這是一個開放的數(shù)據(jù)庫，具有許多規(guī)則，您可以免費下載并在Suricata實例中使用。
1.Action
動作順序，默認(rèn)順序為：pass，drop，reject，alert
所有簽名/規(guī)則都有不同的屬性。其中之一是Action屬性。它決定了簽名/規(guī)則匹配時會發(fā)生什么。有四種類型的動作，當(dāng)簽名匹配并包含其中一個操作時將發(fā)生什么動作。
(1.1)pass
如果簽名匹配并包含pass, Suricata將停止掃描數(shù)據(jù)包并跳到所有規(guī)則的末尾(僅針對當(dāng)前數(shù)據(jù)包)。
(1.2)Drop
這只涉及IPS/內(nèi)聯(lián)模式。如果程序發(fā)現(xiàn)匹配的簽名(包含drop)，它將立即停止。這個數(shù)據(jù)包不會再發(fā)送出去了。缺點:接收方?jīng)]有接收到有關(guān)正在進(jìn)行的操作的消息，從而導(dǎo)致時間延遲（使用TCP）。Suricata會為此數(shù)據(jù)包生成警報。
(1.3)Reject
這是對數(shù)據(jù)包的主動拒絕。接收方和發(fā)送方都接收到一個拒絕包。當(dāng)匹配該規(guī)則時，自動選擇兩種類型的拒絕包：
（1.3.1）如果匹配規(guī)則并包含reject的數(shù)據(jù)包與TCP有關(guān)，它將是一個重置包（Reset-packet）。
（1.3.2）對于所有其他協(xié)議，它將是ICMP錯誤數(shù)據(jù)包。
Suricata還會生成警報。在Inline / IPS模式下，違規(guī)數(shù)據(jù)包也會像“drop”操作一樣被丟棄。
(1.5)Alert
如果簽名匹配并包含警報，則包將被視為與任何其他非威脅包一樣，除此之外，Suricata將生成一個警報。只有系統(tǒng)管理員才能注意到此警告alert。
Inline / IPS可以通過兩種方式阻止網(wǎng)絡(luò)流量。一種方法是drop?，另一種方式是reject。
規(guī)則將按照它們在文件中出現(xiàn)的順序加載。但它們將以不同的順序處理。簽名有不同的優(yōu)先級，最重要的簽名首先被掃描。優(yōu)先次序可以改變。默認(rèn)順序是: pass、drop、reject、alert。這意味著在丟棄（drop）規(guī)則之前考慮傳遞（pass?）規(guī)則，在拒絕（reject）規(guī)則之前考慮丟棄（drop）規(guī)則等等。
2.header
(2.1)協(xié)議
簽名/規(guī)則中的這個關(guān)鍵字告訴Suricata它所關(guān)注的協(xié)議是什么。可以在四種基本協(xié)議中進(jìn)行選擇
tcp (for tcp-traffic)
udp
icmp
ip (ip stands for ‘a(chǎn)ll’ or ‘a(chǎn)ny’)
同時也支持應(yīng)用層協(xié)議，可以從中選擇的第7層協(xié)議。如下:
http、ftp、tls (包括ssl)、smb、dns、dcerpc、ssh、smtp、imap、msn、modbus (默認(rèn)禁用)、dnp3 (默認(rèn)禁用)、enip (默認(rèn)禁用)、nfs (depends on rust availability)、ikev2 depends on rust availability)、krb5 (depends on rust availability)、ntp (depends on rust availability)、dhcp (depends on rust availability)。
這些協(xié)議的可用性取決于是否在配置文件suricata.yaml中啟用了該協(xié)議。如果您有一個簽名，例如一個http協(xié)議，Suricata確保簽名只有在涉及http通信時才能匹配。
（2.2）源和目標(biāo)地址（IP）
使用源和目標(biāo)，分別指定流量的來源和流量的目標(biāo)。您可以分配IP地址（支持IPv4和IPv6）和IP范圍。這些可以與運營商結(jié)合。如圖1所示：第一個強調(diào)部分是源，第二個是目的地（注意方向箭頭的方向）。
drop tcp?$HOME_NET?any ->?$EXTERNAL_NET?any (msg:”ET TROJAN Likely Bot Nick in IRC (USA +..)”; flow:established,to_server; flowbits:isset,is_proto_irc; content:”NICK “; pcre:”/NICK .*USA.*[0-9]{3,}/i”; reference:url,doc.emergingthreats.net/2008124; classtype:trojan-activity; sid:2008124; rev:2;)
通常，可以使用變量，例如$HOME_NET和?$EXTERNAL_NET。配置文件指定了這些關(guān)注的IP地址，這些設(shè)置將用于代替規(guī)則中的變量。
示例：
（2.3）源和目標(biāo)端口
流量通過端口流入和流出。不同的端口具有不同的端口號。例如，HTTP的默認(rèn)端口是80，而443通常是HTTPS的端口。但請注意，端口不指示通信中使用的協(xié)議。相反，它確定哪個應(yīng)用程序正在接收數(shù)據(jù)。
上面提到的端口通常是目標(biāo)端口。源端口，即發(fā)送數(shù)據(jù)包的應(yīng)用程序，通常由操作系統(tǒng)分配一個隨機端口。在為自己的HTTP服務(wù)編寫規(guī)則時，通常會編寫any?->?80，這意味著從任何源端口到HTTP應(yīng)用程序（在端口80上運行）的任何數(shù)據(jù)包都是匹配的。在設(shè)置端口時，您也可以使用特殊操作符，如下：
示例：
（2.4）方向
方向告訴簽名/規(guī)則必須匹配的方式。幾乎每個簽名都有一個向右箭頭（->），意味著只有具有相同方向的數(shù)據(jù)包才能匹配。但是，也可以使規(guī)則匹配兩個方式（<>）：
source->destination
source<>destination(both? directions)
但是沒有<-這種風(fēng)格。
以下示例說明了這一點。比如，有一個IP地址為1.2.3.4和端口1024的客戶端，以及一個IP地址為5.6.7.8的服務(wù)器，監(jiān)聽端口80（通常是HTTP）?？蛻舳讼蚍?wù)器發(fā)送消息，服務(wù)器回復(fù)其答案。
使用規(guī)則：alert tcp 1.2.3.4 1024 -> 5.6.7.8? 80。此規(guī)則僅僅匹配第一個數(shù)據(jù)包，因為方向指定在響應(yīng)包上不匹配。
3.規(guī)則選項
規(guī)則的其余部分包括規(guī)則選項。它們用括號括起來并用分號分隔。某些選項具有設(shè)置功能（例如msg），這些設(shè)置功能的選項由關(guān)鍵字指定，關(guān)鍵字后面跟冒號，冒號后跟設(shè)置的內(nèi)容。其他選項沒有設(shè)置功能，只有簡單的關(guān)鍵字（例如nocase）：
<keyword> : <settings>;
<keyword>;
規(guī)則選項具有特定的順序，更改其順序?qū)⒏淖円?guī)則的含義。
注意：字符 ; 和 " 在Suricata規(guī)則語言具有特殊含義，在規(guī)則選項值使用時必須轉(zhuǎn)義。使用轉(zhuǎn)義反斜杠，因為它充當(dāng)轉(zhuǎn)義字符例如：msg:" Message with semicolon\； " ;
接下來在文檔中介紹各種關(guān)鍵字的使用，一些關(guān)鍵字詳情如下：
（3.1）修飾符關(guān)鍵字
一些關(guān)鍵字函數(shù)充當(dāng)修飾符。有兩種類型的修飾符。
（3.1.1）舊式“content modifiers”風(fēng)格：
alert http any any->any any(content:"index.php";http_uri;sid:1;)
在上面的示例中，修改了模式'index.php'以檢查HTTP uri緩沖區(qū)。
（3.1.2）最近的類型稱為“sticky buffe”。它首先放置緩沖區(qū)名稱，然后將其后面的所有關(guān)鍵字應(yīng)用于該緩沖區(qū)，例如：
alert http any any->any any(http_response_line;content:"403 Forbidden";sid:1;)
在上面的示例中，針對HTTP響應(yīng)行檢查模式“403 Forbidden”，因為它遵循h(huán)ttp_response_line關(guān)鍵字
（3.2）標(biāo)準(zhǔn)化緩沖區(qū)
一個數(shù)據(jù)包由原始數(shù)據(jù)組成。HTTP和重組會復(fù)制這些類型的數(shù)據(jù)包。它們擦除異常內(nèi)容，組合數(shù)據(jù)包等。剩下的是一個叫做“標(biāo)準(zhǔn)化緩沖區(qū)”：
因為數(shù)據(jù)正在規(guī)范化，所以它不像過去那樣;?這是一種解釋.標(biāo)準(zhǔn)化緩沖區(qū)包括：所有HTTP關(guān)鍵字，重組流，TLS-，SSL-，SSH-，F(xiàn)TP-和dcerpc-緩沖區(qū)。
4.Meta 關(guān)鍵字
Meta?設(shè)置對Suricata的規(guī)則檢查沒有影響; 他們是Suricata上報的事件信息，對上報內(nèi)容有影響。
(4.1)msg (message)
關(guān)鍵字msg提供對觸發(fā)警報的有關(guān)簽名/規(guī)則相關(guān)文本提示信息。格式如下：
msg："some description";
實例：
msg: "ET EXPLOIT SMB-DS DCERPC PnP bind attempt ";
約定：（1）通常將簽名第一部分設(shè)為大寫顯示簽名的類。（2）通常在簽名中的第一個關(guān)鍵字為msg。
（4.2）SID(規(guī)則ID)
關(guān)鍵字sid為每個簽名提供自己的ID。這個id用數(shù)字表示。sid的格式是：
sid:123;
通常，簽名sid是作為簽名的最后一個關(guān)鍵字（或者如果有rev的話，則倒數(shù)第二個）提供的。
（4.3）rev（修訂版）
sid關(guān)鍵字幾乎每次都伴隨著rev。Rev代表簽名的版本。如果修改了簽名，則簽名編寫者將增加rev的數(shù)量。rev的格式是：
rev:123;:
sid寫在rev之前，這是一個慣例，兩者都是最后一個關(guān)鍵字。
（4.4）gid(組ID)
gid關(guān)鍵字可用于為不同的簽名組提供另一個id值（如sid中）。Suricata默認(rèn)使用gid 1.可以修改它。它通常不會被改變，改變它沒有技術(shù)含義。您只能在警報中注意到它。
示例: 在一個?fast.log文件中：
10/15/09-03:30:10.219671 [**] [1:2008124:2] ET TROJAN Likely Bot Nick in IRC (USA +..) [**] [Classification: A Network Trojan was Detected] [Priority: 3] {TCP} 192.168.1.42:1028 -> 72.184.196.31:6667
在[1:2008124:2]部分，1代表gid，2008124代表sid；2代表rev
(4.5)分類
classtype關(guān)鍵字提供有關(guān)規(guī)則和警報分類的信息。它由短名稱，長名稱和優(yōu)先級組成。例如，它可以告訴規(guī)則是僅僅是信息性的還是關(guān)于黑客等。對于每個classtype，這個classification.config具有將在規(guī)則中使用的優(yōu)先級。classtype定義如下：
config classification: web-application-attack,Web Application Attack,1
config classification: not-suspicious,NotSuspiciousTraffic,3
現(xiàn)在，當(dāng)我們在配置中定義了這個時，我們可以在規(guī)則中使用classtypes。具有classtype web-application-attack的規(guī)則將被賦予優(yōu)先級1，并且警報將包含“Web Application Attack”：
（4.6）reference （參考）
可以找到參考關(guān)鍵字指向有關(guān)簽名的信息以及簽名試圖解決的問題的位置。參考關(guān)鍵字可以在簽名中多次出現(xiàn)。此關(guān)鍵字適用于簽名編寫者和分析師，他們會調(diào)查簽名匹配的原因。它具有以下格式：
reference:type,reference
示例：reference: url,www.info.com? ? ?、reference: cve,CVE-2014-1234
（4.7）priority（優(yōu)先級）
priority關(guān)鍵字帶有一個強制數(shù)字值，范圍從1到255.最常使用數(shù)字1到4。將首先檢查具有更高優(yōu)先級的簽名。最高優(yōu)先級是1.通常，簽名已經(jīng)通過classtype具有優(yōu)先級。這可以用關(guān)鍵字優(yōu)先級否決。優(yōu)先格式為：
priority:1;
（4.8）metadata（元數(shù)據(jù)）
metadata關(guān)鍵字允許將額外的非功能信息添加到簽名中。雖然格式是自由格式，但建議堅持使用鍵值對，因為Suricata可以在前夕警報中包含這些值。格式為：
metadata:keyvalue;
metadata:keyvalue,keyvalue;
（4.9）target（目標(biāo)）
target關(guān)鍵字允許規(guī)則編寫者指定警報的哪一側(cè)是攻擊的目標(biāo)。如果指定，則會增強警報事件以包含有關(guān)源和目標(biāo)的信息。
格式為：
target:[src_ip|dest_ip]
如果值為src_ip，則生成的事件中的源IP（JSON中的src_ip字段）是攻擊的目標(biāo)。如果target設(shè)置為dest_ip，則目標(biāo)是生成的事件中的目標(biāo)IP。
5.IP 關(guān)鍵字
5.1 ttl
ttl關(guān)鍵字用于檢查數(shù)據(jù)包標(biāo)頭中的特定IP生存時間值。
格式為：ttl:<number>.
在ttl關(guān)鍵字的末尾，您可以輸入要匹配的值。生存時間值確定數(shù)據(jù)包在Internet系統(tǒng)中的最長時間。如果此字段設(shè)置為0，則必須銷毀數(shù)據(jù)包。生存時間基于跳數(shù)。數(shù)據(jù)包通過的每個跳/路由器減去一個數(shù)據(jù)包TTL計數(shù)器。此機制的目的是限制數(shù)據(jù)包的存在，以便數(shù)據(jù)包不會在無限路由循環(huán)中結(jié)束。
5.2?ipopts?
使用ipopts關(guān)鍵字，您可以檢查是否設(shè)置了特定的IP選項。Ipopts必須在規(guī)則的開頭使用。每條規(guī)則只能匹配一個選項。有幾個選項可以匹配。這些是：
5.3??sameip?
每個數(shù)據(jù)包都有一個源IP地址和一個目標(biāo)IP地址。源IP可以與目標(biāo)IP相同。使用sameip關(guān)鍵字，您可以檢查源的IP地址是否與目標(biāo)的IP地址相同。sameip關(guān)鍵字的格式為：sameip;
5.4?ip_proto?
使用ip_proto關(guān)鍵字，您可以匹配數(shù)據(jù)包標(biāo)頭中的IP協(xié)議。您可以使用協(xié)議的名稱或編號。例如，您可以匹配以下協(xié)議：
5.5 ID?
使用id關(guān)鍵字，您可以匹配特定的IP ID值。ID標(biāo)識主機發(fā)送的每個數(shù)據(jù)包，并且通常與正在發(fā)送的每個數(shù)據(jù)包一起遞增。IP ID用作片段標(biāo)識號。每個數(shù)據(jù)包都有一個IP ID，當(dāng)數(shù)據(jù)包被分段時，該數(shù)據(jù)包的所有片段都具有相同的ID。以這種方式，分組的接收器知道哪些片段屬于同一分組。（IP ID不處理順序，在這種情況下使用偏移。它闡明了片段的順序。）
id:<number>;
5.6 geoip
geoip關(guān)鍵字使您（您）能夠匹配網(wǎng)絡(luò)流量的源，目標(biāo)或源和目標(biāo)IP地址，并查看它所屬的國家/地區(qū)。為了能夠做到這一點，Suricata使用Maxmind的GeoIP API。
geoip的語法:
因此，您可以看到您可以使用以下內(nèi)容來明確您希望匹配的方向：
該關(guān)鍵字僅支持IPv4。因為它使用Maxmind的GeoIP API，所以必須編譯libgeoip。
5.7?fragbits （IP碎片）
使用fragbits關(guān)鍵字，可以檢查IP頭中是否設(shè)置了分段和保留位。fragbits關(guān)鍵字應(yīng)放在規(guī)則的開頭。Fragbits用于修改碎片機制。在將消息從一個Internet模塊路由到另一個Internet模塊期間，可能發(fā)生分組大于網(wǎng)絡(luò)可以處理的最大分組大小。在這種情況下，可以分段發(fā)送數(shù)據(jù)包。數(shù)據(jù)包大小的最大值稱為最大傳輸單位（MTU）。您可以匹配以下位：
可以使用以下修飾符更多地指定匹配此位：
格式：fragbits:[*+!]<[MDR]>;
5.8?fragoffset?
使用fragoffset關(guān)鍵字，您可以匹配IP片段偏移字段的特定十進(jìn)制值。如果要檢查會話的第一個片段，則必須將fragoffset 0與More Fragment選項組合在一起。碎片偏移字段便于重組。id用于確定哪些片段屬于哪個分組，并且片段偏移字段闡明片段的順序。您可以使用以下修飾符：
fragoffset的格式：
????????????????fragoffset:[!|<|>]<number>;
5.9?TOS?
tos關(guān)鍵字可以匹配IP頭TOS字段的特定十進(jìn)制值。tos關(guān)鍵字的值可以是0到255，IP頭的這個字段已由rfc2474更新，?以包含差異化服務(wù)的功能?。格式：
tos:[!]<number>;
6.TCP 關(guān)鍵字
6.1 SEQ?
可以在簽名中使用seq關(guān)鍵字來檢查特定的TCP序列號。序列號是TCP連接的兩個端點實際上隨機生成的數(shù)字?？蛻舳撕头?wù)器都創(chuàng)建一個序列號，它隨著它們發(fā)送的每個字節(jié)的增加而增加。所以這個序列號對于雙方都是不同的。該序列號必須由連接的雙方確認(rèn)。通過序列號，TCP處理確認(rèn)，命令和重傳。它的數(shù)量隨著發(fā)送方發(fā)送的每個數(shù)據(jù)字節(jié)而增加。seq有助于跟蹤字節(jié)所屬的數(shù)據(jù)流中的位置。如果SYN標(biāo)志設(shè)置為1，則數(shù)據(jù)的第一個字節(jié)的序列號是該數(shù)字加1（因此，2）。
6.2 ACK
ack是對TCP連接另一端發(fā)送的所有先前（數(shù)據(jù)）字節(jié)的接收的確認(rèn)。在大多數(shù)情況下，TCP連接的每個數(shù)據(jù)包在第一個SYN之后都有一個ACK標(biāo)志，而ack-number隨著每個新數(shù)據(jù)字節(jié)的接收而增加?？梢栽诤灻惺褂胊ck關(guān)鍵字來檢查特定的TCP確認(rèn)號。
6.3?window(窗口)
window關(guān)鍵字用于檢查特定的TCP窗口大小。TCP窗口大小是一種控制數(shù)據(jù)流的機制。窗口由接收器設(shè)置（接收器通告的窗口大?。?，并指示可以接收的字節(jié)數(shù)。在發(fā)送方可以發(fā)送相同數(shù)量的新數(shù)據(jù)之前，接收方必須首先確認(rèn)此數(shù)據(jù)量。該機制用于防止接收器被數(shù)據(jù)溢出。窗口大小的值是有限的，可以是2到65.535字節(jié)。要更多地利用帶寬，您可以使用更大的TCP窗口。window關(guān)鍵字的格式：
window:[!]<number>;
7.ICMP 關(guān)鍵字
ICMP（Internet控制消息協(xié)議）是IP的一部分。在提供數(shù)據(jù)（數(shù)據(jù)報）方面，IP本身并不可靠。ICMP在出現(xiàn)問題時提供反饋。它不會阻止問題的發(fā)生，但有助于理解出錯的地方和地點。如果需要可靠性，使用IP的協(xié)議必須自己處理可靠性。在不同的情況下，將發(fā)送ICMP消息。例如，當(dāng)目的地不可達(dá)時，如果沒有足夠的緩沖容量來轉(zhuǎn)發(fā)數(shù)據(jù)，或者當(dāng)數(shù)據(jù)報不應(yīng)該被分段時，等等?？梢栽诎㈩愋偷牧斜碇姓业礁鄡?nèi)容。ICMP消息有四個重要內(nèi)容，可以與相應(yīng)的ICMP關(guān)鍵字匹配。它們是：消息的類型，代碼，id和序列。
7.1? ITYPE?
itype關(guān)鍵字用于匹配特定的ICMP類型（數(shù)字）。ICMP有幾種消息，并使用代碼來澄清這些消息。不同的消息由不同的名稱區(qū)分，但更重要的是數(shù)值。有關(guān)更多信息，請參閱包含消息類型和代碼的表。
itype關(guān)鍵字的格式：
????????itype:min<>max;
????????itype:[<|>]<number>;
如查找大于10的ICMP類型：
itype：>10
以下列出了ICMP類型
7.2?ICODE
使用icode關(guān)鍵字，您可以匹配特定的ICMP代碼。ICMP消息的代碼闡明了該消息。與ICMP類型一起，它表明您正在處理什么樣的問題。代碼與每種ICMP類型具有不同的用途。icode關(guān)鍵字的格式：
icode:min<>max;
icode:[<|>]<number>;
示例：此示例查找大于5的ICMP代碼：icode:>5;
以下列出了所有ICMP類型的含義。如果未列出代碼，則僅在上表中定義類型0并具有ICMP代碼的含義。最新的表格可以在IANA的網(wǎng)站上找到
7.3 icmp_id
使用icmp_id關(guān)鍵字，您可以匹配特定的ICMP id值。每個ICMP數(shù)據(jù)包在發(fā)送時都會獲得一個id。在接收方收到數(shù)據(jù)包時，它將使用相同的ID發(fā)送回復(fù)，以便發(fā)送方識別它并將其與正確的ICMP請求連接。icmp_id關(guān)鍵字的格式：
????????icmp_id:<number>;?
7.4?icmp_seq?
您可以使用icmp_seq關(guān)鍵字檢查ICMP序列號。ICMP消息都有序列號。這可以用于（與id一起）用于檢查哪個回復(fù)消息屬于哪個請求消息.icmp_seq關(guān)鍵字的格式：
icmp_seq:<number>;
8.Payload關(guān)鍵字
Payload關(guān)鍵字檢查數(shù)據(jù)包或流的有效負(fù)載的內(nèi)容。
8.1 content（內(nèi)容）
content關(guān)鍵字在簽名中非常重要。在引號之間，您可以寫下您希望簽名匹配的內(nèi)容。最簡單的內(nèi)容格式是：
content: ”............”;
可以在簽名中使用多個內(nèi)容。內(nèi)容匹配字節(jié)。一個字節(jié)有256個不同的值（0-255）。你可以匹配所有角色;?從a到z，大寫和小寫以及所有特殊標(biāo)志。但并非所有字節(jié)都是可打印字符。對于這些字節(jié)，使用十六進(jìn)制表示法。許多編程語言使用0x00作為表示法，其中0x表示它涉及二進(jìn)制值，但規(guī)則語言?|00|用作表示法。這種表示法也可用于可打印字符。如：
您無法在內(nèi)容中使用的字符因為它們在簽名中已經(jīng)很重要。要匹配這些字符，您應(yīng)該使用十六進(jìn)制表示法。這些是：
將大寫符號寫成大寫字符是一種慣例
要http://在簽名的內(nèi)容中編寫，您應(yīng)該這樣寫：如果在簽名中使用十六進(jìn)制表示法，請確保始終將其放在管道之間。否則，表示法將作為內(nèi)容的一部分。content:?“http|3A|//”;幾個例子：
可以讓簽名檢查整個有效載荷以與內(nèi)容匹配，或者讓它檢查有效載荷的特定部分。如果您沒有為簽名添加任何特殊內(nèi)容，它將嘗試在有效內(nèi)容的所有字節(jié)中找到匹配項。默認(rèn)情況下，模式匹配區(qū)分大小寫。內(nèi)容必須準(zhǔn)確，否則不會匹配。
舉例：
content:!”Firefox/3.6.13”;。這意味著如果使用的Firefox版本不是3.6.13，則會生成警報。
8.2?nocase（不關(guān)心大小寫）
如果您不想?yún)^(qū)分大寫和小寫字符，可以使用nocase。關(guān)鍵字nocase是內(nèi)容修飾符.此關(guān)鍵字的格式為：nocase;您必須將其放在要修改的內(nèi)容之后，例如：
content: “abc”; nocase;它對簽名中的其他內(nèi)容沒有影響。
8.3?depth（深度）
depth關(guān)鍵字是絕對內(nèi)容修飾符。它來自內(nèi)容。深度內(nèi)容修飾符帶有必需的數(shù)值，如：depth:12;深度后的數(shù)字表示將檢查有效負(fù)載開頭的字節(jié)數(shù)。
8.4?startswith
該startswith關(guān)鍵字類似depth。它不需要參數(shù)，必須遵循content關(guān)鍵字。它修改了content在緩沖區(qū)的開頭準(zhǔn)確匹配。如：content:"GET|20|";startswith;
startswith?是一個簡寫符號：
content:"GET|20|";depth:4;offset:0;
startswith不能與被混合depth，offset，within或?distance為相同的圖案。
8.5 offset?（偏移）
offset關(guān)鍵字指定將檢查有效負(fù)載中的哪個字節(jié)以查找匹配。例如offset：3;?檢查第四個字節(jié)并進(jìn)一步。關(guān)鍵字偏移和深度可以組合并且通常一起使用。
如： content:“def”; offset:3; depth:3;
它將檢查從第三個字節(jié)到第六個字節(jié)的有效載荷。
8.6 （distance )距離
關(guān)鍵字distance是相對內(nèi)容修飾符。這意味著它表示此content?關(guān)鍵字與其前面的內(nèi)容之間的關(guān)系。距離在前一次匹配后有影響。關(guān)鍵字distance帶有必填數(shù)值。給出距離的值確定有效載荷中的字節(jié)，從中檢查相對于前一個匹配的匹配項。距離僅確定Suricata將開始尋找模式的位置。所以，distance：5;?表示模式可以是前一個匹配后的任何位置+5個字節(jié)。要限制Suricata最后一次匹配后的距離，請使用“within”。
如：
距離也可以是負(fù)數(shù)。它可用于檢查部分相同內(nèi)容（參見示例）的匹配項，或者甚至完全位于其之前的內(nèi)容。但這并不經(jīng)常使用。與其他關(guān)鍵字可以獲得相同的結(jié)果。
8.7?within
關(guān)鍵字within?是相對于前一個匹配。其中的關(guān)鍵字帶有必填數(shù)值。使用within確保只有當(dāng)內(nèi)容與設(shè)置的字節(jié)數(shù)內(nèi)的有效負(fù)載匹配時才會有匹配。within?不能為0（零）.
如前所述，距離和內(nèi)部可以很好地組合在一個簽名中。如果您希望Suricata檢查有效負(fù)載的特定部分以進(jìn)行匹配，請在內(nèi)部使用。
8.8?isdataat
isdataat關(guān)鍵字的目的是查看有效負(fù)載的特定部分是否仍有數(shù)據(jù)。關(guān)鍵字以數(shù)字（位置）開頭，然后是可選的，后跟“relative”，用逗號和選項rawbytes分隔。您可以使用“relative”一詞來了解有效負(fù)載的特定部分是否仍有相對于上一次匹配的數(shù)據(jù)。
如：
isdataat:512;
isdataat:50,relative;
第一個例子說明了一個簽名，它搜索有效載荷的字節(jié)512。第二個例子說明了在最后一次匹配之后搜索字節(jié)50的簽名。
您也可以在isdataat之前使用否定（?。?/p>
8.9 dsize
使用dsize關(guān)鍵字，您可以匹配數(shù)據(jù)包有效負(fù)載的大小。例如，您可以使用關(guān)鍵字來查找有效負(fù)載的異常大小。這在檢測緩沖區(qū)溢出時可能很方便。格式：
dsize:<number>;
8.10?rpc
rpc關(guān)鍵字可用于在RPC過程編號和RPC版本的SUNRPC CALL中進(jìn)行匹配。您可以使用通過*定義的通配符修改關(guān)鍵字。使用此通配符，您可以匹配所有版本和/或程序編號。RPC（遠(yuǎn)程過程調(diào)用）是一種允許計算機程序在另一臺計算機（或地址空間）上執(zhí)行過程的應(yīng)用程序。它用于進(jìn)程間通信。請參見?http://en.wikipedia.org/wiki/Inter-process_communication
格式：
????rpc:<applicationnumber>,[<versionnumber>|*],[<procedurenumber>|*]>;
8.11?replace（IPS模式）
替換內(nèi)容修飾符只能在ips中使用。它調(diào)整網(wǎng)絡(luò)流量。它將其后面的內(nèi)容（'abc'）更改為另一個（'def'），參見示例：
替換修飾符必須包含與其替換的內(nèi)容一樣多的字符。它只能用于單個數(shù)據(jù)包。它不適用于HTTP uri等規(guī)范化緩沖區(qū)或重組流中的內(nèi)容匹配。
校驗和將由Suricata重新計算，并在使用replace關(guān)鍵字后更改。
8.12pcre（Perl兼容正則表達(dá)式）
關(guān)鍵字pcre與正則表達(dá)式上的特定匹配。有關(guān)正則表達(dá)式的更多信息，請訪問http://en.wikipedia.org/wiki/Regular_expression。
pcre的復(fù)雜性雖然價格很高，但它對性能有負(fù)面影響。因此，為了減輕Suricata不得不經(jīng)常檢查pcre，pcre主要與'content'相結(jié)合。在這種情況下，在檢查pcre之前，內(nèi)容必須先匹配。pcre的格式：pcre:"/<regex>/opts";
有一些pcre的特性可以修改：
默認(rèn)情況下，pcre區(qū)分大小寫。
.（點）是正則表達(dá)式的一部分。它匹配除換行符之外的每個字節(jié)。
默認(rèn)情況下，有效負(fù)載將被檢查為一行。
可以使用以下字符修改這些質(zhì)量：
這些選項是perl兼容修飾符。要使用這些修飾符，您應(yīng)該將它們添加到正則表達(dá)式后面的pcre。像這樣：
????pcre: “/<regex>/i”;
有一些pcre兼容的改性劑也可以改變pcre的質(zhì)量。這些是：
A：模式必須在緩沖區(qū)的開頭匹配。（在pcre ^中類似于A.）
E：忽略緩沖區(qū)/有效負(fù)載末尾的換行符。
G：顛倒貪婪。
8.12.1?Suricata的修飾符
Suricata有自己特定的pcre修飾符。這些是：
R：匹配相對于最后一個模式匹配。它類似于距離：0;
U：使標(biāo)準(zhǔn)化的uri上的pcre匹配。它與uri_buffer匹配就像uricontent一樣，內(nèi)容與http_uri.U結(jié)合可以與/ R結(jié)合使用。請注意，R是相對于前一個匹配的，因此兩個匹配必須位于HTTP-uri緩沖區(qū)中。閱讀有關(guān)HTTP URI規(guī)范化的更多信息。
I：在HTTP-raw-uri上進(jìn)行pcre匹配。它與http_raw_uri匹配在同一個緩沖區(qū)中。我可以和/ R結(jié)合使用。請注意，R是相對于前一個匹配的，因此兩個匹配必須位于HTTP-raw-uri緩沖區(qū)中。閱讀有關(guān)HTTP URI規(guī)范化的更多信息。
P：在HTTP-request-body上進(jìn)行pcre匹配。因此，它在與http_client_body相同的緩沖區(qū)上匹配。P可以與/ R組合。請注意，R是相對于前一個匹配的，因此兩個匹配必須位于HTTP請求主體中。
Q：在HTTP響應(yīng)主體上進(jìn)行pcre匹配。因此，它在與http_server_body相同的緩沖區(qū)上匹配。Q可與/ R組合使用。請注意，R是相對于前一個匹配的，因此兩個匹配必須位于HTTP響應(yīng)主體中。
H：在HTTP標(biāo)頭上進(jìn)行pcre匹配。H可以與/ R組合。請注意，R是相對于前一個匹配的，因此兩個匹配必須位于HTTP標(biāo)頭正文中。
D：使非標(biāo)準(zhǔn)化標(biāo)題上的pcre匹配。因此，它在與http_raw_header相同的緩沖區(qū)上匹配。D可以與/ R組合。請注意，R是相對于前一個匹配的，因此兩個匹配必須位于HTTP-raw-header中。
M：使請求方法上的pcre匹配。因此，它在與http_method相同的緩沖區(qū)上匹配。M可以與/ R組合。請注意，R與前一個匹配項相關(guān)，因此兩個匹配項必須位于HTTP方法緩沖區(qū)中。
C：在HTTP-cookie上進(jìn)行pcre匹配。因此，它與http_cookie在同一個緩沖區(qū)上匹配。C可以與/ R組合。請注意，R與前一個匹配項相關(guān)，因此兩個匹配項必須位于HTTP-cookie緩沖區(qū)中。
S：使HTTP-stat-code上的pcre匹配。因此，它在與http_stat_code相同的緩沖區(qū)上匹配。S可與/ R組合使用。請注意，R是相對于前一個匹配的，因此兩個匹配必須位于HTTP-stat-code緩沖區(qū)中。
Y：使HTTP-stat-msg上的pcre匹配。因此，它在與http_stat_msg相同的緩沖區(qū)上匹配。Y可以與/ R組合。請注意，R是相對于前一個匹配的，因此兩個匹配必須位于HTTP-stat-msg緩沖區(qū)中。
B：您可以在簽名中遇到B，但這只是為了兼容性。因此，Suricata不使用B但支持它，因此它不會導(dǎo)致錯誤。
O：覆蓋配置pcre匹配限制。
V：在HTTP-User-Agent上進(jìn)行pcre匹配。因此，它在與http_user_agent相同的緩沖區(qū)上匹配。V可以與/ R組合。請注意，R與前一個匹配項相關(guān)，因此兩個匹配項必須位于HTTP-User-Agent緩沖區(qū)中。
W：在HTTP主機上進(jìn)行pcre匹配。因此，它在與http_host相同的緩沖區(qū)上匹配。W可與/ R組合使用。請注意，R與前一個匹配項相關(guān)，因此兩個匹配項必須位于HTTP-Host緩沖區(qū)中。
9.轉(zhuǎn)換
轉(zhuǎn)換關(guān)鍵字將粘性緩沖區(qū)中的數(shù)據(jù)轉(zhuǎn)換為其他內(nèi)容。例：
alert http any any->any any (file_data;strip_whitespace;\content:"window.navigate(";sid:1;)
即使在navigate和(之間有一個或多個空格，此示例也會匹配流量。變換可以鏈接。它們按照它們在規(guī)則中出現(xiàn)的順序進(jìn)行處理。每個轉(zhuǎn)換輸出都充當(dāng)下一個輸出的輸入。
9.1??strip_whitespace
剝離isspace()C中調(diào)用所考慮的所有空格，如：
alert http any any->any any (file_data;strip_whitespace;\content:"window.navigate(";sid:1;)
9.2?compress_whitespace
將所有連續(xù)的空格壓縮到單個空間中.
9.3?to_sha256
獲取緩沖區(qū)，計算SHA-256哈希并傳遞原始哈希值。如：
alert http any any->any any(http_request_line;to_sha256;\content:"|54A9 7A8A B09C 1B81 3725 2214 51D3 F997 F015 9DD7 049E E5AD CED3 945A FC79 7401|";sid:1;)
注意：取決于libnss被編譯到Suricata中。
10.預(yù)過濾關(guān)鍵字
10.1?fast_pattern?
10.1.1?Suricata快速模式確定解釋
如果在規(guī)則中明確設(shè)置了'fast_pattern'關(guān)鍵字，Suricata將使用它作為快速模式匹配。'fast_pattern'關(guān)鍵字只能按規(guī)則設(shè)置一次。如果未設(shè)置“fast_pattern”，Suricata會自動確定要用作快速模式匹配的內(nèi)容。以下說明Suricata用于自動確定要使用的快速模式匹配的邏輯。(請注意，如果存在正（即非否定）內(nèi)容匹配，則忽略否定內(nèi)容匹配以進(jìn)行快速模式確定。否則，考慮否定的內(nèi)容匹配)
fast_pattern選擇標(biāo)準(zhǔn)如下：
1.Suricata首先識別簽名中使用的具有最高“優(yōu)先級”的所有內(nèi)容匹配。優(yōu)先級基于匹配的緩沖區(qū)，通常“http_ *”緩沖區(qū)具有更高的優(yōu)先級（較低的數(shù)字是較高的優(yōu)先級）。有關(guān)哪些緩沖區(qū)具有優(yōu)先級的詳細(xì)信息，請參見?附錄B.
2.在步驟1中識別的內(nèi)容匹配（最高優(yōu)先級內(nèi)容匹配）內(nèi)，最長（就字符/字節(jié)長度而言）內(nèi)容匹配被用作快速模式匹配。
3.如果多個內(nèi)容匹配具有相同的最高優(yōu)先級并且有資格獲得最長長度，則具有最高字符/字節(jié)多樣性分?jǐn)?shù)（“模式強度”）的那個匹配用作快速模式匹配。有關(guān)用于確定圖案強度的算法的詳細(xì)信息，請參閱附錄C.
4.如果多個內(nèi)容匹配具有相同的最高優(yōu)先級，符合最長長度和相同的最高模式強度，則最后注冊的緩沖區(qū)（“l(fā)ist_id”）用作快速模式匹配。有關(guān)不同緩沖區(qū)/列表的注冊順序，請參閱附錄B.
5.如果多個內(nèi)容匹配具有相同的最高優(yōu)先級，則有資格獲得最長的長度，相同的最高模式強度，并且具有相同的list_id（即查看相同的緩沖區(qū)），然后是首先出現(xiàn)的（從左到右） ）在規(guī)則中用作快速模式匹配。
值得注意的是，對于具有相同優(yōu)先級，長度和模式強度的內(nèi)容匹配，'http_stat_msg'，'http_stat_code'和'http_method'優(yōu)先于常規(guī)'內(nèi)容'匹配。
10.1.2?附錄
附錄A - Suricata 1.3.4的緩沖區(qū)，list_id值和注冊順序.對于Suricata 1.1.x - 1.4.x，這應(yīng)該基本相同.
附錄B - Suricata 2.0.7的緩沖區(qū)，list_id值，優(yōu)先級和注冊順序
對于Suricata 2.0.x，這應(yīng)該基本相同。
附錄C - 模式強度算法
來自detect-engine-mpm.c。基本上，模式強度“得分”從零開始，從左到右查看傳入的字節(jié)數(shù)組中的每個字符/字節(jié)。如果之前在數(shù)組中沒有看到字符/字節(jié)，如果它是一個字母字符，它會為分?jǐn)?shù)增加3;?否則，如果它是可打印字符0x00,0x01或0xFF，它會為分?jǐn)?shù)增加4;?否則它會增加6分。如果在分?jǐn)?shù)加1之前已經(jīng)看到字符/字節(jié)。最終得分返回。
在多模式匹配器（MPM）中僅使用一個簽名內(nèi)容。如果有多個內(nèi)容，則Suricata使用“最強”的內(nèi)容。這意味著長度的組合，內(nèi)容的變化程度以及它所處的緩沖區(qū)。通常，越長越好，越多越好。有時，簽名作者得出結(jié)論，他希望Suricata使用其他內(nèi)容，而不是默認(rèn)使用。例如：
User-agent: Mozilla/5.0 Badness;
content:”User-Agent|3A|”;
content:”Badness”; distance:0;
在此示例中，您會看到第一個內(nèi)容比第二個內(nèi)容更長且更多，因此您知道Suricata將使用此內(nèi)容作為MPM。由于“User-Agent：”會經(jīng)常匹配，并且“Badness”在網(wǎng)絡(luò)流量中顯得較少，因此您可以使用“fast_pattern”使Suricata使用第二個內(nèi)容。
content:”User-Agent|3A|”;
content:”Badness”; distance:0; fast_pattern;
10.1.1? fast_pattern:only
有時簽名只包含一個內(nèi)容。在這種情況下，沒有必要Suricata將在MPM中找到匹配后進(jìn)一步檢查。如果只有一個內(nèi)容，則整個簽名匹配。Suricata會自動注意到這一點。在某些簽名中，仍然用'fast_pattern：only;'表示。雖然Suricata不需要fast_pattern：但它確實支持它。
10.1.2??fast_pattern:’chop’
如果您不希望MPM使用整個內(nèi)容，可以使用fast_pattern'chop'。例如：
content: “aaaaaaaaabc”; fast_pattern:8,4;
這樣，MPM僅使用最后四個字符
10.2 prefilter
可以使用'prefilter'關(guān)鍵字在特定規(guī)則中啟用其他非MPM關(guān)鍵字的預(yù)過濾器引擎。在以下規(guī)則中，TTL測試將用于預(yù)過濾而不是單字節(jié)模式：
alert ip any any->any any(ttl:123;prefilter;content:"a";sid:1;)
有關(guān)如何配置預(yù)濾器引擎的更多信息，請參閱預(yù)濾器引擎。
11 .流關(guān)鍵字
11.1?flowbits
Flowbits由兩部分組成。第一部分描述了它將要執(zhí)行的操作，第二部分是flowbit的名稱。有多個數(shù)據(jù)包屬于一個流。Suricata將這些流量保留在內(nèi)存中。欲了解更多信息，請參閱 流和流處理。Flowbits可以確保在例如兩個不同的數(shù)據(jù)包匹配時生成警報。只有兩個數(shù)據(jù)包匹配時才會生成警報。因此，當(dāng)?shù)诙€數(shù)據(jù)包匹配時，Suricata必須知道第一個數(shù)據(jù)包是否也匹配。如果數(shù)據(jù)包匹配，F(xiàn)lowbits標(biāo)記流程，因此Suricata'知道'它應(yīng)該在第二個數(shù)據(jù)包匹配時生成警報。
Flowbits有不同的動作。這些是：
flowbits：set，name
????????????將在流程中設(shè)置條件/'名稱'（如果存在）。
flowbits：isset，name
????????????可以在規(guī)則中使用，以確保在規(guī)則匹配并在流中設(shè)置條件時生成警報。
flowbits：toggle，name
????????????反轉(zhuǎn)當(dāng)前設(shè)置。因此，例如，如果設(shè)置了條件，則將取消設(shè)置，反之亦然。
flowbits：unset，name
????????????可用于取消流程中的條件。
flowbits：isnotset，name
????????????可以在規(guī)則中使用，以確保它在匹配時生成警報，并且未在流中設(shè)置條件。
flowbits：noalert
????????????此規(guī)則不會生成警報。
如：
當(dāng)您查看第一個規(guī)則時，您將注意到它會生成一個警報，如果它匹配，如果它不是該規(guī)則末尾的'flowbits：noalert'。此規(guī)則的目的是檢查“userlogin”上的匹配項并在流中標(biāo)記該匹配項。因此，無需生成警報。沒有第一條規(guī)則，第二條規(guī)則無效。如果第一個規(guī)則匹配，則flowbits將該特定條件設(shè)置為存在于流中?，F(xiàn)在使用第二個規(guī)則可以檢查先前的數(shù)據(jù)包是否滿足第一個條件。如果此時第二個規(guī)則匹配，則會生成警報。
11.2?flow
flow關(guān)鍵字可用于匹配流的方向，因此可以to/from客戶端或to/from服務(wù)器進(jìn)行匹配。如果流程建立與否，它也可以匹配。flow關(guān)鍵字也可用于表示簽名必須僅在流上（only_stream）或僅在數(shù)據(jù)包上匹配（no_stream）。
因此，使用flow關(guān)鍵字，您可以匹配：
to_client
????????????匹配從服務(wù)器到客戶端的數(shù)據(jù)包。
to_server
????????????匹配從客戶端到服務(wù)器的數(shù)據(jù)包。
from_client
????????????匹配從客戶端到服務(wù)器的數(shù)據(jù)包（與to_server相同）。
from_server
????????????匹配從服務(wù)器到客戶端的數(shù)據(jù)包（與to_client相同）。
established
????????????匹配已建立的連接。
not_established
????????????匹配不屬于已建立連接的數(shù)據(jù)包。
stateless
????????????匹配已建立連接且不屬于已建立連接的數(shù)據(jù)包。
only_stream
????????????匹配由流引擎重新組裝的數(shù)據(jù)包。
no_stream
????????????匹配尚未由流引擎重組的數(shù)據(jù)包。將不匹配已重新組裝的數(shù)據(jù)包。
only_frag
????????????匹配已從片段重組的數(shù)據(jù)包。
no_frag
????????????匹配尚未從片段重組的數(shù)據(jù)包。
可以組合多個流選項，例如：
確定的標(biāo)準(zhǔn)取決于協(xié)議：
對于TCP，將在三次握手之后建立連接：
對于其他協(xié)議(例如UDP)，在看到來自連接兩邊的流量后，將認(rèn)為建立了連接。
11.3?flowint
Flowint允許使用變量進(jìn)行存儲和數(shù)學(xué)運算。它的運行方式與flowbits非常相似，但增加了數(shù)學(xué)功能，并且可以存儲和操作整數(shù)，而不僅僅是標(biāo)志集。我們可以將它用于許多非常有用的事情，例如計算出現(xiàn)次數(shù)，添加或減去出現(xiàn)次數(shù)，或者在流中對多個因子進(jìn)行閾值處理。這將很快擴展到全局上下文，因此用戶可以在流之間執(zhí)行這些操作。
語法如下:
flowint:name,modifier[,value];
定義var（不是必需的），或檢查是否設(shè)置了一個:
flowint:name,<+,-,=,>,<,>=,<=,==,!=>,value;
flowint:name,(isset|isnotset);
比較或改變變量。加，減，比較大于或小于，大于或等于，小于或等于可用。要比較的項目可以是整數(shù)或其他變量。
例如，如果您想要計算在特定流中看到用戶名的次數(shù)，并警告它是否超過5。
alert tcp any any->any any(msg:"Counting Usernames";content:"jonkman";\flowint:usernamecount,+,1;noalert;)這將計算每次出現(xiàn)并增加var usernamecount，而不為每個出現(xiàn)警報。現(xiàn)在說如果流中有超過五個匹配，我們想要生成警報:alert tcp any any->any any(msg:"More than Five Usernames!";content:"jonkman";\flowint:usernamecount,+,1;flowint:usernamecount,>,5;)因此，只有當(dāng)usernamecount超過五個時，我們才會收到提醒.所以現(xiàn)在讓我們說我們想要獲得如上所述的警報，但不是如果有更多的用戶名注銷。假設(shè)此特定協(xié)議表示使用“jonkman logout”注銷，請嘗試:alert? tcp? any? any->any? any(msg:"Username Logged out";content:"logout jonkman";\flowint:usernamecount,-,1;flowint:usernamecount,>,5;)所以現(xiàn)在，如果此特定用戶名的活動登錄數(shù)超過五個，我們將僅收到警報.這是一個相當(dāng)簡單的例子，但我相信它顯示了這樣一個簡單的函數(shù)可以為規(guī)則編寫做些什么的力量。我在登錄跟蹤，IRC狀態(tài)機，惡意軟件跟蹤和暴力登錄檢測等方面看到了很多應(yīng)用程序。
假設(shè)我們正在跟蹤一個通常允許每個連接有五次登錄失敗的協(xié)議，但是我們有一個漏洞，攻擊者可以在五次嘗試之后繼續(xù)登錄，我們需要了解它。alert tcp an yany->any any(msg:"Start a login count";content:"login failed";\flowint:loginfail,notset;flowint:loginfail,=,1;noalert;)因此，如果變量尚未設(shè)置，我們會檢測到初始失敗，如果是，則將其設(shè)置為1。我們的第一擊。
alert tcp any any->any any(msg:"Counting Logins";content:"login failed";\flowint:loginfail,isset;flowint:loginfail,+,1;noalert;)
如果已設(shè)置，我們現(xiàn)在正在遞增計數(shù)器。
alert tcp any any->any any(msg:"More than Five login fails in a Stream";\content:"login failed";flowint:loginfail,isset;flowint:loginfail,>,5;)
現(xiàn)在，如果我們在同一個流中交叉五次登錄失敗，我們將生成警報。
但是，我們還要說，如果有兩次成功登錄并且之后登錄失敗，我們也需要提醒。
alert tcp any any->any any(msg:"Counting Good Logins";\content:"login successful";flowint:loginsuccess,+,1;noalert;)
在這里，我們計算好登錄，所以現(xiàn)在我們將計算與失敗相關(guān)的良好登錄：
alert tcp any any->any any(msg:"Login fail after two successes";\content:"login failed";flowint:loginsuccess,isset;\flowint:loginsuccess,=,2;)
11.4?stream_size?
流大小選項根據(jù)注冊的字節(jié)數(shù)按序列號匹配流量。此關(guān)鍵字有幾個修飾符：
格式：
stream_size:<server|client|both|either>,<modifier>,<number>;
規(guī)則中stream-size關(guān)鍵字的示例:
alert tcp any any->any any(stream_size:both,>,5000;sid:1;)
12 . bypass關(guān)鍵字
Suricata有一個bypass關(guān)鍵字，可用于簽名，以排除進(jìn)一步評估的流量。該bypass關(guān)鍵字在預(yù)期流量較大的情況下非常有用（例如Netflix，Spotify，Youtube）.該bypass關(guān)鍵字被視為匹配后關(guān)鍵字.如：在匹配的http流量上繞過流量：
alert http any any->any any(content:"suricata-ids.org";\http_host;bypass;sid:10001;rev:1;)
