2.2 Snort 預處理器

Snort的1.5版中引入了預處理器。它們允許用戶和程序員相當容易地將模塊化插件放入Snort中，從而擴展了Snort的功能。在調用檢測引擎之前，但在對數據包進行解碼之后，將運行預處理程序代碼。可以使用此機制以帶外方式修改或分析數據包。

使用preprocessor關鍵字加載和配置預處理器。Snort配置文件中預處理器指令的格式為：

 preprocessor <name>: <options>

2.2.1 Frag3

frag3預處理器是Snort的基于目標的IP碎片整理模塊。Frag3的設計目標如下：

1. 快速執行，不需要復雜的數據管理。
2. 基于目標的主機建模防規避技術。

Frag3在內部使用sfxhash數據結構和鏈表進行數據處理，這使其在任何可以幫助我們管理高度分散的環境中，具有更可預測的確定性。

基于目標的分析是基于網絡的入侵檢測中一個相對較新的概念。基于目標的系統的思想是對網絡上的實際目標進行建模，而不僅僅是對協議進行建模并在其中尋找攻擊。當為不同的操作系統編寫IP堆棧時，通常是由閱讀RFC，然后將其對RFC概述內容的解釋寫到代碼中的人員實現的。不幸的是，RFC定義了可能出現的某些邊緣條件的方式存在歧義，并且當這種情況發生時，不同的人會以不同的方式實現其IP堆棧的某些方面。對于IDS來說，這是一個大問題。

在攻擊者可以確定在特定目標上使用哪種樣式的IP碎片整理的環境中，攻擊者可以嘗試對數據包進行分段，以便目標以特定方式將它們放回一起，而任何被動系統都在嘗試對主機進行建模流量必須猜測目標操作系統將以哪種方式處理重疊并重新傳輸。就像我要說的那樣，如果攻擊者比IDS擁有更多有關網絡目標的信息，則有可能逃避IDS。這就是“基于目標的IDS”思想的來源。

基于目標的IDS的基本思想是，我們將有關網絡上主機的IDS信息告訴給IDS，以便它可以根據有關單個目標IP堆棧操作方式的信息來避免Ptacek＆Newsham式的規避攻擊。

我們還可以向IDS提供拓撲信息，以避免基于TTL的逃避和其他各種問題。一旦獲得了這些信息，我們就可以開始針對這些復雜的建模問題真正改變游戲規則。

Frag3的實現是為了展示和原型化Snort中基于目標的模塊，以測試這一想法。

2.2.1.1 Frag 3配置

激活frag3至少需要兩個預處理程序指令，一個全局配置指令和一個引擎實例化。在啟動時可以定義任意數量的具有其自身配置的引擎，但是只有一個全局配置。

全局配置

• 預處理器名稱：frag3_global
• 可用選項：注：全局配置選項以逗號分隔。
  • max_frags <number> -要跟蹤的最大同時碎片數。默認值為8192。
  • memcap <bytes> -用于自我保存的內存上限。默認值為4MB。
  • prealloc_memcap <bytes> -備用內存管理模式，使用基于內存上限的預分配片段節點（在某些情況下更快）。
  • prealloc_frags <number> -備用內存管理模式，使用預分配的片段節點（在某些情況下更快）。
  • disable -任何策略都允許使用此可選關鍵字以避免數據包處理。此選項禁用此配置的預處理器，但不禁用多個配置的其他實例。在基本配置中使用disable關鍵字可以為選項memcap，prealloc_memcap和prealloc_frags指定值，而無需預處理器檢查用于基本配置的流量。其他選項已解析但未使用。任何有效的配置都可能添加了“禁用”。

引擎配置

• 預處理器名稱：frag3_engine
• 可用選項：注：引擎配置選項以空格分隔。
  • time <seconds> -片段超時。引擎中超過此時間段的片段將被自動刪除。默認值為60秒。
  • min_ttl <value> -對于一個分段包的最小可接受的TTL值。默認值為1。此選項的可接受范圍是1-255。
  • detect_anomalies -檢測片段異常。
  • bind_to <ip_list> -綁定此引擎的IP列表。該引擎僅對IP地址列表中包含目標地址的數據包運行。默認值為all。
  • overlay_limit <number> -限制每個數據包的重疊片段數。默認值為“ 0”（無限制）。此配置選項采用等于或大于零的值。這是一個可選參數。必須配置detect_anomalies選項，此選項才能生效。
  • min_fragment_length <number> -定義應視為有效的最小片段大小（有效負載大小）。如果還配置了detect_anomalies，則小于或等于此限制的片段被認為是惡意的，并引發事件。默認值為“ 0”（無限制），最小值為“ 0”。這是一個可選參數。必須配置detect_anomalies選項，此選項才能生效。
  • policy <type> -選擇基于目標的碎片整理模式。可用的類型為first，last，bsd，bsd-right，linux，windows和solaris。默認類型為bsd。

Paxson Active Mapping論文介紹了術語frag3用于描述策略類型。已知的映射如下。

2.2.1.2 格式

請注意，在下面的高級配置中，指定了三個運行Linux的引擎，并分配了第一個和最后一個策略。前兩個引擎綁定到特定的IP地址范圍，最后一個引擎適用于所有其他流量。不屬于前兩個引擎的地址要求的數據包將自動進入第三個引擎。

2.2.1.2.1 基本配置

   preprocessor frag3_global
    preprocessor frag3_engine

2.2.1.2.2 高級配置

    preprocessor frag3_global: prealloc_nodes 8192 
    preprocessor frag3_engine: policy linux bind_to 192.168.1.0/24
    preprocessor frag3_engine: policy first bind_to [10.1.47.0/24,172.16.8.0/24]
    preprocessor frag3_engine: policy last detect_anomalies

2.2.1.3 Frag 3警報輸出

Frag3能夠檢測八種不同類型的異常。它的事件輸出是基于數據包的，因此它將與Snort的所有輸出模式一起使用。

2.2.2 Session

會話預處理器是Snort的全局流會話管理模塊。它源自Stream5預處理器中的會話管理功能。

由于Session實現了Stream5中以前的功能和API的一部分，因此它不能與Stream5一起使用，而必須與新的Stream預處理器結合使用。同樣，由于API的更改，Snort 2.9.7中的其他預處理器只能與新的Session和Stream預處理器一起使用。

2.2.2.1 會話API

會話提供了一個API，以支持為流創建和管理會話控制塊，以及由服務和應用程序預處理器管理可能與該流相關聯的數據和狀態（其中大多數功能以前都由Stream5 API支持） 。調用這些方法以標識可能被忽略的會話（大數據傳輸等），并更新有關會話的標識信息（應用程序協議，方向等），這些信息以后可由規則使用。在會話API中已添加了API方法，這些方法使預處理器可以注冊端口和服務的分發，應調用端口和服務來處理它們。使用“ flow”和“ flowbits”關鍵字需要會話。

2.2.2.2 會話全局配置

會話預處理器的全局設置。

        preprocessor stream5_global:
        [track_tcp <yes|no>], [max_tcp <number>],
        [memcap <number bytes>],
        [track_udp <yes|no>], [max_udp <number>],
        [track_icmp <yes|no>], [max_icmp <number>],
        [track_ip <yes|no>], [max_ip <number>],
        [flush_on_alert], [show_rebuilt_packets],
        [prune_log_max <number bytes>], [disabled],
        [enable_ha]

2.2.2.3 Session HA配置

HA會話狀態共享的配置。

preprocessor stream5_ha: [min_session_lifetime <num millisecs>],
[min_sync_interval <num millisecs>], [startup_input_file <filename>],
[runtime_output_file <filename>], [use_side_channel]

2.2.2.4 示例配置

1. 此示例配置將TCP會話控制塊的最大數量設置為8192，啟用對TCP和UPD會話的跟蹤，并禁用對ICMP會話的跟蹤。UDP會話控制塊的數量將設置為已編譯的默認值。

   preprocessor stream5_global: \
       max_tcp 8192, track_tcp yes, track_udp yes, track_icmp no
   
   preprocessor stream5_tcp: \
       policy first, use_static_footprint_sizes
   
   preprocessor stream5_udp: \
       ignore_any_rules

2.2.3 Stream

流預處理器是Snort的基于目標的TCP重組模塊。它能夠跟蹤TCP和UDP的會話。

2.2.3.1 傳輸協議

TCP會話通過經典的TCP“連接”進行標識。UDP會話是通過來自兩個端點的同一組端口的一系列UDP數據包的結果而建立的。跟蹤ICMP消息是為了檢查不可達消息和服務不可用消息，從而有效終止TCP或UDP會話。

2.2.3.2 基于目標

與Frag3一樣，Stream引入了基于目標的操作來處理重疊數據和其他TCP異常。處理重疊數據，TCP時間戳，SYN，FIN和復位序列號上的數據等的方法以及Stream支持的策略是對許多目標操作系統進行廣泛研究的結果。

2.2.3.3 流API

Stream支持修改后的Stream API，該API現在專注于特定于重組和協議感知的刷新操作的功能。會話管理功能已移至會話API。其余的API函數使其他協議規范化器/預處理器可以根據應用層協議的要求動態配置重組行為。

2.2.3.4 異常檢測

TCP協議異常（例如SYN數據包上的數據，TCP窗口外部接收的數據等）通過TCP配置的detect_anomalies選項進行配置。其中一些異常是按目標檢測的。例如，某些操作系統允許TCP SYN數據包中的數據，而其他操作系統則不允許。

2.2.3.5 協議感知刷新

可以使用以下選項啟用HTTP，SMB和DCE / RPC的協議感知刷新：

config paf_max：<max-pdu>

其中，<max-pdu>在零（關閉）和63780之間。這使Snort可以有狀態地掃描流并重組完整的PDU，而無需進行分段。例如，單個TCP段中的多個PDU以及跨越多個TCP段的一個PDU將被重組為每個PDU每個數據包一個PDU。大于配置的最大值的PDU將被拆分為多個數據包。

2.2.3.6 Stream TCP配置

在每個IP地址目標上提供一種方法來配置TCP策略。每個綁定到IP地址或網絡的策略可能會多次出現。必須指定一個默認策略，并且該策略未綁定到IP地址或網絡。

        preprocessor stream5_tcp: \
        [log_asymmetric_traffic <yes|no>], \
        [bind_to <ip_addr>], \
        [timeout <number secs>], [policy <policy_id>], \
        [overlap_limit <number>], [max_window <number>], \
        [require_3whs [<number secs>]], [detect_anomalies], \
        [check_session_hijacking], [use_static_footprint_sizes], \
        [dont_store_large_packets], [dont_reassemble_async], \
        [max_queued_bytes <bytes>], [max_queued_segs <number segs>], \
        [small_segments <number> bytes <number> [ignore_ports number [number]*]],  \
        [ports <client|server|both> <all|number|!number [number]* [!number]*>], \
        [protocol <client|server|both> <all|service name [service name]*>], \
        [ignore_any_rules], [flush_factor <number segs>]

*注意： *如果沒有為給定的TCP策略指定選項，則為默認TCP策略。如果僅使用bind_to選項，而沒有其他選項，則TCP策略將使用所有默認值。

2.2.3.7 Stream UDP配置

UDP會話跟蹤的配置。由于沒有基于目標的綁定，因此應該僅出現一次UDP配置。

preprocessor stream5_udp: [timeout <number secs>], [ignore_any_rules]

*注意： *使用ignore_any_rules選項，將忽略UDP規則，除非有另一個適用于流量的特定于端口的規則。例如，如果UDP規則指定目標端口53，則忽略 any- > any 規則將應用于去往/來自端口53的流量，而不應用于任何其他源端口或目標端口。Snort啟動時將打印受此選項影響的規則SID列表。

*注意： *使用ignore_any_rules選項，如果使用任何->任何端口的UDP規則包括流或流位，則ignore_any_rules選項實際上是毫無意義的。由于禁用流位規則的潛在影響，在這種情況下，ignore_any_rules選項將被禁用。

2.2.3.8 流ICMP配置

ICMP會話跟蹤的配置。由于沒有基于目標的綁定，因此應該僅出現一次ICMP配置。

*注意： *ICMP目前未經測試，以最小的代碼形式出現，尚不能在生產網絡中使用。默認情況下未打開。

preprocessor stream5_icmp: [timeout <number secs>]

2.2.3.9 流IP配置

IP會話跟蹤的配置。由于沒有基于目標的綁定，因此應該僅出現一次IP配置。

*注意： *如果沒有另外配置ICMP，“ IP”包括所有通過IP的非TCP / UDP流量，包括ICMP。默認情況下未打開。

preprocessor stream5_ip: [timeout <number secs>]

2.2.3.10 示例配置

1. 此示例配置是snort.conf中的默認配置，可用于在回讀模式下對流重組進行可重復的測試。

   preprocessor stream5_global: \
       max_tcp 8192, track_tcp yes, track_udp yes, track_icmp no
   
   preprocessor stream5_tcp: \
       policy first, use_static_footprint_sizes
   
   preprocessor stream5_udp: \
       ignore_any_rules

2. 此配置將兩個網段映射到不同的OS策略，一個用于Windows，一個用于Linux，其他所有流量都流向Solaris的默認策略。

   preprocessor stream5_global: track_tcp yes
   preprocessor stream5_tcp: bind_to 192.168.1.0/24, policy windows
   preprocessor stream5_tcp: bind_to 10.1.1.0/24, policy linux
   preprocessor stream5_tcp: policy solaris

   2.2.4 sfPortscan

由Sourcefire開發的sfPortscan模塊旨在檢測網絡攻擊的第一階段：Reconnaissance。在Reconnaissance階段，攻擊者確定主機支持哪些類型的網絡協議或服務。這是進行端口掃描的傳統場所。該階段假設攻擊主機沒有目標所支持的協議或服務的先驗知識。否則，將不需要此階段。

由于攻擊者沒有事先知道其預期目標，因此攻擊者發送的大多數查詢都將是否定的（意味著服務端口已關閉）。在合法網絡通信的本質上，來自主機的否定響應很少，并且在給定的時間內仍是多個否定響應。我們檢測portcan的主要目的是檢測和跟蹤這些負面反應。

Nmap是當今使用的最常見的端口掃描工具之一。Nmap涵蓋了許多（即使不是全部）當前的端口掃描技術。sfPortscan旨在檢測Nmap可以產生的不同類型的掃描。

sfPortscan當前將警告以下Nmap掃描類型：

• TCP端口掃描
• UDP端口掃描
• IP端口掃描

這些警報針對的是傳統掃描類型的端口掃描。一臺主機掃描另一臺主機上的多個端口。由于大多數主機的可用服務相對較少，因此大多數端口查詢將為負。

sfPortscan還警告以下類型的decoy portscans：

• TCP Decoy端口掃描
• UDP Decoy端口掃描
• IP Decoy端口掃描

Decoy端口掃描與上述Nmap端口掃描非常相似，只有攻擊者的欺騙源地址與真實掃描地址混合在一起。此策略有助于隱藏攻擊者的真實身份。

sfPortscan警告以下類型的分布式portcan：

• TCP分布式端口掃描
• UDP分布式端口掃描
• IP分布式端口掃描

當多個主機向一臺主機查詢開放服務時，就會發生分布式端口掃描。這用于逃避IDS和混淆命令和控制主機。

*注意： *否定查詢將分布在掃描主機之間，因此我們通過掃描的主機跟蹤這種類型的掃描。

sfPortscan對以下類型的端口掃描發出警報：

• TCP端口掃描
• UDP端口掃描
• IP端口掃描
• ICMP Portsweep

這些警報是針對許多端口掃描的。一臺主機掃描多臺主機上的單個端口。當出現新的攻擊并且攻擊者正在尋找特定服務時，通常會發生這種情況。

*注意： *Portseep掃描的特征可能不會導致很多負面響應。例如，如果攻擊者將Web場的端口80移植為Web場，我們很可能不會看到很多負面響應。

sfPortscan對以下經過過濾的端口掃描和端口掃描發出警報：

• TCP篩選的端口掃描
• UDP篩選的端口掃描
• IP過濾的端口掃描
• TCP過濾Decoy端口掃描
• UDP過濾Decoy端口掃描
• IP過濾Decoy端口掃描
• TCP篩選的端口掃描
• UDP篩選的端口掃描
• IP過濾的端口掃描
• ICMP篩選的端口掃描
• TCP篩選的分布式Portscan
• UDP篩選的分布式Portscan
• IP過濾的分布式Portscan

“已過濾”警報表示沒有網絡錯誤（ICMP無法訪問或TCP RST），或者已關閉的端口上的響應已被抑制。這也很好地表明了警報是否只是一個非常活躍的合法主機。活動主機（例如NAT）可以觸發這些警報，因為它們可以在非常短的時間內發出許多連接嘗試。在接收到來自遠程主機的響應之前，過濾的警報可能會發出。

sfPortscan僅在時間窗口內為每個有問題的主機對生成一個警報（更多信息在下面的窗口中）。在TCP掃描警報上，sfPortscan還將顯示所有已掃描的打開端口。但是，在TCP掃描警報上，sfPortscan僅在觸發警報后才跟蹤打開的端口。打開端口事件不是單個警報，而是基于原始掃描警報的標簽。

2.2.4.1 sfPortscan配置

sfPortscan需要使用流預處理器。在無連接協議（例如ICMP和UDP）的情況下，Stream會為portcan指明方向。

可用于配置portscan模塊的參數為：

1. proto < protocol>

可用選項：

• TCP協議
• UDP協議
• ICMP
• ip_proto
• all

2. scan_type < scan_type>

可用選項：

• Portscan
• portsweep
• decoy_portscan
• 分布式端口掃描
• all

3. sense_level < level >

可用選項：

• 低 -僅在從目標主機發送的錯誤數據包上生成“低”警報，并且由于錯誤響應的性質，此設置應該很少出現誤報。但是，由于缺少錯誤響應，此設置將永遠不會觸發“篩選掃描”警報。此設置基于60秒的靜態時間窗口，此后重置此窗口。
• 中 -“中”警報跟蹤連接計數，因此將生成過濾的掃描警報。此設置在活動主機（NAT，代理，DNS緩存等）上可能會誤判，因此用戶可能需要部署使用Ignore指令來正確調整此指令。
• 高 -“高”警報使用時間窗口連續跟蹤網絡上的主機，以評估該主機的端口掃描統計信息。由于持續監控，“高”設置將捕獲一些慢速掃描，但對活動主機非常敏感。這絕對需要用戶調整sfPortscan。

4. watch_ip < ip1 | ip2/cidr[ [port|port2-port3]]>

定義要監視的IP，網絡和這些主機上的特定端口。該列表是逗號分隔的IP地址列表，該IP地址使用CIDR表示法。（可選）在IP地址/ CIDR后使用空格指定端口，端口可以是單個端口，也可以是短劃線表示的范圍。如果使用此選項，則不屬于此范圍的IP或網絡將被忽略。

5. ignore_scanners < ip1|ip2/cidr[ [port|port2-port3]]>

忽略掃描警報的來源。該參數與watch_ip的格式相同 。

6. ignore_scanned < ip1|ip2/cidr[ [port|port2-port3]]>

忽略掃描警報的目的地。該參數與watch_ip的格式相同。

7. logfile < file >

此選項會將portscan事件輸出到指定的文件。如果文件不包含斜杠，則此文件將放置在Snort配置目錄中。

8. include_midstream

此選項將包括Stream在中途拾取的會話。這可能會導致錯誤警報，尤其是在數據包丟失的高負載下；這就是默認情況下該選項處于關閉狀態的原因。

9. detect_ack_scans

此選項將包括流模塊在中途拾取的會話，這對于檢測ACK掃描是必需的。但是，這可能會導致錯誤警報，尤其是在丟失數據包的高負載下；這就是默認情況下該選項處于關閉狀態的原因。

10. disabled

任何策略都允許使用此可選關鍵字，以避免數據包處理。此選項禁用預處理器。如果禁用了預處理器，則在配置中指定時僅應用memcap選項。其他選項已解析但未使用。任何有效的配置都可能添加了“禁用”。

2.2.4.2 格式

  preprocessor sfportscan: proto <protocols> \
        scan_type <portscan|portsweep|decoy_portscan|distributed_portscan|all> \
        sense_level <low|medium|high> \
        watch_ip <IP or IP/CIDR> \
        ignore_scanners <IP list> \
        ignore_scanned <IP list> \
        logfile <path and filename> \
        disabled

2.2.4.3 例子

 preprocessor flow: stats_interval 0 hash 2
    preprocessor sfportscan:\
        proto { all } \
        scan_type { all } \
        sense_level { low }

2.2.4.4 sfPortscan警報輸出

2.2.4.4.1 統一輸出

為了獲取與警報一起記錄的所有portcan信息，snort會生成一個偽數據包，并使用有效載荷部分來存儲其他portcan信息，這些信息包括優先級計數，連接計數，IP計數，端口計數，IP范圍和端口范圍。數據包的特征是：

 Src/Dst MAC Addr == MACDAD
    IP Protocol == 255
    IP TTL == 0

除此之外，數據包看起來像是導致端口可以生成警報的數據包的IP部分。這包括任何IP選項，等等。數據包的有效負載和有效負載大小等于所記錄的其他端口的長度。大小通常約為100-200字節。

開放端口警報不同于其他端口掃描警報，因為開放端口警報利用標記的數據包輸出系統。這意味著，如果使用不打印標記數據包的輸出系統，則用戶將不會看到打開的端口警報。打開的端口信息存儲在IP有效負載中，并且包含打開的端口。

sfPortscan警報輸出旨在與Unified2數據包日志記錄一起使用，因此可以擴展喜歡的Snort GUI來使用上述數據包特性在IP有效負載中顯示端口掃描警報和其他信息。

2.2.4.4.2 日志文件輸出

日志文件輸出以以下格式顯示，并在下面進一步說明：

    Time: 09/08-15:07:31.603880
    event_id: 2
    192.168.169.3 -> 192.168.169.5 (portscan) TCP Filtered Portscan
    Priority Count: 0
    Connection Count: 200
    IP Count: 2
    Scanner IP Range: 192.168.169.3:192.168.169.4
    Port/Proto Count: 200
    Port/Proto Range: 20:47557

如果目標上有開放端口，則將附加一個或多個其他帶標記的數據包：

    Time: 09/08-15:07:31.603881
    event_ref: 2
    192.168.169.3 -> 192.168.169.5 (portscan) Open Port
    Open Port: 38458

1. Event_id / Event_ref

這些字段用于將警報與相應的 Open Port標記的數據包鏈接

2. Priority Count

優先計數跟蹤不良響應（重置，不可達）。優先級計數越高，收到的響應越多。

3. Connection Count

連接計數列出了主機（src或dst）上活動的連接數。這對于基于連接的協議來說是準確的，而對于其他協議則更多。在此確定是否對端口掃描進行了過濾。高連接數和低優先級數將指示已過濾（未從目標接收到響應）。

4. IP計數

IP計數跟蹤與主機聯系的最后一個IP，如果下一個IP不同，則增加計數。對于一對一掃描，這是一個較低的數字。對于活動主機，無論如何此數字都將很高，并且一對一掃描可能會顯示為分布式掃描。

5. 掃描/掃描儀IP范圍

該字段根據警報類型而變化。Portsweep（一對多）掃描顯示掃描的IP范圍；Portscans（一對一）顯示掃描儀IP。

6. 端口數

端口計數跟蹤上次聯系的端口，并在此端口號更改時遞增該數字。我們使用此計數（以及IP計數）來確定一對一portcan和一對一誘餌之間的差異。

2.2.4.5 調整sFPortscan

檢測端口掃描最重要的方面是調整網絡的檢測引擎。以下是一些調優技巧：

7. 使用watch_ip，ignore_scanners和ignore_scanned選項。

正確設置這些選項很重要。該watch_ip選項是很容易理解。分析人員應將此選項設置為他們要監視的CIDR塊和IP的列表。如果未定義watch_ip，則sfPortscan將監視所有網絡流量。

該ignore_scanners和ignore_scanned選項來發揮作用的淘汰是在網絡上非常活躍的合法主人。一些最常見的示例是NAT IP，DNS緩存服務器，syslog服務器和nfs服務器。sfPortscan可能不會為這些類型的主機生成誤報，但是請注意在首次為這些IP調整sfPortscan時。根據主機生成的警報類型，分析人員將知道忽略該警報的方式。如果主機正在生成portsweep事件，則將其添加到ignore_scanners選項。如果主機正在生成端口掃描警報（并且正在掃描主機），請將其添加到 ignore_scanned選項。

8. 過濾后的掃描警報更容易出現誤報。

在確定誤報時，警報類型非常重要。sfPortscan可能生成的大多數誤報都是經過過濾的掃描警報類型。因此，對已過濾的portcan更加懷疑。很多時候，這僅表明主機在所討論的時間段內非常活躍。如果主機持續生成這些類型的警報，請將其添加到 ignore_scanners列表中或使用較低的敏感度級別。

