snort規則提取方法梳理

一. 概述

suricata是一款開源的流量檢測引擎,支持實時入侵檢測(IDS)、內聯入侵預防(IPS)、網絡安全監控(NSM)和離線pcap處理,經過編寫suricata配套的snort規則可以對實時的網絡流量進行威脅檢測,及時發現網絡流量中存在的威脅和風險。如下針對實施入侵檢測的snort規則編寫進行方法的梳理。html

二. 規則組成及經常使用字段說明

一條完整的suricata snort規則主要分爲三部分,動做(action)、規則頭(header)、規則可選項(options)。以下圖所示:java

image.png

紅色部分表示動做,綠色部分表示頭,藍色部分表示規則可選項。web

2.1.動做(action)

當snort規則命中流量中的關鍵數據是,須要執行的操做,主要有告警動做(alert)、丟棄動做(drop)。實時入侵檢測以威脅告警爲主,規則使用的是alert字段。正則表達式

image.png

2.2.規則頭(header)

主要定義匹配的網絡流量的協議、IP地址、端口、流量方向。api

2.2.1. 規則頭協議

image.png

支持的基礎協議爲:tcp、udp、icmp、ip。更加上層的協議爲:安全

http、ftp、tls (包括ssl)、smb、dns、dcerpc、ssh、smtp、imap、msn、modbus (默認關閉該協議的支持)、dnp3 (默認關閉該協議的支持)、enip (默認關閉該協議的支持)、nfs (默認關閉該協議的支持)、ikev2 (默認關閉該協議的支持)、krb5 (依賴rust語言環境)、ntp (依賴rust語言環境)、dhcp (依賴rust語言環境)。網絡

2.2.2. IP地址和方向

image.png

image.png

IP地址支持以常量、變量、範圍域、非運算符方式來定義匹配流量,參考:app

示例 解釋
!1.1.1.1 全部的IP地址除去1.1.1.1
![1.1.1.1, 1.1.1.2] 全部的IP地址除去1.1.1.1,1.1.1.2
$HOME_NET 在suricata.yaml配置文件中設置的局域網範圍,IP地址變量
[$EXTERNAL_NET, !$HOME_NET] 外部網絡變量 除去局域網變量
[10.0.0.0/24, !10.0.0.5] 全部10.0.0.0/24(10.0.0.1-10.0.0.255)網段的ip 除去10.0.0.5

"->" 表示流量的方向,流量流向箭頭指向的方向。less

"<>" 表示雙向流量均可以進行匹配。ssh

端口與IP地址書寫配套使用,支持常量,變量,任意端口的匹配,參考:

示例 解釋
[80, 81, 82] 匹配80,81,82中的任意端口
[80: 82] 匹配從80到82之間的任意端口
[1024: ] 匹配1024一直到65535的最大端口
!80 匹配全部端口除去80
[80:100,!99] 匹配80到100端口,除去99端口
[1:80,![2,4]] 匹配1到80端口,除去2到4端口
$HTTP_PORTS 匹配在suricata.yaml配置文件中設置$HTTP_PORTS對應的端口

2.3.規則可選項(options)

對於規則可選項部分(options)部分有如下經常使用字段。

2.3.1. sid

snort規則的編號,確保每條規則編號的惟一性

image.png

2.3.2. rev

規則的版本,默認使用1,若是規則有調整,能夠增長1

image.png

2.3.3. reference

規則相關信息,如參考連接等

image.png

2.3.4. classtype

規則分類,在classification.config中進行配置使用,確保classification.config存在對應規則類別,不然規則將沒法生效。

classification.config內容配置示例:

config classification: web-application-attack,Web Application Attack,1config classification: not-suspicious,Not Suspicious Traffic,3

2.3.5. flow

數據流狀態,從服務端到客戶端,經常使用值以下:

to_client

流量數據從服務端到客戶端

to_server

流量數據從客戶端到服務端

from_client

流量數據從客戶端來 (與to_server效果相同).

from_server

流量數據從服務端來 (與to_client效果相同).

established

匹配已經創建鏈接的流量數據,對於tcp協議,爲三次握手以後的流量數據,對於udp協議,爲兩端都存在數據傳輸以後的流量數據.

not_established

匹配未創建鏈接的流量數據,該值能夠用戶檢測端口掃描行爲,端口掃描存在大量的未開放端口,所以都不能正常創建鏈接.

stateless

匹配已經創建爲爲創建鏈接的流量數據,這個應該是用來約束流數據或者報文數據協議的,通常指tcp/udp協議.

2.3.6. target

攻擊目標,可選擇值,src_ip|dest_ip,若是被攻擊者是源ip,則target:src_ip,默認被攻擊者是目的ip

