3.3 Snort Payload檢測規則選項

3.3.1 內容

content關鍵字是Snort更重要的功能之一。它允許用戶設置規則以搜索數據包payload中的特定內容，并基于該數據觸發響應。每當執行內容選項模式匹配時，就會調用Boyer-Moore模式匹配功能，并針對數據包內容執行（在計算上比較昂貴）測試。如果數據包的payload中的任何位置都包含與參數數據字符串完全匹配的數據，則測試成功，并且將執行其余的規則選項測試。請注意，此測試區分大小寫。

content關鍵字的選項數據有些復雜。它可以包含混合文本和二進制數據。二進制數據通常包含在豎線（|）字符內，并表示為字節碼。字節碼將二進制數據表示為十六進制數字，并且是描述復雜二進制數據的簡便快捷方法。下面的示例顯示在Snort規則中混合文本和二進制數據的使用。

注意，可以在一個規則中指定多個內容規則。這使得可以針對較少的誤報量身定制規則。

如果規則前面有！，則將在不包含此內容的數據包上觸發警報。當編寫規則以警告不符合特定模式的數據包時，這很有用

注意：另請注意，以下字符必須在內容規則中轉義： ; "

3.3.1.1 格式

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

3.3.1.2 例子

    alert tcp any any -> any 139 (content:"|5c 00|P|00|I|00|P|00|E|00 5c|";)

    alert tcp any any -> any 80 (content:!"GET";)

注意： A ！修飾符可否定整個內容搜索的結果，包括修飾符。例如，如果使用content：！“A”; within 50并且只有3個字節的payload，并且這5個字節中沒有“ A”，結果將返回一個匹配項。如果必須有30個字節才能有效匹配，請使用 isdataat作為內容的前兆。 |

3.3.1.3 改變內容行為

content的關鍵字有許多修改關鍵字。Modify關鍵字更改了先前指定內容的工作方式。這些修飾詞關鍵字是：

nocase
rawbytes
depth
offset
distance
within
http_client_body
http_cookie
http_raw_cookie
http_header
http_raw_header
http_method
http_uri
http_raw_uri
http_stat_code
http_stat_msg
fast_pattern

3.3.2 protected_content

protected_content關鍵字提供了content關鍵字的許多功能，但是它的執行和使用方式非常不同。與內容相比，protected_content的主要優勢在于，protected允許通過僅顯示所述內容的安全哈希摘要來隱藏目標內容。與content關鍵字一樣，其主要目的是匹配特定字節的字符串。通過對輸入數據包的部分進行哈希處理并將結果與所提供的哈希進行比較來執行搜索，因此，這在計算上是昂貴的。

當前，可以將MD5，SHA256和SHA512哈希算法與protected_content關鍵字一起使用。如果未在Snort配置中設置默認值，則必須在規則中使用哈希指定哈希算法。此外，必須指定長度修飾符并加保護以指示原始數據的長度。

與內容一樣，可以在一個規則中使用多個protected_content規則。此外，可以將多個protected_content規則與多個內容規則混合使用。

如果規則前面有！，則將在不包含目標內容的數據包上觸發警報。當編寫規則以警告不符合特定模式的數據包時，這很有用

注意： protected_content關鍵字可以與某些（但不是全部）內容修飾符一起使用。不支持的功能包括： nocase,fast_pattern,depth,within

3.3.2.1 格式

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

3.3.2.2 例子

關于字符串“ HTTP”的以下警報：

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

    alert tcp any any <> any 80 (msg:"SHA256 Alert"; 
    protected_content:"56D6F32151AD8474F40D7B939C2161EE2BBF10023F4AF1DBB3E13260EBDC6342"; 
    hash:sha256; offset:0; length:4;)

注意： A ！修飾符可否定整個內容搜索的結果，包括修飾符。例如，如果使用content：！“ A”; within 50并且只有3個字節的有效負載，并且這5個字節中沒有“ A”，結果將返回一個匹配項。如果必須有30個字節才能有效匹配，請使用 isdataat作為內容的前兆。

3.3.3 哈希

hash關鍵字用于指定匹配protected_content規則時要使用的哈希算法。如果在Snort配置中未指定默認算法，則protected_content規則必須指定所使用的算法。當前，支持MD5，SHA256和SHA512。

3.3.3.1 格式

hash:[md5|sha256|sha512];

3.3.4 長度

length關鍵字用于指定protected_content規則摘要中指定的內容的原始長度。提供的值必須大于0且小于65536。

3.3.4.1種格式

length:[<original_length>];

3.3.5 nocase

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

3.3.5.1 格式

nocase

3.3.5.2 例子

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

3.3.6 rawbytes

rawbytes關鍵字允許規則查看原始數據包數據，而忽略預處理器進行的任何解碼。這充當了上一個content選項的修飾符。

HTTP Inspect具有一組使用原始數據的關鍵字，例如 http_raw_cookie，http_raw_header，http_raw_uri等，它們與原始HTTP請求和響應的特定部分匹配。

如果未顯式指定rawbytes，則默認情況下，大多數其他預處理器都會使用解碼/規范化的數據進行內容匹配。因此，應指定rawbytes以檢查數據包中的任意原始數據。

3.3.6.1 格式

rawbytes

3.3.6.2 例子

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

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

3.3.7 depth

depth關鍵字允許規則編寫者指定Snort應該在包中搜索指定模式的距離。depth修改了規則中先前的“ content”關鍵字。

深度為5會使Snort僅在payload的前3個字節內查找指定的模式。

由于depth關鍵字是以前的content關鍵字的修飾符，因此在指定depth之前，規則中必須有內容。

此關鍵字允許值大于或等于要搜索的模式長度。最小允許值為1。此關鍵字的最大允許值為65535。

該值也可以設置為引用同一規則中由byte_extract關鍵字提取的變量的字符串值。

3.3.7.1 格式

depth:[<number>|<var_name>];

3.3.8 offset

offset關鍵字允許規則編寫器指定從何處開始搜索數據包中的模式。offset修改規則中的上一個“ content”關鍵字。

偏移量5會告訴Snort在payload的前3個字節之后開始尋找指定的模式。

由于此關鍵字是先前內容關鍵字的修飾符，因此在指定offset之前規則中必須有內容。

