Windows IIS 安全配置

对于一个网站来说，Web服务器程序（为了区分与服务器硬件，下面把服务器硬件称为主机）就是响应用户的总处理程序，不同的操作系统有不同的Web服务器程序，Windows系列主机是IIS，Linux是Apache、Tomcat、Nginx。服务器程序是一个对外开放的网关，所有人都可以没有或者很少限制的访问。因此，它也常常被黑客盯上，成为攻击的对象。Web服务器中存放有一个站点所有的源代码程序、数据库连接程序或者数据库本身（往往包含普通用户的账号和密码）、其他有利于攻击者发动对主机进行攻击。因此，有必要对服务器程序进行周密的配置，以确保整个网站不会倒在这一关上。从本章节开始，将会介绍几个主流Web服务器程序须要采取的安全措施，本章节介绍Windows IIS的安全防护。

一、IIS用户标识和权限

IIS中，从Windows 2000的IIS 5.0开始，操作系统就内置了几个账户，用于给Web服务器程序操作本地数据，这些账户都被赋予了最小的权限。这个思路被一直沿用了下来。IIS会创建IUSR_computername（computername是计算机名，每台计算机都有自己的计算机名）和IWAM_computername账户以备使用。当系统安装.net framework时，一个名为ASPNET的账户也被创建。

1、交互式用户组

交互式用户组是操作系统内置且自动维护的组。它可以登录到本地服务器上的所有用户。本地登录就像是在登录服务器本身，而非远程登录。在用户或者组执行一个本地登录前，必须具备登录本地机器的用户权限。可以使用交互式用户组来限制或许可所有经过基本身份验证的用户的访问。

2、网络用户组

网络用户组是一个操作系统内置且自动维护的组，它包括登录到网络服务器上的所有用户。在用户或组执行网络登录之前，必须具备从网络访问这台计算机的用户权限。可以用网络用户组控制所有经过摘要式身份验证或集成Windows身份验证的用户的访问。

3、IUSR_computername账户

互联网来宾账户(Internet Guest)被命名为IUSR_computername，该账户被用于提供对Web应用程序、文件或文件夹的匿名访问。管理互联网来宾账户的NT文件系统权限对Web服务器和网络安全是很重要的，互联网来宾账户被赋予访问服务器资源的最小权限。

4、IWAM_computername账户

IWAM_computername账户也是由IIS创建的，它仅被用于运行在中、高级应用程序保护下的Web应用程序。某些时候，需要为这个账户提供访问服务器资源的适当权限。例如，访客需要通过程序访问数据库，并且这个程序运行在中、高级应用程序的保护下，则需要为IWAM_computername账户提供适当的访问数据库的权限。

5、ASPNET账户

ASPNET是由.net framework创建的，它仅仅用于ASP.net Web应用程序。某些时候，需要为这个账户提供适当的权限访问服务器资源。例如，如果Web应用程序需要进行写文件操作，则必须为ASPNET账户赋予写文件的权限。

6、IIS模拟Windows用户账户的实现

当IIS接收到客户端的请求时，通过使用Windows用户或组账户来验证客户端身份，通过身份验证后，IIS才开始执行任务。然后，使用上文所述的IUSR_computername账户和IWAM_computername账户，或为ASP.net启用ASPNET账户、IUSR_computername账户来模拟客户端。

鉴于IIS模拟客户端，IIS只能在经过验证的用户的安全上下文的范围内操作。安全上下文就是一种权限限制，可以在处理的不同阶段改变，改变取决于需要执行的操作。IIS的安全上下文以LocalSystem最为大家熟知。然而，当IIS处理客户端请求时，将模拟最初生成请求的客户的上下文。不同的身份验证方法，使用不同的Windows账户，也就有着不同的安全上下文。在IIS执行完客户端请求后，IIS将IIS进程的安全上下文还原为LocalSystem。

默认情况下，ASP.net不进行模拟，ASP.net使用与ASP.net进程相同的账户来执行所有代码，如前文所述，这个账户通常是ASPNET，但也可以使用IUSR_computername账户。怎么设置呢？需要在web应用程序的web.config文件中，设置如下节点即可使用IUSR_computername账户：

