Snort規則

一、Snort簡介

如果病毒一樣，大多數入侵行為都具有某種特征，Snort的規則就是用這些特征的有關信息構建的。入侵者會劉勇已知的系統弱點數據庫嗎，如果入侵者試圖利用這些弱點來實施攻擊，也可以作為一些特征。這些特征可能出現在包的頭部，也可能出現在載荷中。Snort的檢測系統是基於規則的，而規則是基於特征的。Snort規則可以用來檢測數據包的不同部分。Snort 1.x可以分析第3等和第4層的信息，但是不能分析應用層協議。Snort 2.x增加了對應用層頭部的支持。所有的數據包根據類型的不同按順序與規則比對。
規則可以用來產生告警信息、記錄日志，或者使包通過（pass）：對Snort來說，也就是悄悄丟棄（drop），通過在這里的意義與防火牆或路由器上的意義是不同的。在防火牆和路由器中，通過和丟棄是兩個相反的概念。規則文件通常放置在snort.conf文件中，你可以用其他規則文件，然后用主配置文件引用它們（#include 的方式，在snort 2.x主要是用過主文件引用）。

二、規則示例

2.1 第一個不可用規則

這里有一個非常不好用的規則，事實上，也許是最差的規則，但是它可以很好地檢測snort是否正常工作，並可以產生告警：
alert ip any any -> any any (msg: "IP Packet detected";)

這個規則使每當捕獲一個IP包都產生告警信息，下面簡要解釋一下該條規則所用的語句：

• "alert"表示如果包與條件匹配，就產生一個告警信息。條件由下面的語句定義
• "ip"表示規則獎杯用在所有的IP包上
• 第一個"any"是對IP包源地址部分的條件定義，表示來自任何一個IP地址的IP包都符合條件，任何IP包都符合本條件
• 第二個"any"用來定義源端口號，表示匹配任何（0 ~ 65535）端口號,本條規則匹配IP報文，所以端口號其實無任何意義，因為端口號只針對傳輸層協議（TCP、UDP）生效
• 第三個"any"是對IP包目的地址部分的條件地址，any表示這條規則匹配所有的目的地址
• 第四個"any"用來定義目的端口條件，在此條規則中同樣不生效
• 最后一部分是規則的選項，並包含一條將被記錄的告警信息

2.2 規則的結構

所有的規則都可以分為兩個邏輯組成部分：規則頭部和規則選項

規則頭部	規則選項

規則的頭部包含規則所做的動作的信息，也可以包含於包所對比的一些條件。選項部分通常包含一個告警信息以及包的哪個部分被用來產生這個信息。一條規則可以用來探測一個或多個類型的入侵活動，一個好的規則可以用來探測多種入侵特征。

動作	協議	地址	端口	方向	地址	端口

動作部分表示，當規則與包比對並不符合條件時，會采取什么類型的動作。通常的動作時產生告警或記錄日志或向其他規則發出請求。
協議部分用來在一個特定協議的包上應用規則。這是規則所涉及 的第一個條件，一些可以用到的協議如：IP，ICMP，UDP，TCP等

地址部分定義源或目的地址。地址可以是一個主機，一些主機的地址或者網絡地址。你也可以用這些部分將某些地址從網絡中排除。注意，在規則中有兩個地址段，依賴於方向決定地址是源或者是目的，例如，方向段的值是"->"那么左邊的地址就是源地址，右邊的地址就是目的地址。

如果協議是TCP、UDP，端口部分用來確定規則所對應的包的源及目的端口。如果是網絡層協議，如IP或ICMP，端口號就沒有意義了。

方向部分用來確定哪一邊的地址和端口是源，哪一邊是目的在。

示例：
alert icmp any any -> any any (msg: "Ping with TTL=100"; ttl:100;)

括號之前的部分叫做規則頭部，括號中的部分叫做規則選項。頭部一次包括下面部分：

• 規則的動作：在這個規則中，動作是alert（告警），就是如果符合下面的條件，就會產生告警。記住如果產生告警，默認的情況下是會記錄日志的。
• 協議：在這個規則中，協議時ICMP，也就是說這條規則僅僅對ICMP包有效，如果一個包的協議不是ICMP，Snort探測引擎就不會理會這個包已節省CPU事件。協議部分在你對某種協議的包應用snort規則的時候是非常重要的。
• 方向。這在個示例中，方向用->表示從左向右的方向，表示在這個符號的左面部分是源，右面是目的，也表示規則引用在從源到目的的包上。如果是<-，那么久相反。注意，也可以用<>來表示規則將應用在所有方向上。
• 目的地址和端口，在這個示例中。它們都是"any"，表示規則並不關心它們的目的地址。在這個規則中，由於any的作用，方向段並沒有實際的作用，因為它將被應用在所有方向的ICMP包上。

在括號中的選項部分表示：如果包符合TTL=100的條件就產生一條包含文字："Ping with TTL=100"的告警。TTL是IP包頭部字段。

三、規則詳解

3.1 規則頭部

3.1.1 規則動作

動作是snort規則中的第一個部分，它表示規則的條件符合的時候，將會有什么樣的動作產生。Snort有5個預定義動作，你也可以定義自己的動作，需要注意的是，Snort 1.x 和 2.x對規則的應用是不同的，在1.x中，只要包符合第一個條件，它就會做出動作，然后就不再管它，盡管它可能符合多個條件；在2.x中，只有包和所有的相應規則對比后，才根據最嚴重的情況發出告警。

3.1.1.1 pass

這個動作高速Snort不理會這個包，這個動作在你不想檢查特定的包的時候可以加快Snort的操作速度。例如：如果你在網絡中有一台包含一些弱點的主機，用來檢測網絡安全漏洞，可能希望不理會對這台機器的攻擊，pass規則這時就可以用到了。

3.1.1.2 log

