部署過程的檢閱

確認已安全地部署 ASP.NET Web 應用程式，且 ASP.NET Web 應用程式正在安全的環境中執行。

建立執行部署過程的檢閱和安全性稽核的方法和範圍。

透過一系列廣泛的安全性問答，快速找出安全性的漏洞。

檢閱下列已部署項目的設定：網路及主機、基本 Windows 2000、IIS 及 .NET Framework、Web 應用程式及 Web 服務、Enterprise Services、遠端服務、和 SQL Server。

Microsoft Windows Server 2000

Microsoft .NET Framework 1.1 及 ASP.NET 1.1

Microsoft SQL Server

閱讀並遵循單元 21＜程式碼的檢閱＞中的內容及方法，以確保安全地部署 Web 應用程式。

使用設定類別。使用本單元所指定的類別來把握安全性檢閱的重點。

閱讀本單元之後，接著閱讀本指南第四部之同系列的安全性單元：

使用同系列的檢查清單

補充程式及更新

服務

通訊協定

帳戶

檔案及目錄

共用

連接埠

登錄

稽核和記錄

您是否已經執行 MBSA？
確認您已經執行 MBSA 工具來找出常見的 Windows 及 IIS 安全性弱點，並且找出遺漏的 Service Pack 及補充程式。

修正所找到的安全性弱點，並且安裝最新的補充程式及更新，藉此回應 MBSA 的輸出結果。如需詳細資訊，請參閱單元 16＜保護 Web 伺服器的安全＞中的「步驟 1：補充程式及更新」

您是否已經安裝 .NET Framework 的更新程式？
若要判定目前的 .NET Framework 版本，請參閱 Microsoft 知識庫文件 318785《INFO: Determining Whether Service Packs Are Installed on the .NET Framework (英文)》。接著比較已安裝的 .NET Framework 版本與目前的 Service Pack。若要進行比較，請利用文件 318836《INFO: How to Obtain the Latest .NET Framework Service Pack (英文)》所列出的各種 .NET Framework 版本。

您是否執行了不必要的服務？
使用 [服務] 嵌入式管理單元來檢查正在執行的各個服務，並確認這些服務是否有執行的必要。確定必須執行這些服務的原因，以及應用它們的解決方案。確認所有不必要的服務均已關閉。

您是否已經停用 Telnet 服務？
Telnet 通常用於遠端 IIS 系統管理。但是卻很容易遭受多種攻擊，因此是一種不安全的通訊協定。請檢查 Telnet 服務是否已停用。如需更安全的系統管理解決方案，請使用終端機服務 (Terminal Services)。

您是否已經停用 FTP、SMTP、以及 NNTP 服務？
這些服務都是不安全的通訊協定，而且具有已知的安全性弱點。如果您不需要這些服務，請停用它們。如果您使用這些服務，請尋找安全的替代方案。在 [服務] MMC 嵌入式管理單元中，這些服務分別列為 FTP 發行服務、Simple Mail Transport Protocol (SMTP) 和網路新聞傳輸通訊協定 (NNTP)。

注意 IISLockdown 會停用這些服務。

您是否使用 ASP.NET 工作階段狀態服務？
若要判斷您的應用程式是否使用此服務，請查看該應用程式之 Web.config 檔中的 <sessionState> 元素。如果 Web.config 未包含此元素，請在 Machine.config 中檢查其設定。當 mode 屬性設定為「StateServer」且 stateConnectionString 指向本機電腦時 (例如使用如下所示的本機位址)，您便是在 Web 伺服器上使用工作階段狀態服務：

<sessionState mode="StateServer"
stateConnectionString="tcpip=127.0.0.1:42424" />

如果您沒有在 Web 伺服器上使用此服務，那麼請停用它。在服務 MMC 嵌入式管理單元中，此服務列為「ASP.NET 狀態服務」。

有關如何保障 ASP.NET 工作階段狀態安全的詳細資訊，請參閱單元 19＜保障 ASP.NET 應用程式及 Web 服務的安全＞中的「工作階段狀態」內容。

您是否使用 WebDAV？
如果您使用 Web Distributed Authoring and Versioning 通訊協定 (WebDAV) 來發行內容，那麼請確保此通訊協定的安全性。如果您沒有使用此通訊協定，那麼請停用它。

有關如何保障 WebDAV 安全的資訊，請參閱 Microsoft 知識庫文件 323470《How To: Create a Secure WebDAV Publishing Directory (英文)》有關如何停用 WebDAV 的資訊，請參閱文件 241520《How to Disable WebDAV for IIS 5.0 (英文)》。

您是否已經強化 TCP/IP 堆疊？
確保您已強化 TCP/IP 堆疊以防止包含 SYN Flood 攻擊在內的各種網路層拒絕服務攻擊。若要檢查伺服器上的堆疊是否已進行強化，請使用 Regedt32.exe 並查看下列登錄機碼：

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

如果出現以下的子系機碼，代表 TCP/IP 堆疊已經強化：SynAttackProtect、EnableICMPRedirect、及 EnableDeadGWDetect。

有關充分強化堆疊所需的必要機碼和適當數值的完整清單，請參閱本指南中 How To 章節的＜How To：強化 TCP/IP 堆疊＞。

您是否已經停用外部網路網路卡的 NetBIOS 及 SMB？
檢查透過 TCP/IP 的 NetBIOS 及 SMB 是否均已停用，以防止主機列舉攻擊 (Host Enumeration Attack)。如需詳細資訊，請參閱單元 16＜保護 Web 伺服器的安全＞中的「通訊協定」內容。

