保護應用服務器的安全

時間 2019-11-07

原文原文鏈接

備註：Microsoft技術資源庫很不錯的，左邊還有不少解決方案以及教程能夠學習，慢慢欣賞吧~html

本單元概要前端

中間層應用程序服務器最經常使用的用途是宿主業務邏輯和數據訪問服務。這一功能一般打包在企業服務應用程序中，或者經過使用中間層 Web 服務或 Microsoft® .NET Framework 遠程處理技術向前端 Web 服務器公開。web

本單元將分別討論這些技術，說明在各類狀況下如何保護應用程序服務器的安全。集中討論將 Web 服務器和應用程序服務器，以及將應用程序服務器與數據庫服務器鏈接的相關通訊信道。數據庫

在深刻討論與具體技術相關的配置以前，本單元將首先討論針對應用程序服務器的主要威脅。這些威脅與適用於面對 Internet 的 Web 服務器的威脅有所不一樣，由於中間層應用程序服務器與直接的 Internet 訪問是（或者說應該是）隔離開來的。編程

返回頁首
windows

目標

使用本單元能夠：api

保護到應用程序服務器的通訊信道。安全
保護中間層應用程序服務器上的 Web 服務、企業服務和遠程處理解決方案。服務器
配置內部防火牆，將 Web 服務器與應用程序服務器分隔開來。網絡
管理 RPC 動態端口的分配。
安全地使用 .NET 遠程管理。
鎖定企業服務應用程序。
瞭解哪些對策可以應對常見的應用程序服務器威脅，包括網絡偵聽、未受權訪問、病毒、特洛伊木馬和蠕蟲。

返回頁首

適用範圍

本單元適用於下列產品和技術：

Microsoft® Windows® Server 2000 和 Windows Server™ 2003 操做系統
Microsoft .NET Framework 1.1 和 ASP.NET 1.1
Microsoft SQL Server™

返回頁首

如何使用本單元

要從本單元受益最多：

請閱讀「威脅與對策」單元。它能使您更好地理解 Web 應用程序所面臨的潛在威脅。
使用其餘配套的「保護……」單元。本單元是安全解決方案的一部分，此解決方案還包括多個單元，涵蓋了主機（操做系統）和網絡層的安全。除本單元以外還能夠結合使用如下單元：

「保護網絡的安全」
「保護 Web 服務器的安全」
「保護數據庫服務器」

本頁內容

本單元概要
 目標
 適用範圍
 如何使用本單元
 概述
 威脅與對策
 方法
 通訊信道注意事項
 防火牆注意事項
 .NET遠程管理安全注意事項
 企業服務 (COM+) 安全注意事項
 小結
 其餘資源

返回頁首

概述

爲了保護應用程序服務器的安全，必須在基礎操做系統和 Internet 信息服務 (IIS) Web 服務器（若是已經安裝）已經鎖定的前提下應用增量安全配置。

圖 1 顯式了本單元的重點，包括配置許多多層部署模型中都具有的內部防火牆。

圖 1. 遠程應用程序服務器部署模型

返回頁首

威脅與對策

許多針對應用程序服務器的威脅都來自單位的內部，由於應用程序服務器應該與 Internet 訪問相隔離。應用程序服務器的主要威脅有：

網絡偵聽
未受權訪問
病毒、特洛伊木馬和蠕蟲

圖 2 顯示了應用程序服務器的主要威脅。

圖 2. 應用程序服務器相關的主要威脅和漏洞

網絡偵聽

攻擊者使用網絡監控軟件能夠偵遵從 Web 服務器傳遞到應用程序服務器以及從應用程序服務器傳遞到下游系統和數據庫服務器的數據。攻擊者能夠查看甚至可能修改這些數據。

漏洞

可能使應用程序服務器受到網絡偵聽攻擊的漏洞包括：

應用程序以明文傳遞敏感數據
對數據庫使用 Microsoft SQL Server 身份驗證，生成明文憑據
缺少傳輸層或者應用程序層加密
不安全的網絡－硬件管理界面
使用 .NET 遠程管理TCP 信道鏈接遠程組件

攻擊

攻擊者在網絡上安裝數據包嗅探工具以捕捉流量。

對策

防止數據包嗅探的對策包括如下幾種：

使用安全的身份驗證（好比 Windows 身份驗證），它不會跨網絡發送密碼。
加密 SQL Server 身份驗證憑據。若是使用 SQL Server 身份驗證，您能夠經過在數據庫服務器上安裝服務器證書自動地加密憑據。
保護通訊信道。選項包括使用安全套接字層 (SSL) 或者 Internet 協議安全 (IPSec)。
對企業服務應用程序使用遠程過程調用 (RPC) 加密。
使用分段網絡，將偵聽與可能存在問題的網段隔離開來。
在 .NET遠程管理使用 HttpChannel 和 SSL。

未受權訪問