9. 利用“優先級計數”，“連接計數”，“ IP計數”，“端口計數”，“ IP范圍”和“端口范圍”來確定誤報。

Portcan警報詳細信息對于確定Portcan的范圍以及Portcan的置信度至關重要。將來，我們希望在分配范圍級別和置信度級別時自動執行很多這種分析，但是現在用戶必須手動執行此操作。確定誤報的最簡單方法是通過簡單的比率估計。以下是估計比率和相關值的列表，這些比率指示合法掃描而不是假陽性。

連接計數/ IP計數： 此比率表示每個IP的估計平均連接數。對于portcans，此比率應較高，越高越好。對于portweeps，此比率應低。

端口數/ IP數： 此比率表示每個IP連接的端口的估計平均值。對于portcans，此比率應較高，并指示通過較少的IP連接到掃描主機的端口。對于端口掃描，此比率應較低，這表明掃描主機連接到的端口很少，但連接的主機很多。

連接計數/端口計數： 此比率表示每個端口的估計平均連接數。對于portcans，此比率應低。這表明每個連接都連接到不同的端口。對于portweeps，此比率應較高。這表明到同一端口的連接很多。

不包括優先級計數 的原因是，由于優先級計數包含在連接計數中，因此上述比較考慮了這一點。優先級計數在調整中起著重要作用，因為優先級計數越高，它越有可能是真實的端口掃描或端口掃描（除非對主機進行防火墻保護）。

10. 如果其他所有方法均失敗，請降低靈敏度級別。

如果其他所有調整技術均無效，或者分析人員沒有時間進行調整，請降低靈敏度級別。靈敏度級別越高，您將獲得最好的保護，但是端口掃描檢測引擎生成警報以使分析人員發現有用信息也很重要。低靈敏度級別僅基于錯誤響應生成警報。這些響應表明端口掃描，并且低靈敏度級別生成的警報非常準確，并且需要的調整最少。低靈敏度級別無法捕獲過濾的掃描；因為這些更容易出現誤報。

2.2.5 RPC解碼

rpc_decode預處理器將RPC多個分段記錄標準化為單個未分段記錄。它通過將數據包標準化到數據包緩沖區中來實現。如果啟用stream5，它將僅處理客戶端流量。默認情況下，它針對端口111和32771上的流量運行。

2.2.5.1 格式

preprocessor rpc_decode: \
        <ports> [ alert_fragments ] \
        [no_alert_multiple_requests] \
        [no_alert_large_fragments] \
        [no_alert_incomplete]

2.2.6 性能監控器

該預處理器可測量Snort的實時和理論上的最大性能。無論何時打開此預處理器，都應啟用輸出模式，即“控制臺”將統計信息打印到控制臺窗口，或“文件”以及文件名，其中將統計信息打印到指定的文件名。默認情況下，處理Snort的實時統計信息。這包括：

• 時標
• 下降率
• 兆比特/秒（有線）[在下面重復以方便與其他速率進行比較]
• 警報/秒
• K-Pkts /秒（導線）[在下面重復以方便與其他費率進行比較]
• 平均字節數/包（線）[在下面重復以方便與其他速率進行比較]
• Pat-Matched [Snort在模式匹配中處理的接收數據的百分比]
• Syns/秒
• SynAcks /秒
• 新會話已緩存/秒
• 會話數從緩存/秒
• 當前緩存的會話
• 最大緩存的會話
• Stream Flushes/秒
• 流會話緩存故障
• 流會話緩存超時
• 新片段跟蹤器/秒
• 片段完成/秒
• 片段插入/秒
• 片段刪除/秒
• 片段自動刪除/秒[內存DoS保護]
• Frag-Flushes/秒
• Frag-Current [當前Frag跟蹤器的數量]
• Frag-Max [任意時間的最大Frag Tracker數量]
• Frag-Timeouts
• Frag-Faults
• CPU數量[僅當使用LINUX_SMP編譯時，每個CPU才會顯示下三個]
• CPU使用率（用戶）
• CPU使用率（sys）
• CPU使用率（空閑）
• 兆位/秒（有線）[總流量的平均兆位]
• Mbits /秒（ipfrag）[IP分段流量的平均mbits]
• 兆位/秒（ipreass）[IP重組后Snort注入的平均兆位]
• 兆位/秒（tcprebuilt）[TCP重組后Snort注入的平均兆位]
• 兆位/秒（應用程序層）[規則和協議解碼器看到的平均兆位]
• 平均字節數/包（線）
• 平均字節數/包（ipfrag）
• 平均字節數/千字節（ipreass）
• 平均字節數/包（tcprebuilt）
• 平均字節數/包（applayer）
• K-Pkts /秒（電線）
• K-Pkts /秒（ipfrag）
• K-Pkts /秒（ipreass）
• K-Pkts /秒（tcprebuilt）
• K-Pkts /秒（applayer）
• 收到的總數據包
• 丟棄的總數據包（未處理）
• 阻止的總數據包（內聯）
• 丟包率
• 已過濾的TCP數據包總數
• 已過濾的UDP數據包總數
• 中游TCP會話/秒
• TCP會話關閉/秒
• 修剪的TCP會話/秒
• 超時TCP會話/秒
• 丟棄的異步TCP會話數/秒
• TCP會話初始化
• TCP會話建立
• TCP會話關閉
• 最大TCP會話數（時間間隔）
• 新的緩存UDP會話/秒
• 緩存的UDP Ssns Del / Sec
• 當前緩存的UDP會話
• 最大緩存的UDP會話
• 當前屬性表主機（基于目標）
• 屬性表重新加載（基于目標）
• 兆位/秒（snort）
• 兆位/秒（嗅探）
• 兆位/秒（組合）
• uSeconds / Pkt（發聲）
• uSeconds / Pkt（嗅探）
• uSeconds / Pkt（組合）
• KPkts /秒（snort）
• KPkts /秒（嗅探）
• KPkts /秒（組合）

有超過100個個人統計信息。標題行在啟動和翻轉時輸出，標記每列。

以下選項可以與性能監視器一起使用：

• flow -打印有關的流量和協議分布的該Snort的是看到的類型和量的統計信息。此選項可以產生大量輸出。

• flow- file- 以逗號分隔的格式將flow統計信息打印到指定的文件。

  • Timestamp
  • TCP字節總數
  • UDP字節總數
  • ICMP字節總數
  • 總計％其他字節
  • 包長度條目數
  • 數據包長度條目-字節，總計
  • TCP端口流表項數
  • TCP端口流條目：端口，％total，％src，％dst
  • ％TCP高端口到高端口
  • UDP端口流表項數
  • UDP端口流條目：端口，％total，％src，％dst
  • UDP高端口到高端口的百分比
  • ICMP類型條目數
  • ICMP類型條目：類型，總計指定此選項將隱式啟用流統計信息。

• 事件 -打開事件報告。這將打印出有關已評估和不匹配的規則數量（不合格事件）與已評估和匹配的規則數量（合格事件）的統計信息。較高的非合格事件與 合格事件之比可以表明存在許多規則，這些規則要么內容最少，要么沒有內容，但是沒有成功評估。快速模式匹配器用于根據最長的內容或使用fast_pattern修改 的內容選擇一組評估規則規則中的規則選項。具有較短，通用內容的規則比具有較長，更獨特內容的規則更有可能被選擇進行評估。沒有內容的規則不會通過快速模式匹配器進行過濾，并且始終會進行評估，因此，如果可能的話，在這些規則中添加內容規則選項可以減少需要評估的次數并提高性能。

• max-在給定處理器速度和當前性能的情況下，打開Snort計算的理論最大性能。這僅對單處理器計算機有效，因為許多操作系統無法為多個CPU保留準確的內核統計信息。

• 控制臺 -在控制臺上打印統計信息。

• 文件 -將統計信息以逗號分隔的格式輸出到指定的文件。并非所有統計信息都輸出到該文件。您也可以使用snortfile，它將輸出到您定義的Snort日志目錄中。這兩個偽指令都可以在命令行上使用-Z或-perfmon-file選項覆蓋 。在啟動時，Snort會將帶有時間戳記的特殊行記錄到此文件中，以向所有讀者開放，以輕松識別由于Snort未運行而導致的統計差異。

• pktcnt-調整在檢查時間樣本之前要處理的數據包數量。由于檢查時間樣本會降低Snort的性能，因此可以提高性能。默認情況下，這是10000。

• 時間 -表示間隔之間的秒數。

• 累積或重置 -定義操作系統保留哪種丟棄統計信息。默認情況下，使用重置。

• atexitonly -Snort整個生命周期的轉儲統計信息。可以提供以下一個或多個參數來指定要在退出時轉儲的特定統計信息類型：

  • 基本統計
  • 流量統計
  • 流量統計
  • 事件統計沒有任何參數，所有啟用的統計信息僅在Snort退出時才會轉儲。

• max_file_size-定義逗號分隔文件的最大大小。在文件超過此大小之前，它將被滾動到格式為YYYY-MM-DD的新的帶日期戳的文件中，然后是YYYY-MM-DD.x，其中，每當用逗號分隔文件滾動時，x都會增加。 。最小為4096字節，最大為2147483648字節（2GB）。默認值與最大值相同。

• flow-ip-基于主機對收集IP流量分配統計信息。對于已看到IP流量的每對主機，將為兩個方向（A到B和B到A）收集以下統計信息：

  • TCP數據包
  • TCP流量（以字節為單位）
  • TCP會話建立
  • TCP會話關閉
  • UDP數據包
  • UDP流量（以字節為單位）
  • UDP會話創建
  • 其他IP數據包
  • 其他IP流量（以字節為單位）這些統計信息將在每個間隔結束時打印并重置。

• flow-ip- file-以逗號分隔的格式將流IP統計信息打印到指定的文件。包括了上面提到的所有統計信息以及人類可讀格式的主機對的IP地址。

  文件中的每一行都將具有與以下值相對應的值（按順序）：

  • IP地址A（字符串）
  • IP地址B（字符串）
  • 從A到B的TCP數據包
  • 從A到B的TCP流量（以字節為單位）
  • 從B到A的TCP數據包
  • 從B到A的TCP流量（以字節為單位）
  • 從A到B的UDP數據包
  • 從A到B的UDP流量（以字節為單位）
  • 從B到A的UDP數據包
  • 從B到A的UDP流量（以字節為單位）
  • 從A到B的其他IP數據包
  • 從A到B的其他IP流量（以字節為單位）
  • 從B到A的其他IP數據包
  • 從B到A的其他IP流量（以字節為單位）
  • TCP會話建立
  • TCP會話關閉
  • UDP會話創建

• flow-ip-memcap-在哈希表上設置內存上限，用于存儲主機對的IP流量統計信息。一旦達到上限，該表將開始刪除最近最少看到的主機對的統計信息以釋放內存。該值以字節為單位，默認值為52428800（50MB）。

2.2.6.1 例子

   preprocessor perfmonitor: \
        time 30 events flow file stats.profile max console pktcnt 10000 

    preprocessor perfmonitor: \
        time 300 file /var/tmp/snortstat pktcnt 10000

    preprocessor perfmonitor: \
        time 30 flow-ip flow-ip-file flow-ip-stats.csv pktcnt 1000

    preprocessor perfmonitor: \
        time 30 pktcnt 1000 snortfile base.csv flow-file flows.csv atexitonly flow-stats

    preprocessor perfmonitor: \
        time 30 pktcnt 1000 flow events atexitonly base-stats flow-stats console

2.2.7 HTTP檢查

HTTP Inspect是用于用戶應用程序的通用HTTP解碼器。給定一個數據緩沖區，HTTP Inspect將解碼該緩沖區，找到HTTP字段，并對字段進行規范化。HTTP Inspect可用于客戶端請求和服務器響應。

HTTP Inspect具有非常“豐富”的用戶配置。用戶可以使用各種選項配置單個HTTP服務器，這應該允許用戶模擬任何類型的Web服務器。在HTTP Inspect中，有兩個配置區域：全局和服務器。

2.2.7.1 全局配置

全局配置處理確定HTTP Inspect全局功能的配置選項。以下示例給出了通用的全局配置格式：

2.2.7.2 格式

preprocessor http_inspect: \
        global \
        iis_unicode_map <map_filename> \
        codemap <integer> \
        [detect_anomalous_servers] \
        [proxy_alert] \
        [max_gzip_mem <num>] \
        [compress_depth <num>] [decompress_depth <num>] \
        [memcap <num>] \
        disabled

您只能有一個全局配置，否則嘗試將得到一個錯誤。

2.2.7.2.1 配置

1. iis_unicode_map < map_filename>[codemap < integer>]

這是全局的iis_unicode_map文件。所述 iis_unicode_map是一個需要的配置參數。映射文件可與snort.conf駐留在同一目錄中，或通過映射文件的標準路徑指定。

該iis_unicode_map文件是Unicode編碼點地圖，它告訴HTTP解碼Unicode字符時檢查該代碼頁的使用。對于美國服務器，代碼映射通常為1252。

默認情況下 ，Snort源等目錄中提供了Microsoft US Unicode代碼點映射 。它稱為unicode.map，如果沒有其他代碼點映射可用，則應使用它。Snort提供了一個工具來生成自定義Unicode maps-ms_unicode_generator.c，該工具可從http://www.snort.org/dl/contrib/ 獲得。

注意： 請記住，此配置用于全局IIS Unicode映射，單個服務器可以引用自己的IIS Unicode映射。

2. detect_anomalous_servers

此全局配置選項可在未配置HTTP的端口上啟用常規HTTP服務器流量檢查，并在看到HTTP流量時發出警報。如果您沒有包含用戶可能訪問的所有HTTP服務器端口的默認服務器配置，請不要打開此功能。將來，我們希望將其限制在特定的網絡中，這樣才更有用，但是現在，它可以檢查所有網絡流量。默認情況下，此選項是關閉的。

3. proxy_alert

這將啟用有關HTTP服務器代理使用情況的全局警報。通過配置HTTP Inspect服務器并啟用allow_proxy_use，您將僅收到未使用已配置代理或正在使用惡意代理服務器的Web用戶的代理使用警報。

請注意，如果不需要用戶配置Web代理使用，則可能會收到很多代理警報。因此，請僅將此功能與傳統代理環境一起使用。盲目防火墻代理不算在內。

4. compress_depth < integer>
   此選項指定要解壓縮的最大數據包有效負載量。可以在1到65535之間設置此值。此選項的默認值為1460。

注意： 請注意，如果有多個策略，則使用默認策略中指定的值，并且該值將覆蓋其他策略中指定的值。如果是unlimited_decompress，則應將其設置為最大值。即使使用disable關鍵字關閉了HTTP檢查預處理器，也應在默認策略中指定此值。

5. decompress_depth <integer>
   此選項指定從壓縮的數據包有效負載中獲取的最大解壓縮數據量。可以在1到65535之間設置該值。此選項的默認值為2920。

注意:請注意，如果有多個策略，則使用默認策略中指定的值，并且該值將覆蓋其他策略中指定的值。如果是unlimited_decompress，則應將其設置為最大值。即使使用disable關鍵字關閉了HTTP檢查預處理器，也應在默認策略中指定此值。

6. max_gzip_mem <integer>

此選項（以字節為單位）確定HTTP Inspect預處理程序將用于解壓縮的最大內存量。此選項的最小允許值為3276字節。此選項確定可以在任何給定時刻解壓縮的并發會話數。此選項的默認值為838860。

此值還用于可選的SWF / PDF文件解壓縮。如果啟用了這些模式，則該相同值將設置用于文件解壓縮會話狀態信息的最大內存量。

注意:即使使用disable關鍵字關閉了HTTP檢查預處理器，也應在默認策略中指定此值。

7.memcap <integer>

此選項（以字節為單位）確定HTTP Inspect預處理器將用于記錄URI和主機名數據的最大內存量。可以在2304至603979776（576 MB）之間設置此值。此選項以及最大的uri和主機名日志記錄大小（在snort中定義）將確定將在任何給定瞬間記錄URI和主機名數據的最大HTTP會話。記錄URI數據的最大大小為2048，主機名的最大大小為256。此選項的默認值為150994944（144 MB）。

注意:即使使用disable關鍵字關閉了HTTP檢查預處理器，也應在默認策略中指定此值。如果有多個策略，則默認策略中指定的值將覆蓋其他策略中指定的值。記錄的最大http會話數= memcap /（最大uri日志記錄大小+最大主機名日志記錄大小）在snort中定義的最大uri日志記錄大小：2048在snort中定義的最大主機名日志記錄大小：256 |

8. normalize_random_nulls_in_text

此選項使用服務器響應中的UTF8的16LE，16BE，32LE和32BE UTF編碼的隨機編碼的空字節規范化文本內容。它依靠文件預處理器來確定內容是否為文本。因此，應啟用文件預處理器并使用預打包的文件魔術來配置文件預處理器，而該選項無效。

注意： 此opton依靠文件預處理器來確定在標準化之前是否可以安全地將內容視為文本。但是，由于該選項會將文件預處理器未知的文件類型視為文本，因此文件預處理器未知的非文本文件類型可能會被標準化。此類情況可能會導致檢測結果出現假陽性或假陰性。

9. fast_blocking

使用此選項可以在刷新數據之前檢查http數據。這樣可以盡早進行IPS規則評估，從而使阻止規則生效，并且盡早阻止連接，而不是在刷新數據后稍后阻止連接。該配置僅在啟用內聯規范化后才有效。

10. disabled

任何策略都允許使用此可選關鍵字，以避免數據包處理。此選項禁用預處理器。如果禁用了預處理器，則在通過配置指定時僅應用“ memcap”，“ max_gzip_mem”，“ compress_depth”和“ decompress_depth”選項。解析但不使用其他選項。任何有效的配置都可能添加了“禁用”。

2.2.7.3 示例全局配置

 preprocessor http_inspect：\
 global iis_unicode_map unicode.map 1252

2.2.7.4 服務器配置

服務器配置有兩種類型：默認和IP地址。

2.2.7.4.1 默認

此配置為未單獨配置的任何服務器提供默認服務器配置。大多數Web服務器很可能最終將使用默認配置。

2.2.7.5 示例默認配置

 preprocessor http_inspect_server：\
 server default profile all ports { 80 }

2.2.7.5.1 按IP地址配置

此格式與“默認”非常相似，唯一的區別是可以配置特定IP。

2.2.7.6 IP配置示例

preprocessor http_inspect_server: \
        server 10.1.1.1 profile all ports { 80 }

2.2.7.6.1 通過多個IP地址進行配置

此格式與“按IP地址配置”非常相似，唯一的區別是可以通過空格分隔的列表指定多個IP。每個http_inspect_server行最多只能有40個IP地址或CIDR表示法 。

2.2.7.7 示例多個IP配置

preprocessor http_inspect_server: \
        server { 10.1.1.1 10.2.2.0/24 } profile all ports { 80 }

2.2.7.8 服務器配置選項

重要說明：某些配置選項的參數為“是”或“否”。此參數指定用戶是否希望配置選項生成HTTP Inspect警報。“ yes / no”參數不指定配置選項本身是打開還是關閉，僅指定警報功能。換句話說，無論設置為“是”還是“否”，HTTP規范化仍將發生，并且基于HTTP流量的規則仍將觸發。

1. profile < all|apache|iis|iis5_0|iis4_0>

用戶可以使用預定義的HTTP服務器配置文件來配置HTTP Inspect。配置文件使用戶可以輕松地為某種類型的服務器配置預處理器，但正常操作不需要配置文件。

共有五種配置文件：all，apache，iis，iis5_0和iis4_0。

1) all

將所有的個人資料是指利用最可用的常用的招數，以規范化的URI。我們警惕更嚴重的逃避形式。這是一個很好的配置文件，可以檢測所有類型的攻擊，而與HTTP服務器無關。

表:“所有”配置文件的選項

2) apache

在Apache的配置文件用于Apache網絡服務器。這與iis配置文件的不同之處在于，它僅接受UTF-8標準Unicode編碼，而不像IIS一樣接受合法的反斜杠。Apache還接受制表符作為空白。

表：apache配置文件的選項

3) iis

在IIS輪廓模仿IIS服務器。因此，這意味著我們對每臺服務器使用IIS Unicode代碼映射，％u編碼，bare字節編碼，雙解碼，反斜杠等。

表：iis配置文件的選項

4) iis4_0，iis5_0

在IIS 4.0和IIS 5.0中，存在一個雙重解碼漏洞。這兩個配置文件與iis相同，除了默認情況下，如果URL具有雙重編碼，它們將發出警報。IIS 5.1及更高版本不支持雙解碼，因此默認情況下禁用雙解碼。

5) default,no profile

HTTP Inspect使用的默認選項不使用配置文件，如表所述:

表：默認的HTTP檢查選項

必須將概要文件指定為第一個服務器選項，并且不能與其他任何選項組合使用，但以下情況除外：

• ports
• iis_unicode_map
• allow_proxy_use
• server_flow_depth
• client_flow_depth
• post_depth
• no_alerts
• inspect_uri_only
• oversize_dir_length
• normalize_headers
• normalize_cookies
• normalize_utf
• max_header_length
• max_spaces
• max_headers
• Extended_response_inspection
• enable_cookie
• inspect_gzip
• unlimited_decompress
• normalize_javascript
• max_javascript_whitespaces
• enable_xff
• http_methods
• log_uri
• log_hostname
• small_chunk_length
• decompress_swf
• decompress_pdf
• legacy_mode

這些選項必須在配置文件選項之后指定。

2.2.7.9 例子

 preprocessor http_inspect_server: \
        server 1.1.1.1 profile all ports { 80 3128 }
ports { < port> [< port> < ...>]}

這是用戶配置HTTP服務器上要解碼的端口的方式。但是，HTTPS流量已加密，無法使用HTTP Inspect進行解碼。要忽略HTTPS通信，請使用SSL預處理器。

iis_unicode_map < map_filename> codemap < integer>

IIS Unicode映射由程序ms_unicode_generator.c生成。該程序位于Snort.org網站上的 <http://www.snort.org/dl/contrib/>目錄中。執行該程序將為其運行的系統生成Unicode映射。因此，要獲取IIS Web服務器的特定Unicode映射，請在該服務器上運行該程序并在此配置中使用該Unicode映射。

使用此選項時，用戶需要指定包含IIS Unicode映射的文件，還需要指定要使用的Unicode映射。對于美國服務器，通常為1252。這是ANSI代碼頁。您可以通過查看ms_unicode_generator輸出的可用代碼頁來選擇正確的代碼頁。

Extended_response_inspection

這將啟用擴展的HTTP響應檢查。默認的http響應檢查不檢查HTTP響應的各個字段。通過啟用此選項，將對HTTP響應進行徹底檢查。提取HTTP響應的不同字段，例如狀態代碼，狀態消息，標頭，cookie（配置了enable_cookie時）和正文，并將其保存到緩沖區中。提供了不同的規則選項來檢查這些緩沖區。

必須啟用此選項才能使用decompress_swf或decompress_pdf選項。

注意： 啟用此選項后，如果HTTP響應數據包具有正文，則任何匹配的內容模式（不帶http修飾符）將搜索響應正文（（對于gzip，則為解壓縮），而不是整個數據包有效負載。響應的標頭，應該使用帶有http_header，http_stat_code，http_stat_msg 和http_cookie之類的內容的http修飾符。

enable_cookie

此選項打開從HTTP請求和HTTP響應中提取Cookie的功能。默認情況下，cookie檢查和提取將關閉。從Cookie標題行提取的cookie并將其存儲在HTTP Cookie緩沖區中以用于HTTP請求，而從Set-Cookie提取的cookie并將其存儲在HTTP Cookie緩沖區中以進行HTTP響應。該Cookie的：和的Set-Cookie： 頭名本身帶有前導空格和CRLF終止標題行一起存儲在HTTP標頭緩沖區，而不是存儲在HTTP cookie的緩沖區。

例如：Set-Cookie：mycookie \ r \ n

在這種情況下，Set-Cookie：\ r \ n將位于HTTP標頭緩沖區和模式中 mycookie將位于HTTP cookie緩沖區中。

inspect_gzip

此選項指定HTTP檢查模塊以解壓縮HTTP響應中的壓縮數據（gzip / deflate）。在配置此選項之前，應選擇配置選項“ extended_response_inspection”。跨數據包進行解壓縮。因此，當達到“ compress_depth”或“ decompress_depth”或壓縮數據結束時，解壓縮將結束。當壓縮數據跨越多個數據包時，最后一個解壓縮數據包的狀態將用于解壓縮下一個數據包的數據。但是解壓縮的數據需要單獨檢查。（即，檢查時不合并來自不同數據包的解壓縮數據）。同樣，將要檢查的解壓縮數據量取決于配置的“ server_flow_depth”。

當解壓縮失敗時，Http Inspect會使用gid 120和sid 6生成預處理器警報。當由于zlib遇到CRC錯誤而導致解壓縮失敗時，HTTP Inspect還將為檢測模塊提供由zlib解壓縮的數據。

