当前位置： 首页 > news >正文

IIS安全加固实战：隐藏版本信息与配置URLScan防御Web攻击

news 2026/6/26 12:44:07

1. 项目概述：一次典型的IIS安全加固实战

最近在给一个老项目做安全巡检，发现一个挺典型但容易被忽略的问题：IIS服务器版本信息暴露。这玩意儿说大不大，说小不小，但在渗透测试里，这往往是攻击者踩点的第一步。知道了你用的IIS具体版本，人家就能去漏洞库里精准匹配，看看有没有对应的历史漏洞能直接利用，攻击成本直线下降。同时，结合最近的一些安全热点，比如CVE-2016-2183（SSL/TLS协议信息泄露）、CVE-2010-2730这类老漏洞的修复要求，以及日常部署中遇到的CORS策略、应用池回收后数据库连接异常等问题，都指向了IIS配置管理的精细化和安全加固的必要性。

这次的任务很明确，就两件事：第一，把IIS默认响应的Server头信息改掉，别让它轻易暴露自己的“身份证”；第二，安装并配置URLScan这款经典的IIS安全过滤工具，从请求入口就筑起一道防线。这不仅是应对等保测评、满足合规性要求（比如记录中间件等保测评结果）的常规操作，更是提升Web服务器自身韧性的基本功。无论你是用IIS部署Django、用友U8，还是运行一些老旧的ASP应用，这些基础安全配置都通用。下面，我就把这次完整的操作流程、背后的原理，以及踩过的坑、总结的技巧，毫无保留地分享出来。

2. 核心需求与风险深度解析

2.1 为什么必须隐藏IIS版本信息？

IIS在默认情况下，会在HTTP响应头中携带一个Server字段，例如Server: Microsoft-IIS/10.0。这个信息对于系统管理员和开发者调试来说可能有用，但在互联网上，这就是一个明确的风险信号。

风险一：攻击面测绘与精准攻击。攻击者使用简单的工具（如curl -I你的网站）就能获取这个信息。一旦得知具体版本，他们就可以查询该版本IIS及对应Windows Server系统所有已知的公开漏洞。例如，如果暴露的是IIS 7.5，攻击者可能会尝试利用CVE-2010-2730（FastCGI缓冲区溢出）等历史漏洞进行攻击尝试，大大提高了攻击成功率。

风险二：安全策略绕过。一些自动化攻击脚本会首先检查服务器类型和版本，然后选择对应的攻击载荷。隐藏版本信息可以增加攻击者的识别成本，迫使他们对多种可能性进行测试，从而可能触发我们部署的入侵检测规则。

风险三：合规性要求。在等保测评、行业安全规范中，通常明确要求“不应在HTTP响应头中泄露服务器软件的具体版本信息”。这属于“安全审计”或“入侵防范”层面的基本要求。记录“IIS中间件等保测评结果”时，版本信息泄露往往是一个扣分项。

注意：隐藏版本信息是一种“安全通过隐匿”的初级手段，绝不能替代及时安装系统补丁和更新IIS本身。它的核心价值在于增加攻击者的信息收集难度，为其他安全措施争取时间。

2.2 URLScan能解决哪些实际问题？

URLScan是微软提供的一款经典的IIS安全工具，它作为一个ISAPI筛选器运行，在IIS处理HTTP请求的早期阶段进行拦截和过滤。你可以把它理解成IIS的“门卫”，所有请求都要先经过它的检查才能进门。

它的核心功能是基于规则过滤恶意请求，能有效防御多种常见Web攻击：

  1. 路径遍历与目录穿越攻击：过滤包含../、..\、%2e%2e%2f等编码的请求，防止攻击者访问Web目录之外的文件。
  2. SQL注入探测：可以配置规则，拦截请求URL或查询字符串中包含常见SQL关键字（如union select,xp_cmdshell,' OR '1'='1）的请求。
  3. 跨站脚本攻击：过滤请求中异常的<script>,javascript:等标签和事件处理器。
  4. 服务器端包含攻击：阻止包含<!--#include或<%等指令的请求。
  5. 限制危险的HTTP方法：默认可以禁止如PUT,DELETE,TRACE,DEBUG等非必要且高风险的方法，只允许GET,POST,HEAD。
  6. 基于扩展名的过滤：可以直接禁止对.config,.bak,.old,.log等敏感文件的直接访问请求。