此關鍵字允許輸入-65535到65535之間的值。

該值也可以設置為引用同一規則中由byte_extract關鍵字提取的變量的字符串值。

3.3.8.1 格式

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

3.3.8.2例子

以下示例顯示了組合使用的內容，偏移量和深度搜索規則。

alert tcp any any -> any 80 (content:"cgi-bin/phf"; offset:4; depth:20;)

3.3.9 distance

distance關鍵字使規則編寫者可以指定Snort在開始搜索相對于先前模式匹配末尾的指定模式之前應忽略的包數。

可以認為這與offset完全一樣，只是它與最后一個模式匹配的末尾有關，而不是與數據包的開頭有關。

此關鍵字允許輸入-65535到65535之間的值。

該值也可以設置為引用同一規則中由byte_extract關鍵字提取的變量的字符串值。

3.3.9.1 格式

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

3.3.9.2 例子

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

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

3.3.10 within

within關鍵字是一個內容修飾符，它使用content關鍵字確保在模式匹配之間最多N個字節。它被設計為與distance規則選項結合使用。

此關鍵字允許大于或等于要搜索的圖案長度的值。此關鍵字的最大允許值為65535。

該值也可以設置為引用同一規則中由byte_extract關鍵字提取的變量的字符串值。

3.3.10.1 格式

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

3.3.10.2 例子

此規則限制對EFG的搜索不要超過ABC匹配超過10個字節。

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

3.3.11 http_client_body

http_client_body關鍵字是一個內容修飾符，用于將搜索限制為HTTP客戶端請求的正文。

由于此關鍵字是先前內容關鍵字的修飾符，因此在指定“ http_client_body”之前，規則中必須有內容。

使用此選項檢查的數據量取決于HttpInspect 的post_depthconfig 選項。當post_depth設置為-1 時，與此關鍵字匹配的模式將不起作用。

3.3.11.1 格式

http_client_body;

3.3.11.2 例子

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

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

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

3.3.12 http_cookie

http_cookie關鍵字是一個內容修飾符，它將搜索范圍限制為HTTP客戶端請求或HTTP服務器響應（根據HttpInspect的配置）提取的Cookie標頭字段（標頭名稱本身和終止標頭行的CRLF除外）。Cookie緩沖區不包含標頭名稱（Cookie：用于HTTP請求或Set-Cookie：用于HTTP響應）或前導空格和CRLF終止標頭行。這些包含在HTTP標頭緩沖區中。

由于此關鍵字是先前內容關鍵字的修飾符，因此在指定http_cookie之前，規則中必須有內容。此關鍵字取決于enable_cookie config選項。僅當配置此選項時，才會提取Cookie標題字段。如果未指定enable_cookie，則cookie仍然以HTTP標頭結尾。

根據HttpInspect的配置，提取的Cookie標題字段可以進行標準化。

3.3.12.1 格式

http_cookie;

3.3.12.2 例子

此規則將對模式“ EFG”的搜索限制為HTTP客戶端請求的提取的Cookie標頭字段。

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

注意：對于相同的內容，不允許將http_cookie修飾符與 rawbytes或fast_pattern修飾符一起使用。

3.3.13 http_raw_cookie

http_raw_cookie關鍵字是一個內容修飾符，用于將搜索限制為HTTP客戶端請求或HTTP服務器響應（根據HttpInspect的配置）的提取的UNNORMALIZED Cookie Header字段。

由于此關鍵字是以前的內容關鍵字的修飾符，因此在指定http_raw_cookie之前，規則中必須有內容。此關鍵字取決于enable_cookie config選項。僅當配置此選項時，才會提取Cookie標題字段。

3.3.13.1 格式

http_raw_cookie;

3.3.13.2 例子

此規則將對模式“ EFG”的搜索限制為HTTP客戶端請求的提取的Unnormalized Cookie Header字段。

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

注意：對于相同的內容，不允許將http_raw_cookie修飾符與 rawbytes，http_cookie或fast_pattern修飾符一起使用。

3.3.14 http_header

http_header關鍵字是一個內容修飾符，用于將搜索限制為HTTP客戶端請求或HTTP服務器響應（根據HttpInspect的配置）的提取的Header字段。

由于此關鍵字是先前內容關鍵字的修飾符，因此在指定http_header之前，規則中必須有內容。

根據HttpInspect的配置，提取的Header字段可以進行標準化。

3.3.14.1 格式

http_header;

3.3.14.2 例子

此規則將對模式“ EFG”的搜索限制為HTTP客戶端請求或HTTP服務器響應的提取的Header字段。

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

3.3.13 http_raw_header

http_raw_header關鍵字是一個內容修飾符，用于將搜索限制為HTTP客戶端請求或HTTP服務器響應（根據HttpInspect的配置）的提取的UNNORMALIZED Header字段。

由于此關鍵字是先前內容關鍵字的修飾符，因此在指定http_raw_header之前，規則中必須有內容。

3.3.13.1 格式

http_raw_header;

3.3.13.2 例子

此規則將對模式“ EFG”的搜索限制為HTTP客戶端請求或HTTP服務器響應的提取的Header字段。

alert tcp any-> any 80（content：“ ABC”；content：“ EFG”； http_raw_header;）

3。3。16 http_method

關鍵字http_method是一個內容修飾符，它將搜索限制為從HTTP客戶端請求中提取的Method。

由于此關鍵字是先前內容關鍵字的修飾符，因此在指定http_method之前，規則中必須有內容。

3.3.16.1 格式

http_method;

3.3.16.2 例子

此規則將對模式“ GET”的搜索限制為從HTTP客戶端請求中提取的方法。

alert tcp any-> any 80（content：“ ABC”；content：“ GET”； http_method;）

3.3.17 http_uri

http_uri關鍵字是一個內容修飾符，用于將搜索限制為NORMALIZED請求URI字段。使用內容規則選項后跟http_uri修飾符與使用uricontent本身相同。

由于此關鍵字是先前內容關鍵字的修飾符，因此在指定http_uri之前，規則中必須有內容。

3.3.17.1 格式

http_uri;

3.3.17.2 例子

該規則將對模式“ EFG”的搜索限制為“ NORMALIZED URI”。

