0x00 一條簡單的規則

---

alert tcp 202.110.8.1 any -> 122.111.90.8 80 (msg:”Web Access”; sid:1)

• alert：表示如果此條規則被觸發則告警
• tcp：協議型別
• ip地址：源/目的IP地址
• any/80：埠號
• ->：方向運算子，還有<>雙向。
• msg：在告警和包日誌中列印訊息
• sid：Snort規則id …

這條規則看字面意思就很容易理解。Snort就是利用規則來匹配資料包進行實時流量分析，網路資料包記錄的網路入侵檢測/防禦系統(Network Intrusion Detection/Prevention System),也就是NIDS/NIPS。

0x01 SNORT目錄結構

---

建議將Snort的目錄結構配置成如下：

/etc/snort
 ├── barnyard2.conf      barnyard2日誌分析工具配置檔案
 ├── snort.conf          snort配置檔案（關鍵）
 ├── threshold.conf      事件過濾配置檔案
 ├── classification.config 規則分類配置檔案(classtype)
 ├── reference.config      外部參考配置檔案(reference)
 ├── gen-msg.map      generate id 和 msg 對應關係map
 ├── sid-msg.map      snort id 和 msg對應關係map
 ├── unicode.map      前處理器http_inspect編碼翻譯檔案
 ├── preproc_rules       前處理器及解碼器規則集
 │ ├── decoder.rules  
 │ ├── preprocessor.rules
 │ └── sensitive-data.rules
 ├── rules               Snort規則集（關鍵）
 │  ├── web-iis.rules 
 │  ├── web-php.rules
 More…
 ├── so_rules            Share Object規則集
 │  ├── browser-ie.rules
 │  ├── browser-other.rules    
 More…

0x02 snort.conf配置檔案

---

此檔案是配置snort的核心檔案，包括以下幾部分：
  1) Set the network variables.  設定各類網路地址，規則中易於使用
  2) Configure the decoder      設定解碼器
  3) Configure the base detection engine  設定基礎檢測引擎
  4) Configure dynamic loaded libraries   設定動態連結庫
  5) Configure preprocessors     設定前處理器
  6) Configure output plugins    設定輸出外掛
  7) Customize your rule set     設定自定義規則
  8) Customize preprocessor and decoder rule set設定預處理、解碼器規則
  9) Customize shared object rule set 設定共享物件規則集

0x03 SNORT體系結構

---

• 資料包嗅探模組，主要負責監聽網路資料包，並根據TCP/IP協議解析資料包。
• 預處理模組，1.包重組前處理器，它的作用是為了防止攻擊資訊被拆分到多個包中而 逃避了Snort的檢測；2.協議編碼前處理器，它的功能是把資料包協議解碼成一個統一的格式，再傳送給檢測模組；3.協議異常檢測預處器。
• 檢測引擎模組，當前處理器把資料包送過來後，檢測引擎將這些資料包與三維連結串列形式的檢測規則進行匹配，一旦發現資料包中的內容和某條規則相匹配，就通知報警模組。
• 報警/日誌模組，檢測引擎將資料包傳送給報警模組後，報警模組會根據規則定義（alert，log..）對其進行不同的處理（資料庫，日誌）。

下面分別詳細介紹這四大模組。

0x04 解碼模組與預處理模組

---

4.1 模組介紹

由於解碼模組和預處理模組功能類似，都是在規則檢測引擎之前對資料包的處理，所以兩個模組一併介紹。 解碼模組主要是將從監控網路當中抓取的原始網路資料包，按照各個網路協議棧從下至上進行解碼，並將解碼資料儲存到各個對應的資料結構當中，最後交由預處理模組進行處理。

解碼後的資料包經過預處理之後才能被主探測引擎進行規則匹配。前處理器的主要用來應對一些IDS攻擊手段。其作用包括：

1)針對可疑行為檢查包或修改包，以便探測引擎能對其正確解釋。 2)負責對流量標準化，以便探測引擎能精確匹配特徵。

目前已知的IDS逃避技術主要有：

1)– 多型URL編碼； 2)– 多型shellcode； 3)– 會話分割； 4)– IP碎片；

Snort主要包含以下三類前處理器（舉例說明）：

1)包重組前處理器：

• frag3：IP分片重組和攻擊監測。
• stream：維持TCP流狀態，進行會話重組。