log動作用來記錄包，記錄包有不同的方式，例如：可以記錄到文件或者數據庫。根據命令行參數和配置文件，包可以被記錄為不同的詳細程度。你可以用"snort -?"命令來查看你所用的Snort版本的命令行參數。

3.1.1.3 alert

alert動作用來在一個包符合規則條件時發送告警信息。告警的發送有多種方式，例如可以發送到文件或者控制台。log動作與alert動作不同在於：alert動作是發送告警然后記錄包，log動作僅僅記錄包。

3.1.1.4 dynamic

dynamic規則動作由其他activate動作的規則調用，在正常情況下，他們不會被用來檢測包。一個動態規則僅能被一個"activate"動作激活。

3.1.1.5 自定義動作

除了以上動作外，你也可以定義自己的動作，以用於不同的目的，例如：

• 向syslog發送消息。Syslog是系統日志守護進程，它在/var/log中創建日志文件，這些文件的位置可以通過修改/etc/syslog.conf來改變。你可以在unix系統中用命令"man syslog"或者"man syslog.conf"來獲取更多的信息。Syslog相當於Windows中的事件查看器。
• 向如HP OpenView等網管系統發送SNMP trap
• 在一個包上引用多個動作。如你前面所看到的，一個規則僅僅規定了一個動作，自定義動作可以用來產生多個動作。例如：你可以在發送SNMP trap的同時記錄Syslog
• 將數據記錄到XML文件中
• 將信息記錄到數據庫中，Snort可以將數據記錄到MySQL，Postgress SQL，Oracle和Microsoft SQL server中

這些新的動作類型在配置文件snort.conf中定義。一個新動作用下面的通用結構來定義：

ruletyoe action_name
{
    action definition
}

關鍵字ruletype后面跟隨動作的名稱，連個大括號中是實際的動作定義，類似於c語言中的函數。例如：我們定義一個叫做smb_db_alert的動作，用來向workstation.list中的主機發送SMB告警，同時在MySQL中的"snort"數據庫記錄，如下所示：

ruletype smb_db_alert
{
    type alert
    output alert_smb: workstation.list
    output database: log,mysql,user=root password=root dbname=snort hsot=localhost
}

3.1.2 協議

協議是Snort規則中的第二部分，這一部分將顯示哪種類型的包將與規則比對。到目前為止，Snort可以支持以下協議：

• IP
• ICMP
• TCP
• UDP
  如果協議是IP，Snort檢測包中的數據鏈路層頭部來確定包的類型，如果協議類型是其他任何一種，Snort檢測IP頭部來確定協議類型。

3.1.3 協議

在Snort規則中，有兩個地址部分，用來檢測包的來源和目的地址。地址可以是一個主機地址或者網絡地址。你可以用關鍵字any來制定所有的地址。地址后面用斜線來附加一個數字，表示掩碼的位數。比如：192.168.2.0/24 代表一個C類網絡192.168.2.0，其子網掩碼是255.255.255.0。

你也可以在Snort規則額胡總制定一個地址的列表，比如：你在網絡中包含連個C類地址：192.168.2.0和192.168.8.0，你想對除了這兩個網絡之外的其他地址應用規則，你可以用下面的規則，其中連個地址用逗號分隔：

alert icmp ![192.168.2.0/24,192.168.8.0/24] any -> any any (msg: "Ping with TTL=1--"; ttl:100;)

注意：方括號與否定器一起用的，如果沒有否定符號，你可以不用方括號。（2.9版本待確認）

3.1.4 端口

端口號用來在進出特定的某個或一些列端口的包上運行規則，例如，你可以用源端口23來對來自Telnet服務器的包應用規則。你可以用關鍵字any來對包應用規則，而不管它的端口號。端口號僅僅對TCP、UDP協議有意義，如果你選擇的協議是ICMP、IP，端口號就不起作用。

3.1.4.1 端口范圍

你可以在規則中的端口段設置一些列的端口，而不是一個。用冒號分隔起始和結束。例如下面的規則將對來自1024-2048的所有UDP包告警：

alert udp any 1024:2048 -> any any (msg: "UDP ports";)

3.1.4.2 上限和下限

你可以僅僅用一個起始端口號或結束端口號來表示端口列表，例如：:1024表示比1024小，包含1024的所有端口，1000: 表示比1000大，包括1000的所有端口

3.1.4.3 否定符

與地址段相同，你也可以在Snort規則中的端口段中用否定符合來排除一個或多個端口。下面的規則將記錄除了53端口外的其他所有UDP通信。

log udp any !53 -> any any(msg:"Log UDP";)

但是你不能用逗號來分隔過個端口，如 53,54 這樣的表示是不允許的，但是你可以用 53:54 來表示一個端口范圍。（2.9版本待確認）

3.1.4.4 共用端口號

共用端口號是提供給一些公用應用的。在UNIX平台上，你可以查看/etc/services文件，可以看到更多的端口的定義。RFC1700中包含詳細列表。目前ICANN負責管理這些端口號，可以在 ICANN.ORG中獲取信息。

3.1.4 方向段

在Snort規則中，方向段確定源和目的，下面是方向段的相關規定：

• "->"表示左邊的地址和端口是源而右邊是目的
• "<-"表示右邊第地址和端口是源而左邊是目的在
• "<>"表示規則獎杯應用在兩個方向上，在你想同時監視服務器和客戶端的時候，可以用到這個標示。

以下部分學習自CSDN: https://blog.csdn.net/weixin_44813582/article/details/105918523

3.2 規則選項

Snort規則選項部分在頭部后面，在一對圓括號里面，其中可能包含一個選項，也可能包含用分號分割的過個選項，這些選項的關系是邏輯與的關系，只有當選項中的條件都滿足的時候，規則動作才會被執行。所有snort規則選項之間用分號隔開，每個規則選項也被用冒號分為選項關鍵字和選項值。

四類主要的規則選項類：

