Suricata 如何協助進行網路威脅偵測？

Suricata 唸作「蘇里卡塔」，名字像動物，工作卻像資安警衛。只要網路流量出現可疑特徵，就發出告警，牠就可能吹哨，也像巡邏警察，負責發現可疑線索。但警察按了警鈴，不代表案件就破了，是注意的開始。

在網路流量分析與資安事件調查中，除了了解哪些主機彼此通訊、使用哪些協定之外，我們還需要判斷網路流量是否存在可疑行為，例如已知漏洞利用、惡意連線或符合攻擊特徵的封包。

Malcolm 整合 Suricata，讓網路流量除了能被解析與搜尋，也能透過偵測規則產生安全警示。本文將從 Suricata 的定位、與 Malcolm 的整合方式，以及規則管理與實務應用三個面向，說明這項元件的用途。

一、Suricata 是什麼？在 Malcolm 中扮演什麼角色？

Suricata 是一套開源的網路威脅偵測引擎，具備入侵偵測系統（Intrusion Detection System，IDS）功能。它可以檢查網路封包，依據偵測規則與協定解析結果，判斷流量是否符合已知威脅或可疑活動的特徵。

例如，當內部主機與外部伺服器建立連線時，單純知道兩者曾經通訊，還不足以判斷這次連線是否具有風險。Suricata 可以進一步檢查封包內容與相關特徵，若符合某條偵測規則，就會產生對應的警示資訊，供後續調查使用。

在 Malcolm 中，Suricata 的主要定位是網路威脅偵測與警示產生。它並不是獨立運作的完整資安平台，而是 Malcolm 整體網路流量分析能力的一部分。

Malcolm 內部還整合了其他不同用途的元件：

• Suricata： 依據偵測規則辨識可能的威脅，產生警示事件。
• Zeek： 解析網路通訊，產生連線、DNS、HTTP 等協定相關的活動紀錄。
• Arkime： 管理與搜尋網路連線工作階段，協助調查人員回頭檢視相關封包。
• OpenSearch Dashboards： 提供搜尋、篩選與視覺化介面，方便分析相關事件。

這些元件的角色並不相同。Suricata 偏重於「哪些流量符合威脅特徵」，Zeek 偏重於「網路通訊發生了什麼事」，Arkime 則可協助調查人員追蹤相關連線與封包。搭配使用時，便能從警示進一步延伸至網路活動調查。

需要注意的是，Suricata 產生警示不代表攻擊一定成功。警示是需要驗證的調查線索，仍須搭配其他流量紀錄、封包內容與端點證據，才能判斷實際影響。

官方參考文件：Malcolm Components、Malcolm General Overview。

二、Malcolm 如何使用 Suricata 分析網路流量？

Malcolm 中的 Suricata 可用於分析即時擷取的網路流量，也可以對已保存的 PCAP 封包檔進行事後分析。這讓管理人員能依據監控需求或資安事件調查情境，選擇適當的分析方式。

1. 即時流量分析

在需要持續監控網路的環境中，可以設定 Malcolm 使用 Suricata 監看指定網路介面上的流量。

相關設定包括：

• SURICATA_LIVE_CAPTURE：控制 Suricata 是否直接監看即時網路流量。
• PCAP_IFACE：指定供封包擷取使用的網路介面。
• PCAP_FILTER：設定封包篩選條件，控制哪些流量需要被擷取。

例如，企業希望觀察特定網段的網路活動，可以先確認感測介面的連線方式，再依需求規劃監控介面及封包篩選條件。當 Suricata 發現符合偵測規則的流量時，相關警示就能納入 Malcolm 的分析環境。

不過，實際能否觀察到目標流量，仍取決於交換器鏡像埠、網路 TAP、路由位置及介面設定。若封包沒有被正確送到感測介面，即使 Suricata 正常執行，也無法偵測未被觀察到的流量。

2. 使用 PCAP 進行事後分析

除了即時監控，Malcolm 也能匯入先前保存的 PCAP 檔案。這對資安事件調查相當重要，因為調查人員不一定能在攻擊發生當下立即完成分析。

例如，企業發現某台主機疑似連線至惡意伺服器，可以將事件發生期間保存的 PCAP 匯入 Malcolm，再利用 Suricata 檢查流量是否符合偵測規則。