2)協議規範化前處理器：

• http_inspect：規範HTTP流。
• rpcDecode：規範RPC呼叫。

3)異常檢測前處理器：

• ARP spoof：檢測ARP欺騙。
• sfPortscan：檢測埠掃描。

4.2 模組配置

配置分兩個步驟，都是在snort.conf中配置。

1.snort.conf的2)和5)中配置解碼器或者預處理引數。

2.snort.conf的8)中啟用檢測規則。

4.2.1 解碼器配置舉例

1.配置解碼器

config disable_decode_alerts   關閉decode告警。
config enable_decode_oversized_alerts
      如果一個包（IP,UDP,TCP）長度長於length欄位，則告警。
# Stop generic decode events

格式為config docoder [option],使用#作為註釋

2.啟用解碼器檢測規則

include $PREPROC_RULE_PATH/decoder.rules

snort.conf檔案中使用include關鍵詞包含配置檔案和規則檔案。

3.在decoder.rules中我們找到了檢測IP長度異常的規則。

alert ( msg:"DECODE_IPV4_DGRAM_GT_IPHDR"; sid:6; gid:116; rev:1; metadata:rule-type decode;classtype:protocol-command-decode; )

4.2.2 前處理器http_insepect配置舉例

1.下面是http_inspect預設的配置

preprocessor http_inspect: global iis_unicode_map                            unicode.map 1252 compress_depth 65535 decompress_depth 65535
#unicode.map是http_inspect解碼unicode時的解碼檔案。
preprocessor http_inspect_server: server default \
http_methods { GET POST PUT SEARCH MKCOL ...} \
    ...  
    enable_cookie        #將http請求或響應中的cookie提取到快取，用於後面規則匹配。
    normalize javascript #對標籤中的js指令碼解碼。
    ...

2.啟用前處理器規則

#include $PREPROC_RULE_PATH/preprocessor.rules

下面是一條解碼器規則：

alert ( msg:"DECODE_TCP_INVALID_OFFSET"; sid:46; gid:116; rev:1; metadata:rule-type decode; reference:cve,2004-0816; classtype:bad-unknown; )

發現這條規則和之前看到的不一樣，它沒有源/目的IP，埠等資訊，說明這條規則是由解碼器自動觸發的，使用者不需要干預。 一般我們也不需要去修改解碼器或者前處理器的規則，只需要去snort.conf中新增、配置或者刪除外掛即可。

0x05檢測引擎模組

---

規則結構 alert tcp 202.110.8.1 any -> 122.111.90.8 80 (msg:”Web Access”; sid:1) |---||---||---||---||---||---||---||---||---||--規則頭---||---||---||---||---||---||---||---||--||---||---||---||-規則選項---||---||---||---||-|

5.1 規則頭

動作：

在snort中有五種動作：alert、log、pass、activate和dynamic.

  1)Alert：       生成一個告警，然後記錄（log）這個包。
  2)Log：         記錄這個包。
  3)Pass：        丟棄這個包。
  4)Activate： alert並且啟用另一條dynamic規則。
  5)Dynamic：保持空閒直到被一條activate規則啟用，被啟用後就作為一條log規則執行。

協議：

Snort當前可分析的協議有四種：TCP,UDP,ICMP和IP。將來可能會更多，例如：ARP、IGRP、GRE、OSPF、RIP、IPX等。

IP地址：

1)地址就是由直接的ip地址或一個CIDR塊組成的。也可以指定ip地址列表，一個ip地址列表由逗號分割的ip地址和CIDR塊組成，並且要放在方括號內 [,]。 2)否定運算子用!表示。 3)關鍵字“any”可以被用來定義任何地址。

例如：

alert tcp ![192.168.1.0/24,10.1.1.0/16] any -> 192.168.2.1 80(msg:”notice!”;content|xxxx|;)

方向運算子：

方向運算子->

表示規則所施加的流的方向。方向運算子左邊的ip地址和埠號被認為是流來自的源主機，方向運算子右邊的ip地址和埠資訊是目標主機，還有一個雙向運算子<>。

埠號：

1)埠號可以用幾種方法表示，包括any埠、靜態埠定義、範圍、以及透過否定運算子。 2)靜態埠定義表示一個單個埠號，例如111表示portmapper，23表示telnet，80表示http等等。 3)埠範圍用範圍運算子“:”表示.比如，80: , :1024 ,80:1024

