iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 9
2
Security

學習網路安全監控的30天系列 第 9

NSM 09: 深度分析封包﹝NetMon 可以直接當作IDS?﹞

昨天運用NetMon各種內建的儀表板和便利的搜尋功能查詢收集到的資料,這些豐富的資料是怎麼來的呢?除了從Flow 中擷取Metadata元資料,NetMon 本身能對監控的網路流量進行DPI﹝Deep Packet Inspection深度封包檢測﹞,對Layer 2到7封包進行完整監控與分析,從封包中擷取資訊,進一步補充Metadata元資料,自動辨識應用程式和網路流向,藉以偵測不明程式、異常網路流量、網路行為等等,當metadata分析結束後希望進一步深入調查,也可對存放的原始資料及封包資料進行搜尋或Replay。

Deep Packet Analytic

NetMon對監控的網路流量進行DPI﹝Deep Packet Inspection深度封包檢測﹞有其流程,分為packet封包 和flow流量兩部分,如下圖示意,網路流量經過NIC收集後,開始進行DPI深度封包檢測,利用NetMon內建的DPA (深度封包分析Deep Packet Analytic) Rule 進行分析。首先通過Packet Analysis Packet Rules分析,將PCAP儲存後把資訊以metadata元資料繼續以Flow Analysis Flow Rules進行第二次分析,獲得的資料儲存至Elastic Search供日後檢索。透過Packet和 Flow的DPA Rule,NetMon可以偵測異常行為,將偵測結果豐富metadata資料, 以圖形儀表板呈現;或者觸發Alarm警示;或者經由Syslog傳至SIEM﹝Security Information and Event Management,安全資訊和事件管理﹞進一步比對分析。

https://ithelp.ithome.com.tw/upload/images/20181024/200848062ibtpH7I8g.png

*來自網路截圖

DPA Rule預設是關閉的,我們首先點選儀表板上方Rule,然後選擇左方的Deep Packet Analytics Rules,可見以下截圖:下方區域便是NetMon本身內建的DPA Rule,這些都是經過LogRhythm公司開發人員測試過的,對封包檢測時不會對網路效能造成影響,我們可以個別開啟Rule set開始偵測,或者點選右方小圖示檢視這些DPA Rule是怎麼寫的。
https://ithelp.ithome.com.tw/upload/images/20181024/20084806nSuhLv5hwL.png

DPA Rule 是以Lua程式設計語言編寫,所以社群中也有自行開發的DPA Rule Set,我們可以透過儀表板左上方的按鍵上傳別人寫好的Rule Set,在PCAP Replay儀表板重播PCAP來測試DPA Rule;也可以從右上方按鍵用Lua程式設計語言編寫自己的DPA Rule set,善用DPA Rule讓NetMon提供即時偵測、警示及回應零時差惡意攻擊,甚至可以偵測資料外洩!﹝因為可以從封包看到網路流量傳輸的是什麼檔案﹞。我從以下的網站下載一些測試資料來測試資料外洩的DPA Rule。

https://dlptest.com/

這是一個測試DLP﹝Data Loss Prevention資料遺失保護﹞功能的網站,可以下載一些測試用的樣本,包括信用卡號樣本、社會安全號碼SSN樣本等等,有word檔有excel檔,也可以直接測試http post 和https post。當我們測試後,可以回到Alarm Dashboard看到觸發的警示,這些警示都可以透過syslog傳到SIEM作為資料進一步分析比對:例如從SIEM中藉由Log日誌察覺有一個帳號多次在Server登入失敗,登入成功後,接著從NetMon收到偵測/警示該Server傳輸包含信用卡號的機密檔案。總合以上活動判斷可能是Server被突破,入侵者正外洩資料。

文末分享三篇文章,第一篇說明如何用NetMon偵測WannaCry流量,及時發現避免在內網橫向感染;第二篇是用NetMon偵測隱藏在ICMP流量裡的PowerShell指令;第三篇是說明如何善用Lua程式語言用NetMon自製IDS。有興趣深入玩玩的讀者不妨參考。

LogRhythm Blog: Using NetMon to Detect WannaCry Initial Exploit Traffic
https://logrhythm.com/blog/using-netmon-to-detect-wannacry-initial-exploit-traffic/

Identifying PowerShell Tunneling Through ICMP
https://logrhythm.com/blog/identifying-powershell-tunneling-through-icmp/

Network Monitor as a Programmatic Intrusion Detection System
https://logrhythm.com/blog/network-monitor-as-a-intrusion-detection-system/


上一篇
NSM 08: 漫遊NetMon,糾出異常狀態
下一篇
NSM 10 網路安全監控佈署方式 (TAP or SPAN?)
系列文
學習網路安全監控的30天30

1 則留言

0
彭偉鎧
iT邦新手 3 級 ‧ 2018-10-24 23:08:14

"總合以上活動判斷可能是Server被突破,入侵者正外洩資料。"

Frank,
大概判斷是駭客入侵的正確率有多高?

另外,這個測試的樣本數大概是多少?

這個問題很難直接回答,我接下來會另外寫一篇關於偵測分析的方法分享。

簡單一點回答的話:我們運用工具偵測到的是「活動」。例如收集Log日誌知道「多次登入失敗」、「登入成功」;藉由NSM工具偵測到「正在傳輸含有信用卡資料的檔案」等。個別看這些單一活動無法辨別是否為惡意行為或是駭客入侵,只能說它「可疑」,除非是PowerShell Tunneling Through ICMP這種活動(因為正常情況下不會出現)。

SIEM最重要的功能之一就是比對來自不同來源的資料(日誌、警示等等),當發現很多相關可疑活動(例如出自同一IP位址、同一帳號等等),屬於入侵行為的可能性相對比較高。我舉的例子可能是有人用brute force猜測帳密失敗多次後終於成功登入,找到一份包含信用卡號的機密檔案,藉由網路傳輸出去(web upload);但也很有可能是公司員工Frank記錯密碼登入失敗好幾次後終於成功,然後上傳了一份檔案,裡面有些很像信用卡號的數字。在沒有進一步調查前,無法排除入侵可能性,也不能證明確實是入侵。

彭偉鎧 iT邦新手 3 級 ‧ 2018-10-25 13:16:38 檢舉

好ㄉ,期待你的測試結果!

我要留言

立即登入留言