[工具介紹] 利用 OpenNMS 監測 IP/MAC/Switch Port 使用情形

身為一個專業的系統管理人員，使用各式各樣的監測機制是絕對少不了的。監測可以分為兩大類，第一類是監測"應該存在"的項目，例如監測某台主機上的 Web 服務是否正常運作、或是某台主機的 CPU 使用量是否合理。這類監測項目通常與可用性 (Availability) 有關，而可用性是許多資訊系統存在的最重要目的，因此管理者往往會竭盡心力做好這類的監測。相對應於這類項目，還有另外一類的監測項目是屬於"不應該存在"的項目，像是某台主機不應該提供 MSSQL 的服務。這類監測項目因為通常與可用性無關，所以容易受到管理者的忽視。儘管如此，這類事件對資訊環境的安全性卻有著無比重要的地位。
以管理主機群來說，一個很重要的監測項目就是我們必須確保沒有多餘的服務在有意或無意下被開啟了，也必須確保沒有不必要的設備被接上了主機群所在的網路。後者對於一個實體管理嚴格的機房來說，或許是很難發生的狀況。但是以現今虛擬化的資訊環境來看，接上一台不被允許的"設備"，卻再也不需要"出現在現場"才有可能達成了。今天要跟各位分享的這個工具 – OpenNMS，支援 SNMP 協定，可以用來抓取各項重要的資訊 (如網路介面流量數據) 並繪製為圖表。除了這個功能外，更重要的是 OpenNMS 可以定期掃描網路上 IP 的使用狀況，以及這些設備上所開啟的 (網路) 服務。一旦發現 IP 位址或 (網路) 服務情況有所變動，就可以透過各式各樣的通知機制通知管理者，以做出必要的因應之策。
OpenNMS 的監測機制，除了透過主動掃描以發現任何異動外，還支援 L2/L3 對應的能力。我們都知道，在常見的網路中，每個網路介面都具備兩種位址，一種是所謂的 MAC 位址，另外一種則是 IP 位址。MAC 與 IP 的對應關係，通常記錄於設備 (主機、交換器等) 的 ARP 快取表當中。而對於交換器而言，通常還會另外維護一份稱之為 CAM 表的資料。在 CAM 表當中，記載了 MAC 位址與交換器埠的對應關係，以達到封包交換的目的。CAM 表的存在，讓交換器不需要像集線器般使用廣播方式來傳送封包。OpenNMS 可以透過 SNMP 協定查詢網路設備的 ARP 快取表與 CAM 表，並記錄之間的關係，也就是說我們可以利用 OpenNMS 了解某個交換器上的某個埠接了哪些設備及其使用的 IP 位址。這些資料不只對於管理主機群時很重要，對於管理用戶端來說更是重要。因為用戶端通常處於開放且動態的實體環境，再加上用戶端系統的安全管理通常不如主機群般嚴謹，所以監控用戶端的網路連結情形絕對馬虎不得。事實上，這類資料就是屬於新版個資法中定義的軌跡資料，對於日後舉證需求將有莫大的助益。
不過可惜的是，OpenNMS 預設並沒有開啟 L2/L3 對應的功能，所以我們需要修改設定檔才能獲得這樣的資訊。這個設定檔的位置是

$OPENNMS_HOME$/etc/service-configuration.xml

對以 rpm 方式安裝的 OpenNMS 而言，這個檔案的實際位置是

/opt/opennms/etc/service-configuration.xml

將下列這段文字取消註解即可：

<service>
  <name>OpenNMS:Name=Linkd</name>
  <class-name>org.opennms.netmgt.linkd.jmx.Linkd</class-name>
  <invoke at="start" pass="0" method="init"/>
  <invoke at="start" pass="1" method="start"/>
  <invoke at="status" pass="0" method="status"/>
  <invoke at="stop" pass="0" method="stop"/>
</service>

記得要重新啟動 opennms 服務才會使修改後的設定生效。服務重新啟動後，我們可以透過指令

service opennms –v status

來查看服務的執行狀態。如果看到下列訊息，表示 L2/L3 對應的功能已經正常啟動了。

...
OpenNMS.Statsd         : running
OpenNMS.Provisiond     : running
OpenNMS.Reportd        : running
OpenNMS.Alarmd         : running
OpenNMS.AsteriskGateway: running
OpenNMS.Ackd           : running
OpenNMS.JettyServer    : running
OpenNMS.Linkd          : running
opennms is running