alert tcp any-> any 80（content：“ ABC”；content：“ EFG”； http_uri；）

3.3.18 http_raw_uri

http_raw_uri關鍵字是一個內容修飾符，用于將搜索限制為UNNORMALIZED請求URI字段。

由于此關鍵字是先前內容關鍵字的修飾符，因此在指定http_raw_uri之前，規則中必須有內容。

3.3.18.1 格式

http_raw_uri;

3.3.18.2 例子

該規則將對模式“ EFG”的搜索限制為未規范的URI。

alert tcp any-> any 80（content：“ ABC”；content：“ EFG”； http_raw_uri；）

注意：對于相同的內容，不允許將http_raw_uri修飾符與 rawbytes，http_uri或fast_pattern修飾符一起使用。

3.3.19 http_stat_code

http_stat_code關鍵字是一個內容修飾符，用于將搜索限制為從HTTP服務器響應中提取的狀態代碼字段。

由于此關鍵字是先前內容關鍵字的修飾符，因此在指定http_stat_code之前，規則中必須有內容。

僅當為HttpInspect配置了extended_response_inspection時，才會提取“狀態代碼”字段。

3.3.19.1 格式

http_stat_code;

3.3.19.2 例子

該規則將對模式“ 200”的搜索限制為HTTP服務器響應的提取的“狀態代碼”字段。

alert tcp any-> any 80（content：“ ABC”；content：“ 200”； http_stat_code;）

注意：對于相同的內容，不允許將http_stat_code修飾符與 rawbytes或fast_pattern修飾符一起使用。

3.3.20 http_stat_msg

關鍵字http_stat_msg是一個內容修飾符，用于將搜索限制為從HTTP服務器響應中提取的狀態消息字段。

由于此關鍵字是先前內容關鍵字的修飾符，因此在指定http_stat_msg之前，規則中必須有內容。

僅當為HttpInspect配置了extended_response_inspection時，才會提取“狀態消息”字段。

3.3.20.1 格式

http_stat_msg;

3.3.20.2 例子

此規則將對模式“未找到”的搜索約束到HTTP服務器響應的提取的“狀態消息”字段中。

alert tcp any-> any 80（content：“ ABC”；content：“Not Found”； http_stat_msg；）

注意:對于相同的內容，不允許將http_stat_msg修飾符與 rawbytes或fast_pattern修飾符一起使用。

3.3.21 http_encode

該HTTP_ENCODE關鍵字將使基于在HTTP客戶端請求或（HttpInspect的配置的HTTP服務器響應編碼本類型ALERTING ）。

有幾個與http_encode關聯的關鍵字。關鍵字“ uri”，“ header”和“ cookie”確定用于搜索特定編碼類型的HTTP字段。關鍵字“ utf8”，“ double_encode”，“ non_ascii”，“ uencode”，“ iis_encode”，“ ascii”和“ bare_byte”確定將觸發警報的編碼類型。可以使用“或”運算來組合這些關鍵字。這些關鍵字可以否定。

需要打開配置選項“ normalize_headers”，規則才能與關鍵字“ header”一起使用。關鍵字“ cookie”取決于配置選項“ enable_cookie”和“ normalize_cookies”。如果指定的HTTP字段未標準化，則此規則選項將無法檢測編碼。

選項	描述
`uri`	檢查HTTP客戶端請求URI字段中指定的編碼類型。
`header`	檢查HTTP請求或HTTP響應標頭字段中的指定編碼類型（取決于數據包流）
`cookie`	檢查HTTP請求或HTTP響應cookie頭字段中的指定編碼類型（取決于數據包流）
`utf8`	檢查指定緩沖區中的utf8編碼
`double_encode`	檢查指定緩沖區中的雙重編碼
`non_ascii`	檢查指定緩沖區中的非ASCII編碼
`uencode`	檢查指定緩沖區中的u編碼
`bare_byte`	檢查指定緩沖區中的裸字節編碼
`ASCII`	檢查指定緩沖區中的ascii編碼
`iis_encode`	檢查指定緩沖區中的IIS Unicode編碼

3.3.21.1 格式

    http_encode:<http buffer type>, [!]<encoding type>
    http_encode:[uri|header|cookie], [!][<utf8|double_encode|non_ascii|uencode|bare_byte|ascii|iis_encode>];

3.3.21.2 例子

    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;)

注意：Negation（！）和OR（|）操作不能一起用于 http_encode關鍵字。OR和否定運算僅在編碼類型字段上起作用，而在http緩沖區類型字段上不起作用。

3.3.22 fast_pattern

fast_pattern關鍵字是內容修改器設置為與快速模式匹配所使用的規則中的內容。快速模式確定的默認行為是使用最長的HTTP緩沖區內容。如果不存在HTTP緩沖區，則快速模式是最長的內容。給定此行為，如果較短的內容比較長的內容更“獨特”，則很有用，這意味著較短的內容比較長的內容在包中更不可能被發現。

快速模式匹配器用于通過使用規則中的內容進行選擇來僅選擇有匹配機會的規則，并且僅在有效內容中找到該內容時才評估該規則。盡管這似乎有些開銷，但是它可以大大減少需要評估的規則數量，從而提高性能。用于快速模式匹配器的內容越好，則不必要評估規則的可能性就越小。

由于此關鍵字是先前內容關鍵字的修飾符，因此在指定fast_pattern之前，規則中必須有一個內容規則選項。該fast_pattern選項可能每個規則只有一次指定。

注：該fast_pattern：修飾符不能與下面的HTTP內容修飾符使用:HTTP_COOKIE，http_raw_uri， http_raw_header，http_raw_cookie，http_method， http_stat_code，http_stat_msg。

注意： fast_pattern修飾符只能用于否定內容，前提是這些內容沒有被使用offset、depth、distance或within進行修改。

注意： 快速模式匹配器始終不區分大小寫。

3.3.22.1 格式

fast_pattern選項可單獨使用或任意取參數。單獨使用時，其含義僅是將指定內容用作規則的快速模式內容。

fast_pattern;

