IIS服务器禁用不安全的HTTP方法降低攻击面

IIS服务器默认开启的HTTP方法，往往是攻击者最喜欢利用的突破口。很多人以为只要打了补丁、配好防火墙就万事大吉，却忽略了Web服务器本身允许的方法就可能成为远程代码执行、目录遍历甚至拒绝服务攻击的入口。PUT方法可以让你直接上传恶意脚本，DELETE方法可能清空关键文件，TRACE方法则可能泄露认证凭证。这些风险并非理论上的假设，而是每天都在发生的真实攻击场景。所以，禁用不安全的HTTP方法不是可选项，而是服务器加固的基本功。

在动手操作之前，必须先搞清楚哪些方法是真正需要禁用的。HTTP协议定义了多种请求方法，但绝大多数Web应用只需要GET、POST和HEAD就能正常运行。PUT方法原本用于上传资源到指定位置，如果服务器配置不当，攻击者可以直接上传WebShell。DELETE方法顾名思义就是删除资源，一旦被利用，服务器上的文件可能被批量清除。TRACE方法用于回显服务器收到的请求，主要用于调试，但它会让浏览器端的HttpOnly Cookie等敏感信息暴露在响应中，形成跨站追踪漏洞。OPTIONS方法虽然常用于CORS预检请求，但如果不需要跨域资源共享，也可以考虑禁用，至少应该限制其返回的信息量。CONNECT方法用于建立隧道连接，在普通Web服务器上几乎没有合法用途，却可能被用来代理恶意流量。PATCH方法在RESTful API中用于部分更新资源，如果你的应用不使用这种语义，同样应该关闭。总结下来，一个最小权限原则的配置是：只开放GET、POST和HEAD，其余全部禁用。

对于不熟悉命令行的管理员，IIS管理器提供了直观的操作方式。打开IIS管理器，在左侧连接面板中选择目标服务器或具体站点，然后在功能视图中找到“请求筛选”图标并双击进入。切换到“HTTP方法”选项卡，这里默认是空的，意味着所有方法都被允许。点击右侧操作面板中的“拒绝方法”，在弹出的对话框中输入要禁止的方法名称，比如PUT，然后确定。重复这个操作，依次添加DELETE、TRACE、OPTIONS、CONNECT、PATCH等。完成后，IIS会立即拒绝所有使用这些方法的请求，客户端会收到HTTP 405方法不被允许的错误响应。这种方式的优点是操作简单、不易出错，缺点是无法批量处理，当服务器上有几十个站点时，逐个配置效率很低。另外要注意，这里的设置是站点级别的，如果希望在整个服务器层面统一禁用，需要在服务器节点下配置，并确保子站点继承这些设置。

对于需要批量部署或者版本化管理配置的场景，直接修改web.config文件是更好的选择。在站点根目录下的web.config文件中，找到或创建system.webServer节点，添加security/requestFiltering/verbs配置段。一个完整的禁用配置如下：

<configuration>
  <system.webServer>
    <security>
      <requestFiltering>
        <verbs allowUnlisted="false">
          <add verb="GET" allowed="true" />
          <add verb="POST" allowed="true" />
          <add verb="HEAD" allowed="true" />
        </verbs>
      </requestFiltering>
    </security>
  </system.webServer>
</configuration>

这里的关键属性是allowUnlisted，当设置为false时，所有未在列表中明确声明为允许的方法都会被自动拒绝。这意味着你只需要列出白名单方法，不需要逐一去添加黑名单。这种方式比逐个拒绝更安全，因为未来任何新出现的HTTP方法都会被默认拦截。配置完成后，IIS会自动检测web.config的变更并立即生效，无需重启站点。如果需要在服务器级别统一配置，可以将这段配置放在applicationHost.config文件中，路径通常在C:\Windows\System32\inetsrv\config目录下，修改后需要重启IIS服务或执行iisreset命令。

管理几十台服务器时，手动操作显然不现实。IIS提供了appcmd命令行工具，可以快速完成HTTP方法的限制。以管理员身份打开命令提示符，执行以下命令可以在服务器级别全局禁用PUT方法：

appcmd set config /section:requestFiltering /+verbs.[verb='PUT',allowed='false']

如果要采用白名单模式，先设置allowUnlisted为false，然后逐一添加允许的方法：

appcmd set config /section:requestFiltering /verbs.allowUnlisted:false
appcmd set config /section:requestFiltering /+verbs.[verb='GET',allowed='true']
appcmd set config /section:requestFiltering /+verbs.[verb='POST',allowed='true']
appcmd set config /section:requestFiltering /+verbs.[verb='HEAD',allowed='true']

对于更复杂的自动化场景，PowerShell提供了强大的脚本能力。以下脚本可以遍历服务器上所有站点，统一应用HTTP方法白名单：