一旦啟動 L2/L3 對應功能後，我們就可以在交換器節點 (Node) 的畫面看到如下的連結 (註一)：


點下連結 View Node Link Detailed Info 就可以看到詳細的交換器埠使用狀況：


除了用表列的呈現方式，OpenNMS 也提供網路拓撲圖的呈現方式。透過網路拓撲圖，我們不但可以看到設備的連結關係，更可以即時看到各連結關係的狀態，方便管理者隨時掌握網路的狀態。OpenNMS 讓管理者可以確實掌握網路環境中 IP/MAC/Switch Port 的使用狀況，不管是任何未經授權的使用或變更，都將無所遁形。

註一：重新啟動服務後，需要很長的一段時間才會看到相關的資訊。我一直到隔天才看到資訊出現。

[教戰守則] 談 VMware 虛擬交換器之 Promiscuous Mode

在早期使用集線器當做網路的連結設備時，因為集線器的特性是使用廣播方式傳遞封包，所以網路上的任何一台電腦只要"有心"就可以看到不屬於它的封包。不過網路介面 (網路卡) 通常為了效能的考量，並不會處理所有傳送過來的封包，而會先檢查這些封包是否確實是它應該加以處理的，唯有它應該處理的封包才會進入系統並處理之。而 Promiscuos Mode，屬於網路介面的一種運作模式，在這種模式運作下的網路介面，會忽略檢查的動作並把網路上傳送過來的所有封包都交給系統處理。也就是說，在集線器的環境下，只要電腦的網路介面進入 Promiscuous Mode 就可以把網路上的封包看透透，其中肯定包含了不少重要的資料 (如密碼)。

好在現在使用的網路設備多屬於較為聰明的交換器，交換器在正常的運作情況下不使用廣播方式傳遞封包，所以即使我們將電腦的網路介面設定為 Promiscuous Mode 也無法窺得別台電腦的封包。不過有時候，我們 (網路管理員) 確實需要窺得其他電腦的封包，其中最常見的一種狀況就是佈署 IDS/IDP 時。此時，我們可以透過交換器的 Port Mirror 功能，讓交換器把其他電腦的封包複製一份至 IDS/IDP 所連結的交換器埠，好讓 IDS/IDP 看到這些封包。這是實體交換器的特性，那麼對於虛擬環境下使用的虛擬交換器呢？

在 VMware vSphere 5 ESXi 下，虛擬機預設只能看到遞送給它的封包。對於需要看到其他電腦封包的需求，虛擬交換器並沒有 Port Mirror 的功能，不過倒是有支援 Promiscuous Mode 的功能。Promiscuous Mode 的功能設定可以指定在整個虛擬交換器上，也可以指定在特定的 Port Group 上。對於虛擬交換器而言，Promiscuous Mode 的設定預設是關閉的。而 Port Group 預設則是沒有任何設定，因此會直接繼承虛擬交換器的設定，也就是同樣是關閉的。如果我們想要虛擬機具備看到其他電腦封包的能力，我們就必須讓這台虛擬機所在的 Port Group 擁有 Promiscuous Mode 的功能。根據前面所提，這個功能可以從虛擬交換器或 Port Group 的層級加以開放。從安全的角度來看，建議的作法是將這台虛擬機放入一個專屬的 Port Group，並 (只) 針對這個 Port Group 開放 Promiscuous Mode 的功能。如此一來，這台虛擬機就可以看到這個虛擬交換器內所有收送的封包了 (包含其他 Port Group，但不包含 Management Traffic)。以此看之，Port Group 是用來方便管理的單位，而不是為了模擬不同的實體網路。如果我們想要單一虛擬機僅能看到虛擬交換器上部分的封包 (而非全部封包)，必須搭配 VLAN 的設計方式，而不是光透過 Port Group 就可以達成。

網路封包窺視是一個很嚴重的問題，其可怕之處不只在於可以窺得很多重要的資料，更令管理者感到困擾的是封包窺視通常是一種很隱密的被動攻擊行為。不管是在實體或虛擬環境下，如果佈署上不一小心，就可能變成全都露而不自知了。因此對網路管理者而言，了解虛擬交換器的運作方式就成了虛擬化過程中一個必須認真對待的課題了。

[迷你好兔] 利用 Host Profile 確保 VMware vSphere 5 ESXi 主機的設定狀態