可選參數僅可用于指定內容僅應用于快速模式匹配器，而不應作為規則選項進行評估。例如，如果必須將已知內容放置在有效負載中而與有效負載中的位置無關，則這很有用，因為這樣可以節省評估規則選項所需的時間。請注意，（1）修改后的內容必須不區分大小寫，因為將模式以不區分大小寫的方式插入到模式匹配器中；（2）否定的內容不能使用；（3）內容不能具有任何位置修飾符，例如offset，depth，distance 或within。

fast_pattern：only;

可選參數<offset>，<length>可用于指定僅一部分內容用于快速模式匹配器。如果圖案非常長，并且僅需要一部分圖案即可滿足“唯一性”，這將很有用，從而減少了在快速圖案匹配器中存儲整個圖案所需的內存。

fast_pattern：<offset>，<length>;

注意：可選參數和<offset>，<length>是互斥的。 |

3.3.22.2 例子

該規則使模式“ IJKLMNO”與快速模式匹配器一起使用，即使它比早期的模式“ ABCDEFGH”短。

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

此規則表示將內容“ IJKLMNO”用于快速模式匹配器，并且該內容應僅用于快速模式匹配器，而不應作為內容規則選項進行評估。

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

此規則表示將“ JKLMN”用作快速模式內容，但仍將內容規則選項評估為“ IJKLMNO”。

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

3.3.23 uricontent

Snort規則語言中的uricontent關鍵字搜索NORMALIZED請求URI字段。這等效于對內容關鍵字使用 http_uri修飾符。這樣，如果您編寫的規則包含標準化的內容（例如％2f或目錄遍歷），則這些規則將不會發出警報。原因是您要查找的內容已從URI緩沖區中標準化。

例如，URI：
/scripts/..%c0%af../winnt/system32/cmd.exe?/c+ver

將標準化為：

/winnt/system32/cmd.exe?/c+ver

另一個示例，URI：

/cgi-bin/aaaaaaaaaaaaaaaaaaaaaaaaaaaa/..%252fp%68f？

將標準化為：

/ cgi-bin / phf？

編寫uricontent規則時，請在要規范化URI的上下文中編寫要查找的內容。例如，如果Snort規范化了目錄遍歷，則不包括目錄遍歷。

您可以使用content選項編寫查找非規范化內容的規則。

uricontent可以與content關鍵字可用的幾個修飾符一起使用。這些包括：

nocase
depth
offset
distance
within
fast_pattern

該選項與Section中指定的HTTP Inspect預處理器結合使用。

3.3.23.1 格式

uricontent：[！]“ <content string>”;

注意： uricontent不能通過rawbytes修飾符或任何其他HTTP修飾符進行修改。如果要搜索UNNORMALIZED請求URI字段，請使用帶有內容選項的http_raw_uri修飾符。

3.3.24 urilen

Snort規則語言中的urilen關鍵字指定確切的長度，最小長度，最大長度或要匹配的URI長度范圍。默認情況下，將使用原始uri緩沖區。使用可選的 <uribuf>參數，可以指定使用原始緩沖區還是規范化緩沖區。

3.3.24.1 格式

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

    <uribuf> : "norm" | "raw"

以下示例將匹配5個字節長的URI：

urilen：5;

以下示例將匹配少于5個字節的URI：

urilen：<5；

以下示例將匹配大于5個字節且小于10個字節（包括10個字節）的URI：

urilen：5 <> 10;

以下示例將使用規范化的URI緩沖區匹配大于300個字節的URI：

urilen：> 300，norm;

以下示例將匹配大于300個字節的URI，這些URI明確聲明要使用原始URI緩沖區：

urilen：> 300，raw;

該選項與Section中指定的HTTP Inspect預處理器結合使用。

3.3.23 isdataat

驗證有效負載在指定位置具有數據，可以選擇查找相對于先前內容匹配末尾的數據。

3.3.23.1 格式

isdataat：[！] <int> [，relative|rawbytes]；

3.3.23.2 例子

    alert tcp any any -> any 111 (content:"PASS"; isdataat:50,relative; \ 
        content:!"|0a|"; within:50;)

此規則查找數據包中是否存在字符串PASS，然后驗證字符串PASS末尾至少有30個字節，然后驗證PASS字符串末尾的30個字節內沒有換行符。

當使用isdataat指定了rawbytes修飾符時，它將查看原始數據包數據，而忽略了預處理器進行的任何解碼。只要原始數據包數據中以前的內容匹配，此修飾符就可以與相對修飾符一起使用。

A！修飾符使isdataat測試的結果無效。如果payload中不存在一定數量的數據，它將發出警報。例如，帶有修飾符的規則content：“ foo”; isdataat：！10，relative； 會在有效負載結束之前警告“ foo”之后是否沒有10個字節。

3.3.26 pcre

pcre關鍵字允許使用與perl兼容的正則表達式編寫規則。

3.3.26.1 格式

pcre：[！]“（// <regex> / | m <delim> <regex> <delim>）[ismxAEGRUBPHMCOIDKYS]”;

后重新修飾符為正則表達式設置編譯時間標志。

下表顯示針對pcre的 Perl兼容修飾符：

i	不區分大小寫
s	在dot元字符中包含換行符
m	默認情況下，該字符串被視為一行大字符。^和$在字符串的開頭和結尾匹配。設置m時，^和$在緩沖區中的任何換行符之后或之前以及緩沖區的最開始和結尾處立即匹配。
X	模式中的空白數據字符將被忽略，除非已轉義或在字符類內部

下表顯示PCRE兼容的pcre修飾符：

A	該模式必須僅在緩沖區的開頭匹配（與^相同）
E	將$設置為僅在主題字符串的末尾匹配。如果沒有E，則$也將在最后一個字符之前（如果它是換行符）進行匹配（但不匹配任何其他換行符）。
G	反轉量詞的“greediness”，以便默認情況下它們不是貪婪的，但是如果后面跟有“？”，則變成貪婪的。

下表顯示針對pcre的 Snort特定修飾符：

R	相對于最后一個模式匹配的結尾進行匹配。（類似于距離：0;）
U	匹配解碼的URI緩沖區（類似于`uricontent`和`http_uri`）。對于相同的內容，未規范化的HTTP請求uri緩沖區修飾符（I）不允許使用此修飾符。
I	匹配未標準化的HTTP請求uri緩沖區（類似于`http_raw_uri`）。對于同一內容，HTTP請求uri緩沖區修飾符（U）不允許使用此修飾符。
P	匹配未標準化的HTTP請求正文（類似于`http_client_body`）。
	對于SIP消息，匹配SIP主體以進行請求或響應（類似于`sip_body`）。