Import-Module WebAdministration
$sites = Get-ChildItem IIS:\Sites
foreach ($site in $sites) {
    $siteName = $site.Name
    Set-WebConfigurationProperty -Filter "system.webServer/security/requestFiltering/verbs" -Name allowUnlisted -Value $false -PSPath "IIS:\Sites\$siteName"
    Add-WebConfiguration -Filter "system.webServer/security/requestFiltering/verbs" -PSPath "IIS:\Sites\$siteName" -Value @{verb="GET";allowed="true"}
    Add-WebConfiguration -Filter "system.webServer/security/requestFiltering/verbs" -PSPath "IIS:\Sites\$siteName" -Value @{verb="POST";allowed="true"}
    Add-WebConfiguration -Filter "system.webServer/security/requestFiltering/verbs" -PSPath "IIS:\Sites\$siteName" -Value @{verb="HEAD";allowed="true"}
}

这个脚本会覆盖所有站点的配置，执行前务必确认业务需求。如果某些站点确实需要额外的HTTP方法，可以在脚本中添加排除逻辑，或者在站点级别的web.config中单独覆盖服务器级别的设置。

配置完成后，必须验证HTTP方法限制是否真正生效。最简单的方式是使用curl命令行工具发送测试请求。以PUT方法为例，向服务器发送一个PUT请求并观察响应状态码：

curl -X PUT https://yourdomain.com/test.txt -I

如果配置正确，服务器应该返回HTTP 405 Method Not Allowed状态码。继续测试DELETE、TRACE等方法，确保都返回405。对于TRACE方法，还可以发送一个带有自定义请求头的请求，检查响应中是否回显了该请求头，以确认TRACE确实被禁用：

curl -X TRACE https://yourdomain.com/ -H "Test-Header: sensitive-data" -v

如果响应体中不包含Test-Header的内容，说明TRACE方法已经被成功拦截。除了手动测试，也可以使用专业的漏洞扫描工具进行批量检测，这些工具通常内置了HTTP方法检测模块，能够快速扫描出所有可用的危险方法。另外，定期检查IIS日志也是好习惯，搜索日志中出现的PUT、DELETE、TRACE等方法的请求记录，如果发现有405响应，说明拦截生效；如果出现200或其他成功状态码，则需要立即排查配置问题。

在实际操作中，直接禁用所有非必要方法可能会影响某些业务功能。RESTful API服务可能确实需要使用PUT和DELETE方法来实现资源的更新和删除，这种情况下就不能简单地一刀切。解决方案是分层控制：在服务器级别保持严格的白名单，然后在需要特殊方法的站点或虚拟目录级别，通过web.config单独开放特定方法。另一个常见问题是WebDAV模块，它依赖PUT、DELETE、PROPFIND等方法来实现远程文件管理。如果你的站点不需要WebDAV功能，建议直接在IIS中卸载WebDAV模块，而不是仅仅禁用相关方法，因为模块本身的存在就可能引入额外的攻击面。还有一点容易被忽略的是OPTIONS方法，虽然它本身不危险，但它会泄露服务器支持的HTTP方法列表，等于给攻击者提供了信息收集的便利。如果业务不需要CORS预检，禁用OPTIONS是更安全的选择；如果需要，可以通过代码层面精确控制OPTIONS请求的响应内容，而不是完全依赖IIS的默认处理。

禁用不安全HTTP方法只是Web服务器安全加固的一个环节，单独依赖这一措施远远不够。它应该与请求筛选的其他功能配合使用，比如限制URL长度、查询字符串长度、文件扩展名黑名单等。同时，Web应用防火墙可以在请求到达服务器之前就拦截恶意HTTP方法，提供额外一层防护。服务器层面的配置与WAF规则形成互补，即使WAF被绕过，服务器本身仍然会拒绝危险方法。此外，定期进行安全审计和渗透测试，持续验证HTTP方法限制的有效性，也是维持安全状态的关键。对于已经遭受过攻击的服务器，除了修复漏洞和加固配置，还应该仔细检查IIS日志，分析攻击者是否通过HTTP方法漏洞上传了后门文件或修改了系统配置，彻底清除潜在威胁。

HTTP方法限制看似是一个简单的配置项，但它直接关系到Web服务器的攻击面大小。在无数次的安全事件中，攻击者正是利用这些看似无害的默认配置，一步步渗透进内网、窃取数据。花半小时完成这些配置，远比事后花数周时间做应急响应和溯源分析划算得多。而且这些配置一旦部署，基本不需要后续维护，属于性价比极高的安全投入。对于任何运行在公网上的IIS服务器，无论承载的是企业官网还是内部管理系统，都应该将HTTP方法白名单作为上线前的标准检查项，而不是等到出了安全问题才想起来补救。