基于OSSIM平臺的多點采集網絡報文分析實戰

本文為大家介紹分布式OSSIM環境中，利用OSSIM系統中一種基于Web的數據包分析工具tshark。結合分布式OSSIM部署特點實現遠程多點采集數據包進行分析的實例。

Wireshark是一種網絡數據包分析軟件，它能在圖形化界面中抓取網絡封包，并顯示出詳細的數據包信息，網絡日常運維中的數據包分析利器，而tshark則是它的命令行版本。

我們在復雜網絡環境中采用tcpdump或wirshark抓包分析網絡故障，往往不是一個工程師能搞定的。很多情況下需要多人配合，徹底解決故障，非常不方便。例如要想以每秒間隔，統計 IP 地址 192.168.120.78 的封包、字節數量，就要輸入一串的的命令。

我們既需要命令行功能強大，還需要友好的交互界面，下面介紹的OSSIM將它集成進來之后，并用Python語言對其功能擴展，形成了一套基于Web模式多點（多Sensor）網絡分析利器。下面我們看看它是如何使用的吧。

1.分布式OSSIM環境

為了實現多點采集我們必須先將分布式OSSIM系統部署完成。每個傳感器和OSSIM Server之間通訊正常。各個傳感器所連接的均為相應交換機的SPAN口。在Web UI界面中操作路徑為Environment→Traffic Capture，界面如下圖所示。

操作方法非常簡單，選擇傳感器，輸入源地址和目標地址，然后點擊捕捉按鈕即可。應用該工具之前，需要操作者對最基礎的TCP、UDP、IP協議、ICMP協議掌握，還需熟悉HTTP、DHCP、DNS、FTP等常見應用層協議。

注意，在設置（settings）選項下方源地址和目標地址均為可選項。抓包時可以不必輸入，除非確切知道要捕獲的機器之間通訊。

在分布式OSSIM系統中，在分析遠程某個網段的數據包，由受控網段內的Sensor抓包，存儲在Sensor端/var/ossim/traffic/目錄下，命名為netscan_admin_IP.pcap，前提是這臺Sensor的/var目錄剩余空間大于5GB。

2.數據包設定

在設定數據包時，可以在Sensor下拉菜單中選擇需要監控網段的傳感器，選定網絡接口，以及捕包時間（10s~180s，時間一到自動停止捕獲）選擇源地址、目標地址，設定過濾選項（Raw Filter）以及設定每個捕獲數據包的大小等幾個步驟。

Raw filter可設置過濾協議例如過濾TCP、IP、UDP等協議，其可能的值為tcp、upd、ip、icmp、arp、rarp等，如果不填寫，則代表所有協議。在過濾條件的功能上不及wireshark豐富，在過濾的使用上不及第2章介紹的SIEM控制臺的過濾選項豐富，很多過濾條件需要手工輸入，另外填寫在Raw filter后面的一定是協議名稱的小寫字母。捕捉到數據包以后下面開始查看細節，如下圖所示。

最上方顯示捕獲數據包的開始時間結束時間和持續時間，再往下的主窗口上有三個面板，分別是包列表，包細節和包字節3部分

（1）包列表。最上面的面板顯示了當前捕獲文件中的所有數據包，包括了數據包序號（NO.）、數據包捕獲的相對時間（Time）、源地址（Source）、目的地址（Destination）、協議（Protocol）、數據包長度（Length）以及概況信息等。為了便于觀察，對于選中的包系統會用綠色高亮顯示出來。

（2）包細節。中間面板顯示了一個數據包中的內容，并且可以通過展開或者收縮來顯示這個數據包中所捕獲到的全部信息。

（3）包字節。最下面的面板可能是比較讓人頭痛的了，因為它顯示了一個數據包的真實面目，如果用過16進制編輯的就明白，下圖中左邊方框內顯示的是偏移量，中間顯示的是16進制。右邊方框顯示的是中間內容的可顯示字符。

3.故障實例分析