若是您沒法在外圍防火牆阻塞應用程序服務器上運行的應用程序所使用的端口，外部攻擊者就可以直接與應用程序服務器通訊。若是您容許計算機而不是前端 Web 服務器與應用程序服務器鏈接，對應用程序服務器的攻擊面將會增長。

漏洞

可能致使未受權訪問的漏洞包括：

脆弱的外圍網絡和防火牆配置
內部防火牆中打開的端口過多
缺少限制主機鏈接的 IPSec 策略
沒必要要的活動服務
沒必要要的協議
脆弱的賬號和密碼策略

攻擊

常見的可以得到未受權訪問的攻擊包括：

檢測偵聽服務的端口掃描
泄漏可用服務以及可能的軟件版本的標誌攫取
惡意的應用程序輸入
對密碼脆弱的默認賬號的密碼攻擊

對策

防止未受權訪問的對策包括：

防火牆策略阻止除來自指望的通訊端口以外的全部流量
TCP/IP 篩選或者 IPSec 策略防止未受權主機創建鏈接
禁用未用服務
靜態 DCOM 終結點映射只容許訪問已受權的主機

病毒、蠕蟲和特洛伊木馬

這些攻擊一般只有惡意程序開始消耗系統資源時才被注意到，它們會減慢或者暫停其餘應用程序的執行。宿主 IIS 的應用程序服務器很容易受到 IIS 攻擊。

漏洞

未安裝修補程序的服務器
運行沒必要要的服務
沒必要要的 ISAPI 篩選器和 ISAPI 擴展

對策

有助於減輕病毒、特洛伊木馬和蠕蟲所形成的風險的對策包括：

儘快應用最新的軟件修補程序
禁用未用的功能，好比未用的 ISAPI 篩選器和擴展
以最低特權賬號運行進程，以減小出現安全事故時形成的危害範圍

返回頁首

方法

經過保護到應用程序服務器的通訊信道，防止除受權 Web 服務器以外的任何主機訪問應用程序服務器，攻擊者將被限制爲只能利用 Web 應用程序設計和開發中出現的漏洞實施應用程序層攻擊。

爲了減輕這種風險，開發人員必須應用本指導第二部分和第三部分中敘述的安全設計和開發方法。

本單元中的配置解決方案是專門針對應用程序服務器的，它們不該該孤立地使用。應該將它們與「保護網絡的安全」、「保護 Web 服務器的安全」和「保護數據庫服務器」單元中提出的解決方案一塊兒應用。

返回頁首

通訊信道注意事項

發送到應用程序服務器以及從其接收的敏感應用程序數據和身份驗證憑據應該進行加密，以提供私密性和完整性。這將減小與偵聽和篡改相關的風險。

加密網絡流量可以解決網絡偵聽和篡改威脅。若是您認爲這種威脅在環境中無足輕重（例如，由於應用程序位於一個封閉的和物理上很是安全的網絡中），那麼可能無需加密流量。若是存在網絡偵聽問題，則可使用 SSL，它在應用程序層提供了一個安全的通訊信道，或者使用 IPSec，它提供了一種傳輸級解決方案。IPSec 可以加密在兩個服務器之間傳遞的全部 IP 流量，而 SSL 則容許全部應用程序選擇是否提供加密通訊信道。

企業服務

企業服務（即 COM+）應用程序使用 RPC 之上的 DCOM 跨網絡進行通訊。RPC 使用端口 135，後者提供了終結點映射服務，容許客戶端就參數進行協商，其中包括通訊端口，它在默認狀況下是動態指派的。

企業服務信道的保護方式有兩種：

RPC 加密
您能夠配置一個企業服務應用程序以使用 RPC 數據包私密性身份驗證。除了身份驗證以外，這還能爲發送到企業服務應用程序和從企業服務應用程序接收的全部數據包提供加密。
IPSec
您可使用 IPSec 策略在 Web 服務器和應用程序服務器之間加密通訊信道。

.NET 遠程管理

應用程序使用 .NET遠程管理有兩種可能的實現模型：

端口 80 上的 HTTP 信道
這種模型使用 ASP.NET 做爲宿主服務。
任何端口上的 TCP 信道
在此模型中，應用程序宿主在自定義的可執行文件（一般是一個 Windows 服務）中。

根據應用程序的性能和安全要求，您可使用以上兩種方法中的一種保護遠程處理信道。

使用 SSL 和 HttpChannel
若是您宿主在 ASP.NET 中，能夠利用 IIS 提供的內置 HTTPS 功能。HTTPS 提供了身份驗證和安全的數據通訊。
使用 IPSec 和 TCPChannel。
在 TCP 信道中，您可使用 IPSec 策略爲全部 IP 數據提供傳輸層加密。請注意若是您使用 TCP 信道，就必須提供本身的身份驗證機制。有關更多信息，請參閱「構建安全的遠程組件」單元。

