作者： Colin Jao 饒康立 – VMware資深技術顧問，主要負責VMware NSX產品線，目前致力於網路虛擬化、分散式安全防護技術與新應用遞送方案的介紹與推廣。

在前兩篇內我們討論在客戶生產環境現有運作應用系統上要部署微分段功能時，建議進行步驟的前三項。接續前文，這篇網誌繼續討論第四步驟。回憶一下這四個步驟如下圖：

步驟四：啟用防火牆阻擋規則，持續觀察與修正

 

經過前文的三步驟，包含一開始的資料檢視、不同工具的使用、日誌檢查、以及數次與業務應用團隊的訪談與檢討，此時部署的防火牆政策應該已經正確度大增了，雙方應該都有信心此時可以正式啟用阻擋規則。在此步驟我們將各應用最後的預設規則由允許改為拒絕。但當然這邊應該要持續進行應用以及防火牆日誌的觀察與修正，以確認雖然我們透過微分段、白名單的機制對業務系統進行完善的防護，但同時不會對正常的業務運作造成影響。

 

但不要忘記，當後續業務有異動，比如說換版等作業時，也應該再就前面的步驟在測試環境內重新進行防火牆規則的確認，並據以更新。此外，上面的流程是針對一個業務系統。客戶的環境當然同時有多個業務系統在運作，因此上面的配置當然可以多個業務平行進行。

 

這邊我們抓幾張實際的NSX-T / vRealize Log Insight的圖給大家看。在下列這張圖是針對展示的應用系統之對應防火牆規則，其中包含了

 

  • 允許任何來源到CRM此應用系統的ping流量 (規則ID 6123)

 

  • 允許任何來源到CRM系統Web群組的HTTP流量 (規則ID 6120)

 

  • 允許CRM系統Web群組到AP群組的TCP-8443 Port流量 (規則ID 6122)

 

  • 允許CRM系統AP群組到DB群組的MySQL流量 (規則ID 6121)

 

  • 對應此業務系統的預設規則設為Reject (規則6124)

在上圖內的Default Rule 6124號，就是在前篇步驟3內說明應先開啟成為Permit進行一段時間觀察，修正防火牆規則後，於步驟4內正式改為Reject or Deny進行白名單防護的應用預設規則。在這條規則內，我們應配置將Log機制打開，同時也可以加上一個Log Label （下圖內的 CRM-DEFAULT-REJECT），以易於進行後續的搜尋：

我們在Log Insight上可以直接透過輸入此規則的ID (6124)，或是前面輸入的 Log Label (CRM-DEFAULT-REJECT) 來進行搜尋。下圖內就是輸入6124，於指定的時間（五分鐘內），所看到的日誌資訊

同樣的紀錄可以看到有包含往172.17.11.11 / 172.17.11.12內的23 / 8080 / 9443等相關的port被阻擋。

在前面談到的步驟三，Default規則為允許，我們應該到Log Insight內確認這邊有哪些符合Default規則的日誌，並且與客戶進行比對確認這些是否是應該明確允許的規則（但是在前面步驟內的Workshop或工具監測時被遺漏了）。同樣的，在步驟四內，我們仍應該持續監測此條規則，並確認這些被拒絕的Traffic是異常的攻擊所以被阻擋，或是有阻擋到應該正常運作的應用流量，需要進行修正。

 

透過上述的步驟一到步驟四，我們提供一個可執行的方式，讓客戶能夠依據實際需求與時程，逐步將多個業務系統納入東西向防護。此方法具備下列優勢：

 

  • 方案安裝無痛，沒有業務停機需求

 

  • 白名單機制進行防火牆防護，僅有應用使用到的網路流可允許通過

 

  • 各個業務系統可以逐步納入NSX防護，無需於同一個時間內同時進行切換，也沒有業務中斷狀況上圖內，是我們對此方法的綜合簡要說明，請大家參考。 

    在接下來的網誌我想要分成數篇，進一步與大家介紹在步驟二裡面提到的工具：vRNI / NSX Intelligence，以及兩個方案之間的比較。