在上一篇的文章中，我分享了如何修改 ESXi 主機上的 syslog 設定。由於 syslog 設定是存在於各 ESXi 主機上，所以如何有效地設定所有 ESXi 主機並確認無所錯誤，就成了一件很重要的事情。在這一篇文章中，我將利用 Host Profile 的功能，幫助我們確保所有的 ESXi 主機都有相同的 syslog 設定。

不囉嗦，馬上就開始進行：

1. 因為 Host Profile 屬於 VMware vCenter Server 的功能，所以我們需要使用 VMware Client 連結 VMware vCenter Server。直接連結 ESXi 主機無法使用 Host Profile 的功能。
2. 選取 "Inventory" –> "Hosts and Clusters"。
3. 選取一個已經修改好 syslog 設定的 ESXi 主機，並在右鍵選單中選取 "Host Profile" –> "Create Profile from Host…"。
4. 輸入 Host Profile 的 Name (名稱) 與 Description (描述)，輸入完畢後按下 "Next >"。
   
5. 確認輸入無誤後，按下 "Finish"。
   
6. 選取另外一台尚未修改 syslog 設定的 ESXi 主機，並在右鍵選單中選取 "Host Profile" –> "Manage Host Profile…"。
   
7. 選取我們剛剛新增的 Host Profile，選取完畢後按下 "OK"。Host Profile 必須附加 (Attach) 於 ESXi 主機才有作用，而且一台 ESXi 主機僅能附加一個 Host Profile。
   
8. 在右鍵選單中選取 "Host Profile" –> "Check Compliance" 以開始檢查作業。
   
9. 檢查完畢後我們可以在 Summary 這個頁籤看到此主機的設定並不符合規範 (Host is not in compliance with the attached profile)。
   
10. 在 Summary 這個頁籤的下方可以找到相關資訊。
    
11. 點選連結後可以看到詳細資訊，顯示 Syslog.global.logHost 這個設定值不符合規範 (Option Syslog.global.logHost doesn’t match the specified criteria)。
    
12. 我們可以透過右鍵選單中的 "Host Profile" –> "Apply Profile…"，將相關設定自動套用到選取的 ESXi 主機。
    
13. 不過在使用 Host Profile 自動套用的功能時，ESXi 主機必須先進入維護模式 (Maintenance mode) 方可進行。對於不適合進入 Maintenance mode 的 ESXi 主機，可以使用手動的方式進行設定。
    

Host Profile 除了可以幫助我們簡化設定的作業，更重要的是 Host Profile 可以幫助我們確保設定的正確性。Host Profile 可有效地避免因為人為疏失或其他因素所造成的設定值不正確，進而危害到整個虛擬作業的有效性或/與安全性。

[迷你好兔] 啟用 VMware vSphere 5 syslog 並整合至 Splunk

在前一篇 VMware vSphere 5 ESXi 安全建議事項的文章 中，我提到應該啟用 ESXi 主機的 syslog 機制，並將這些重要的資訊統一集中至公司原本的日誌管理機制中。儘管 VMware vCenter Server 包含了一個 syslog daemon 可供安裝與使用，但是我並不建議使用此一套件。我之前與各位分享過一個功能強大的日誌管理系統 – Splunk，因此我今天要跟各位分享如何讓 ESXi 的主機透過 syslog 機制將資訊遞送到 Splunk，並利用 Splunk 即時警示登入錯誤的資訊。

好了，同樣讓我們一步步完成今天的任務吧：

1. 我們必須擁有一個正常運作的 Splunk，而且接受來自 syslog (UDP:514) 的資料輸入。
   
2. 設定 Splunk 主機的防火牆，允許 syslog (UDP:514) 封包進入。
3. 使用 VMware vSphere Client 連結主機或是 VMware vCenter Server。
4. 如果你是連結至 VMware vCenter Server，請選擇 "Inventory" –> "Hosts and Clusters"。
5. 點選你想要開啟 syslog 機制的主機。
6. 點選 Configuration 的頁籤 (Tab)。
7. 點選 "Security Profile"，並按下連結 "Properties…" 以設定主機的防火牆。
   
8. 開啟 syslog 封包的傳送規則，設定完成後按下 "OK"。
   
9. 點選 "Advanced Settings"。
   
10. 打開 Syslog –> Global 的設定。在 Syslog.global.logHost 此一欄位輸入 syslog 主機的 IP 位址，此時我們應該指定為 Splunk 主機的 IP 位址。輸入完畢後按下 "OK"。
    