Web 服務

Web 服務是由 ASP.NET 和 IIS 宿主的，服務使用 HTTP 協議進行跨網絡通訊。

SSL 或者 IPSec 可以用來保護通訊信道。此外，也能夠經過加密消息負載或者負載的敏感部分在應用程序層進行加密。爲了使用開放標準作到這一點，應該使用針對 Web 服務的 Web Services Enhancements (WSE) 。有關更多信息，請參閱「構建安全的 Web 服務」單元。

SQL Server

應用程序服務器默認狀況下經過 TCP端口 1433 與 SQL Server 通訊。除非進行了其餘配置，不然還須要使用用 UDP端口 1434 進行協商。

爲了保護從應用程序服務器到 SQL Server 的信道，應該使用 IPSec 或者 SSL。使用 SSL 時，須要在數據庫服務器上安裝服務器證書。

有關在 SQL Server 上使用 SSL 的更多信息，請參閱 Microsoft 知識庫文章 276553，「如何：經過證書服務器爲 SQL Server 2000 啓用 SSL 加密」。

返回頁首

防火牆注意事項

安全基礎結構中可能在應用程序服務器的兩端都包括內部防火牆。本部分討論了爲支持應用程序的各類功能而在這些防火牆上打開的端口。

企業服務

若是您使用中間層企業服務，應該配置一個內部防火牆，將 Web 服務器和應用程序服務器隔離，以容許 DCOM 和 RPC 流量。此外，若是您使用企業服務，應用程序常常會用到分佈式事務和分佈式事務協調程序 (DTC) 的服務。在此時，應該打開將應用程序服務器與遠程資源管理器（好比數據庫服務器）隔離開的任何防火牆上的 DTC 端口。圖 3 顯示了典型的企業服務端口配置。

圖 3. 典型的企業服務防火牆端口配置

×¢ 圖 3 沒有顯示在客戶端和企業服務應用程序之間，以及可能在企業服務應用程序和數據庫服務器之間的身份驗證機制必需的附加端口。一般，對於不使用 Active Directory 的網絡，Windows 身份驗證必需 TCP 端口 139 。有關端口需求的更多信息，請參閱 TechNet 文章「TCP 和 UDP 端口指派」，網址爲：http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/tcpip/part4/tcpappc.asp ，以及「管理機構的安全注意事項」，網址爲：http://www.microsoft.com/technet/security/bestprac/bpent/sec2/seconaa.asp 。

默認狀況下，DCOM 使用 RPC 動態端口分配，隨機選擇大於 1024 的端口號。此外，RPC 終結點映射服務使用端口 135。

限制內部防火牆上支持 DCOM 所需的端口有兩種方式：

定義端口範圍。
這種方式容許您控制 RPC 動態分配的端口。有關動態端口限制的更多信息，請參閱 Microsoft 知識庫文章 300083，「如何：限制 Windows 2000 和 Windows XP 上的 TCP/IP端口」。
使用靜態終結點映射。
Microsoft Windows 2000 SP3（或者 QFE 18.1 和更高版本）或者 Windows Server 2003 容許您配置企業服務應用程序以使用靜態終結點。靜態終結點映射意味着您只須要打開防火牆中的兩個端口：端口 135 用於 RPC，以及一個命名端口用於企業服務應用程序。
有關靜態終結點映射的更多信息，請參閱 Microsoft 知識庫文章 312960，「沒法設置 COM+ 應用程序的固定終結點」。

Web 服務

若是沒法打開內部防火牆的端口，您能夠在應用程序服務器上的服務組件前引入一個 Web 服務外觀層。這意味着您只需爲 HTTP 流量（說得具體一些，也就是 SOAP 消息）打開端口 80 以進行雙向傳輸。

這種方法不容許您從客戶端到服務器傳輸事務上下文，雖然許多狀況下，部署體系結構中包括一箇中間層應用程序服務器，那樣的話，在應用程序服務器上的遠程服務組件中啓動事務比較合適。

有關服務代理和服務接口（好比 Web 服務外觀層）物理部署需求的信息，請參閱「物理部署和操做需求」，在 MSDN 文章「.NET 應用程序結構：設計應用程序和服務」中的參考部分裏，網址是： http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/distapp.asp 。

DTC 需求

若是應用程序使用 COM+ 分佈式事務，並且是跨越被內部防火牆分隔的遠程服務器來使用的，那麼防火牆必須打開必要的端口以支持 DTC 流量。DTC 使用 RPC 動態端口分配。除了用於 RPC 的端口 135 以外，DTC 通訊還至少要求一個額外的端口。

若是部署體系結構中包括一個遠程應用程序層，企業服務應用程序中的事務一般從這裏啓動，並傳播到數據庫服務器中。若是沒有應用程序服務器，Web 服務器上的企業服務應用程序將啓動事務並將其傳播到 SQL Server 資源管理器。