這類操作也適合用於：

• 針對已發生的資安事件進行回溯調查。
• 檢查可疑主機與外部 IP 位址之間的歷史連線。
• 驗證特定偵測規則是否能在測試封包中觸發。
• 比較不同規則版本對同一批封包產生的分析結果。

要特別注意，Malcolm 的 SURICATA_AUTO_ANALYZE_PCAP_FILES 預設值是 false。若希望匯入的 PCAP 自動交由 Suricata 分析，就必須確認並調整相關設定；不能假設每個匯入的 PCAP 都已經經過 Suricata 檢測。

3. 警示與其他分析資料的整合

Suricata 產生警示後，Malcolm 可以將這些資料納入整體的搜尋與分析環境，讓調查人員不必只停留在單一警示訊息。

例如，Suricata 發現某個來源 IP 位址涉及可疑流量時，可以接著利用 Malcolm 查詢：

• 該 IP 位址是否與其他內部主機通訊。
• 同一時間是否出現可疑 DNS 查詢或其他異常協定活動。
• 相關連線是否有可供進一步檢查的 PCAP 封包。
• 是否存在其他 Suricata 警示或相關的 Zeek 紀錄。

這樣的整合能將「發現可疑活動」延伸成「調查可疑活動的前因後果」，也是 Malcolm 相較於只查看單一 IDS 告警更有價值的地方。

官方參考文件：Malcolm Configuration、Malcolm General Overview。

三、Suricata 規則管理與實務應用注意事項

Suricata 的偵測能力與規則品質密切相關。規則負責描述要辨識的流量特徵，因此，除了讓服務正常運作，也需要考慮規則來源、更新頻率、自訂需求及誤報問題。

1. Malcolm 提供的規則與自訂方式

Malcolm 的 Suricata 整合包含預設規則集，也支援 Emerging Threats Open 規則集。使用者還能依據環境需求加入自訂規則。

Malcolm 的自訂 Suricata 規則可放置於安裝目錄下的：

./suricata/rules/

規則檔案需使用 .rules 副檔名。

例如，企業內部有特定服務、應用程式或測試環境，希望針對某種已知流量特徵建立額外偵測，就可以撰寫自訂規則，再依 Malcolm 官方文件要求套用變更。

此外，Malcolm 也提供規則更新相關設定，例如 SURICATA_UPDATE_RULES，可用來控制是否定期更新 Suricata 規則。官方文件中此設定的預設值為 false，因此管理人員應確認實際環境的更新政策，而不是假設規則一定會自動更新。

另有 SURICATA_CUSTOM_RULES_ONLY 設定。若將它設為 true，Malcolm 會略過預設 Suricata 規則集，只使用使用者自行提供的規則。這項設定會改變實際使用的偵測範圍，應確認需求後再調整。

2. 規則有了，不代表所有威脅都能被發現

Suricata 的警示判斷受到規則涵蓋範圍、封包可見性、協定解析能力及設定影響。沒有觸發警示，不一定表示網路沒有威脅；反過來說，出現警示也不一定代表主機已遭入侵。

因此，在企業環境導入時，建議特別關注以下事項：

規則更新與版本管理： 確認規則來源、更新時間及更新後的變更內容，避免長時間使用過時的偵測規則。

誤報與規則調校： 對於經常出現、但經確認屬於正常業務的警示，應先分析原因，再評估是否調整規則或排除條件，不宜直接忽略所有類似事件。

效能與流量負載： 即時封包分析會受到流量速率、封包大小、規則數量與運算資源影響。若要處理高流量環境，應依照實際網路負載測試分析效能，並調整相關設定。

加密流量的限制： Malcolm 官方文件指出，Malcolm 本身不具備解密加密流量的能力。即使 Suricata 能辨識部分連線特徵，也不能因此假設它可以直接檢視所有 HTTPS/TLS 加密內容。

3. 實務上應如何運用 Suricata？

對資安維運或事件調查人員而言，Suricata 最適合被視為一個威脅偵測入口，而不是事件調查的終點。

當 Malcolm 出現一筆 Suricata 警示時，可以先確認警示規則、來源與目的 IP 位址、時間及使用的協定，再利用 Zeek 的通訊紀錄與 Arkime 的連線、封包資訊進一步查證。