对于搜索热词中提到的“CORS漏洞修复”，URLScan本身不直接处理CORS头，但它可以拦截那些试图利用错误CORS配置的畸形或恶意请求。而像“IIS无法读取数据库，回收后正常”这类问题，通常与连接池管理有关，URLScan虽不直接解决，但稳定的请求过滤环境有助于减少异常请求对应用池的意外冲击。

3. 环境准备与工具获取

3.1 确认IIS环境与权限

在开始操作前，我们需要明确服务器的环境。从热词看，可能涉及 Windows Server 2012/2019/2022 等多个版本。不同版本的IIS管理界面和部分功能路径略有差异，但核心操作一致。

  • 查看IIS版本：在服务器上，打开“Internet Information Services (IIS)管理器”，点击左侧服务器节点，在中间“管理”区域找到“IIS”部分下的“服务器证书”或直接看关于信息，即可确认版本。或者，在命令行运行%windir%\system32\inetsrv\appcmd.exe list config -section:system.webServer/security/requestFiltering，输出的头部信息也会包含版本。
  • 管理员权限：以下所有修改操作，都需要在拥有服务器本地管理员权限的账户下进行。如果是在生产环境，请务必在变更窗口内操作，并提前做好备份。

3.2 获取URLScan工具

URLScan有多个版本，对应不同版本的IIS。对于现代Windows Server（2012 R2及以后，对应IIS 8+），我们通常使用URLScan 3.1。这是一个独立安装包。

  1. 官方下载：最可靠的来源是微软官方下载中心或安全公告附件。你可以搜索“URLScan 3.1”从微软官网获取。如果官网链接变更，也可以从一些可信的第三方技术社区找到存档版本。
  2. 文件确认：下载后通常是一个MSI安装包（如UrlScan3.1.msi）或一个包含urlscan.dll、urlscan.ini等文件的压缩包。我们主要需要的是urlscan.dll（主程序）和urlscan.ini（配置文件）。

实操心得：我建议将URLScan的安装文件（如MSI包）和配置文件备份在一个固定的目录，比如C:\Tools\URLScan\。这样以后在其他服务器上部署，或者需要回滚配置时，会非常方便。不要直接从不明来源的网站下载DLL文件，以防被植入恶意代码。

4. 实操步骤一：隐藏IIS服务器版本信息

隐藏Server头信息有多种方法，这里介绍两种最常用、最有效的方法：通过IIS管理器图形界面修改，以及通过web.config文件进行配置。推荐使用方法二，因为它更灵活，可以应用到特定站点或应用。

4.1 方法一：使用IIS管理器全局修改（适用于IIS 7+）

这种方法修改的是服务器级别的配置，对所有站点生效。

  1. 打开IIS管理器。
  2. 在左侧连接面板中，点击服务器节点（你的服务器名）。
  3. 在主窗口中间，找到“管理”部分，双击“配置编辑器”。
  4. 在配置编辑器顶部，从“部分”下拉菜单中选择system.webServer/security/requestFiltering。
  5. 在展开的树形结构中，找到requestFiltering->alwaysAllowedUrls的同级或父级，实际上我们需要找的是system.webServer/security/requestFiltering下的removeServerHeader。但请注意，旧版本IIS的GUI可能不直接提供此选项。更通用的路径是修改system.webServer/httpProtocol下的customHeaders。
  6. 更直接的方法是修改system.webServer/security/requestFiltering下的removeServerHeader。如果找不到，则采用方法二。

4.2 方法二：通过web.config或applicationHost.config修改（推荐）

这是更底层、更可靠的方式。我们可以直接编辑配置文件。

原理：IIS有一个设置叫removeServerHeader，将其设为true即可移除Server头。另外，我们还可以添加一个自定义的、虚假的Server头来迷惑扫描器。

操作步骤：

  1. 定位配置文件：

    • 针对特定站点/应用：在该站点或应用的根目录下，修改或创建web.config文件。
    • 针对整个服务器：修改%windir%\system32\inetsrv\config\applicationHost.config文件（修改前务必备份！）。

  2. 编辑配置：在<system.webServer>节点下，添加或修改<security>和<rewrite>（用于自定义头）规则。