您是否已經刪除或停用所有未使用的帳戶？
執行稽核來確定您的所有帳戶都有其用途與必要性。刪除或停用任何不必要的帳戶。您無法刪除本機的「系統管理員 (Administrator)」帳戶和「來賓 (Guest)」帳戶。因此您應停用「來賓 (Guest)」帳戶並重新命名「系統管理員 (Administrator)」帳戶，且務必使用增強式密碼。

您是否已經停用「來賓 (Guest)」帳戶？
若要檢查「來賓 (Guest)」帳戶是否已停用，在 [電腦管理] 工具中顯示 [使用者 (Users)] 資料夾，查看「來賓 (Guest)」帳戶旁是否顯示十字圖示。如果尚未停用，請顯示其 [內容] 對話方塊，然後選擇 [帳戶已停用]。

您是否已經重新命名預設的系統管理員帳戶？
預設的本機「系統管理員 (Administrator)」帳戶是攻擊的首要目標。請確認您已經重新命名「系統管理員 (Administrator)」帳戶，並使用增強式密碼。

您是否已經建立自訂的匿名 Web 帳戶？
檢查預設的 IUSR_MACHINE 帳戶是否已經停用，並確定您已經設定了替代的匿名使用者帳戶，以供您的 Web 應用程式使用。

您是否使用增強式密碼原則？
使用「本機安全性原則」工具來檢閱密碼原則。有關建議密碼原則的資訊，請參閱單元 16＜保護 Web 伺服器的安全＞中的「步驟 5：帳戶」。

您是否有限制遠端登入？
在「本機安全性原則」工具中檢查使用者權利指派，以確定並未將「從網路存取這台電腦」的使用者權利授與 Everyone 群組。

您是否已經停用 Null 工作階段？
檢查是否已停用 Null 工作階段以避免您的伺服器建立匿名 (未經驗證) 工作階段。若要檢查此項目，請執行 Regedt32.exe，並確認 RestrictAnonymous 值已設定為 1，如下所示。

HKLM\System\CurrentControlSet\Control\LSA\RestrictAnonymous=1

IIS 是否安裝在 NTFS 磁碟區上？
這可讓您使用 NTFS 來設定資源的 ACL，以限制存取。請勿建置使用 FAT 磁碟分割的伺服器。

您是否已經限制 Everyone 群組？
使用 Windows 檔案總管來確保 Everyone 群組沒有下列目錄的存取權限：

您是否已經限制匿名 Web 使用者帳戶？
確定匿名的網際網路使用者帳戶無法寫入 Web 內容目錄。使用 Windows 檔案總管來檢視每個內容目錄的 ACL。同時檢查 %windir%\system32 目錄的 ACL，以確保它無法存取系統工具與公用程式。

注意 如果您曾經執行 IISLockdown，則 Web 匿名使用者 (Web Anonymous Users) 群組和 Web 應用程式 (Web Applications) 群組就可以用來限制存取。在預設的狀況下，Web 匿名使用者 (Web Anonymous Users) 群組會包含 IUSR 帳戶，而 Web 應用程式 (Web Applications) 群組則包含 Internet Web Application Manager (IWAM)。以系統管理員的立場來看，限制群組存取優於個別帳戶限制。

您是否已經保護或移除公用程式及 SDK？
請確認您的伺服器上沒有公用程式或軟體開發套件 (Software Development Kit，SDK)。確認未安裝 Visual Studio.NET 或任何 .NET Framework 的 SDK。另外確認您已經限制使用 NTFS 權限來存取功能強大的系統工具，例如 At.exe、Cmd.exe、Net.exe、Pathping.exe、Regedit.exe、Regedt32.exe、Runonce.exe、Runas.exe、Telnet.exe、以及 Tracert.exe。最後，確認沒有在伺服器上安裝任何偵錯工具。IISLockdown 會自動利用 Web 匿名使用者 (Web Anonymous Users) 群組和 Web 應用程式 (Web Applications) 群組來限制系統工具的存取。

您是否已經移除未使用的 DSN？
檢查所有未使用的資料來源名稱 (DSN) 是否都自伺服器中移除，因為 DSN 可能包含純文字資料庫連線的詳細資訊。

伺服器上有哪些共用？
若要檢閱共用及相關的使用權限，請執行 [電腦管理] MMC 嵌入式管理單元，並選取 [共用資料夾] 下的 [共用]。檢查所有共用是否均有必要存在。移除不必要的共用。

Everyone 群組是否可以存取共用？
除非別有用意，否則請確定沒有將共用的存取權限授與 Everyone 群組，並且設定特定使用權限來替代此權限。

您是否已經移除系統管理共用？
如果您不允許遠端管理伺服器，那麼請檢查是否已移除系統管理共用，例如 C$ 及 IPC$。

將外部網路連接埠限制為 TCP 80 及 443。

限制或加密內部網路的資料傳輸。

您是否已經限制遠端登錄系統管理？
使用 Regedt32.exe 來檢閱 WinReg 登錄機碼上的 ACL，WinReg 登錄機碼可控制是否允許遠端存取登錄。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg

根據 Windows 2000 的預設值，遠端登錄存取僅限於 Administrator 與 Backup Operator 群組的成員。為了確保安全性，使用空的「判別存取控制清單 (DACL)」來限制登錄的所有遠端存取。

注意 某些服務需要使用遠端存取登錄的功能。請參閱 Microsoft 知識庫文件 153183《How to Restrict Access to the Registry from a Remote Computer (英文)》，以瞭解您的方案是否需要限制遠端登錄存取。

您是否已經保障 SAM 的安全？
此項目僅適用於獨立伺服器。檢查您是否已經限制安全性帳戶管理員 (SAM) 資料庫的 LMHash 存放區，方法是在登錄中建立機碼 (非數值) NoLMHash ，如下所示：

HKLM\System\CurrentControlSet\Control\LSA\NoLMHash