下面我們看看通過分布式OSSIM部署的解決方法，公司總部C部署了一臺高性能OSSIM服務器，在異地分公司A機房和B機房分別部署Sensor，它們通過VPN和Ossim Server連接。異地機房的Sensor分別連入交換機的SPAN口，當工作需要時，能夠實時抓取網絡數據。

當A機房內服務器出現故障，需要總部運維人員支持時，他們可以連接到OSSIM的Web UI界面,通過Traffic capture并選擇對應的Sensor,然后開始抓包，并進行后續分析，這樣部署大大提高了遠程機房之間數據包分析的效率。對于抓包存放位置是操作者必須了解的內容，系統抓的pcap數據包存放在/var/ossim/traffic/目錄。

4.編寫表達式

我們在使用tcpdump或者wireshark一般都會編寫表達式以便過濾出想要的數據包。在這里也是一樣，在這里的表達式跟wireshark稍有不同，下面列出常用的幾種方式：

①tcpdst port 22：顯示目的TCP端口為22的數據包。

②ipsrc host 192.168.150.10：顯示來源IP地址為192.168.150.10的數據包。

③host 192.168.150.10：顯示目的或來源IP地址為192.168.150.10的數據包。

④srcport range3000~5500 顯示來源為UDP或TCP，并且端口號在3000至5500范圍內的數據包。

首先說幾個常用的關鍵字，“eq”和“==”等同，可以使用“and”表示并且，“or”表示或。“!" 和 "not”則表示取反。對IP地址的過濾其中有3種情況：

（1）對源地址為192.168.11.121的包的過濾，即抓取源地址滿足要求的包。

表達式為：ip.src == 192.168.11.121

照此方法我們可以填寫到過濾的表單中然后點擊“Apply”按鈕即可過濾出結果。

如果輸入地址沒有找到則顯示”no data with this filter”：

（2）對目的地址為192.168.0.1的包的過濾，即抓取目的地址滿足要求的包。

表達式為：ip.dst == 192.168.0.1

（3）抓取滿足源或者目的地址的IP地址是192.168.0.1的封包。

表達式為： ip.src == 192.168.0.1 or ip.dst == 192.168.0.1

5.協議過濾

（1）僅僅需要捕獲某種協議的數據包，表達式很簡單僅僅需要把協議的名字輸入即可。

表達式為：http

那么在進行數據包過濾時在Filter：輸入http即可。如圖10-7所示。

圖  過濾Http協議

（2）排除某種協議的數據包

表達式為：!tcp 

排除IP協議：

6. 端口過濾

（1）捕獲某一端口的數據包。

表達式為：tcp.port == 80

圖  端口過濾

（2）捕獲多端口的數據包，可以使用and來連接，下面是捕獲高位端口（大于1024）的表達式。

表達式為：udp.port>= 2048

7.數據長度過濾

一組數據包查看它們的大小，會發現很多問題，在正常情況下，一個以太網的最大幀長為1518字節，去除以太網、IP以及TCP頭，還剩1460字節可供應用層協議的頭或者數據使用。那么我們根據這個原則就能通過捕獲數據包分析長度了解其分布然后對故障進行合理的分析和猜測。不過在OSSIM系統中這一功能交給Ntop來完成，下面我們看看如何通過一些表達式多包進行過濾。

（1）針對長度的過慮（這里的長度指定的是數據段的長度）。

表達式為：udp.length< 86

圖 長度過濾

我們知道以太網頭是14字節（包括了4字節的CRC校驗），IP頭最小20字節，沒有數據以及選項的TCP數據包也是20字節，這也就是說TCP用于控制的數據包，例如ACK、RST以及FIN的大小大約是54字節。查看那些長度小于64字節的數據包。

過濾器表達式如下：

frame.len<=64

圖  長度過濾

同樣方法可以使用如下表達式:

frame.number<=10   代表過濾出幀數小于10的所有包

fram.number= =10  代表過濾出幀數為10的包

通過以上的最基本的功能的學習，如果隨意發揮，可以靈活應用，就基本上算是入門了。我們還可以根據IP地址+端口進行過濾，比如在Filter:后面輸入：“ip.addr==192.168.11.1&& udp.port==53”效果如下圖所示。