有關配置防火牆以支持 DTC 流量的信息，請參閱：

COM+ 平臺 SDK 中的「DTC 安全注意事項」，網址是： http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cossdk/htm/pgdtc_admin_9dkj.asp
Microsoft 知識庫文章 250367，「信息：」配置 Microsoft 分佈式事務協調程序 (DTC) 以透過防火牆工做」。
Microsoft 知識庫文章 306843，「如何：解決 MS DTC 防火牆疑難問題。」

.NET 遠程管理

若是您使用 HTTP 信道並在 ASP.NET 中宿主遠程組件，只能在內部防火牆上打開端口 80 以容許 HTTP 流量經過。若是您的應用程序還要使用 SSL，則應該打開端口 443。

若是您使用 TCP 信道並宿主在 Windows 服務中，須要打開特定的 TCP端口或者遠程處理應用程序已經配置使用的端口。應用程序可能須要另外一個端口以支持回調。

圖 4 顯示了一個典型的 .NET 沿程管理防火牆端口配置。請注意所顯示的端口號對應的是使用 TCP 信道的狀況（5555 和 5557），這只是爲了說明的方便。實際的端口號是在客戶端和服務器機器上的 web.config 配置文件中指定的。有關更多信息，請參閱「構建安全的遠程組件」單元。

圖 4. HTTP 信道和TCP 信道狀況下典型的遠程處理防火牆端口配置

Web 服務

Web 服務使用 HTTP 之上的 SOAP 進行通訊，所以只需在內部防火牆上打開端口 80 便可。

SQL Server

若是防火牆將應用程序服務器與數據庫服務器分隔開來，那麼經過防火牆與 SQL Server 鏈接，要求您使用 SQL Server 客戶端網絡實用工具配置客戶端，而且使用服務器網絡實用工具來配置數據庫服務器。默認狀況下，SQL Server 偵聽 TCP端口 1433，固然這種狀況也會變化。必須在防火牆上打開所選擇的端口。

根據所選擇的 SQL Server 身份驗證模式和應用程序使用的分佈式事務，還可能須要在防火牆上打開幾個其餘端口：

若是您的應用程序使用 Windows 身份驗證與 SQL Server 鏈接，應該打開必要的端口以支持 Kerberos 協議或者 NTLM 身份驗證。
若是應用程序使用分佈式事務，例如自動化 COM+ 事務，須要將防火牆配置爲容許 DTC 流量以在不一樣的 DTC 實例之間以及 DTC 與資源管理器（好比 SQL Server）之間傳遞。

有關 SQL Server 端口需求的更多信息，請參閱「保護數據庫服務器」單元。

返回頁首

.NET遠程管理安全注意事項

.NET遠程管理基礎結構使同一臺機器上的應用程序或者網絡中不一樣機器上的應用程序可以互相通訊。遠程處理基礎結構可以使用 HTTP 或者 TCP 傳輸進行通訊，能夠以許多格式發送消息，其中最多見的是 SOAP 或者二進制格式。

宿主在 Windows 服務（TCP 信道）中

由於遠程處理基礎結構沒有默認的身份驗證和受權機制，因此不推薦在面向 Internet 的應用程序中使用。遠程處理是爲運行在可信環境中的應用程序而設計的，很是適於 Web 服務器與遠程應用程序服務器的通訊，如圖 5 所示。

圖 5. 使用 TCP 信道的遠程處理和 Windows 服務宿主

在這種狀況下，Windows 服務宿主遠程處理對象，通訊是經過 TCP 信道進行的。這種方法提供了很好的性能，可是未必能解決安全問題。爲了增長安全性，能夠在 Web 服務器和應用程序服務器之間使用 IPSec，而且只容許 Web 服務器與應用程序服務器創建鏈接。

宿主在 IIS （HTTP 信道）中

爲了利用 ASP.NET 和 IIS 提供的安全功能，將遠程組件宿主在 ASP.NET 中，使用 HTTP 信道進行通訊，如圖 6 所示。

圖 6. 使用 HTTP 信道的遠程處理和 ASP.NET 宿主

在這種狀況下，您可使用 Windows 集成身份驗證對 ASP.NET Web 應用程序進程的身份進行驗證。您還可使用 SSL 進行安全的通訊，使用 IIS 和 ASP.NET 提供的網關守衛進行受權。

返回頁首

企業服務 (COM+) 安全注意事項

COM+ 爲企業服務提供了基礎結構，所以，若是您在中間層應用程序服務器上使用 COM+ ，就須要保護 COM+ 的安全。保護使用企業服務的應用程序服務器，須要涉及兩個主要步驟：

保護組件服務基礎結構。
您必須保護基礎操做系統和企業服務基礎結構。這包括許多基本安全措施，好比應用修補程序和更新，禁用未用服務，阻塞未用端口，等等。
配置企業服務應用程序安全。
您必須保護部署在服務器上的企業服務應用程序，充分考慮應用程序特定的安全須要。