若發現警示對應的流量確實可疑，便可以擴大調查範圍，確認是否還有其他受影響主機或關聯連線。若判定為誤報，則可保留調查紀錄，評估是否需要調校規則。

整體而言，Suricata 負責協助 Malcolm 發現符合偵測規則的可疑網路活動；Malcolm 則進一步將警示、協定紀錄與封包搜尋能力整合，協助調查人員掌握事件脈絡。

這也是使用 Malcolm 時應掌握的觀念：IDS 警示提供調查線索，真正的事件判斷仍需結合網路流量與其他證據。

四、實戰案例：從 Suricata 告警開始，利用 Malcolm 逐步還原可疑網路活動

在實際的資安事件調查中，調查人員經常會遇到一個問題：Suricata 已經產生告警，但這筆告警究竟代表什麼？是正常的業務流量誤觸規則，還是主機真的正在與惡意伺服器通訊？

如果只看告警名稱就直接判定主機遭到入侵，可能會造成誤判；反過來說，如果因為沒有看到明確的惡意程式特徵就忽略告警，也可能錯過調查時機。

因此，正確的調查方式不是只確認告警有沒有出現，而是以這筆告警為起點，逐步驗證網路活動的背景、關聯與影響範圍。

以下使用一個模擬的企業網路事件，示範如何利用 Malcolm 進行調查。案例中的時間、IP 位址、流量內容與調查結果均為示範資料，不代表真實攻擊事件。

4.1 案例背景：內部工作站出現可疑 HTTP 告警

假設企業已經部署 Malcolm，並透過網路交換器的鏡像埠，將內部網路的流量送至感測設備進行分析。

某天上午，Suricata 產生一筆告警，指出內部工作站與外部伺服器之間的 HTTP 通訊，符合某條可疑流量偵測規則。

初始告警資訊如下：

上述目的 IP 屬於文件範例專用網段，並不是實際的惡意伺服器。

調查人員現在掌握的事實只有：一台內部工作站與外部位址之間存在符合特定偵測規則的網路活動。

目前還不知道這台工作站是由使用者主動發起連線，還是由某個背景程序建立連線；也不知道可疑特徵是否來自正常業務、錯誤設定，或真的與惡意活動有關。

因此，調查的第一個目標不是立即判定主機遭到入侵，而是先確認告警的意義，再利用 Malcolm 中的其他資料驗證這筆通訊。

4.2 第一步：確認告警本身，了解 Suricata 為什麼觸發

調查首先從 Suricata 告警本身開始。

在 Malcolm 的 OpenSearch Dashboards 中，先查看對應的 Suricata 事件，確認告警時間、來源與目的 IP、連接埠、協定，以及規則相關資訊。

應特別注意以下幾個欄位：

這裡列出的部分欄位名稱來自 Suricata 原始 EVE JSON 格式。資料匯入 Malcolm 後，欄位可能依解析及正規化方式呈現不同名稱，因此應以實際版本中的事件欄位為準。

接著，調查人員需要查閱觸發告警的規則內容，確認這條規則究竟在檢查什麼。

例如，規則可能針對特定 HTTP 請求內容、可疑 URI、已知漏洞利用特徵，或特定惡意通訊模式進行比對。不同規則所代表的意義不同，不能單靠告警名稱就推論攻擊已經成功。

此時應回答三個問題：

1. 這條規則想要偵測什麼行為？
2. 這筆流量的哪些特徵符合規則條件？
3. 這條規則是否可能被正常的業務流量觸發？

例如，若規則描述的是可疑 HTTP 請求特徵，調查人員就應進一步查看請求內容，而不是直接把告警歸類為惡意程式感染。

另外，若 Suricata 的 alert.action 顯示 allowed，代表該告警紀錄所標示的流量處理動作為允許。這不代表流量安全，也不代表主機未遭入侵。是否有實際封鎖，仍須確認 Suricata 的部署模式及相關防火牆或 IPS 政策。

這一步的調查目的，是釐清「Suricata 偵測到了什麼」，而不是急著回答「主機是否已經被入侵」。

4.3 第二步：確認來源主機的身分與正常用途

了解告警規則後，下一步要確認來源 IP 192.168.10.25 是哪一台設備。

這是非常重要的環節，因為同一個網路行為，發生在不同類型的設備上，可能代表完全不同的風險。