11. 故意使用錯誤的帳號/密碼嘗試登入此一 ESXi 主機。
12. 至 Splunk 主機下 "Hostd: Rejected password" 此一查詢語法。我們可以看到登入錯誤訊息出現在查詢結果當中。
    

透過 Splunk 的儀表板與即時通知功能，我們可以把嘗試登入 ESXi 主機的錯誤訊息做更有效率與更即時的應用。當然，ESXi 所遞送過來的資訊很多，並不局限於此一應用。不過以登入錯誤資訊而言，光取得 ESXi 主機上的 syslog 資訊依舊不夠完整。如果我們採用 VMware vCenter Server 來管理虛擬化環境，大多時候我們是登入至 VMware vCenter Server ，而非直接登入主機。而不幸的是，VMware vCenter Server 本身並沒有將相關訊息透過 syslog 遞送至遠方的功能。關於此點，我們可以在 VMware vCenter Server 主機上安裝 Splunk 的 forwarder，並即時監測 VMware vCenter Server 相關日誌的目錄，如果一來 Splunk 就可以獲得 VMware vCenter Server 的日誌記錄了。VMware vCenter Server 在 Windows 2008 下將日誌存放於 C:\Program Files\VMware\VMware VirtualCenter\Logs 這個目錄之內，至於在其他作業下的目錄可以參考 VMware 的官方文件。

就跟大多數的 ESXi 主機設定值一樣，syslog 的設定也必須一台台 ESXi 主機分別進行。這對管理大量 ESXi 主機的管理者而言，是一件費時而且容易出錯的工作。在下一篇文章中，我將跟各位分享如何利用 VMware vCenter Server 的 Host Profile 功能，來簡化 ESXi 主機的設定作業。

[教戰守則] VMware ESXi 安全建議

這幾年來，越來越多的企業開始使用虛擬化環境。不管是將虛擬化環境用於支援系統，還是將重要核心系統佈署在虛擬化的環境當中，虛擬化環境的安全性都是一項不可忽視的議題。虛擬化環境的導入，通常以提高資源使用效率與可用性為主要目的，而安全性卻往往沒有受到同等的重視。事實上，將系統從實體環境轉換到虛擬化的環境後，除了原有的安全考量之外，還多了一些額外的事項需要注意。因此，如果只是單純將系統從實體環境轉換到虛擬化環境之中，整體的安全性可能反而是下降的。
在這篇文章中，我將針對 VMware vShpere 5 的虛擬化環境，提供一些用來加強虛擬化環境安全性的建議作法：

1. 充分使用 ESXi 內建的防火牆 ESXi 已經內建防火牆，而且預設就是開啟的。更棒的是，如果某些服務 (如ssh daemon) 被開啟或關閉時，系統將會自動啟用或關閉相對應的防火牆設定。ESXi 內建防火牆的設定以各項服務為主體，而不是單純的網路協定或埠號，也就是說我們無法透過 ESXi 的防火牆指定開放 TCP Port 3306 (MySQL 服務)。乍看之下可能會令人覺得這樣的設定方式不夠完整，但是其實這樣設定方式卻是再方便不過了。事實上，我們沒有必要進行開放 TCP Port 3306 的設定，原因在於 ESXi 防火牆僅適用於過濾與主機 (host) 溝通的封包。對於與虛擬主機溝通的封包，ESXi 內建的防火牆並不會進行任何過濾的行為。如果我們要限制虛擬機所能提供的服務，必須透過作業系統 (guest OS) 內的防火牆機制或是其他套件來達成此一目的。
   在使用 EXSi 內建防火牆時有一個需要特別注意的地方，那就是預設並沒有針對任何遠端 IP 位址進行限制。也就是說如果一旦選擇開放 ssh daemon 的服務，任何 IP 位址都可以對此服務進行存取。想當然爾，這並不是一個安全的設定方式，我們應該針對實際的情況限制可以存取服務的 IP 位址，以避免任何不安全的存取嘗試。在下圖中，我限制只有 211.x.x.x 的 IP 位址可以存取主機上的 snmp daemon。
   
   最後，ESXi 內建的防火牆必須一台台主機加以設定。對於同時管理多台主機的管理者而言，可以利用 host profile 或其他工具來統一進行主機的防火牆設定作業。