• 一般 提供信息但在檢測過程中不產生任何影響
• 有效負載 在凈荷中查找數據，並且能過相互關聯（數據包數據部分）
• 非有效負載 查找非凈荷中的數據（數據包首部）
• 過后檢測選項 這些選項時某條規則被處罰后，所設置的執行的規則

3.2.1 general rule options

3.2.1.1 msg

msg規則選項向日志和警報引擎告知要打印的消息以及數據包轉儲或警報，他是一個簡單的文本字符串，利用\作為轉義字符來表示離散的字符，否則這些字符可能會使Snort的規則解析器感到困惑（例如分號; 字符）。

msg:"<message text>";

3.2.1.2 reference

提供包含外部的一些攻擊識別系統的引用功能，該插件目前支持幾種特定的系統以及唯一URL。輸出插件將使用此插件來聽有關生成的警報的其他信息的鏈接。
確保還查看<http://www.snort.org/pub-bin/sigs-search.cgi/>，以獲取基於sid索引警報描述的系統。

格式：

reference:<id system>, <id>; [reference:<id system>, <id>;]

示例：

alert tcp any any -> any 21 (msg:"IDS287/ftp-wuftp260-venglin-linux";
    flags:AP; content:"|00 00 00 01 02|";
    reference:arachnids, IDS287; reference:bugtraq,1387;
    reference:cve,CAN-2000-1574;)

3.2.1.3 gid

用於標識當規則被觸發時，是snort的哪一部分生成事件，例如gid 1和規則子系統有關，大於100的gid被實際來表示特定的預處理器和解碼器。有關正在使用的當前生成器ID，請參見源代碼樹中的etc/generators。請注意，gid關鍵字是可選項，如未指定，默認為1，為避免與snort已定義的gid沖突，建議從1000000開始，一般規則編寫，不建議使用。gid需要和sid配合使用。文件etc/gen-msg.map包含有關預處理器和解碼器gid的更多信息，示例：

alert tcp any any -> any 80 (content:"BOB"; gid:1000001; sid:1; rev:1;)

查看/usr/local/share/doc/snort/generators文件（此文件不是配置文件）：

rules_subsystem             1 # Snort Rule Engine
rpc_decode                  106 # RPC Preprocessor（預處理器）
stream4                     111 # Stream4 preprocessor（預處理器）
ftp                         125 # FTP decoder（解碼器）

3.2.1.3 sid

識別不同的snort規則（snort規則編號），用於唯一標識一條規則，應與rev關鍵字配合使用，文件sig-msg.map包含警報消息到Snort規則id的映射。在對警報進行處理后以將ID映射到警報消息時，此信息非常有用。

sid:<snort rule id>;

3.2.1.4 rev

標識snort規則的修訂，與sid配合使用（說明規則的版本）

alert tcp any any -> any 80 (content:"BOB"; sid:1000003; rev:2;)

3.2.1.5 classtype

snort根據其默認的規則文件，將攻擊進行相應分類，並具有不同的優先級，1-4，1最高，規則分類被定義在classification.config文件中。(優先級1（高）是最嚴重的，優先級4（非常低）是最不嚴重的。)

classtype: <class name>;

classifacation.config文件，該文件的每一行都遵循下面的語法：
    config classification: name,description,priority
name表示類別名稱，在snort規則中用classtype關鍵字來指定
description是對類別的簡單描述
priority是這個類別的默認優先級，用數字表示，並可以在snort選項中用關鍵字priority改變。
    示例：
    config classification: DoS,Denial of Service Attack,2

類型	描述	優先
attempted-admin	嘗試獲取管理員特權	高
attempted	嘗試獲取用戶特權	高
inappropriate-content	檢測到不適當內容	高
policy-violation	潛在的違反公司隱私的行為	高
shellcode-detect	檢測到可執行代碼	高
successful-admin	管理員特權獲取成功	高
successful-user	用戶特權獲取成功	高
trojan-activity	檢測到網絡木馬	高
unsuccessful-user	用戶權限獲取失敗	高
web-application-attack	Web應用攻擊	高
attemptd-dos	試圖拒絕服務	中
attempted-recon	企圖泄漏	中
bad-unknown	潛在的不良流量	中
default-login-attempt	嘗試使用默認的用戶名和密碼登錄	中
denial-of-service	嘗試拒絕服務攻擊	中
misc-attack	雜項攻擊	中
non-standard-protocol	檢測非標准協議或事件	中
rpc-portmap-decode	解碼RPC查詢	中
successful-dos	拒絕服務	中
successful-recon-largescale	大規模信息泄漏	中
successful-recon-limited	信息泄漏	中
suspicious-filename-detect	檢測到可疑文件名	中
suspicious-login	檢測到使用可疑用戶名的嘗試登錄	中
system-call-detect	檢測到系統調用	中
unusual-client-port-connection	客戶端正在使用異常端口	中
web-application-activity	訪問潛在的易受攻擊的Web應用程序	中
icmp-event	常規ICMP事件	低
misc-activity	雜項活動	低
network-scan	檢測網絡掃描	低
not-suspicious	不可以流量	低
protocol-command-decode	通用協議命令解碼	低
string-detect	檢測到可疑字符串	低
unknown	未知流量	低
tcp-connection	檢測到TCP連接	非常低

3.2.1.6 priority

配置規則優先級（可以覆蓋規則類型classtype預置的優先級）

priority:<priority interger>;

3.2.1.7 metadata

表明規則的一些其他信息，例如是否在規則共享庫中共享，及其gid和sid，以及基於什么目標的服務標識，采用鍵值對形式，鍵值之間空格分開，多個鍵值對，逗號隔開，次關鍵字只有在Host Attribute Table已經提供才有意義。

metdata:key1 value1;
metdata:key1 value1,key2 value2;

鍵	描述	值格式
engine	指共享庫規則	"shared"
sodi	共享庫規則生成器和SID	gid/sid
service	基於目標的服務標識符	"http"