您是否有記錄所有失敗的登入嘗試？
使用「本機安全性原則」工具來檢查您是否已啟用失敗登入嘗試的稽核作業。

您是否記錄整個檔案系統中所有失敗的動作？
使用「本機安全性原則」工具來檢查您是否已啟用物件存取稽核。接著檢查是否已啟用檔案系統整體的稽核。

IISLockdown

URLScan

站台及虛擬目錄

ISAPI 篩選器

IIS Metabase

伺服器憑證

若要查看是否安裝 URLScan：

網站位置

指令碼對應

匿名網際網路使用者帳戶

稽核和記錄

Web 權限

IP 位址及網域名稱限制

驗證

上層路徑設定

Microsoft FrontPage 伺服器延伸

若要檢閱指令碼對應：

記錄檔是否位於個別的非系統磁碟區上？
在 IIS 中的網站上按一下滑鼠右鍵，再按 [網站] 索引標籤。按一下 [內容] 按鈕以查看記錄檔位置。檢查記錄檔是否位於非預設的位置，並且使用非預設的名稱，最好是位於非系統的磁碟區上。

您是否限制記錄檔的存取？
使用 Windows 檔案總管來檢視記錄檔目錄的 ACL。檢查 ACL 是否將完全控制授與系統管理員 (Administrator) 與系統 (System)，但未將存取權授與其他任何使用者。

包含目錄限制讀取權。

可供匿名存取的虛擬目錄已設定為限制寫入和執行權限。

寫入權和指令碼來源存取權限僅授與允許撰寫內容的內容資料夾。並且檢查允許撰寫內容的資料夾是否要求驗證和 Secure Sockets Layer (SSL) 加密。

若要檢閱上層路徑設定：

若要檢閱 ISAPI 篩選器：

您是否已經限制 Metabase 的存取？
檢查 Metabase 檔案的 ACL 是否授與完全控制存取權給系統帳戶及系統管理員。其他帳戶均不宜具有此存取權。Metabase 檔案及位置如下：

%windir%\system32\inetsrv\metabase.bin

您是否顯示內部 IP 位址？
在 HTTP 回應標頭的內容位置 (Content-Location) 區段中，IIS 依預設會傳回伺服器的內部 IP 位址。您應該將 UseHostName Metabase 內容設定為 true，以避免發生上述情況。若要檢查是否已經設定，請從 \inetpub\adminscripts 目錄執行下列命令：

adsutil GET w3svc/UseHostName

確認已將屬性值設定為 True。如果尚未設定該屬性，則此命令將傳回下列訊息：「尚未設定此節點的參數 'UseHostName' (The parameter 'UseHostName' is not set at this node」)。如需詳細資訊，請參閱單元 16＜保護 Web 伺服器的安全＞中的「步驟 14：IIS Metabase」。

您的伺服器憑證是否已經過期？

對受信任的根憑證而言，憑證鏈結中的所有公開金鑰是否都有效？

您的憑證是否已經撤銷？

查看核發憑證之伺服器的憑證撤銷清單 (CRL) 上是否不包含憑證。

<trace>

<httpRunTime>

<compilation>

<pages>

<customErrors>

<authentication>

<identity>

<authorization>

<machineKey>

<trust>

<sessionState>

<httpHandlers>

<processModel>

您是否使用檢視狀態？
如果 enableViewState 設定為 True，請務必將 enableViewStateMac 也設定為 True ，以便保障網路上檢視狀態的安全。另外，請務必檢查 <machineKey> 設定，因為此元素會指定與相關金鑰一併使用的加密及雜湊演算法。

您是否使用工作階段狀態？
如果 enableSessionState 設定為 True，請務必檢查 <sessionState> 元素設定。

您是否有針對驗證 Cookie 進行加密？
即使是經由 SSL 通道，也應對 Cookie 的完整性進行加密與查核，以便偵測是否有竄改情形，因為 Cookie 可能會遭到跨網站指令碼 (Cross-site Scripting，XSS) 攻擊的盜用。檢查 <forms> 元素的 protection 屬性是否設定為 All。

<forms protection="All" .../>   All 是指加密和驗證而言

您是否使用 SSL 與表單驗證？
SSL 可防止連線劫持及 Cookie 被重新執行的攻擊。檢查 <forms> 元素的 requireSSL 屬性。

<forms requireSSL="true" ... />

您是否限制驗證 Cookie 存留期？
盡量減少 Cookie 逾時值，藉此限制攻擊者能使用 Cookie 來存取您的應用程式的時間長度。檢查 <forms> 元素上的 timeout 屬性。

<forms timeout="10" ... />

您是否使用 滑動逾時 (Sliding Expiration)？
檢查 slidingExpiration 屬性。slidingExpiration="true" 表示 Cookie 會在本身初始期間之後的固定持續時間時到期。逾時時鐘 (Timeout Clock) 不會在每個要求後重設。對於所有頁面都不使用 SSL 的應用程式而言，特別建議使用滑動逾時 (Sliding Expiration) 來保障 Cookie 的安全。

您是否使用唯一 Cookie 路徑及名稱？
請檢查每個 Web 應用程式是否都使用不同的 Cookie 名稱及路徑。如此可確保通過某個應用程式驗證的使用者在使用相同 Web 伺服器上的另一個應用程式時，不會被視為已經驗證。檢查 <forms> 元素上的 path 及 name 屬性。

<forms name=".ASPXAUTH" path="/" ... />

您是否使用 <credentials> 元素？
您不應在生產伺服器上使用 <credentials> 元素。此元素是專供研發及測試之用。憑證應該儲存在 Microsoft Active Directory® 目錄服務或 SQL Server 中。