<identity impersonate="true" />

也可以启用模拟，并指定特定的模拟身份，如下所示：

<identity impersonate="true" name="domain\user" password="password" />

7、程序代码访问用户标识

无论使用哪种身份验证机制，当某个用户访问Web应用程序后，Web页都可以通过代码访问用户名。无论是VB.net还是C#，都使用User.Identity对象来取得身份信息。几个常见的属性有User.Identity.Name（授权用户名）、User.Identity.AuthenticationType（授权类型）、User.Identity.IsAuthenticated（是否已授权）。

当ASP.net Web应用程序没有启用模拟时，它以ASPNET账户运行，而不是作为经过验证的用户来运行。这时就涉及到另一个类：WindowsIdentity类（位于System.Security.Principal命名空间中）。未启用模拟时，User.Identity.Name属性显示经过验证的用户，但是其代码仍然以ASPNET账户运行，因此仍然限制那些可用账户对资源进行访问。WindowsIdentity.GetCurrent().Name属性定义了运行Web应用程序的账户名称。

就是说，如果使用的是集成Windows身份验证或基本身份验证，而模拟处于启用状态，那么代码将以经过验证的用户账户来运行，User.Identity.Name属性和WindowsIdentity.GetCurrent().Name属性显示的名称是一样的。如果没有开启模拟，WindowsIdentity.GetCurrent().Name显示ASPNET，而User.Identity.Name显示经过验证的用户。

二、配置IIS访问权限

1、使用IP地址和域名限制

通过配置IIS，可以授权或拒绝指定的IP地址、网络地址或域名的访问。如果设置默认所有IP可访问，则只限制指定的IP、地址和域名。反之，则只授权特定的IP、地址和域名访问。

如果Web用户通过代理服务器或防火墙访问站点，该用户的IP将被代理服务器或防火墙的IP取代，因此，通过限制IP机制，只对代理服务器或防火墙开放，则可以防止部分攻击者绕过防火墙对服务器发动攻击。

不同版本的IIS，设置IP地址和域名限制方式不尽相同，这里大致说一下位置，具体的可以去度娘，这里不再赘述。IIS6.0及较早版本在本网站属性中，“目录安全性”选项卡中，“IP地址和域名限制”区块中。而较新的IIS版本中，一般处于网站“功能视图”的“IIS”选项卡的“IP地址和域限制”选项。如果找不到，则点击下方的“Web平台安装程序”进行安装。

2、基于Web的权限

为了精确控制安全性，可以在IIS上配置一个Web应用程序具体的操作权限，包括对目录、文件、文件夹的访问权限，以及是否可执行本地应用程序权限。这些权限相当于TCP/IP协议中的应用层，对用户而言，这种权限具有强制的平等性，不能对不同用户采取不同的策略。通常，基于Web的权限分为“常规访问权限”和“执行权限”两大部分，下面2个图，是两个不同IIS版本（分别为6.0，下为7.5）中的设置位置：

各个常规访问权限说明如下：

• 读取：启用该选项时，用户可以通过浏览器访问诸如.html、.asp、.txt等类型的文件。禁用该选项将会组织任何人查看该Web应用程序的文件。只对静态内容有效，对脚本文件无效。
• 写入：启用该选项时，用户可以改变Web应用程序的文件的内容和属性。其更改是通过使用Web文件夹或能发布Web应用程序的浏览器来实现的。只对静态内容有效，对脚本文件无效。
• 目录浏览:启用该选项时，如果IIS没有启用默认文档，则用户可以浏览该文件夹的列表。
• 脚本资源访问:启用该选项时，允许用户读取和编辑Web应用程序的源代码，该选项仅当读取或写入权限都处于启用状态时才可以使用。此外，该选项还规定了用户是否可以通过使用WebDAV从Web应用程序中复制脚本或向其写入脚本。当启用该选项时，用户可能会从脚本网页，或诸如Perl等其他基于脚本的Web应用程序中看到一些敏感信息，如用户名和密码。所以请谨慎启用该选项。

几个执行权限的说明如下：

