sfportscan
此模組由sourcefire開發,被設計用來偵測第一階段的網路攻擊:Reconnaissance(偵察)
在reconnaissance階段,攻擊者要決定目標的網路協定及服務是什麼類型的,所以會使用傳統的portscan技術,該階段是假設攻擊者尚未知道目標的網路協定及服務是什麼類型,若攻擊者已經知道則該階段是不必要的
因為攻擊者沒有目標主機的相關資訊,所以scan時送過去的訊息大部份都不會有回應,也就是服務的port都是在關閉狀態,
在一般正常的網路通訊中,無回應是罕見的,更罕見的是多個無回應同時發生在一個時間點附近
我們偵測portscan的主要目標就是要偵測和追蹤那些罕見的事件
目前最常被使用的portscan工具是nmap,它包括許多掃描技術,而sfportscan被設計用來偵測各種nmap能產生的掃描
sfportscan根據nmap scans類型分為以下3種
TCP Portscan
UDP Portscan
IP Portscan
這3種都是傳統的1對1掃描,1台主機掃描另一台主機的多個port,而大部份的port都會沒有回應,因為大多數主機有提供的服務相對較少
sfportscan也可根據decoy portscans類型分為以下3種
TCP Decoy Portscan
UDP Decoy Portscan
IP Decoy Portscan
攻擊者將自己的來源位置混合在多個假的來源位置對目標發動掃描,這種策略可以幫助隱藏攻擊者的真實位置
sfportscan可根據distributed portscans類型分為以下3種
TCP Distributed Portscan
UDP Distributed Portscan
IP Distributed Portscan
多台主機對另一台主機掃描,這用來欺騙ids和混淆指令及控制主機
無回應的查詢被分散在被掃描的主機中,所以我們透過被掃描的主機追蹤此類型的掃描
sfportscan根據portsweeps類型分為以下4種
TCP Portsweep
UDP Portsweep
IP Portsweep
ICMP Portsweep
一台主機掃描多台主機的單一port,通常發生在一個新的漏洞出現,然後攻擊者正在尋找特定的服務
ps:
The characteristics of a portsweep scan may not result in many negative responses
例如,攻擊者針對web farm的port 80發動portsweep,我們極可能只看到有回應的查詢
sfportscan能根據以下的filtered portscans and portsweeps分類
TCP Filtered Portscan
UDP Filtered Portscan
IP Filtered Portscan
TCP Filtered Decoy Portscan
UDP Filtered Decoy Portscan
IP Filtered Decoy Portscan
TCP Filtered Portsweep
UDP Filtered Portsweep
IP Filtered Portsweep
ICMP Filtered Portsweep
TCP Filtered Distributed Portscan
UDP Filtered Distributed Portscan
IP Filtered Distributed Portscan
filter表示沒有network errors(ICMP unreachables,TCP RSTs)或從關閉的port回應.
It’s also a good indicator of whether the alert is just a very active legitimate host.
像是nat這類Active hosts能觸發這些警報,因為它們在非常短的時間內會送出很多連結嘗試
在遠端主機接受任何訊息之前,filter可能就會警報
在time window(more on windows below)週期中,sfportscan對每對有問題的主機中只能產生一個警報.
在TCP scan警報中,sfportscan也將列出被掃描的任何open ports
然而在tcp sweep警報中,在警報被觸發後,sfportscan將只追蹤open ports,
雖然open port事件不是個別的警報,but tags based on the orginal scan alert
…………………………………………………………………………………………………………………………….
sfPortscan Configuration
sfportscan需使用到stream5 preprocessor,它可以指出像是udp,icmp無連結協定的portscan方向,
preprocessor sfportscan:
可用的參數如下
proto < protocol > 可用的值有TCP,UDP,ip_proto,IGMP,ALL
scan type < scan type>可用的值有portscan,portsweep,decoy portscan,distributed portscan,all
sense level < level>可用的值有low,medium,high
low
產生警報條件,1從目標主機傳送錯誤封包,2和自然的錯誤回應,
該設定很少false postives,,因為缺乏錯誤回應,該設定不會產生Filtered Scan警報,
這設定是基於60秒的靜態time window,然後重設這window
medium
會追蹤連接數量,且會產生Filtered Scan警報,
該設定在active hosts(NATs,proxies,DNS caches,…等)可能會false postives,所以使用者可能需要好好佈署及調整directive(指令)
high
不斷追蹤網路上的主機並根據主機的portscan統計做評估,
因為該設定會持續性監控所以可捕捉slow scan,但該設定對active hosts十分敏感,使用者需要設定好sfportscan是無庸置疑的
watch ip < ip1|ip2/cidr[[port|port2-port3]]> 指定要被偵測的ip及port,若要設定多個ip則以comma做分隔,若有設定ignore_之類的參數則會被忽略
ignore scanners < ip1|ip2/cidr[[port|port2-port3]]> 忽略來源的掃描警報
ignore scanned < ip1|ip2/cidr[[port|port2-port3]]> 忽略目地的掃描警報
logfile < file> 輸出logfile到指定的地方,若使用相對位置,則該檔案會在Snort config目錄
include midstream 透過stream5讀取sessions picked up in midstream,但在負擔大且丟包率高的網路下很容易產生假警報,預設關閉
detect ack scans 透過stream模組讀取sessions picked up in midstream,偵測ack scan必備選項,但在負擔大且丟包率高的網路下很容易產生假警報,預設關閉
disabled 關閉該preprocessor,預設值
預設組態
preprocessor sfportscan: proto { all }
memcap { 10000000 }
sense_level { low }
………………………………………………………………………………………………………………………………
sfPortscan Alert Output
Unified Output
為了得到所有記錄在警報中的portscan資訊,snort建立了一種pseudo-packet,並使用部份的payload儲存額外的portscan資訊,包括priority count,connection count,IP count,port count,IP range,port range.
packet大致如下
Src/Dst MAC Addr == MACDAD
IP Protocol == 255
IP TTL == 0
除此之外,packet看起來像IP封包部分導致portscan警報被產生,這包含任何ip option,…等
payload和封包的payload大小在額外的portscan資訊所記錄的長度是相等的,大小約在100-200bytes
open port警報不同於其他的portscan警報,因為open port警報利用tagged packet output system(標籤封包輸出系統)
這意指若輸出系統沒有發行可使用的tagged packet,則使用者將無法看到open port警報
open port資訊被儲存在ip payload並保留已open的port
sfportscan警報輸出被設計to work with unified packet logging,所以很有可能被擴充為snort GUI,並使用以上封包特徵顯示portscan警報和ip payload內的額外資訊
Log File Output
格式大致如下
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
假如目標有open port,一個或多個額外添加的封包將被附加,如下
Time: 09/08-15:07:31.603881
event_ref: 2
192.168.169.3 -> 192.168.169.5 (portscan) Open Port
Open Port: 38458
各欄位說明如下
event_id/event_ref
和相對應的open port tagged packet警報連結
Priority Count
持續追蹤bad responses(reset,unreachables),數值越高表示己接收的bad responses越高
Connection Count
列出有多少活動中的連線在主機(src or dst)
對已連結為基礎的協定而言是很精確的,and is more of an estimate for others,portscan是否被過濾在此決定,較高的connection count和較低的priority count表示被過濾(沒有收到來自目標的回應)
IP Count
持續追蹤連接到主機的最後一個ip,若下一個ip不同則在累加,對於1對1掃描該數值很低,對於active hosts該數量會很高,而且1對1掃描會很像distributed scan
Scanned/Scanner IP Range
這欄位會因警報類型做改變,Portsweep(one-to-many)掃描顯示被掃ip範圍,而Portscans(one-to-one)則顯示掃描者ip範圍
Port Count
持續追蹤連接到主機的最後一個port,若下一個port不同則在累加,我們使用count(along with IP Count)決定1對1portscan和1對1decoys的差異性
……………………………………………………………………………………………………………………….
Tuning sfPortscan
偵測portscan最重要的方向是根據你的網路調整偵測引擎,以下是一些調整的建議
善用watch ip,ignore scanners,ignore scanned的選項
設定這些選項是重要的,
watch ip選項是容易理解的,
分析者應設定要阻擋的網段和想看的ip
若沒有定義watch ip,snort會看全部的網路流量
ignore scanners和ignore scanned選項會忽略掉網路上活躍的合法主機,
通常都是NAT IPs,DNS cache servers,syslog servers,nfs servers.
對於這類的主機,一但調整好該選項所設定的ip,sfportscan可能就不會誤報了.
決定在於那些主機產生的警報類型,分析者將知道那一個要忽略
若主機正產生portsweep事件,那就加到ignore scanners選項中
若主機正產生portscan警報,那就加到ignore scanned選項中
filter scan警報更容易誤報
當判斷為誤報時,警報類型是非常重要的
sfportscan大部份可能產生的誤判都是filter scan警報類型
因此,有很多可疑的filter portscans
很多時候就是在產生問題的期間指出那是活躍的主機
假如那些主機不斷的產生那類型的警報,就加入ignore_scanners選項或將sense level設成low
利用priority count,Connection Count,IP Count,Port Count,IP Range,Port Range判斷誤報
在未來,判斷portscan的範圍和可信度時,portscan警報詳細度很重要.
我們希望自動化大部份在分配範圍等級和可信度等級上的分析,但現在使用者必須手動做這些
判斷誤報最簡單的方法就是透過簡單的比率估計
以下是比率估計的清單和指出合法掃描及非誤報的相關值
Connection Count/IP Count
這比率指出每個ip的平均連線預估值,
在portscan時,這比率應該很高,越高越好
在portsweep時,這比率應該很低
Port Count/IP Count
這比率指出每個ip的平均port連線預估值
在portscan時,這比率應該很高,而且這表示被掃描的主機port被少數幾個ip連接
在portsweep時,這比率應該很低,而且表示掃描主機連接少數的port,但是多個主機
Connection Count/Port Count
這比率指出每個port的平均連線預估值
在portscan時,這比率應該很低,這說明每一個連線都是不同的port
在portsweep時,這比率應該很高,這說明有很多連線到同一個port
ps:
priority count不在以上清單的理由是,因為priority count已包含在connection count內,另外以上比較僅供參考
priority count在調整上扮演一個重要的角色,priority count越高表示portscan和portsweep越像是真的,除非這主機是防火牆
如果這些方法都失敗,就調低sense level
假如以上的調整都沒運作,或是分析者沒時間調整,那就調低sense level.
越高的sense level可以得到更好的保護,分析師也會發現portscan偵測引擊產生的警報很重要
低sense level只會產生以錯誤回應為基礎的警報
那些回應說明portscan和警報的產生是透過高精確的低sense level,而且很少調整
低sense level不會感應到filter scan,因為那樣更容易出現誤報
…………………………………………………………………………………………………………………………….
sfportscan alert type
相關說明可參考以上內容
122-1.TCP Portscan
122-2.TCP Decoy Portscan
122-3.TCP Portsweep
122-4.TCP Distributed Portscan
122-5.TCP Filtered Portscan
122-6.TCP Filtered Decoy Portscan
122-7.TCP Filtered Portsweep
122-8.TCP Filtered Distributed Portscan
122-9.IP Protocol Scan
122-10.IP Decoy Protocol Scan
122-11.IP Protocol Sweep
122-12.IP Distributed Protocol Scan
122-13.IP Filtered Protocol Scan
122-14.IP Filtered Decoy Protocol Scan
122-15.IP Filtered Protocol Sweep
122-16.IP Filtered Distributed Protocol Scan
122-17.UDP Portscan
122-18.UDP Decoy Portscan
122-19.UDP Portsweep
122-20.UDP Distributed Portscan
122-21.UDP Filtered Portscan
122-22.UDP Filtered Decoy Portscan
122-23.UDP Filtered Portsweep
122-24.UDP Filtered Distributed Portscan
122-25.ICMP Sweep
122-26.ICMP Filtered Sweep
122-27.Open Port
更多資訊請參考http://www.snort.org/search/sid/122-1到27
資料參考http://manual.snort.org/