例如，若來源主機是一般員工使用的 Windows 工作站，調查人員可能需要檢查使用者的瀏覽行為、下載活動，以及相關程序的執行情況。

但如果來源主機是負責對外服務的 Web Server，則需要考慮它是否正在執行正常的 API 呼叫、更新作業，或其他伺服器工作。

調查時可以透過企業既有的資產清冊、DHCP 紀錄、IPAM、NetBox 或端點管理系統，確認下列資訊：

• 主機名稱與設備用途。
• 所屬部門及使用者。
• 主機作業系統與重要性。
• 該設備是否允許連線至外部 HTTP 服務。
• 該主機是否曾出現相同或類似的網路活動。

如果已整合 NetBox，Malcolm 也能在符合設定條件時，利用資產資訊豐富網路事件的相關中繼資料。

這裡的重點是建立主機的正常使用背景。例如，某台工作站平常只會瀏覽企業內部系統，卻突然出現大量對外 HTTP 連線，就值得進一步分析；但如果它本來就是執行外部 API 整合的應用伺服器，則必須先確認該連線是否符合既有業務需求。

需要注意的是，資產清冊只能協助確認設備身分，不能直接證明這筆流量正常或異常。

4.4 第三步：擴大時間範圍，還原告警前後的網路活動

確認主機身分後，接著要回答一個問題：

這是一筆孤立的異常連線，還是某一連串活動中的其中一步？

假設告警發生在上午 09:15:32，調查人員可以先將搜尋範圍設定為 09:05 至 09:25，觀察告警前後各 10 分鐘的網路活動。

這個時間範圍只是初步調查的起點。如果事件可能涉及長時間潛伏、固定週期連線，或早在數天前就開始的異常活動，就需要再擴大搜尋範圍。

在 OpenSearch Dashboards 中，可以使用 DQL 語法，先找出指定來源與目的 IP 之間的相關紀錄：

source.ip:"192.168.10.25" AND destination.ip:"198.51.100.20"

同時在介面中設定正確的事件時間範圍，避免因為查詢時間不一致而漏掉資料。

如果要先了解來源主機在這段時間內的所有通訊，可以改用：

source.ip:"192.168.10.25"

若要觀察該主機在這段期間作為通訊來源或目的端的全部紀錄，則可以使用：

source.ip:"192.168.10.25" OR destination.ip:"192.168.10.25"

上述查詢使用 Malcolm 官方文件所說明的 OpenSearch Dashboards DQL 語法。Arkime 使用的是另一套查詢語法，不應直接混用。

完成搜尋後，調查人員可以依時間排序，觀察是否出現以下情況：

• 可疑連線發生前，主機是否先查詢某個網域。
• 告警發生前後，是否有其他不同目的 IP 的連線。
• 相同目的位址是否在短時間內被重複連線。
• 告警發生後，是否持續出現其他可疑活動。
• 同一來源主機是否觸發其他 Suricata 告警。

例如，若發現主機在 09:14:58 查詢某個網域，隨後於 09:15:32 建立可疑 HTTP 連線，這兩筆事件就值得進一步比對。

但必須強調，時間相近只代表兩筆活動可能有關聯，不能直接證明 DNS 查詢與後續連線屬於同一個惡意行為。還需要確認網域解析結果、目的 IP、連線內容，以及其他可用證據。

這個階段的調查目標，是建立一份初步的事件時間線，找出值得深入檢查的活動。

4.5 第四步：利用 Zeek 補充通訊細節，判斷連線是否符合正常行為

在確認告警前後存在相關活動後，接著利用 Zeek 紀錄補充 Suricata 沒有直接回答的問題。

Suricata 主要根據偵測規則辨識可疑流量；Zeek 則能將網路通訊解析成不同協定的活動紀錄，例如 DNS、HTTP 與連線資訊。

調查人員可以在 Malcolm 的 OpenSearch Dashboards 或 Arkime 介面中，使用來源 IP、目的 IP 及時間範圍搜尋對應的 Zeek 資料。

這時候不只是看有沒有連線，而是要分析連線的上下文。

第一個調查方向：DNS 活動。

如果相關流量包含 DNS 紀錄，可以確認主機是否曾查詢與該目的 IP 有關的網域，以及查詢時間與後續連線的關係。