H	匹配標準化的HTTP請求或HTTP響應標頭（類似于`http_header`）。對于同一內容，未規范化的HTTP請求或HTTP響應標頭修飾符（D）不允許使用此修飾符。
	對于SIP消息，匹配請求或響應的SIP標頭（類似于`sip_header`）。
D	匹配未標準化的HTTP請求或HTTP響應標頭（類似于`http_raw_header`）。相同內容的規范化HTTP請求或HTTP響應標頭修飾符（H）不允許使用此修飾符。
M	匹配規范化的HTTP請求方法（類似于`http_method`）
C	匹配規范化的HTTP請求或HTTP響應cookie（類似于`http_cookie`）。對于相同的內容，未規范化的HTTP請求或HTTP響應cookie修飾符（K）不允許使用此修飾符。
K	匹配未規范化的HTTP請求或HTTP響應cookie（類似于`http_raw_cookie`）。相同內容的標準化HTTP請求或HTTP響應cookie修飾符（C）不允許使用此修飾符。
S	匹配HTTP響應狀態代碼（類似于`http_stat_code`）
Y	匹配HTTP響應狀態消息（類似于`http_stat_msg`）
B	不要使用解碼后的緩沖區（類似于rawbytes）
O	覆蓋為此表達式配置的pcre匹配限制和pcre匹配限制遞歸。在評估指定的花紋圖案時，它完全忽略了限制。

注意： HTTP修飾符（例如U，I，P，H，D，M，C，K，S和Y）不允許使用修飾符R（相對）和B（原始字節）。

3.3.26.2 例子

本示例對HTTP URI foo.php？id = <some number>執行不區分大小寫的搜索

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

注意：在使用pcre的規則中至少有一個content關鍵字是明智的。這允許快速模式匹配器過濾掉不匹配的數據包，從而不會對通過電線的每個數據包執行pcre評估。

注意: Snort使用PCRE對多個URI的處理無法正常工作。當不使用uricontent時，PCRE僅評估第一個URI。為了使用pcre檢查所有URI，必須使用content或uricontent。

3.3.27 pkt_data

此選項將用于檢測的光標設置為原始傳輸有效負載。

任何相對或絕對內容匹配（沒有HTTP修飾符或rawbytes）以及規則中遵循pkt_data的其他有效負載檢測規則選項將應用于原始TCP / UDP有效負載或規范化的緩沖區（對于telnet，smtp規范化），直到游標（用于檢測）再次設置。

該規則選項可以在規則中多次使用。

3.3.27.1 格式

pkt_data;

3.3.27.2 例子

        alert tcp any any -> any any(msg:"Absolute Match"; pkt_data; content:"BLAH"; offset:0; depth:10;)
        alert tcp any any -> any any(msg:"PKT DATA"; pkt_data; content:"foo"; within:10;)
        alert tcp any any -> any any(msg:"PKT DATA"; pkt_data; content:"foo";)
        alert tcp any any -> any any(msg:"PKT DATA"; pkt_data; pcre:"/foo/i";)

3.3.28 file_data

此選項將用于檢測的游標設置為以下緩沖區之一：1.當檢測到的流量為HTTP時，它將緩沖區設置為a。HTTP響應主體（無分塊/壓縮/規范化）b。HTTP解塊響應主體c。HTTP解壓縮的響應主體d（當打開inspect_gzip時）。HTTP標準化響應正文（當啟用normalized_javascript時）e。HTTP UTF標準化響應正文（當normalize_utf打開時）f。以上所有這些2.當檢測到的流量是SMTP / POP / IMAP時，它將緩沖區設置為a。SMTP / POP / IMAP數據主體（包括關閉解碼時的電子郵件標頭和MIME）b。Base64解碼的MIME附件（當b64_decode_depth時大于-1）c。未編碼的MIME附件（當bitenc_decode_depth大于-1時）d。帶引號的可打印解碼的MIME附件（當qp_decode_depth大于-1時）e。Unix到Unix解碼的附件（當uu_decode_depth大于-1時）3.如果未由1和2設置，則將其設置為有效負載。

規則中file_data之后的任何相對或絕對內容匹配（沒有HTTP修飾符或rawbytes）和payload檢測規則選項將應用于此緩沖區，直到由其他規則選項明確重置為止。

該規則選項可以在規則中多次使用。

這個mime到file_data已被棄用。規則選項file_data本身將指向已解碼的MIME附件。

3.3.28.1 格式

file_data;

3.3.28.2 例子

alert tcp any any -> any any(msg:"Absolute Match"; file_data; content:"BLAH"; offset:0; depth:10;)
alert tcp any any -> any any(msg:"FILE DATA"; file_data; content:"foo"; within:10;)
alert tcp any any -> any any(msg:"FILE DATA"; file_data; content:"foo";)
alert tcp any any -> any any(msg:"FILE DATA"; file_data; pcre:"/foo/i";)

The following rule searches for content "foo" within the file_data buffer and content "bar" within the 
entire packet payload. The rule option pkt_data will reset the cursor used for detection to the 
TCP payload.
alert tcp any any -> any any(msg:"FILE DATA"; file_data; content:"foo"; pkt_data; content:"bar";)

3.3.29 base64_decode

此選項用于解碼base64編碼的數據。在HTTP標頭（例如HTTP授權標頭）的情況下，此選項特別有用。此選項在解碼之前先展開數據。

3.3.29.1 格式

base64_decode [：[bytes <bytes_to_decode>] [，] [offset <offset> [，relative]]];

選項	描述
`bytes`	要解碼的base64編碼字節數。此參數僅采用正值和非零值。如果未指定此選項，我們將尋找base64編碼的數據，直到到達標題行的末尾或到達數據包payload的末尾。
`offset`	當 `relative` 選項確定的偏移相對于doe_ptr指定或相對于該分組的payload的開始來開始編碼數據的base64的檢查。此參數僅采用正值和非零值。
`relative`	指定對base64編碼數據的檢查是相對于doe_ptr的。

上面base64_decode參數是可選的。