您如何儲存憑證？
如果您的應用程式使用 Windows 驗證，那麼憑證會儲存在 Active Directory 中，而 Active Directory 會將憑證管理問題傳送到作業環境中。如果您的應用程式使用表單驗證，那麼請確定您是使用 SQL Server 或 Active Directory 憑證存放區。

您是否儲存密碼雜湊？
請勿將密碼儲存在資料庫中。而是利用 Salt 來儲存密碼雜湊，以遏阻字典攻擊。

您是否使用增強式密碼？
您的應用程式應強制使用增強式密碼。在表單登入頁中使用規則運算式是一個有效的方法。

您是否模擬原始呼叫者？
如果 impersonate 屬性設定為 True ，而 userName 或 password 屬性並未指定，您便是模擬 IIS 授權的識別身份，這可能是匿名的網際網路使用者帳戶。

請務必設定 ACL，好讓模擬的識別身份只能存取必須取得存取權的資源。

您是否模擬固定的識別身份？
如果您模擬並設定 userName 及 password 屬性，您便是模擬固定的識別身份，而此識別身份可用於資源存取。

請確定您並未在 <identity> 元素中指定純文字憑證。而是使用 Aspnet_setreg.exe 將加密後的憑證儲存在登錄中。

在 Windows 2000 中，這個方法會強迫您將「充當部分作業系統」使用者權利授與 ASP.NET 處理序帳戶，但不建議您這麼做。如需替代的解決方法，請參閱單元 19＜保障 ASP.NET 應用程式及 Web 服務的安全＞。

您是否已經使用正確的使用者及角色名稱格式？
使用 <authentication mode="Windows" />時，表示您授與存取權給 Windows 使用者和群組帳戶。

使用者名稱的形式為「DomainName\WindowsUserName」。角色名稱的形式為「DomainName\WindowsGroupName」。

注意 本機系統管理員群組稱為「BUILTIN\Administrators」。本機使用者群組稱為「BUILTIN\Users」。

使用 <authentication mode="Forms" /> 時，表示您正在授權由應用程式驗證的識別身份。一般而言，您會根據從資料庫取得的角色來授權。角色名稱是視應用程式而定的。

您是否在相同伺服器上執行多個應用程式？
如果是，請使用 IsolateApps 設定來確保為每個 Web 應用程式產生不同的金鑰。

<machineKey validationKey="AutoGenerate,IsolateApps" 
decryptionKey="AutoGenerate,IsolateApps" validation="SHA1"/>

您是否在 Web 伺服陣列中執行？
如果是，請確認您是使用特定的機器金鑰，並將在伺服陣列中的所有伺服器複製這些金鑰。

您是否有保護檢視狀態？
舉例而言，如果您將 <pages> 元素設定為 enableViewSetMac="true" ，藉此保護檢視狀態，那麼請將 <machineKey> 元素設定為 validation="SHA1" (安全雜湊演算法) 或 "3DES"。如果您同時又將 <forms> 元素設定為 protection="All" 來加密表單驗證 Cookie，那麼就必須使用 Triple Data Encryption Standard (3DES) 設定。

您執行哪個 .NET Framework 版本？
如果您執行 .NET Framework 1.0，那麼信任等級必須設定為 Full。如果是執行 1.1 及以上的版本，您可以將信任等級變更為以下其中一個設定：

<!--  level="[Full|High|Medium|Low|Minimal]" -->
<trust level="Full" originUrl=""/>  

您使用什麼信任等級？
基於安全性原則和開發團隊的同意，在 Web.config 或 Machine.config 中為應用程式設定適當的信任等級。

您是否使用遠端狀態存放區？
檢視 mode 屬性來檢查狀態存放區。

<sessionState mode="Off|Inproc|stateServer|SQLServer" ... />

如果您使用遠端狀態存放區，而 mode 屬性設定為 stateServer 或 SQLServer，那麼請分別檢查 stateConnectionString 及 sqlConnectionString 屬性。為了不要讓憑證存放在資料庫中，請確認連線字串已使用 Aspnet_setreg.exe 進行加密並安全地存放在登錄中，或 Windows 驗證已用來連接 SQL Server 狀態存放區。

以下設定顯示當使用 Aspnet_setreg.exe 來加密登錄中的字串時，stateConnectionString 的形式如下。

<!-- aspnet_setreg.exe has been used to store encrypted details -->
<!-- in the registry. -->
<sessionState mode="StateServer"
stateConnectionString="registry:HKLM\SOFTWARE\YourSecureApp\
identity\ASPNET_SETREG,stateConnectionString" />

您是否將 Windows 驗證用於狀態資料庫？
如果您使用 SQL Server 狀態存放區，請檢查您是否使用 Windows 驗證來連接到狀態資料庫。這表示憑證並未儲存在連線字串中，而且也不會透過網路連線來送出。

如果您一定要使用 SQL 驗證，請確認登錄中的連線字串已經經過加密，而且資料庫伺服器上已安裝伺服器認證，如此可確保通過網路傳輸的憑證有經過加密。

您使用什麼識別身份來執行 ASP.NET？
檢查 userName 及 password 屬性。在理想情況下，您應使用下列設定，讓 ASP.NET 處理序以最小權限的 ASPNET 帳戶執行。

<processModel userName="Machine" password="AutoGenerate" . . ./>

您是否有針對 <processModel> 憑證進行加密？
如果您使用自訂帳戶，請檢查並確定 Machine.config 中並未以純文字形式指定該帳戶憑證。請務必使用 Aspnet_setreg.exe 公用程式在登錄中儲存加密憑證。如果您已經使用此公用程式，userName 及 password 屬性應該如以下設定所示：

<processModel
userName="registry:HKLM\SOFTWARE\YourSecureApp\processModel\
ASPNET_SETREG,userName"
password="registry:HKLM\SOFTWARE\YourSecureApp\processModel\
ASPNET_SETREG,password" . . ./>