開發人員可使用嵌入在部署程序集中的元數據，指定許多應用程序級和組件級安全配置設置。這些設置管理最初的目錄安全設置，在應用程序向企業服務註冊時，這些設置將應用於應用程序。而後，若是必要的話，管理員能夠經過使用組件服務工具查看和修改這些設置。

保護組件服務基礎結構

企業服務不是可選組件，它是做爲 Windows 2000 不可分割的一部分安裝的。從安全的角度來看，瞭解哪些操做系統組件是爲了支持企業服務而安裝的，有助於您採起適當的安全措施。

操做系統已經安裝了哪些組件？

下表列出了隨標準操做系統安裝而安裝的核心組件服務元素。

表 1 企業服務組件

項	詳細信息
管理	組件服務資源管理器提供了對 COM+ 應用程序的可配置管理，位於 \WINNT\system32\Com\comexp.msc。 COM+ 目錄 COM+ 目錄保存每一個 COM+ 應用程序的配置信息。
系統應用程序（一個 COM+ 服務器應用程序）	系統應用程序這個應用程序管理配置並跟蹤 COM+ 組件。它能夠從組件服務 Microsoft 管理控制檯 (MMC) 查看。它還有兩個相關聯的角色： Administrator 和 Reader。默認狀況下，管理員屬於 Administrator 角色的一部分，該角色可以修改 COM+ 目錄，而 Everyone 屬於 Reader 角色，該角色只能讀取 COM+ 目錄值。
服務	COM+ 事件系統此服務須要支持 COM+ 鬆耦合事件 (LCE) 系統。操做系統服務（好比系統事件通知服務 (SENS) 服務）和應用程序均可能使用 LCE 系統。分佈式事務協調程序 (DTC) 若是您的企業服務解決方案使用 COM+ 自動事務，則須要用到此服務。
賬戶	企業服務不建立任何賬戶。庫應用程序以它們運行所在進程的身份運行。服務器應用程序能夠配置爲以交互用戶或者特定的用戶運行。（您能夠在組件服務中 COM+ 應用程序 Properties 對話框的 Identity 選項卡上配置用戶賬戶）。
日誌文件	DTC 日誌文件：%windir%\system32\DTCLog CRM 日誌文件：%windir%\registration
註冊表項	HKEY_CLASSES_ROOT\CLSID HKEY_CLASSES_ROOT\AppID

.NET Framework 安裝了哪些組件？

當您安裝 .NET Framework 時，將安裝如下與企業服務相關的組件。

表 2 .NET Framework 企業服務工具和配置設置

項	說明
Regsvcs.exe	命令行工具，用於向 COM+ 註冊企業服務組件
庫	System.EnterpriseServices.dll System.EnterpriseServices.Thunk.dll System.EnterpriseServices.tlb
Machine.config 配置元素	若是您從 ASP.NET 調用企業服務，Machine.config 中的如下項將與此有關： <assemblies> 爲 ASP.NET 加載 System.EnterpriseServices 程序集。 <processModel> comAuthentication 屬性用於配置 ASP.NET 身份驗證級。DCOM 身份驗證級是在客戶端（例如，Web 應用程序）和服務器（企業服務應用程序）之間協商的。使用兩個安全設置中較高的一個。 comImpersonationLevel 屬性配置了 ASP.NET 模擬級（對於全部輸出的 DCOM 調用）。客戶端決定了授予服務器的模擬功能。

爲了保護組件服務基礎結構，須要考慮如下幾項：

修補程序和更新
服務
端口
COM+ 目錄

修補程序和更新

用最新的服務包和修補程序更新應用程序服務器，以下降病毒、蠕蟲和特洛伊木馬帶來的風險。須要按期更新的軟件包括操做系統、IIS 和 .NET Framework。

COM+ 運行庫的更新有時是以 QFE 版本的形式發佈的。使用如下資源有助於管理修補程序和更新：

Windows 更新和修補程序
使用 Microsoft 基準安全分析程序 (MBSA) 檢測應用程序服務器上遺漏的安全更新。有關如何在一臺計算機上使用 MBSA 以及保持一組服務器最新的更多信息，請參閱本指導的「如何……」部分中的「如何使用 MBSA 」。
有關要求許多服務器從一個集中管理點更新的環境方面的信息，請參閱本指導的「如何……」部分中的「如何實現修補程序管理」。
.NET Framework 更新和修補程序
在撰寫本單元的時候（2003 年 5 月），MBSA 尚未能力檢測 .NET Framework 。因此，您必須手工更新 .NET Framework。

手工更新 .NET Framework