例如，假設主機在告警前查詢一個不熟悉的網域，並在查詢後立即連線到相應的 IP 位址，這會增加兩筆活動具有關聯的可能性。

但如果 DNS 紀錄不存在，也不能直接認定主機異常。主機可能使用 DNS 快取、直接連線至 IP 位址，或透過其他解析方式取得目的位址。

第二個調查方向：HTTP 活動。

HTTP 紀錄可能提供 Host、URI、HTTP Method、User-Agent、狀態碼及其他可用欄位。

這些資料可以協助回答：

• 主機正在存取哪一個網站或 API？
• 使用的是 GET、POST，還是其他 HTTP 方法？
• 請求路徑是否與正常應用程式行為一致？
• 伺服器回應的是成功、重新導向，還是錯誤？
• 是否出現與可疑下載或異常通訊有關的特徵？

假設調查人員發現，工作站對不熟悉的外部伺服器持續送出 POST 請求，且請求路徑不符合公司應用程式的正常使用方式，便有理由將其列為需要進一步檢查的活動。

不過，HTTP POST 本身不是惡意行為。網頁表單、正常 API 與企業系統整合都可能使用 POST，因此仍需結合請求內容、目的服務及端點資訊進行判斷。

第三個調查方向：連線頻率與資料量。

若同一來源主機持續與相同目的位址建立連線，可以觀察連線數量、發生時間、傳輸資料量，以及連線間隔是否具有規律性。

例如，每隔固定時間便出現一次類似請求，可能代表程式正在定期輪詢或執行背景工作，也可能與惡意程式的週期性通訊有關。

這類現象通常不足以單獨確認惡意活動，但可以成為後續調查的依據。

4.6 第五步：進入 Arkime，檢查實際工作階段與封包內容

當 Suricata 與 Zeek 的紀錄提供了可疑線索後，下一步是確認是否存在可以進一步檢視的封包資料。

在 Malcolm 中，Arkime 的 Sessions 介面可以搜尋網路工作階段，也能顯示與工作階段相關的 Zeek 紀錄。若系統有保存完整 PCAP，則可以進一步檢視對應工作階段中的封包。

這時候可以使用來源 IP、目的 IP、連接埠及時間範圍，將搜尋結果縮小到先前發現的可疑活動。

Arkime 的查詢語法範例：

ip.src == 192.168.10.25 &&
ip.dst == 198.51.100.20

這項查詢會尋找指定來源與目的端之間的相關紀錄。實際調查時，仍應搭配介面中的時間範圍，避免搜尋到其他時間的連線。

找到相關工作階段後，先檢查基本資訊，例如開始時間、結束時間、傳輸協定、來源與目的連接埠，以及雙向封包數與資料量。

如果能取得對應的封包內容，再進一步檢查 HTTP 請求與回應。

此時應特別注意：

• 實際的 HTTP Host 與請求路徑。
• 請求的 Method 及其他可用標頭。
• 是否出現異常的請求參數或可疑內容。
• 伺服器回應是否包含檔案下載或其他值得調查的資料。
• 同一工作階段中是否存在與告警規則相符的封包特徵。

如果 Arkime 只顯示連線中繼資料，而沒有可供檢視的封包內容，可能是因為沒有保存完整 PCAP，或目前的部署架構無法直接取得相關封包。此時不能把缺乏封包證據解讀成「沒有惡意內容」。

另外，若連線使用 HTTPS/TLS，Malcolm 本身不具備內建的 TLS 解密能力。即使能觀察到來源、目的、連線時間與部分加密連線中繼資料，也不代表能直接讀取加密的 HTTP 請求與回應內容。

Malcolm 官方文件也說明，Arkime 可以利用 network.community_id 或 Zeek 的 zeek.uid 等欄位，在具有相應資料的情況下，協助關聯特定網路連線的不同紀錄。調查人員可以從已找到的紀錄複製這些識別值，再尋找其他相關事件。

這一步的核心，是嘗試從「資料顯示有一筆可疑連線」，進一步確認「這筆連線實際傳輸了什麼」。

4.7 第六步：擴大調查範圍，確認是否只影響單一連線

完成單筆工作階段的檢查後，調查人員不應只停留在這筆連線。

接下來要確認的是：這項活動是否僅出現一次，還是同一主機或其他主機也有相似行為。