以下是一个功能完整的web.config示例，它同时做了三件事：移除原始Server头、添加一个假的Server头、移除X-Powered-By头（ASP.NET等框架也会泄露信息）。

<?xml version="1.0" encoding="UTF-8"?> <configuration> <system.webServer> <!-- 1. 移除默认的 Server 头 --> <security> <requestFiltering removeServerHeader="true" /> </security> <!-- 2. 移除 X-Powered-By 头 (如果存在) --> <httpProtocol> <customHeaders> <remove name="X-Powered-By" /> <remove name="X-AspNet-Version" /> <!-- 3. 可选：添加一个假的 Server 头迷惑扫描器 --> <add name="Server" value="Apache/2.4.1 (Unix)" /> </customHeaders> </httpProtocol> <!-- 以下是一个可选的URL重写规则，作为另一种移除Server头的方法，与上面requestFiltering任选其一即可 --> <!-- <rewrite> <outboundRules> <rule name="Remove Server header"> <match serverVariable="RESPONSE_Server" pattern=".*" /> <action type="Rewrite" value="" /> </rule> </outboundRules> </rewrite> --> </system.webServer> </configuration>

  1. 保存并生效：保存web.config文件。IIS会自动检测到文件变更并应用新配置。无需重启IIS或应用池。

  2. 验证效果：打开命令提示符（CMD），使用curl命令测试：

    curl -I http://你的服务器IP或域名/

    观察返回的HTTP头部。如果成功，你将看不到Server: Microsoft-IIS/xx.x这样的字段，或者看到的是你自定义的假值（如Server: Apache/2.4.1 (Unix)）。

注意事项：修改applicationHost.config会影响服务器上所有站点，风险较高。建议优先在站点级的web.config中配置。如果某个站点需要保留Server头（例如某些CDN或负载均衡器需要），可以在该站点的web.config中使用<remove name="Server" />然后再<add>一个自定义值，或者不配置此项。

5. 实操步骤二：安装与配置URLScan 3.1

5.1 安装URLScan

  1. 运行安装程序：如果下载的是MSI包，直接以管理员身份运行安装。安装过程很简单，基本一路“Next”即可。安装程序会自动将urlscan.dll注册为全局ISAPI筛选器，并在%windir%\system32\inetsrv\urlscan目录下创建配置文件和日志目录。
  2. 手动部署（如果没有MSI）：
    • 将urlscan.dll复制到%windir%\system32\inetsrv\目录。
    • 将urlscan.ini复制到%windir%\system32\inetsrv\urlscan\目录（可能需要手动创建该目录）。
    • 以管理员身份打开命令提示符，执行以下命令注册DLL：
      cd %windir%\system32\inetsrv\ regsvr32 urlscan.dll

5.2 配置URLScan规则（关键步骤）

URLScan的行为完全由urlscan.ini配置文件控制。默认配置文件比较严格，可能会阻断一些正常的请求。我们的目标是安全且可用，因此需要根据实际应用进行调整。配置文件通常位于%windir%\system32\inetsrv\urlscan\。

下面我们逐部分解析关键配置项：

（1）[Options] 部分 - 基础选项

[Options] ; 是否启用URLScan。1=启用，0=停用 UseAllowVerbs=0 UseAllowExtensions=0 NormalizeUrlBeforeScan=1 VerifyNormalization=1 AllowHighBitCharacters=0 ; 通常设为0，防止Unicode攻击 AllowDotInPath=0 ; 设为0，防止路径遍历 RemoveServerHeader=1 ; 与之前操作呼应，再次移除Server头 ; 日志级别：0=无，1=仅错误，2=警告，3=信息，4=详细调试 LoggingLevel=2 LoggingDirectory=C:\Windows\System32\inetsrv\urlscan\logs ; 日志路径
  • UseAllowVerbs和UseAllowExtensions：设为0表示使用“拒绝列表”模式。即，我们定义哪些动词（HTTP方法）和扩展名是不允许的。另一种模式是设为1，使用“允许列表”，只放行明确允许的，更严格但配置更复杂。新手建议从“拒绝列表”开始。
  • NormalizeUrlBeforeScan和VerifyNormalization：务必设为1。这能确保URL在被扫描前被规范化（解码URL编码），防止攻击者通过双重编码等手段绕过过滤。

