Windows服务器IIS安全配置与请求过滤

把一台全新的Windows服务器丢到公网上，不做任何加固，平均被攻陷的时间可能不超过24小时。这不是危言耸听，大量的自动化扫描工具在持续嗅探着默认开放的端口和服务。IIS作为Windows生态的核心Web服务器，其默认配置往往优先考虑兼容性和易用性，而非安全性。直接投入使用，等于把家门钥匙挂在门外。安全配置不是锦上添花，是上线前的最后一道工序，必须亲手焊死。

安全的第一原则是“最小权限”和“最少组件”。很多人装完系统，习惯性地点选“Web服务器（IIS）”角色后一路下一步，结果安装了大量的无关模块。你需要立刻打开服务器管理器，检查IIS角色服务。凡是没用的，一律卸载。WebDAV发布、FTP服务器、IIS管理控制台（如果不是必需）、ASP.NET早期版本、CGI、ISAPI扩展和筛选器，如果你明确自己的应用不需要，就不要勾选。每一个多余的组件都是一个潜在的攻击向量。特别是WebDAV，历史上出过太多严重漏洞，如果业务不涉及文件远程发布，务必将其彻底移除。服务器只应该运行支撑业务所必需的最少代码，多一行都是风险。

这是最容易被忽视的配置。绝不要把所有网站都丢进默认的DefaultAppPool里运行。你必须为每一个站点创建独立的应用程序池。这样做的好处是双重的：其一，实现进程隔离，一个站点崩溃或被攻破，不会影响其他站点；其二，可以针对每个站点设置不同的运行身份。为每个应用池配置一个独立的、权限极低的域账户或本地账户，而不是使用Network Service这种共享的内置账户。在应用程序池的高级设置中，将“标识”修改为你专门创建的账户，并确保该账户的密码符合强复杂度要求。同时，设置“空闲超时”为一个合理的值，比如20分钟，让不活动的进程自动回收，释放资源。回收机制也要配置，可以设定特定时间进行回收，避免长时间运行可能产生的内存泄漏被利用。

IIS的运行账户只应该拥有读取和执行Web内容文件的权限，仅此而已。你的网站根目录，比如C:\inetpub\wwwroot，默认权限过于宽松。你需要彻底清理。首先，移除Everyone和Users组的权限。然后，为你的应用程序池专属账户只分配“读取和执行”、“列出文件夹内容”和“读取”权限。对于需要写入的特殊目录，比如上传文件夹、日志目录或数据库文件目录，单独为这些子目录分配“写入”权限，但绝对不要给“执行”权限。如果你允许用户上传文件到某个目录，同时该目录又有脚本执行权限，这等于搭建了一个免费的WebShell后门仓库。静态资源目录和脚本执行目录必须严格分离，这是铁律。

IIS的请求过滤模块是抵御注入攻击和探测扫描的第一道防线，但默认规则几乎形同虚设。你需要在站点级别或服务器级别，打开“请求筛选”功能进行精细化配置。第一件事，是定义允许的文件扩展名。不要使用“允许未列出的文件扩展名”这种懒惰做法。切换到“拒绝未列出的文件扩展名”模式，然后显式添加你应用所需的扩展名，如.aspx、.html、.css、.js、.jpg等。任何不在白名单里的扩展名请求，IIS会直接返回404.7错误，连应用程序代码都碰不到。这能有效阻断对.bak、.config、.sql、.zip等敏感文件的探测。

在请求筛选的“HTTP谓词”选项卡中，你可以精确控制允许的HTTP方法。如果你的网站只提供浏览和表单提交功能，那么允许GET、POST和HEAD就足够了。像OPTIONS、TRACE、DELETE、PUT这些方法，除非你的RESTful API明确需要，否则一律拒绝。特别是TRACE方法，它可能导致跨站追踪攻击，泄露用户的认证信息。你可以直接添加一个拒绝条目，写上TRACE，IIS就会拦截所有TRACE请求。同样地，对PUT和DELETE的拒绝，也能防止攻击者尝试直接上传文件或篡改资源。