您是否使用最小權限帳戶？
預設的 ASPNET 帳戶是專為執行 ASP.NET 所用的最小權限本機帳戶。若要用它來執行遠端資源存取，您必須在遠端伺服器上建立一個複製帳戶。或者，您也可以建立一個最最小權限網域帳戶。

請檢查並確定該帳戶不屬於 Users 群組的一員，並使用「本機安全性原則」工具來檢視使用者權利指派，以免授與其過度或不必要的權利。請勿授與其「充當部分作業系統」使用者權利。

您是否已經停用 Documentation 通訊協定？
如果您不希望暴露 Web 服務端點，那麼您可以在 Machine.config 中將 <protocols> 元素的 Documentation 通訊協定移除，並以手動方式將 Web 服務描述語言工具 (Web Services Description Language，WSDL) 檔案發佈到特定的 Web 服務消費者。

您是否已經停用 HTTP Get and Post 通訊協定？
藉由停用 (將其變更為註解) Machine.config 檔案中 <protocols> 元素的 HttpGet 及 HttpPost 通訊協定，您就能有效減少 Web 服務遭受攻擊的風險。

您是否限制 WSDL 的存取？
如果您將產生的 .WSDL 檔案存放在 Web 伺服器上，以便發佈至消費者，請務必使用適合的 ACL 來保護這些檔案。如此可避免惡意使用者更新或取代 WSDL，讓 WSDL 指向原本 URL 以外的端點。

您是否有在 SOAP 要求或回應中傳送機密資料？
如果您的 Web 服務需處理機密資料，您要如何保護網路上的資料安全，並且因應網路竊聽的風險？您是否使用 SSL 或 IPSec 加密的通道，或者您是否使用 XML 加密來處理部分訊息？

您如何驗證呼叫者？
如果您的 Web 服務會暴露受限制的作業或資料，該 Web 服務就必須驗證呼叫者以支援授權。審查 Web 服務如何驗證其用戶端。

您是否有在 SOAP 標頭中傳送憑證？
如果您在 SOAP 標頭中傳送憑證，這些憑證是否採用純文字形式？如果是，請務必使用經過加密的通道。

帳戶

檔案及目錄

驗證

授權

遠端服務的元件

您是否使用最小權限帳戶？
檢查您用來執行 Enterprise Services 伺服器應用程式的帳戶，確定該帳戶已經設定為最小權限帳戶，並且有限制使用者權利及存取權利。如果您使用處理序帳戶來存取下游資料庫，請務必在資料庫中限制該資料庫的登入。

您是否使用互動式帳戶？
請勿在生產伺服器上使用互動式帳戶 (Interactive Account)。此帳戶是專供研發使用。

COM+ 目錄是否受到保護？
COM+ 目錄維護 COM+ 應用程式的設定資料。請確定用來維護目錄檔案的下列資料夾均已使用受限制的 ACL 來加以設定。

%windir%\registration

設定下列 ACL：

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

CRM 記錄檔是否受到保護？
如果您的應用程式使用補償資源管理員 (Compensating Resource Manager，CRM)，那麼您應該使用 NTFS 權限來保護 CRM 記錄檔 (.crmlog)，因為這些記錄檔可能包含機密應用程式資料。

您的應用程式 DLL 是否受到保護？
請檢查並確定用來保存應用程式 DLL 的資料夾是否已經使用下列受限制的 ACL 來加以設定。

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

如需詳細資訊，請參閱單元 17＜保障應用程式伺服器的安全＞。

您是否有防止匿名存取？
檢查您的應用程式是否至少使用呼叫層級驗證，以確保用戶端每次進行方法呼叫時，都會加以驗證。此舉可避免發生匿名存取。

您使用什麼模擬等級？
檢查您是否至少使用識別身份等級的模擬，好讓下游系統識別服務的元件。在預設的狀況下，這是由應用程式 Run-as 帳戶所決定的處理序識別身份。如果服務的元件使用程式設計模擬，那麼這可能是模擬識別身份。除非您希望下游系統能夠使用服務元件的識別身份來存取遠端資源，否則請勿使用委派等級。

您是否已經停用驗證？
若要查明，請查看應用程式 [內容 (Properties)] 對話方塊中 [安全性 (Security)] 頁上的 [啟用驗證 (Enable authentication)] 核取方塊設定。除非基於特殊需求，例如從遠端服務的元件處理未驗證的回呼，否則您不應停用驗證。

您使用什麼驗證等級？
在 Machine.config 的 <processModel> 元素中所指定的驗證等級負責管理連出呼叫用於遠端服務元件或 DCOM 元件的驗證等級。系統會使用比這個值更高、設定於遠端伺服器的值。檢查 <processModel> 元素中的 comAuthenticationLevel 設定：

您使用什麼模擬等級？
模擬等級會影響從程式庫元件傳送到其他遠端元件的連出呼叫。在 Machine.config 中檢查 <processModel> 元素的 comImpersonationLevel 屬性。

<processModel comImpersonationLevel=
"Default|Anonymous|Identify|Impersonate|Delegate" .../>

是否有啟用存取檢查？
這將決定是否啟用 COM+ 授權。在應用程式之 [元件服務] 的 [內容 (Properties)] 對話方塊中，檢查 [安全性 (Security)] 頁上的 [強制此應用程式的存取檢查] 是否已經選取。

您使用什麼安全層級？
在應用程式之「元件服務」的 [內容 (Properties)] 對話方塊中，檢視 [安全性 (Security)] 頁上指定的 [安全層級 (Security level)]。應用程式應使用處理序及元件層級存取檢查來支援細分授權。如此可讓應用程式利用角色來控制特定類別、介面和方法的存取。

注意 您必須為程式庫應用程式啟用處理序及元件層級存取檢查，否則無法使用角色型授權。