肯定要在 Web 服務器上安裝的 .NET Framework 服務包。
爲此，請參閱 Microsoft 知識庫文章 318785，「INFO: Determining Whether Service Packs Are Installed on .NET Framework 」。
比較當前服務包與 .NET Framework 的安裝版本。
爲了此，使用 Microsoft 知識庫文章 318836，「INFO: How to Obtain the Latest .NET Framework Service Pack 」中列出的 .NET Framework 版本。

COM+ 更新和修補程序
最新的 Windows 服務包包括對 COM+ 的當前修補。可是，對 COM+ 運行庫的更新有時是以 QFE 版本的形式發佈的。COM+ 更新自動通知服務如今尚未，所以須要不斷關注 Microsoft 知識庫，網址是：http://support.microsoft.com 。使用「kbQFE」做爲搜索關鍵字以改善搜索結果。

服務

爲了減小受攻擊面，應該禁用任何不須要的服務。必需的服務包括：Microsoft DTC 和 COM+ 事件系統服務，這是支持 LCE COM+ 功能所需的。

爲了保護應用程序服務器上的服務，若是不須要它的話，應該禁用 MS DTC。

若是不須要就禁用 Microsoft DTC

DTC 服務是與 COM+ 緊密結合的。它負責協調跨越兩個或者多個數據庫、消息隊列、文件系統或者其餘資源管理器分佈的事務。若是您的應用程序不使用 COM+ 自動事務服務，那麼應該經過使用服務 MMC 管理單元禁用 DTC。

端口

服務組件使用 DCOM 進行通訊，DCOM 繼而又使用 RPC 傳輸通訊。

默認狀況下，DCOM 動態分配端口，這從安全和防火牆配置的角度來看是不可取的。對 DCOM 端口應該進行限制，以減小受攻擊面，並保證無需打開內部防火牆上沒必要要的端口。要限制 DCOM 使用的端口有兩種選擇：

使用端口範圍。
使用靜態終結點映射。

端口範圍

對於傳入的通訊，能夠配置 RPC 動態端口分配，從而在大於 1024 的有限範圍中選擇端口。而後配置防火牆以限制傳入的外部通訊只經過這些端口和端口 135，後者是 RPC 終結點映射器端口。

控制 RPC 動態端口分配

啓動組件服務工具。
單擊以打開 Component Services 和Computers 節點，右鍵單擊 My Computer，而後單擊 Properties。
單擊 Default Protocols 選項卡，而後選擇 DCOM Protocols 列表框中的 Connection-oriented TCP/IP。
單擊 Properties。
在 Properties for COM Internet Services 對話框中，單擊 Add。
在 Port range 文本框中，添加端口範圍，例如 5000–5020，而後單擊 OK。
將 Port range assignment 和 Default dynamic port allocation 選項設置爲 Internet range。
單擊 OK 兩次，關閉對話框。
重啓計算機，使更改生效。

靜態終結點映射

Windows 2000（SP3 或者 QFE 18.1）或者 Windows Server 2003 容許您配置企業服務應用程序，以使用靜態終結點。若是防火牆將客戶端與服務器分隔開來，只須要打開防火牆的兩個端口。具體來講，您必須爲 RPC 打開端口 135，併爲企業服務應用程序打開一個端口。

爲 DCOM 配置靜態終結點

從 COM+ 目錄獲取企業服務應用程序的應用程序 ID。步驟以下：

啓動組件服務工具。
顯示應用程序的 Properties 對話框，並從 General 頁檢索應用程序 ID。

啓動註冊表編輯器 (Regedt32.exe)。
選擇如下注冊表項：
HKEY_CLASSES_ROOT\AppID
從 Edit 菜單中，單擊 Add Value，而後添加如下注冊表值，其中 {your AppID} 是第 1 步中獲取的 COM+ 應用程序的應用程序 ID：
```
Key name: {Your AppID}
Value name: Endpoints
Data type: REG_MULTI_SZ
Value data: ncacn_ip_tcp,0,
```
在 Value data 文本框中指定的端口號必須大於 1024，不能與計算機上其餘應用程序使用的已知端口衝突。不能修改此項中的 ncacn_ip_tcp,0 部分。
關閉註冊表編輯器。

COM+ 目錄

企業服務應用程序配置設置保存在 COM+ 目錄中。大多數配置項保存在註冊數據庫 (RegDB) 中，由位於如下目錄中的文件組成：

%windir%\registration

默認狀況下，Everyone 組有讀取此數據庫的權限。修改此目錄的訪問控制列表 (ACL)，以限制對管理員和本地系統賬號的讀/寫訪問權限。還要授予對於賬戶的讀訪問權限，用來運行企業服務應用程序。如下是必需的 ACL：

Administrators: Read, Write
System: Read, Write
Enterprise Services Run-As Account(s): Read

保護企業服務應用程序