5.2 規則選項

規則選項分為四大類：

1)General rule option 通用規則選項 2)Payload detection rule option 負載檢測規則選項 3)Non-Payload detection rule option 非負載檢測規則選項 4)Post detection rule option 後檢測規則選項

5.2.1 General rule option通用規則選項

sid

   snort id ,這個關鍵字被用來識別snort規則的唯一性（說的其實嚴禁，後面會有補充）。sid 的範圍是如下分配的：          

• <100 保留做將來使用
• 100-1000,000 包含在snort釋出包中
• >1000,000 作為本地規則使用

msg

      標示一個訊息，但是規則中的msg不起作用，sid和msg的對應關係查閱sid-msg.map。

sid-msg.map

格式：sid || msg

例子：384 || PROTOCOL-ICMP PING 在/etc/snort/rules/protocol-icmp.ruls中我們找到了這條規則： alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"PROTOCOL-ICMP PING"; icode:0; itype:8; metadata:ruleset community; classtype:misc-activity; sid:384; rev:8;)

此檔案作用是將sid與msg的一一對應，否則，在告警中會出現下圖中第一條的現象。

此檔案用於自定義規則中sid與msg的對應和在snort自有規則中自定義告警資訊。 上圖中Snort Alert[1:1000015:0]其中內容對應為Snort alert[gid:sid:rev]。這說明一個規則需要這三個因素才能確定,之前說只有sid唯一標示一條規則是不嚴謹的。

gid

 generate id，作用是為了說明這條規則是snort的哪部分觸發的。比如是由解碼器、前處理器還是Snort自有規則等。
 檢視/usr/local/share/doc/snort/generators檔案（此檔案不是配置檔案）：

rules_subsystem       1 # Snort Rules Engine
rpc_decode            106 # RPC Preprocessor(前處理器)
stream4               111 # Stream4 preprocessor（前處理器）
ftp                   125 # FTP decoder（解碼器）
...                   ...

decoder和preprocessor的gid就不一一列舉，可以看到Snort Rule Engine的gid為1，自定義規則和snort自有規則（也就是/etc/snort/rules目錄下的規則）gid預設是1。但是這裡我們獲知decoder和preprocessor也是有sid的。 舉例說明：

/etc/snort/rules/protocol-icmp.rules中的一條規則：

alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:“PROTOCOL-ICMP Traceroute”; icode:0; itype:30; metadata:ruleset community; classtype:misc-activity; sid:456; rev:8;)

gid預設為1

/etc/snort/preproc_rules/decoder.rules中的一條規則：

alert ( msg:"DECODE_IP6_EXCESS_EXT_HDR"; sid:456; gid:116; rev:1; metadata:rule-type decode; classtype:misc-activity; )

可以看到兩條規則的sid是相同的，所以還需要gid來區分。

gen-msg.map

這個檔案和sid-msg.map作用類似，在邏輯上應該是包含了sid-msg.map（sid-msg.map相當於預設gid為1）

格式：generatorid || alertid(sid) || MSG

例子：

1   || 1 || snort general alert
129 || 2 || stream5: Data on SYN packet
116 || 271 || snort_decoder: WARNING: IPv6 header claims to not be IPv6
116 || 456 || snort_decoder: WARNING: too many IPV6 extension headers #例子
...

拿gid中第二條規則舉例，如果此條規則被觸發，則會報snort_decoder: WARNING: too many IPV6 extension headers告警，而不是DECODE_IP6_EXCESS_EXT_HDR。所以規則中的msg僅僅起到標示作用，告警msg需要在sid-msg.map和gen-msg.map這兩個檔案中對應查詢。

rev

這個關鍵字是被用來識別規則修改的版本，需要和sid,gid配合使用。 這樣就介紹完了gid，sid，rev三個確定規則唯一的元素。

reference

外部攻擊參考，這個關鍵字允許規則包含一個外面的攻擊識別系統。這個外掛目前支援幾種特定的系統，這些外掛被輸出外掛用來提供一個關於產生報警的額外資訊的連線。

reference.config

格式：config reference: system URL

