Windows 2003安全指南之强化IIS服务器二

---

息队列子组件
　　
　　下表简要地描述了消息队列子组件，并且对何时启用它们提供了建议。
　　
　　 表8.7: 消息队列子组件
　　　 点击查看大图

 

　　“ 后台智能传输服务（BITS）服务器扩展”对话框中的子组件如下图所示：
　　 　
　　图8.4
　　
　　后台智能传输服务（BITS）服务器扩展子组件
　　
　　下表简要地描述了后台智能传输服务（BITS）服务器扩展子组件，并且对何时启用它们提供了建议。
　　
　　 表8.8: 后台智能传输服务（BITS）服务器扩展子组件
　　　 点击查看大图
　　“World Wide Web服务”对话框中的子组件如下图所示：
　　 　
　　图8.5
　　
　　World Wide Web服务子组件
　　
　　下表简要地描述了World Wide Web服务子组件，并且对何时启用它们提供了建议。
　　
　　 表8.9: World Wide Web服务子组件
　　　 点击查看大图
　　仅启用必需的Web服务扩展
　　
　　许多运行于IIS服务器上的网站和应用程序具有超出静态页面范畴的扩展功能，包括生成动态内容的能力。通过IIS服务器提供的特性来产生或扩展的任何动态内容，都是通过使用Web服务扩展来实现的。
　　
　　IIS6.0 中的增强安全特性允许用户单独启用或禁用Web服务扩展。在一次新的安装之后，IIS服务器将只能传送静态内容。可通过IIS Manager中的Web Service Extensions节点来启用动态内容能力。这些扩展包括ASP.NET、SSI、WebDAV、以及FrontPage Server Extensions。
　　
　　启用所有的Web服务扩展可确保与现有应用软件的最大可能的兼容性。但是，这可能带来一些安全性风险，因为当所有的扩展被启用时，同时也启用了您的环境下IIS服务器所不需要的功能，这样IIS的攻击表面积就会增加。
　　
　　为了尽可能减少IIS服务器的攻击表面，在本指南所定义的三种环境下，只有必需的Web服务扩展才应该在IIS服务器上被启用。
　　
　　仅仅启用在您的IIS服务器环境下运行的站点和应用软件所必需的Web服务扩展，通过最大限度精简服务器的功能，可以减少每个IIS服务器的攻击表面，从而增强了安全性。
　　
　　下表列举了预先定义的Web服务扩展，并且提供了何时启用它们的详细指导。
　　
　　 表8.10: 启用Web服务扩展
　　　 点击查看大图
　　在专用磁盘卷中放置内容
　　
　　IIS会将默认Web站点的文件存储到<systemroot>\inetpub\wwwroot，其中<systemroot>是安装了Windows Server 2003的驱动器。
　　
　　在本指南所定义的三种环境下，应该将构成Web站点和应用程序的所有文件和文件夹放置到IIS服务器的专用磁盘卷中。将这些文件和文件夹放置到IIS服务器的一个专用磁盘卷——不包括操作系统所在的磁盘卷——有助于防止针对目录的遍历攻击。目录遍历攻击是指攻击者对位于IIS服务器目录结构之外的一个文件发送请求。
　　
　　例如，cmd.exe位于<systemroot>\System32文件夹中。攻击者可以请求访问以下位置：
　　
　　..\..\Windows\system\cmd.exe，企图调用该命令。
　　
　　如果站点内容位于一个单独的磁盘卷，这种类型的目录遍历攻击将无法成功，原因有二。首先，cmd.exe的权限已经作为Windows Server 2003基础结构的一部分进行了重设，从而将对它的访问限制在很有限的用户群中。其次，完成该修改之后，cmd.exe不再与站点根目录处于同一磁盘卷，而目前没有任何已知的方法可通过使用这种攻击来访问位于不同驱动器上的命令。
　　
　　除了安全性问题之外，将站点和应用软件文件和文件夹放置在一个专用的磁盘卷中使得诸如备份和恢复这样的管理操作变得更加容易。而且，将这种类型的内容放在一个分开的专用物理驱动器中有助于减少系统分区中的磁盘争用现象，并且改善磁盘的整体访问性能。
　　
　　设置NTFS访问权限
　　
　　Windows Server 2003检查NTFS文件系统权限，以决定用户或进程对特定文件或文件夹的访问类型。
　　
　　您应该分配相应的NTFS权限，以便在本指南定义的三种环境下，允许或拒绝特定用户对IIS服务器上站点的访问。
　　
　　NTFS访问权限应当与Web访问权限协同使用，而不是取代Web权限。NTFS权限只影响那些已经被允许或被拒绝访问站点和应用程序内容的帐户。Web权限则影响所有访问站点或应用程序的用户。如果站点权限与NTFS权限在某个文件夹或目录上发生冲突，限制性更强的设置将生效。
　　
　　对于不允许匿名访问的站点和应用程序，匿名帐户访问将被明确拒绝。当没有经过身份验证的用户访问系统资源时，就是所谓的匿名访问。匿名帐户包括内置的Guest 帐户，Guests 组，以及IIS Anonymous 帐户。此外，除了IIS管理员之外，对其它任何用户都应该清除所有的写权限。
　　
　　下表提供了关于NTFS权限的一些建议，这些权限将应用在IIS服务器上不同的文件类型之上。不同的文件类型可以被组织在不同的文件夹中，以简化应用NTFS权限的过程 。
　　
　　 表8.11: NTFS 权限
　　　 点击查看大图
　　设置 IIS 站点权限
　　
　　IIS 检查站点许可权限，以确定能够在站点上执行的操作类型，例如允许访问脚本源代码或允许浏览文件夹。您应该为站点分配权限，以便进一步保证IIS服务器上的站点在本指南定义的三种环境下的安全性。
　　
　　站点许可权限可以与NTFS权限协同使用。它们可配置给特定的站点、文件夹和文件。与NTFS权限不同，站点权限影响试图访问IIS服务器站点的每个人。站点许可权限可以通过使用IIS Manager管理单元得到应用。
　　
　　下表列举了IIS6.0支持的站点权限，并且提供了简要描述，解释如何为站点分配给定的许可权限。
　　
　　 表8.12: IIS 6.0站点权限
　　　 点击查看大图
　　配置IIS日志
　　
　　本指南建议在指南定义的三种环境下均启用IIS服务器上的IIS日志。
　　
　　可以为每个站点或应用程序创建单独的日志。IIS可以记录Microsoft Windows提供的事件日志或性能监视特性所记录信息范围之外的信息。IIS日志可记录诸如谁访问过站点，访客浏览过哪些内容、以及最后一次访问的时间等信息。IIS日志可被用来了解那些内容最受欢迎，确定信息瓶颈，或者帮助用户对攻击事件展开调查。
　　
　　IIS Manager管理单元可以用来配置日志文件格式、日志日程，以及将被记录的确切信息。为限制日志的大小，应当对所记录信息的内容进行仔细规划。
　　
　　当IIS日志被启用时，IIS使用W3C扩展日志文件格式（W3C Extended Log File Format）来创建日常操作记录，并存储到在IIS Manager 中为站点指定的目录中。为改善服务器性能，日志文件应当存储到系统卷以外的条带集或条带集/镜像磁盘卷上。
　　
　　而且，您还可以使用 UNC 路径将日志文件写到网络上以便远程共享。远程日志使得管理员能够建立集中的日志文件存储和备份。但是，通过网络读写日志文件可能会对服务器性能带来负面影响。
　　
　　IIS日志可以配置为使用其它几种 ASCII 或开放数据库连接（ODBC）文件格式。ODBC日志使得IIS能够将操作信息存储到SQL数据库中。但是，必须指出的是，当ODBC日志被启用时，IIS禁用了内核模式缓存。因此，执行ODBC日志会降低服务器的总体性能。
　　
　　包括了数以百计站点的 IIS 服务器可通过启用集中的二进制日志来改善日志性能。集中化的二进制日志允许IIS服务器将所有站点的活动信息写到一个日志文件上。这样，通过减少需要逐一存储和分析的日志文件的数量，大大地提高了IIS日志记录过程的可管理性和可测量性。要了解关于集中二进制日志的更多信息，请参看Microsoft TechNet主题“集中化的二进制日志记录”：http://www.microsoft.com/technet/prodtechnol/windowsserver2003/proddocs/server
　　/log_binary.asp
　　
　　当IIS日志按缺省设置存储在IIS服务器中时，只有管理员有权访问它们。如果日志文件的文件夹或文件的所有者不在 Local Administrators 组中时，HTTP.sys —— IIS 6.0的内核模式驱动程序——将向NT事件日志发布一个错误。该错误指出文件夹或文件的所有者不在Local Administrators 组中，并且这个站点的日志将暂时失效，直到其所有者被添加到Local Administrators 组中，或者现有的文件夹或文件被删除。
　　
　　向用户权限分配手动增加唯一的安全组
　　
　　大多数通过DCBP应用的用户权限分配都已经在本指南附带的安全性模板中进行了适当的指定。但是，有些帐户和安全组不能被包括在模板内，因为它们的安全标识对于单个的Windows 2003域是特定的。下面给出了必须手动配置的用户权限分配。
　　
　　警告：下表包含了内置的Administrator帐户。注意不要将Administrator帐户和内置的Administrators安全组相混淆。如果Administrators安全组添加了以下任何一个拒绝访问的用户权限，您必须在本地登录并且更正该错误。
　　
　　此外，根据第三章“创建成员服务器基线”，内置的Administrator账户可能已经被重命名。当添加Administrator账户时，请确信添加的是经过了重命名的账户。
　　
　　 表 8.13：手动添加用户权限分配
　　　 点击查看大图
　　警告：所有非操作系统服务账户包括整个企业范围内用于特定应用程序的服务账户。这不包括操作系统使用的内置帐户——本地系统，本地服务或网络服务帐户。
　　
　　保护众所周知帐户的安全
　　
　　Windows Server 2003有很多内置的帐户，它们不能被删除，但可以重命名。Windows 2003中最常见的两个帐户是Guest 和 Administrator。
　　
　　在成员服务器和域控制器中，Guest帐户缺省时被禁用。不应改变该设置。内置的Administrator帐户应被重命名，而且其描述也应被更改，以防止攻击者通过该帐户破坏远程服务器。
　　
　　许多恶意代码的变种企图使用内置的管理员账户来破坏一台服务器。在近几年来，进行上述重命名配置的意义已经大大降低了，因为出现了很多新的攻击工具，这些工具企图通过指定内置 Administrator 账户的安全标识（SID）来确定该帐户的真实姓名，从而侵占服务器。SID是唯一能确定网络中每个用户、组、计算机帐户以及登录会话的值。改变内置帐户的SID是不可能的。将本地管理员帐户改变为一个特别的名称，可以方便您的操作人员监视对该帐户的攻击企图。
　　
　　保护IIS服务器中众所周知帐户的安全：
　　
　　1. 重命名Administrator和Guest帐户，并且将每个域和服务器上的密码更改为长而复杂的值。
　　
　　2. 在每个服务器上使用不同的名称和密码。如果在所有的域和服务器上使用相同的帐户名和密码，攻击者只须获得对一台成员服务器的访问，就能够访问所有其它具有相同帐户名和密码的服务器。
　　
　　3. 修改缺省的帐户描述，以防止帐户被轻易识别。
　　
　　4. 将这些变化记录一个安全的位置。
　　
　　注意：内置的管理员帐户可通过组策略重命名。本指南提供的任何安全性模板中都没有配置该设置，因为您必须为您的环境选择一个独一无二的名字。在本指南定义的三种环境下，“帐户：重命名管理员帐户” 设置可用来重命名管理员帐户。该设置是组策略的安全选项设置的一部分。
　　
　　保护服务帐户的安全
　　
　　除非绝对必须，否则不要让服务运行在域帐户的安全上下文中。如果服务器的物理安全受到破坏，域账户密码可以很容易通过转储本地安全性授权（LSA）秘文而获得。
　　
　　用IPSec过滤器阻断端口
　　
　　Internet 协议安全性（IPSec）过滤器可为增强服务器所需要的安全级别提供有效的方法。本指南推荐在指南中定义的高安全性环境中使用该选项，以便进一步减少服务器的攻击表面。
　　
　　要了解关于IPSec过滤器使用的更多信息，请参看“威胁与对策：Windows Server 2003和Windows XP中的安全性设置 ”的第11章 “其它成员服务器的强化程序” ，。
　　
　　下表列举了在本指南定义的高级安全性环境下，可在IIS服务器上创建的IPSec过滤器。
　　
　　 表8.14: IIS服务器IPSec网络流量图
　　　 点击查看大图
　　在实施上表所列举的规则时，应当对其进行镜像处理。这样可以保证任何进入服务器的网络流量也可以返回到源服务器。
　　
　　上表介绍了服务器要想完成特定角色的功能所应该打开的基本端口。如果服务器使用静态的IP地址，这些端口已经足够。如果需要提供更多的功能，则可能需要打开更多的端口。打开更多的端口将使得您的环境下的IIS服务器更容易管理，但是这可能大大降低服务器的安全性。
　　
　　由于在域成员和域控制器之间有大量的交互，尤其是RPC和身份验证通信，在IIS服务器和全部域控制器之间，您应该允许所有的通信。通信还可以被进一步限制，但是大多数环境都需要为有效保护服务器而创建更多的过滤器。这将使得执行和管理IPSec策略非常困难。您应该为每一个将与IIS服务器进行交互的域控制器创建类似的规则。为了提高IIS服务器的可靠性和可用性，您需要为环境中的所有域控制器添加更多规则。
　　
　　正如上表所示，如果环境中运行了Microsoft Operations Manager（MOM），那么在执行IPSec过滤器的服务器和MOM服务器之间，应该允许传输所有的网络通信。这是必须的，因为在MOM服务器和OnePoint 客户端——向MOM控制台提供报告的客户应用程序——之间存在大量的交互过程。其它管理软件可能也具有类似的需求。如果希望获得更高级别的安全性，可将OnePoint 客户端的过滤动作配置就IPSec与MOM服务器进行协商。
　　
　　该IPSec策略将有效地阻止通过任意一个高端口的通信，因此它不允许远程过程调用（RPC）通信。这可能使得服务器的管理很困难。由于已经关闭了许多端口，您可以启用终端服务。以便管理员可以进行远程管理。
　　
　　上面的网络通信图假设环境中包含启用了Active Directory的DNS服务器。如果使用独立的DNS服务器，可能还需要建立更多规则。
　　
　　IPSec策略的执行将不会对服务器的性能带来明显影响。但是，在执行这些过滤器之前必须进行测试，以核实服务器保持了必要的功能和性能。您可能还需要添加一些附加规则以支持其它应用程序。
　　
　　本指南包括一个.cmd文件，它简化了依照指南要求为域控制器创建IPSec过滤器的过程。PacketFilters-IIS.cmd文件使用NETSH命令来创建适当的过滤器。应当修改该.cmd文件，在其中包含您所在环境中域控制器的IP地址。脚本中包含两个占位符，这是为将被增加的两个域控制器IP地址预留的。如果需要，还可以添加其它更多的域控制器。这些域控制器的IP地址列表应当是最新的。
　　
　　如果环境中有MOM，应当在脚本中指定相应的MOM服务器 IP 地址。该脚本不创建永久的过滤器。因此，直到IPSec Policy Agent启动时，服务器才会得到保护。要了解关于建立永久过滤器或创建更高级IPSec过滤器脚本的信息，请参看本指南姐妹篇“ 威胁与对策：Windows Server 2003和Windows XP中的安全性设置 ”的第11章“其它成员服务器的强化程序”。最后，该脚本不会分发其创建的IPSec策略。IP安全性策略管理单元可被用来检查所创建的IPSec过滤器，并且分发IPSec策略以便让其生效。
　　
　　总结
　　
　　本章解释了在本指南指定的三种环境下，为保护IIS服务器的安全所应采取的强化设置。我们讨论的大多数设置通过组策略进行配置和应用。可以将能够为MSBP提供有益补充的组策略对象（GPO）链接到包含IIS服务器的相应组织单位（OU），以便为这些服务器提供的服务赋予更多的安全性。
　　
　　本章讨论的有些设置不能通过组策略得到应用。对于这种情况，本章介绍了有关手动配置这些设置的详细信息。此外，我们还详细介绍了创建和应用能够控制IIS服务器间网络通信类型的IPSec过滤器的具体过程 本文作者:

---

« 
» 

---