單獨的應用程序配置設置是保存在 COM+ 目錄中的，可使用組件服務工具或者使用腳本進行配置。下面討論的許多設置也能夠由應用程序開發人員經過在服務組件程序集中使用正確的程序集級元數據來指定。在註冊服務組件時，例如經過使用 Regsvcs.exe 時，COM+ 目錄自動地使用此元數據進行配置，可是應用程序的運行方式 (run-as) 身份必須經過管理手段進行配置。

爲了保護企業服務應用程序，必須配置如下項：

身份 (run as)
身份驗證級
COM+ 基於角色的安全
模擬
CRM 日誌文件
應用程序程序集

身份 (Run As)

配置企業服務服務器應用程序，以最低特權賬戶運行。當服務器進程遇到攻擊者使用其安全上下文執行代碼的攻擊時，這將減小所以形成的潛在危害。

若是企業服務應用程序中的服務組件並不模擬調用方的安全上下文，那麼經過 run-as 賬戶指定的進程級身份將用於下游的本地資源和遠程資源的訪問。爲了支持對遠程數據庫服務器的網絡身份驗證，您能夠建立一個「鏡像的」本地賬戶，後者是一個具備匹配用戶名和密碼的遠程服務器上的本地賬戶。

×¢ 當您將企業服務設置爲 run-as 身份時，將自動授予該賬戶所必需的「Logon as a batch job」特權。

身份驗證級

企業服務應用程序使用 RPC 對調用方進行身份驗證，而調用方繼而又會使用經過安全服務提供程序接口 (SSPI) 層提供的操做系統基礎身份驗證服務。這意味着應用程序將使用 Windows 身份驗證，即 Kerberos 或者 NTLM 對調用方進行身份驗證。

RPC 定義了多個身份驗證級，用於決定什麼時候進行身份驗證，以及已通過身份驗證的通訊是否還應該檢查完整性或者進行加密。至少，您應該使用調用級身份驗證確保每一個對服務組件方法的方法調用都要進行身份驗證。

×¢ 調用級身份驗證並不會致使消息數據的加密。所以，若是網絡偵聽問題很嚴重的話，可使用數據包私密性身份驗證級，若是是在一個用 IPSec 保護的信道上，則可使用調用級身份驗證。

表 3 顯示了各類身份驗證級：

表 3：企業服務應用程序身份驗證級

身份驗證級	說明
默認值	使用正常的協商規則選擇身份驗證級
無	無身份驗證
鏈接	當客戶端最初鏈接服務器時只有身份驗證憑據
調用	在每次遠程過程調用的開始進行身份驗證
數據包	對從客戶端接收到的全部數據進行身份驗證
數據包完整性	對全部數據進行身份驗證，並驗證已傳輸的全部數據都沒有被修改
數據包私密性	對全部數據進行身份驗證，並使用 RPC 加密機制加密全部傳輸的數據包

設置調用級身份驗證

啓動組件服務，並顯示應用程序的 Properties 對話框。
單擊 Security 選項卡。
從 Authentication level for calls 下拉列表中選擇 Call。

COM+ 基於角色的安全

企業服務應用程序中的受權是由企業服務 (COM+) 角色提供的。COM+ 角色包含 Windows 用戶和組賬戶，用於限制對應用程序、組件、接口和方法的訪問。理想狀況下，企業服務應用程序應該配置爲組件級受權，這樣能夠受權調用方訪問單獨服務組件方法。

配置基於角色的安全：

啓用基於角色的安全。
啓用組件級訪問檢查。
強制組件級訪問檢查。

啓用基於角色的安全

默認狀況下，基於角色的安全性在 Windows 2000 上是禁用的。而對於 Windows Server 2003 則正好相反。

啓用基於角色的安全

啓用組件服務工具，顯示應用程序的 Properties 對話框。
單擊 Security 選項卡。
選擇 Enforce access checks for this application。

圖 7. 啓用基於角色的安全

啓用組件級訪問檢查

在沒有組件級訪問檢查的狀況下，若是用來鏈接任何應用程序組件的任何賬戶是應用程序中任何角色的成員，都將被授予訪問權限。組件級訪問檢查容許單獨的組件應用本身的受權。這是推薦的粒度級別。

啓用組件級訪問檢查

啓動組件服務工具，並顯示應用程序的 Properties 對話框。
單擊 Security 選項卡。
單擊 Perform access checks at process and component level。
圖 8. 啓用組件級訪問檢查

強制組件級訪問檢查

爲了容許企業服務應用程序中的單獨組件執行訪問檢查和對調用方進行受權，您必須在組件級啓用組件級訪問檢查。

強制組件級訪問檢查

啓動組件服務工具，並在樹控件中展開應用程序。
選擇 Components 文件夾，右鍵單擊它，而後單擊 Properties。
單擊 Security 選項卡。
單擊 Enforce component level access checks。

×¢ 此設置只在您已經啓用了應用程序級訪問檢查以後並且配置了進程和組件級訪問檢查時是有效的，這一點前面已經敘述過。

