3.4.2 IIS加固

下面是我们首选的强化IIS安全、对抗常见攻击的技术:

·关闭可能为攻击者提供太多信息的详细错误信息

·正确放置Web文件夹

·消除无用的扩展映射

·明智地使用文件系统访问控制列表

我们将在接下来的小节中详细讨论这样一些技术。

关闭IIS详细错误信息

详细错误信息绝不应该在生产服务器上启用。它们只能给攻击者过多可能用于对付你的信息。你应该参考Microsoft TechNet关于如何在你的IIS版本上禁用详细错误信息的指南。

在系统驱动器之外的驱动器上安装Web文件夹

过去,目录遍历攻击在IIS平台上相当常见(过去的公告链接参见“参考与延伸阅读”小节)。目前,这类攻击已经受到不允许跨卷跳转的URL语法的限制。因此,通过将IIS Web根目录移到没有强大工具(如cmd.exe)的卷,这种攻击已不可行。

当你将Web根目录迁移到新驱动器时,要确保所有文件系统ACL的完整性。在Windows服务器上,如果你不这么做,目标文件夹的ACL将被设置为默认值:每个人都有完全控制权限!Windows服务器资源工具箱(Server Resource Kit)中的Robocopy工具是移动具备完整ACL的Windows文件和文件夹的便利工具。Robocopy/SEC开关是需要考虑的重要参数。

删除无用的扩展映射

多年以来,围绕被称作ISAPI DLL的IIS扩展出现了许多安全问题。这些问题包括.printer缓冲区溢出和+.htr源代码泄露Bug。所有这些Bug都存在于应该通过删除DLL应用映射禁用的ISAPI DLL中。你还有一个选择,就是删除实际的.dll文件。删除应用映射时,这些DLL在启动期间不会被装入IIS进程。这样一来,这些漏洞就不会遭到攻击。

随着IIS 6及后续版本的发行,Microsoft默认禁用所有扩展。如果你使用Microsoft产品,这一改进和IIS 6以来许多其他安全改进使我们在部署IIS作为Web平台时的建议减少到最低限度。好的做法是遵循Microsoft的IIS指引,并与你的开发团队协作确定必要的扩展,并禁用其他所有扩展。

使用UrlScan

较新版本的UrlScan(本书编写时是版本3.1)允许管理员定义过滤规则,用于阻止有害的HTTP请求到达Web服务器。UrlScan不仅可以用于过滤URI,也可以过滤查询串和HTTP首部。尽管UrlScan是阻止攻击字符串的有用工具,但是不能代替开发过程中对应用漏洞的识别和修复,我们将在第10章对此加以讨论。

始终在Web服务器卷上使用NTFS并且保守地设置ACL!

使用FAT和FAT32文件系统,文件和目录级访问控制是不可能的;结果是,IUSR账户就成了读取和上传文件的全权委托书。在可以Web访问的NTFS目录上配置访问控制时,要使用最小权限原则。IIS 5及以上版本还提供了IIS权限向导,指导你完成基于场景的ACL设置过程。我们强烈建议你使用这个向导。

移动、改名、删除或者限制任何强大的实用程序

Microsoft建议将cmd.exe和多个其他强大的可执行文件的NTFS ACL设置为仅管理员和SYSTEM账户有完全控制权。Microsoft已经公开说明,这种简单的技巧能够阻止大部分远程命令执行的诡计,因为IUSR不再有访问cmd.exe的权限。Microsoft还建议使用内建的CACLS工具全面设置这些权限。我们来演示一个CACLS用于设置系统目录中可执行文件权限的示例。因为系统文件夹中的可执行文件太多,对我们来说,研究一个将文件移动到带有子文件夹test2的新文件夹test1的示例更简单一些。采用仅显示模式使用CACLS,我们可以看到测试文件的现有权限太宽松:


C:\cacls test1 /T
C:\test1 Everyone:(OI)(CI)F
C:\test1\test1.exe Everyone:F
C:\test1\test1.txt Everyone:F
C:\test1\test2 Everyone:(OI)(CI)F
C:\test1\test2\test2.exe Everyone:F
C:\test1\test2\test2.txt Everyone:F

我们假定你希望将test1中所有可执行文件的权限改为系统账户和管理员完全控制。下面是你所需要的CACLS命令语法:


C:\cacls test1\*.exe /T /G System:F Administrators:F
Are you sure (Y/N)?y
processed file: C:\test1\test1.exe
processed file: C:\test1\test2\test2.exe

现在再次运行CACLS确认结果。注意,所有子目录中的.txt文件具有原来的权限,但是可执行文件现在已适当设置:


C:\cacls test1 /T
C:\test1 Everyone:(OI)(CI)F
C:\test1\test1.exe NT AUTHORITY\SYSTEM:F
BUILTIN\Administrators:F
C:\test1\test1.txt Everyone:F
C:\test1\test2 Everyone:(OI)(CI)F
C:\test1\test2\test2.exe NT AUTHORITY\SYSTEM:F
BUILTIN\Administrators:F
C:\test1\test2\test2.txt Everyone:F

将这个示例应用到典型的Web服务器,将%systemroot%目录中的所有可执行文件设置为系统账户和管理员完全控制是一种好的做法,如:


C:\cacls %systemroot%\*.exe /T /G System:F Administrators:F

这样就阻止了非管理用户访问这些可执行文件,帮助避免像Unicode这样的攻击,它们严重依赖对这些程序的非特权访问。

当然,这些可执行文件也可以移动、改名或者删除,进一步阻止黑客的访问。

从服务器上的写入和执行ACL中删除Everyone和Guests组

匿名IIS访问账户IUSR_机器名和IWAM_机器名是这些组的成员。你要多加小心,IUSR和IWAM账户对系统上的任何文件或者目录不能有写入的权限——你已经目睹了可写的目录所导致的恶作剧!还有,对于非特权组的执行权限要仔细审查。特别要确定,不要允许任何非特权用户同时有相同目录的写入和执行权限!

详细审查并删除现有ISAPI应用对RevertToSelf的调用

老版本的IIS很容易遭到针对RevertToSelf Win32编程调用的权限提升攻击。通过实例化进行这一调用的现有DLL,攻击者能够破坏它以获得全能的LocalSystem特权。IIS 5和更旧的版本是主要的考虑对象,而运行于兼容模式的版本6也容易遭受攻击。你可以评估IIS DLL的RevertToSelf调用,避免它被用于权限提升。使用包含在许多Win32开发人员工具中的Dumpbin工具帮助你完成这一工作,下面是使用IsapiExt.dll的一个示例:


dumpbin /imports IsapiExt.dll | find "RevertToSelf"