unlimited_decompress

此選項使用戶可以解壓縮無限的gzip數據（跨多個數據包）。當壓縮數據結束或收到亂序數據包時，解壓縮將停止。為了確保無限制的解壓縮，用戶應在默認策略中將“ compress_depth”和“ decompress_depth”設置為其最大值。單個數據包中的解壓縮仍然受到“ compress_depth”和“ decompress_depth”的限制。

decompress_swf { mode [mode]}

此選項將啟用對在GET事務中作為HTTP響應正文遇到的壓縮SWF（Adobe Flash內容）文件進行解壓縮的功能。可用的解壓縮模式為“放氣”和“ lzma”。前提條件是啟用extended_response_inspection（如上所述）。啟用后，預處理器將檢查響應主體以獲取相應的文件簽名。Deflate / ZLIB壓縮的“ CWS”和LZMA壓縮的“ ZWS”。每種減壓模式均可單獨啟用。例如 lzma或deflate或lzma deflate。壓縮的內容被“就地”解壓縮，并且內容可用于檢測/規則“ file_data”選項。如果啟用并找到，則壓縮的SWF文件簽名將轉換為“ FWS”以指示未壓縮的文件。

可以選擇使用’decompress_depth’，’compress_depth’和’unlimited_decompress’來限制解壓縮過程。SWF文件的語義類似于gzip解壓縮過程。

在解壓縮過程中，如果Deflate解壓縮失敗，則預處理器可能會生成警報120：12；如果LZMA解??壓縮失敗，則預處理器可能會生成警報120：13。

注意： 僅當Snort是在存在liblzma程序包且功能正常的情況下構建的時，LZMA減壓才可用。如果不存在LZMA軟件包，則lzma選項將指示致命的解析錯誤。如果存在liblzma軟件包，但有人希望禁用LZMA支持，則configure上的-disable-lzma選項將禁用該庫的使用。

decompress_pdf {mode[mode]}

此選項將啟用對在GET事務中作為HTTP響應主體遇到的PDF文件的壓縮部分進行解壓縮的功能。前提條件是啟用extended_response_inspection（如上所述）。

啟用后，預處理器將檢查響應正文是否有“ PDF文件被解析”，并使用單個“ / FlateDecode”過濾器定位PDF“流”。這些流就地解壓縮，替換了壓縮的內容。

可以選擇使用’decompress_depth’，’compress_depth’和’unlimited_decompress’來限制解壓縮過程。PDF文件的語義類似于gzip解壓縮過程。

在文件解析/解壓縮過程中，預處理器可能會生成幾個警報：

normalize_javascript 此選項啟用HTTP響應正文中的Javascript規范化。在配置此選項之前，應選擇配置選項extended_response_inspection。啟用此選項后，Http Inspect通過< script>標簽在HTTP響應正文中搜索Java>標簽在HTTP響應正文中搜索Java 腳本并開始對其進行規范化。當Http Inspect看到沒有類型的< script>標記時，它將被視為javascript。javascript函數（例如unescape，String.fromCharCode，decodeURI，decodeURIComponent）內的混淆數據將被標準化。在unescape / decodeURI / decodeURIComponent中處理的不同編碼為％XX，％uXXXX，XX和uXXXXi。除了這些編碼之外，Http Inspect還將檢測連續的空格并將其標準化為單個空格。Http Inspect還將規范plus并連接字符串。規則選項file_data可用于從規則訪問此規范化緩沖區。當Http檢查中的混淆級別等于或大于2時，將生成帶有SID 9和GID 120的預處理器警報。

例：

HTTP/1.1 200 OK\r\n
Date: Wed, 29 Jul 2009 13:35:26 GMT\r\n
Server: Apache/2.2.3 (Debian) PHP/5.2.0-8+etch10 mod_ssl/2.2.3 OpenSSL/0.9.8c\r\n
Last-Modified: Sun, 20 Jan 2008 12:01:21 GMT\r\n
Accept-Ranges: bytes\r\n
Content-Length: 214\r\n
Keep-Alive: timeout=15, max=99\r\n
Connection: Keep-Alive\r\n
Content-Type: application/octet-stream\r\n\r\n 
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>FIXME</title>
</head>
<body>
<script>document.write(unescape(unescape("%48%65%6C%6C%6F%2C%20%73%6E%6F%72%74%20%74%65%61%6D%21")));
</script>
</body>
</html>

上述的JavaScript將與SID 9和GIDF 120產生預處理器警報時normalize_javascript 被接通。

當轉義/編碼數據中存在一種以上類型的編碼時，Http Inspect還將生成GID 120和SID 11的預處理器警報。

例如：

 unescape("%48\x65%6C%6C%6F%2C%20%73%6E%6F%72%74%20%74%65%61%6D%21");
String.fromCharCode(0x48, 0x65, 0x6c, 0x6c, 111, 44, 32, 115, 110, 111, 114, 116, 32, 116, 101, 97, 109, 33)

\\end{verbatim}

The above obfuscation will generate the preprocessor alert with GID 120 and SID 11.

This option is turned off by default in HTTP Inspect.

\item \texttt{max\_javascript\_whitespaces $<$positive integer up to 65535$>$}
This option takes an integer as an argument.  The integer determines the maximum number
of consecutive whitespaces allowed within the Javascript obfuscated data in a HTTP
response body. The config option \texttt{normalize\_javascript} should be turned on before configuring
 this config option. When the whitespaces in the javascript obfuscated data is equal to or more
than this value a preprocessor alert with GID 120 and SID 10 is generated. The default value for 
this option is 200.  To enable, specify an integer argument to \texttt{max\_javascript\_spaces} of 1 to 65535.
Specifying a value of 0 is treated as disabling the alert.

\item \texttt{enable\_xff}

This option enables Snort to parse and log the original client IP present in the
X-Forwarded-For or True-Client-IP HTTP request headers along with the generated
events. The XFF/True-Client-IP Original client IP address is logged only with
unified2 output and is not logged with console (-A cmg) output.

\item \texttt{xff\_headers}

If/When the \texttt{enable\_xff} option is present, the \texttt{xff\_headers} option specifies a set of custom 'xff'
headers.  This option allows the definition of up to six custom headers in addition to the
two default (and always present) X-Forwarded-For and True-Client-IP headers.  The option
permits both the custom and default headers to be prioritized.  The headers/priority pairs
are specified as a list.  Lower numerical values imply a higher priority.  The headers do
not need to be specified in priority order.  Nor do the priorities need to be contiguous.
Priority values can range from 1 to 255.  The priority values and header names must be unique.
The header names must not collide with known http headers such as 'host', 'cookie',
'content-length', etc.

A example of the \texttt{xff\_header} syntax is:
\begin{verbatim}
xff_headers { [ x-forwarded-highest-priority 1 ] [ x-forwarded-second-highest-priority 2 ] \
              [ x-forwarded-lowest-priority-custom 3 ] }

默認的X-Forwarded-For和True-Client-IP標頭始終存在。可以在xff_headers配置中明確指定它們，以便確定其優先級。如果未指定，它們將自動作為最低優先級標頭添加到xff列表中。

例如，假設我們有以下（縮寫）HTTP請求標頭：

Host: www.snort.org
X-Forwarded-For: 192.168.1.1
X-Was-Originally-Forwarded-From: 10.1.1.1

使用默認的xff行為（無xff_headers），“ X-Forwarded-For”標頭將用于在Unified2日志中提供192.168.1.1原始客戶端IP地址。自定義標頭未解析。

帶有：

xff_headers { [ x-was-originally-forwarded-from 1 ] [ x-another-forwarding-header 2 ]
              [ x-forwarded-for 3 ] }

X-Was-Originally-Forwarded-From標頭是當前出現的最高優先級，其值10.1.1.1將被記錄為Unified2日志中的原始客戶端IP。

但是有：

xff_headers { [ x-was-originally-forwarded-from 3 ] [ x-another-forwarding-header 2 ] \
              [ x-forwarded-for 1 ] }

現在，X-Forwarded-For標頭具有最高優先級，并且記錄了其值192.168.1.1。

注意:可以使用工具u2spewfoo來查看Unified2日志中來自XFF / True-Client-IP的原始客戶端IP。此工具位于snort源代碼樹的tools / u2spewfoo目錄中。

server_flow_depth < integer>

這指定要檢查的服務器響應有效負載量。當 extended_response_inspection導通時，它被施加到HTTP響應體（當解壓縮數據inspect_gzip被接通），而不是HTTP標頭。當extended_response_inspection關閉時，server_flow_depth 將應用于整個HTTP響應（包括標頭）。與client_flow_depth不同 此選項適用于每個TCP會話。此選項可用于平衡IDS性能的需求和HTTP服務器響應數據的檢查級別。Snort規則以HTTP服務器響應流量為目標，當與較小的flow_depth值一起使用時，可能會導致誤報。這些規則中的大多數都以HTTP標頭為目標，或者以非標頭數據的前一百個字節中可能存在的內容為目標。標頭通常不足300個字節，但是您的里程可能會有所不同。建議將server_flow_depth設置為最大值。

可以在-1到65535之間設置此值。值-1會使Snort 在extended_response_inspection關閉時 忽略端口中定義的端口的所有服務器端流量。當extended_response_inspection 接通時，值-1引起的Snort忽略HTTP響應身體的數據，而不是HTTP標頭。相反，值為0會使Snort檢查在“端口”中定義的所有HTTP服務器有效負載（請注意，這可能會降低IDS性能）。大于0的值告訴Snort要檢查服務器響應的字節數（extended_response_inspection時不包括HTTP標頭） 在給定的HTTP會話中打開）。僅將以“ HTTP”開頭的數據包有效負載視為服務器響應的第一個數據包。如果在給定會話中HTTP響應數據包的有效負載中少于flow_depth字節，則將檢查整個有效負載。如果會話中HTTP響應數據包的有效負載中有不止flow_depth字節，則僅針對該會話檢查有效負載中的flow_depth字節。除非flow_depth設置為0，這意味著在超過65535個字節的會話HTTP響應數據包的有效載荷檢查數據的規則將是無效的默認值server_flow_depth是300注意，65535字節的最大flow_depth適用于數據流重組包也是如此。建議設置server_flow_depth 達到最大值

注意:server_flow_depth與舊的flow_depth 選項相同，它將在以后的版本中棄用。

client_flow_depth < integer>

這指定要檢查的原始客戶端請求有效負載的數量。可以在-1到1460之間設置此值。與server_flow_depth不同，該值應用于HTTP請求的第一個數據包。它不是基于會話的流深度。它的默認值為300。它主要是消除了Snort檢查較大的HTTP Cookies的麻煩，這些cookie出現在許多客戶端請求標頭的末尾。

值為-1會使Snort忽略“端口”中定義的端口的所有客戶端流量。相反，值為0會使Snort檢查在“端口”中定義的所有HTTP客戶端流量（請注意，這可能會降低IDS性能）。大于0的值告訴Snort客戶請求的第一個數據包中要檢查的字節數。如果第一個數據包的TCP有效負載（HTTP請求）中的flow_depth字節少于字節，則將檢查整個有效負載。如果第一個數據包的有效載荷中有多個flow_depth字節，則僅檢查有效載荷的flow_depth字節。除非將flow_depth設置為0，否則用于檢查客戶端請求的第一個數據包的有效載荷中超過1460字節的數據的規則將無效。請注意，最大1460字節的flow_depth也適用于流重組的數據包。建議設置client_flow_depth達到最大值。

post_depth < integer>

這指定要在客戶發布消息中檢查的數據量。可以在-1到65495之間設置該值。默認值為-1。值為-1會使Snort忽略發布消息中的所有數據。相反，值為0會使Snort檢查所有客戶端發布消息。通過僅檢查發布消息中的指定字節，可以提高性能。

ASCII < yes |no>

該ASCII解碼選項告訴我們是否解碼編碼的ASCII字符，又名％2F = /，％2E =，這是很正常的網址，ASCII編碼的使用，因此建議您禁用HTTP檢查警報此選項。

extended_ascii_uri

此選項啟用對HTTP請求URI中擴展ASCII碼的支持。默認情況下，此選項是關閉的，任何配置文件均不支持。

UTF_8 < yes |no>

UTF-8解碼選項告訴HTTP檢查解碼是在URI標準的UTF-8的Unicode序列。這遵守Unicode標準，僅使用％編碼。Apache使用此標準，因此對于任何Apache服務器，請確保已啟用此選項。至于警報，您可能想知道何時擁有UTF-8編碼的URI，但這會導致誤報，因為合法的Web客戶端使用這種類型的編碼。當 UTF_8啟用，ASCII碼解碼也使執行正確的功能。

u_encode < yes |no>

此選項模擬IIS％u編碼方案。％u編碼方案的工作方式如下：編碼方案以％u開頭，后跟4個字符，例如％uxxxx。xxxx是十六進制編碼的值，與IIS Unicode代碼點相關。此值絕對可以是ASCII。ASCII字符的編碼方式類似于％u002f = /，％u002e =。等。如果在此選項之前或之后未指定iis_unicode_map，則使用默認代碼圖。

您應該對％u編碼發出警報，因為我們不知道任何使用此編碼的合法客戶端。因此，很可能有人試圖隱蔽。

bare_byte < yes |no>

bare字節編碼是IIS的一個技巧，它在解碼UTF-8值時使用非ASCII字符作為有效值。這不是HTTP標準，因為所有非ASCII值都必須用％編碼。裸字節編碼允許用戶模擬IIS服務器并正確解釋非標準編碼。

應該啟用此解碼的警報，因為沒有合法的客戶端以這種方式對UTF-8進行編碼，因為它是非標準的。

iis_unicode < yes |no>

該iis_unicode選項開啟Unicode的代碼點映射。如果沒有在服務器配置中指定iis_unicode_map選項，則 iis_unicode使用默認的代碼映射。該iis_unicode 選項把手非ASCII碼點的IIS服務器接收和解碼正常UTF-8的請求映射。

您應該對iis_unicode選項發出警報，因為它主要出現在攻擊和逃避嘗試中。啟用iis_unicode時，還將啟用ASCII和UTF-8解碼以強制執行正確的解碼。要發出有關UTF-8解碼的警報，必須同時啟用utf_8 yes。

double_decode < yes |no>

該double_decode選項再次IIS特異性和模擬IIS功能。這種工作方式是IIS在請求URI中進行兩次傳遞，并在每個傳遞中進行解碼。在第一遍中，似乎所有類型的iis編碼都已完成：utf-8 unicode，ASCII，裸字節和％u。在第二遍中，完成以下編碼：ASCII，裸字節和％u。我們省去utf-8的原因是，我認為這是如何工作的：將％編碼的utf-8在第一遍解碼為Unicode字節，然后在第二階段解碼UTF-8。無論如何，這確實很復雜，并且為一個字符添加了大量不同的編碼。當double_decode啟用，所以ASCII也能執行正確的解碼。