例子： config reference: cve http://cve.mitre.org/cgi-bin/cvename.cgi?name= 定義了一些外部安全網站的網址。比如規則中定義reference: cve,1001,那麼就像在上面的網址後面新增了1001，http://cve.mitre.org/cgi-bin/cvename.cgi?name=1001，最後點選告警中的[cve]，就會跳轉到相應的網址。注：reference也需要在sid-msg.map中與sid對應，否則不起作用，類比msg。

classtype

規則類別標識。這個關鍵字把報警分成不同的攻擊類。透過使用這個關鍵字和使用優先順序，使用者可以指定規則類中每個型別所具有的優先順序。

priority

設定classtype的優先順序。classtype和priority是配合使用的，classification.config檔案將其聯絡起來。

classification.config

格式： config classification:shortname,short description,priority

例子： config classification: attempted-admin,Attempted Administrator Privilege Gain,1 寫在此檔案中的都是預設值，priority關鍵詞可以在規則中重寫優先順序。 例子： alert tcp any any -> any 80 (msg:"EXPLOIT ntpdx overflow"; dsize:>128; classtype:attempted-admin; priority:10 );

metadata

可以在規則中新增自定義的資訊，一般以鍵值對的形式出現。

通用規則選項只是對一條規則進行標示，分類等操作，並沒有進行實際的過濾檢測。

5.2.2 Payload Detection Rule Options 負載檢測規則選項

content

content是Snort重要的關鍵詞之一。它規定在資料包的負載中搜尋指定的樣式。它的選項資料可以包含混合的文字和二進位制資料。二進位制資料一般包含在管道符號中“|”，表示為位元組碼（bytecode），也就是將二進位制資料的十六進位制形式。

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

content還有很多修飾符：

Nocase            content字串大小寫不敏感
rawbytes          直接匹配原始資料包
Depth             匹配的深度
Offset            開始匹配的偏移量
Distance          兩次content匹配的間距
Within            兩次content匹配之間至多的間距  
http_cookie       匹配cookie
http_raw_cookie   匹配未經normalize的cookie
http_header       匹配header
http_raw_header   匹配未經normalize的header
http_method       匹配method
http_url          匹配url
http_raw_url      匹配日在未經normalize的url中
http_stat_code    匹配狀態碼中匹配
http_stat_msg     匹配狀態資訊
http_encode       匹配編碼格式

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

pcre

允許使用者使用與PERL語言相相容的正規表示式。

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

例子：
alert tcp any any -> any 80 (content:“/foo.php?id="; pcre:"/\/foo.php?id=[0-9]{1,10}/iU";) 正則的細節查閱snort_manual。

protected_content

將content中的查詢內容使用hash演算法加密，保護規則的私密性。 protected_content:[!]"<content hash>", length:orig_len[, hash:md5|sha256|sha512];

rawbytes

忽略解碼器及前處理器的操作，直接匹配原始網路包。

上面只列舉出了一些常用的payload detection rule option，更多的關鍵詞查閱snort_manual。

5.2.3 Non-Payload Detection Rule Option非負載檢測規則選項

Fragoffset                IP 偏移量
Ttl                       IP 生存時間
Tos                       IP 服務型別
Id                        IP 標識
Ipopts                    IP 可選項
Fragbits                  IP 標誌
Dsize                     資料包負載量
Flags                     TCP flags
Seq                       TCP seq
Ack                       TCP ack
Window                    TCP window
Icmp_id                   ICMP ID

此類規則選項都是對資料包幀結構中特殊欄位的匹配。

5.2.4 Post-Detection Rule Option後檢測規則選項

Logto                     輸出日誌路徑
Session                   從TCP會話中獲取使用者資料
Resp                      透過傳送響應結束惡意的請求
React                     不僅僅記錄觸發規則的特定資料包
Tag                       不僅僅記錄觸發規則的特定資料包
Activates                 activate動作
Activates_by              dynamic動作
Count                     dynamic規則被觸發後可以匹配的包的數目
Replace                   替換content內容
Detection-filter          檢測過濾

5.3 檢測引擎模組配置

1.在/etc/rules目錄下的*.rules檔案中寫規則。 2.snort.conf 7)中include對應規則。

include $RULE_PATH/local.rules
#include $RULE_PATH/app-detect.rules
#include $RULE_PATH/attack-responses.rules
#include $RULE_PATH/backdoor.rules
#include $RULE_PATH/bad-traffic.rules
#include $RULE_PATH/blacklist.rules

