Microsoft Forefront
使用 Microsoft Forefront TMG 2010 做為安全的 Web 閘道
Yuri Diogenes、 Jim Harrison 和 Mohit Saxena
當公司建立安全性原則時,金鑰的目標是讓員工更安全地瀏覽網際網路。 當然這泛指非常廣泛的區域,例如涵蓋一些需求:
- 請確定使用者遵守有關網際網路存取的公司原則。
- 檢查流量,並封鎖潛在的惡意程式碼與可疑的活動。
- 請注意檢查它們的 Web 流量的一般使用者。
幸運的是,利用安全的 Web 閘道功能在 Microsoft Forefront 威脅管理閘道 (TMG) 2010年可以幫助您達成這些目標。 圖 1 顯示主要的 Forefront TMG 2010 功能可以使用來實作安全的 Web 存取閘道:
圖 1 核心 Forefront TMG 2010 功能的安全 Web 閘道案例
您可以看到 Forefront TMG 會使用三個主要的定域機組元件:Microsoft 更新、 Telemetry 服務和 Microsoft 信譽服務 (MRS)。 Microsoft Update 會保持反惡意程式碼和更新的網路檢查系統 (NIS) 簽章。 Microsoft 惡意軟體回應小組會使用所提供的 TMG telemetry 報表學習看到什麼攻擊,並因此增強簽章品質。 MRS 維護龐大的分類的 URL Forefront TMG 2010 可以查詢資料庫。
本文中我們重點 URL 篩選和 HTTPS 檢查。 我們涵蓋深入我們先前 TechNet 雜誌二月 2009年文,惡意程式碼檢查,並且 「 功能 hasn’t Forefront TMG 2010 中變更。
使用 URL 篩選更安全的瀏覽經驗
URL 篩選可視為 Forefront TMG 第一行的防禦來協助保護您的組織 ’s Web 存取安全。 利用 URL 篩選區塊的要求不想要的網站的 Forefront TMG 可以花費較少惡意程式碼和更多的時間將很有用的內容傳送掃描的時間。
URL 篩選組成兩個主要部份 — 評估 Web 要求,以及提供從其篩選條件將決定如何被分類為要求的類別定義的 MRS 網頁 Proxy 篩選器。 這裡 ’s 一簡化的程序發生在 Web 要求的格式:
Web 應用程式會傳送 「 http://malware.contoso.com/nefarious 」 透過 TMG 的要求。
網頁 Proxy 篩選器會傳遞透過 URL 篩選要求。
URL 篩選將整個要求分割成不同的部份。 我們的範例部分會是類似:
- Com
- Contoso.com
- Malware.contoso.com
- Malware.contoso.com/nefarious
URL 篩選會尋找到本機的 URL 類別快取每個部分。
請注意: 如果要求無法對應到本機快取區中的 URL 類別,URL 篩選查詢 MRS。 如果 MRS 傳回 「 未知 」,或者 can’t 連絡 MRS,URL 篩選傳回 「 未知 」 的回應到網頁 Proxy 篩選。
一旦 URL 篩選知道每個 URL 部分相關聯類別,它會決定將會套用到整個 URL 的分類。 若要執行此動作 TMG 會使用 MRS 讓 TMG 知道哪些類別會優先於其他人所提供的預先定義的優先順序清單。 舉例而言:
- Com = 未知
- Contoso.com = 一般商務
- Malware.contoso.com = 惡意
- Malware.contoso.com/nefarious = 未知 在這個範例被識別兩種類別:一般商務和惡意。 根據預先定義的優先順序清單,惡意的優先順序高於一般商務 ; 整個 URL 指定為惡意的結果。
如果產生的 URL 類別集符合拒絕規則,拒絕該要求,並且錯誤回應傳回至 Web 應用程式。
如果 [URL] 類別 doesn’t 符合拒絕規則,並不會符合允許規則,要求是根據相符的規則 ’s 剩餘準則來提供服務。
如果要求失敗,比對任何使用者建立拒絕或允許規則,TMG 規則處理落於透過預設的拒絕規則,並傳回至 Web 應用程式拒絕回應。
因為使用者通常會在他們的 Web 使用方式以統計方式 habitual,URL 類別快取將會變成更符合您的組織,經過一段時間 Forefront TMG 處理使用者要求。 如此一來最後會減少 MRS 查詢使用者要求的比率。 因為 URL 分類都可能會改變,MRS 會指派一個時間存活的每個項目。 像這類 MRS 要求的數目會永遠不會完全達到零,即使您的使用者永遠移至相同的站台。
為充分了解如何篩選的運作方式的 URL 您必須也瞭解 Web 應用程式建立連線和發出要求的方式。 Web 應用程式通常可分為兩類:設定成要做為 Web Proxy 用戶端以及的 aren’t。
- (CERN) 的 Web Proxy: 這種類型的 Web 應用程式設定為讓任何的 Web Proxy 知道而且能夠適當地運作。 Web 應用程式會連接至 Web Proxy 接聽項和問題的要求,在特定的表單:
HTTP:
METHOD http://website.contoso.com/path/page.aspx?querystring HTTP/1.x
METHOD http://1.2.3.4/path/page.aspx?querystring HTTP/1.x
在這種情況下 Forefront TMG 從而 URL 篩選,會有可用的 URL 篩選資料庫與比較完整的 URL。
請注意: 方法可能是任何有效的 HTTP 方法,例如 GET,張貼等等。
HTTPS:
CONNECT website.contoso.com:443 HTTP/1.x
CONNECT 1.2.3.4:666 HTTP/1.x
這些要求的 Forefront TMG 和 URL 篩選有只有主機名稱或 IP 位址 (取決於如何用戶端發出要求) 及比較與 URL 篩選資料庫的連接埠]。
- 非 Web Proxy: 做為 CERN Proxy 用戶端未設定 Web 應用程式時, 它會嘗試的 Web 站台的名稱解析為 IP 位址,如果這成功將嘗試連線到使用任何連接埠已原始 URL 的一部分該 IP 位址。 無論用戶端是 (之前稱為防火牆用戶端) 的 TMG 用戶端] 或 [SecureNET 用戶端 (aka SecureNAT 用戶端),將使用下列形式會傳送要求:
METHOD /path/page.aspx?querystring HTTP/1.x
此案例中篩選來評估要求能力是 URL 的取決於兩個準則:
- 連線導向預設 HTTP 連接埠吗? 如果是這樣,Web Proxy 可能可以攔截這個要求,並將它傳遞至 URL 篩選進行比較。 如果不,要求將不會看到 URL 篩選以及因此無法比較到資料庫。
- 如果連線導向在預設的 HTTPS 連接埠,HTTPS 視察啟用嗎? 如果是這樣,HTTPS 視察可以橋接此連線,而且 URL 篩選的比較資料庫要求的機會。
什麼不似乎是顯而易見的事情是該 URL 篩選中,其本身的不提供任何形式的封鎖機制 — 它只是回應 Web Proxy 與為 Web Proxy 要求的 URL 相關聯的類別 (以及因此 URL 篩選) 能夠了解它。 在所有情況下 URL 篩選收到用戶端要求時它當做圖解 的 圖 2 中。
圖 2 的 基本流程的 URL 篩選
如果 Forefront TMG 需要查詢 MRS,使用單一的 Web 服務呼叫至 MRS Web 服務的入口網站提出要求。 MRS 處理 Forefront TMG 呈現資料,並使用目前套用至資料 MRS 接收到的 URL 類別會回應。 Forefront TMG 2010 有作用中包含了入口的目的地時 Forefront TMG 出貨 (請參閱 的 圖 3) 的預先定義的網域組。
圖 3 的 MRS 網域設定
如果 「 拒絕 」 規則中找不到由 URL 篩選傳回的 URL 類別,Forefront TMG 會傳送拒絕回應 (HTTP 結果-碼 502) 給用戶端。 根據用戶端是否在瀏覽器或其他 Web 應用程式,使用者可能會看到 Forefront TMG 回應頁面 ; 用非瀏覽器應用程式 (如 Windows Media Player或 CERN Proxy FTP 應用程式) 中的情況下使用者可能只看到來自應用程式本身的錯誤訊息]。
因為最昂貴的任務 Forefront TMG 有執行,才能判斷 URL 分類來查詢 MRS,此處理程序是在 CPU 方面更便宜,他們要求記憶體和網路的資源,比在允許使用者到達網頁] 網站,然後不必以執行惡意程式碼上的所有內容的都掃描。
控制透過加密通道,使用 HTTPS 視察
使用者已被告知許多年進行安全的線上交易他們必須使用 HTTP 和 SSL (HTTPS)。 不過,此安全通道也已經使用惡意用途。 當使用者啟動的交易時使用 HTTPS 流量通常加密的端到端 (從使用者到目的伺服器),正在之間交換任何裝置無法讀取它們之間的內容。 雖然這是理想的行為,因為您 don’t 希望任何人查看您的線上信用卡發卡交易,其缺點是任何惡意的作業,在這個頻道 can’t 被評估。 圖 4 會反白顯示這項作業使用 ISA Server 2006 防火牆作為主要組的件。
圖 4 的 繁體 HTTPS 分析藍本
圖 4 說明完整的 Proxy 案例,用戶端正在存取 HTTPS 站台。 此處所述,彙總的步驟會劃分在兩個主要階段:
階段 1 – SSL 通道
- 用戶端連線到網頁 Proxy。
- 用戶端發出的 SSL 通道要求:CONNECT malicious.contoso.com:443 HTTP/1.1。
- Web Proxy 會解析成 IP 位址 1.2.3.4 malicious.contoso.com。
- 網頁 Proxy 連線到 TCP 連接埠 443 上 1.2.3.4。
- 網頁 Proxy 傳送 「 200 確定 」 給用戶端。
階段 2 – 加密對話
- 用戶端和 Web 伺服器交換 SSL 信號交換訊息、 加密金鑰和憑證。
- 用戶端現在有一個加密的通道端到端與目的伺服器,它會啟動傳送和接收的流量,透過這個通道。
- ISA Server 會保留該通道用戶端和伺服器之間開啟,但它不會檢查流量,因為它 doesn’t 有這項功能。
在此案例中潛在的風險是作為第二階段的邊緣防火牆有不知道什麼真的傳輸該通道上。 其中攔截目的地伺服器的案例和插入惡意程式碼中有 ’s 目的地伺服器會傳送透過用戶端會收到沒有 hesitation 因為透過所謂受信任的連線是來自此加密通道的惡意軟體的潛在風險。
Forefront TMG HTTPS 檢查降低這項威脅檢查流量和與使用者和伺服器維護個別加密的通道。 圖 5 顯示 Forefront TMG 如何完成的。
圖 5 的 動作] 中的 HTTPS 檢查
彙總的步驟仍分割在兩個主要階段 ; 不過,處理程序現在包含檢查:
階段 1 – 用戶端要求
- 用戶端連線到 TMG 網頁 Proxy 接聽程式。
- 用戶端發出的 SSL 通道要求:CONNECT malicious.contoso.com:443 HTTP/1.1。
- TMG 會解析成 IP 位址 1.2.3.4 malicious.contoso.com。
- TMG 連接到 TCP 連接埠 443 上 1.2.3.4。
- TMG 交涉,與伺服器的 SSL 連線,並評估該憑證。
- 如果憑證是有效而且信任,TMG 會回應 「 200 確定 」 給用戶端。
階段 2 – 檢查加密交談
用戶端和 TMG 交換 SSL 信號交換訊息、 加密金鑰和憑證。 請注意因為 TMG 建置使用衍生自 Web 伺服器憑證的資訊的伺服器憑證,用戶端認為它與 Web 伺服器通訊。
用戶端現在擁有與 Forefront TMG 一個加密的通道,Forefront TMG 有與目的地伺服器的加密的通道。 Forefront TMG 將可以檢查用戶端和伺服器之間傳送藉由遵循此序列的所有流量:
a) TMG 接收並解密加密的流量從目的地伺服器。
b) TMG 將惡意程式碼檢查和 NIS 篩選器套用於資料傳輸。
c) 如果惡意程式碼和 NIS 篩選器允許 TMG 會加密結果,並將它傳送到用戶端工作站。
d) 用戶端會接收、 解密和處理之傳輸作業。
若要與用戶端建立 SSL 信號交換,Forefront TMG 需要伺服器憑證。 若要建立它,Forefront TMG 會建立詐騙的証照原來的伺服器憑證資料,並使用 HTTPS 檢查 CA 憑證簽署。 為了最大效能 Forefront TMG 會維護重複的伺服器憑證的快取。 TMG 會搜尋本機快取中的重複的伺服器憑證,如果沒有,它將重複的上游伺服器憑證,並將其置於快取。 快取儲存只在記憶體中。 因此,詐騙憑證快取是空的之後重新啟動防火牆服務。
請注意: 快取 (憑證的數量) 的大小是由 LowLevelSettings.ClonedCertificatesCacheSize COM 屬性所控制。
HTTPS 檢查選項
設定 HTTPS 視察前, 請先務必瞭解完整的功能集和由這項功能所組成的選項。 圖 6 顯示區域可以設定 HTTPS 檢查。
圖 6 HTTPS 檢查功能集
在規劃 HTTPS 視察實作時您必須先考慮憑證設定的決定是否將使用自我簽署的憑證或內部 CA 所核發的憑證。 當匯入現有的受信任的憑證授權單位,您需要包含的授權連同其私密金鑰的憑證的 PFX 檔案。 您需要這個私密金鑰才能簽署 TMG 所發出的詐騙憑證。 您也必須確定憑證 ’s 金鑰使用方式設定給憑證簽署。 這個 CA 憑證必須再部署用戶端電腦 (位於 「 信任的根憑證授權 」 本機電腦憑證存放區的) 上 ; 否則用戶端 won’t 信任伺服器收到 TMG 憑證。
上 Forefront TMG HTTPS 視察可啟用透過 Web 存取規則。 請依照下列步驟啟用這項功能:
- 從 Forefront TMG] 主控台按一下 [Web 存取原則,並選取 [工作] 窗格上的 [Web 保護任務] 下設定 HTTPS 檢查]。
- 在 [一般] 索引標籤上的 HTTPS 輸出檢查螢幕,選取啟用 HTTPS 視察核取方塊 的 圖 7 所示。
圖 7 的 啟用 HTTPS 視察
為使本範例中,我們使用 Forefront TMG 自我簽署的憑證。 按一下 [產生及網頁 會出現類似 圖 8。
圖 8 產生憑證視窗
- 產生的憑證] 頁面上填入發照者名稱]、 [到期日] 及 [發行者陳述式,根據到您的公司需求,再按一下 [立即產生憑證。
- 將產生新的憑證,且 [憑證] 頁面會跳出。 確認憑證組態,然後按一下 [關閉]。
- 按一下 [確定] 關閉視窗。
- HTTPS 輸出檢查] 視窗上按一下 [HTTPS 檢查受信任根 CA 憑證選項] 按鈕。 的 圖 9 所示,就會出現憑證部署選項] 視窗。
圖 9 選擇如何部署 [憑證
- 「 自動透過 Active Directory 」 如果 TMG 所屬網域,則建議的部署方法。當您選擇這個選項時,TMG CA 憑證將會自動部署到用戶端電腦使用 「 群組原則。 按一下 [網域系統管理員認證] 按鈕,然後輸入用於這個作業的認證。 «\u246 o¤@¤U [½T©w]¡C 請注意您不應該包含網域中使用者名稱欄位。
- 因為 Forefront TMG 者使用 certutil 工具來將 TMG CA 憑證發佈到 Active Directory,您可能會注意到簡短的命令提示字元視窗。 在 「 自動憑證部署成功 」 訊息方塊,並將憑證部署選項] 視窗上的 [確定] 中按一下 [確定]。
- 按一下 [確定] 即可完成。
重點: 除了滿足貴公司 ’s 安全性原則,您也需要啟用 HTTPS 視察前評估任何法律及法規遵循法規。 其中 HTTPS 視察被視為不適合任何站台可加入至例外狀況清單。
增強的使用者經驗
HTTPS 檢查和 URL 篩選中 Forefront TMG 不僅協助提供一個受保護的瀏覽的環境對一般使用者、 它們也包含增強一般使用者經驗,透過告知性訊息的功能以及藉由提供自訂或精確的錯誤訊息一般使用者可以直接關聯到。
HTTPS 用戶端通知
若要保持與公司的隱私權原則規定,您可以開啟的 SSL 網站被檢查,並提供選項以保護他 deems 個人或機密的資訊保持站台,讓他時警示使用者的用戶端通知。 圖 10 說明這個行為。
圖 10 的 HTTPS 檢查用戶端通知
使用者收到 HTTPS 視察通知用戶端電腦必須安裝,Forefront TMG 用戶端,而且它必須具有 HTTPS 檢查受信任的根憑證授權安裝在本機電腦信任的根憑證授權憑證存放。 請記住是否您上游和下游 TMG 組態 HTTPS 通知必須在下游 Proxy,而非上游 Proxy 上啟用。
若要實作 HTTPS 檢查用戶端通知,您必須啟用它 Forefront TMG 伺服器和用戶端上。 若要啟用伺服器上的 HTTPS 視察通知:
- Forefront TMG 管理] 主控台中按一下 [Web 存取原則]。
- 在右窗格中的工作下的 [設定 HTTPS 檢查。
- 在用戶端通知] 索引標籤上按一下 [通知使用者會被檢查 HTTPS 內容,],然後再按一下 [確定]。
若要啟用通知 Forefront TMG 用戶端上:
- 在系統匣中的 [Forefront TMG 用戶端] 圖示上按一下滑鼠右鍵,按一下 [設定]。
- 在 [安全的連線檢查] 索引標籤上檢查傳送到安全的 Web 網站的內容時,請選取通知我],然後按一下 [確定]。
URL 篩選錯誤訊息
系統管理員可以允許或拒絕使用者根據 URL 類別 Web 的存取。 如果使用者嘗試移至已拒絕的網站,她會收到錯誤頁面,如 圖 11 中, 顯示站台存取被拒因為它已被因此依分類 Forefront TMG 系統管理員。
圖 11 拒絕存取 」 的網頁
可以 TMG 系統管理員可以自訂錯誤訊息。 做法如下:
- 開啟 Forefront TMG 管理主控台,並按一下 [Web 存取原則。
- 連按兩下以開啟來允許或拒絕存取管理員所建立的規則。
- 按一下在 [動作] 索引標籤上,如 所示 圖 12
圖 12 自訂篩選錯誤訊息的 URL
您可以加入顯示拒絕通知至使用者的文字方塊中的任何自訂的訊息。 只要在 HTML 的 HTML < 主體 > 項目內容中有效,但是 can’t 包括任何指令碼,您甚至可以使用 HTML 內容。
您也可以選擇顯示的類別在其下站台存取被拒。 如果要執行這項操作,按一下核取方塊為拒絕要求通知類別的新增。 這會特別有用,如果讓一般使用者可以讓您知道不正確地分類站台。 您,依序可以傳送此玩家意見給 Microsoft 透過 telemetry 和設定覆寫類別,以修正分類,直到它固定的同時。
如果您想要變更整個 URL 篩選錯誤訊息網頁的外觀和感覺,需要編輯 12232.htm HTML 網頁。 您找到有關這在的 Forefront TMG (ISA Server) 產品團隊部落格Forefront TMG 2010 上拒絕版面自訂 頁面的資訊。
Jim Harrison 結合成為 QFE 軟體測試人員的 ISA Server 保持工程小組在 2003 年一月。 他現在是 Forefront Edge CS 和 avid 的 ISA 伺服器 supporter 與系統實作器的程式管理員,以及稱為 「 故事 「 邊緣 」 的 Forefront 社群分頁的 coauthor
**Yuri Diogenes *** *Microsoft 為資深安全性的運作方式支援 ISA Server/IAG 小組上的重大問題工程師。 Diogenes 是稱為 「 故事 「 邊緣 」 的 Forefront 社群分頁的 coauthor
**Mohit Saxena *** *是,Microsoft ISA Server 支援小組,一群支援的技術指導人員,在符號運作與客戶的擴大工程師修正問題、 Bug 和設計變更要求。