攻击者经常在URL和查询字符串中构造超长字符或特殊编码来进行缓冲区溢出或SQL注入探测。在请求筛选的“URL”选项卡下，你可以设置最大URL长度、最大查询字符串长度和最大路径段长度。将查询字符串长度限制在一个合理范围，比如2048字符，可以有效拦截那些携带大量注入代码的请求。更关键的是“规则”选项卡，这里可以创建自定义过滤规则。你可以添加规则，拒绝任何查询字符串中包含“<script”或“1=1”这类经典攻击特征的请求。但要注意，过于严格的通用规则可能误伤正常业务，需要仔细测试。一个更稳妥的做法是，针对你应用的具体参数进行白名单验证，但请求过滤模块的规则可以作为粗粒度的第一道防线。</p> 隐藏服务器身份，增加攻击难度

默认情况下，IIS会在HTTP响应头中大方地告知攻击者服务器的版本信息，如Server: Microsoft-IIS/10.0，以及X-Powered-By: ASP.NET。这极大降低了攻击者的侦察成本。你需要通过配置，移除或修改这些响应头。对于Server头，可以通过安装URL Rewrite模块，然后在web.config或IIS管理器的输出规则中，创建一个出站规则来清空其值。规则配置如下：

<outboundRules>
  <rule name="Remove Server Header">
    <match serverVariable="RESPONSE_SERVER" pattern=".*" />
    <action type="Rewrite" value="" />
  </rule>
</outboundRules>

对于X-Powered-By头，直接在IIS的“HTTP响应标头”功能中将其移除即可。这虽然只是安全模糊化的一种手段，但能有效过滤掉大量依赖版本信息进行漏洞匹配的自动化扫描脚本。

启用HTTPS只是第一步，配置不当的HTTPS依然是脆弱的。你必须在服务器级别，通过修改注册表或使用IIS Crypto这类工具，强制禁用SSL 2.0、SSL 3.0、TLS 1.0和TLS 1.1。这些协议都存在已知的严重漏洞，如POODLE和BEAST攻击。你应该只启用TLS 1.2和TLS 1.3。同时，需要配置强加密套件顺序，优先使用支持前向保密（ECDHE）和AEAD加密模式（如AES-GCM）的套件，彻底禁用RC4、3DES和CBC模式的套件。这不仅关乎数据加密的强度，也直接影响你的业务在合规性审计和第三方安全评级中的表现。

如果你的Web应用是面向内部员工或特定合作伙伴的，那么最有效的安全措施就是网络层访问控制。安装“IP和域限制”角色服务后，你可以为整个服务器或特定站点设置允许或拒绝的IP地址列表。默认设置为拒绝所有，然后添加允许的内部网段IP，这是一种极其坚固的防护方式。对于公网站点，这个功能同样有价值。你可以用它来封禁那些持续进行恶意扫描或暴力破解的IP地址。结合动态IP限制模块，可以自动识别并临时封禁异常高频请求的客户端IP，有效缓解CC攻击和暴力破解。

没有日志，安全事件发生后你连溯源都做不到。必须确保IIS日志已启用，并且记录了所有关键字段，包括客户端IP、用户名、请求时间、方法、URI资源、查询字符串、协议状态和子状态、用户代理和Referer。更重要的是，要定期分析这些日志。不要等到出事了才去看。通过分析状态码，特别是大量404.7（请求筛选拒绝）、401（未授权）、500（服务器错误）的记录，你可以及时发现正在进行的攻击探测或已成功的入侵尝试。将IIS日志实时同步到集中的日志分析平台，结合告警规则，才能将静态配置转化为动态防御能力。

永远不要将web.config、appsettings.json或其他包含数据库连接字符串、API密钥、加密盐值的配置文件暴露在Web可访问目录下。即使你配置了请求过滤拒绝.config扩展名，任何疏忽都可能导致灾难。这些敏感文件应存放在Web根目录之外，通过应用程序的配置路径去引用。同样，不要在代码注释中留下任何敏感信息，也不要将备份文件（.bak, .old）遗留在服务器上。攻击者拿到WebShell后的第一件事，就是翻找这些文件。你的数据库连接字符串应该使用Windows集成身份验证或加密存储，而不是明文写在配置文件里。

服务器的安全状态不是一个终点，而是一个持续的过程。今天看似完美的配置，明天可能因为新漏洞的披露而变得千疮百孔。你需要建立一套机制，定期审查IIS配置、检查用户权限、更新过滤规则、审计访问日志。安全配置与业务功能常常是矛盾的，每一次放宽限制，都必须经过审慎评估。把IIS从一个功能完备的通用平台，改造成一个仅服务于你业务的、坚硬的、不透明的壳，这才是Windows服务器Web安全的核心要义。