（2）[AllowVerbs] 和 [DenyVerbs] 部分 - 控制HTTP方法

[AllowVerbs] ; 如果UseAllowVerbs=1，则只允许下面列出的方法 GET HEAD POST [DenyVerbs] ; 如果UseAllowVerbs=0，则拒绝下面列出的方法 PUT DELETE TRACE DEBUG TRACK CONNECT OPTIONS

对于大多数Web应用（如搜索热词中的用友U8、Django应用、普通网站），GET、HEAD、POST足够了。OPTIONS方法在CORS预检请求中会用到，如果你遇到“has been blocked by CORS policy”错误，并且前端确实需要跨域，可以考虑将OPTIONS从[DenyVerbs]移到[AllowVerbs]，或者在[DenyVerbs]中删除它（当UseAllowVerbs=0时）。这是一个常见的配置冲突点。

（3）[DenyExtensions] 部分 - 拒绝危险的文件扩展名

[DenyExtensions] ; 拒绝访问以下扩展名的文件 .asa .asax .ascx .ashx .asmx .asp .aspx .axd .bak .bat .cdx .cer .config .cs .csproj .dat .db .dll .exe .ini .log .mdb .old .pass .pdb .resources .swp .sys .vb .vbproj .vsdisco .webinfo

这个列表已经包含了很多敏感文件。你可以根据自己站点的实际情况增减。例如，如果你的站点有.json或.xml的API接口，就不能把它们加进来。

（4）[DenyUrlSequences] 部分 - 拒绝危险的URL序列

[DenyUrlSequences] ; 拒绝包含以下序列的URL .. ./ .\ : & % ? ;

这是防御路径遍历和参数注入的关键。../和./用于目录穿越，:可能用于NTFS流，&,%,?是查询字符串分隔符，在特定位置出现可能异常。分号;在某些攻击中也有用。

（5）[AllowExtensions] 部分当UseAllowExtensions=0时，此部分无效。如果设为1，则需要在这里穷举所有允许的静态文件和动态处理程序扩展名，如.html,.htm,.js,.css,.jpg,.png,.gif,.aspx,.php等，配置非常繁琐，容易遗漏导致网站部分功能失效。

5.3 将URLScan应用到IIS站点

安装并配置好urlscan.ini后，需要将其与IIS的站点关联。

  1. 打开IIS管理器。
  2. 在左侧选择你要保护的网站（或者为了全局生效，点击服务器节点）。
  3. 在主窗口中间，双击“ISAPI 筛选器”。
  4. 在右侧操作面板，点击“添加”。
  5. 在弹出的对话框中：
    • 筛选器名称：输入URLScan。
    • 可执行文件：点击浏览，定位到%windir%\system32\inetsrv\urlscan.dll。
  6. 点击“确定”。

现在，URLScan筛选器就添加到了该网站。IIS会在启动该网站时加载它。如果你是在服务器节点添加的，则对所有站点生效。

5.4 测试与验证

  1. 重启IIS或对应应用池：为了使URLScan配置生效，最简单的方法是重启一下该网站对应的应用程序池，或者在命令行执行iisreset（影响所有站点）。
  2. 测试正常访问：用浏览器正常访问你的网站，确保所有功能（页面浏览、表单提交、静态资源加载）都正常。
  3. 测试恶意请求：
    • 尝试访问http://yoursite.com/../../windows/win.ini（路径遍历）。应该收到一个404.7 - URL Scan或类似的拒绝访问错误。
    • 尝试使用PUT方法请求一个URL：curl -X PUT http://yoursite.com/test.txt。应该收到404.5 - HTTP verb rejected错误。
    • 尝试访问一个不存在的危险扩展名：http://yoursite.com/web.config。应该被拒绝。
  4. 检查日志：查看%windir%\system32\inetsrv\urlscan\logs\目录下的日志文件（以日期命名），里面会记录被拦截的请求详情，包括原因、客户端IP等，这对于安全分析和规则调优至关重要。

6. 高级配置与疑难问题排查