您是否強制執行元件層級存取檢查？
為了支援在元件、介面和方法層級上執行授權檢查，每個元件都必須在 COM+ 目錄中正確設定。請檢查應用程式中的每個元件，以確保已經選取元件之 [內容 (Properties)] 對話方塊中、[安全性 (Security)] 頁上的 [強制執行元件層級存取檢查 (Enforce component level access checks)]。

您是否傳送機密資料？
如果是，您使用什麼機制來妥善處理網路竊聽的風險？請務必在傳輸層加密用戶端與伺服器之間的連結，例如使用 IPSec。或者，確認您已為封包私密性層級驗證而設定 Enterprise Services 應用程式，因為封包私密性層級驗證可強制應用程式內外傳送的所有資料封包都使用 RPC 加密。

您是否透過防火牆進行通訊？
Enterprise Services 使用 DCOM，而 DCOM 則會使用 RPC 通訊。RPC 通訊會要求防火牆開放連接埠 135。檢閱您的防火牆和 Enterprise Services 設定，確定將其他開啟的連接埠數目減至最少。

DCOM 所動態配置的連接埠範圍可以加以限制，或使用端點對應來指定個別連接埠。如需詳細資訊，請參閱單元 17＜保障應用程式伺服器的安全＞。

您如何保護透過網路傳輸的機密資料？
您是否使用 SSL 或 IPSec？如果不使用 SSL 或 IPSec，遠端元件往來傳送的資料很容易會遭受資訊洩露和竄改的危險。檢討應使用什麼防範措施來解決網路竊聽的風險。

您如何驗證呼叫者？
請確定在 IIS 中已經針對您的應用程式虛擬目錄停用匿名存取。另外再檢查您是否使用 Windows 驗證。應用程式的 Web.config 應該包含下列設定。

<authentication mode="Windows" />

您是否使用 ASP.NET 檔案授權？
如果未使用，原因為何？藉由建立 .rem 或 .soap 檔案並在檔案中設定 NTFS 權限，您就可以使用 ASP.NET 檔案授權來控制遠端服務應用程式的端點。接著 ASP.NET FileAuthorizationModule 將存取權限授權給元件。如需詳細資訊，請參閱單元 13＜建置安全的遠端元件＞中的「授權」。

您是否使用 URL 授權？
檢查應用程式對於 <authorization> 元素的使用情形。UrlAuthorizationModule by 套用 <allow> 及 <deny> 標記來使用 ASP.NET。

您是否有防止將錯誤細節傳回用戶端？
檢查應用程式的設定，確認您已經正確設定 <customErrors> 元素，以免將錯誤細節傳回用戶端。請務必將 mode 屬性設定為 On ，如下所示。

<customErrors mode="On" />

您使用什麼識別身份來執行 ASP.NET？
檢查並確定您是使用最低特殊權限帳戶來執行 ASP.NET，例如預設的 ASPNET 帳戶，或 Windows Server 2003 上的網路服務帳戶。

您如何保護透過網路傳輸的機密資料？
您是否已經保障從用戶端到伺服器的通道安全？您可以使用傳輸層 IPSec 加密，或者您的應用程式也可以使用自訂加密接收來加密要求及回應資料。

您如何驗證呼叫者？
TcpChannel 並未提供驗證機制，因此您必須自行開發。檢查您的應用程式如何驗證其呼叫者。

您是否有限制用戶端？
遠端服務與 TcpChannel 是專門用於受信任的伺服器，其中遠端元件會信任其用戶端。您是否有限制允許連接至遠端元件的用戶端範圍，例如使用 IPSec 原則？

您是否有使用最小權限的處理序識別身份？
檢查您使用哪個帳戶來執行自訂主機處理序，並確認此自訂主機處理序已經設定為最小權限帳戶。

補充程式及更新

服務

通訊協定

帳戶

檔案及目錄

共用

連接埠

登錄

稽核和記錄

SQL Server 安全性

SQL Server 登入、使用者及角色

您執行哪些 SQL Server 服務？
SQL Server 會安裝四種服務。如果您只要求基本功能即可，那麼請停用 Microsoft Search Service、MSSQLServerADHelper 和 SQLServerAgent，以降低伺服器被攻擊的風險。

您是否使用分散式交易？
如果您的應用程式使用 COM+ 的交易服務來管理 SQL Server 間的交易，那麼資料庫伺服器就必須具有分散式異動協調器 (DTC) 服務。

如果您不使用分散式交易，請務必停用 DTC 服務。

SQL Server 針對哪些通訊協定進行設定？
SQL Server 支援多種通訊協定。請使用伺服器網路公用程式來檢查是否只啟用了 TCP/IP 通訊協定支援。

您是否已經強化 TCP/IP 堆疊？
若要檢查伺服器上的堆疊是否已進行強化，請使用 Regedt32.exe 並查看下列登錄機碼：

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

如果出現以下的子系機碼，代表 TCP/IP 堆疊已經強化：SynAttackProtect、EnableICMPRedirect、及 EnableReadGWDetect。

有關充分強化堆疊所需的必要機碼和適當數值的完整清單，請參閱本指南中＜How To＞一節的＜How To：強化 TCP/IP 堆疊＞。

您是否使用最低特殊權限帳戶來執行 SQL Server？
檢查您使用什麼帳戶來執行 SQL Server，並確認此帳戶為最低特殊權限帳戶。此帳戶不應該是系統管理帳戶或權限高的本機系統帳戶。另請確認此帳戶並非本機電腦上 Users 群組的成員。

您是否已經刪除或停用未使用的帳戶？
稽核伺服器上的本機帳戶，並檢查是否已停用所有未使用的帳戶。 稽核伺服器上的本機帳戶，並檢查是否已停用所有未使用的帳戶。