• 无：禁止在本Web应用程序或文件夹中运行任何程序或脚本。
• 纯脚本：在没有设置执行权限的情况下，该选项会把Web应用程序的源码映射到脚本引擎中，并在指定的文件夹中运行。该选项比下面将要介绍的“脚本和可执行文件”安全性要高，例如，使用该选项将不能执行.exe和.dll文件，这样就能一定程度上防止黑客上传这类程序并运行，是大多数网站采用的选项。
• 脚本和可执行文件：该选项使得任何Web应用程序都可以在指定的文件夹中运行，包括映射到脚本引擎中的Web应用程序、Windows二进制代码以及.dll和.exe文件。建议谨慎使用该选项，因为当这个选项被启用时，潜在的攻击者可以上传和执行某些危害性极大的可执行文件。

三、IIS身份验证

Web用户在向IIS发出请求时，IIS有四种方式可以验证用户身份：

1. 匿名身份验证
2. 基本身份验证
3. 摘要式身份验证
4. Windows集成身份验证

匿名身份验证是目前绝大多数网站采取的验证方式，其实就是不进行验证，整个网站采用开放式的结构。各个版本的IIS都默认只启用了匿名身份验证。身份验证的优先级次序为：匿名身份验证>windows验证>摘要式身份验证>基本身份验证。就是说，如果同时开启匿名身份验证和基本身份验证，客户端就会先利用匿名身份验证，所以此时基本身份验证即无效！

1、匿名身份验证

即用户访问站点时，不需要提供身份认证信息，即可正常访问站点！

2、基本身份验证

若网站启用了基本身份验证，访问站点时，会要求用户输入密码，此验证常用于网站后台等目录。使用此身份验证，需先将匿名身份验证禁用。设置目录：IIS6一般在“目录安全性”选项卡<身份验证和访问控制里。而IIS7一般在“IIS”<身份验证里。在IIS左侧文件列表里，选择需要设置基本身份验证的文件夹，然后单击“属性”（IIS6）或右侧“身份验证”项（IIS7或更高），即可为一个目录设置单独的身份验证。

3、摘要式身份验证

摘要式身份验证如基本身份验证一样需要输入账户密码，但是比基本身份认证更安全，基本身份验证在网络上传输不加密的 Base64 编码的密码，而摘要式身份验证用户密码使用MD5加密。

使用摘要式身份验证必须具备下面三个条件：

1. 浏览器支持HTTP 1.1 IE5以上都支持
2. IIS服务器必须是Windows 域控制器成员服务器或者域控制器
3. 用户登录招呼必须是域控制器账户，而且是同IIS服务器用以域或者信任域！

由此可见，摘要式身份验证是使用 Windows 域控制器对请求访问 Web 服务器内容的用户进行身份验证。

4、Windows 集成身份验证

如果您希望客户端使用 NTLM 或 Kerberos 协议进行身份验证，则应使用 Windows 身份验证。Windows 身份验证同时包括 NTLM 和 Kerberos v5 身份验证，它最适用于 Intranet 环境，其原因如下：

1. 客户端计算机和 Web 服务器位于同一个域中。
2. 管理员可以确保所有客户端浏览器均为 Internet Explorer 2.0 或更高版本。
3. 不需要不受 NTLM 支持的 HTTP 代理连接。
4. Kerberos v5 需要连接到 Active Directory，这在 Internet 环境中不可行。

在一些需要身份验证的地方，可以使用Windows 集成身份验证和摘要式身份验证，因为当前网站大都采用数据库+表单验证的方式，连基本身份验证都运用的很少，而绝大多数网站使用的是匿名身份验证，这也是互联网的开放性特征决定的。IIS的身份验证虽然可以加强安全性，但其本身显得与大环境格格不入，且灵活性很差，因此，我们不予展开介绍。

四、常见IIS漏洞

1、IIS短文件名泄露漏洞

目标存在IIS短文件名泄露漏洞。Internet Information Services（IIS，互联网信息服务）是由微软公司提供的基于运行Microsoft Windows的互联网基本服务。Microsoft IIS在实现上存在文件枚举漏洞，攻击者可利用此漏洞枚举网络服务器根目录中的文件。验证方式：打开目标页面如果提示Bad Request即证明存在漏洞。示例如下图：