non_rfc_char ![$ \ {< byte> [<byte...>]}

如果在請求URI中使用了某些非RFC字符，則該選項使用戶能夠收到警報。例如，用戶可能不希望在請求URI中看到空字節，我們可以對此進行提醒。請謹慎使用此選項，因為您可以將其配置為對所有“ /”或類似內容發出警報。它很靈活，所以要小心。

multi_slash < yes |no>

此選項將一行中的多個斜線歸一化，因此類似：“ foo ///////// bar”被規范化為“ foo / bar”。

如果要在看到多個斜杠時發出警報，請配置 yes；否則，請使用no。

iis_backslash < yes |no>

將反斜杠標準化為斜杠。這又是IIS仿真。因此，請求URI“ / foo \bar”被標準化為“ / foo / bar”。

directory < yes |no>

此選項將目錄遍歷和自引用目錄標準化。

目錄：

/foo/fake\_dir/../bar

規范化為：

/ foo / bar

目錄：

/foo/./bar

規范化為：

/ foo / bar

如果要配置警報，請指定“ 是”，否則，請指定“ 否”。由于某些網站使用目錄遍歷引用文件，因此該警報可能會產生誤報。

apache_whitespace < yes |no>

此選項處理使用Tab作為空格定界符的非RFC標準。Apache使用此選項，因此，如果仿真的Web服務器是Apache，請啟用此選項。關于此選項的警報可能很有趣，但也可能容易出現誤報。

iis_delimiter < yes |no>

最初是特定于IIS的，但是Apache很好地采用了這種非標準的分隔符。由于這很常見，因此我們始終將其作為標準，因為最受歡迎的Web服務器都接受它。但是您仍然可以在此選項上收到警報。

chunk_length <non-zero positive integer>

此選項是異常檢測器，用于異常大的塊大小。這將利用Apache塊編碼漏洞，并可能會警告使用塊編碼的HTTP隧道。

small_chunk_length {< chunk size> <consecutive chunks> }

當客戶端或服務器使用Transfer-Encoding：chunked時，此選項是連續小塊大小的逃避檢測器。 < chunk size>指定將被視為較小的最大塊大小。< consecutive chunks>指定連續小塊的數量< = < chunk size>。默認情況下，此選項是關閉的。每個的最大值為255，< chunk size>為0禁用。對于客戶端小塊，生成的事件為gid：119，sid：26和對于服務器小塊的gid：120，sid：7。

例：

small_chunk_length {10 5}

如果連續5個塊大小等于或小于10，則表示警報。

no_pipeline_req

此選項關閉HTTP管道解碼，并且在需要時可以提高性能。默認情況下，將檢查管道請求是否受到攻擊，但是啟用此選項后，不會按HTTP協議字段對管道請求進行解碼和分析。僅使用通用模式匹配進行檢查。

non_strict

此選項為Apache服務器解碼URI的中斷方式打開非嚴格URI解析。僅在將接受以下URI的服務器上使用此選項：“ get /index.html alsjdfk alsj lj aj la jsj s \n”。non_strict選項假定URI在第一和第二個空間之間，即使第二個空間之后沒有有效的HTTP標識符也是如此。

allow_proxy_use

通過指定此關鍵字，用戶允許在此服務器上使用代理。這意味著如果使用proxy_alert全局關鍵字，則不會生成警報。如果未啟用proxy_alert關鍵字，則此選項不起作用。該allow_proxy_use關鍵字只是一種打壓授權服務器的未經授權的代理使用的方式。

no_alerts

該選項關閉由HTTP Inspect預處理器模塊生成的所有警報。這對規則集中的HTTP規則沒有影響。沒有指定參數。

oversize_dir_length <non-zero positive integer

此選項采用非零正整數作為參數。該參數指定URL目錄的最大char目錄長度。如果url目錄大于此參數大小，則生成警報。一個好的參數值是300個字符。這應該將警報限制為IDS規避類型的攻擊，例如whisker -i 4。

inspect_uri_only

這是性能優化。啟用后，將僅檢查HTTP請求的URI部分是否受到攻擊。由于此字段通常包含90-95％的Web攻擊，因此您將捕獲大多數攻擊。因此，如果您需要額外的性能，請啟用此優化。重要的是要注意，如果使用此選項時沒有任何不滿意的規則，則不會進行檢查。這很明顯，因為僅使用uricontent規則檢查URI ，并且如果沒有可用的規則，則沒有要檢查的內容。

例如，如果我們具有以下規則集：

alert tcp any any-> any 80（msg：“ content”; content：“ foo”;）

然后我們檢查以下URI：

get/foo.htm http / 1.0 \ r \ n \ r \ n

啟用inspect_uri_only 時不會生成警報。所述 inspect_uri_only配置關閉除了各種形式的檢測uricontent檢查。

max_header_length < positive integer up to 65535>

此選項以整數作為參數。整數是HTTP客戶端請求標頭字段允許的最大長度。超過此長度的請求將導致“長標頭”警報。默認情況下，此警報處于關閉狀態。要啟用該功能，請將max_header_length的整數參數指定為1到65535。將值指定為0將被視為禁用警報。

max_spaces < positive integer up to 65535>

此選項以整數作為參數。整數確定HTTP客戶端請求行折疊所允許的最大空格數。請求折疊有等于或大于此值的空格的標頭將導致SID 26和GID 119出現“空間飽和”警報。此選項的默認值為200。要啟用，請為max_spaces指定1到65535 的整數參數。將值指定為0將被視為禁用警報。

Webroot < yes |no>

當目錄遍歷超過Web服務器根目錄時，此選項將生成警報。與目錄選項相比，這產生的誤報要少得多，因為它不會警告駐留在Web服務器目錄結構內的目錄遍歷。它僅在目錄遍歷超過與某些Web攻擊相關聯的Web服務器根目錄時發出警報。

tab_uri_delimiter

此選項打開使用制表符（0x09）作為URI的分隔符。Apache接受制表符作為定界符；IIS沒有。對于IIS，應將URI中的選項卡視為任何其他字符。不管此選項是否啟用，如果在制表符前面加一個空格字符（0x20），該選項卡都將被視為空格。沒有指定參數。

normalize_headers

此選項打開不包括Cookies的HTTP標頭字段的規范化（使用與URI規范化相同的配置參數（即多斜杠，目錄等）。對于規范化HTTP標頭中可能出現的引薦來源URI很有用 。

normalize_cookies

此選項打開HTTP Cookie字段的規范化（使用與URI規范化相同的配置參數（即多斜杠，目錄等）。對于規范化可能已編碼的HTTP Cookie中的數據很有用。

normalize_utf

此選項打開HTTP響應主體的規范化，其中Content-Type標頭將字符集列出為“ utf-16le”，“ utf-16be”，“ utf-32le”或“ utf-32be”。HTTP Inspect將嘗試將其標準化回8位編碼，如果額外字節非零，則會生成警報。

max_headers < positive integer up to 1024>

此選項以整數作為參數。整數是HTTP客戶端請求標頭字段的最大數量。包含比此值更多的HTTP標頭的請求將引發“最大標頭”警報。默認情況下，警報處于關閉狀態。要啟用該功能，請將max_headers的整數參數指定為1到1024。將值指定為0將被視為禁用警報。

http_methods {cmd [cmd] }除了在預處理器中默認檢查的HTTP請求方法（GET和POST）之外，它還指定其他HTTP請求方法。該列表應括在大括號內，并以空格，制表符，換行符或回車符分隔。config選項，花括號和方法也需要用花括號分隔。

http_methods {PUT CONNECT}

注意:請注意，方法名稱的最大長度為256。

log_uri

此選項使HTTP Inspect預處理器可以解析HTTP請求中的URI數據，并將其與該會話的所有生成的事件一起記錄下來。需要在HTTP端口上打開流重組以啟用日志記錄。如果會話中有多個HTTP請求，則將記錄警報期間最新HTTP請求的URI數據。記錄的最大URI為2048。

*注意： *請注意，此記錄僅與Unified2輸出一起記錄，而不與控制臺輸出（-A cmg）一起記錄。u2spewfoo可用于從Unified2讀取此數據。

log_hostname

此選項使HTTP Inspect預處理器可以解析HTTP請求的“主機”標頭中的主機名數據，并將其與該會話的所有生成的事件一起記錄下來。需要在HTTP端口上打開流重組以啟用日志記錄。如果會話中有多個HTTP請求，則將記錄警報期間最新HTTP請求的主機名數據。在一個HTTP請求中有多個“主機”標頭的情況下，將生成帶有sid 24的預處理器警報。記錄的最大主機名長度為256。

*注意： *請注意，此記錄僅與Unified2輸出一起記錄，而不與控制臺輸出（-A cmg）一起記錄。u2spewfoo可用于從Unified2讀取此數據。

legacy_mode 默認情況下，不支持HTTP2通信。您可以使用“ legacy_mode no”來啟用HTTP2支持。如果配置了http傳統模式，則禁用HTTP2檢查。

2.2.7.10 例子

preprocessor http_inspect_server: \
        server 10.1.1.1 \
        ports { 80 3128 8080 } \
        server_flow_depth 0 \
        ascii no \
        double_decode yes \
        non_rfc_char { 0x00 } \
        chunk_length 500000 \
        non_strict \
        no_alerts

    preprocessor http_inspect_server: \
        server default \ 
        ports  { 80 3128 }  \
        non_strict \
        non_rfc_char  { 0x00 }  \
        server_flow_depth 300  \
        apache_whitespace yes \
        directory no \
        iis_backslash no \
        u_encode yes \
        ascii no \
        chunk_length 500000 \
        bare_byte yes \
        double_decode yes \
        iis_unicode yes \ 
        iis_delimiter yes \
        multi_slash no

    preprocessor http_inspect_server: \
        server default \
        profile all \
        ports { 80 8080 }

2.2.8 SMTP預處理器

SMTP預處理器是用于用戶應用程序的SMTP解碼器。給定一個數據緩沖區，SMTP將解碼該緩沖區并查找SMTP命令和響應。它還將標記命令，數據頭數據主體節和TLS數據。

SMTP處理無狀態和有狀態處理。它保存各個數據包之間的狀態。但是，保持正確的狀態取決于流客戶端的重組（即，丟失一致的流數據會導致狀態丟失）。

2.2.8.1 配置

SMTP具有通常的配置項，例如port和 inspection_type。此外，可以對SMTP命令行進行標準化以刪除多余的空格。可以忽略TLS加密的流量，從而提高了性能。此外，可以忽略常規郵件數據，以提高性能。由于針對郵件數據的攻擊很少（在當前的snort規則集中沒有），因此這樣做相對安全，并且可以提高數據檢查的性能。

配置選項如下所述：

1. ports{< port> [<port>] ...}

這指定在哪些端口上檢查SMTP數據。通常，對于加密的SMTP，這將包括25，可能包括465。

2. inspection_type <stateful | stateless>

指示是以有狀態還是無狀態模式進行操作。

3. normalize<all| none| cmds>

這將打開標準化。規范化檢查命令后是否有多個空格字符。空格字符定義為空格（ASCII 0x20）或制表符（ASCII 0x09）。

• all 檢查所有命令

• none將關閉所有命令的規范化。

• cmds 僅檢查使用normalize_cmds參數列出的命令。

4. ignore_data

處理規則時，請忽略郵件的數據部分（郵件頭除外）。

5. ignore_tls_data

處理規則時，請忽略TLS加密的數據。

6. max_command_line_len <int>

如果SMTP命令行的長度超過此值，則發出警報。缺少此選項或為“ 0”表示永遠不會在命令行長度上發出警報。RFC 2821建議使用512作為最大命令行長度。

7. max_header_line_len <int>

如果SMTP DATA標頭行長于此值，則發出警報。缺少此選項或為“ 0”表示從不對數據標題行的長度發出警報。RFC 2821建議使用1024作為最大數據標題行長度。

8. max_response_line_len <int>

SMTP響應行長于此值時發出警報。如果沒有此選項或為“ 0”，則表示永遠不會在響應行長度上發出警報。RFC 2821建議使用512作為最大響應線長度。

9. alt_max_command_line_len <int> {<cmd> [<cmd>]}

覆蓋max_command_line_len的特定命令。

10. no_alerts

關閉該預處理器的所有警報。

11. invalid_cmds {<Space-delimited list of commands>}

警報此命令是否從客戶端發送。默認為空列表。

12. valid_cmds {<Space-delimited list of commands>}

有效命令列表。我們不會在此列表中提醒命令。默認值為空列表，但預處理器對此列表進行了硬編碼：

 {ATRN AUTH BDAT DATA DEBUG EHLO EMAL ESAM ESND ESOM ETRN EVFY EXPN HELO HELP IDENT MAIL NOOP QUIT RCPT RSET SAML SOML SEND ONEX QUEU STARTTLS TICK TIME TURN TURNME VERB VRFY X-EXPS X-LINK2STATE XADR XAUTH XCENE XCUTH XCRE } 

13.data_cmds {<Space-delimited list of commands>}

以數據定界符結尾發起數據發送的命令列表，與RFC 5321中的DATA命令相同- “ <CRLF>。<CRLF>”。默認值為{DATA}。

14. binary_data_cmds {<Space-delimited list of commands>}

初始化數據發送并在命令后使用長度值指示要發送的數據量的命令列表，類似于RFC 3030中的BDAT命令。默認值為{BDAT XEXCH50}。

15. auth_cmds {<Space-delimited list of commands>}

在客戶端和服務器之間啟動身份驗證交換的命令列表。默認值為{AUTH XAUTH X-EXPS}。

16. alert_unknown_cmds

如果我們不識別命令，則發出警報。默認為關閉。

17. normalize_cmds {<Space-delimited list of commands>}

標準化此命令列表默認為{RCPT VRFY EXPN}。

18. xlink2state {enable| disable[drop]}

啟用/禁用xlink2state警報。如果收到警告，則刪除。默認為 啟用。

19. print_cmds

列出預處理器可以理解的所有命令。通常不會在配置中將其打印出來，因為它可以打印大量數據。

20. disabled

在配置中禁用SMTP預處理器。當在不打開SMTP預處理程序的情況下指定默認解碼配置中的解碼深度（例如b64_decode_depth，qp_decode_depth， uu_decode_depth，bitenc_decode_depth或用于對max_mime_mem進行解碼的memcap時，這很有用）。

21. b64_decode_depth

此配置選項用于關閉/打開或設置用于解碼base64編碼的MIME附件的base64解碼深度。值的范圍是-1到65535。值-1將關閉MIME附件的base64解碼。值0將base64編碼的MIME附件的解碼設置為無限制。非0或-1的值限制對base64 MIME附件的解碼，并應用于每個附件。解碼失敗時，將生成sid 10的SMTP預處理器警報（如果啟用）。

一個數據包中的多個MIME附件/數據通過管道傳輸。啟用狀態檢查后，跨多個數據包的base64編碼的MIME附件/數據也會被解碼。

使用規則選項file_data可以檢測到解碼后的數據。

該選項替換了已棄用的選項enable_mime_decoding和 max_mime_depth。建議用戶輸入一個為4的倍數的值。當指定的值不是4的倍數時，SMTP預處理器會將其向上舍入為4的下一個倍數。

如果有多個配置，則非默認配置中指定的值不能超過默認配置中指定的值。

22. qp_decode_depth

此配置選項用于關閉/打開或設置用于對Quoted-Printable（QP）編碼的MIME附件進行解碼的Quoted-Printable解碼深度。值的范圍是-1至65535。值-1將關閉MIME附件的QP解碼。值0將QP編碼的MIME附件的解碼設置為無限制。0或-1以外的值限制QP MIME附件的解碼，并按附件應用。解碼失敗時，將生成sid 11的SMTP預處理器警報（如果啟用）。

一個數據包中的多個MIME附件/數據通過管道傳輸。啟用狀態檢查后，跨多個數據包的QP編碼MIME附件/數據也會被解碼。

使用規則選項file_data可以檢測到解碼后的數據。如果有多個配置，則非默認配置中指定的值不能超過默認配置中指定的值。

23. bitenc_decode_depth

此配置選項用于關閉/打開或設置用于提取未編碼MIME附件的未編碼MIME提取深度。值的范圍是-1到65535。值-1會關閉對這些MIME附件的提取。值為0會將這些MIME附件的提取設置為無限制。0或-1以外的值限制提取這些MIME附件，并按附件應用。

一個數據包中的多個MIME附件/數據通過管道傳輸。啟用狀態檢查時，也會提取多個數據包之間的未編碼MIME附件/數據。

使用規則選項file_data可以檢測到提取的數據。如果有多個配置，則非默認配置中指定的值不能超過默認配置中指定的值。

24. uu_decode_depth

此配置選項用于關閉/打開或設置用于解碼Unix至Unix（UU）編碼附件的Unix至Unix解碼深度。取值范圍是-1到65535。-1表示關閉SMTP附件的UU解碼。值0將UU編碼的SMTP附件的解碼設置為無限制。0或-1以外的值限制對UU SMTP附件的解碼，并應用于每個附件。解碼失敗時，將生成sid 13的SMTP預處理器警報（如果啟用）。

一個數據包中的多個UU附件/數據都通過管道傳輸。啟用狀態檢查后，跨多個數據包的UU編碼SMTP附件/數據也會被解碼。

使用規則選項file_data可以檢測到解碼后的數據。如果有多個配置，則非默認配置中指定的值不能超過默認配置中指定的值。

25. enable_mime_decoding

啟用Mime附件/數據的Base64解碼。一個數據包中有多個base64編碼的MIME附件/數據被流水線處理。啟用狀態檢查后，跨多個數據包的base64編碼的MIME附件/數據也會被解碼。當達到max_mime_depth或最大MIME會話（使用max_mime_depth和max_mime_mem計算 ）或編碼數據結束時，對base64編碼附件/數據的解碼 結束。使用規則選項file_data可以檢測到解碼后的數據。
不建議使用此選項。使用選項b64_decode_depth可以關閉或打開base64解碼。

26. max_mime_depth <int>

指定每個SMTP附件要解碼的base64編碼數據的最大數量。該選項的取值范圍是4到20480字節。缺省值為1460字節的snort。

建議用戶輸入一個為4的倍數的值。當指定的值不是4的倍數時，SMTP預處理器會將其向上舍入為4的下一個倍數。

不建議使用此選項。使用選項b64_decode_depth可以關閉或打開base64解碼。

27. max_mime_mem <int>

此選項（以字節為單位）確定SMTP預處理器將用于解碼base64編碼/帶引號的可打印/非編碼MIME附件/數據或Unix-to-Unix編碼的附件的最大內存量。此值可以設置為3276字節至100MB。

此選項以及最大解碼深度將確定將在任何給定瞬間解碼的SMTP會話。此選項的默認值為838860。

注意：建議設置此值，以使如下計算的最大smtp會話至少為1。

最大smtp會話= max_mime_mem /（2 * max of（b64_decode_depth， uu_decode_depth，qp_decode_depth 或bitenc_decode_depth））

例如，如果b64_decode_depth為0（表示無限解碼），而 qp_decode_depth為100，則

最大smtp會話= max_mime_mem / 2 * 65535（b64_decode_depth的最大值）

如果有多個配置，則非默認配置的max_mime_mem將被默認配置的值覆蓋。因此，用戶需要在默認配置中定義它，并且禁用新關鍵字（用于禁用配置中的SMTP預處理程序）。

28. log_mailfrom
    此選項使SMTP預處理程序可以解析和記錄從“ MAIL FROM”命令中提取的發件人的電子郵件地址，以及該會話的所有生成的事件。此選項記錄的最大字節數為1024。

請注意，此記錄僅與Unified2輸出一起記錄，而不與控制臺輸出（-A cmg）一起記錄。u2spewfoo可用于從Unified2讀取此數據。

29. log_rcptto
    此選項使SMTP預處理程序可以解析和記錄從“ RCPT TO”命令中提取的收件人的電子郵件地址，以及該會話的所有生成的事件。多個收件人后面加上逗號。此選項記錄的最大字節數為1024。

請注意，此記錄僅與Unified2輸出一起記錄，而不與控制臺輸出（-A cmg）一起記錄。u2spewfoo可用于從Unified2讀取此數據。

30. log_filename
    此選項使SMTP預處理程序可以解析和記錄從MIME主體中的Content-Disposition標頭提取的MIME附件文件名以及該會話的所有生成的事件。多個文件名后面加上逗號。此選項記錄的最大字節數為1024。

請注意，這僅與Unified2輸出一起記錄，而不與控制臺輸出（-A cmg）一起記錄。u2spewfoo可用于從Unified2讀取此數據。

31. log_email_hdrs
    此選項使SMTP預處理程序可以解析和記錄從SMTP數據中提取的SMTP電子郵件標頭以及該會話的所有生成的事件。提取和記錄的字節數取決于email_hdrs_log_depth。

請注意，這僅與Unified2輸出一起記錄，而不與控制臺輸出（-A cmg）一起記錄。u2spewfoo可用于從Unified2讀取此數據。

32. email_hdrs_log_depth <int>
    此選項指定記錄電子郵件標題的深度。此選項的允許范圍是0-20480。值為0將禁用電子郵件標題記錄。此選項的默認值為1464。

請注意，如果有多個策略，則使用默認策略中指定的值，并且目標策略中指定的值將被默認值覆蓋。即使禁用了SMTP配置，也必須在默認策略中配置此選項。

33. memcap <int>
    此選項以字節為單位確定SMTP預處理器將用于記錄文件名，MAIL FROM地址，RCPT TO地址和電子郵件標題的最大內存量。該值以及用于記錄MAIL FROM，RCPT TO，文件名和email_hdrs_log_depth的緩沖區大小 將確定在任何給定時間記錄電子郵件標題的最大SMTP會話。達到此內存限制后，SMTP將停止記錄文件名，MAIL FROM地址，RCPT TO地址和電子郵件標題，直到有可用的內存為止。

在任何給定時間記錄電子郵件標題的最大SMTP會話= memcap /（1024 + 1024 + 1024 + email_hdrs_log_depth）

大小1024是用于記錄文件名，RCPTTO和MAIL FROM地址的最大緩沖區大小。

該選項的默認值為838860。此選項的允許范圍為3276到104857600。當在多個配置中指定此選項時，將使用默認配置中指定的值。即使禁用了SMTP配置，也必須在默認配置中配置此選項。

請注意，如果有多個策略，則使用默認策略中指定的值，并且目標策略中指定的值將被默認值覆蓋。即使禁用了SMTP配置，也必須在默認策略中配置此選項。

2.2.8.2 例子

preprocessor SMTP:
        ports { 25 }
        inspection_type stateful
        normalize cmds
        normalize_cmds { EXPN VRFY RCPT }
        ignore_data
        ignore_tls_data
        max_command_line_len  512
        max_header_line_len   1024
        max_response_line_len 512
        no_alerts
        alt_max_command_line_len 300 { RCPT }
        invalid_cmds { }
        valid_cmds { }
        xlink2state { disable }
        print_cmds
        log_filename
        log_email_hdrs
        log_mailfrom
        log_rcptto
        email_hdrs_log_depth 2920
        memcap 6000

preprocessor SMTP:
     b64_decode_depth 0
     max_mime_mem 4000
     memcap 6000
     email_hdrs_log_depth 2920
     disabled

2.2.8.3 默認

preprocessor SMTP: \
        ports { 25 } \
        inspection_type stateful \
        normalize cmds \
        normalize_cmds { EXPN VRFY RCPT } \
        alt_max_command_line_len 260 { MAIL } \
        alt_max_command_line_len 300 { RCPT } \
        alt_max_command_line_len 500 { HELP HELO ETRN } \
        alt_max_command_line_len 255 { EXPN VRFY }

2.2.8.4 Note

RCPT TO：和MAIL FROM：是SMTP命令。對于預處理器配置，它們分別稱為RCPT和MAIL。在代碼中，預處理器實際上將RCPT和MAIL映射到正確的命令名稱。

2.2.9 POP預處理器

POP是用于用戶應用程序的POP3解碼器。給定一個數據緩沖區，POP將解碼該緩沖區并查找POP3命令和響應。它還將標記命令，數據頭數據主體節，并提取POP3附件并對其進行適當解碼。

POP將處理狀態處理。它保存各個數據包之間的狀態。但是，保持正確的狀態取決于流的服務器端的重組（即，丟失一致的流數據會導致狀態丟失）。

對于POP，應打開流。請確保將POP端口添加到stream5端口以進行正確的重組。

POP預處理器使用GID 142注冊事件。

2.2.9.1 配置

配置選項如下所述：

1. ports{<port> [<port>] ...}

這指定在哪些端口上檢查POP數據。通常，它將包括110。如果未指定，則默認端口為110。

2. disabled

在配置中禁用POP預處理器。當指定解碼深度很有用。（例如b64_decode_depth，qp_decode_depth， uu_decode_depth，bitenc_decode_depth或默認配置中用于解碼的memcap,而不打開POP預處理程序時）

3. b64_decode_depth

此配置選項用于關閉/打開或設置用于解碼base64編碼的MIME附件的base64解碼深度。值的范圍是-1到65535。值-1將關閉MIME附件的base64解碼。值0將base64編碼的MIME附件的解碼設置為無限制。非0或-1的值限制對base64 MIME附件的解碼，并應用于每個附件。解碼失敗時，將生成sid 4的POP預處理器警報（如果啟用）。

一個數據包中的多個MIME附件/數據通過管道傳輸。啟用狀態檢查后，跨多個數據包的base64編碼的MIME附件/數據也會被解碼。

使用規則選項file_data可以檢測到解碼后的數據。
建議用戶輸入一個為4的倍數的值。當指定的值不是4的倍數時，POP預處理器會將其向上舍入為4的下一個倍數。
如果有多個配置，則非默認配置中指定的值不能超過默認配置中指定的值。

4. qp_decode_depth

此配置選項用于關閉/打開或設置用于對Quoted-Printable（QP）編碼的MIME附件進行解碼的Quoted-Printable解碼深度。值的范圍是-1至65535。值-1將關閉MIME附件的QP解碼。值0將QP編碼的MIME附件的解碼設置為無限制。0或-1以外的值限制QP MIME附件的解碼，并按附件應用。解碼失敗時，將生成sid 5的POP預處理器警報（如果啟用）。

一個數據包中的多個MIME附件/數據通過管道傳輸。啟用狀態檢查后，跨多個數據包的QP編碼MIME附件/數據也會被解碼。

使用規則選項file_data可以檢測到解碼后的數據。如果有多個配置，則非默認配置中指定的值不能超過默認配置中指定的值。

5. bitenc_decode_depth

此配置選項用于關閉/打開或設置用于提取未編碼MIME附件的未編碼MIME提取深度。值的范圍是-1到65535。值-1會關閉對這些MIME附件的提取。值為0會將這些MIME附件的提取設置為無限制。0或-1以外的值限制提取這些MIME附件，并按附件應用。

一個數據包中的多個MIME附件/數據通過管道傳輸。啟用狀態檢查時，也會提取多個數據包之間的未編碼MIME附件/數據。

使用規則選項file_data可以檢測到提取的數據。如果有多個配置，則非默認配置中指定的值不能超過默認配置中指定的值。

6. uu_decode_depth

此配置選項用于關閉/打開或設置用于解碼Unix至Unix（UU）編碼附件的Unix至Unix解碼深度。取值范圍是-1到65535。-1表示關閉POP附件的UU解碼。值0將UU編碼的POP附件的解碼設置為無限制。0或-1以外的值限制對UU POP附件的解碼，并應用于每個附件。解碼失敗時，將生成sid 7的POP預處理器警報（如果啟用）。

一個數據包中的多個UU附件/數據都通過管道傳輸。啟用狀態檢查后，跨多個數據包的UU編碼POP附件/數據也會被解碼。

使用規則選項file_data可以檢測到解碼后的數據。如果有多個配置，則非默認配置中指定的值不能超過默認配置中指定的值。

7. memcap <int>

此選項（以字節為單位）確定POP預處理器將用于解碼base64編碼/帶引號的可打印/非編碼MIME附件/數據或Unix-to-Unix編碼的附件的最大內存量。此值可以設置為3276字節至100MB。

此選項以及最大解碼深度將確定將在任何給定瞬間解碼的POP會話。此選項的默認值為838860。

注意：建議設置此值，以使如下計算的最大彈出會話數至少為1。

最大彈出會話= memcap /（2 * max of（b64_decode_depth， uu_decode_depth，qp_decode_depth 或bitenc_decode_depth））

例如，如果b64_decode_depth為0（表示無限解碼），而 qp_decode_depth為100，則

最大彈出會話= memcap / 2 * 65535（b64_decode_depth的最大值）

如果有多個配置，則非默認配置的memcap將被默認配置的值覆蓋。因此，用戶需要在默認配置中定義它，并禁用新關鍵字（用于禁用配置中的POP預處理程序）。

當超過用于解碼的memcap（memcap）時，將生成sid 3的POP預處理器警報（啟用時）。

2.2.9.2 例子

preprocessor pop: \
ports { 110 } \
memcap 1310700 \
qp_decode_depth -1 \
b64_decode_depth 0 \
bitenc_decode_depth 100


preprocessor pop: \
memcap 1310700 \
qp_decode_depth 0 \
disabled

2.2.9.3 默認

preprocessor pop: \
 ports { 110 } \
 b64_decode_depth 1460 \
 qp_decode_depth 1460 \
 bitenc_decode_depth 1460 \
 uu_decode_depth 1460

2.2.10 IMAP預處理器

IMAP是用于用戶應用程序的IMAP4解碼器。給定一個數據緩沖區，IMAP將解碼該緩沖區并查找IMAP4命令和響應。它還將標記命令，數據頭數據主體節，并提取IMAP4附件并對其進行適當解碼。

IMAP將處理狀態處理。它保存各個數據包之間的狀態。但是，保持正確的狀態取決于流的服務器端的重組（即，丟失一致的流數據會導致狀態丟失）。

應為IMAP打開流。請確保將IMAP端口添加到stream5端口以正確重組。

IMAP預處理器使用GID 141注冊事件。

2.2.10.1 配置

配置選項如下所述：

1. ports{<port> [<port>] ...}

這指定在哪些端口上檢查IMAP數據。通常，這將包括143。如果未指定默認端口，則為143。

2. disabled

在配置中禁用IMAP預處理程序。當指定解碼深度很有用。（例如b64_decode_depth，qp_decode_depth， uu_decode_depth，bitenc_decode_depth而不打開IMAP預處理程序時）

3. b64_decode_depth

此配置選項用于關閉/打開或設置用于解碼base64編碼的MIME附件的base64解碼深度。值的范圍是-1到65535。值-1將關閉MIME附件的base64解碼。值0將base64編碼的MIME附件的解碼設置為無限制。非0或-1的值限制對base64 MIME附件的解碼，并應用于每個附件。解碼失敗時，會生成（如果啟用）帶有sid 4的IMAP預處理程序警報。

一個數據包中的多個MIME附件/數據通過管道傳輸。啟用狀態檢查后，跨多個數據包的base64編碼的MIME附件/數據也會被解碼。

使用規則選項file_data可以檢測到解碼后的數據。
建議用戶輸入一個為4的倍數的值。當指定的值不是4的倍數時，IMAP預處理器會將其向上舍入為4的下一個倍數。
如果有多個配置，則非默認配置中指定的值不能超過默認配置中指定的值。

4. qp_decode_depth

此配置選項用于關閉/打開或設置用于對Quoted-Printable（QP）編碼的MIME附件進行解碼的Quoted-Printable解碼深度。值的范圍是-1至65535。值-1將關閉MIME附件的QP解碼。值0將QP編碼的MIME附件的解碼設置為無限制。0或-1以外的值限制QP MIME附件的解碼，并按附件應用。解碼失敗時，會生成（如果啟用）帶有sid 5的IMAP預處理程序警報。

一個數據包中的多個MIME附件/數據通過管道傳輸。啟用狀態檢查后，跨多個數據包的QP編碼MIME附件/數據也會被解碼。

使用規則選項file_data可以檢測到解碼后的數據。如果有多個配置，則非默認配置中指定的值不能超過默認配置中指定的值。

5. bitenc_decode_depth

此配置選項用于關閉/打開或設置用于提取未編碼MIME附件的未編碼MIME提取深度。值的范圍是-1到65535。值-1會關閉對這些MIME附件的提取。值為0會將這些MIME附件的提取設置為無限制。0或-1以外的值限制提取這些MIME附件，并按附件應用。

一個數據包中的多個MIME附件/數據通過管道傳輸。啟用狀態檢查時，也會提取多個數據包之間的未編碼MIME附件/數據。

使用規則選項file_data可以檢測到提取的數據。如果有多個配置，則非默認配置中指定的值不能超過默認配置中指定的值。

6. uu_decode_depth

此配置選項用于關閉/打開或設置用于解碼Unix至Unix（UU）編碼附件的Unix至Unix解碼深度。取值范圍是-1到65535。取值-1會關閉IMAP附件的UU解碼。值0將UU編碼的IMAP附件的解碼設置為無限制。0或-1以外的值將限制UU IMAP附件的解碼，并按附件應用。解碼失敗時，會生成（如果啟用）帶有sid 7的IMAP預處理程序警報。

一個數據包中的多個UU附件/數據都通過管道傳輸。啟用狀態檢查后，跨多個數據包的UU編碼IMAP附件/數據也會被解碼。

使用規則選項file_data可以檢測到解碼后的數據。如果有多個配置，則非默認配置中指定的值不能超過默認配置中指定的值。

7. memcap<int>

此選項（以字節為單位）確定IMAP預處理器將用于解碼base64編碼/帶引號的可打印/非編碼MIME附件/數據或Unix-Unix編碼附件的最大內存量。此值可以設置為3276字節至100MB。

此選項以及最大解碼深度將確定將在任何給定時刻解碼的IMAP會話。此選項的默認值為838860。

注意：建議設置此值，以使按以下方式計算的最大imap會話至少為1。

最大imap會話數= memcap /（2 *（b64_decode_depth， uu_decode_depth，qp_decode_depth 或bitenc_decode_depth的最大值））

例如，如果b64_decode_depth為0（表示無限解碼），而 qp_decode_depth為100，則

最大imap會話= memcap / 2 * 65535（b64_decode_depth的最大值）

如果有多個配置，則非默認配置的memcap將被默認配置的值覆蓋。因此，用戶需要在默認配置中定義它，并禁用new關鍵字（用于禁用配置中的IMAP預處理程序）。

當超過用于解碼的memcap（memcap）時，將生成sid 3的IMAP預處理程序警報（啟用時）。

2.2.10.2 例子

preprocessor imap: \
ports { 110 } \
memcap 1310700 \
qp_decode_depth -1 \
b64_decode_depth 0 \
bitenc_decode_depth 100

preprocessor imap: \
memcap 1310700 \
qp_decode_depth 0 \
disabled

2.2.10.3 默認

preprocessor imap:
 ports { 110 }
 b64_decode_depth 1460
 qp_decode_depth 1460
 bitenc_decode_depth 1460
 uu_decode_depth 1460

2.2.11 FTP / Telnet預處理器

FTP / Telnet是對Telnet解碼器的改進，并為FTP和Telnet數據流提供狀態檢查功能。FTP / Telnet將解碼流，識別FTP命令和響應以及Telnet轉義序列，并對字段進行規范化。FTP / Telnet對客戶端請求和服務器響應均起作用。

FTP / Telnet具有處理無狀態處理的功能，這意味著它僅在逐個數據包的基礎上查找信息。

默認設置是在狀態檢查模式下運行FTP / Telnet，這意味著它將查找信息并正確處理重組后的數據。

FTP / Telnet具有非常“豐富”的用戶配置，類似于HTTP Inspect。用戶可以使用各種選項配置各個FTP服務器和客戶端，這應該允許用戶模擬任何類型的FTP服務器或FTP客戶端。在FTP / Telnet中，有四個配置區域：全局，Telnet，FTP客戶端和FTP服務器。

注意： 某些配置選項的參數為yes或no。此參數指定用戶是否希望配置選項生成ftptelnet警報。該選項的存在指示該選項本身已打開，而yes / no參數適用于與該選項關聯的警報功能。

2.2.11.1 全局配置

全局配置處理確定FTP / Telnet全局功能的配置選項。以下示例給出了通用的全局配置格式：

2.2.11.2 格式

preprocessor ftp_telnet: \
        global \
        inspection_type stateful \
        encrypted_traffic yes \
        check_encrypted

您只能有一個全局配置，否則嘗試將得到一個錯誤。FTP / Telnet全局配置必須出現在其他三個配置區域之前。

2.2.11.2.1 配置

1. inspection_type

這表明是在有狀態還是無狀態模式下運行。

2. crypto_traffic < yes |no>

此選項啟用對加密的Telnet和FTP命令通道的檢測和警報。

注意： 當inspection_type處于無狀態模式時，將在每個數據包上進行加密流量的檢查，而在有狀態模式下，特定會話將被標記為已加密并且不再進行檢查。

3. check_encrypted

指示預處理器繼續檢查加密的會話，以查找后續命令以停止加密。

2.2.11.3 示例全局配置

  preprocessor ftp_telnet: \
        global inspection_type stateful encrypted_traffic no

2.2.11.4 Telnet配置

telnet配置處理配置選項，這些選項確定預處理器的Telnet部分的功能。以下示例給出了通用的telnet配置格式：

2.2.11.5 格式

preprocessor ftp_telnet_protocol:
        telnet
        ports { 23 }
        normalize
        ayt_attack_thresh 6
        detect_anomalies

只能有一個telnet配置，后續實例將覆蓋先前設置的值。

2.2.11.5.1 配置

1.ports { < port> [< port> <...>]}

這是用戶配置要解碼為telnet流量的端口的方式。SSH隧道無法解碼，因此添加端口22僅會產生誤報。通常，將包括端口23。

2. normalize

此選項告訴預處理器通過消除telnet轉義序列來標準化telnet流量。它的功能與其前身telnet_decode預處理器相似。使用“原始”內容選項編寫的規則將忽略使用此選項時創建的規范化緩沖區。

3. ayt_attack_thresh < number>

此選項使預處理器在連續的telnet Are You（AYT）命令數量達到指定的數量時發出警報。僅在模式為有狀態時適用。

4. detect_anomalies

為了支持某些選項，Telnet支持子協商。根據Telnet RFC，子協商以SB（子協商開始）開始，并且必須以SE（子協商結束）結束。但是，Telnet服務器的某些實現將忽略沒有相應SE的SB。這是異常行為，可能是回避案件。由于FTP在控制連接上使用Telnet協議，因此它也容易受到此行為的影響。所述detect_anomalies選項使得能夠在遠程登錄SB警報沒有相應的SE。

2.2.11.6 Telnet配置示例

preprocessor ftp_telnet_protocol: \
        telnet ports { 23 } normalize ayt_attack_thresh 6

2.2.11.7 FTP服務器配置

FTP服務器配置有兩種類型：默認和IP地址。

2.2.11.7.1 默認

此配置為未單獨配置的任何FTP服務器提供默認服務器配置。大多數FTP服務器很可能最終將使用默認配置。

2.2.11.8 示例默認FTP服務器配置

preprocessor ftp_telnet_protocol:
        ftp server default ports { 21 }

2.2.11.8.1 按IP地址配置

此格式與“默認”非常相似，唯一的區別是可以配置特定IP。

2.2.11.9 IP特定FTP服務器配置示例

preprocessor _telnet_protocol: \
        ftp server 10.1.1.1 ports { 21 } ftp_cmds { XPWD XCWD }

2.2.11.10 FTP服務器配置選項

1. ports { < port> [< port> <...>] }

這是用戶配置要解碼為FTP命令通道流量的端口的方式。通常將包括端口21。

2. print_cmds

在初始化期間，此選項使預處理器為該服務器打印每個FTP命令的配置。

3. ftp_cmds {cmd [cmd] }

預處理器配置為在看到服務器不允許的FTP命令時發出警報。

此選項指定此服務器允許的其他命令的列表，該列表位于RFC 959中指定的默認FTP命令集之外。它可以用于允許使用RFC 775中標識的“ X”命令以及任何其他根據需要命令。

例如：

ftp_cmds {XPWD XCWD XCUP XMKD XRMD}

4. def_max_param_len < number>

這指定FTP命令的默認最大允許參數長度。它可以用作基本的緩沖區溢出檢測。

5. alt_max_param_len < number> {cmd[cmd]}

這指定了指定FTP命令的最大允許參數長度。它可以用作更特定的緩沖區溢出檢測。例如，USER命令-用戶名不能超過16個字節，因此適當的配置應為：

alt_max_param_len 16 {user}

6. chk_str_fmt {cmd [cmd] }

此選項導致檢查指定命令中的字符串格式攻擊。

7. cmd_validity cmd < fmt>

此選項為給定命令的參數指定有效格式。

fmt必須包含在中< >，并且可能包含以下內容：

cmd_validity選項的示例如下所示。這些示例是根據RFC 959和預處理器執行的其他檢查的默認檢查。

    cmd_validity MODE <char SBC>
    cmd_validity STRU <char FRP>
    cmd_validity ALLO < int [ char R int ] >
    cmd_validity TYPE < { char AE [ char NTC ] | char I | char L [ number ] } >
    cmd_validity PORT < host_port >

cmd_validity行可用于覆蓋這些默認值和/或添加對其他命令的檢查。

 # This allows additional modes, including mode Z which allows for
 # zip-style compression.
 cmd_validity MODE < char ASBCZ >

 # Allow for a date in the MDTM command.
 cmd_validity MDTM < [ date nnnnnnnnnnnnnn[.n[n[n]]] ] string >

MDTM是一個值得討論的案例。盡管不是已建立標準的一部分，但是某些FTP服務器接受MDTM命令，該命令可設置文件的修改時間。在這樣做的服務器中，最常見的是使用YYYYMMDDHHmmss [.uuu]接受格式。其他一些接受使用YYYYMMDDHHmmss [+ |-] TZ格式的格式。上面的示例是第一種情況（時間格式如http://www.ietf.org/internet-drafts/draft-ietf-ftpext-mlst-16.txt 中指定）

要檢查使用TZ格式的服務器的有效性，請使用以下命令：

cmd_validity MDTM <[date nnnnnnnnnnnnnn [{+ |-} n [n]]]string>

8. telnet_cmds < yes |no>

當在FTP命令通道上看到telnet轉義序列時，此選項將打開檢測和警報。telnet轉義序列的注入可用作FTP命令通道上的回避嘗試。

9. ignore_telnet_erase_cmds < yes |no>

使用此選項，在標準化FTP命令通道時，Snort可以忽略擦除字符（TNC EAC）和擦除行（TNC EAL）的telnet轉義序列。某些FTP服務器不處理那些telnet轉義序列。

10. data_chan

此選項使其余的snort（規則，其他預處理程序）忽略FTP數據通道連接。使用此選項意味著 對FTP數據傳輸不執行TCP狀態以外的任何檢查。它可用于提高性能，尤其是從受信任的源進行大文件傳輸時。如果您的規則集包含病毒類型規則，則建議不要使用此選項。

不建議使用“ data_chan”選項，而建議使用“ ignore_data_chan”選項。在未來的版本中將刪除“ data_chan”。

11. ignore_data_chan < yes |no>

此選項使Snort的其余部分（規則，其他預處理程序）忽略FTP數據通道連接。將此選項設置為“是”意味著將對FTP數據傳輸執行除TCP狀態以外的其他任何檢查。它可用于提高性能，尤其是從受信任的源進行大文件傳輸時。如果您的規則集包含病毒類型規則，則建議不要使用此選項。

2.2.11.11 FTP服務器基本配置選項

FTP服務器的基本配置如下。配置文件中指定的選項將修改這組選項。FTP命令已添加到允許的命令集中。其他選項將覆蓋基本配置中的那些選項。

def_max_param_len 100
    ftp_cmds { USER PASS ACCT CWD CDUP SMNT 
      QUIT REIN TYPE STRU MODE RETR 
      STOR STOU APPE ALLO REST RNFR 
      RNTO ABOR DELE RMD MKD PWD LIST 
               NLST SITE SYST STAT HELP NOOP } 
    ftp_cmds { AUTH ADAT PROT PBSZ CONF ENC } 
    ftp_cmds { PORT PASV LPRT LPSV EPRT EPSV } 
    ftp_cmds { FEAT OPTS } 
    ftp_cmds { MDTM REST SIZE MLST MLSD } 
    alt_max_param_len 0 { CDUP QUIT REIN PASV STOU ABOR PWD SYST NOOP } 
    cmd_validity MODE < char SBC > 
    cmd_validity STRU < char FRPO [ string ] > 
    cmd_validity ALLO < int [ char R int ] > 
    cmd_validity TYPE < { char AE [ char NTC ] | char I | char L [ number ] } > 
    cmd_validity PORT < host_port > 
    cmd_validity LPRT < long_host_port > 
    cmd_validity EPRT < extd_host_port > 
    cmd_validity EPSV < [ { '1' | '2' | 'ALL' } ] >

2.2.11.12 FTP客戶端配置

與FTP服務器配置類似，FTP客戶端配置有兩種類型：默認和IP地址。

2.2.11.12.1 默認

此配置為未單獨配置的任何FTP客戶端提供默認客戶端配置。大多數FTP客戶端很可能最終會使用默認配置。

2.2.11.13 示例默認FTP客戶端配置

preprocessor ftp_telnet_protocol:
        ftp client default bounce no max_resp_len 200

2.2.11.13.1 按IP地址配置

此格式與“默認”非常相似，唯一的區別是可以配置特定IP。

2.2.11.14 IP特定FTP客戶端配置示例

preprocessor ftp_telnet_protocol: \
ftp client 10.1.1.1 bounce yes max_resp_len 500

2.2.11.15 FTP客戶端配置選項

1. max_resp_len < number>

這指定了客戶端接受的FTP命令的最大允許響應長度。它可以用作基本的緩沖區溢出檢測。

2. bounce < yes|no>

此選項打開對FTP反彈攻擊的檢測和警報。發出FTP PORT命令并且指定的主機與客戶端的主機不匹配時，會發生FTP反彈攻擊。

3. bounce_to < CIDR,[port|portlow,porthi]>

啟用bounce選項時，這使PORT命令可以使用IP地址（CIDR格式）和端口（或包含端口的范圍）而不生成警報。它可用于處理FTP數據通道與客戶端不同的代理FTP連接。

一些例子：

• 允許跳到192.162.1.1端口20020-即使用 PORT 192,168,1,1,78,52。

  bounce_to {192.168.1.1,20020}

• 允許跳到192.162.1.1端口20020至20040-即使用 PORT 192,168,1,1,78，xx，其中xx是52至72（包括52和72）。

  bounce_to {192.168.1.1,20020,20040}

• 允許跳至192.162.1.1端口20020和192.168.1.2端口20030。

  bounce_to {192.168.1.1,20020 192.168.1.2,20030}

• 允許跳回IPv6地址fe8 :: 5端口59340。

  bounce_to {fe8 :: 5,59340}

4. telnet_cmds < yes|no>

當在FTP命令通道上看到telnet轉義序列時，此選項將打開檢測和警報。telnet轉義序列的注入可用作FTP命令通道上的回避嘗試。

5. ignore_telnet_erase_cmds < yes|no>

使用此選項，在標準化FTP命令通道時，Snort可以忽略擦除字符（TNC EAC）和擦除行（TNC EAL）的telnet轉義序列。某些FTP客戶端不處理那些telnet轉義序列。

2.2.11.16 示例/來自snort.conf的默認配置

    preprocessor ftp_telnet: \
        global \
        encrypted_traffic yes \
        inspection_type stateful

    preprocessor ftp_telnet_protocol:\
        telnet \
        normalize \
        ayt_attack_thresh 200

    # This is consistent with the FTP rules as of 18 Sept 2004.
    # Set CWD to allow parameter length of 200
    # MODE has an additional mode of Z (compressed)
    # Check for string formats in USER & PASS commands
    # Check MDTM commands that set modification time on the file.

    preprocessor ftp_telnet_protocol: \
        ftp server default \
        def_max_param_len 100 \
        alt_max_param_len 200 { CWD } \
        cmd_validity MODE < char ASBCZ > \
        cmd_validity MDTM < [ date nnnnnnnnnnnnnn[.n[n[n]]] ] string > \
        chk_str_fmt { USER PASS RNFR RNTO SITE MKD } \
        telnet_cmds yes \
        ignore_data_chan yes

    preprocessor ftp_telnet_protocol: \
        ftp client default \
        max_resp_len 256 \
        bounce yes \
        telnet_cmds yes

2.2.12 SSH

SSH預處理程序檢測以下漏洞：挑戰-響應緩沖區溢出，CRC 32，安全CRT和協議不匹配漏洞。

挑戰-響應溢出和CRC 32攻擊都在密鑰交換后發生，因此被加密。兩種攻擊都涉及在身份驗證質詢后立即向服務器發送較大的有效負載（20kb +）。為了檢測攻擊，SSH預處理器會對傳輸到服務器的字節數進行計數。如果這些字節在預定義的數據包數內超過了預定義的限制，則會生成警報。由于質詢響應溢出僅影響SSHv2，而CRC 32僅影響SSHv1，因此使用SSH版本字符串交換來區分攻擊。

在交換密鑰之前，可以觀察到安全CRT和協議不匹配利用。

2.2.12.1 配置

默認情況下，所有警報均被禁用，預處理器檢查端口22上的流量。

可用的配置選項如下所述。

1. server_ports {< port> [< port> <...>]}

此選項指定SSH預處理程序應檢查流量的端口。

2. max_encrypted_packets < number>

Snort在忽略給定的SSH會話之前將檢查的流重組加密數據包的數量。Snort可以檢測到的所有SSH漏洞都發生在SSH會話的最開始。一旦看到max_encrypted_packets數據包，Snort便會忽略會話以提高性能。默認設置為25。此值可以設置為0到65535。

3. max_client_bytes < number>

在向質詢響應溢出或CRC 32發出警報之前允許傳輸的未答復字節數。必須在發送max_encrypted_packets數據包之前將其擊中，否則Snort將忽略通信量。默認設置為19600。此值可以設置為0到65535。

4. max_server_version_len <number>

在安全CRT服務器版本字符串溢出警報之前，SSH服務器版本字符串中允許的最大字節數。默認設置為80。此值可以設置為0到255。

5. autodetect

嘗試自動檢測SSH。

6. enable_respoverflow

啟用檢查質詢-響應溢出漏洞利用的功能。

7. enable_ssh1crc32

啟用檢查CRC 32漏洞利用。

8. enable_srvoverflow

啟用對Secure CRT利用的檢查。

9. enable_protomismatch

啟用檢查協議不匹配利用。

10. enable_badmsgdir

為流向錯誤方向的流量啟用警報。例如，假定服務器生成客戶端流量，或者客戶端生成服務器流量。

11. enable_paysize

啟用有關無效負載大小的警報。

12. enable_recognition

為SSH端口上的非SSH流量啟用警報。

SSH預處理器默認情況下應該工作。達到max_encrypted_packets后，預處理器將停止處理給定會話的流量。如果質詢響應溢出或CRC 32誤報，請嘗試使用max_client_bytes增加所需的客戶端字節數。

2.2.12.2 snort.conf中的示例配置

    preprocessor ssh: \
        server_ports { 22 } \
        max_client_bytes 19600 \
        max_encrypted_packets 20 \
        enable_respoverflow \
        enable_ssh1crc32

2.2.13 DNS

DNS預處理器對DNS響應進行解碼，并且可以檢測以下漏洞：DNS客戶端RData溢出，過時的記錄類型和實驗性記錄類型。

DNS會查看UDP和TCP上的DNS響應流量，并且需要啟用Stream預處理程序以進行TCP解碼。

2.2.13.1 配置

默認情況下，所有警報均被禁用，預處理器檢查端口53上的流量。

可用的配置選項如下所述。

1. ports { <port> [<port> <...>] }

此選項指定DNS預處理程序應檢查流量的源端口。

2. enable_obsolete_types

關于過時的警報（根據RFC 1035）記錄類型

3. enable_experimental_types

關于實驗性記錄（根據RFC 1035）的警報

4. enable_rdata_overflow

檢查DNS客戶端RData TXT溢出

如果未檢查3個漏洞中的任何一個，則DNS預處理器不執行任何操作。它不會在中途拾取的TCP會話上運行，如果由于丟失數據（丟失的數據包）而導致狀態丟失，它將在會話上停止運行。

2.2.13.2 示例/來自snort.conf的默認配置

在DNS服務器端口53上查找通信。檢查DNS客戶端RData溢出漏洞。不要對過時的或實驗性的RData記錄類型發出警報。

    preprocessor dns:
        ports { 53 }
        enable_rdata_overflow

2.2.14 SSL / TLS

出于性能和減少誤報的雙重考慮，Snort應該忽略加密的流量。SSL動態預處理器（SSLPP）解碼SSL和TLS通信，并可選地確定Snort是否以及何時停止對其進行檢查。

通常，SSL通過端口443用作HTTPS。通過啟用SSLPP檢查端口443并啟用noinspect_encrypted選項，將僅檢查每個連接的SSL握手。一旦確定流量已加密，就不會再檢查連接上的數據了。

默認情況下，SSLPP會先尋找握手，然后再向雙方傳輸加密的流量。如果一方以諸如握手等失敗的指示響應，則該會話不會標記為已加密。驗證是否從兩個端點都發送了無誤的加密流量，這可以確保兩件事：沒有精心設計最后的客戶端握手數據包來逃避Snort，并且對流量進行了合法加密。

在某些情況下，尤其是可能會丟失數據包時，從一個端點觀察到的唯一響應將是TCP ACK。因此，如果用戶知道可以信任服務器端加密的數據以將該會話標記為已加密，則該用戶應使用下面介紹的“ trustservers”選項。

2.2.14.1 配置

1. ports {<port> [< port> <...>] }

此選項指定SSLPP將檢查流量的端口。

默認情況下，SSLPP監視以下端口：

• 443 HTTPS
• 465 SMTP
• 563 NNTPS
• 636 LDAPS
• 989 FTPS
• 992 TelnetS
• 993 IMAPS
• 994 IRCS
• 995 POPS

2. noinspect_encrypted

禁用對加密流量的檢查。默認為關閉。

3. max_heartbeat_length

允許的最大心跳記錄長度。此配置選項用于檢測令人討厭的攻擊。允許的范圍是0到65535。將該值設置為0將關閉心跳長度檢查。對于心跳請求，如果請求記錄的有效負載大小大于max_heartbeat_length，則會生成具有sid 3和gid 137的警報。對于心跳響應，如果記錄大小本身大于max_heartbeat_length，則會生成帶有sid 4和gid 137的警報。默認為關閉。

4. trustservers

禁用以下要求：在會話被標記為加密之前，必須在會話的兩端都必須遵守應用程序（加密）數據。如果您相信服務器不會受到影響，請使用此選項以提高性能。這要求noinspect_encrypted選項有用。默認為關閉。

2.2.14.2 示例/來自snort.conf的默認配置

啟用SSL預處理程序，并告訴它禁用對加密流量的檢查。

preprocessor ssl: noinspect_encrypted

2.2.14.3 規則選項

啟用ssl預處理程序可支持以下規則選項：

• ssl_version
• ssl_state

ssl_version
該ssl_version規則選項跟蹤的SSL加密端點之間協商的版本。下面是版本標識符列表，并且可以通過逗號分隔的列表來指定多個標識符。標識符列表一起進行“或”運算。如果在SSL連接中使用任何OR版本的選項，則該選項將匹配。要同時檢查兩個或多個使用中的SSL版本，應使用多個 ssl_version規則選項。
句法:

ssl_version: <version-list>
version-list = version | version , version-list
version      = ["!"] "sslv2" | "sslv3" | "tls1.0" | "tls1.1" | "tls1.2"

例子：

   ssl_version:sslv3;
   ssl_version:tls1.0,tls1.1,tls1.2;
   ssl_version:!sslv2;

ssl_state
該ssl_state規則選項打招呼和密鑰交換的過程中跟蹤的SSL加密的狀態。狀態列表如下。可以通過逗號分隔的列表指定多個狀態，然后將它們進行“或”運算。如果連接當前處于任一OR’ed狀態，則該選項將匹配。為確保連接已達到一組狀態中的每個狀態，應使用使用ssl_state rule選項的多個規則。
句法:

ssl_state: <state-list>
state-list = state | state , state-list
state      = ["!"] "client_hello" | "server_hello" | "client_keyx" | "server_keyx" | "unknown"

例子：

   ssl_state:client_hello;
   ssl_state:client_keyx,server_keyx;
   ssl_state:!server_hello;

2.2.15 ARP欺騙預處理器

ARP欺騙預處理器對ARP數據包進行解碼，并檢測ARP攻擊，單播ARP請求以及以太網到IP映射的不一致。

如果沒有為arpspof指定任何參數，則預處理器將檢查以太網地址和ARP數據包中的地址。發生不一致時，將生成GID 112和SID 2或3的警報。

當將“ -unicast ”指定為arpspoof的參數時，預處理器將檢查單播ARP請求。如果檢測到單播ARP請求，將生成GID 112和SID 1的警報。

指定一對IP地址和硬件地址作為arpspoof_detect_host的參數 。具有IP地址的主機應與Snort位于同一第2層網段。每行指定一個主機IP MAC組合。當檢測到ARP緩存覆蓋攻擊時，預處理器將使用此列表。在這種情況下使用警報SID 4。

2.2.15.1 格式

    preprocessor arpspoof[: -unicast]
    preprocessor arpspoof_detect_host: ip mac

2.2.15.2 示例配置

第一個示例配置既不進行單播檢測也不進行ARP映射監視。預處理器僅查找以太網地址不一致。

preprocessor arpspoof

下一個示例配置不執行單播檢測，而是監視主機192.168.40.1和192.168.40.2的ARP映射。

    preprocessor arpspoof
    preprocessor arpspoof_detect_host: 192.168.40.1 f0:0f:00:f0:0f:00
    preprocessor arpspoof_detect_host: 192.168.40.2 f0:0f:00:f0:0f:01

第三個示例配置啟用了單播檢測。

    preprocessor arpspoof: -unicast
    preprocessor arpspoof_detect_host: 192.168.40.1 f0:0f:00:f0:0f:00
    preprocessor arpspoof_detect_host: 192.168.40.2 f0:0f:00:f0:0f:01

2.2.16 DCE / RPC 2預處理器

預處理器的主要目的是執行SMB分割和DCE / RPC碎片整理，以避免使用這些技術規避規則。對以下命令執行SMB細分，這些命令可用于傳輸DCE / RPC請求和響應：Write, Write Block Raw,Write and Close, Write AndX, Transaction,Transaction Secondary, Read, Read Block Raw 和 Read AndX。DCE / RPC支持以下傳輸：HTTP v.1代理和服務器上的SMB，TCP，UDP和RPC。已實施新的規則選項，以提高性能，減少誤報并減少基于DCE / RPC的規則的數量和復雜性。

2.2.16.1 依賴性要求

為了使預處理器正常工作：

• 流會話跟蹤必須啟用，即stream5。預處理器需要會話跟蹤器來保留其數據。
• 必須為TCP會話執行流重組。如果通過配置的端口，服務器或自動檢測確定會話是SMB或DCE / RPC，則dcerpc2預處理器將在必要時為該會話啟用流重組。
• 應該啟用IP碎片整理，即 應該啟用和配置frag3預處理程序。

2.2.16.2 基于目標

Windows和Samba版本之間有足夠重要的區別，因此已經實現了基于目標的方法。一些重要的區別：

命名管道實例跟蹤

必須使用有效的登錄句柄或UID，共享句柄或TID和文件/命名管道句柄或FID的組合來將數據寫入命名管道。它們之間的綁定取決于OS /軟件版本。

Samba 3.0.22及更早版本
任何有效的UID和TID以及有效的FID均可用于發出請求，但是，如果刪除了創建FID中使用的TID（通過樹斷開連接），則使用該TID創建的FID無效，即無法將更多請求寫入該命名管道實例。

Samba大于3.0.22
任何有效的TID以及有效的FID均可用于發出請求。但是，只有使用打開命名管道的UID才能使用對命名管道實例的FID句柄進行請求。如果刪除了用于創建FID的TID（通過樹斷開連接），則使用該TID創建的FID將變為無效，即無法將更多請求寫入該命名管道實例。如果刪除了用于創建命名管道實例的UID（通過Logoff AndX），則由于在向命名管道發出請求時有必要，因此FID無效。

** Windows 2003 | Windows XP | Windows Vista**
這些Windows版本要求用于向命名管道實例發出請求的UID，TID和FID之間嚴格綁定。將數據寫入同一命名管道實例時，必須同時使用用于打開命名管道實例的UID和TID。因此，刪除UID或TID會使FID無效。

Windows 2000
Windows 2000的有趣之處在于，對命名管道的第一個請求必須使用與其他Windows版本相同的綁定。但是，此后的請求遵循與Samba 3.0.22及更早版本相同的綁定，即沒有綁定。它還遵循大于3.0.22的Samba，因為刪除用于創建命名管道實例的UID或TID也會使它無效。

接受的SMB命令
特別是Samba不能識別IPC$樹下的某些命令。
Samba(所有版本)
IPC$樹下，不接受:

`Open` 
`Write And Close`
`Read`
`Read Block Raw`
`Write Block Raw`

Windows(所有版本)
接受IPC$樹下的所有上述命令

AndX命令鏈
Windows在允許鏈接的命令組合方面非常嚴格。另一方面，Samba非常寬松，并且允許一些無意義的組合，例如，多次登錄和樹連接（只有一個地方可以返回這些句柄），登錄/注銷和樹連接/樹斷開連接。最終，我們不想跟蹤服務器不接受的數據。規避漏洞的可能是在服務器不接受的請求中接受片段，該片段夾在漏洞利用之間。

交易追蹤
事務請求與使用Write *命令將數據寫入命名管道之間的區別在于:
（1） 事務執行對命名管道的寫入和讀取操作，而在使用Write *命令時，客戶端必須顯式發送Read *請求，以告知服務器發送響應。
（2）直到接收到所有數據（通過潛在的Transaction Secondary請求），事務請求才寫入命名管道。在Write *命令，服務器將接收到的數據寫入命名管道。可以同時向同一個命名管道發出多個事務請求。這些請求也可以使用輔助事務命令進行細分。區分它們的方式（當寫入相同的命名管道時，即具有相同的FID）是SMB標頭中代表進程ID（PID）和多路復用ID（MID）的字段。PID表示此請求所屬的過程。MID代表流程（或PID下）的不同子流程。每個“線程”的段分別存儲，并在收到所有段時將其寫入命名管道。有必要對此進行跟蹤，以免一起提出這些請求（這可能是逃避的機會）。
Windows（所有版本）
使用PID和MID的組合來定義“線程”。
Samba（所有版本）
僅使用MID定義“線程”。

多個綁定請求
綁定請求是必須在面向連接的DCE / RPC會話，以便指定一個想要與之通信的接口/接口進行第一請求。

Windows（所有版本）
對于所有Windows版本，無論會話成功與否，都只能在會話中進行一次綁定。之后的任何綁定都必須使用Alter Context請求。如果進行了另一個綁定，則所有先前的接口綁定都將失效。

Samba 3.0.20及更早版本
可以發出 任意數量的綁定請求。

Samba遲于3.0.20
如果第一個失敗并且沒有成功綁定任何接口，則可以發出 另一個綁定請求。如果在成功綁定之后進行了 綁定，則所有先前的接口綁定都將失效。

DCE / RPC碎片請求- Context ID

分段請求中的每個片段都帶有要向其發出請求的綁定接口的上下文ID。

Windows（所有版本）
最終用于請求的上下文ID包含在第一個片段中。任何其他片段中的上下文ID字段可以包含任何值。

Samba（所有版本）
最后一個片段中包含最終用于請求的上下文ID。任何其他片段中的上下文ID字段可以包含任何值。

DCE / RPC碎片請求-操作號

分段請求中的每個分段都攜帶一個操作號（opnum），該操作號或多或少是該接口提供的功能的句柄。

Samba（所有版本）
Windows 2000
Windows 2003
Windows XP
最后一個片段中包含最終用于請求的opnum。任何其他片段中的opnum字段可以包含任何值。

Windows Vista
最終用于請求的opnum包含在第一個片段中。任何其他片段中的opnum字段可以包含任何值。

DCE / RPC存根數據字節順序

對于Windows和Samba，存根數據的字節順序是不同的。

Windows（所有版本）
存根數據的字節順序與綁定請求中使用的順序相同 。

Samba（所有版本）
存根數據的字節順序是在承載存根數據的請求中使用的字節順序。

2.2.16.3 配置

該dcerpc2預編譯器有一個全局配置和一個或多個服務器配置。全局預處理器配置名稱為 dcerpc2，而服務器預處理器配置名稱為 dcerpc2_server。

全局配置

preprocessor dcerpc2

需要全局dcerpc2配置。只能指定一個全局 dcerpc2配置。

選項語法:

    memcap           = 1024-4194303 (kilobytes)
    max-frag-len     = 1514-65535
    events           = pseudo-event | event | '[' event-list ']'
    pseudo-event     = "none" | "all"
    event-list       = event | event ',' event-list
    event            = "memcap" | "smb" | "co" | "cl"
    re-thresh        = 0-65535
    fp-policy        = "server" | "client" | "both"

選項說明:

• memcap 指定可以分配的最大運行時內存。運行時內存包括配置后分配的所有內存。默認值為100 MB。
• disabled 禁用預處理器。默認情況下，此值處于關閉狀態。如果禁用了預處理器，則在配置中指定時僅應用memcap選項。
• disable_defrag 告訴預處理器不要進行DCE / RPC碎片整理。默認為進行碎片整理。
• max_frag_len 指定將添加到碎片整理模塊的最大片段大小。如果片段大于此大小，則會在將其添加到碎片整理模塊之前將其截斷。此選項的允許范圍是1514-65535。
• events 指定要啟用的事件的類別。（有關事件的枚舉和解釋，請參見事件部分。）
• memcap 只有一個事件。如果達到或超過了內存限制，請發出警報。
• smb 對與SMB處理有關的事件發出警報。
• co 代表面向連接的DCE / RPC。對與面向連接的DCE / RPC處理有關的事件發出警報。
• CL 代表無連接DCE / RPC。對與無連接DCE / RPC處理有關的事件發出警報。
• reassemble_threshold 在創建重組數據包以發送到檢測引擎之前，指定DCE / RPC碎片整理和碎片整理緩沖區中的最小字節數。此選項在串聯模式下很有用，以便在完成完全碎片整理之前及早捕獲漏洞。作為此選項的參數提供的值0實際上將禁用此選項。默認設置為禁用。
• smb_fingerprint_policy 默認情況下，將檢查SMBv1，SMBv2和SMBv3文件。如果配置了傳統模式，則僅啟用SMBv1文件檢查。
• legacy_mode 在SMB會話的初始階段，客戶端需要使用SessionSetupAndX進行身份驗證。此命令的請求和響應都包含操作系統和版本信息，這些信息可以允許預處理器動態設置會話的策略，從而可以更好地保護Windows和Samba特定的行為。

選項示例:

    memcap 30000
    max_frag_len 16840
    events none
    events all
    events smb
    events co
    events [co]
    events [smb, co]
    events [memcap, smb, co, cl]
    reassemble_threshold 500
    smb_fingerprint_policy both
    smb_fingerprint_policy client
    smb_legacy_mode

配置實例:

    preprocessor dcerpc2
    preprocessor dcerpc2: memcap 500000
    preprocessor dcerpc2: max_frag_len 16840, memcap 300000, events smb
    preprocessor dcerpc2: memcap 50000, events [memcap, smb, co, cl], max_frag_len 14440
    preprocessor dcerpc2: disable_defrag, events [memcap, smb]
    preprocessor dcerpc2: reassemble_threshold 500
    preprocessor dcerpc2: memcap 50000, events [memcap, smb, co, cl], max_frag_len 14440, smb_fingerprint_policy both

默認全局配置:
preprocessor dcerpc2: memcap 102400

服務器配置:
preprocessor dcerpc2_server

dcerpc2_server配置可選。一個 dcerpc2_server配置必須以默認或 網絡選項開始。默認和網絡選項是互斥的。最多可以指定一種默認配置。如果未指定默認配置，則默認值將用于默認配置。可以指定零個或多個網絡配置。對于任何dcerpc2_server配置，如果未指定不需要的選項，則將使用默認值。處理DCE / RPC流量時，默認如果沒有網絡配置匹配，則使用配置。如果網絡配置匹配，它將覆蓋默認配置。一個網絡配置相匹配，如果數據包的服務器IP地址匹配在指定的IP地址或凈凈的配置。在凈選件支持IPv6地址。請注意，不能使用snort.conf中 定義的port和ip變量。

選項語法：

    net          = ip | '[' ip-list ']'
    ip-list      = ip | ip ',' ip-list
    ip           = ip-addr | ip-addr '/' prefix | ip4-addr '/' netmask
    ip-addr      = ip4-addr | ip6-addr
    ip4-addr     = a valid IPv4 address
    ip6-addr     = a valid IPv6 address (can be compressed)
    prefix       = a valid CIDR
    netmask      = a valid netmask
    policy       = "Win2000" | "Win2003" | "WinXP" | "WinVista" |
                   "Samba" | "Samba-3.0.22" | "Samba-3.0.20"
    detect       = "none" | detect-opt | '[' detect-list ']'
    detect-list  = detect-opt | detect-opt ',' detect-list
    detect-opt   = transport | transport port-item | 
                   transport '[' port-list ']'
    transport    = "smb" | "tcp" | "udp" | "rpc-over-http-proxy" | 
                   "rpc-over-http-server"
    port-list    = port-item | port-item ',' port-list
    port-item    = port | port-range
    port-range   = ':' port | port ':' | port ':' port
    port         = 0-65535
    shares       = share | '[' share-list ']'
    share-list   = share | share ',' share-list
    share        = word | '"' word '"' | '"' var-word '"'
    word         = graphical ASCII characters except ',' '"' ']' '[' '$'
    var-word     = graphical ASCII characters except ',' '"' ']' '['
    max-chain    = 0-255
    file-inspect = file-arg | '[' file-list ']'
    file-arg     = "off" | "on" | "only"
    file-list    = file-arg [ ',' "file-depth" <int64_t> ]

由于Snort主解析器將’$’視為變量的開頭并嘗試對其進行擴展，因此必須將帶有’$’的shares括在引號中。

選項說明:

• 默認| 指定此配置用于默認服務器配置。
• net| 指定此配置是IP或網絡特定的配置。該配置僅適用于作為參數提供的IP地址和網絡。
• policy| 指定在處理時使用的基于目標的策略。默認為“ WinXP”。
• detect| 指定應該在該傳輸上檢測到的DCE / RPC傳輸和服務器端口。SMB的默認端口是139和445，TCP和UDP的默認端口是135，HTTP服務器的RPC的端口是593，HTTP代理的RPC的端口是80。
• autodetect| 指定預處理器應嘗試在其上自動檢測到的DCE / RPC傳輸和服務器端口。僅當沒有檢測到的傳輸/端口與數據包匹配時才查詢自動檢測端口。預處理器將嘗試自動檢測的順序為-TCP / UDP，HTTP服務器上的RPC，HTTP代理上的RPC和最后的SMB。請注意，大多數動態DCE / RPC端口都高于1024，并且直接通過TCP或UDP傳輸。在端口139和445以外的任何其他端口上看到SMB都是非常罕見的。TCP，UDP和RPC over HTTP服務器的默認值為1025-65535。
• no_autodetect_http_proxy_ports| 默認情況下，預處理器將始終嘗試自動檢測在rpc-over-http-proxy的檢測配置中指定的端口。這是因為代理可能是Web服務器，并且預處理程序不應查看所有Web流量。如果配置了detect選項的RPC over HTTP代理僅用于代理DCE / RPC通信，則此選項很有用。默認是在RPC over HTTP代理檢測端口上自動檢測。
• smb_invalid_shares| 指定SMB共享，如果嘗試通過Tree Connect或Tree Connect AndX連接到它們，則預處理器應發出警報。默認為空。
• smb_max_chain| 指定在生成警報之前允許的AndX命令鏈接的最大數量。默認最大值為3個鏈接命令。值為0將禁用此選項。可以在0到255之間設置該值。
• smb_file_inspection| 指示預處理程序檢查正常的SMB文件傳輸。這包括通過文件API進行文件類型和簽名，以及為file_data 規則選項設置指針。請注意，文件深度選項僅適用于將為其設置file_data規則選項的指針的最大文件數據量 。對于文件類型和簽名，它將使用為文件API配置的值。如果僅指定，則預處理器將僅執行SMB文件檢查，即，它將不執行任何DCE / RPC跟蹤或檢查。如果沒有參數指定為on，則默認文件深度為16384字節。-1為文件深度的參數 禁用設置file_data的指針，從而有效禁用規則中的SMB文件檢查。文件深度的參數0表示無限制。默認為關閉，即在預處理器中不進行SMB文件檢查。支持SMBv1，SMBv2和SMBv3。

選項示例:

    net 192.168.0.10
    net 192.168.0.0/24
    net [192.168.0.0/24]
    net 192.168.0.0/255.255.255.0
    net feab:45b3:ab92:8ac4:d322:007f:e5aa:7845
    net feab:45b3:ab92:8ac4:d322:007f:e5aa:7845/128
    net feab:45b3::/32
    net [192.168.0.10, feab:45b3::/32]
    net [192.168.0.0/24, feab:45b3:ab92:8ac4:d322:007f:e5aa:7845]
    policy Win2000
    policy Samba-3.0.22
    detect none
    detect smb
    detect [smb]
    detect smb 445
    detect [smb 445]
    detect smb [139,445]
    detect [smb [139,445]]
    detect [smb, tcp]
    detect [smb 139, tcp [135,2103]]
    detect [smb [139,445], tcp 135, udp 135, rpc-over-http-server [593,6002:6004]]
    autodetect none
    autodetect tcp
    autodetect [tcp]
    autodetect tcp 2025:
    autodetect [tcp 2025:]
    autodetect tcp [2025:3001,3003:]
    autodetect [tcp [2025:3001,3003:]]
    autodetect [tcp, udp]
    autodetect [tcp 2025:, udp 2025:]
    autodetect [tcp 2025:, udp, rpc-over-http-server [1025:6001,6005:]]
    smb_invalid_shares private
    smb_invalid_shares "private"
    smb_invalid_shares "C$"
    smb_invalid_shares [private, "C$"]
    smb_invalid_shares ["private", "C$"]
    smb_max_chain 1
    smb_file_inspection on
    smb_file_inspection off
    smb_file_inspection [ on, file-depth -1 ]
    smb_file_inspection [ on, file-depth 0 ]
    smb_file_inspection [ on, file-depth 4294967296 ]
    smb_file_inspection [ only, file-depth -1 ]

配置實例:

    preprocessor dcerpc2_server: \
        default

    preprocessor dcerpc2_server: \
        default, policy Win2000

    preprocessor dcerpc2_server: \
        default, policy Win2000, detect [smb, tcp], autodetect tcp 1025:, \
        smb_invalid_shares ["C$", "D$", "ADMIN$"]

    preprocessor dcerpc2_server: net 10.4.10.0/24, policy Win2000

    preprocessor dcerpc2_server: \
        net [10.4.10.0/24,feab:45b3::/126], policy WinVista, smb_max_chain 1

    preprocessor dcerpc2_server: \
        net [10.4.10.0/24,feab:45b3::/126], policy WinVista, \
        detect [smb, tcp, rpc-over-http-proxy 8081], 
        autodetect [tcp, rpc-over-http-proxy [1025:6001,6005:]], \
        smb_invalid_shares ["C$", "ADMIN$"], no_autodetect_http_proxy_ports

    preprocessor dcerpc2_server: \
        net [10.4.11.56,10.4.11.57], policy Samba, detect smb, autodetect none

    preprocessor dcerpc2_server: default, policy WinXP, \
        smb_file_inspection [ on, file-depth 0 ]

默認服務器配置:

    preprocessor dcerpc2_server: default, policy WinXP, \
        detect [smb [139,445], tcp 135, udp 135, rpc-over-http-server 593], \
        autodetect [tcp 1025:, udp 1025:, rpc-over-http-server 1025:], \
        smb_max_chain 3, smb_file_inspection off

完整的dcerpc2默認配置:

    preprocessor dcerpc2: memcap 102400

    preprocessor dcerpc2_server: \
        default, policy WinXP, \
        detect [smb [139,445], tcp 135, udp 135, rpc-over-http-server 593], \
        autodetect [tcp 1025:, udp 1025:, rpc-over-http-server 1025:], \
        smb_max_chain 3, smb_file_inspection off

2.2.16.4 Events

預處理器使用GID 133來注冊事件。

Memcap事件:

SMB事件:

面向連接的DCE / RPC事件:

無連接DCE / RPC事件:

2.2.16.5 規則選項

通過啟用dcerpc2預處理程序來支持新的規則選項：

• dce_iface
• dce_opnum
• dce_stub_data

現有byte_test和byte_jump規則選項的新修飾符：

• byte_test:dce
• byte_jump:dce

dce_iface

對于基于DCE / RPC的規則，必須根據客戶端綁定到服務來設置流位，以避免誤報。客戶端必須先綁定到服務，然后才能對其進行調用。當客戶端向服務器發送綁定請求時，它可以指定一個或多個要綁定的服務接口。每個接口都由一個UUID表示。每個接口UUID都與唯一的索引（或上下文ID）配對，以后的請求可以使用該索引來引用客戶端正在調用的服務。服務器將使用其接受為有效的接口UUID進行響應，并允許客戶端向這些服務發出請求。客戶端發出請求時，它將指定上下文ID，以便服務器知道客戶端向其請求的服務。與其使用流位，一條規則可以使用此規則選項簡單地詢問預處理器，客戶端是否已綁定到特定接口UUID，以及此客戶端請求是否正在向其發出請求。由于預處理器可以將綁定UUID與請求中使用的上下文ID相關聯，因此可以消除將多個服務成功綁定到的誤報。DCE / RPC請求可以指定將數字表示為大端還是小端。接口UUID的表示形式有所不同，具體取決于DCE / RPC中指定的字節序，以前需要兩個規則-一個用于大字節序，一個用于小字節序。預處理器通過標準化UUID消除了對兩個規則的需求。接口包含一個版本。接口的某些版本可能不容易受到某些利用。也，DCE / RPC請求可以分為1個或多個片段。在DCE / RPC標頭中設置標志（和無連接標頭中的字段）以指示該片段是第一個片段，中間片段還是最后一個片段。僅當DCE / RPC請求是第一個片段（或完整請求）時，才對DCE / RPC請求中的數據進行許多檢查，因為后續片段將包含更深入DCE / RPC請求的數據。尋找數據的規則（例如，進入請求的5個字節（可能是一個長度字段））將在除第一個片段以外的其他片段上尋找錯誤的數據，因為后續片段的開頭已經從請求的開始。這可能是碎片化DCE / RPC通信中誤報的來源。默認情況下，僅評估請求是否為第一個片段（或完整請求）是合理的。但是，如果any_frag選項用于指定對所有片段的評估。
句法:

    dce_iface:<uuid>[, <operator><version>][, any_frag];

    uuid       = hexlong '-' hexshort '-' hexshort '-' 2hexbyte '-' 6hexbyte
    hexlong    = 4hexbyte
    hexshort   = 2hexbyte
    hexbyte    = 2HEXDIGIT
    operator   = '<' | '>' | '=' | '!'
    version    = 0-65535

例子：

    dce_iface:4b324fc8-1670-01d3-1278-5a47bf6ee188;
    dce_iface:4b324fc8-1670-01d3-1278-5a47bf6ee188, <2;
    dce_iface:4b324fc8-1670-01d3-1278-5a47bf6ee188, any_frag;
    dce_iface:4b324fc8-1670-01d3-1278-5a47bf6ee188, =1, any_frag;

此選項用于指定接口UUID。可選參數是接口版本和運算符，用于指定版本小于（’<’），大于（’>’），等于（’=’）或不等于（’！’）指定的版本。同樣，默認情況下，僅針對第一個片段（或完整請求，即不是片段）評估規則，因為大多數規則是從請求的開頭開始編寫的。該any_frag 參數也用于計算中間和最后的片段。此選項要求跟蹤預處理器中面向連接的DCE / RPC的客戶端Bind和Alter Context請求以及服務器Bind Ack和Alter Context響應。更改上下文請求后，客戶端將為每個接口UUID指定接口UUID的列表以及句柄（或上下文ID），在DCE / RPC會話期間將使用該句柄來引用該接口。服務器響應指示它將允許客戶端向哪個接口發出請求-它接受還是拒絕客戶端綁定到某個接口的愿望。此跟蹤是必需的，以便在處理請求時，可以將請求中使用的上下文ID與作為其句柄的接口UUID相關聯。

hexlong和hexshort將被指定和解釋為大端順序（這通常是顯示和表示接口UUID的默認方式）。例如，下面的Messenger接口UUID是從一點端字節Bind請求中斷開的：
| f8 91 7b 5a 00 ff d0 11 a9 b2 00 c0 4f b6 e6 fc |

必須寫為：
5a7b91f8-ff00-11d0-a9b2-00c04fb6e6fc

相同的UUID從大字節序的Bind請求中刪除：
| 5a 7b 91 f8 ff 00 11 d0 a9 b2 00 c0 4f b6 e6 fc |

必須以相同的方式編寫： 5a7b91f8-ff00-11d0-a9b2-00c04fb6e6fc

如果指定的接口UUID與DCE / RPC請求的接口UUID（由上下文ID引用）相匹配，并且如果提供了版本操作，則此選項匹配。如果片段不是第一個片段（或完整請求），則此選項將不匹配，除非提供了any_frag選項，在這種情況下，僅接口UUID和版本需要匹配。請注意，對碎片整理后的DCE / RPC請求將被視為完整請求。

注意： 使用此規則選項將自動將快速模式內容插入快速模式匹配器。對于UDP規則，將以大小順序排列的UUID接口UUID插入快速模式匹配器。對于TCP的規則，（1）如果規則選項流：to_server | from_client被使用，$\vert$05 00 00$\vert$ 將被插入到快速模式匹配，（2）如果規則選項流：from_server | to_client被使用，$\vert$05 00 00$\vert$ 將被插入到快速模式匹配器中，（3）如果流程未知，則$\vert$05 00 00$\vert$ 將被插入快速模式匹配器。請注意，如果規則中已經包含內容規則選項，則將使用最佳（意味著最長）模式。如果規則中的內容使用fast_pattern規則選項，那么它將明確地用于上述模式。

dce_opnum

opnum表示對接口的特定函數調用。確定客戶端綁定到特定接口并向其發出請求后（請參見上文-dce_iface），通常我們想知道它正在對該服務調用什么功能。漏洞可能存在于特定的DCE / RPC函數調用中。
句法：

    dce_opnum:<opnum-list>;

    opnum-list   = opnum-item | opnum-item ',' opnum-list
    opnum-item   = opnum | opnum-range
    opnum-range  = opnum '-' opnum
    opnum        = 0-65535

例子：

    dce_opnum:15;
    dce_opnum:15-18;
    dce_opnum:15, 18-20;
    dce_opnum:15, 17, 20-22;

dce_stub_data

由于大多數netbios規則僅在進行協議解碼時才獲取DCE / RPC存根數據，即遠程過程調用或函數調用數據，因此該選項將減輕這種需求，并將光標放在DCE / RPC存根數據的開頭。這減少了規則選項檢查的次數和規則的復雜性。此選項不帶參數。

例子：
dce_stub_data

此選項用于將游標(用于在規則處理中遍歷包有效負載)放置在DCE/RPC存根數據的開始位置，而與前面的規則選項無關。這個選項沒有參數。如果存在DCE/RPC存根數據，則此選項匹配。

光標將移動到存根數據的開頭。所有隨后的規則選項都將被視為對該緩沖區“粘滯”。如果dce_stub_data之后的第一個規則選項取決于位置，則應使用絕對位置修飾符。如果后續規則選項與存根數據緩沖區中的先前規則選項匹配，則應使用相對修飾符。任何未指定相對修飾符的規則選項都將從存根數據緩沖區的開頭評估。要離開存根數據緩沖區并返回到主有效負載緩沖區，請使用pkt_data規則選項。

使用dce進行byte_test和byte_jump
DCE / RPC請求可以指定數字是以大端還是小端表示的。這些規則選項將作為新的參數dce并與普通的byte_test / byte_jump基本上相同 ，但是由于DCE / RPC預處理器將知道請求的字節序，因此將能夠進行正確的轉換。

byte_test
句法：

    byte_test:<convert>, [!]<operator>, <value>, <offset> [, relative], dce;

    convert    = 1 | 2 | 4 (only with option "dce")
    operator   = '<' | '=' | '>' | '<=' | '>=' | '&' | '^'
    value      = 0 - 4294967295
    offset     = -65535 to 65535

例子：

    byte_test:4, >, 35000, 0, relative, dce;
    byte_test:2, !=, 2280, -10, relative, dce;

當對byte_test使用dce參數時，以下普通的byte_test參數將不被允許:big、little、string、hex、dec和oct。
byte_jump
語法：

    byte_jump:<convert>, <offset>[, relative][, multiplier <mult_value>] \
        [, align][, post_offset <adjustment_value>], dce;

    convert           = 1 | 2 | 4 (only with option "dce")
    offset            = -65535 to 65535
    mult_value        = 0 - 65535
    adjustment_value  = -65535 to 65535

例子：

 byte_jump:4,-4,relative,align,multiplier 2,post_offset -4,dce;

減少規則復雜度的示例:

以下兩個使用新規則選項的規則替換了不使用新規則選項所必需的64條（set和isset flowbit）規則：

    alert tcp $EXTERNAL_NET any -> $HOME_NET [135,139,445,593,1024:] \
        (msg:"dns R_Dnssrv funcs2 overflow attempt"; flow:established,to_server; \
        dce_iface:50abc2a4-574d-40b3-9d66-ee4fd5fba076; dce_opnum:0-11; dce_stub_data; \
        pcre:"/^.{12}(\x00\x00\x00\x00|.{12})/s"; byte_jump:4,-4,relative,align,dce; \
        byte_test:4,>,256,4,relative,dce; reference:bugtraq,23470; reference:cve,2007-1748;\
        classtype:attempted-admin; sid:1000068;)

    alert udp $EXTERNAL_NET any -> $HOME_NET [135,1024:] \
        (msg:"dns R_Dnssrv funcs2 overflow attempt"; flow:established,to_server; \
        dce_iface:50abc2a4-574d-40b3-9d66-ee4fd5fba076; dce_opnum:0-11; dce_stub_data; \
        pcre:"/^.{12}(\x00\x00\x00\x00|.{12})/s"; byte_jump:4,-4,relative,align,dce; \
        byte_test:4,>,256,4,relative,dce; reference:bugtraq,23470; reference:cve,2007-1748;\
        classtype:attempted-admin; sid:1000069;)

2.2.17 敏感數據預處理器

敏感數據預處理器是一個Snort模塊，用于檢測和過濾個人身份信息（PII）。該信息包括信用卡號，美國社會保險號和電子郵件地址。還包括有限的正則表達式語法，用于定義您自己的PII。

2.2.17.1 依存關系

必須啟用流預處理器才能使敏感數據預處理器正常工作。

2.2.17.2 預處理器配置

敏感數據配置分為兩部分：預處理器配置和規則選項。預處理器配置以以下內容開頭：

preprocessor sensitive_data:

選項語法:

alert_threshold = 1-65535

選項說明:

• alert_threshold| 當在會話中檢測到任何PII組合時，預處理器都會發出警報。此選項指定警報前需要檢測多少個。應將其設置為高于“ sd_pattern”規則中的最高個人計數。
• mask_output| 此選項用“ X”替換檢測到的PII的除了最后4位以外的所有數字。僅在信用卡和社會安全號上執行此操作，否則組織的規定可能會阻止他們看到未加密的號碼。
• ssn_file| 社會保險號分為3個部分：區域（3位數字），組（2位數字）和序列號（4位數字）。社會保障局每月發布一個列表，列出每個地區正在使用的組號。通過在CSV文件中提供要使用的新的最大組編號，可以在Snort中更新這些編號。默認情況下，Snort會識別到2009年11月發布的社會安全號碼。

示例預處理器配置:

preprocessor sensitive_data: alert_threshold 25 \
                             mask_output \
                             ssn_file ssn_groups_Jan10.csv

2.2.17.3 規則選項

Snort規則用于指定預處理程序應查找的PII。預處理器提供了一個新的規則選項：

sd_pattern

此規則選項指定規則應檢測的PII類型。

句法:

    sd_pattern:<count>, <pattern>;
    count   = 1 - 255
    pattern = any string

選項說明

• 計數| 這決定了要生成警報，必須將PII模式匹配多少次。跟蹤會話中所有數據包的計數。
• 模式| 這是指定PII模式的地方。有一些內置模式可供選擇：
  • 信用卡| “ credit_card”模式匹配15位和16位信用卡號。這些數字在組之間可能有空格，破折號或什么都沒有。這包括Visa，Mastercard，Discover和American Express。使用Luhn算法驗證以這種方式匹配的信用卡號的校驗位。
  • us_social| 此模式與9位數的美國社會安全號碼相匹配。SSN的“區域”，“組”和“序列”部分之間應有破折號。SSN沒有校驗位，但是預處理器將根據當前分配的組號列表檢查匹配項。
  • us_social_nodashes| 此模式與美國社會安全號碼相匹配，但沒有用破折號分隔“區域”，“組”和“序列”部分。
  • 電子郵件| 此模式與電子郵件地址匹配。

如果指定的模式不是上述內置模式之一，則它是自定義PII模式的定義。使用受限的正則表達式樣式語法定義自定義PII類型。支持以下特殊字符和轉義序列：

模式中的其他字符將按字面值進行匹配。

注意： 與PCRE不同，此規則選項中的\ w與下劃線不匹配。

例子：
sd_pattern：2，us_social;
在會話中出現2個社會安全號碼（帶破折號）時發出警報。

sd_pattern：5，（\ d {3}）\ d {3}-\ d {4};
按照格式(123)456-7890的5個美國電話號碼發出警報
整個規則示例：

    alert tcp $HOME_NET $HIGH_PORTS -> $EXTERNAL_NET $SMTP_PORTS \
    (msg:"Credit Card numbers sent over email"; gid:138; sid:1000; rev:1; \
    sd_pattern:4,credit_card; metadata:service smtp;)

注意事項: sd_pattern與其他規則選項不兼容。嘗試將其他規則選項與sd_pattern一起使用將導致錯誤消息。

使用sd_pattern的規則必須使用GID 138。

2.2.18 標準化

在內聯模式下操作Snort時，對數據包進行規范化有助于降低規避漏洞的機會。

要啟用標準化器，請在配置Snort時使用以下命令：

./configure-enable-normalizer

規范化預處理器通過conf激活，如下所示。也有許多新的預處理器和解碼器規則來警告或丟棄具有“異常”編碼的數據包。

請注意，在下文中，僅當字段非零時才清除字段。此外，僅當選定的DAQ支持數據包替換并且以內聯模式運行時，才能啟用規范化。

如果將策略配置為inline_test或被動模式，則將忽略該策略配置中的任何規范化語句。

2.2.18.1 IP4規范化

IP4規范化通過以下方式啟用：

preprocessor normalize_ip4：[df]，[rf]，[tos]，[trim]

通過“ preprocessor normalize_ip4 ” 啟用的基本規范化包括：

• TTL標準化（如果啟用）（如下所述）。
• 清除差異服務字段（以前為TOS）。
• NOP所有選項字節。

可選的規范化包括：

• df 不要分段：清除傳入數據包上的此位。
• rf 保留標志：清除傳入數據包的該位。
• TOS 服務類型（區分服務）：清除該字節。
• trim 截斷分組用過量的有效載荷，以在IP報頭+層2報頭（例如，以太網）中指定的數據報的長度，但不截斷低于最小幀長。如果DAQ無法注入數據包，則會自動禁用此功能。

2.2.18.2 IP6規范化

IP6規范化通過以下方式啟用：

preprocessor normalize_ip6

通過“ preprocessor normalize_ip6 ” 啟用的基本規范化包括：

• 跳數限制規范化（如果啟用）（如下所述）。
• 在逐跳和目標選項擴展頭中NOP所有選項八位位組。

2.2.18.3 ICMP4 / 6規范化

ICMP4和ICMP6規范化可通過以下方式啟用：

preprocessor normalize_ip4
preprocessor normalize_ip6

上面啟用的基本規范化包括：

• 清除回顯請求和答復中的代碼字段。

2.2.18.4 TCP規范化

TCP規范化可通過以下方式啟用：

    preprocessor normalize_tcp: \
        [block], [rsv], [pad], \
        [req_urg], [req_pay], [req_urp], \
        [ips], [urp], [trim], \
        [trim_syn], [trim_rst], \
        [trim_win], [trim_mss], \
        [ecn <ecn_type>], \
        [opts [allow <allowed_opt>+]]

    <ecn_type> ::= stream | packet

    <allowed_opt> ::= \
        sack | echo | partial_order | conn_count | alt_checksum | md5 | <num>

    <sack> ::= { 4, 5 }
    <echo> ::= { 6, 7 }
    <partial_order> ::= { 9, 10 }
    <conn_count> ::= { 11, 12, 13 }
    <alt_checksum> ::= { 14, 15 }
    <md5> ::= { 19 }
    <num> ::= (3..255)

規范化包括：

• block TCP規范化期間，允許數據包丟棄。

• rsv 清除TCP標頭中的保留位。

• pad 清除所有選項填充字節。

• req_urg 如果未設置緊急標志，則清除緊急指針。

• req_pay 如果沒有有效載荷，則清除緊急指針和緊急標志。

• req_urp 如果未設置緊急指針，則清除緊急標志。

• ips 確保重傳數據的一致性（也將重組策略強制為“ first”）。任何無法正確重組的段都將被丟棄。

• trim_syn 刪除SYN上的數據。

• trim_rst 從RST數據包中刪除所有數據。

• trim_win 數據修剪到窗口。

• trim_mss 數據修剪為MSS。

• trim 啟用以上所有修剪選項。

• ecn packet
  在每個數據包的基礎上清除ECN標志（與協商無關）。

• ecn stream

  如果未協商使用情況，請清除ECN標志。還應該啟用require_3whs。

• opts

  NOP除了最大段大小，窗口縮放，時間戳以及allow關鍵字明確允許的任何選項字節以外的所有選項字節。您可以允許按名稱或數字傳遞選項。

• opts

  如果時間戳存在但無效，或者有效但未經協商，則NOP時間戳八位字節。

• opts

  如果協商了時間戳但不存在，則阻止該數據包。

• opts

  如果未設置ACK標志，則清除TS ECR。

• opts

  如果未設置SYN標志，則MSP和窗口比例選項為NOP。

2.2.18.5 TTL標準化

TTL標準化同時適用于IP4 TTL（生存時間）和IP6（躍點限制），并且僅在同時啟用了相關基本標準化（如上所述）并且配置了最小和新TTL值的情況下才執行TTL標準化：

    config min_ttl: <min_ttl>
    config new_ttl: <new_ttl>

    <min_ttl> ::= (1..255)
    <new_ttl> ::= (<min_ttl>+1..255)

如果是new_ttl ``min_ttl，則如果接收到帶有TTL min_ttl的數據包，則TTL將設置為new_ttl。

請注意，此配置項在2.8.6中已棄用：

preprocessor stream5_tcp: min_ttl <#>

默認情況下，min_ttl = 1（禁用了TTL標準化）。啟用TTL標準化時，默認情況下new_ttl設置為5。

2.2.19 SIP預處理器

會話發起協議（SIP）是一種應用程序層控制（信號）協議，用于創建，修改和終止與一個或多個參與者的會話。這些會議包括Internet電話呼叫，多媒體分發和多媒體會議。SIP預處理程序提供了解決過去幾年中與SIP相關的常見漏洞和披露（CVE）的方法。這也使檢測新攻擊更加容易。

2.2.19.1 依賴性要求

為了使預處理器正常工作：

• 流會話跟蹤必須啟用，即stream5。必須在stream5中同時啟用TCP和UDP。預處理器需要會話跟蹤器來保留其數據。此外，Stream API能夠為忽略音頻/視頻數據通道提供正確的支持。
• 應該啟用IP碎片整理，即應該啟用和配置frag3預處理程序。

2.2.19.2 配置

預處理程序配置名稱為sip。
preprocessor sip

選項語法:

     max_sessions        = 1024-4194303
     max_dialogs         = 1-4194303
     methods             = "invite"|"cancel"|"ack"|"bye"|"register"| "options"\
                           |"refer" |"subscribe"|"update"|"join"|"info"|"message"\                
                           |"notify"|"prack"
     max_uri_len         = 0-65535
     max_call_id_len     = 0-65535
     max_requestName_len = 0-65535
     max_from_len        = 0-65535
     max_to_len          = 0-65535
     max_via_len         = 0-65535
     max_contact_len     = 0-65535
     max_content_len     = 0-65535

選項說明:

• disabled| 可以通過配置啟用/禁用SIP動態預處理器。默認情況下，此值處于關閉狀態。禁用預處理器時，在配置中指定時僅應用max_sessions選項。

• max_sessions| 這指定可以分配的最大會話數。這些會話是流會話，因此它們受最大流會話數限制。默認值為10000

• max_dialogs| 這指定一個流會話中對話框的最大數量。如果超過，最舊的對話框將被刪除。默認值為4。

• ports| 這指定在哪些端口上檢查SIP消息。通常，這將包括5060、5061。
  句法:
  ports { <port> [<port>< ... >] }
  例子：
  ports { 5060 5061 }

• methods| 這指定了檢查SIP消息的方法：（1）邀請，（2）取消，（3）確認，（4）再見，（5）注冊，（6）選項，（7）引用，（8）訂閱，（9）更新（10）加入（11）信息（12）消息（13）通知（14）消息。注意：這14種方法是最新列表（2011年2月）。可以將新方法添加到列表中。最多支持32種方法。
  句法 :

      methods { <method-list> }
      method-list = method|method method-list
      methods     = "invite"|"cancel"|"ack"|"bye"|"register"| "options"\
                    |"refer"|"subscribe"|"update"|"join"|"info"|"message"\                
                    |"notify"|"prack"

  例子：

   methods { invite cancel ack bye register options }
   methods { invite cancel ack bye register options information }

  注意:“{”和“}”的前后有空格。

• max_uri_len| 這指定最大請求URI字段大小。如果“請求URI”字段大于此大小，則會生成警報。默認設置為256。此選項的允許范圍是0-65535。“ 0”表示永不警報。

• max_call_id_len| 這指定最大的Call-ID字段大小。如果“呼叫ID”字段大于此大小，則會生成警報。默認設置為256。此選項的允許范圍是0-65535。“ 0”表示永不警報。

• max_requestName_len| 這指定了CSeq ID的最大請求名稱大小。如果請求名稱大于此大小，則會生成警報。默認設置為20。此選項的允許范圍是0-65535。“ 0”表示從不發出警報。

• max_from_len| 這指定最大的From字段大小。如果“發件人”字段大于此大小，則會生成警報。默認設置為256。此選項的允許范圍是0-65535。“ 0”表示永不警報。

• max_to_len| 這指定最大To字段大小。如果“收件人”字段大于此大小，則會生成警報。默認設置為256。此選項的允許范圍是0-65535。“ 0”表示永不警報。

• max_via_len| 這指定最大的“通過”字段大小。如果“通過”字段大于此大小，則會生成警報。默認設置為1024。此選項的允許范圍是0-65535。“ 0”表示永不警報。

• max_contact_len| 這指定最大的“聯系人”字段大小。如果“聯系人”字段大于此大小，則會生成警報。默認設置為256。此選項的允許范圍是0-65535。“ 0”表示永不警報。

• max_content_len| 這指定消息正文的最大內容長度。如果內容長度大于此數字，則會生成警報。默認設置為1024。此選項的允許范圍是0-65535。“ 0”表示永不警報。

• ignore_call_channel| 這樣就可以支持忽略音頻/視頻數據通道（通過Stream API）。默認情況下，這是禁用的。

選項示例:

     max_sessions 30000
     disabled
     ports { 5060 5061 }
     methods { invite cancel ack bye register options }
     methods { invite cancel ack bye register options information }
     max_uri_len 1024
     max_call_id_len 1024
     max_requestName_len 10
     max_from_len 1024
     max_to_len 1024
     max_via_len 1024
     max_contact_len 1024
     max_content_len 1024
     max_content_len
     ignore_call_channel

配置實例

     preprocessor sip
     preprocessor sip: max_sessions 500000
     preprocessor sip: max_contact_len 512, max_sessions 300000, methods { invite \
                       cancel ack bye register options } , ignore_call_channel
     preprocessor sip: ports { 5060 49848 36780 10270 }, max_call_id_len 200, \
                      max_from_len 100, max_to_len 200, max_via_len 1000, \
                      max_requestName_len 50, max_uri_len 100, ignore_call_channel,\
                      max_content_len 1000
     preprocessor sip: disabled
     preprocessor sip: ignore_call_channel

默認配置
preprocessor sip

2.2.19.3 事件

預處理器使用GID 140來注冊事件。

2.2.19.4 規則選項

通過啟用sip預處理器來支持新的規則選項：

sip_method
sip_stat_code
sip_header
sip_body

對現有pcre規則選項的重載修飾符：

• H：匹配SIP請求或SIP響應頭，類似于sip_header。

• P：匹配SIP請求或SIP響應主體，類似于sip_body。

  sip_method

sip_method關鍵字用于檢查特定SIP請求的方法。方法列表為：邀請，取消，確認，再見，注冊，選項，引用，訂閱，更新，加入，信息，消息，通知，發送。通過逗號分隔的列表可以指定多個方法，并且可以將這些方法進行“或”運算。如果可用，它將以快速模式匹配方式應用。如果此規則中使用的方法未在預處理器配置中列出，它將被添加到關聯策略的預處理器配置中。
句法:

    sip_method:<method-list>;
    method-list = method|method, method-list
    method      = ["!"] "invite"|"cancel"|"ack"|"bye"|"register"| "options"
                  |"refer"|"subscribe"|"update"|"join"|"info"|"message"\                
                  |"notify"|"prack"
    Note: if "!" is used, only one method is allowed in sip_method.

例子：

   sip_method:invite, cancel
   sip_method:!invite

   Note: If a user wants to use "and", they can use something like this:
   sip_method:!invite; sip_method:!bye

sip_stat_code

該sip_stat_code用于檢查SIP響應狀態代碼。如果指定的任何狀態代碼與SIP響應的狀態代碼匹配，則此選項匹配。
句法:

   sip_stat_code:<code _list> ;
   code_list = state_code|state_code, code_list
   code      = "100-999"|"1-9"

例子：

   sip_stat_code:200  
   sip_stat_code: 2  
   sip_stat_code: 200, 180

sip_header

所述sip_header關鍵字限制搜索到的SIP消息請求或響應的所提取的報頭字段。這類似于file_data。
句法:
sip_header;

例子:
alert udp any any -> any 5060 (sip_header; content:"CSeq"; )

sip_body

sip_body關鍵字在SIP消息的主體領域的開始將光標置于。這種工作原理類似于file_data和dce_stub_data。消息主體包括使用SDP協議（會話描述協議）的信道信息。
句法:
sip_body;
例子:
alert udp any any -> any 5060 (sip_body; content:"C=IN 0.0.0.0"; within 100;)

pcre

SIP重載了pcre的兩個選項：

• H：匹配SIP標頭以進行請求或響應，類似于sip_header。
• P：匹配SIP主體以進行請求或響應，類似于sip_body。
  例子:

  alert udp any any -> any 5060 (pcre:"/INVITE/H"; sid:1000000;)
  alert udp any any -> any 5060 (pcre:"/m=/P"; sid:2000000;)

2.2.20 信譽預處理器

信譽預處理器提供基本的IP黑名單/白名單功能，以阻止/丟棄/傳遞來自列出的IP地址的流量。過去，我們使用標準的Snort規則來實現基于信譽的IP阻止。該預處理器將解決性能問題，并使IP信譽管理更加容易。該預處理器先于其他預處理器運行。

2.2.20.1 配置

預處理程序的配置名稱為信譽。

Reputation Preprocessor

選項語法:

| 選項 | 論據 | 需要 | 默認 |
| memcap | <memcap> | 沒有 | memcap500 |
| scan_local | NONE | 沒有 | 關 |
| 黑名單 | <list file name> | 沒有 | NONE |
| 白名單 | <list file name> | 沒有 | NONE |
| priority | [黑名單 白名單] | 沒有 | 白名單優先 |
| nested_ip | [inner outer both] | 沒有 | nested_ip inner |
| White | [unblack trust] | 沒有 | white unblack |

memcap = 1-4095 Mbytes

選項說明:

• memcap| 支持的最大總內存。可以設置為4095 MB。

• scan_local| 啟用檢查RFC 1918中定義的本地地址：| 10.0.0.0-10.255.255.255（前綴10/8）| 172.16.0.0-172.31.255.255（172.16 / 12前綴）| 192.168.0.0-192.168.255.255（192.168 / 16前綴）

• 黑名單/白名單| IP列表是從外部文件加載的。它支持包含的相對路徑和$ variables的路徑。支持多個黑名單或白名單。

  注意：如果稍后重新定義相同的IP，它將覆蓋先前的IP。換句話說，IP列表始終優先處理最后處理的文件或條目。

• priority| 當源/目標在黑名單上而目標/源在白名單上時，指定黑名單或白名單具有更高的優先級。缺省情況下，白名單優先級高。換句話說，當源或目標被列入白名單時，數據包將通過。

  注意：這僅在運行時存在決策沖突時定義優先級。在初始化期間，如果在白名單和黑名單中定義了相同的IP地址，則最后定義的那個將是最后一個。在這種情況下，優先級無效。

• nested_ip| 指定存在IP封裝時要使用的IP地址。

• white| 指定白名單的含義。如果白色表示未黑，則將黑名單中的IP取消黑。當白色表示信任時，數據包將被繞過，而不會被snort進一步檢測到。您只能指定不黑或信任。

  注意：當白色表示不黑時，白名單的優先級始終高于黑名單。

配置實例:

    preprocessor reputation:\ 
                   blacklist /etc/snort/default.blacklist, \
                   whitelist /etc/snort/default.whitelist

    preprocessor reputation: \
                   nested_ip both, \
                   blacklist /etc/snort/default.blacklist, \
                   whitelist /etc/snort/default.whitelist

    preprocessor reputation: \
                   memcap  4095, scan_local, nested_ip both, \
                   priority whitelist,  \
                   blacklist /etc/snort/default.blacklist, \
                   whitelist /etc/snort/default.whitelist,
                   white trust

    $REP_BLACK_FILE1 = ../dshield.list
    $REP_BLACK_FILE2 = ../snort.org.list
    preprocessor reputation: \
                blacklist $REP_BLACK_FILE1,\
                blacklist $REP_BLACK_FILE2

IP列表文件格式:

• 句法| IP列表文件每行有1個條目。該條目可以是IP條目，也可以是注釋。
• IP輸入| CIDR注釋< comments> 換行符。

例： 172.16.42.32/32
172.33.42.32/16

• 注釋| 注釋以＃開頭 #< comments>

例:

    #  This is a full line comment
    172.33.42.32/16    # This is a in-line comment

IP列表文件示例:

    # This is a full line comment
    172.16.42.32/32    # This is an inline comment, line with single CIDR block
    172.33.42.32/16

用例:

用戶只想允許某些受信任的IP，就想保護他/她的網絡免受有害/未知IP的侵害。配置如下：

  preprocessor reputation: \
        blacklist /etc/snort/default.blacklist
        whitelist /etc/snort/default.whitelist

  In file "default.blacklist"
        # These two entries will match all ipv4 addresses  
        1.0.0.0/1  
        128.0.0.0/1

  In file "default.whitelist"
        68.177.102.22 # sourcefire.com
        74.125.93.104 # google.com

2.2.20.2 事件

信譽預處理器使用GID 136來注冊事件。

2.2.20.3 共享內存支持

為了在同時運行多個Snort實例時最大程度地減少內存消耗，我們引入了對共享內存的支持。配置后，所有snort實例在共享內存中共享相同的IP表。

• 系統要求| 僅在Linux中支持此功能。

• 構建配置| ./configure命令中引入了一個新選項-enable-shared-rep。此選項啟用對共享內存的支持。

• 配置

  • shared_mem| 如果構建支持共享內存，則此配置將啟用共享內存。如果未設置此選項，則使用標準內存。此選項必須指定將IP列表加載到共享內存中的路徑或目錄。一個snort實例將創建并維護共享的IP列表。我們使用實例ID 1（在snort -G選項中指定為主snort）。所有其他snort實例都是客戶端（讀取器）。
    句法：
    shared_mem：path
    例子: shared_mem /user/reputation/iplists

  • shared_refresh| 此選項以秒為單位更改檢查新共享內存段的時間。默認情況下，刷新速率為60秒。 句法: shared_refresh <period> period = "1 - 4294967295"
    例子: shared_refresh 60

• 配置共享內存的步驟:

  • 構建Snort時，將選項-enable-shared-rep添加到./configure中
    例如：

    ./configure --enable-gre --enable-sourcefire --enable-flexresp3 
    --enable-pthread --enable-linux-smp-stats 
    --enable-targetbased --enable-shared-rep --enable-control-socket

  • 將您的IP列表文件放在snort擁有完全訪問權限的目錄中。
    例如：/user/reputation/iplists
    為了將白名單與黑名單分開，您需要指定擴展名為.wlf的白名單和擴展名為.blf的黑名單。

  • 在snort配置文件中，使用IP文件的路徑指定共享內存支持。
    例如：shared_mem /user/reputation/iplists
    如果要更改檢查新IP列表的時間，請添加刷新時間。
    例如：shared_refresh 300

  • 使用-G 0選項啟動共享內存主（寫入器）。注意：僅應啟用一個主機。

  • 使用-G 1或其他ID 啟動共享內存客戶端（讀取器）。注意：對于一個ID，僅應啟用一個snort實例。

  • 您將看到IP列表已加載并在snort實例之間共享！

• 使用控制套接字重新加載IP列表

  • 使用帶有選項-cs-dir <path>的命令行運行snort或使用以下命令配置snort：
    config cs_dir：<path>

  • （可選）您可以在IP列表目錄中創建一個名為“ IPRVersion.dat”的版本文件。該文件通過指定版本來幫 助管理重新加載IP列表。當版本未更改時，如果IP列表已經在共享內存中，則不會重新加載它們。版本號應為32位數字。
    例如：VERSION = 1

  • 在<snort root> / src / tools / control目錄中，如果使用-enable-control-socket選項構建，則會找到snort_control命令 。

  • 鍵入以下命令以重新加載IP列表。鍵入此命令之前，如果要使用版本文件，請確保更新版本文件。所述<路徑>是在第一步驟中相同的路徑。
    <snort root> / src / tools / control / snort_control <path> 1361

• 使用清單文件來管理加載（可選）

  使用清單文件，您可以控制文件加載順序，采取的措施以及基于區域的檢測。您可以在IP列表目錄中創建一個名為“ zone.info”的清單文件。當通知Snort加載新列表時，首先讀取清單文件，以確定每個列表中的IP適用于哪些區域以及每個列表采取什么操作（阻止，白色，監視）。清單中列出的文件從上到下加載。您應該將優先級較高的文件放在首位。在清單文件中，最多可以放置255個文件。沒有清單文件，文件將按字母順序加載。這是清單文件的格式。文件的每一行具有以下格式：

  <filename>, <list id>,<action>[, <zone>]+
  <list id> ::= 32 bit integer
  <action> ::= "monitor"|"block"|"white"
  <zone>  ::= [0-1051]

  使用清單文件，您可以指定一個名為“ monitor”的新操作，該操作指示需要檢查數據包，但不會禁用檢測。這與“阻止”操作不同，后者阻止了進一步的檢測。此新操作可幫助用戶在應用IP列表之前評估其IP列表。
  清單文件示例：

    #ipreputation manifest file
    white.wlf, 111 ,white, 
    black1.blf, 1112, black,  3, 12
    black2.blf, 1113, black,  3, 12
    monitor.blf,2222, monitor, 0, 2, 8

2.2.21 GTP解碼器和預處理器

在核心通信網絡中使用GTP（GPRS隧道協議）在GSN（GPRS服務節點）之間建立通道。GTP解碼預處理器提供了通過GTP解決對這些網絡的入侵嘗試的方法。這也使檢測新攻擊更加容易。

開發了兩個組件：GTP解碼器和GTP預處理器。

• GTP解碼器提取GTP PDU內部的有效負載；
• GTP預處理器檢查所有信令消息并提供關鍵字以供進一步檢查

啟用并配置解碼器后，解碼器將剝離GTP標頭并解析底層IP / TCP / UDP封裝的數據包。因此，所有規則和檢測就像沒有GTP標頭一樣工作。

例：
大多數GTP數據包看起來像這樣IP-> UDP-> GTP-> IP-> TCP-> HTTP
如果您有標準的HTTP規則：

alert tcp any any ->  any $HTTP_PORTS (msg:"Test HTTP"; flow:to_server,established; 
content:"SOMETHINGEVIL"; http_uri;  .... sid:X; rev:Y;)

2.2.21.1 依賴性要求

為了使預處理器正常工作：

• 流會話跟蹤必須啟用，即stream5。必須在stream5中啟用UDP。預處理器需要會話跟蹤器來保留其數據。
• 應該啟用IP碎片整理，即應該啟用和配置frag3預處理程序。

2.2.21.2 GTP數據通道解碼器配置

GTP解碼器從GTP PDU中提取有效負載。以下配置設置了GTP解碼：

config enable_gtp

默認情況下，GTP解碼器使用端口號2152（GTPv1）和3386（GTPv0）。如果用戶想要更改這些值，則可以使用portvar GTP_PORTS：

portvar GTP_PORTS [2152,3386]

2.2.21.3 GTP控制通道預處理器配置

與GTP解碼器不同，GTP預處理器檢查所有信令消息。預處理程序配置名稱為gtp。

preprocessor gtp

選項語法:

選項說明:

ports| 這指定在哪些端口上檢查GTP消息。通常，這將包括2123、3386。
句法:
ports { <port> [<port>< ... >] }
例子:
ports { 2123 3386 2152 }

注意：“ {”和“}”之前和之后都有空格。

默認配置:

preprocessor gtp

2.2.21.4 GTP解碼器事件

2.2.21.5 GTP預處理程序事件

2.2.21.6 規則選項

通過啟用gtp預處理程序來支持新的規則選項：

gtp_type
gtp_info
gtp_version

• gtp_type
gtp_type關鍵字用于檢查特定GTP類型。用戶可以輸入消息類型值，[0，255]中的整數或下表中定義的字符串。可以通過逗號分隔的列表指定多個類型，并將它們進行“或”運算。如果在預處理器配置中未列出規則中使用的類型，則將引發錯誤。
  消息類型在不同的GTP版本中可以具有不同的類型值。例如，sgsn_context_request在GTPv0和GTPv1中具有消息類型值50，但在GTPv2中具有消息類型值130。gtp_type將匹配不同的值，具體取決于數據包中的版本號。在此示例中，評估GTPv0或GTPv1數據包將檢查消息類型值是否為50; 評估GTPv2數據包將檢查消息類型值是否為130。當版本中未定義消息類型時，該版本中的任何數據包將始終返回“不匹配”。
  如果使用整數指定消息類型，則無論該GTP數據包是什么版本，都將對其進行評估。如果消息類型與數據包中的值匹配，它將返回“匹配”。
  句法:

    gtp_type:<type-list>;
   type-list = type|type, type-list
   type      = "0-255"|
                | "echo_request" | "echo_response" ...

  例子:
  gtp_type：10，11，echo_request;

GTP消息類型:

• gtp_info

  所述gtp_info關鍵字用于檢查特定GTP信息元素。此關鍵字將搜索限制為信息元素字段。用戶可以輸入信息元素值中的整數[0,255]或下表中定義的字符串。如果此規則中使用的信息元素未在預處理器配置中列出，則將引發錯誤。
  當消息中有多個具有相同類型的信息元素時，此關鍵字將搜索限制為總連續緩沖區。因為該標準要求將相同類型的組放在一起，所以該功能將可用于所有有效消息。在“亂序信息元素”的情況下，此關鍵字將搜索限制為最后一個緩沖區。
  與消息類型類似，相同的信息元素在不同的GTP版本中可能具有不同的信息元素值。例如， cause在GTPv0和GTPv1中具有值1，但是2在GTPv2中。 gtp_info將匹配不同的值，具體取決于數據包中的版本號。當未在版本中定義信息元素時，該版本中的任何數據包將始終返回“無匹配項”。如果使用整數指定信息元素類型，則無論該GTP數據包是什么版本，都將對其進行評估。如果消息類型與數據包中的值匹配，它將返回“匹配”。
  句法:

  gtp_info：<ie>;
  ie=“ 0-255” |
  “ rai” | “ tmsi” ...

  例子:

  gtp_info：16； gtp_info：tmsi

GTP信息元素:

• gtp_version

該gtp_version關鍵字用于檢查特定GTP版本。
由于不同的GTP版本定義了不同的消息類型和信息元素，因此此關鍵字應與gtp_type 和gtp_info結合使用。句法:

   gtp_version:<version>;
   version   = "0, 1, 2'

例子: gtp_version：1；

2.2.22 Modbus預處理器

Modbus預處理器是一個Snort模塊，可對Modbus協議進行解碼。它還提供了訪問某些協議字段的規則選項。這使用戶可以編寫Modbus數據包規則，而無需使用一系列“內容”和“ byte_test”選項對協議進行解碼。

Modbus是SCADA網絡中使用的協議。如果您的網絡不包含任何啟用了Modbus的設備，建議關閉此預處理器。

2.2.22.1 依賴性要求

為了使預處理器正常工作：

• 流會話跟蹤必須啟用，即stream5。必須在stream5中啟用TCP。預處理器需要會話跟蹤器來保留其數據。
• 必須啟用協議感知刷新（PAF）。
• 應該啟用IP碎片整理，即應該啟用和配置frag3預處理程序。

2.2.22.2 預處理器配置

首先，必須啟用Modbus預處理器。預處理器名稱為modbus。

preprocessor modbus

選項語法:

選項說明:

• ports| 這指定在哪些端口上檢查Modbus消息。通常，這將包括502。
  句法:
  ports { <ports> [<ports> <...>] }
  例子: ports { 1237 3945 5067 }

默認配置: preprocessor modbus

2.2.22.3 規則選項

Modbus預處理器添加了3個新規則選項。這些規則選項在Modbus標頭的各個部分上匹配：

modbus_func
modbus_unit
modbus_data

必須啟用預處理器才能使這些規則選項起作用。

• modbus_func
  此選項與Modbus頭內部的功能代碼匹配。該代碼可以是數字（十進制格式），也可以是下面提供的列表中的字符串。
  句法:

    modbus_func:<code>
  
    code  = 0-255 |
            "read_coils" |
            "read_discrete_inputs" |
            "read_holding_registers" |
            "read_input_registers" |
            "write_single_coil" |
            "write_single_register" |
            "read_exception_status" |
            "diagnostics" |
            "get_comm_event_counter" |
            "get_comm_event_log" |
            "write_multiple_coils" |
            "write_multiple_registers" |
            "report_slave_id" |
            "read_file_record" |
            "write_file_record" |
            "mask_write_register" |
            "read_write_multiple_registers" |
            "read_fifo_queue" |
            "encapsulated_interface_transport"

例子:

 modbus_func：1;
 modbus_func：write_multiple_coils;

• modbus_unit
  此選項與Modbus標頭中的Unit ID字段匹配。

句法:

    modbus_unit:<unit>

    unit = 0-255

例子:

modbus_unit：1;

• modbus_data
  此規則選項將光標設置在Modbus請求/響應中“數據”字段的開頭。

句法:

modbus_data;

例子:

modbus_data; context：“ badstuff”；

2.2.22.4 預處理器事件

Modbus預處理器將GID 144用于其預處理器事件。

2.2.23 DNP3預處理器

DNP3預處理器是一個Snort模塊，可對DNP3協議進行解碼。它還提供了訪問某些協議字段的規則選項。這允許用戶編寫DNP3數據包的規則，而無需使用一系列“內容”和“ byte_test”選項對協議進行解碼。

DNP3是SCADA網絡中使用的協議。如果您的網絡不包含任何啟用DNP3的設備，建議關閉此預處理器。

2.2.23.1 依賴性要求

為了使預處理器正常工作：

• 流會話跟蹤必須啟用，即stream5。必須在stream5中啟用TCP或UDP。預處理器需要會話跟蹤器來保留其數據。
• 必須啟用協議感知刷新（PAF）。
• 應該啟用IP碎片整理，即應該啟用和配置frag3預處理程序。

2.2.23.2 預處理器配置

首先，必須啟用DNP3預處理器。預處理程序名稱是dnp3。

preprocessor dnp3

選項語法:

| 選項 | 論據 | 需要 | 默認 |
| ports | <ports> | 沒有 | ports{20000} |
| memcap | <number> | 沒有 | memcap262144 |
| check_crc | NONE | 沒有 | 關 |
| disabled | NONE | 沒有 | 關 |

選項說明:

• ports| 這指定在哪些端口上檢查DNP3消息。通常，這將包括20000。
  句法: ports { <port> [<port>< ... >] }
  例子:ports { 1237 3945 5067 }

  注意：“ {”和“}”之前和之后都有空格。

• memcap| 這將最大數量分配給分配給DNP3預處理器以進行會話跟蹤的內存量。參數以字節為單位。每個會話大約需要4 KB的跟蹤時間，默認值為256 kB。這使預處理器能夠同時跟蹤63個DNP3會話。將memcap設置為4144字節以下將導致致命錯誤。當使用多個配置時，非默認配置中的memcap將被默認配置中的memcap覆蓋。如果默認配置不是用于檢查DNP3流量的，請使用“ disabled”關鍵字。

• check_crc| 此選項使預處理器驗證DNP3鏈接層幀中包含的校驗和。校驗和無效的幀將被忽略。如果啟用了相應的預處理程序規則，則無效的校驗和將生成警報。相應的規則是GID 145，SID 1。

• disabled| 此選項用于加載預處理器而不檢查任何DNP3流量。在禁用時，DNP3預處理器在一個單獨的政策已開啟的關鍵字是唯一有用的。

默認配置: `preprocessor dnp3

2.2.23.3 規則選項

DNP3預處理器添加了4個新規則選項。這些規則選項在DNP3標頭的各個部分上匹配：

dnp3_func
dnp3_obj
dnp3_ind
dnp3_data

必須啟用預處理器才能使這些規則選項起作用。

• dnp3_func
  此選項與DNP3應用程序層請求/響應標頭中的功能代碼匹配。該代碼可以是數字（十進制格式），也可以是下面提供的列表中的字符串。

句法:

    dnp3_func:<code>

    code  = 0-255 |
            "confirm" |
            "read" |
            "write" |
            "select" |
            "operate" |
            "direct_operate" |
            "direct_operate_nr" |
            "immed_freeze" |
            "immed_freeze_nr" |
            "freeze_clear" |
            "freeze_clear_nr" |
            "freeze_at_time" |
            "freeze_at_time_nr" |
            "cold_restart" |
            "warm_restart" |
            "initialize_data" |
            "initialize_appl" |
            "start_appl" |
            "stop_appl" |
            "save_config" |
            "enable_unsolicited" |
            "disable_unsolicited" |
            "assign_class" |
            "delay_measure" |
            "record_current_time" |
            "open_file" |
            "close_file" |
            "delete_file" |
            "get_file_info" |
            "authenticate_file" |
            "abort_file" |
            "activate_config" |
            "authenticate_req" |
            "authenticate_err" |
            "response" |
            "unsolicited_response" |
            "authenticate_resp"

例子:

dnp3_func：1; dnp3_func：delete_file;

• dnp3_ind
  此選項與DNP3應用程序響應標題中的“內部指示器”標志匹配。與TCP標志規則選項非常相似，如果設置了任何 一個標志，則在一個選項中提供多個標志將導致規則觸發。要警告組合標志，請使用多個規則選項。

句法:

    dnp3_ind:<flag>{,<flag>...]

    flag =  "all_stations"
            "class_1_events"
            "class_2_events"
            "class_3_events"
            "need_time"
            "local_control"
            "defice_trouble"
            "device_restart"
            "no_func_code_support"
            "object_unknown"
            "parameter_error"
            "event_buffer_overflow"
            "already_executing"
            "config_corrupt"
            "reserved_2"
            "reserved_1"

例子:

    # Alert on reserved_1 OR reserved_2
    dnp3_ind:reserved_1,reserved_2;

    # Alert on class_1 AND class_2 AND class_3 events
    dnp3_ind:class_1_events; dnp3_ind:class_2_events; dnp3_ind:class_3_events;

• dnp3_obj
  此選項與請求或響應中存在的DNP3對象標頭匹配。

句法:

 dnp3_obj：<group>，<var>
 組= 0-255 var = 0-255

例子:

    # Alert on DNP3 "Date and Time" object
    dnp3_obj:50,1;

• dnp3_data
  當Snort處理DNP3數據包時，DNP3預處理器將收集鏈路層幀，并將其重新組合成應用程序層片段。此規則選項將光標設置在“應用程序層片段”的開頭，以便其他規則選項可以處理重組后的數據。使用dnp3_data規則選項，您可以基于分片中的數據編寫規則，而無需拆分數據并每16個字節添加CRC。

句法:

dnp3_data;

例子:

dnp3_data; context：“ badstuff_longer_than_16chars”;

2.2.23.4 預處理器事件

DNP3預處理器將GID 145用于其預處理器事件。

2.2.24 AppId預處理器

隨著網絡的日益復雜和網絡流量的增長，網絡管理員需要在管理網絡時了解應用程序。管理員可能只允許與業務相關，低帶寬和/或處理某些主題的應用程序。

AppId預處理器添加了應用程序級別視圖來管理網絡。通過添加以下功能來做到這一點

• 網絡控制：預處理器通過使Snort規則編寫器可以使用一組應用程序標識符（AppId）來簡化簡化的單點應用程序感知。
• 網絡使用意識：預處理器輸出統計信息，以顯示網絡上看到的每個應用程序使用的網絡帶寬。管理員可以監視帶寬使用情況，并可以決定阻止浪費的應用程序。
• 定制應用程序：預處理器使管理員能夠創建自己的應用程序檢測器來檢測新應用程序。檢測器使用Lua編寫，并使用定義明確的C-Lua API與Snort交互。

2.2.24.1 依賴性要求

為了使預處理器正常工作：

• 流會話跟蹤必須啟用，即stream5。必須在stream5中啟用TCP或UDP。預處理器需要會話跟蹤器來保留其數據。
• 必須啟用協議感知刷新（PAF）。
• 應該啟用IP碎片整理，即應該啟用和配置frag3預處理程序。
• 必須啟用和配置HTTP預處理器。處理器不需要任何特定于AppId的配置。預處理器提供了已解析的HTTP標頭，用于確定應用程序。如果沒有HTTP預處理程序，AppId預處理程序將僅識別非HTTP應用程序。
• LuaJIT版本2.0.2必須安裝在正在編譯和運行snort的主機上。尚未測試較新版本的LuaJIT的兼容性。

2.2.24.2 預處理器配置

默認情況下（從snort-2.9.12開始）啟用AppId動態預處理器。通過在./configure中包含以下選項，可以在構建期間禁用預處理器：

-disable-open-appid

配置名稱為“ appid”：

預處理程序名稱為appid。

preprocessor appid

選項語法:

選項說明:

• app_detector_dir| 指定通過ODP（開放檢測器軟件包）軟件包安裝思科提供的檢測器和應用程序配置文件的基本路徑。該軟件包包含Lua檢測器和一些應用程序元數據。客戶編寫的檢測器存儲在同一基本路徑下的“ custom”子目錄中。
  句法:
  app_detector_dir <directory name>
  例子:app_detector_dir / usr / local / cisco / apps

• app_stats_filename| 文件名。如果缺少此配置，則會禁用應用程序統計信息。
  句法:app_stats_filename <filename>
  例子 :app_stats_filename appStats.log

• app_stats_period| 桶大小（以秒為單位）。默認5分鐘。
  句法: app_stats_period <time in seconds>
  例子: app_stats_period 15

• app_stats_rollover_size| 文件大小，這將導致文件翻轉。預設20 MB。
  句法: app_stats_rollover_size <file size in bytes>
  例子: app_stats_rollover_size 2000000

• app_stats_rollover_time| 自文件創建以來的時間，這將導致翻轉。默認為1天。
  句法: app_stats_rollover_time <time in seconds>
  例子: app_stats_rollover_time 3600

• memcap| AppId內部結構使用的內存的上限。默認值32MB。
  句法:memcap <memory in bytes>
  例子:memcap 100000000

• dump_ports>| 僅顯示端口探測器，并在活動探測器上顯示信息。用于故障排除。
  句法: dump_ports <“yes” |“no”>
  例子:dump_ports“yes”

• 調試| 在某些舊的檢測器中用于調試。
  句法: debug
  例子:debug

默認配置: preprocessor appid

2.2.24.3 規則選項

AppId預處理器將添加1個新規則選項，如下所示：

appid

必須啟用預處理器，此規則選項才能工作。

appid
規則選項允許用戶以簡單的方式自定義特定應用程序的規則。該選項最多可以包含10個應用程序名稱，用空格，制表符或逗號分隔。規則中的應用程序名稱是您將在appMapping.data文件的最后一欄中看到的名稱。如果規則中的appId之一與會話中的appId匹配，則該規則被視為匹配。對于客戶端數據包，會話中的payloadAppId與規則中的所有AppId匹配。之后，將miscAppId，clientAppId和serviceAppId匹配。由于警報事件包含一個AppId，因此僅報告第一個匹配項。如果沒有appId選項的規則匹配，則將報告最特定的appId（按有效負載，雜項，客戶端，服務器的順序）。服務器端數據包遵循相同的邏輯，但有一個例外。更改匹配順序以使serviceAppId高于clientAppId。

句法:

appid：<list of application names>

例子:

    appid: http;
    appid: ftp, ftp-data;
    appid: cnn.com, zappos;

2.2.24.4 應用規則事件

定義了一個新的事件類型，以便僅以Unified2格式在Snort Alerts中記錄應用程序名稱。這些事件僅包含一個應用程序名稱。可以使用’appid_event_types關鍵字為統一2輸出啟用事件。

例如，以下配置將使用應用程序名稱將警報記錄在my.alert文件中。

 output alert\_unified2: filename my.alert, appid\_event\_types

u2spewfoo，u2openappid，u2streamer工具可用于以新格式打印警報。每個事件將在事件結束時顯示其他應用程序名稱。

例子:

#> u2spewfoo outputs the following event format
(Event)
        sensor id: 0    event id: 6     event second: 1292962302        event microsecond: 227323
        sig id: 18763   gen id: 1       revision: 4      classification: 0
        priority: 0     ip source: 98.27.88.56  ip destination: 10.4.10.79
        src port: 80    dest port: 54767        protocol: 6     impact\_flag: 0  blocked: 0
        mpls label: 0   vland id: 0     policy id: 0    appid: zappos

2.2.24.5 應用使用統計

AppId預處理程序以統一2格式的snort日志目錄定期打印應用程序網絡使用情況。文件名，統計信息的時間間隔和文件翻轉由appId預處理程序配置控制。u2spewfoo，u2openappid，u2streamer工具可用于打印這些文件的內容。u2openappid工具的示例輸出如下：

 statTime =“ 1292962290”，appName =“ firefox”，txBytes =“ 9395”，rxBytes =“ 77021”
 statTime =“ 1292962290”，appName =“ google \ _analytic”，txBytes =“ 2024”，rxBytes =“ 928”   statTime =“ 1292962290”，appName =“ http”，txBytes =“ 28954”，rxBytes =“ 238000”
 statTime =“ 1292962290”，appName =“ zappos”，txBytes =“ 26930”，rxBytes =“ 237072”

2.2.24.6 打開檢測器軟件包（ODP）安裝

Snort團隊的應用程序檢測器將以單獨的包裝（稱為“ Open Detector Package”）交付。ODP是一個包含以下工件的軟件包：

1. Lua語言的應用程序檢測器。
2. YAML格式的元數據中的端口檢測器，僅是端口應用程序檢測器。
3. 包含應用程序元數據的appMapping.data文件。此文件不應被修改。第一列包含應用程序標識符，第二列包含應用程序名稱。其他列包含內部信息。
4. Lua庫文件DetectorCommon.lua，flowTrackerModule.lua和hostServiceTrackerModule.lua

用戶可以在其選擇的任何目錄中安裝ODP軟件包，并在appId預處理程序配置的app_detector_dir選項中配置此目錄。安裝ODP不會修改用戶創建的檢測器所在的任何名為custom的子目錄。

安裝后，ODP將創建以下子目錄：

    odp/port    //Cisco port-only detectors
    odp/lua     //Cisco Lua detectors
    odp/libs    //Cisco Lua modules

2.2.24.7 用戶創建的應用程序檢測器

用戶可以通過使用Lua語言對檢測器進行編碼來創建新的應用程序。用戶還可以將Snort團隊提供的檢測器復制到自定義子目錄中，并自定義檢測器。文檔將發布在Snort網站上，其中包含API使用的詳細信息。

用戶必須通過在ODP安裝目錄下創建以下目錄結構來組織其Lua檢測器和庫。

    custom/port    //port-only detectors
    custom/lua     //Lua detectors
    custom/libs    //Lua modules