0x06 Snort告警/日誌模組

---

6.1 輸出模組配置

snort.conf 6):Configure output plugins 設定日誌路徑 config logdir：/var/log/snort 設定輸出格式為unified2： output unified2: filename snort.log, limit 128

barnyard2.conf

barnyard2的作用是將unified2格式的資料存入資料庫 設定與snort日誌關聯 config waldo_file:/var/log/snort/barnyard.waldo 設定資料庫 output database: log, mysql, user=snort password=123456 dbname=snort host=localhost

6.2 資料庫

ER圖

schema

vseq：資料庫模式ID
ctime：資料庫建立時間

資訊表，和其他資料庫內容上沒有聯絡

sensor

sid：感測器代號
hostname：感測器所屬的使用者名稱稱
Interface：感測器對應的網路介面
filter：對應感測器的過濾原則
detail：表示感測器監測模式，記錄模式詳細程度的級別        
encoding：包含資料存在形式
last_cid： 對應每個sid即感測器捕獲告警的最後一個值

detail

0-fast快速檢測
1-full全面檢測

感測器sensor的檢測級別。

encoding

0- Hex
1- base64
2- asci

資料包中資料的存在形式。

event

sid：sensor id，感測器id。
cid；event id   事件id。sid和cid共同作為主碼，其中cid是在sid的基礎上進行排序的。每個sid對應自己的cid排序。
signature：對應signature表格中的sig_id選項，表明這條告警事件所屬的規則形式的告警對應哪一類rules。
timestamp：對應告警事件發生的系統時間。

最核心的一張表，告警的每一條資料都會儲存在event表中，一條event資料就代表一個包。

signature

sig_id： 總數代表發生告警種類的總數。是告警種類的主碼。唯一標識一條規則。
sig_name：告警名稱。對應每條alert語句的Msg。
sig_class_id：對應sig_class表格中的sig_class_id.代表告警種類的大類資訊。
sig_priority：告警的優先順序
sig_rev：版本號
sig_sid：snort id   
sig_gid：generate id 

儲存snort規則的一張表，可以看到sig_sid,sig_gid,sig_rev分別對應規則中的sid,gid,rev。注意規則中的snort id和資料庫中的 sensor id注意區分。

sig_reference

sig_id：對應的告警種類。
ref_id：對應reference表格中的主碼
ref_seq：參考序列號

提供報警種類資訊signature的參考資訊。將signature與reference聯絡起來的表格。

reference

Ref_id：主碼
Ref_system_id：對應reference_system表格
Ref_tag：規則中 cve,bugtraq 後面的引數

reference_system

ref_system_id：主碼
ref_system_name：reference system的名字，如cve，url等。

sig_class

sig_class_id：分類編號
sig_class_name：分類名稱

signature告警種類的分類資訊。

iphdr

tcphdr

udphdr

icmphdr

data

data_payload：資料包有效載荷

規則中協議為tcp時，data_payload中是tcp後面的內容

規則中協議為icmp時，data_payload中是icmp協議中的data欄位值

opt

IP和OPT的option。

參考文獻：

• [1] CentOS6.6下基於snort+barnyard2+base的入侵檢測系統的搭建
• 2 基於Snort的C_S模式的IDS的設計與應用_王會霞.caj
• [3] Snort 筆記1 - 3種模式簡介
• [4] Snort.conf 分析
• [5] Snort 入侵檢測系統簡介
• [6] Snort部署及埠掃描檢測試驗總結
• [7] Barnyard create_mysql
• [8] Snort mysql概述
• [9] Snort響應模組總結-實時監聽-資料庫分析
• [10] Snort資料表項含義及ER圖
• [11] 上文的中文翻譯
• [12] Snort rules概述
• [13] Snort安裝配置與NIDS規則編寫
• [14] Snort 筆記2 - 規則編寫
• [15] 撰寫一組SNORT規則防禦SQL隱碼攻擊
• [16] Snort規則中的邏輯關係
• [17] Snort_manual.pdf 官方文件中文翻譯
• [18] Snort sid-msg.map檔案概述
• [19] Snort classification.config檔案概述
• [20] Snort reference.config檔案概述