2.3.7. msg

image.png

規則信息說明,能夠在規則中豐富對規則的說明描述。例如,某cve編號對應漏洞的檢測規則,某個木馬家族名稱對應的上線包等

2.3.8. content

image.png

須要匹配的網絡流量。支持16進制及明文字符串匹配,使用示例:

content:"a|0D|bc";

content:"|61 0D 62 63|";

content:"a|0D|b|63|";

默認content匹配的內容爲字符串敏感,

image.png

2.3.9. nocase

nocase與content配套使用,申明content大小寫字符串不敏感,使用示例:

content: "abc"; nocase;

image.png

2.3.10. offset

匹配網絡流量的偏移位置。偏移位置起始位置爲標準協議頭以後的數據載荷payload,使用示例:

content:"def"; offset:3; depth:3;

image.png

2.3.11. depth

匹配網絡流量的長度,通常與offset字段搭配使用,使用示例:

image.png

2.3.12. distance

與content配套使用,本次匹配內容與上次匹配payload內容的間距,同時確保不一樣的content匹配內容存在匹配的順序,distance生效的content爲距離distance最近的左側content。舉例:

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

image.png

image.png

2.3.13. pcre

正則表達式匹配,遵循標準正則表達式的書寫方法,此處不作展開。相關連接。https://redmine.openinfosecfo...
示例:

pcre:"/<regex>/opts";

image.png

/i表示正則表達式字符串大小寫不敏感。

2.3.14. dsize

匹配的通訊流量payload大小。示例:

dsize:>268; payload大於268 字節

dsize:<268;  payload小於268 字節

dsize:268;   payload等於268 字節

dsize:200<>268;  payload在200字節和268字節之間

image.png

三. 經常使用snort威脅檢測規則示例分析

當拿到威脅流量pcap包後,要提取snort規則,首先須要分析通訊包的具體內容,從中提取固定的能夠做爲通訊特徵的標識。如下將選取兩種場景進行pcap通訊包的分析與特徵規則提取。

3.1.木馬通訊上線包

3.1.1. wireshark數據流的跟蹤

使用Wireshark流量分析工具打開離線pcap包,

image.png

若是木馬使用TCP協議進行通訊,通常上線包的會出如今TCP 三次握手以後,所以能夠對TCP三次握手以後的數據包進行查看和分析,要獲取整個木馬通訊的數據流可使用WireShark的數據流跟蹤功能,以下圖所示:

image.png

使用追蹤功能後能夠獲得和本次上線通訊鏈接有關的全部數據包數據,以下圖所示:

image.png

3.1.2. payload載荷特徵分析

使用數據流追蹤獲得了可讀的字符串流數據,紅色數據表示socket客戶端向服務端發送的數據,藍色數據表示socket服務端向客戶端的返回數據。經過對字符串流數據的觀察,socket客戶端也就是木馬程序像服務端上傳了操做系統、CPU性能等計算機配置數據,這個是典型的獲取計算機配置並進行上傳的木立刻線行爲。下方重複出現的信息,疑似木馬的向控制端發送的心跳包。可使用WireShark查看每一個通訊包的大小以及服務端的端口以下圖所示:

image.png

image.png

3.1.3. snort通訊特徵提取分析

image.png

alert:將該規則定義爲發生告警動做的規則。

tcp:經過抓包分析,木馬通訊屬於tcp協議。

any(ip):客戶端爲任意ip。(*若是重點監測內網木立刻線,能夠將any換成,$HOME_NET,縮小匹配範圍、控制精度有利於下降規則的誤報,同時要結合snort規則的使用場景,若是snort規則檢測的目標是蜜罐服務,suricata引擎(實時入侵檢測功能)部署在蜜罐系統處,非大流量出口則可適當放寬規則擴大檢出範圍,若是位於大流量而且存在大量白流量的流量口,則須要更加精確的控制規則)。

any(port):客戶端爲任意端口

->:網絡數據流向。

any(ip):服務端爲任意ip。經過分析獲得的服務端IP和端口能夠做爲C2 IOC情報,本次分析的PCAP包爲生成器生成,C2端屬於演練環境IP,不作IOC提取。

any(port):服務端爲任意端口,木馬控制端的端口同家族存在一些類似性,在大流量的環境下,能夠控制木馬控制端端口的精度,採用精確的木馬控制端端口,例如:48080,若是指定某些經常使用的高位端口範圍,例如:[40000:60000]

msg:規則相關說明及附件信息木馬家族信息等,經過病毒檢測引擎已經明確產生該通訊包的家族爲Dofloo家族。