2. 使用其他針對虛擬化環境設計的安全產品
   傳統的安全機制不是無法套用於虛擬環境之中，不然就是效能將受到影響，所以針對虛擬化環境我們必須採用專門為其所發展的產品。VMware 有另外一個稱之為 vShield 的產品，可以用來強化整體虛擬環境的安全性。
3. 啟用集中管理的日誌功能
   ESXi 支援 syslog 的機制，可以將系統相關訊息透過 syslog 的機制統一遞送到 syslog 伺服器。在 VMware Server 的安裝光碟上包含了一個 syslog 伺服器的套件，安裝後就可以在 VMware Client 上直接看到日誌的相關資訊。雖然看似方便，但是我個人並不建議使用此一套件，原因在於我們並不能透過 VMware Client 直接查看日誌的內容。所以比較建議的方式是將這些主機的訊息遞送到企業原有的 syslog 伺服器以便進行統一個管理。syslog 的相關設定，同樣必須一台台主機加以設定。
4. 記得更新 EXSi 與 VMware Tools
   雖然 ESXi 看似單純，而且也不似我們之前常接觸的作業系統，但是不管如何，ESXi 還是一個不則不扣的作業系統。所以跟所有的軟體一樣，ESXi 也有更新的需求。然而因為通常單一主機上執行了多台的虛擬機，所以造成管理者對於更新作業所要求的重啟行為會有所擔憂。此部份如果搭配 vMotion, VMware HA, FT 等機制，其實並不會因為主機重啟而造成服務的中斷。除了 ESXi 更新之外，VMware Tools 也應該隨時保持在最新的狀態。我們可以透過 Update Manager 這個 plug-in 來簡化這些更新作業的進行，不過 Update Manager 必須搭配 VMware Server 方可使用。
5. 考慮使用其他非自簽的憑證
   雖然 ESXi 預設已經使用憑證進行資料的溝通 (例如 VMware Client 與 主機之間的溝通)，但是因為內建的憑證是自簽的關係，所以不容易確保憑證的合法性。如果企業內部擁有 CA 的機制，應該統一採用企業所簽發的憑證。如果企業內部沒有建置 CA，那就應該考慮採用外部機構所簽發的憑證了。
6. 使用安全性足夠的密碼
   在我們安裝 ESXi 的過程中，系統會強制我們設定一組密碼，而這組密碼是用來搭配預設的本機管理者 (root) 帳號。安裝完畢後，我們可以建立其他的本機帳號，用以管理此一主機。這些帳號的密碼必須提供足夠的安全性，以避免主機受到有心份子的惡意使用。除了建立本機帳號之外，我們也可以整合環境中現有的 AD 架構，達到統一管理帳號資訊的目的。
   當使用 VMware Server 時，帳號資訊將來自於安裝 VMware Server 的作業系統之內。如果我們希望統一透過 VMware Server 來進行虛擬環境的管理作業，就不需要在本機建立額外的帳號了。
7. 謹慎地使用授權機制
   ESXi 提供了相當彈性的授權機制，然而也因為彈性而造成設定上必須多加注意以避免開放過多的權限而造成安全危害。ESXi 的授權預設是具備繼承性的，也就是父物件的權限也會適用於子物件 (如果子物件沒有其他權限設定)。舉例來說，如果我開放資料中心 (Datacetner ) 的網路設定 (Network – Configure) 權限給 A 這個使用者，那麼 A 就可以設定這個資料中心下所有主機的網路。雖然我們可以取消這樣的繼承關係，但是這樣做卻可能造成不少額外的設定工作。好在 ESXi 另外提供一個叫做 No Access 的權限，透過 No Access 權限的使用，我們可以讓 A 無法設定特定主機的網路。總而言之，如何決定適當的物件層級並搭配 No Access 的使用，將是授權是否合適的關鍵。
   
   此外必須特別注意的是，當使用本機帳號直接連結主機時，權限是依附在本機帳號上。但是如果是透過 VMware Server 進行連結，那麼權限就是依附在 VMware Server 的帳號上。兩者設定的地方不同，甚至選項也不一樣。因此建議如果是採用 VMware Server 的環境，就應該限制使用者只能透過 VMware Server 進行管理，以避免權限管理的額外負擔。
8. 限制遠端登入本機 Shell 的權限 當我們在建立本機帳號時，有一個選項 (Grant shell access to this user) 可以決定是否允許此一帳號從遠端登入本機 Shell，這個選項預設的關閉的 (也就是不能從遠端登入本機 Shell)。除非有很明確的需求，並做好了相關的安全措施，否則請勿開啟這個權限。
   