alert tcp any any -> any 80 (msg:"Shared Library Rule Example";
    metadata:engine shared; metadata:soid 3|12345;)
    
alert tcp any any -> any 80 (msg:"Shared Library Rule Example";
    metadata:engin shared, soid 3|12345;)
    
alert tcp any any -> any 80 (msg:"Shared Library Rule Example";
    metadata:service http;)    

3.2.2 payload detection rule options

3.2.2.1 content

查找匹配凈荷中的內容，並觸發響應，選項數據可以包含混合文本和二進制數據，二進制數據放在兩個管道符號"||"之間，表示為字節碼，需要通過十六進制的方式進行表示，若果規則前面有!，則將在不包含此內容的數據包上觸發警報。當編寫規則以警告不符合特定模式的數據包時，這很有用，格式：

content:[!]"<content string>";

alert tcp any any -> any 139 (content:"|5c 00|p|00|I|00|P|00|E|00 5c|";)
alcet tcp any any -> any 80 (content:!"GET";)

此外，content還有很多修飾符：

Nocase          content字符串大小寫不敏感，即忽略大小寫
rawbytes        直接匹配原始數據包，忽視預處理器解碼。如果未設置該關鍵字，大部分預處理器會使用解碼規范化數據做content匹配
Depth           匹配的深度
Offset          開始匹配的偏移量
Distance        兩次content之間匹配的間距，與offset類似，不過，distance設置的是從上一個匹配結束開始的距離，而offset是從開始計算
Within          兩次content匹配之間至多的間距（字節）
http_cookie     匹配cookie
http_raw_cookie 匹配未經normalize的cookie
http_header     匹配header
http_raw_header 匹配未經normalize的header
http_method     匹配method
http_uri        匹配uri
http_raw_url    匹配日志未經nomalize的url中
http_stat_code  匹配狀態碼中匹配
http_stat_msg   匹配狀態信息
http_encode     匹配HTTP報文中url，首部，cookie字段使用的特定的編碼方式，格式（！和or不能結合使用）
http_encode格式：
http_encode;[uri|header|cookie], [!][<utf8|double_encode|non_ascii|uencode|bare_byte|ascii|iis_encode>]
http_encode示例：
alert tcp any any -> any any (msg:"UTF8/UEncode Encoding present"; http_encode:uri,utf8|uencode;)
alert tcp any any -> any any (msg:"No UTF8"; http_encode:uri,!utf8);

注意：http開頭的修飾符需要配合前面介紹過的預處理器http_inspect一起使用

3.2.2.2 protected_content

提供content的大部分功能，不同的是輸入的查詢內容形式上不同，上傳查詢內容的安全哈希摘要進行查詢，隱藏查詢內容更具保護性，如在配置文件中未指定默認的哈希算法，則在規則中要指定（md5，sha25，sha512），還需要指定length關鍵字，標識原始數據長度，格式。

protected_content:[!]"<content hash>", length:orig_len[, hash:md5|sha256|sha512]

示例：

alert tcp any any <> any 80 (msg:"MD5 Alert"; protected_content:"293C9EA246FF9985DC6F62A650F78986"; hash:md5; offset:0; length:4;)

 - hash 如上例，配合protecte_content，指定使用的哈希算法
 - length 配合protect_content關鍵字使用，已受保護的形式標識規則摘要的內容的原始數據長度，范圍 0 - 65535

3.2.2.4 nocase

使用nocase關鍵字，規則編寫者可以指定Snort應該查找特定的模式，而忽略大小寫。nocase修改規則中的上一個content關鍵字，格式：

nocase;

示例：

alert tcp any any -> any 21 (msg:"FTP ROOT"; content:"USER root"; nocase;)

圖解：

content:"abc"; cocase;

3.2.2.5 rawbytes

rawbytes關鍵字允許規則查看原始數據包數據，而忽略預處理器進行的任何解碼。這充當了上一個content選項的修飾符。
HTTP Inspect具有一組使用原始數據的關鍵字，例如：
http_raw_cookie、http_raw_header、http_raw_uri等，它們與原始HTTP請求和響應的特定部分匹配。
如果未顯式指定rawbytes，則默認情況下，大多數其他預處理都會使用解碼/規范化的數據進行內容匹配。因此，應中rawbytes以檢查數據包中的任意原始數據，格式;

rawbytes;

示例：
此示例告訴內容模式匹配查看原始流量，而不是Telnet解碼器提供的解碼流量。

alert tcp any any -> any 21 (msg:"Telnet NOP"; content:"|FF F1|"; rawbytes;)

3.2.2.6 depth

depth關鍵字允許規則編寫者指定Snort應該在包中搜索指定模式的距離。depth修改了規則中先前的"content"關鍵字。
深度為5會使Snort僅在payload的前5個字節內查找指定的模式。
由於depth關鍵字是以前的content關鍵字的修飾符，因此在指定depth之前，規則中必須由內容。
此關鍵字允許值大於或等於要搜索的模式長度，最小允許值為1，此關鍵字的最大允許值為65535。
該值也可以設置為引用同一規則中由byte_extract關鍵字提取的變量的字符串值。

格式：

depth:[<number><var_name>];

圖解：

content:"abc"; depth:3;

3.2.2.7 offset

offset關鍵字允許規則編寫器指定從何處開始搜索數據包中的模式。offset修改規則中的上一個"content"關鍵字。
偏移量5會告訴Snort咋payload的前5個字節之后開始尋找指定的模式。
由於offset關鍵字是以前的content關鍵字的修飾符，因此指定offset之前，規則中必須有內容。
辭官集資允許輸入-65535到65535之間的值。
該值也可以設置為引用同一規則中由byte_extract關鍵字提取出來的變量的字符串值。

格式：

offset:[<number>|<var_number>];

圖解：