6.1 针对特定场景的规则调优

  • 场景：网站使用Web API（ASP.NET Web API, RESTful API）

    • 问题：API可能需要使用PUT,DELETE,PATCH等方法。
    • 解决：不能简单地在[DenyVerbs]中删除这些方法，这样会降低安全性。更好的做法是：
      1. 将API部署在一个独立的应用程序或虚拟目录下，例如/api/。
      2. 为该/api/应用单独设置一个web.config，并在其中使用<remove filter />移除URLScan筛选器，或者为该路径配置更宽松的URLScan规则（需要更复杂的配置）。更常见的做法是，在API层（如ASP.NET Core Middleware或Spring Security）实现方法级别的认证和授权，而在IIS层只放行必要方法。

  • 场景：前端报告CORS错误

    • 问题：浏览器控制台报错 “has been blocked by CORS policy”。
    • 排查：
      1. 首先确认是预检请求被拦截。预检请求使用OPTIONS方法。检查URLScan的[DenyVerbs]是否包含了OPTIONS。
      2. 如果包含，将其移除或移到[AllowVerbs]。
      3. CORS响应头（如Access-Control-Allow-Origin）需要在后端应用代码或IIS的HTTP响应头模块中设置，URLScan不负责添加这些头。

  • 场景：网站部分功能（如下载、上传）异常

    • 问题：上传文件功能失效，或某些特定URL的请求被拦截。
    • 排查：
      1. 检查扩展名：上传的文件扩展名是否在[DenyExtensions]列表中？例如，如果允许上传.txt文件，要确保.txt不在拒绝列表里。
      2. 检查URL序列：上传的URL可能包含&或?等字符。查看[DenyUrlSequences]是否过于严格。通常这些字符在查询字符串中是允许的，URLScan会智能区分。但如果你的URL路径部分包含这些字符（不常见），就可能被拦截。
      3. 查看日志：这是最直接的方法。找到被拦截的请求日志，查看Rejection Reason字段，它会明确告诉你是因为Verb、Extension还是Sequence被拒绝。

6.2 URLScan常见问题与解决方案速查表

问题现象可能原因解决方案
网站所有页面返回404.7 - URL Scan[DenyUrlSequences]规则过于严格，拦截了正常路径字符（如/被误加？）或UseAllowExtensions=1但[AllowExtensions]列表为空/不全。1. 检查urlscan.ini的[DenyUrlSequences]部分，移除对正常字符如/的限制（默认不应有）。
2. 如果UseAllowExtensions=1，确保[AllowExtensions]列出了网站需要的所有扩展名（如.html,.aspx,.php,/等）。建议新手先将UseAllowExtensions改回0。
网站静态资源（CSS, JS, 图片）无法加载静态资源的文件扩展名（如.css,.js,.png）被列入了[DenyExtensions]，或者UseAllowExtensions=1时未在[AllowExtensions]中列出。1. 检查[DenyExtensions]，移除.css,.js,.png,.jpg,.gif等静态资源扩展名。
2. 如果使用允许列表模式，确保将它们添加到[AllowExtensions]。
表单提交或API调用失败，返回404.5 - HTTP verb rejected表单或API使用了POST以外的HTTP方法（如PUT,DELETE），且该方法在[DenyVerbs]中。1. 确认应用是否需要这些方法。
2. 如果确实需要，将PUT,DELETE等从[DenyVerbs]列表中移除（安全风险升高）。
3. 更优解：将使用特殊方法的API隔离到独立应用，并配置更精细的规则。
前端出现CORS错误，预检请求失败OPTIONS方法被[DenyVerbs]拒绝。将OPTIONS从[DenyVerbs]列表中移除。
URLScan日志文件快速增长，磁盘空间不足LoggingLevel设置过高（如4），记录了太多信息。将LoggingLevel调整为2（警告）或1（仅错误）。定期清理日志目录。
修改urlscan.ini后配置未生效IIS应用程序池未回收/重启，或配置文件有语法错误。1. 在IIS管理器中回收对应的应用程序池。
2. 检查urlscan.ini文件格式，确保没有多余的空格或中文标点。
3. 查看系统事件查看器，在“Windows日志 -> 应用程序”中筛选来源为“UrlScan”的错误事件。