9. 妥善地利用 Host Profile
   前面我提到有些主機的設定(應該說是大部分，如防火牆、syslog)  必須一台台加以進行，而這種作法將會遭遇到幾個問題，一個是設定上過於費時，另外一個則是很難確保所有主機的設定都符合政策要求。此外，如果採用自動佈署的方式來安裝主機，如何確保這些主機的設定也能自動符合要求更是一大困擾。別擔心，這些困擾都可以透過 Host Profile 機制來加以解決。透過 Host Profile 的建立，我們可以檢查主機是否符合 Host Profile 內的設定基準，甚至可以將 Host Profile 內的設定基準套用到主機之上。所以只要好好利用 Host Profile，我們就可以輕鬆管理主機的所有設定值。
10. 盡可能使用實體隔離的方式保護用以管理主機的網路介面
    雖然是處於虛擬化的環境，但是 ESXi 依舊必須透過實體的資源才能提供服務，而在這些資源中一個很重要的資源就是網路。前面提到 ESXi 內建防火牆的時候，我們知道 ESXi 把與主機溝通的封包跟與虛擬機溝通的封包做了不同的處理。這樣的作法雖然有其安全性，但是仍舊有所不足。
    在安裝 EXSi 時，不管系統上安裝了多少張實體網卡，系統都會要求並限制我們只能選取一張網路作為管理之用。當系統安裝完畢之後，我們可以利用 VMware Client 針對其他網卡進行管理功能的開放。如果主機上擁有足夠的實體網卡，最好能夠將管理與虛擬機使用的網卡區分開來，並連結至不同的交換器，以減少安全問題發生的機會。對於不打算開放管理功能的網卡，請記得不要設定 IP 位址。如果實體網卡的數量不夠，可以搭配 VLAN 的機制，將管理用的 VLAN 與虛擬機用的 VLAN 區隔開來。
    以一般主機常見的安裝兩張網卡來說，我們有兩種選擇。 第一種是一張網卡專門作為管理之用，另外一張網卡則作為虛擬機專用。第二種選擇則是兩張網卡同時提供管理與虛擬機使用。對此我個人傾向第二種的選擇，一則兩個管理用的網卡可以避免因為單一網卡故障而無法管理的困境，二則虛擬機通常也需要兩個以上的實體網路，以便有效區隔不同的流量。所以如果主機上只有兩張實體網卡，那就只好充分利用 VLAN 的功能了。
    不管採用哪種佈署方式，都別忘了防火牆等安全機制的必要性。
11. 保護你的虛擬交換器 雖然 ESXi  虛擬交換器的功能不似實體交換器那般強大，但是倒還是有一些安全選項可供設定。包含是否允許使用 Promiscuous Mode (預設拒絕)、MAC Address Changes (預設允許) 與 Forged Transmits (預設允許)。Promiscuous Mode 可以讓 Guest OS 看到此一 Port Group 與"外界"溝通的封包，而 MAC Address Changes 與 Forged Transmits 則限制了 Guest OS 使用自定 MAC Address 時是否可以正常的接收 (MAC Address Changes) 或傳送 (Forged Transmits) 封包。除非有特殊的需求，否則這些選項應該都設定為拒絕 (Reject)。
12. 監測你的虛擬環境 如果你的環境包含 VMware Server，那麼你就可以直接利用 VMware Server 進行相關的監測作業。VMware Server 提供許多詳細的資訊與圖表，可以讓管理者很方便的了解各項資源的使用狀況。充分利用這些圖表，我們可以即早發現可能出現的問題。
    除了這些圖表，我們也可以透過前述的 syslog、snmp daemon、以及接下來要談的 alarm 來協助我們監測整個虛擬環境。
13. 設定合適的告警 (alarm)
    雖然 VMWare Server 內建的資訊與圖表可以幫助我們在需要時了解虛擬環境的狀況，但是除非你沒別的事可以幹，不然絕對是不會沒事就盯著這些圖表的。而針對一些需要管理者特別注意的狀況 (例如記憶體使用量過高)，除了可以透過圖表被動的發現外，EXSi 還會主動對管理者進行提示。很可惜的是這些提示預設只顯示在 VMware Client 的介面上，也就是說除非你一直盯著 VMware 的管理介面，否則還是不會發現這些善意的提醒。因此我們必須將一些重要的告警設定為其他的通知方式 (如寄發 email、snmp trap 等)，好在問題發生的第一時間就能加以掌握。