攻击者可以利用该漏洞猜解后台地址和敏感文件甚至直接下载对应文件，或对IIS服务器中的.Net Framework进行拒绝服务攻击。

三种修复方案只有第二和第三种能彻底修复该问题,可以联系空间提供商协助修改。方案1、修改注册列表HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation的值为1,或者，可以直接点此下载，然后运行,再重启下机器。(此修改只能禁止NTFS8.3格式文件名创建,已经存在的文件的短文件名无法移除)。该修改不能完全修复,只是禁止创建推荐使用后面的修复建议；方案2、如果你的web环境不需要asp.net的支持你可以进入Internet 信息服务(IIS)管理器 --- Web 服务扩展 - ASP.NET 选择禁止此功能。（推荐）；方案3、升级net framework 至4.0以上版本。（推荐）

2、IIS版本号可以被识别

该漏洞使得目标服务器IIS版本号可以被识别，可以被攻击者用来收集更多的信息。攻击者可能通过IIS版本号利用对应的已知IIS漏洞——IIS4\IIS5 CGI环境块伪造漏洞、IIS 7.0/7.5服务器PHP解析漏洞等来进行针对性攻击，并且可以通过IIS版本号推测出当前使用操作系统的版本从而利用已知的OS漏洞进行更加多样化的攻击。

解决方案：在IIS配置文件中进行修改。借助IIS URL Rewrite Module，添加如下的重写规则：

<rewrite>
        <allowedServerVariables>
            <add name="REMOTE_ADDR" />
        </allowedServerVariables>            
        <outboundRules>
            <rule name="REMOVE_RESPONSE_SERVER">
                <match serverVariable="RESPONSE_SERVER" pattern=".*" />
                <action type="Rewrite" />
            </rule>
        </outboundRules>
</rewrite>

重写规则存放在C:\Windows\System32\inetsrv\config\applicationHost.config中。

3、启用了OPTIONS方法

攻击者可利用options方法获取服务器的信息，进而准备进一步攻击。

解决方案：修改配置文件禁用options方法。

在程序的web.config中加入如下内容（如某些节已经存在，则将其包含的内容加到其下面）：

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
    <security>
      <requestFiltering>
        <verbs allowUnlisted="true">
          <add verb="OPTIONS" allowed="false"/>
        </verbs>
      </requestFiltering>
    </security>
</system.webServer>
</configuration>

4、X-Frame-Options头未设置

X-Frame-Options HTTP响应头是用来确认是否浏览器可以在frame或iframe标签中渲染一个页面，网站可以用这个头来保证他们的内容不会被嵌入到其它网站中，以来避免点击劫持。

攻击者可以使用一个透明的、不可见的iframe，覆盖在目标网页上，然后诱使用户在该网页上进行操作，此时用户将在不知情的情况下点击透明的iframe页面。通过调整iframe页面的位置，可以诱使用户恰好点击iframe页面的一些功能性按钮上，导致被劫持。

配置 IIS 发送 X-Frame-Options 响应头，添加下面的配置到 Web.config 文件中即可解决:

<system.webServer>
  ...
 
  <httpProtocol>
    <customHeaders>
      <add name="X-Frame-Options" value="SAMEORIGIN" />
    </customHeaders>
  </httpProtocol>
 
  ...
</system.webServer>

X-frame-options响应头赋值有如下三种：（1）DENY：不能被嵌入到任何iframe或frame中。（2）SAMEORIGIN：页面只能被本站页面嵌入到iframe或者frame中。（3）ALLOW-FROM uri：只能被嵌入到指定域名的框架中。上面的例子选择了第2种。

在现代浏览器尝试加载 frame 的内容时，如果 X-Frame-Options 响应头设置为禁止访问了，那么浏览器会用 about:blank 展现到 frame 中。

如果浏览器不支持，则可以采用代码的方式，禁止iframe：

<script type="text/javascript">  
    if(top.location != self.location){  
    top.location = self.location;//防止页面被框架包含  
    }  
</script>

如果对方采用禁用JS的框架，则需要在程序页面代码中加入代码头“X-Frame-Options:Deny”。

转载本站内容时，请务必注明来自W3xue，违者必究。