注意：此選項可以擴展到具有類似于HTTP折疊功能的協議。如果沒有折疊，當我們看到回車符或換行符或兩者都沒有空格或制表符時，對base64編碼數據的搜索將結束。此選項需要與base64_data結合使用，以便其他任何有效負載檢測規則選項都可以在base64解碼緩沖區上工作。

3.3.29.2 例子

    alert tcp $EXTERNAL_NET any -> $HOME_NET any
    (msg:"Base64 Encoded Data"; base64_decode; base64_data;
    content:"foo bar"; within:20;)

    alert tcp $EXTERNAL_NET any -> $HOME_NET any
    (msg:"Authorization NTLM"; content:"Authorization: NTLM";
    base64_decode:relative; base64_data; content:"NTLMSSP"; )

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

3.3.30 base64_data

此選項與規則選項file_data相似，用于將用于檢測的游標設置為base64解碼緩沖區（如果存在）的開頭。

此選項不帶任何參數。需要在base64_data選項之前指定規則選項base64_decode。

3.3.30.1 格式

base64_data;

如果存在base64解碼緩沖區，則此選項匹配。

注意：此緩沖區不允許快速模式內容匹配。

3.3.30.2 例子

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

3.3.31 byte_test

針對特定值測試字節字段（使用運算符）。能夠測試二進制值或將代表字節字符串轉換為等效的二進制字符串并進行測試。

3.3.31.1 格式

    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
    bitmask_value    = 1 to 4 byte hexadecimal value

選項	描述
`bytes_to_convert`	從數據包中提取的字節數。不使用`dce`時允許的值為1到10 。如果與`dce`一起使用，則允許值為1、2和4。
`operator`	執行測試值的操作：- <-小于;- >-大于;- <=-小于或等于;- > =-大于或等于;- =-相等;- ＆-按位與;- ^-按位或
`value`	用于測試轉換后的值的值
`offset`	有效負載中開始處理的字節數
`relative`	使用相對于上一個圖案匹配的偏移量
`endian`	要讀取的數字的字節序類型：- `big` -過程數據作為大端（默認）;- `little` -處理小尾數形式的數據
`string`	數據以字符串格式存儲在數據包中
`number type`	讀取的號碼類型：- `hex` -轉換后的字符串數據以十六進制表示,- `dec-`轉換后的字符串數據以十進制表示,- `oct-`轉換后的字符串數據以八進制表示
`dce`	讓DCE / RPC 2預處理器確定要轉換的值的字節順序。
`bitmask`	將AND運算符應用于轉換后的字節。結果將右移等于掩碼中尾隨零的位數。

任何運算符也可以包括！檢查運算符是否為真。如果！不指定任何運算符，則將該運算符設置為=。

注意： Snort對每個這些運算符使用C運算符。如果使用＆運算符，則與使用if（data＆value）{do_something（）;}相同.

3.3.31.2 例子

    alert udp $EXTERNAL_NET any -> $HOME_NET any
        (msg:"AMD procedure 7 plog overflow";
        content:"|00 04 93 F3|";
        content:"|00 00 00 07|"; distance:4; within:4;
        byte_test:4, >, 1000, 20, relative;)

    alert tcp $EXTERNAL_NET any -> $HOME_NET any
        (msg:"AMD procedure 7 plog overflow";
        content:"|00 04 93 F3|";
        content:"|00 00 00 07|"; distance:4; within:4;
        byte_test:4, >, 1000, 20, relative;)

    alert udp any any -> any 1234
        (byte_test:4, =, 1234, 0, string, dec;
        msg:"got 1234!";)

    alert udp any any -> any 1235
        (byte_test:3, =, 123, 0, string, dec;
        msg:"got 123!";)

    alert udp any any -> any 1236
        (byte_test:2, =, 12, 0, string, dec;
        msg:"got 12!";)

    alert udp any any -> any 1237
        (byte_test:10, =, 1234567890, 0, string, dec;
        msg:"got 1234567890!";)

    alert udp any any -> any 1238
        (byte_test:8, =, 0xdeadbeef, 0, string, hex;
        msg:"got DEADBEEF!";)

    alert tcp any any -> any any
        (byte_test:2, =, 568, 0, bitmask 0x3FF0;
        msg:"got 568 after applying bitmask 0x3FF0 on 2 bytes extracted";)

3.3.32 byte_jump

byte_jump關鍵字允許為長度編碼的協議編寫規則。通過具有讀取一部分數據長度的選項，然后跳過該數據包中的該長度，可以編寫規則來跳過長度編碼協議的特定部分，并在非常特定的位置執行檢測。

該byte_jump選項通過讀取一定數量的字節，這樣做，將它們轉換為他們的數字表示，此舉多少字節向前，并為后來的檢測的指針。該指針稱為檢測偏移量結束指針或doe_ptr。

3.3.32.1 格式

    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
    post_offset       = -65535 to 65535
    bitmask_value     = 1 to 4 bytes hexadecimal value

選項	描述
`bytes_to_convert`	從數據包中提取的字節數。不使用`dce`時允許的值為1到10 。如果與`dce`一起使用，則允許值為1、2和4。如果與`from_end`參數一起使用，則bytes_to_convert可以為0。如果bytes_to_convert為0，則提取的值為0。
`offset`	有效負載中開始處理的字節數
`relative`	使用相對于上一個圖案匹配的偏移量
`multiplier<value>`	將計算的字節數乘以 `<value>`然后向前跳過該字節數。
`big`	將數據處理為大端（默認）
`little`	處理小端數據
`string`	數據以字符串格式存儲在數據包中
`hex`	轉換后的字符串數據以十六進制表示
`dec`	轉換后的字符串數據以十進制表示
`oct`	轉換后的字符串數據以八進制表示
`align`	將轉換后的字節數四舍五入到下一個32位邊界
`from_beginning`	從數據包有效負載的開始而不是從數據包中的當前位置向前跳過。
`from_end`	跳轉將從payload的結尾開始
`post_offset<value>`	應用其他跳轉選項后，按字節的值向前或向后（負值的正數）跳過。
`dce`	讓DCE / RPC 2預處理器確定要轉換的值的字節順序。
`bitmask`	將AND運算符應用于`bytes_to_convert` 參數。結果將右移等于掩碼中尾隨零的位數。

