| 适用于 Windows 2000 Advanced Server、Internet
信息服务 5.0、SQL Server 2000 和 .NET Framework 的最佳安全方案
摘要：由 Microsoft 工程师使用 Microsoft .NET Framework、Microsoft Windows 2000 Advanced Server、Internet 信息服务 5.0 和 Microsoft SQL Server 2000 构建的 Web 站点，在 eWeek OpenHack 4 竞赛中成功顶住了 82,500 多次攻击，并一举胜出。本文介绍此解决方案的构建和配置方法，并为软件开发人员和系统管理员确保自己的解决方案的安全性提供了最佳方案。（本文包含一些指向英文站点的链接。） 目录
2002 年 10 月，eWeek Labs 举行了第四届年度 OpenHack 联机安全性竞赛。此次年度竞赛（这是 Microsoft® 第三次参加此项赛事）旨在通过将系统暴露在 Web 真实而险恶的环境中来测试企业的安全性。eWeek 向 Microsoft 和 Oracle 提供了 Web 应用程序示例，要求双方使用各自的技术重新开发此应用程序。随后，eWeek 又邀请美国各地的计算机用户破坏最终站点的安全性，成功者可领取一定数额的奖金。可接受的破坏包括跨站点的脚本攻击、动态 Web 页面源代码泄漏、破坏 Web 页面、向数据库发送恶意 SQL 命令以及窃取所用数据库中的信用卡数据。 Microsoft 使用 Microsoft® .NET Framework 开发其应用程序。Microsoft® .NET Framework 是一个完整的 Windows 组件，支持构建和运行下一代应用程序和 XML Web Service。此应用程序以 Microsoft® Internet 信息服务 (IIS) 5.0 为宿主，并使用 Microsoft® SQL Server™ 2000 作为其数据库。所有服务器都运行在 Microsoft® Windows® 2000 Advanced Server 操作系统上。（值得注意的是，如果竞赛时已发布带有 IIS 6.0 的 Microsoft® Windows Server 2003，则当时会使用此版本的操作系统。如果使用 Windows Server 2003，则可以省去竞赛中用于“锁定”操作系统和 Web 服务器的几个步骤。） 竞赛结果可以在 http://www.eweek.com/category2/1,3960,600431,00.asp 中找到。总而言之，Microsoft 的解决方案顶住了 82,500 多次攻击。正如它在第一届和第二届 OpenHack 竞赛中表现的一样，Microsoft 安然无恙地从 OpenHack 4 竞赛中胜出。本文将对竞赛中使用的各种技术加以介绍，以说明此解决方案的构建和配置方法，并向确保自己的解决方案安全性的开发人员和系统管理员介绍如何应用这些最佳方案。 此应用程序本身模拟 eWeek eXcellence Awards Web 站点。在此站点中，用户可以登记其公司的产品或服务以参与获奖评选。用户可以设置一个帐户，以输入产品或服务进行评选，可以提交信用卡号支付报名费，还可以获取有关奖项本身的信息。Microsoft 使用 .NET Framework 构建其解决方案，.NET Framework 是一个完整的 Windows 组件，用于构建和运行应用程序及 XML Web Service。大多数开发均围绕 Framework 的 ASP.NET、ADO.NET 和加密类库进行，这三项技术提供的功能分别用于构建基于 Web 的应用程序，访问和使用数据，以及加密、解密和确保数据完整性。 窗体身份验证Microsoft® ASP.NET 类提供了几个用于验证用户身份的选项（即，使用一些凭据，如用户名和密码，来确认给定用户的身份）。这些选项包括集成的 Windows 身份验证、基本身份验证、摘要身份验证、Microsoft® .NET Passport 以及客户证书等。对于每个 eWeek 请求，OpenHack 解决方案选择了基于窗体的或自定义的身份验证。 当用户通过窗体身份验证登录时，系统将创建一个加密的 cookie，用于在整个站点中跟踪用户。（从技术角度而言，cookie 是一个由 Web 站点生成的纯文本字符串，可进入用户的 Web 浏览器内存，用于对浏览站点的用户进行标识。） 如果用户在未登录的情况下请求一个安全页面，系统会将此用户重定向到登录页面，所有这些都只需要使用应用程序的基于 XML 的 Web.config 文件进行配置就可以实现。该文件由 Microsoft® Visual Studio® .NET（用于构建基于 .NET Framework 的应用程序的集成开发环境）自动生成，用于存储 ASP.NET Web 应用程序的配置。 在应用程序的根文件夹中，我们向
Web.config 文件的 <authentication mode="Forms"> <forms loginUrl="Login.aspx" name="OPSAMPLEAPP"/> </authentication> 此顶层配置文件应用到此应用程序的所有页面。然后，用第二个 Web.config 文件创建子目录。此文件只应用到应用程序中的少数几个选定页面，以防未经身份验证的用户（即匿名用户）对其进行访问。第二个 .config 文件继承了顶层 .config 文件的身份验证信息。 <?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<authorization>
<deny users="?" />
</authorization>
</system.web>
</configuration>
通过这种方式使用这两个 .config 文件，未经身份验证的用户只能访问主页和其他少数几个页面，而已通过身份验证的用户则还可以访问站点上那些需要用户登录的页面。 登录页本身包含供用户输入用户名和密码的字段，并通过安全套接字层 (SSL) 将其返回给 Web 服务器，从而防止某些用户“窃取”网络中传递的凭据。用户创建新帐户后，Web 应用程序将使用 Triple DES 算法将新密码加密（详见存储机密信息一节的介绍），并将其与用户名一同存储在数据库中。以后登录时，Web 应用程序将使用 Triple DES 对在登录页输入的密码进行加密，然后与数据库中存储的加密密码进行比较。如果这两个密码匹配，Web 应用程序将使用 ASP.NET 库中的 System.Web.Security.FormsAuthentication 类生成一个包含用户的用户名和姓名的加密 cookie。此 cookie 将返回给用户并储存在用户的浏览器中，直到超时为止。用户此后向 Web 站点发送的任何请求都会包含此 cookie。所有涉及 cookie 的传输都使用 SSL 进行，以防“重放”攻击（即攻击者从网络中窃取到 cookie，然后使用它假冒用户进行操作）。强烈建议您通过公共网络发送可用于访问敏感信息的敏感信息或凭据时使用 SSL。 输入有效性验证OpenHack 在应用程序中实现了不同级别、不同类型的有效性验证，以确保代码以外的输入（即用户输入）无法更改应用程序的操作。验证输入有效性是一个关键的最佳安全方案，有助于防止缓存溢出、跨站点的脚本攻击以及其他潜在的在应用程序上下文中执行恶意代码的尝试。提供多层保护（正如此处所做的）是另一个重要的最佳安全方案，称为“层层设防”。做最坏的打算并假定解决方案的一层或多层可能遭到破坏，这往往很重要。 第一道防线是由 ASP.NET（特别是 RegularExpressionValidator 类和 RequiredFieldValidator 类）提供的有效性验证控制，可确保提供了所需的所有输入，且均为有效数据。只允许使用用于提供所需用户操作的字符，在本例中，字符范围很有限。例如，某些字段只允许输入“[ ',\.0-9a-zA-Z_]*”，即空格、单引号、逗号、句号、字母和数字。其他可用于向 Web 站点发送恶意脚本的字符被禁止使用。 除文本框以外，本应用程序还通过“查询字符串”接受某些输入，查询字符串是动态 URL 的一部分，包含用于生成页面的参数。通过 System.Text.RegularExpressions.Regex 类提供的功能，用正则表达式对数据进行验证，如下所示： Regex isNumber = new Regex("^[0-9]+$");
if(isNumber.Match(inputData) ) {
// 使用它
}
else {
// 丢弃它
}
正则表达式是用于匹配文本模式的字符和语法元素集合。在 OpenHack 应用程序中，它们用于确保查询字符串内容是正确且无恶意的。 此应用程序中的所有数据访问均通过参数化存储过程完成，这些存储过程是使用 T-SQL 语言开发的，并且根据定义在数据库内运行。将与数据库的交互限制到存储过程，这通常是一个最佳方案。如果不存在存储过程，则 SQL 查询必须由 Web 应用程序动态构造。如果 Web 层遭到破坏，攻击者就可以向数据库查询中插入恶意命令，以检索、更改或删除数据库中存储的数据。使用存储过程，Web 应用程序与数据库的交互操作仅限于通过存储过程发送的几个特定的严格类型参数。每当开发人员使用 .NET Framework 调用存储过程时，系统都会对发送到此存储过程的参数进行检查，以确保它们是存储过程可接受的类型（如整数、8 个字符的字符串等）。这是 Web 层有效性验证上的又一个保护层，可确保所有输入数据格式正确，而且不能自行构造为可操作的 SQL 语句。 任何数据在返回给用户前均采用 HTML 编码。这只需使用 System.Web.HttpServerUtility 类中的 HtmlEncode 方法即可实现，如下所示。 SomeLabel.Text = Server.HtmlEncode(username); HTML 编码有助于防止跨站点的脚本攻击。攻击者一旦破坏了数据库，便可向记录中输入脚本，此脚本随后返回给用户并在浏览器中执行。通过 HTML 编码，大多数脚本命令都自动转换为无害文本。 存储机密信息安全地存储机密信息（如提供数据库登录信息的数据库连接字符串）很重要，这样可以防止攻击者访问并使用这些机密信息来读取、操作数据或重新配置解决方案。由于本解决方案使用了集成的 Windows 身份验证来访问数据库，因此连接字符串的价值对于攻击者来说已经显著降低，这是因为连接字符串只包含服务器的位置和数据库名称，而不包括特定的凭据（如密码）。 默认情况下，Visual Studio .NET 中的数据库连接向导将把连接字符串作为属性值存储在“内含代码”文件（此文件包含应用程序的核心逻辑，这与提供用户界面定义的文件不同）中。 这为开发人员访问字符串提供了方便。但是，如果攻击者设法登录到包含源代码和 .config 文件的物理计算机上，便有可能读取连接字符串并用它来访问数据库以进行恶意破坏。 在生产环境中，通常建议您对连接字符串和任何其他所需的凭据进行妥善地保护。一种保护凭据的方法是 OpenHack 4 中采用的方法：加密连接字符串，将其存储在注册表中，并使用访问控制列表 (ACL) 确保只有系统管理员和 ASPNET 辅助进程（IIS 一节中给出了定义）才能访问注册表项。 使用 Windows 2000/XP 数据保护 API (DPAPI) 函数 CryptProtectData 和 CryptUnprotectData 将数据库连接字符串加密，使用这两个函数可以将机密信息加密，而无需直接管理（或存储）随后用于访问这些机密信息的注册表项。 尽管 DPAPI 非常适合用于加密用户或计算机特定数据，但对于加密存储在共享数据库中的信息（如信用卡号码和密码），却不是一种很有效的方法。这是因为 DPAPI 函数根据本地计算机和/或用户信息创建和内部存储加密密钥。在 Web 领域方案中，Web 服务器将使用自己的加密密钥，以防它们访问相同的加密数据。 因此，为了演示 Web 领域方案中使用的方法，生成了一个随机的 Triple DES 加密密钥和初始化向量。此功能是用 .NET Framework 的 System.Security.Cryptography 类中的 TripleDES 类提供的。这些密钥用于对称地加密存储在数据库中的密码和信用卡信息。为了存储信用卡信息，选择了加密性很强的随机第一块作为处理技术。 生成密钥的备份副本后，我们使用 DPAPI 将其加密并存储到注册表中，然后又使用 ACL 将访问权限仅授予系统管理员和 ASPNET 辅助进程。将密钥加密，可确保当攻击者实际定位并访问数据时，如果不先将密钥解密，便无法解密数据。这是“层层设防”的又一个典型例子。 为了防止攻击者攻击 Web 服务器本身，我们对 Windows 2000 Advanced Server 中的 Internet 信息服务 (IIS) 5.0 Web 服务器进行了适当的更改。首先，安装了 TechNet Web 站点上列出的所有公用安全性修补程序，以确保拥有最新的增强功能。运行任何软件时，安装最新的 Service Pack 和修补程序是一种非常关键的安全方案。 然后，将磁盘上的默认 Web 站点位置从默认位置 c:\inetpub\ 更改到其他卷。因此，一旦系统在某些方面遭到破坏，攻击者将很难导航到此目录树，除非确实了解此目录树的实际位置，也就是说，攻击者无法通过输入 ..\ 作为位置说明来轻松地访问 C: 驱动器。 接着，使用静态 Web 服务器附带的模板运行 IIS 锁定工具。此操作删除了此应用程序中未使用的所有其他动态内容类型。以这种方式减少暴露给潜在攻击者的表面区域通常是很重要的最佳方案。可以免费获得 IIS Lockdown Tool。它是一个很出色的资源，所有运行 IIS 的系统管理员都应该使用它。 此时，我们已经安装了 .NET Framework Redistributable（它是运行 .NET Framework 应用程序所必需的）、.NET Framework Service Pack 2、最新的 .NET Framework 问题更正和 MDAC 2.7（.NET Framework 所需的组件）。 在此方案中，应用程序只使用带有 .aspx 扩展名的动态文件和几个用于图像与样式表的静态内容类型。由于不需要 .NET Framework 安装的其他 IIS 应用程序映射，因此将这些扩展重新绑定到 IIS 锁定工具附带的 404.dll 扩展。这样做也是为了减少解决方案暴露的表面区域。 此应用程序使用低权限的默认本地服务帐户（ASPNET 帐户）运行 ASP.NET 代码。“最低权限”原则对于所有管理人员来说都很重要，决不要向帐户授予并非绝对需要的权限。以这种方式锁定解决方案相当于减少暴露的表面区域。 （ASPNET 帐户是在安装 .NET Framework Redistributable 时作为本地帐户创建的，只属于创建该帐户的计算机上的“用户”组。因此它拥有所有与此“用户”组相关的权限，并可与此用户组有权访问的任何资源进行交互。此外，它在默认情况下拥有对 Temporary ASP.NET Files 目录和 %windir%\temp 的完全访问权限，以及对 Framework 安装目录的读取权限。） 我们将此 ASPNET 帐户添加到 IIS 锁定工具创建的本地“Web 应用程序组”，以防进程在被偷袭时运行任何未得到授权的命令行可执行程序。 然后，我们修改了此用户组的权限，并允许此用户组中的用户运行应用程序需要的 .NET Framework C# 编译器和资源转换器（Csc.exe 和 Cvtres.exe）。 IIS 锁定工具安装了 URLScan 2.5，它是一个 ISAPI 过滤器，可根据查询长度和字符集等规则监视和过滤发送到 IIS Web 服务器的所有输入请求。将 URLScan 配置成只允许应用程序中使用的扩展集，并用它阻止较长的请求。这是深度防护的另一个示例，它是防止通过用户输入插入恶意代码的额外保护层。TechNet 和 IIS 锁定工具中免费提供了 URLScan。与前面提到的 IIS 锁定工具一样，URLScan 是一种很出色的资源，所有运行 IIS 的系统管理员都应该使用它。 我们为 Web 内容目录设置了适当的权限，从而授予 ASP.NET 进程对内容文件的读访问权限，授予匿名用户对所提供内容的适当只读访问权限。 只有系统帐户和系统管理员组的成员才对 IIS 和 URLScan 的日志目录具有访问权限。限制对日志文件的访问通常很有必要，它使攻击者很难对其进行更改，以覆盖其中的记录或隐藏有关所受攻击的有用信息。 Windows 2000 Advanced Server 操作系统 本次竞赛使用的服务器全部运行安装了 Service Pack 3（它是竞赛时最新的 Service Pack）的 Windows 2000 Advanced Server 操作系统。还安装了自 Service Pack 3 发行以来 TechNet Web 站点上发布的所有安全性修补程序。使用最新的安全性修补程序对系统管理员同样是一个很重要的最佳安全方案。 安装这些更新会对某些配置进行更改，从而进一步增强操作系统级的完整性。首先，禁用了所有不必要的操作系统服务，这通常也是一个最佳方案。通过关闭这些服务，可以释放系统资源并减少暴露给攻击者的表面区域。可以禁用的特定服务将随每个解决方案的需要而变化。Messenger、Alerter 和 ClipBook 只是已禁用服务的几个示例。 强烈建议您阅读 Windows 2000 Server Resource Kit，以帮助确定不需要的服务。然后进行相应的测试，以确保应用程序在没有这些服务的情况下也能正常工作。最后，将这些服务的启动状态更改为 disabled 以关闭它们。 在应用程序中，我们还使用注册表编辑器 (Regedit.exe) 更改了四个注册表设置，以便进一步增强安全性。我们将所有这些都作为最佳方案推荐给您，只要您不需要已禁用的功能即可。
另外，尽管与防止攻击没有直接关系，我们还启用了几个审核日志以覆盖登录和注销事件、帐户管理、策略更改和系统事件。这有助于我们在竞赛中更好地监视服务器。 从 Windows 2000 开始，Microsoft 已经使用 IP 安全标准 (IPSec)（IPv4 协议的扩展）为管理 Internet 协议 (IP) 通信的身份验证和加密提供支持。下面的图 1 显示了“服务器(请求安全设置)属性”对话框的默认策略。我们特地为竞赛创建了一种策略。
图 1：“服务器(请求安全设置)属性”对话框 IPSec 规则是在 Microsoft 管理控制台 (MMC) 管理单元的“本地安全设置”中进行配置的，如上所述。这些策略在增强和确保 OpenHack 服务器之间允许的通讯的安全性方面起到了主要作用。这些规则使我们能够通过以下方法，增强最低特权的最佳方案：
IPSec 规则有三个主要部分：标识由 IPSec 处理的通信的过滤器，过滤器找到这样的通信时要采取的操作，以及用于建立安全性关联的身份验证机制。如果要进行通信的两个系统没有用于标识通信的规则，两者之间也没有公用的身份验证机制，则它们将无法建立连接。 使用 IPSec 锁定解决方案的第一步是完全了解不同系统之间的通信路径，以便建立适当的 IPSec 过滤器。应允许 Web 服务器与 SQL 服务器数据库进行通信；远程访问服务器应允许系统管理员使用虚拟专用网络 (VPN) 访问网络的管理段；管理服务器应授予 VPN 客户端创建 Windows 2000 终端服务客户端会话的权限（以便访问运行于远程计算机桌面上的应用程序）以及访问和复制文件以便在管理服务器上共享的权限；所有系统应允许管理服务器为其专用接口生成管理终端服务会话；最后，所有系统应能够访问管理系统上共享的特定文件。当系统之间所需的连接按每个端口进行映射时，我们便在每一个系统上创建了 IPSec 过滤器。 然后，必须确定处理通信的方法，因为通信是由系统上的过滤器识别的。对于 OpenHack 4，我们定义了四个可以采取的操作（称为“过滤器操作”）：
阻止规则就是丢弃数据包。此规则与“默认拒绝”规则的功能相同，它意味着“如果我们未明确地允许通信，则禁止通信”。允许规则允许通信通过，而无需考虑通信来源。此功能用于允许公开访问 Web 应用程序。 尽管使用证书对通信进行身份验证要求我们从公用的证书颁发机构 (CA) 生成并分发 IPSec 证书，但它却显著增强了系统进行安全通信的能力。值得注意的是，我们使用了一个独立的 CA。授予所有证书后，该 CA 将从网络中删除。如果生产时不再需要此 CA，请务必遵循此方法，因为这是减少解决方案表面区域的另一个好方法。 使用 IPSec 证书能够确保源系统和目标系统的标识，包括访问远程访问服务器的远程系统管理员。通过配置策略以便使用 SHA1 散列对所有传输进行签名，可确保数据包在后端系统之间传递时不会被攻击者成功修改。 我们使用 MD5 加密算法对管理服务器通信进行了加密。使用这种方法，即使攻击者能够破坏一个面向 Internet 系统的安全性，也无法窃取专用网络的通信。这就使得系统管理员能够安全地连接到实时的 Web 站点以进行应用程序更新。 IPSec 使用具有最高优先权的专用规则来处理规则。因此，每个系统最初具有以下两个规则：
然后，针对每个系统构建规则。向 Web 服务器和数据库服务器之间的通信提供“身份验证和签名”过滤器操作；向与管理服务器的通信赋予“身份验证、签名和加密”过滤器操作；将对 Web 站点的公开访问设置为允许访问。 下面显示了使用 IPSec 建立的 OpenHack 4 应用程序的逻辑连接。
图 2：使用 IPSec 的应用程序逻辑连接 OpenHack 4 的部分要求是能够在竞赛过程中更新应用程序。这项功能是通过使用第 2 层隧道协议 (L2TP) 创建 VPN、终端服务和受限文件共享实现的。
图 3：用于创建 VPN（终端服务）的 L2TP 首先，L2TP 需要 IPSec 证书以建立连接。我们用适当的证书配置了几个远程系统管理员计算机。然后为远程系统管理员创建启用了远程访问的帐户。 为了建立 VPN 连接，系统管理员必须在系统上安装了 IPSec 证书以及远程访问帐户凭据。简而言之，IPSec 证书以不可导出的格式将证书的专用部分嵌入到本地计算机的证书存储区中。这意味着此证书将无法移植并在其他系统上使用。实际上，我们能够确保系统管理员只能在允许的远程管理工作站中使用 VPN 客户端帐户，从而将对解决方案的管理访问降低到最低程度。 对 L2TP 会话进行身份验证后，系统管理员工作站将获得管理网络上的 IP 地址。建立到管理网络的 VPN 隧道后，系统管理员即可打开到管理服务器 OHTS 的终端服务会话，并可使用管理服务器上的“收件箱”和“发件箱”文件共享，以丢弃更改的站点内容或检索文件进行分析。所有系统都是独立的（即不属于某个域），因此将共享访问和终端服务会话配置成通过增强的不明显的密码（详见密码一节的介绍）使用系统上的本地帐户。所用的共享被限制为只允许对“发件箱”进行读操作和对“收件箱”进行写操作。 大量的管理工作是在管理服务器“终端服务”会话中进行的。在此会话中，系统管理员将连接到任何其他系统的远程管理终端服务会话，从根本上“嵌套”终端服务会话。然后，可以连接到管理服务器上的“收件箱”和“发件箱”共享，并根据所服务的系统的需要丢弃或检索文件。支持这些管理功能的所有通信都需要使用 IPSec，如上所述。 OpenHack SQL Server 2000 数据库运行在专用计算机上，这是一种“层层设防”措施。即使 Web 层崩溃，数据库及它所包含的所有信息仍会受到隔离和保护。 如上所述，我们的解决方案使用集成的 Windows 身份验证连接到数据库。这是一种值得借鉴的方法，因为它不需要开发和安全存储用于访问数据库的密码。 为了确保向后兼容，Windows 2000 和 Windows XP 支持几种类型的身份验证协议。由于只有实现 NTLMv2 身份验证的计算机才能访问我们的数据库服务器，因此强烈建议将 LAN 管理器身份验证级别更改为“仅限于 NTLMv2”。注意，使用其他配置，Windows 95、Windows 98 和带有 Service Pack 4 及更高版本的 Windows NT Server 4.0 也可以支持 NTLMv2。通过限制所支持的身份验证协议的数量，系统管理员最大限度地减少了暴露给攻击者的表面区域。
图 4：设置 LAN 管理器身份验证级别 使用 SQL Server 与使用 Windows 一样，我们需要小心地安装、配置和运行必要的服务，以减少暴露给潜在攻击者的数据库表面区域。对于 OpenHack，我们未安装升级工具、调试符号、复制支持、联机图书或 Dev 工具组件。 该安装是在 NTFS 分区上进行的，因为它可以为 SQL Server 使用的文件和文件夹提供额外的基于 ACL 的安全保护。下一步，通常也是最关键的一步，是安装 SQL Server 2000 Service Pack 2 及所有最新的修补程序。 在服务帐户为 localSystem 的计算机中通常可以找到 SQL Server 安装程序。尽管在锁定良好的专用网络中，这是可以接受的，但由于它是基础计算机上的管理帐户，因此仍具有远远超过 SQL Server 服务真正所需的权限。如果要求服务帐户能够访问网络资源（如备份到网络驱动器时、使用日志传送时或使用复制支持时），则最好选择低权限的域帐户。但如果您的环境不需要这些功能，则完全可以选择低权限的本地帐户。在本次竞赛中，由于不打算使用这些功能，而且为了坚持“最低权限”原则，我们使用了本地用户帐户。 我们使用以下设置创建了一个新的 NT 本地用户帐户：
创建新用户帐户后，我们使用 SQL Server Enterprise Manager 更改了启动服务帐户信息，强制数据库服务以此用户的身份运行。
图 5：更改启动服务帐户信息 为了坚持只运行所需服务的思想和最佳安全方案，我们使用 Services MMC 管理单元停止 Distributed Transaction Coordinator (MSDTC) 服务，并将其设置为手动启动，这样 OpenHack 数据库就不会运行事务，服务器本身也不会运行 COM+ 应用程序。这里我们看到在专用计算机上运行数据库服务器的另一个优势：比与其他服务器和服务并行运行的服务器具有更强的减少周围表面区域的能力。 还可以通过禁用 SQL Server 代理和 Microsoft 搜索服务进一步减少表面区域，因为我们的数据库解决方案不需要此功能。 下一步，由于更多考虑的是可靠性而非安全性问题，我们设置了 Microsoft SQL Server 服务本身的属性，并将恢复操作更改为出现故障后重新启动服务。这样做是为了在出现故障时尽量减少停机时间。
图 6：将恢复操作更改为出现故障后重新启动服务 然后我们设置了 Server Network 实用程序，并将网络属性从“直接客户端广播”更改为“隐藏 SQL Server”。还删除了“命名管道”协议，因为我们只需要 TCP/IP。 作为此配置的一部分，我们返回到前面的配置，为 SA 帐户设置了非常强大的密码。即使在 Windows 身份验证模式下运行，也建议采用这种做法。如果以后通过企业管理器工具或直接通过注册表从身份验证模式切换到混合模式，您希望确保系统是安全的（即使系统管理员当时忘记设置 SA 密码），也可以使用这种方法。在这种方法中，最好做最坏的打算。 我们将默认的登录审核设置更改为 Failure。此操作将登录 SQL Server 数据库的所有失败尝试都写到错误日志和事件日志，该信息对识别攻击数据库的尝试非常有用。 然后，我们删除了默认的 Northwind 和 Pubs 数据库，以减少暴露给潜在攻击的表面区域。 完成所有步骤后，我们创建了最终解决方案中使用的 Awards 数据库。然后仔细检查表和存储过程，并确保与应用程序关联的帐户对存储过程只有执行权限，而对实际表没有任何权限。这使我们能够控制对存储过程的访问并限制对它的操作，而不必担心针对表直接运行的特殊 SQL 查询。此外，我们还确保了此帐户在 SQL Server 中没有任何其他的特权和权限。 确保任何服务器安全性的关键一步是选择不会被轻易猜出的长而复杂的密码。理想情况下，一个出色的密码应至少包括以下四组字符中的三组：小写 a 至 z、大写 A 至 Z、数字 0 至 9，以及非字母数字符号（如“>”、“*”、“&”等）。为了尽可能保证安全，密码应由以上四组中的每一组字符以及使用 ALT 键生成的字符组成。利用这些字符集创建长度至少为八个字符的密码，可最大限度地降低攻击者推测出登录凭据的机会。这是 OpenHack 解决方案中的每个服务器都使用的方法，也是我们极力向您推荐的方法。 确保 OpenHack 解决方案安全性所采取的所有步骤并非适用于每个 Web 解决方案。这些步骤也并不能代表开发人员和系统管理员在确保解决方案的安全性时应采取的所有方法。每个项目都具有独特性，需要开发人员和管理员一起找出潜在的攻击因素及预防措施。也就是说，OpenHack 4 表明上述建议非常有价值。即使它们不能全部直接应用到您的解决方案中，也应从中提取一些关键的好方案，以便在构建安全解决方案时以一种形式或另一种形式加以应用：
|
