昨天談到 Sensor 收不到資料時，我提過會先從 SIEM 管理介面查看，必要時遠端檢查設備。到了現場，則會把筆電接到原本送給 Sensor 的 Mirror 埠，用 Wireshark 確認有沒有封包。

不過，有封包進來之後，裡面到底能看到什麼？

我平常主要透過 Stellar Cyber 查看整理後的網路紀錄與告警，會注意來源與目的 IP、連接埠、傳輸量和連線次數。遇到不認識的內部設備，也會把 IP 或 MAC 提供給客戶，請他們協助確認。

至於每個協定在做什麼，我還在慢慢補充理解。這次就從 Mirror 與 NDR 的分工開始，再整理 SMB、DCERPC 和 ARP 這幾個容易在網路監控中遇到的名稱。

Mirror 把流量送來，後面的工具再負責分析

我原本對 Mirror 的理解，是交換器把其他連接埠的封包，鏡像到一個特定的連接埠輸出。

更精確地說，Port Mirroring 是把指定來源的流量複製一份，送到監控用的目的埠。來源可以是連接埠或 VLAN，也可能設定只複製接收、傳送，或兩個方向的流量。原本的流量仍然沿著原來的路徑傳送。
Cisco：SPAN 說明

所以，Mirror 本身沒有在判斷攻擊，也不是把封包壓縮打包的功能。接上 Sensor、封包分析工具或其他監控設備後，才由後面的工具處理資料。

這裡也有一個限制：Mirror 只能提供設定範圍內、實際經過那些位置的流量。接上監控設備，不代表整個公司的通訊都會自動出現在裡面。

NDR 接著做什麼？

這次整理時，我自己也有一個疑問：NDR 不也是收資料、分析，再產生告警嗎？那和我平常使用的 SIEM 有什麼不同？

NDR 是 Network Detection and Response，網路偵測與回應。它的重點是分析網路活動，從封包或流量摘要中找出可疑模式，提供調查與回應能力。常見方法包含行為分析、建立平常活動的基準，以及比對威脅資訊。Sophos：NDR 基本概念

例如，以下只是教學示意：

一台平常只連固定伺服器的電腦，突然在短時間內，對很多內部設備的同一個連接埠發起連線。每次傳輸量可能不大，但目的設備很多，而且活動集中出現。

NDR 可以分析這種連線模式，提示是否有掃描等可疑活動，再讓人員往下查。至於這台是不是公司安排的掃描主機，仍要確認設備用途與作業安排。
Palo Alto Networks：NDR 與行為分析

這些能力也可能整合在其他平台裡，所以實際產品的功能會有重疊。可以先用下面的方式理解分工：

NDR 的「回應」也不表示接在 Mirror 埠上，就能直接擋住原本的連線。旁路監控收到的是副本，實際阻擋可能需要連動防火牆、EDR 或其他防護工具，依產品與部署方式而定。
Trend Micro：NDR 說明

SMB：開啟共享資料夾，也是網路活動

SMB 是 Server Message Block，常見用途是透過網路存取共享檔案。

例如在 Windows 開啟：

\\192.168.1.20\公用資料

接著瀏覽資料夾、讀取報表或存回檔案，就可能透過 SMB 完成。Windows 檔案伺服器與許多 NAS 都會使用這個協定。
Microsoft：SMB 概觀

因此，如果監控工具能解析相關通訊，看到的就可能不只是「這兩台設備有連線」，還包括共享名稱、檔案路徑、讀寫請求與回應狀態等資訊。

但不是每套工具都會顯示全部內容，也不是收到封包就一定看得到檔案細節。SMB 支援加密；如果相關通訊已加密，旁路工具又沒有解密能力，就無法直接讀出加密部分的內容。
Microsoft：SMB 功能與安全性

前面談噪音時，我提過 SMB 是自己常碰到的一類。回頭看它的用途，就比較能理解為什麼企業環境裡會有這麼多相關活動：日常共享檔案，本來就會產生連線。

因此，SMB 活動多，不代表已經發生橫向移動。還是要知道哪些設備在連、存取什麼，以及是否符合工作需要。

DCERPC：請另一台設備上的服務執行操作

DCERPC 這個名字比較不直觀。