您是否已經停用「來賓 (Guest)」帳戶？
檢查是否已停用 Windows「來賓 (Guest)」帳戶，以便限制匿名連線連至您的資料庫伺服器。

您是否已經建立新的系統管理員帳戶？
預設的本機「系統管理員 (Administrator)」帳戶是攻擊的首要目標。為了提高安全性，請檢查您是否已經建立新的系統管理自訂帳戶，並且停用預設的「系統管理員 (Administrator)」帳戶。

您是否使用增強式密碼原則？
使用「本機安全性原則」工具來檢閱密碼原則。有關建議密碼原則的資訊，請參閱單元 18＜保護資料庫伺服器的安全＞中的「步驟 4：帳戶」。

您是否有限制遠端登入？
在「本機安全性原則」工具中檢查使用者權利指派，以確定並未將「從網路存取這台電腦」的使用者權利授與 Everyone 群組。

您是否已經停用 Null 工作階段？
檢查是否已停用 Null 工作階段以避免您的伺服器建立匿名 (未經驗證) 工作階段。若要檢查此項目，請執行 Regedt32.exe ，並確認 RestrictAnonymous 值已設定為 1，如下所示。

HKLM\System\CurrentControlSet\Control\LSA\RestrictAnonymous=1

用戶端是否使用 Windows 驗證來連線？
如果是，請檢查是否已啟用和強制執行 NTLM 驗證 (NTLMv2) 的最強版本。若要檢查是否強制執行 NTLMv2 驗證，請使用「本機安全性原則工具」。展開 [本機原則] 並選取 [安全性選項]，再連按兩下 [LAN Manager 驗證等級]。查看是否選取 [只傳送 NTLMv2 回應\拒絕 LM 和 NTLM]。

您是否已經設定 SQL Server 安裝目錄的使用權限？
審查 SQL Server 安裝目錄的使用權限，並確認該權限只提供最低的存取權線。如需詳細資訊，請參閱單元 18＜保護資料庫伺服器的安全＞中的「步驟 5：檔案及目錄」。

您是否已經移除 SQL Server 檔案的 Everyone 使用權限？
審查 SQL Server 檔案位置的使用權限 (預設位置是 \Program Files\Microsoft SQL Server\MSSQL)，並檢查 Everyone 群組是否已經自目錄 ACL 中移除。同時，確認只有 SQL Service 帳戶、Administrators 群組和本機系統帳戶才擁有完全控制權。

您是否已經保障安裝記錄檔的安全？
如果您已經安裝 SQL Server 2000 Service Pack 1 或 2，那麼系統管理員或服務帳戶密碼可能會保存在 SQL 安裝目錄中。請務必使用 Killpwd.exe 公用程式從記錄檔中移除密碼項目。

有關取得及使用此公用程式的資訊，請參閱 Microsoft 知識庫文件 263968《FIX: Service Pack Installation May Save Standard Security Password in File (英文)》。

伺服器上有哪些共用？
若要檢閱共用及相關的使用權限，請執行 [電腦管理] MMC 嵌入式管理單元，並選取 [共用資料夾] 下的 [共用]。檢查所有共用是否均有必要存在。移除不必要的共用。

Everyone 群組是否可以存取共用？
除非別有用意，否則請確定沒有將共用的存取權限授與 Everyone 群組，並且設定特殊使用權限來替代此權限。

您是否已經移除系統管理共用？
如果您不允許遠端管理伺服器，那麼請檢查是否已移除系統管理共用，例如 C$ 及 IPC$。

注意 有些應用程式可能需要使用系統管理共用。範例包括 Microsoft Systems Management Server (SMS) 及 Microsoft Operations Manager (MOM)。如需詳細資訊，請參閱 Microsoft 知識庫文件 318751《How To: Remove Administrative Shares in Windows 2000 or Windows NT4 (英文)》。

您是否已經限制 SQL Server 連接埠的存取？
檢閱您如何限制 SQL Server 連接埠的存取。檢查您的外圍防火牆是否可以禁止來自網際網路的直接存取。為了防止內部攻擊，請檢查您的 IPSec 原則，以確保 IPSec 原則會限制 SQL Server 連接埠的存取。

您是否將具名執行個體設定為接聽相同的連接埠？
如果您使用具名執行個體，請使用「網路伺服器公用程式」來檢查您是否將執行個體設定為接聽特定的連接埠。此舉可避免用戶端與伺服器之間的 UDP 交涉，這表示您不需要開啟額外的連接埠。

您是否已經保障 SQL Server 登錄機碼的安全？
使用 Regedt32.exe 來檢查 Everyone 群組是否已經從附加到下列登錄機碼的 ACL 中移除。

Administrators: Full Control
SQL Server service account: Full Control

您是否已經保障 SAM 的安全？
檢查您是否已經限制安全性帳戶管理員 (SAM) 的 LMHash 存放區，方法是在登錄中建立機碼 (非數值) NoLMHash ，如下所示。

HKLM\System\CurrentControlSet\Control\LSA\NoLMHash

如需詳細資訊，請參閱 Microsoft 知識庫文件 299656《How to Prevent Windows from Storing a LAN Manager Hash of Your Password in Active Directory and Local SAM Databases (英文)》。

您是否已經啟用 SQL Server 稽核？
檢查 SQL Server 稽核是否已經啟用。在 Enterprise Manager 的 SQL Server [內容 (Properties)] 對話方塊中，確認 [安全性 (Security)] 頁上的 [稽核層級 (Audit level)] 是設定為 [全部 (All)] 或 [失敗 (Failure)]。

您是否有記錄所有失敗的登入嘗試？
使用「本機安全性原則」工具來檢查您是否已啟用失敗登入嘗試的稽核作業。