14. 使用作業系統的磁碟加密功能 在大部分的情況下，虛擬機的硬碟其實是對應到所謂的 VMDK 檔案。在這個 (些) VMDK 檔案內，包含了 Guest OS 所有存放於硬碟內的資料。也就是說，在實體環境中偷取硬碟的困難工作，在虛擬環境中變成了只要複製 VMDK 檔案的簡單動作。除了複製檔案遠較實際偷取硬碟簡單外，非授權複製行為的發生也比硬碟失竊更難以被管理者所發現。我們可以採用作業系統內建的硬碟加密功能，以大大降低 VMDK 檔案不幸遺失時所造成資料外洩的可能性。現今大部分的作業系統都已經內建硬碟加密的功能，千萬不要吝於使用了。
15. 備份檔案也別忘了加密
    就像實體環境中的備份資料需要與原本資料同等的安全性要求，虛擬環境下的備份也是如此。因此我們可以採用加密的技術來保護這些備份的資料 (通常可能是 VMDK 的檔案)，以避免有心份子透過備份檔案取得重要的機密資料。加密除了可以避免有心份子對於資料的誤用，同時也可以避免有心份子竄改備份資料。此一保護措施對於那些沒有使用前述硬碟加密技術保護的 VMDK 檔案來說顯得格外重要。
16. 保護好你的 datastore ESXi 利用 datastore 來存放各式各樣的資料，包含虛擬機的檔案 (如 VMDK 與設定檔)、虛擬機所使用的光碟/軟碟映像檔、以及虛擬機的記憶體交換檔 (swap file)。因為 datastore 不只用來存放 VMDK 檔案，因此即使我們已經使用 Guest OS 的硬碟加密技術來保護其內的資料，對於 datastore 的保護依舊馬虎不得。這裡所謂的記憶體交換檔，指的並不是 Guest OS 內所使用的交換檔，而是 ESXi 為了因應無法利用實體記憶體來完全滿足虛擬機所設定的記憶體時的一種模擬技術。Guest OS 並不知道這些檔案的存在，而且這些檔案包含了存放於 Guest OS 記憶體內的資料。這種檔案預設與虛擬機其他檔案存放在同一個目錄之下，在保護上必須多加小心。
    至於如何保護 datastore，則根據 datastore 屬於 Local Disk、SAN 或 NFS 架構而在作法上有所不同。
17. 使用強化過的版型 (Template) 來建立新的虛擬機
    雖然我們可以在每次建立虛擬機的時候，透過傳統的方式重新安裝一套可供運行的 Guest OS，但這並不是很有效率的作法，比較建議的作法是利用已經存在的虛擬機來產生新的虛擬機。實際上常用的作法有二，一種是利用複製的功能，將虛擬機複製出一個新的虛擬機。另外一種則是利用版型 (Template) 的方式，利用版型創建出新的虛擬機。嚴格來說，版型與一般的虛擬機沒有什麼多大的差別，最大的不同之處在於我們無法開啟 (Power-On) 版型，所以可以有效避免無意間開機與修改動作的發生。這樣的特性讓管理者可以輕鬆地建立出各種 Guest OS 的基本安裝與設定，並加以妥善防護，以便在需要時可以快速建立出合乎企業安全需求規範的虛擬機與 Guest OS。
18. 修改 Guest OS 的設定
    除非是新建的虛擬機，否則不管是透過複製 (Clone)、匯入 (Import)，甚至是從樣板 (Template) 所建立的虛擬機，都繼承了原有虛擬機內 Guest OS 的全部設定。雖然在這些過程當中，有些設定可以改變，但是大部分的設定依舊必須進入 Guest OS 後才能加以修改。這些設定包含(但不局限於)：