6.3 与其他安全措施的联动

隐藏Server头和部署URLScan只是IIS安全加固的起点。一个纵深防御的体系还应考虑：

  • 及时更新与补丁管理：定期安装Windows Update，修复像CVE-2016-2183（SSL/TLS）、CVE-2010-2730（FastCGI）这类IIS相关漏洞。这是最根本的。
  • 最小化权限原则：为IIS应用池配置独立的、低权限的账户运行。确保网站目录的NTFS权限严格，仅授予该账户必要的读/写权限。
  • 配置请求筛选与限制：除了URLScan，IIS自带的“请求筛选”模块（Request Filtering）也非常强大，可以设置URL长度、查询字符串长度、文件上传大小等限制，应与URLScan配合使用。
  • 启用动态IP限制：防止暴力破解，可以配置同一IP在短时间内最大请求数。
  • 使用Web应用防火墙：对于高安全要求的场景，应考虑部署专业的WAF（如ModSecurity for IIS），它提供比URLScan更强大、更灵活的规则引擎。

完成上述所有步骤后，你的IIS服务器在信息泄露和基础Web攻击防护方面已经有了显著的提升。记住，安全是一个持续的过程，定期审查URLScan日志、关注IIS和Windows的安全公告、并根据应用的变化调整安全配置，才是长治久安之道。这套组合拳打下来，无论是应对日常扫描，还是满足等保测评中对中间件安全配置的检查项，都能让你心里更有底。

http://www.jsqmd.com/news/1081417/

相关文章：

  • 【VMware ESXi 免费版终极避坑指南】：20年虚拟化老兵亲授5大隐藏限制、3个合规红线与2024年最新替代方案
  • 3步搞定百度网盘高速下载：Python解析工具实用指南
  • XXMI启动器：二次元游戏模组管理的终极完整解决方案
  • DouyinLiveRecorder终极指南：一站式录制40+直播平台的完整解决方案
  • P89LPC9151看门狗与IAP-Lite Flash编程实战指南
  • 深入解析EM773 Flash编程：ECC数据保护与CRP安全机制实战指南
  • ALIGN与传统品牌咨询公司的核心差异是什么？精品咨询vs大型咨询深度对比
  • 053、文件读写那些坑：open 的模式、编码检测、大文件分块与上下文安全
  • RAG 在线工作流：从用户提问到可信答案的完整工程链路
  • 猫抓扩展：5分钟快速上手网页视频音频资源嗅探完整指南
  • 车规级晶振在车载电子中的关键作用与应用验证
  • 昆明市安宁市贴身保镖公司有哪些推荐的
  • Navicat密码解密终极指南：3分钟快速找回数据库连接密码
  • EM773微控制器IAP编程与SWD调试实战指南
  • P89LPC9321 CCU模块实战：输入捕获与PWM驱动电机控制
  • ZigBee端点配置实战：组管理与绑定实现本地智能控制
  • 番茄小说下载器：如何轻松实现离线阅读自由
  • 如何永久保存微信聊天记录：WeChatMsg终极数据留痕实战指南
  • JMeter压测Dubbo服务：从插件部署到实战调优全攻略
  • ESP32光伏MPPT与数字电源系统设计优化
  • LPC315x USB OTG中断与DMA实战：嵌入式系统高效事件处理与数据搬移
  • 联发科设备管理终极指南：MTKClient 5大核心功能深度解析与实战应用
  • 算子代数视角下的Navier-Stokes方程谱复杂性分析
  • MyTV Android经典三段界面频道列表崩溃深度剖析与防御性编程实践
  • Nginx ssl_reject_handshake指令实战：彻底隐藏CDN背后的源站IP
  • 蓝牙音频系统设计实战：基于NxH3670 SDK开发板的硬件架构与软件调试
  • ARM嵌入式系统控制寄存器(SysCReg)配置实战：从总线仲裁到引脚复用
  • RimSort终极指南：快速掌握环世界模组管理的完整解决方案
  • i.MX G2D API硬件加速图形开发实战：从原理到性能优化
  • 【ESXi 7.0零基础安装终极指南】：20年VMware架构师亲授，避开97%新手踩坑的12个致命细节