3.3.32.2 例子

    alert udp any any -> any 32770:34000 (content:"|00 01 86 B8|";
        content:"|00 00 00 01|"; distance:4; within:4;
        byte_jump:4, 12, relative, align;
        byte_test:4, >, 900, 20, relative;
        msg:"statd format string buffer overflow";)

    alert tcp any any -> any any (content:"Begin";
        byte_jump:0, 0, from_end, post_offset -6;
        content:"end.."; distance:0; within:5;
        msg:"Content match from end of the payload";)

    alert tcp any any -> any any (content:"catalog";
        byte_jump:2, 1, relative, post_offset 2, bitmask 0x03f0;
        byte_test:2, =, 968, 0, relative;
        msg:"Bitmask applied on the 2 bytes extracted for byte_jump";)

    alert tcp any any -> any any (content:"catalog";
        byte_jump:1, 2, from_end, post_offset -5, bitmask 0x3c;
        byte_test:1, =, 106, 0, relative;
        msg:"Byte jump calculated from end of payload after bitmask applied";)

3.3.33 byte_extract

byte_extract關鍵字是編寫針對長度編碼協議規則的另一個有用的選項。它從數據包payload中讀取一定數量的字節，并將其保存到變量中。這些變量可以在規則的后面引用，而不是使用硬編碼的值。

注意：每個規則只能創建兩個byte_extract變量。可以在同一規則中多次重復使用它們。

3.3.33.1 格式

    byte_extract:<bytes_to_extract>, <offset>, <name> [, relative] \
        [, multiplier <multiplier value>][, <endian>][, string][, hex][, dec][, oct] \
        [, align <align value>][, dce][, bitmask <bitmask>];

    bytes_to_extract = 1 - 10
    operator         = '<' | '=' | '>' | '<=' | '>=' | '&' | '^'
    value            = 0 - 4294967295
    offset           = -65535 to 65535
    bitmask_value    = 1 to 4 byte hexadecimal value

選項	描述
`bytes_to_extract`	從數據包中提取的字節數
`offset`	有效負載中開始處理的字節數
`name`	變量名。這將用于引用其他規則選項中的變量。
`relative`	使用相對于上一個圖案匹配的偏移量
`multiplier<value>`	從數據包讀取的字節乘以 `value`然后將該數字保存到變量中。
`big`	將數據處理為大端（默認）
`little`	處理小端數據
`dce`	使用DCE / RPC 2預處理器確定字節順序。必須啟用DCE / RPC 2預處理程序，此選項才能起作用。
`string`	數據以字符串格式存儲在數據包中
`hex`	轉換后的字符串數據以十六進制表示
`dec`	轉換后的字符串數據以十進制表示
`oct`	轉換后的字符串數據以八進制表示
`align<value>`	將轉換后的字節數四舍五入到下一個 `<value>-byte`邊界。`value`可以是`2`或 `4`。
`bitmask`	將AND運算符應用于`bytes_to_extract` 參數的值。結果將右移等于掩碼中尾隨零的位數。

3.3.33.2 使用byte_extract變量的其他選項

一個byte_extract規則選項本身檢測什么。它的用途是提取數據包數據以供其他規則選項使用。這是可以使用byte_extract變量的位置的列表：

規則選項	帶變量的參數
`content`/`uricontent`	`offset`, `depth`, `distance`, `within`
`byte_test`	`offset`, `value`
`byte_jump`	`offset`
`isdataat`	`offset`

3.3.33.3 例子

本示例使用兩個變量來：

從偏移量為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, var_match, relative, bitmask 0x03ff; \
        byte_test: 2, =, var_match, 2, relative; \
        msg:"Byte test value matches bitmask applied on bytes extracted";)

3.3.34 byte_math

對提取的值和指定的值或現有變量執行數學運算，并將結果存儲在新的結果變量中。這些結果變量可以在規則的后面引用，而不是使用硬編碼的值。

3.3.34.1 格式

    byte_math:bytes <bytes_to_extract>, offset <offset_value>, oper <operator>, 
        rvalue <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

選項	描述
`bytes_to_extract`	從數據包中提取的字節數。不使用`dce`時允許的值為1到10 。如果與`dce`一起使用，則允許值為1、2和4。如果與`<<`或`>>`運算符一起使用，則允許值為1至4。
`oper`	對提取值執行的數學運算允許的運算：+，-，*，/ 、`<<` 、`>>`
`rvalue`	對數學運算使用的值
`offset`	有效負載中開始處理的字節數
`relative`	使用相對于上一個圖案匹配的偏移量
`endiam`	要讀取的數字的字節序類型：- `big` -過程數據作為大端（默認）;- `little` -處理小尾數形式的數據
`string`	數據以字符串格式存儲在數據包中
`number type`	讀取的號碼類型：- `hex` -轉換后的字符串數據以十六進制表示;- `dec-`轉換后的字符串數據以十進制表示;- `oct-`轉換后的字符串數據以八進制表示
`dce`	讓DCE / RPC 2預處理器確定要轉換的值的字節順序。
`bitmask`	對提取的字節應用AND運算符。結果將右移等于掩碼中尾隨零的位數。

3.3.34.2 使用byte_math結果變量的其他規則選項

規則選項	帶結果變量的參數
content	offset, depth, distance, within
byte_test	offset, value
byte_jump	offset
isdataat	offset

3.3.34.3 例子

    alert udp $EXTERNAL_NET any -> $HOME_NET any \
        (msg:"Perform Arithmetic Operation on the extracted bytes"; \
        content:"|00 04 93 F3|"; \
        content:"|00 00 00 07|"; distance:4; within:4; \
        byte_math:bytes 4, offset 0, oper +, rvalue 248, result var, relative; \
        byte_test:4, >, var, 2, relative;)

    alert tcp $EXTERNAL_NET any -> $HOME_NET any \
        (msg:"Bitwise shift operator"; \
        content:"|00 00 00 07|"; distance:4; within:4; \
        byte_extract: 1, 0, extracted_val, relative; \
        byte_math: bytes 1, offset 2, oper >>, rvalue extracted_val, result var, relative; \
        byte_test:2, =, var, 0, relative;)

    alert udp any any -> any 1234 \
        (content: "Packets start"; \
        byte_math: bytes 2, offset 0, oper -, rvalue 100, result var, relative, bitmask 0x7FF0; \
        content: "Packets end"; distance: 2; within var; \
        msg:"Content match with bitmask applied to the bytes extracted";)

    alert udp any any -> any 1235 \
        (byte_extract: 4, 3,  extracted_val, relative; \
        byte_math: bytes 5, offset 0, oper +, rvalue extracted_val, result var, string hex; \
        byte_test:5, =, var, 4, string, hex; \
        msg:"String operator used with math rule option";)