• 主機名稱。
• 網路設定，尤其是 IP 位址。
• 主機對應檔 (hosts 檔)。
• 主機的防火牆設定。
• 存取限制 (/etc/hosts.deny 與 /etc/hosts.allow)。
• ssh daemon 的金鑰設定值。
• 個人的 ssh 設定，包含 known_hosts 與 authorized_keys。
19. 謹慎地佈署從別處取得的虛擬機檔案
    現今有些軟體是以虛擬機檔案的方式加以發佈，這種形式通常又稱之為 Virutal Appliance。在我們將這些 Virtual Appliance 實際佈署到我們的環境前，首先當然必須根據前述要點進行必須要的設定修改 (如果廠商沒有提供類似的安裝程序)。除此之外，我們也必須確保虛擬機所連結的虛擬交換器 Port Group 其安全設定符合標準。除非有特殊的考量，否則此 Port Group 的三個安全選項應該都設定為拒絕 (Reject)。甚至我們可以考慮將此虛擬機置於獨立的 Port Group，以減少發生問題的機會。
    
20. 關閉用不到的系統
    有一句話是這樣說的，鎖在保險箱並避免與外界有任何接觸的系統才是最安全的。在虛擬環境下，雖然我們沒有辦法把虛擬機鎖在保險箱之內，但是我們還是可以在系統不需使用時加以關閉。儘管這種作法也適用於實體的環境，但是在虛擬環境下我們不需要特別的設備就可以輕鬆地從任何地方完成開關機的動作。如果搭配腳本的使用，我們甚至可以做到系統使用前自動開機，並於使用完畢後加以關閉 (或暫停)。這種作法對於一些處理重要資料的系統而言，顯得格外有效。
21. 使用密碼保護開機韌體 (BIOS/EFI)
    在大部分的情況下，管理者可能不會意識到虛擬機內也有 BIOS 的存在。儘管如此，ESXi 確實在虛擬機內提供了 BIOS 的功能。除了提供 BIOS 的選項，ESXi 還提供新的開機韌體 EFI。不管使用哪種開機韌體，因為虛擬機並沒有實體的主控台 (Console)，只要連上主機或 VMware Server 就可以存取到對應的虛擬主控台，因此傳統上的實體保護措施並沒有辦法發揮效果。也因此在虛擬環境下，主控台的其他安全防護措施就顯得格外重要。其中一個最重要的步驟，就是利用密碼功能來保護開機韌體，以避免有心份子修改開機韌體的設定，造成非預期行為的發生。
    
22. 避免使用自動登入的功能
    同樣因為虛擬機使用了虛擬主控台，所以一旦 Guest OS 採用了開機自動登入的設定，任何連上主機或 VMware Server 的使用者都可能可以直接獲得系統的存取權限。
23. 使用完畢一定要記得登出系統
    理由同上。尤其是透過虛擬主控台登入系統時，更是千萬要記得在使用系統完畢後立即進行登出的動作。
24. 設定密碼保護的螢幕保護程式
    理由同上。此一措施應視為登出要求未被遵守時的補救措施，而非用來取代登出要求此一安全措施。
25. 嚴格限制帳號本機存取的權限 理由同上。
26. 關閉不需使用的外接設備 對虛擬機而言，大多數的外接設備都支援熱插拔的功能。即使是一般實體環境下大多不支援熱插拔功能的設備 (像是 IDE 光碟機、IDE 軟碟機、網卡等)，在虛擬環境下也都支援了熱插拔。正因為外接設備易於插拔，所以我們可以在不需使用這些外接設備時加以關閉，並於需要時重新連結即可。這些所謂的關閉，並非從 Guest OS 內加以移除或是停用，而是直接從虛擬機的設定加以關閉。這些被關閉的設備，在再次被開啟之前，都無法被 Guest OS 所使用。舉例來說，當我們不需使用到光碟機的時候，就可以關閉光碟機的連結，以避免有心份子讀取到非授權的資料。
27. 將虛擬環境的安全需求整合至原有的安全政策之內
    虛擬化前的安全政策，都應該繼續存在於虛擬化後的環境中。原因在於一般虛擬化並非 100% 的虛擬化，而是實體與虛擬共存，因此原有針對實體環境所設置的安全政策依舊有其存在的必要性。即使是 100% 虛擬化的環境，原有的安全政策也多必須予以保留。包含管理面、實體層次、作業系統層次、應用系統層次的安全政策，在虛擬環境下都還是會面臨到同樣的安全問題。舉例來說，在虛擬環境下備份整個 Guest OS 是件相當簡單且必要的事情，但是 Guest OS 的備份並不能用來取代傳統的備份機制。傳統的備份方式，可以讓我們在必要時快速找到所需的資料 (如某個檔案)，而這是 Guest OS 備份很難做到的事情。所以虛擬化之後應該是針對原有的安全政策做出相對應的新增與修正，以期達到一致性的安全水平。