您是否記錄整個檔案系統中所有失敗的動作？
使用「本機安全性原則」工具來檢查您是否已啟用物件存取稽核。接著檢查是否已啟用檔案系統整體的稽核。

您是否使用增強式 sa (系統管理員) 密碼？
確認 sa 帳戶使用增強式密碼。

重要 即使您從 SQL 驗證變更為 Windows 驗證，sa 帳戶仍然會處於啟用狀態。

此外，請確定您已經將增強式密碼套用到所有資料庫帳戶，尤其是特殊權限帳戶 (例如，sysadmin 及 db_owner 的成員)。如果您使用複寫，請檢查 distributer_admin 帳戶是否使用增強式密碼。

您是否已經移除 SQL Server Guest 帳戶？
當您安裝 SQL Server 時，如果 Windows Guest 帳戶已經啟用，那麼便會建立 SQL Server Guest 帳戶。檢查每個資料庫，並確定並未出現 SQL Server Guest 帳戶。如果出現 Guest 帳戶，請移除它。

注意 您無法從 Master、tempdb、以及複寫與散發等資料庫中刪除 Guest。

您是否已經移除 BUILTIN\Administrators 伺服器登入？
如果您的公司會區別網域系統管理員與資料庫系統管理員的角色，請移除 BUILTIN\Administrators SQL Server 登入。您可以建立一個特定的 Windows 群組，其中包含該位置的特定資料庫系統管理員，這是一個不錯的解決辦法。

您是否已經移除 Public 角色的權限？
檢閱每個資料庫中授與 Public 角色的權限。請確認 Public 角色並無權限存取任何資料庫物件。

共有多少成員屬於系統管理員 (sysadmin) 角色？
檢查系統管理員 (sysadmin) 角色包含多少登入。在理想情況下，系統管理員不應超過兩位使用者。

您是否有授與登入者受限制之資料庫使用權限？
檢閱授與每個資料庫使用者帳戶的權限，並確認每個帳戶 (包括應用程式帳戶) 只具有最低的必要權限。

您是否已經移除範例資料庫？
使用 SQL Server Enterprise Manager 來檢查所有範例資料庫 (包括 Pubs 和 Northwind) 是否已經移除。

您是否已經保障預存程序的安全？
檢查並確定 Public 角色或 Guest 使用者均無法存取任何預存程序。若要授權預存程序的存取，您應該將伺服器的 SQL Server 登入對應到資料庫使用者，將資料庫使用者放置在使用者定義的資料庫角色中，然後讓權限套用到此角色，以便提供應用程式的預存程序的執行存取權限。

您是否已經限制 cmdExec 的存取？
cmdExec 是 SQL Server 代理程式用來執行由 SQL Server 代理程式所排定的 Windows 命令列應用程式和指令碼的函數。檢查 cmdExec 的存取是否已經限定為系統管理員 (sysadmin) 角色的成員。

若要查明，請使用 SQL Server Enterprise Manager 來展開管理 (Management) 節點。在 [SQL Server 代理程式] 上按一下滑鼠右鍵，並顯示 [SQL Server 代理程式屬性] 對話方塊。按一下 [作業的系統] 索引標籤，並檢查是否已經選取 [只有擁有系統管理員權限的使用者可以執行 CmdExec 及 ActiveScripting] 作業步驟。

路由器

防火牆

交換機

您是否已經套用最新的補充程式及更新？
洽詢網路硬體製造商，確認您已經取得最新的補充程式。

您是否對輸入與輸出的封包進行篩選？
如需詳細資訊，請參閱《Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing (英文)》：http://www.rfc-editor.org/rfc/rfc2267.txt。

您是否封鎖 ICMP 流量？
確認您已經封鎖外部周邊路由器的網際網路控制訊息通訊協定 (ICMP) 流量，以防止像是串連 ping 溢流等攻擊和其他潛在的 ICMP 弱點。

您是否使用數值 0 或 1 來防止存留時間 (TTL) 過期的訊息？
此舉可預防路由器追蹤造成資料公開。

您是否接收或轉寄廣播流量？
應該要篩選的來源位址會顯示在 [表 22.1]。

[表 22.1] 應該要篩選的來源位址

您是否已經停用未使用的介面？
確認僅啟用路由器的必要介面。

您是否使用增強式密碼原則？
您應該使用增強式密碼原則來緩和暴力式及字典攻擊所造成的風險。

您是否使用靜態路由？
藉由使用靜態路由，系統管理介面首先必須修改以變更路由。

您是否有稽核 Web 方面系統管理介面？
可能的話，請關閉外部管理介面，然後以 ACL 使用內部存取方法。

您是否使用路由器的記錄功能？
檢查您的路由器是否記錄所有拒絕動作。

您是否有使用入侵偵測系統?
入侵偵測系統 (IDS) 可以顯示入侵者會企圖攻擊何處。

您是否已經套用最新的補充程式及更新？
洽詢網路硬體製造商，確認您已經取得最新的補充程式。

您是否有記錄經過防火牆的所有資料傳輸？

記錄多久循環一次？
確認您維護健全的記錄循環以便於快速資料分析。

防火牆時鐘是否與其他網路硬體同步？

您是否已經套用最新的補充程式及更新？
洽詢網路硬體製造商，確認您已經取得最新的補充程式。

您是否已經停用出廠預設設定？
為了改善危險預設值的安全性，請檢查您是否已經變更所有出廠預設密碼和簡單網路管理協定 (SNMP) 社群字串，以防止網路列舉或完全控制交換機。

您是否已經停用未使用的服務？
確認關閉所有未使用的服務。此外，請確認停用 Trivial File Transfer Protocol (TFTP)，移除外部網路管理點，同時設定 ACL 來限制系統管理員存取權。