3.3.33 ftpbounce

ftpbounce關鍵字檢測FTP反彈攻擊。

3.3.33.1 格式

ftpbounce;

3.3.33.2 例子

    alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"FTP PORT bounce attempt";
        flow:to_server,established; content:"PORT"; nocase; ftpbounce; pcre:"/^PORT/smi";
        classtype:misc-attack; sid:3441; rev:1;)

3.3.36 asn1

ASN.1檢測插件對數據包或數據包的一部分進行解碼，并查找各種惡意編碼。

可以在’asn1’選項中使用多個選項，并且隱式邏輯為布爾OR。因此，如果任何參數的評估結果為true，則整個選項的評估結果為true。

ASN.1選項提供了程序檢測功能以及一些更動態的類型檢測。如果選項具有參數，則選項和參數用空格或逗號分隔。首選用法是在選項和參數之間使用空格。

3.3.36.1 格式

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

選項	描述
`bitstring_overflow`	檢測已知可被遠程利用的無效位串編碼。
`double_overflow`	檢測大于標準緩沖區的雙ASCII編碼。在Microsoft中，這是已知的可利用功能，但目前尚不清楚哪些服務可被利用。
`oversize_length <value>`	將ASN.1類型長度與提供的參數進行比較。語法看起來像“ oversize_length 300”。這意味著，如果ASN.1類型大于300，則此關鍵字的評估結果為true。此關鍵字必須具有一個參數，該參數指定要比較的長度。
`absolute_offset <value>`	這是從數據包開始的絕對偏移量。例如，如果您想解碼snmp數據包，則說“ absolute_offset 0”。 `absolute_offset`具有一個參數，即偏移值。偏移量可以是正數或負數。
`relative_offset <value>`	這是相對于最后一個內容匹配，pcre或byte_jump的相對偏移量。 `relative_offset`有一個參數，即偏移號。因此，如果您想在內容“ foo”之后立即開始解碼ASN.1序列，則可以指定`'content:"foo"; asn1:bitstring_overflow, relative_offset 0'`。偏移值可以為正或負。

3.3.36.2 例子

    alert udp any any -> any 161 (msg:"Oversize SNMP Length"; \
        asn1:oversize_length 10000, absolute_offset 0;)

    alert tcp any any -> any 80 (msg:"ASN1 Relative Foo"; content:"foo"; \
        asn1:bitstring_overflow, relative_offset 0;)

3.3.37 CVS

CVS檢測插件有助于檢測：Bugtraq-10384，CVE-2004-0396：“格式錯誤的條目已修改且未更改的標志插入”。默認的CVS服務器端口是2401和314，并且包含在用于流重組的默認端口中。

注意： 該插件無法通過加密的會話進行檢測，例如SSH（通常為端口22）。

3.3.37.1 格式

cvs：<option>;

選項	描述
`invalid-entry`	查找無效的Entry字符串，這是導致堆溢出（請參閱CVE-2004-0396）和CVS 1.11.13及更低版本中錯誤的指針取消引用的一種方式。

3.3.37.2 例子

    alert tcp any any -> any 2401 (msg:"CVS Invalid-entry"; \
        flow:to_server,established; cvs:invalid-entry;)

3.3.38 Payload檢測快速參考

下表表示payload檢測規則選項關鍵字:

關鍵詞	描述
`content`	content關鍵字允許用戶設置規則，以搜索數據包有效負載中的特定內容并基于該數據觸發響應。
`rawbytes`	rawbytes關鍵字允許規則查看原始數據包數據，而忽略預處理器進行的任何解碼。
`depth`	depth關鍵字允許規則編寫者指定Snort應該在包中搜索指定模式的距離。
`offset`	offset關鍵字允許規則編寫器指定從何處開始搜索數據包中的模式。
`distance`	distance關鍵字使規則編寫者可以指定Snort在開始搜索相對于先前模式匹配末尾的指定模式之前應忽略的包數。
`within`	within關鍵字是一個內容修飾符，它使用content關鍵字確保最多N個字節在模式匹配之間。
`uricontent`	Snort規則語言中的uricontent關鍵字搜索標準化的請求URI字段。
`isdataat`	isdataat關鍵字用于驗證有效負載在指定位置是否具有數據。
`pcre`	pcre關鍵字允許使用與perl兼容的正則表達式編寫規則。
`byte_test`	byte_test關鍵字針對特定值（使用運算符）測試字節字段。
`byte_jump`	byte_jump關鍵字允許規則讀取數據的一部分長度，然后在數據包中向前跳過該長度。
`ftpbounce`	ftpbounce關鍵字檢測FTP反彈攻擊。
`asn1`	asn1檢測插件對數據包或數據包的一部分進行解碼，并查找各種惡意編碼。
`cvs`	cvs關鍵字檢測到無效的輸入字符串。
`dce_iface`	請參閱2.2 Snort預處理器中 DCE/RPC 2部分
`dce_opnum`	請參閱2.2 Snort預處理器 DCE/RPC 2部分
`dce_stub_data`	請參閱2.2 Snort預處理器 DCE/RPC 2部分
`sip_method`	請參閱2.2 Snort預處理器 SIP部分
`sip_stat_code`	請參閱2.2 Snort預處理器 SIP部分
`sip_header`	請參閱2.2 Snort預處理器 SIP部分
`sip_body`	請參閱2.2 Snort預處理器 SIP部分
`gtp_type`	請參閱2.2 Snort預處理器 GTP部分
`gtp_info`	請參閱2.2 Snort預處理器 GTP部分
`gtp_version`	請參閱2.2 Snort預處理器 GTP部分

本文章首發在網安wangan.com 網站上。