首先，可以擴大來源主機的搜尋範圍，檢查告警發生前後是否還有其他可疑目的位址、不同的通訊協定，或重複出現的連線模式。

其次，可以針對相同目的 IP、相同網域或同一條偵測規則進行搜尋，確認其他內部設備是否曾出現相關活動。

如果發現多台內部主機在相近時間內連線到同一個可疑目的位址，就需要評估是否涉及共同的應用程式、集中式服務，或潛在的跨主機威脅。

若只有單一工作站出現這類活動，則可優先深入檢查該設備的端點紀錄。

這裡要注意兩種常見的誤判。

第一種是看到多台主機連線到相同目的位址，就直接認定所有主機都遭到感染。實際上，也可能是企業共用服務、CDN 或正常的外部應用程式造成。

第二種是只看到一台主機產生告警，就認為事件只影響該設備。網路感測器只能看到實際經過監控位置的流量，沒有觀察到其他主機的活動，不代表其他主機一定沒有受到影響。

因此，調查範圍應依據目前證據逐步擴大，而不是單純以告警數量決定事件規模。

4.8 第七步：整合證據，決定是否需要啟動事件應變

經過前面幾個階段後，調查人員應該已經取得部分或全部的資訊：

• Suricata 的規則名稱與觸發原因。
• 來源主機的身分及正常用途。
• 告警前後的網路活動時間線。
• Zeek 所提供的相關協定紀錄。
• Arkime 工作階段及可取得的封包內容。
• 是否存在其他相關告警或受影響主機。

此時便可以將證據整理成調查結論。

以下是三種可能情況。

情況一：確認為正常業務流量。

假設進一步檢查後，發現該 HTTP 請求是企業內部應用程式執行正常的 API 呼叫，目的服務也與業務用途相符，而且沒有其他證據顯示存在異常活動。

這時可以將告警判定為已確認的誤報或正常活動，但應保留判斷依據。若確認問題來自規則過於寬鬆，可以再評估是否需要調整規則，避免相同情況持續產生大量告警。

情況二：存在可疑行為，但證據還不足。

假設來源主機持續對不熟悉的目的位址建立連線，而且 HTTP 請求具有異常特徵，但目前沒有足夠的封包或端點證據，無法確認是否發生惡意程式執行。

這時合理的結論是「可疑活動，仍待進一步驗證」。

後續可以蒐集端點 EDR 紀錄、Windows 事件日誌、程序執行資訊、DNS 與防火牆紀錄，確認是否有相關程序發起連線、是否下載或執行檔案，以及是否發生其他異常活動。

情況三：證據支持疑似或已確認的入侵事件。

假設除了 Suricata 告警之外，調查人員還發現可疑檔案下載、端點程序異常、相關惡意檔案特徵或其他足以支持入侵判斷的證據。

此時就應依企業事件應變程序，評估是否隔離主機、限制相關網路連線，並擴大調查可能受影響的設備。

實際執行隔離或封鎖之前，仍須考量主機的重要性、事件風險、業務影響，以及既定的應變權限與程序。

這三種情況說明，調查結果不應只分成「有告警」與「沒告警」，而應依據證據判斷活動是否正常、是否仍有疑點，以及是否需要進一步採取行動。

4.9 案例總結：Malcolm 如何將告警轉化為調查結果？

整個案例中，Suricata 提供了最初的偵測線索，但沒有單獨回答這筆連線是否真的構成資安事件。

調查人員先確認規則與主機身分，再建立告警前後的時間線，利用 Zeek 補充協定活動，並透過 Arkime 搜尋相關工作階段與封包。如果還有其他可疑活動，便進一步擴大調查範圍，最後結合端點與網路證據做出判斷。

對 Malcolm 使用者而言，最重要的不是記住每一種告警代表什麼，而是建立一套可重複使用的調查方法：

先確認告警意義，再建立時間線；接著關聯通訊紀錄與封包，最後根據證據判斷風險與應變範圍。

當調查人員能將這些步驟串連起來，Malcolm 就不只是顯示網路告警的工具，而是能協助釐清網路事件脈絡的分析平台。

延伸閱讀：

• Malcolm 官方文件：Arkime
• Malcolm 官方文件：搜尋語法比較
• Malcolm 官方文件：功能與限制
• Suricata 官方文件：EVE JSON 格式