IIS 有问必答 – 2003 年 12 月
有关 Internet 信息服务的热点问题及其解答
本页内容
 | 什么是 Network Service？ |
| Windows 2000 Professional 中 IIS 5.1 的连接数限制为 10 个吗？ |
| IIS Lockdown 工具如何处理应用程序映射？ |
什么是 Network Service？
问：在 IIS 6 中，Web 应用程序的工作进程设置为以进程标识“Network Service”运行。在 IIS 5 中，进程外 Web 应用程序则设置为以 IWAM_<服务器名> 帐户运行，这个帐户是普通的本地用户帐户。可否提供有关这个新帐户的信息，它对于安全性以及管理来说很重要吗？
答：Network Service 是 Windows Server 2003 中的内置帐户。您说得很对，了解 IIS 5 上的本地用户帐户（IUSR 和 IWAM）与这个内置帐户之间的区别是非常重要的。为了理解这一点，您应该知道，Windows 操作系统中的所有帐户都分配了一个 SID（安全标识，Security ID）。服务器是根据 SID，而不是与 SID 相关的名称来识别服务器上所有帐户的，而你我在与用户界面进行交互时，则是使用名称进行交互的。服务器上创建的绝大部分帐户都是本地帐户，都具有一个唯一的 SID，用于标识此帐户隶属于该服务器用户数据库的成员。由于 SID 只是相对于服务器是唯一的，因此它在任何其他系统上无效。所以，如果您为本地帐户分配了针对某文件或文件夹的 NTFS 权限，然后将该文件及其权限复制到另一台计算机上时，目标计算机上并没有针对这个迁移 SID 的用户帐户，即使其上有一个同名帐户也是如此。这使得包含 NTFS 权限的内容复制可能出现问题。
内置帐户是由操作系统创建的、一类较为特别的帐户或组，例如 System 帐户、Network Service 和 Everyone 组。这些对象的重要特征之一就是，它们在所有系统上都拥有一个相同的、众所周知的 SID。当将分配了 NTFS 权限的文件复制到内置帐户时，权限在服务器之间是有效的，因为内置帐户的 SID 在所有服务器上都是相同的。Windows Server 2003 服务中的 Network Service 帐户是特别设计的，专用于为应用程序提供访问网络的足够权限，而且在 IIS 6 中，无需提升权限即可运行 Web 应用程序。这对于 IIS 安全性来说，是一个特大的消息，因为不存在缓冲溢出，怀有恶意的应用程序无法破译进程标识，或是对应用程序的攻击不能进入 System 用户环境。更为重要的一点是，再也不能形成针对 System 帐户的“后门”，例如，再也无法通过 InProcessIsapiApps 元数据库项利用加载到 Inetinfo 的应用程序。
Network Service 帐户在创建时不仅仅考虑了在 IIS 6 中的应用。它还具有进程标识 W3WP.exe 的绝大部分（并不是全部）权限。如同 ASPNET 用户为了运行 ASP.net 应用程序，需要具有 IIS 5 服务器上某些位置的访问权限，进程标识 W3WP.exe 也需要具有类似位置的访问权限，而且还需要一些默认情况下没有指派给内置组的权限。
为了管理的方便，在安装 IIS 6 时创建了 IIS_WPG 组（也称为 IIS 工作进程组，IIS Worker Process Group），而且它的成员包括 Local System（本地系统）、Local Service（本地服务）、Network Service（网络服务）和 IWAM 帐户。IIS_WPG 的成员具有适当的 NTFS 权限和必要的用户权限，可以充当 IIS 6 中工作进程的进程标识。以下位置具有指派给 IIS_WPG 的权限：
| • | %windir%\help\iishelp\common – 读取 |
| • | %windir%\IIS Temporary Compressed Files – 列出、读取、写入 |
| • | %windir%\system32\inetsrv\ASP Compiled Template – 读取 |
| • | Inetpub\wwwroot（或内容目录）- 读取、执行 |
另外，IIS_WPG 还具有以下用户权限：
| • | 忽略遍历检查（SeChangeNotifyPrivilege） |
| • | 作为批处理作业登录（SeBatchLogonRight） |
| • | 从网络访问此计算机（SeNetworkLogonRight） |
因此，Network Service 帐户提供了访问上述位置的权限，具有充当 IIS 6 工作进程的进程标识的充足权限，以及具有访问网络的权限。
Windows 2000 Professional 中 IIS 5.1 的连接数限制为 10 个吗？
问：我听说 Windows 2000 Pro 上 IIS 5.1 的连接数被限制为 10 个。这使得它不太适合我们的应用场合，我在想是否可以通过注册表设置或其他变通方法来提高操作系统的连接数。
答：我收到的问题当中，这是提问频率最高的问题之一，由于许多人有合理的要求，需要支持 10 个以上的连接，以开发和测试支持多个并发访问的系统。然而，有些人希望能将 Windows 2000 Professional 用作服务器平台，但是它的设计初衷并不是如此，或是不允许这样。我知道在新闻组以及其他地方，有许多人在讨论各种允许连接数超过 10 的设置，但是我们没有对任何一种设置进行过测试，理由很简单，我相信如果您需要服务器服务，那么表明您需要服务器操作系统。
常有人错误地认为，连接数为 10 就是用户数为 10。通常一个 Web 客户端可以创建多个至 Web 服务器的连接，因此您的客户端 IIS 服务器可能无法同时支持 10 位用户。所以，安装了 IIS 5 的 Windows 2000 Professional 中存在一个鲜为人知的特殊情况，使得您可以将 Web 站点设置为可以接受多达 40 位用户。您只需将允许连接数设置为一个小于 40 的值，并使用 viola 浏览器，那么您就可以接受高达 40 个并发 HTTP 连接。这个特例只适用于 HTTP，因此您仍然无法通过文件和打印机共享接受 10 个以上的连接。
IIS Lockdown 工具如何处理应用程序映射？
问：当我们在 IIS 5 上使用 IIS Lockdown 工具时，我们禁用了除 .asp 文件之外的所有的应用程序映射。Lockdown 工具的确禁用了其他应用程序映射，但是并没有删除它们。我读过了许多有关安全性的文章和书籍，其中大部分都认为删除不需要的应用程序映射是最佳做法，而且似乎的确很有意义。但是 Lockdown 工具没有删除映射，而是将这些扩展名映射到 404.dll 程序。为什么要保留这些扩展名，而不按照包括“Microsoft 的 IIS 5 安全性检查清单”在内的安全性文章中所建议删除它们？
答：IIS 5 安全性检查清单确实是一个相当好的入门资料，但是，如果要更为全面地了解 Web 安全性方面的知识，我力荐您阅读提高 Web 应用程序的安全性：威胁与对策，这篇文章写得非常好，其链接为
http://msdn.microsoft.com/library/en-us/dnnetsec/html/ThreatCounter.asp。
不过，您提出了一个非常好的有关 IIS Lockdown 工具的问题，我一直推荐在 IIS 5 服务器上使用这个工具。Lockdown 对应用程序映射所采取的操作完全如您所述（参见下图）：
您可以看到，对 .htr 或 .idc 的任何请求都将导致运行 404.dll，而这个程序将向用户显示一条简单且无任何提示信息的错误——找不到文件。那么，为什么将这些扩展名映射到 404.dll，而不是简单地删除它们呢？我们假定您有多个使用 .ida、.idq 和 .htw 等过时扩展名的文件，以实现对索引服务器的查询和显示查询结果。在进行稍微深入的研究后，您明智地决定，使用 ASP 来提供同样的功能，这样效率更高，更为安全。编写代码后，您查看应用程序映射，删除了那些扩展名，因为您不再需要 .ida、.idq 和 .htw 等文件。结果，IIS 会将仍然位于服务器上的 .ida、.idq 和 .htw 文件，以文本形式发送给用户。这可能会暴露您不愿意公开的服务器信息。当然，您应该从服务器的源头删除这些文件，但是将这些扩展名映射到 404.dll 可以降低风险，因为您可能遗漏某一个文件，或是开发人员可能将旧内容上传到服务器。
请注意，您应该定期检查应用程序映射，以确保安装或卸载过程没有对它们进行修改。使用专用文件的 Web 应用程序肯定会将它们需要的扩展名添加到应用程序映射中。对于 Indexing Service，仅仅通过“添加/删除 Windows 组件”来从 IIS 服务器上删除 Indexing Service，将会把原来的 .idq、.idq 和 .htw 映射添加回应用程序映射，并将相关的 .dll 程序（idq.dll 和 webhits.dll）遗留在 Winnt\System32 中。因此，如果您不打算使用 Indexing Service，请在运行 IIS Lockdown 工具之前删除它。
将您的问题提交给 IIS 有问必答。挑选出的问题会连同答案一起刊登在下一期的 IIS 有问必答 专栏中。
要获取 IIS 有问必答 专栏前几个月的问题与解答，请单击此处。
我们代表 Microsoft 公司衷心希望本文章中的信息能对您有所帮助，但是应由您自己承担使用本文所带来的风险。本文中的所有信息都“按原样”提供，对于其准确性、完整性、特殊用途的适用性、所有权和不侵权原则，并没有任何明示或暗示的保证；本著作提及的任何第三方产品和信息，Microsoft 公司都并未参与创作，也不向您推荐、支持或作出任何保证。对使用该信息而造成的任何损失，不管是直接的、间接的、特别的，还是偶然的或必然的，即使已经警告过可能会有这种损失，Microsoft 公司将不承担任何责任。