content:"def"; offset:3;

綜合示例：

alert tcp any any -> any 80 (content:"def"; offset:3; depth:3;)

3.2.2.8 distance

distance關鍵字使規則編寫者可以指定Snort在開始搜索相對於先前模式匹配末尾的指定模式之間應忽略的包數。
可以認為這與offset完全一樣，只是它與最后一個模式匹配的末尾有關，而不是與數據包的開頭有關。
此關鍵字允許輸入-65535到65535之間的值。
該值也可以設置為引用同一規則中由byte_extract關鍵字提取的變量的字符串值。

格式：

distance:[<byte_count>|<var_name>];

示例：
以下規則映射到/ ABC.{1,}DEF /的正則表達式。

alert tcp any any -> any any (content:"ABC"; content:"DEF"; distance:1;)

圖解：

content:"abc"; content:"def"; distance:0;

不僅如此，有時不同的distance值結果可能相同，比如下面這個例子，無論是在"abc"之后偏移0還是4或是中間的任意一個整數，都能匹配到后面的"def"，因為distance並沒有對后面的匹配長度做任何限制：

content:"abc"; content:"def"; distance:0;
content:"abc"; content:"def"; distance:4;

除此之外，distance由於是相對於上一次的匹配結果的位置偏移，所以它的值可以是負數：

content:"abc"; content:"bcd"; distance:-2;

3.2.2.9 within

within也是一個修飾content的關鍵字，他表示從上一個content匹配位置之后的指定字節內對當前的content進行匹配，within的值不能為0，最大值為65535。
該值也可以設置為引用同一規則中由byte_extract關鍵字提取的變量的字符串值。

格式：

within: [<byte_count>|<var_name>];

例子：
在匹配到"ABC"結尾后的十個字節內搜索匹配"EFG"

alert tcp any any -> any any (content:"ABC"; content:"EFG"; within:10;)

圖解：

content:"abc"; content:"def"; within:3;

同樣，within也可以和distance一起使用。

content:"abc"; content:"def"; distance:1; within:4;

3.2.2.10 http_client_body

http_client_body關鍵字是一個內容修飾符，用於將搜索限制為HTTP客戶端請求的正文。
由於此關鍵字是先前content關鍵字的修飾符，因此在指定"http_client_body"之前，規則中必須有內容。使用此選項檢查的數據量取決於HttpInspect的post_depthconfig選項。當post_depth設置為-1時，與此關鍵字匹配的模式將不起作用。

格式：

http_client_body;

示例：
此規則將對模式"EFG"的搜索限制為HTTP客戶端請求的原始正文。

alert tcp any any -> any 80 (content:"ABC"; content:"EFG"; http_client_body;)

注意：不允許將 http_client_body 修飾符與 rawbytes 修飾符用於同一內容；

3.2.2.11 fast_pattern

snort對只有一個content關鍵字的規則使用多模匹配，而對於過個content的規則就對最長對最法則的一個進行多模匹配，而fast_pattern則可以改變這個狀況，如果在較簡單的content字段后加上fast_pattern關鍵字則會優先匹配這個content，有時這種方法可以有效提升效率。
此規則使內容"IJKLMNO"采取快速模式匹配，即使它比氣啊年的模式"ABCDEFGH"段。

alert tcp any any -> any 80 (content:"ABCDEFGH"; content:"IJKLMNO"; fast_pattern;)

不僅如此，fast_pattern還支持部分content多模匹配，比如下面這個例子，表示從content的第一字節'開始之后'的五字節進行多模匹配，即匹配"JKLMN"，但仍用content規則選項檢測為"IJKLMNO"：

alert tcp any any -> any 80 (content:"ABCDEFGH"; content:"IJKLMNO"; fast_pattern:1,5;);

only關鍵字，表示不會將該content加入到規則構建樹中，此條規則中，將內容"IJLKMNO"采用快速模式匹配，並且內容應僅應用於快速模式匹配，並不作為content規則選項檢測。

alert tcp any any -> any 80 (content:"ABCDEFGH"; content:"IJKLMNO"; nocase; fast_pattern:only;)

3.2.2.12 uricontent

相當於http_uri修改的content關鍵字，在標准化的請求url中查找

3.2.2.13 urilen

指定要匹配的url的長度，包括最大長度，最小長度，或者長度范圍，使用norm|raw表示使用的是原始緩沖區還是規范化的url緩沖區，格式：

urilen:min<>max[,<uribuf>];
urilen:[<|>]<number>[,<uribuf>];

<uribuf> : "norm" | "raw"

3.2.2.14 isdataat

判斷指定位置是否有數據，可選相對於之前的content匹配結束，格式

isdataat: [!]<int>[, relative|rawbytes];

3.2.2.15 pcre

pcre關鍵字允許使用兼容perl的正則表達式編寫規則，正則的細節查閱snort_manual
格式：

pcre:[!]"(/<regex>/|m<delim><regex><delim>)[ismxAEGRUBPHMCOIDKY]

示例：

