由于Web服务器被越来越多的骇客和蠕虫制造者作为首要攻击目标，IIS便也成为了Microsoft可信赖计算计划中首要关注的内容。因此，IIS 6.0被完全的重新设计，以实现默认安全和设计安全。本文主要讲述了IIS 6.0在默认设置和设计上安全性的改变是如何使其成为关键web应用的平台。
默认安全
过去，包括像微软这样的企业，都在他们的web服务器上安装一系列的默认示例脚本，文件处理和最小文件授权，以提高管理员管理的灵活性和可用性。但是，这些默认设置都增加了IIS的被攻击面，或者成为了攻击IIS的基础。因此，IIS 6.0被设计成了一个比早期产品更安全的平台。最显而易见的变化是IIS 6.0并没有被Windows Server 2003默认安装，而是需要管理员显式的安装这个组件。其他的变化包括：
·默认只安装静态HTTP服务器
IIS 6.0的默认安装被设置为仅安装静态HTML页面显示所需的组件，而不允许动态内容。下表比较了IIS 5.0和IIS 6.0的默认安装设置：
IIS 组件
IIS 5.0
默认安装
IIS 6.0
默认安装
Static file support（静态文件支持）
启用
启用
ASP
启用
禁用
Server-side includes（服务器端包含）
启用
禁用
Internet Data Connector（Internet数据连接器）
启用
禁用
WebDAV
启用
禁用
Index Server ISAPI（索引服务）
启用
禁用
Internet Printing ISAPI（Internet打印）
启用
禁用
CGI
启用
禁用
Microsoft FrontPage? server extensions
（FrontPage服务器端扩展）
启用
禁用
Password change interface（更改密码界面）
启用
禁用
SMTP
启用
禁用
FTP
启用
禁用
ASP.NET
无
禁用
Background Intelligence Transfer Service
（后台智能传输服务）
无
禁用
IIS 6.0中不再包括任何类似showcode.asp或codebrws.asp等的范例脚本或应用。这些程序原被设计来方便程序员快速察看和调试数据库的连接代码，但是由于showcode.asp和codebrws.asp没有正确的进行输入检查，以确定所访问的文件是否位于站点根目录下。这就允许攻击者绕过它去读取系统中的任何一个文件（包括敏感信息和本应不可见的配置文件），参考以下链接以获取该漏洞的更多的细节： //www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS99-013.asp
·增强的文件访问控制
匿名帐号不再具有web服务器根目录的写权限。另外，FTP用户也被相互隔离在他们自己的根目录中。这些限制有效的避免了用户向服务器文件系统的其他部分上传一些有害程序。例如攻击者可以向/scripts目录上传一些有害的可执行代码，并远程执行这些代码，从而攻击web站点。
·虚拟目录不再具有执行权限
虚拟目录中不再允许执行可执行程序。这样避免了大量的存在于早期IIS系统中的目录遍历漏洞、上传代码漏洞以及MDAC漏洞。
·去除了子验证模块
IIS 6.0中去除了IISSUBA.dll。任何在早期IIS版本中，需要该DLL模块来验证的账号，现在需要具有"从网络上访问这台计算机"的权限。这个DLL模块的去除，可以强制要求所有的访问都直接去SAM或者活动目录进行身份验证，从而减少IIS可能的被攻击面。
·父目录被禁用
IIS 6.0中默认禁用了对父目录的访问。这样可以避免攻击者跨越web站点的目录结构，访问服务器上的其他敏感文件，如SAM文件等。当然也请注意，由于父目录默认被禁用，这可能导致一些从早期版本IIS上迁移过来的应用由于无法使用父目录而出错。
安全设计
IIS 6.0设计中安全性的根本改变表现在：改善的数据有效性、增强的日志功能、快速失败保护、应用程序隔离和最小权限原则。
改善的数据有效性
IIS 6.0设计上的一个主要新特性是工作在内核模式的HTTP驱动--HTTP.sys。它不仅提高了web服务器的性能和可伸缩性，而且极大程度的加强了服务器的安全性。HTTP.sys作为web服务器的门户，首先解析用户对web服务器的请求，然后指派一个合适的用户级工作进程来处理请求。工作进程被限制在用户模式以避免它访问未授权的系统核心资源。从而极大的限制了攻击者对服务器保护资源的访问。
IIS 6.0通过在内核模式的驱动中整合一系列的安全机制，以提升其设计上固有的安全性。这些机制包括避免潜在的缓冲溢出，改善的日志机制以辅助事件响应进程和检查用户有效性请求的先进URL解析机制。
为了第一时间的避免潜在的缓冲区和内存溢出漏洞的利用，微软通过在HTTP.sys中进行特殊的URL解析设置以实现IIS 6.0安全设计中的深度防御原则。这些设置还可以通过修改注册表中特定的键值来进一步优化。下表提供了主要注册表键值的位置（均在以下路径HKLM\System\CurrentControlSet\Services\HTTP\Parameters）：
AllowRestrictedChars
这个键接受布尔值内容，非零值表明允许HTTP.sys接受十六进制编码的URL请求。其默认值为0。这个值也被推荐设置为0，以迫使请求在服务器级就进行输入检查。如果设置为1，可能导致攻击者通过十六进制编码的恶意请求来绕过输入检查。
MaxFieldLength
这个键允许管理员设置每个HTTP头的大小上限（以Byte为单位），它的默认值是16KB。
MaxRequestBytes
这个键用来确定请求行和HTTP头的总大小上限。它的默认值也是16KB。
UrlSegmentMaxCount
这个键决定了服务器可以接受的URL地址中目录深度的最大值。它有效地限制用户URL请求中的反斜杠“/”的数量。建议将这个值根据web目录的深度进行严格的控制，以避免服务器遭受文件遍历攻击。其默认值为255。
UrlSegmentMaxLength
这个键决定了URL请求中每个路径段的字符长度的最大值。这个值也应该根据主机的普通应用来设置，以避免接受超常地址请求而导致应用异常。其默认值为260。
EnableNonUTF8
这个键控制了HTTP.sys允许的字符编码格式。默认值1允许HTTP.sys接受ANSI和DBCS编码的URL地址，其他值允许UTF8的编码格式。
一个全面的日志是检测或响应一个安全事故的基础要求。微软也意识到了在HTTP.sys中进行全面的、可靠的日志机制的重要性。HTTP.sys在将请求指派给特定的工作进程之前就进行日志记录。这样可以保证，即使工作进程中断了，也会保留一个错误日志。日志由发生错误的时间戳、来源目的IP和端口、协议版本、HTTP动作、URL地址、协议状态、站点ID和HTTP.sys的原因解释等条目构成。原因解释能够提供详细的错误产生原因的信息，如由于超时导致的错误，或由于工作进程的异常终止而引发的应用程序池强行切断连接而导致的错误。
以下连接可以看到HTTP.sys日志文件的示例：//www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/iis/iis6/proddocs/resguide/iisrg_log_qlow.asp
快速失败保护
除了修改注册表，IIS 6.0的管理员还可以通过服务器设置，来使那些在一段时间内反复失败的进程关闭或者重新运行。这个附加的保护措施是为了防止应用程序因为受到攻击而不断地出错。这个特性就叫做快速失败保护。
快速失败保护可以按照以下步骤在Internet信息服务管理工具中配置：
1. 在Internet信息服务（IIS）管理器中，展开本地计算机。
2. 展开应用程序池。
3. 在要设定快速失败保护的应用程序池上单击鼠标右键。
4. 选择属性。
5. 选择运行状况选项卡，勾选启用快速失败保护。
6. 在失败数中，填写可以忍受的工作进程失败次数（在结束这个进程之前）。 7. 在时间段中，填写累计工作进程失败次数统计的时间。
应用程序隔离
在早期版本的IIS中（5.0和以前的版本），由于将web应用程序隔离在独立的单元将会导致严重的性能下降，因此没有实现应用程序隔离。通常一个web应用程序的失败会影响同一服务器上其他应用程序。然而，IIS 6.0在处理请求时，通过将应用程序隔离成一个个叫做应用程序池的孤立单元这种设计上的改变，成倍的提高了性能。每个应用程序池中通常由一个或多个工作进程。这样就允许确定错误的位置，防止一个工作进程影响其他工作进程。这种机制也提高了服务器以及其上应用的可靠性。
坚持最小特权原则
IIS 6.0坚持一个基本安全原则--最小特权原则。也就是说，HTTP.sys中所有代码都是以Local System权限执行的，而所有的工作进程，都是以Network Service的权限执行的。Network Service是Windows 2003中新内置的一个被严格限制的账号。另外，IIS 6.0只允许管理员执行命令行工具，从而避免命令行工具的恶意使用。这些设计上的改变，都降低了通过潜在的漏洞攻击服务器的可能性。部分基础设计上的改变、一些简单配置的更改（包括取消匿名用户向web服务器的根目录写入权限，和将FTP用户的访问隔离在他们各自的主目录中）都极大地提高了IIS 6.0的安全性。
IIS 6.0是微软公司在帮助客户提高安全性上迈出的正确一步。它为Web应用提供了一个可靠的安全的平台。这些安全性的提高应归功于IIS 6.0默认的安全设置，在设计过程中就对安全性的着重考虑，以及增强的监视与日志功能。但是管理员不应该认为仅通过简单的迁移到新平台就可以获得全面的安全。正确的做法是应该进行多层面的安全设置，从而获得更全面的安全性。这也与针对Code Red和Nimda病毒威胁而进行的深度安全防御原则是一致的。