圖  根據IP+端口過濾

8.IE瀏覽器漏洞的攻擊分析

背景：下面將要為讀者分析的來自于2010年的一個0day漏洞名叫極光漏洞，它是IE的一個緩沖區溢出漏洞,而利用這個漏洞進行攻擊的程序。接著看個實例：

受害者IP：192.168.100.206；攻擊者IP：192.168.100.200。

由于在在Windows系統的IE6/7/8等版本中，存在零日漏洞，沒有修復次漏洞的客戶端，有可能被攻擊者的網頁掛馬導致任意代碼執行，這里舉的例子中受害者就是使用了Windows XP+SP3+IE6的系統。下面本節講述了通過OSSIM抓包并分析可疑數據包的過程。

在OSSIM下抓包發現了一些可疑數據包，下面我們分析這些數據包的內容，首先受害者和攻擊者之間進行了三次握手，而且初始化連接的目標端口是80，很顯然屬于HTTP流量。從第13個數據包，能看出這是一個對/info的HTTP GET 請求，在圖中用綠色標出的部分。

當攻擊者的機器收到GET請求后，并在第50個數據包中返回了一個302 返回碼，其含義是用于瀏覽器重定向到另一個頁面。

注意這個Location域，它指明重定向的位置是/info?rFfWELUjLJHpP，這些內容好像是<script>標簽內的一些隨機字母，而這些類似亂碼的隨機字母，則可能被攻擊者經過了特殊編碼而逃避檢測。接下來，我們發現了一些更有用的信息。

注意，圖中URI:

/infowTVeeGDYJWNfsrdrvXiYApnuPoCMjRrSZuKtbVgwuZCXwxKjtEclbPuJPPctcflhsttMRrSyxl.gif:/infowTVeeGDYJWNfsrdrvXiYApnuPoCMjRrSZuKtbVgwuZCXwxKjtEclbPuJPPctcflhsttMRrSyxl.gif，這是個惡意的嵌套，很可能是包含在<span></span>標簽內，這些文本很長，包含了不可閱讀的字符創，這是攻擊者管用的手法。這樣用戶無法察覺，這個奇怪的GIF文件有什么用呢，這絕不是什么圖片。另外，大家注意Graphs按鈕內容，顯示了Wireshark的I/O圖像，它可以描繪網絡上的吞吐量，分析者利用這些圖便可找到不同協議數據吞吐的峰值。如圖所示。

GIF文件很有可能用來被觸發某種代碼，從圖10-17可以了解到。

從圖10-18我們清楚看到，一個Windows命令行解釋器，這個shell是由受害者發給服務器的，這表示攻擊者成功利用了漏洞，我們甚至可以看到攻擊者和受害者的交互，即輸入dir命令，列出受害者機器的目錄。這樣攻擊者對受害者機器就有了管理權限。

受害者接收到了可疑的郵件里面的圖片，并點擊了圖片，這對于瀏覽者而言在平常不過了，可是圖片背后的鏈接卻向攻擊者的惡意網站發送了一個GET請求。接著，攻擊者的Web服務器向受害者發送了302重定向，這樣一來，受害者的瀏覽器就向重定向后的URL發起了另一個GET請求。攻擊者的Web服務器向這位客戶端發送了含有惡意嵌套GIF圖像連接的幀（iframe），受害者從服務器上下載了GIF，這樣利用IE瀏覽器漏洞，便執行了隱藏的PayLoad,并打通了受害者到攻擊者的網絡通道，該Payload產生了一個命令行解釋器到攻擊者的計算機，以便遠程控制目標。

以上整個微妙的過程只需要幾秒鐘，而對于管理員很難捕獲到這一變化，下面我們開始梳理OSSIM中的流量抓包功能（Traffic Capture），看看它如何找到這些可疑數據包。下圖是在OSSIM漏洞庫中的有關極光IE 0 day漏洞的信息。

有關OSSIM抓包分析里的更多案例，感興趣的讀者可以參閱圖書《開源安全運維平臺OSSIM疑難解析》入門篇和提高篇。