先從 RPC 開始理解。RPC 是 Remote Procedure Call，遠端程序呼叫，意思是程式發出請求，讓另一個程序執行指定功能，再把結果傳回來。對方可能就在另一台電腦上。
Microsoft：RPC 說明

DCE/RPC 是其中一套協定體系，Windows 的 Microsoft RPC 以它為基礎並加入擴充。在封包工具或告警名稱裡，常會看到 DCERPC 這種寫法。
Akamai：MS-RPC 與安全機制

用遠端管理的情境來想會比較容易：

管理電腦提出請求：「請回傳你目前的服務狀態。」
遠端伺服器執行對應操作，再回覆結果。

這不是開啟遠端桌面讓人操作，而是程式與服務之間交換請求。Windows 的部分服務管理、列印與伺服器管理功能，都會使用 RPC。
Microsoft：Windows 服務與網路連接埠

RPC 也可能透過不同方式傳送。部分 RPC over TCP 通訊會先透過 TCP 135 的 Endpoint Mapper 找到服務端點，再連到服務使用的連接埠；另外也有透過 SMB 具名管道傳送的方式。所以，同一段通訊裡可能同時出現 SMB 與 DCERPC。
Akamai：MS-RPC 傳輸方式

對監控來說，如果工具能解析相關內容，就有機會進一步辨識呼叫的介面、操作與回應。

但正常管理工具也會用到這些功能。看到 DCERPC，還需要往下問：哪台設備發起？呼叫什麼功能？這是不是原本就有的管理作業？

ARP：知道 IP，還要找到本地要交給誰

ARP 可以接回我平常看 IP 與 MAC 的習慣。

在一般的 IPv4 乙太網路裡，設備要把資料送出去，需要知道本地這一段的接收對象。ARP 就是用來查詢 IPv4 位址與 MAC 位址的對應。
RFC 826：ARP 規格

例如，以下是同網段通訊的簡化示意：

• 電腦 A：192.168.1.10/24
• 伺服器 B：192.168.1.20/24

A 想把資料送給 B，如果沒有可用的對應快取，就會發出 ARP 詢問：「誰使用 192.168.1.20？」

收到回覆後，A 就能暫時記住 B 的 IP 與 MAC 對應，將乙太網路訊框送給它。

如果目的地在外部網路，情況就不同。一般情況下，電腦會先把資料交給閘道，因此本地這一段需要的是下一跳閘道的 MAC，而不是外部網站主機的 MAC。

這也解釋了為什麼封包中的目的 IP 與目的 MAC，不一定屬於同一台設備。看 MAC 時，要連同觀察位置一起理解。

我看 MAC，主要是請客戶協助找內網設備

我實際使用 MAC 的情境，主要是遇到不認識的內部設備。

有些客戶使用浮動 IP，單看一個 IP，不一定容易找到當時是哪台設備。因此，只要紀錄裡有 IP 或 MAC，我都會提供給客戶，請他們協助辨識。

這部分是客戶協助確認，不是我自己進去查 DHCP 系統。

這次也補充了一個查證方向：如果要找的是過去某個時間的設備，除了位址，也要提供事件時間。客戶若有保留對應的 DHCP 租約或配發紀錄，就有機會確認當時哪個設備使用那個 IP。

至於 MAC 本身，也不能直接告訴我設備用途。找到設備後，還是需要客戶說明它在做什麼，才知道眼前的連線是否合理。

三個協定，不是固定的一條流程

把這次的概念放在一起，可以先這樣記：

它們不是每次都依序出現的三個步驟。

例如存取同網段的共享資料夾時，需要時可能先透過 ARP 找 MAC，再使用 SMB 存取檔案；但 ARP 快取如果已經存在，就不一定重新查詢。DCERPC 則要看實際執行的功能，不是每次讀檔都必須經過它。

同樣地，Monitor 收到哪些活動，也取決於 Mirror 的位置、設定範圍、通訊是否加密，以及工具的解析能力。

我平常還是從熟悉的 IP、連接埠、傳輸量與連線次數開始看。這次把協定用途補上之後，至少比較能理解，畫面上那些名稱背後可能正在做什麼。

接下來遇到不確定的活動，我還是會先找出涉及的設備，把能看到的資訊提供給客戶或同事，再一起確認。這些協定名稱，會是繼續查看的入口，而不是直接判定攻擊的答案。