alert tcp any any -> any 80 (content:“/foo.php?id="; pcre:"/\/foo.php?id=[0-9]{1,10}/iU";)

3.2.2.16 pkt_data

對於原始的傳輸載荷設置檢測指針，任何相對或是絕對的content匹配和其他凈載荷檢測規則選項，如果設置pkt_data，將應用用於原始的TCP/UDP載荷或者標准化的緩存（如果是telent，規范化的smtp）

3.2.2.17 file_data

將檢測的指針指向下一緩沖區：1、如果是HTTP流量，a.HTTP響應正文（不分開/預縮/規范化），b.解分塊的HTTP響應正文，c.解壓縮的HTTP響應正文，d.規范化HTTP響應正文。2、如果是SMTP/POP/IMAP流量時， 將緩沖區設置到a.SMTP/POP/IMAP數據正文（關閉解碼時包括Email首部和MIME）b.base64解碼的MIME附件。c.非編碼的MIME附件，d.可引用，可打印解碼的MIME附件，e.Unix到Unix的解碼附件。3、如果不是由1和2設置，將被設置到凈荷。

3.2.2.18 base64_decode

用於base64解碼數據，對於http首部，次選項特別有用， 例如Http權限首部，格式：

base64_decode [:[bytes <bytes_to_deocde>][, ][offset <offset>[, relative]];

其中可選bytes后面設置要解碼的字節數，offset后面設置相對起始點或者相對於doe_ptr的偏移量，relative，設定檢測相對doe_ptr。

示例：

alert tcp any any -> any any (msg: "Authorization NTLM"; \
    content:"Authorization:"; http_header; \
    base64_decode:bytes 12, offset 6, relative; base64_data; \
    content:"NTLMSS;"within:8;)

3.2.2.19 base64_data

用於將指針置於base64解碼緩沖區的開頭，base64_decode需要將base64_data選項前指定

3.2.2.20 byte_test

該選項檢測一段二進制字節是否為特定值，能夠測試二進制自定或者轉換代表字節串為等效二進制而檢測，格式：

byte_test: <bytes to convert>, [!]<operator>, <value>, <offset> \
[, relative][, <endian>][, string, <number type>][, dce] \
[, bitmask <bitmask_value>];

bytes = 1 - 10, 檢測的字節數
operator = '<' | '=' | '>' | '<=' | '>=' | '&' | '^'，與設定值的關系
value = 0 - 4294967295，設定值
offset = -65535 to 65535 偏移量
relative 相對上一個
endian 小端存儲，little，大端存儲，big
number type 進制，hex 十六進制，dec 十進制，oct 八進制
bitmask_value = 1 to 4 byte hexadecimal value，字節掩碼

3.2.2.21 bytes_jump

該關鍵字用於跳過指定的字節長度，以在特定位置執行檢測，格式

byte_jump: <bytes_to_convert>, <offset> [, relative][, multiplier <mult_value>] \
[, <endian>][, string, <number_type>][, align][, from_beginning][, from_end] \
[, post_offset <adjustment value>][, dce][, bitmask <bitmask_value>];

bytes = 1 - 10，同上
offset = -65535 to 65535
mult_value = 0 - 65535，將計算字節乘上value，並跳過該值的字節數
post_offset = -65535 to 65535，在其他跳躍之后再次向前或者向后進行跳躍value字節
from_beginning/from_end，從數據包載荷的開始而不是當前位置跳躍/從尾部開始進行跳躍
bitmask_value = 1 to 4 bytes hesadecimal value

3.2.2.22 byte_extract

該規則從數據包載荷中截取一定數量的字節，存為變量，以供后面選項使用，每個規則最多只能創建兩個byte_extract變量。它們可以在同一規則中重復使用任何次數。格式：

byte_extract: <bytes_to_extract>, <offset>, <name> [, relative] \ 
    [, multiplier <multiplier value>][, <endian>][, string][, hex][, doc][, oct]
    [, align <align value>][, dce][, bitmask <bitmask>];
 - bytes_to_extract = 1 - 10
 - name 保存的變量名
 - value = 0 - 4294967295
 - offset = -65535 to 65535
 - bitmask_value = 1 to 4 byte hexadecimal value

示例：

 - 在偏移量0處從字節讀取字符串的偏移量
 - 在偏移量1處從紫兒姐讀取字符串的深度
 - 使用這些值將模式匹配約束到較小的區域
 
 alert tcp any any -> any any (byte_extract:1, 0, str_offset; \
        byte_extract:1, 1, str_depth; \
        content:"bad stuff"; offset:str_offset; depth:str_depth; \
        msg:"Bad Stuff detected within field";)
 
 alert tcp any any -> any any (content:"|04 63 34 35|"; offset:4; depth:4; \
        byte_extract:2, 0, vat_match, relative, bitmask 0x03ff; \
        byte_test:2, =, var_match, 2, relative; \ 
        msg:"Byte test value matches bitmask applied on bytes extracted";)

3.2.2.23 byte_math

對提取和指定值或現有變量執行數學運算，將結果存在新的結果變量中，宮格后面選項使用，格式：

byte_math:bytes <bytes_to_extract>, offset <offset_value>, oper <operator>,
        ravalue <r_value>, result <result_variable> [, relative]
        [, endian <endian>][, string <number type>][, dce]
        [, bitmask <bitmask value>];
        
 - bytes_to_extract = 1 - 10
 - operator = '+' | '-' | '*' | '/' | '<<' | '>>'
 - r_value = 0 - 4294967295 | byte extract variable
 - offset_value = -65535 to 65535
 - bitmask_value = 1 to 4 byte hexadecimal value
 - result_variable = Result Variable name

3.2.2.24 ftpbounce

檢測FTP bounce attacks，格式：ftpbounce;

3.2.2.25 asn1

ASN.1檢測插件解碼數據包或者數據包的一部分，查找惡意代碼，多個asn1選項之間是or的關系，命中其中一個，整個選項命中，格式：

asn1:[bitstring_overflow][, double_overflow][, oversize_length <value>][, absolute_offset <value>|relative_offset <value>];

3.2.2.26 cvs

CVS檢測插件有助於檢測：Bugtraq-10384,CVE-2004-0396:"變形條目修改和未改變標志插入"，格式：

cvs:<option>; option:invalid-entry,查找無效的條目字符串

3.2.3 non-payload detection rule options

3.2.3.1 fragoffset

比較IP首部的片偏移值是否滿足和設定的值是否滿足關系，格式：

fragoffset:[!|<|>]<number>;

3.2.3.2 ttl

檢測IP首部的8位生存時間字段，格式：

ttl:[<, >, =, <=, >=]<number>

ttl:[<number>]-[<number>];

3.2.3.3 tos

檢測IP首部的TOS字段（8位TOS包括3位現已被忽略的優先權子字段，1位必須置零的未用位，另外4為分別表示：最小時延、最大吞吐量、最高可靠性和最小費用，4為均為0代表一般服務），格式：

tos:[!]<number>;

3.2.3.4 id

檢測IP首部的id字段（16位標識），格式：

id:<number>;

3.2.3.5 ipopts

用來查找IP首部的選項字段，是否設置了一些特定的IP選項，需要注意的是每個規則只能設置一個ipopts關鍵字

• rr Record route（記錄路由）
• eol End of list（列表結尾）
• nop No op（無操作）
• ts Time Stamp（時間戳）
• sec IP security（IP安全選項）
• esec IP Extended Security
• lsrr Loose source routing（松散源路由）
• ssrr Strict source routing（嚴格源路由）
• satid Stream identifier（流標示符）
• any Any IP options are set

格式：

ipopts:<rr|eol|nop|ts|sec|esec|lsrr|lsrre|ssrr|satid|any>;

3.2.3.6 fragbits

檢測IP首部的3位和分片有關的標志位，M-更多分片（除最后一篇均置1），D-不分片，R-保留位，snort提供了一些修改匹配條件的修飾符："+"代表匹配設定值及其他任意值，"*"代表匹配任意設定值（or），"~"非。格式：

fragbits:[+*!]<[MDR]>;

示例：

fragbits:MD+;

3.2.3.7 dsize

用來檢測數據包載荷大小，可用於檢查可能導致緩沖區溢出的異常大小的數據包。格式：

dsize:min<>max
dsize:[<|>]<number>;

3.2.3.8 flags

檢查是否存在特定的TCP標志位，可以添加的修飾符同樣有"+""*""!"，可以檢查以下位：

• F FIN
• S SYN
• R RST
• P PSH
• A ACK
• U URG
• C CWR
• E ECE
• 0 No TCP Flags Set

格式：

flags:[!|*|+]<FSRPAUCE0>[, <FSRPAUCE>];

3.2.3.9 flow

flow關鍵字與session tracking結合使用，它允許規則值應用於特定方向的數據流，允許規則只應用與客戶端或者服務端，選項值有：

• to_client 服務器響應從A到B時觸發
• to_server 客戶端請求從A到B時觸發
• from_client 客戶端請求從A到B時觸發
• from_server 服務器響應從A到B時觸發
• established 只觸發已經建立的TCP連接
• stateless 不管流處理器的狀態都觸發
• no_stream 不在重組的流數據包上觸發（對dsize和stream5有用）
• only_stream 只在重組的流數據上觸發
• no_frag 不在重組的片數據包觸發
• only_frag 只在重組的片數據包觸發

格式：

flow:[(established|not_established|stateless)]
        [,(to_client|to_server|from_client|from_server)]
        [,(no_stream|only_stream)]
        [,(no_frag|only_frag)];

3.2.3.10 seq

檢測TCP首部的32位序號字段
格式：

seq:<number>;

3.2.3.11 ack

檢測TCP首部的32位確認序號字段
格式：

ack:<number>;

3.2.3.12 window

檢測TCP首部的16位窗口大小字段（接收端期望接收的字節大小）

3.2.3.13 itype

檢測ICMP首部的8位類型字段
格式：

itype:min<>max
itype:[<|>]<number>;

3.2.3.14 icode

檢測ICMP首部的8位代碼字段，不同的類型和字段代表，代表不同的ICMP類型的報文，格式：

icode:min<>max;
icode:[<|>]<number>;

3.2.3.15 id

檢測ICMP首部的id（標識符字段，並不是所有ICMP報文都有），格式：

icmp_id:<number>;

3.2.3.16 seq

檢測ICMP首部的序列號字段（部分ICMP報文有），格式：

icmp_seq:<number>;

3.2.3.17 rpc

用於檢查SUNRPC CALL請求中的PRC應用程序，版本號，程序編號，通配符"*"對版本和程序標號都有效，格式：

rpc:<application number>, [<version number>|*], [<procedure number>|*];

3.2.3.18 ip_proto

檢查IP的協議頭，格式：

ip_proto:[!|>|<] <name or number>;

3.2.3.19 sameip

檢查源IP和目的IP是否一致，示例：

alert ip any any -> any any (sameip;)

3.2.3.20 stream_reassemble

對TCP流重組進行設置，允許規則在匹配流量時，啟用或者禁用流重組，格式：

stream_reassemble:<enable|disable>, <server|client|both>[, noalert][, fastpath]

其中noalert，設定不報警，fastpath參數使snort忽略連接的其他部分

3.2.3.21 stream_size

匹配指定長度的TCP流，格式：

stream_size:<server|client|both|either>, <operator>, <number>;

3.2.4 post-detection rule options

3.2.4.1 logto

將觸發規則的數據包記錄到指定的輸出日志文件，snort處於二進制日志記錄模式時，次選項不起作用，格式：

logto:"filename";

3.2.4.2 session

用於從TCP會話中提取用戶數據，在很多情況下，查看用戶在telnet，ftp或者web會話找那個嵌入什么是很有用的，有三個可選關鍵字（printable、binary、all）printable關鍵字只打印能夠被用戶正常看到和打印的數據，bindary關鍵字打印二進制數據，all關鍵字以等效的十六進制打印不可打印字符，格式：

session:[printable|bindary|all];

示例：
記錄telnet保重所有可打印字符串。

log tcp any any <> any 23 (session:printable;)

給定端口12345上的FTP數據會話，本示例以為禁止形式記錄有效負載字節。

log tcp any any <> any 12345 (metadata:service ftp-data; session:binary;)

警告：
使用sesion管家在你可能會大大降低Snort的速度，因此不應該在高負載情況下使用它。session關鍵字最適合處理二進制（pcap）日志文件
關鍵字"bindary"不會記錄任何應用層以下的協議頭，當記錄重新組裝的包時，流重新組裝將導致重復數。

3.2.4.3 resp

啟動結束違規會話的主動響應，該響應可以消除干擾會話，可在被動和內聯模式使用，在向目標主機發送多種響應數據包時，這些選項組合使用，多個參數之間使用逗號分隔。該插件合法的參數如下：

• rst_snd 向發送方發送TCP-RST數據包
• rst_rcv 向接受方發送TCP-RST數據包
• rst_all 向收發雙方發送TCP_RST數據包
• icmp_net 向發送方發送ICMP_NET_UNREACH
• icmp_host 向發送方發送ICMP_HOST_UNREACH
• icmp_port 向發送方發送ICMP_PORT_UNREACH
• icmp_all 向發送方發送上述所有的ICMP數據包

3.2.4.4 react

支持主動響應，其中包括向客戶端發送網頁或其他內容，然后關閉連接。用於被動和內聯模式，react和resp都有可能使snort陷入死循環，要注意使用。
這個選項包括如下的基本修飾詞：

• block 關閉連接並且發送一個通知
• warm 發送明顯的警告信息

基本修飾詞可以和如下的附加修飾詞組合使用，大量的附加修飾詞由逗號隔開，react關鍵字將被放在選項的最后一項：

• msg 把msg選項的內容包含進阻塞通知信息中
• proxy 使用代理端口發送通知信息

示例：

alert tcp any any <> 192.168.1.0/24 80 (content:"bad.html"; msg:"Not for Children!"; react:block,msg;)

3.2.4.5 tag

tag關鍵字允許規則記錄多個觸發規則的數據包，一旦一個規則被觸發，涉及源和/或目標主機的額外流量將被標記。記錄標記的流量，以允許分析響應代碼和攻擊后流量。帶標記的警報將被發送到與原始警報相同的輸出插件，但是正確處理這些特殊警報是輸出插件的責任，格式：

tag:host, <count>, <metric>, <direction>;
tag:session[, <count>, <metric>][, exclusive];
 - host     記錄從激活標記的主機來的數據包
 - session  記錄觸發這條規則的會話的數據包
 - count    記錄數量，和metric單位配合
 - metric
    - packets   為主機/會話標記<count>數據包
    - seconds   為主機/會話標記<count>秒
    - bytes     為主機/會話標記<count>字節
 - direction
    - src       標記包，其中包含生成初始事件的包的源IP地址，僅host類型時可用
    - dst       標記包，包含產生初始事件的包的目的IP地址，僅host類型可用
 - exclusive    僅在第一個匹配會話中標記數據包，session類型可用，具有此選項的session類型tag不需要計數和單位參數，而用於獲取完整會話

注意：
1、后續的警報和事件過濾器都不會阻止標記包被記錄。隨后的標記警報將導致限制重置。

alert tcp any any <> 10.1.1.1 any 
    (flowbits:isnotset,tagged;content:"foorbar";nocase;
    flowbits:set,tagged;tag:host,600,seconds,src;)

2、如果在使用"數據包"以外的度量的規則中有標記選項，那么將使用tagged_packet_limit來限制已標記的數據包的數量，而不管是否達到了秒或字節計數。默認的tagged_packet_limit值為256，可以通過使用snort.conf文件中的config選線修改tagged_packet_limit配置選項。您可以禁用則包限制為特定規則通過添加一個"包"度量你的標簽選項，其計數設置為0（可以在全球范圍通過數字tagged_packet_limit在snort.conf中選擇0）。這樣做將確保數據包標記的全額秒或字節，不會得切換為tagged_packet_limit。（注意，tagged_packet_limit的引入是為了避免在高帶寬傳感器上對具有高"秒"或"字節"計數的標記規則使用DOS的情況。）

alert tcp 10.1.1.4 any -> 10.1.1.1 any
    (content:"TAGMYPACKETS";tag:host,0,packets,600,seconds,src;)

示例：
該示例記錄任何telnet會話的前10秒或"tagged_packet_limit"(無論哪個先出現)

alert tcp any any -> any 23 (flags:S,CE; tag:session,10,seconds;)

需要tag:host至少需要一個計數和度量，但是沒有任何度量的tag:session可以用來獲得完整的會話，如下所示：

pass tcp any any -> 192.168.1.1 80 (flags:S;tag:session,exclusive;)

3.2.4.6 replace

replace在內聯模式下可用，可以用提供的字符串和之前匹配的字符換進行替換，新字符串和要替換的內容必須具有相同的長度，一個規則可以有多個替換，每個內容對應一個，格式：

replace:"<string>";

3.2.4.7 detection_filter

detection_filter定義了一個速率，在規則生成事件之前，源主機或目標主機必須超過這個速率。detection_filter的格式如下：

detection_filter:track <by_src|by_dst>,count <c>, seconds <s>;

• track 跟蹤方向，by_src 源防線，by_dst 目的方向
• count 超過檢測篩選器限制之前允許的最大規則匹配數（以秒為單位），C必須是非零的。
• seconds 累計計數的時間周期，該值必須是非零的。

Snort在評估所有其他規則選項（與過濾器在規則源中的位置無關）之后，將detection_filter作為檢測階段的最后一步進行評估，每個規則最多運行一個detection_filter。

示例：
在一個60秒的采樣周期內，在第一次30次失敗的登錄嘗試之后，該規則將在10.1.2.100開始的每一次失敗的登錄嘗試上觸發：

drop tcp 10.1.2.100 any > 10.1.1.100 22 (
    msg:"SSH Brute Force Attempt";
    flow:established,to_server;
    content:"SSH"; nocase; offset:0; depteh:4;
    detection_filer:track by_src, count 30, seconds 60;
    sid:1000001; rev:1;)

因為可以會生成許多事件，所以detection_filter通常會與event_filter一起使用，以減少記錄的事件數量。