content:"|56 45 52 53 4F 4E 45 58 3A 4C 69 6E 75 78|";  "VERSONEX"的16進製表達方式。

offset:0; 偏移爲0,從載荷payload處開始匹配

depth:14; 匹配深度爲14個字節

content:"|4D 48 7A 7C|"; "MHz|"的16進製表達方式"

pcre: "/MHz|[0-9]{1,}MB|[0-9]{1,}MB|Hacker/i"; 正則表達是匹配可變的數字配置,配置單位爲固定值保持不變,Hacker爲固定值保持不變,大小寫不明感

distance:0;  配置相關匹配內容的順序出如今 VERSIONEX以後

dsize: < 1025;  載荷payload的大小1025個字節

sid:10017115; 規則id

flow:established,to_server; 流量方向爲socket客戶端到服務端,而且匹配已經創建鏈接的流量。

target: src_ip; 因爲木立刻線包是被控制的受害機器發出的,所以受害者是是源ip

3.2.漏洞規則REC攻擊包

3.2.1. wireshark數據流的跟蹤

使用Wireshark流量分析工具打開離線pcap包,

image.png

因爲該漏洞爲HTTP請求,所以可進行HTTP的數據流跟蹤

image.png

點擊後獲得HTTP請求相關數據流數據

image.png

3.2.2. payload載荷特徵分析

若是流量數據的漏洞是已知漏洞,能夠經過網上發佈的一些漏洞分析和復現文章瞭解漏洞利用的原理,有利於提取漏洞利用的關鍵流量特徵。該漏洞利用對應的CVE編號爲CVE-2015-1427,對應的分析文章連接:

https://jordan-wright.com/blo...

https://www.secpulse.com/arch...

漏洞原理是es9200服務對應的api腳本查詢模塊,因爲搜索引擎支持使用腳本代碼(MVEL),做爲表達式進行數據操做,攻擊者能夠經過MVEL構造執行任意java代碼。具體Exp以下:

image.png

提取關鍵要素:

1.es 9200端口服務

2.http api

3.腳本查詢模塊

4.白名單中的類獲取Class對象

5.java Runtime exec執行,exec執行

經過上述要素提取snort特徵。

3.2.3. snort通訊特徵提取分析

image.png

alert:將該規則定義爲發生告警動做的規則。

tcp:經過抓包分析,木馬通訊屬於tcp協議,也能夠寫成http協議,經過snort規則編寫和使用suricata引擎檢測,保持其餘條件不變,存在tcp協議可以檢出,http不能檢出的狀況,視具體狀況而定。

any(ip):客戶端爲任意ip。(*若是重點監測內網木立刻線,能夠將any換成,$HOME_NET,縮小匹配範圍、控制精度有利於下降規則的誤報,同時要結合snort規則的使用場景,若是snort規則檢測的目標是蜜罐服務,suricata引擎(實時入侵檢測功能)部署在蜜罐系統處,非大流量出口則可適當放寬規則擴大檢出範圍,若是位於大流量而且存在大量白流量的流量口,則須要更加精確的控制規則)。

any(port):客戶端爲任意端口

->:網絡數據流向。

any(ip):服務端爲任意ip。經過分析獲得的服務端IP和端口能夠做爲C2 IOC情報,本次分析的PCAP包爲生成器生成,C2端屬於演練環境IP,不作IOC提取。

any(port):9200 es api默認的端口爲9200。通常編寫漏洞規則填寫默認端口,從以往經驗來看,公網的漏洞攻擊和漏洞掃描也只針對默認端口進行漏洞掃描。

msg:規則相關說明及附加信息CVE編號漏洞描述信息等,經過相關分析已經明確該漏洞對應的CVE編號爲CVE-2015-1427。

content:"POST";  http的請求方式爲POST請求

offset:0;   載荷payload爲偏移爲0,http請求的開始幾個字節爲請求方式。

depth:5;   匹配深度爲5確保經常使用的web請求方式可以被匹配到。

content:"/_search";   匹配查詢的api uri

distance:0; 確保本次匹配的順序爲上一次匹配的內容以後

content:"script_fields";   匹配腳本相關字符串

distance:0; 確保本次匹配的順序爲上一次匹配的內容以後

pcre:"/class.forName.java.lang.Runtime..getRuntime().exec/i";  匹配白名單類中的forName, .表示使用符號本來的字符表示,不容許正則表達式轉義. 不然.在正則表達是表示匹配任意單個字符。其餘表示引用java中的Runtime而且執行

sid:130000030; 規則id

flow:established,to_server; 流量方向爲socket客戶端到服務端,而且匹配已經創建鏈接的流量。

相關文章
相關標籤/搜索