NSX 分布式防火牆(DFW)最佳實踐與資安防護全貌

VMware NSX 的「分布式防火牆 (Distributed Firewall, DFW)」是微分段 (Micro-segmentation) 的核心元件。本篇給剛接觸 NSX DFW 的工程師：從 NSX Manager 畫面上看到的分頁開始，逐步拆解 5 大 Category 的設計邏輯、初次建置的標準作業順序、Zone/Tag/Group 的關係、Emergency 應變流程，以及 DFW 之外還有哪些資安防護模組（IDS/IPS、防毒沙箱、URL Filter），各自需要什麼授權與架構元件。

一、從畫面看起：「所有規則」vs「類別特定的規則」

打開 NSX Manager → Security → Distributed Firewall，會看到兩個頁籤：

二、5 大 Category 與處理順序（最重要的核心觀念）

DFW 規則永遠按照固定順序處理，不可調整：

Ethernet → Emergency → Infrastructure → Environment → Application
   L2層      緊急隔離      基礎設施依賴     區域/Zone之間    應用程式微分段

DFW 運作在每台 ESXi 的 vNIC 層級，專門處理 East-West（VM 之間） 流量：

三、初次建置 DFW 的標準作業順序（SOP）

Step 1：vCenter / 管理元件先排除（Exclusion List）

在做任何規則收斂之前，先確認以下物件已在 DFW Exclusion List 裡：

Step 2：Infrastructure Category — 先讓環境「能跑」

建立「全環境共用」的規則，Source 通常是 All-VMs（一個涵蓋所有 VM 的動態 Group）：

Step 3：Environment Category — 畫出 Zone 邊界

依 PROD/Non-PROD、DMZ/Internal/Restricted 等 Zone 維度，先建立「兩個 Zone 之間預設 Deny」的粗粒度規則：

Step 4：Application Category — 用「Allow + Log」觀察

對每個應用系統，先寫 Allow 規則並開啟 Log，觀察一段時間：

Web-Tier → App-Tier, TCP 8443, Allow, Log ✅
App-Tier → DB-Tier, TCP 1433, Allow, Log ✅

Step 5：收斂 Default Rule 為 Drop

確認所有合法流量都已被 Allow 規則涵蓋後，把最底層 Default Rule 從 Allow 改成 Drop，並開啟 Log 持續監控是否有合法流量被誤擋。

四、Zone、Tag、Group 三者的關係（新手最常搞混）

Zone（邏輯概念，安全分類，例如「PROD」「DMZ」）
   ↓ 透過
NSX Group（規則實際引用的物件）
   ↓ 成員定義方式（可混用）
   ├─ Tag（最常用，動態打標籤，如 env:prod）
   ├─ VM 名稱規則
   ├─ Segment / 網段
   └─ IP Range

• Tag = 貼在 VM 上的「屬性標籤」（單一維度）
• Group = DFW 規則實際引用的「物件」，成員條件可以用 Tag 動態抓取
• Zone = 人類理解架構用的「邏輯分類」，最終會落地成一個或多個 Group

常見 Zone 劃分維度（可疊加使用）：

五、Emergency Category：怎麼用、隔離後怎麼辦

5.1 典型用法：平時空白，事件時精準打擊

平時：Emergency Category = (空白)
       ↓ VM-Web03 疑似中毒
事件中：
   Rule 1: Any → VM-Web03, Drop, Log✅
   Rule 2: VM-Web03 → Any, Drop, Log✅
       ↓ 事件處理完畢
事後：移除規則，恢復空白

5.2 VM 被全面隔離後，要怎麼進去處理？

方法 A：VM Console（推薦，完全繞過 DFW）

DFW 作用在 vNIC 層級，而 VM Console 透過 Hypervisor 直接存取，不經過 vNIC，不受任何 DFW 規則影響：

VM Console：VM ←→ Hypervisor（不經過 vNIC，DFW 管不到）

透過 vCenter → 該 VM → 啟動主控台，即使 Emergency 規則寫了「全擋」，依然可以登入處理（前提：VM 已安裝 VMware Tools）。

方法 B：白名單鑑識通道

若需要遠端 SSH/RDP/EDR 工具持續作業，把 Allow 規則放在 Drop 之前：

六、DFW Log 在哪裡看

七、L7 Context Profile：App-ID / FQDN / URL Filtering

7.1「Application Category」≠「OSI Layer 7」

這是命名上的混淆陷阱：

• Application Category：5 大 Category 之一，預設仍是 L3/L4（IP+Port 的 5-tuple）
• Layer 7 Context Profile：獨立的選配功能，可以加在任何 Category 的任何規則上

7.2 Context Profile 五種屬性

7.3 授權需求

Context Profile 屬於進階功能，基礎版（NSX Standard）通常不含。在 VCF 9 訂閱模式下，「Full NSX」已涵蓋此功能（詳見第十節）。

八、NSX 完整資安防護全貌（對照傳統 NGFW）

來源：Overview of NSX IDS/IPS and Malware Prevention

九、純 DFW vs 完整防護：缺什麼元件？

NAPP 是什麼？

NAPP（NSX Application Platform）= 一個額外部署的 Kubernetes 叢集，不在流量路徑上，DFW 把事件/樣本「送過去」做進階分析：

十、VCF 授權對應

Broadcom 收購後，VCF 9 改成單一 per-core 訂閱，不再分 Standard/Advanced/Enterprise Plus：

十一、實務建議與延伸思考

• 「Kernel-based」vs「微服務-based」是理解功能分層的關鍵：DFW、Context Profile、基礎 IDS/IPS 跑在 ESXi Kernel，效能高、不需額外平台；Malware Prevention/NTA/NDR 需要大量運算（沙箱引爆、行為模型），所以被抽成獨立 K8s 微服務（NAPP）。這個架構決策直接決定了專案要不要多蓋一個 K8s 平台。
• 授權與架構是兩個獨立關卡：買了 ATP 授權，沒部署 NAPP，Malware Prevention/NTA/NDR 一樣不會動。基礎防護（DFW+L7+IDS/IPS）可以先上線，NAPP 平台排在後續階段。
• DFW 看不到 VM 內部：DFW/IDS/IPS 運作在 Hypervisor 層，看不到 VM 作業系統內部的 process/檔案行為——這部分仍需 EDR 補足，兩者是互補關係。
• 東西向防護是 NSX 的核心價值：傳統 Gateway IPS/AV 只在「進出資料中心」時檢查流量；NSX 把這些能力分散到每個 vNIC，VM 之間的橫向移動也會被偵測到，沒有監控死角。

參考資源

• Distributed Firewall - Broadcom TechDocs (NSX-T 3.2)
• Distributed Firewall Categories - Broadcom TechDocs (NSX 9.0)
• VMware Well-Architected Design: Distributed Firewalls Use Cases
• Preparing for Distributed Security - NSX-T 3.2
• Manage a Firewall Exclusion List
• Layer 7 Context Profile - Broadcom TechDocs
• FQDN Filtering - Broadcom TechDocs
• Overview of NSX IDS/IPS and Malware Prevention
• FAQ - NSX Application Platform (NAPP)
• Licensing Overview - VCF 9.0
• Design NSX Firewall Policies in a smart way - SECUREFEVER
• VMware NSX Layer 7 Firewall Features - Virtualization Howto