模擬

DCOM 客戶端設置模擬級以決定與其通訊的服務器的模擬能力。當配置中間層應用程序服務器上的企業服務應用程序時，已配置的模擬級將影響對下游組件（包括數據庫服務器）的任何遠程調用。模擬級是在組件服務中應用程序 Properties 對話框的 Security 頁設置的，如圖 9 所示。

圖 9. DCOM 模擬級

合適的級別取決於所需的應用程序級的功能，雖然您應該使用如下指導肯定合適的級別：

避免使用 Anonymous 模擬。下游組件不能標識應用程序以用於身份驗證或者受權目的。
使用 Identify 以容許下游組件對您的應用程序進行身份驗證和受權。可是，它將沒法使用應用程序模擬的安全上下文訪問本地或者遠程資源。
使用 Impersonate 若是您想容許下游組件模擬應用程序的身份，這樣使其可以訪問下游服務器上的本地資源。
使用 Delegate 若是你想容許下游組件模擬應用程序的身份，這樣使其可以訪問本地或者遠程資源。這須要賬戶爲在 Active Directory 中的委託進行配置。

全部下游資源的訪問都是由中間層應用程序服務器上的服務組件執行的，一般使用服務器應用程序的身份。可是，若是服務組件執行編程模擬，而客戶端應用程序（一般是一個 ASP.NET Web 應用程序或者 Web 服務器上的 Web 服務）已經配置爲支持 Kerberos 委託，那麼將使用客戶端的身份。

有關更多信息，請參閱「如何：在 Windows 2000 中啓用 Kerberos 委託」，在「Microsoft patterns & practices 第 I 卷，構建安全的 ASP.NET Web 應用程序：身份驗證、受權和安全通信」的「如何……」部分，網址是：http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/secnetlpMSDN.asp。

CRM 日誌文件

若是您的企業服務應用程序使用 CRM，應該確保 CRM 日誌文件獲得保護，避免潛在的信息泄漏。根據應用程序的性質，文件可能包含敏感的應用程序數據。CRM 日誌文件是在如下目錄建立的：

%windir%\system32\dtclog

CRM 日誌文件名是從企業服務應用程序 ID 派生而來的，文件擴展名爲 .crmlog。當企業服務建立 CRM 日誌文件，且該文件經過一個 ACL（授予應用程序 run-as 賬戶 Full Control）進行配置時，該文件將獲得保護。沒有其餘賬戶擁有訪問權限。

若是您在日誌文件建立後改變應用程序的身份，則必須手動改變文件的 ACL。確保應用程序新的 run-as 身份具備 Full Control 權限。

應用程序程序集

爲了保護包含應用程序服務組件的已部署應用程序程序集，應該加固與程序集 .dll 文件相關聯的ACL，以確保它們不會被未受權的用戶替換或者刪除。

對應用程序的 DLL 文件夾應用如下 ACL：

Users: Execute
Application Run as account: Execute
Administrators: Read, Write and Execute

應用程序程序集 DLL 的位置是在部署時指定的，所以可能因不一樣的安裝而異。組件服務工具中的 Properties 對話框並不顯示程序集 DLL 的位置。相反，它指向 %windir%\System32\mscoree.dll，這爲組件提供了偵聽服務。

檢查應用程序 DLL 的位置

啓動組件服務工具，並在樹控件中展開應用程序。
展開 Components 文件夾，選擇一個組件，右鍵單擊它，而後單擊 Properties。
在 Properties 對話框中，檢索組件的類 ID (CLSID)。
啓動 Regedt32.exe，並在 HKEY_CLASSES_ROOT\CLSID 下找到已檢索的 CLSID。
單擊 InprocServer32 項。
DLL 的位置由 CodeBase 命名值所指示。

返回頁首

小結

當具有足夠的外圍網絡防禦時，影響中間層應用程序服務器的許多威脅都來自單位的內部。安全基礎結構是由多個 IPSec 策略組成的，這些策略限制只能從選定的 Web 服務器對應用程序服務器進行訪問，它們還提供了安全的通訊信道。這種安全基礎結構是有效下降風險的策略。

本單元還列舉了更多安全措施。這些措施會根據應用程序服務器所用技術的不一樣而不一樣。

在應用程序服務器兩端的內部防火牆帶來了另外一些問題。必須打開的端口具體取決於應用程序實現的選擇，好比傳輸協議和是否使用分佈式事務。

若是你看到了最後：

在貼幾個與簡要內容相關的：組件服務管理及其安全配置

身份驗證、受權安全配置： http://technet.microsoft.com/zh-cn/library/dd145616.aspx

管理安全性配置：http://technet.microsoft.com/zh-cn/library/cc755073.aspx

其餘資源

有關本單元所討論問題的更多信息，請參閱如下 Microsoft 知識庫文章，網址是：http://support.microsoft.com：

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。