1. 项目概述一次典型的IIS安全加固实战最近在给一个老项目做安全巡检发现一个挺典型但容易被忽略的问题IIS服务器版本信息暴露。这玩意儿说大不大说小不小但在渗透测试里这往往是攻击者踩点的第一步。知道了你用的IIS具体版本人家就能去漏洞库里精准匹配看看有没有对应的历史漏洞能直接利用攻击成本直线下降。同时结合最近的一些安全热点比如CVE-2016-2183SSL/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-2730FastCGI缓冲区溢出等历史漏洞进行攻击尝试大大提高了攻击成功率。风险二安全策略绕过。一些自动化攻击脚本会首先检查服务器类型和版本然后选择对应的攻击载荷。隐藏版本信息可以增加攻击者的识别成本迫使他们对多种可能性进行测试从而可能触发我们部署的入侵检测规则。风险三合规性要求。在等保测评、行业安全规范中通常明确要求“不应在HTTP响应头中泄露服务器软件的具体版本信息”。这属于“安全审计”或“入侵防范”层面的基本要求。记录“IIS中间件等保测评结果”时版本信息泄露往往是一个扣分项。注意隐藏版本信息是一种“安全通过隐匿”的初级手段绝不能替代及时安装系统补丁和更新IIS本身。它的核心价值在于增加攻击者的信息收集难度为其他安全措施争取时间。2.2 URLScan能解决哪些实际问题URLScan是微软提供的一款经典的IIS安全工具它作为一个ISAPI筛选器运行在IIS处理HTTP请求的早期阶段进行拦截和过滤。你可以把它理解成IIS的“门卫”所有请求都要先经过它的检查才能进门。它的核心功能是基于规则过滤恶意请求能有效防御多种常见Web攻击路径遍历与目录穿越攻击过滤包含../、..\、%2e%2e%2f等编码的请求防止攻击者访问Web目录之外的文件。SQL注入探测可以配置规则拦截请求URL或查询字符串中包含常见SQL关键字如union select,xp_cmdshell, OR 11的请求。跨站脚本攻击过滤请求中异常的script,javascript:等标签和事件处理器。服务器端包含攻击阻止包含!--#include或%等指令的请求。限制危险的HTTP方法默认可以禁止如PUT,DELETE,TRACE,DEBUG等非必要且高风险的方法只允许GET,POST,HEAD。基于扩展名的过滤可以直接禁止对.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 Server2012 R2及以后对应IIS 8我们通常使用URLScan 3.1。这是一个独立安装包。官方下载最可靠的来源是微软官方下载中心或安全公告附件。你可以搜索“URLScan 3.1”从微软官网获取。如果官网链接变更也可以从一些可信的第三方技术社区找到存档版本。文件确认下载后通常是一个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这种方法修改的是服务器级别的配置对所有站点生效。打开IIS管理器。在左侧连接面板中点击服务器节点你的服务器名。在主窗口中间找到“管理”部分双击“配置编辑器”。在配置编辑器顶部从“部分”下拉菜单中选择system.webServer/security/requestFiltering。在展开的树形结构中找到requestFiltering-alwaysAllowedUrls的同级或父级实际上我们需要找的是system.webServer/security/requestFiltering下的removeServerHeader。但请注意旧版本IIS的GUI可能不直接提供此选项。更通用的路径是修改system.webServer/httpProtocol下的customHeaders。更直接的方法是修改system.webServer/security/requestFiltering下的removeServerHeader。如果找不到则采用方法二。4.2 方法二通过web.config或applicationHost.config修改推荐这是更底层、更可靠的方式。我们可以直接编辑配置文件。原理IIS有一个设置叫removeServerHeader将其设为true即可移除Server头。另外我们还可以添加一个自定义的、虚假的Server头来迷惑扫描器。操作步骤定位配置文件针对特定站点/应用在该站点或应用的根目录下修改或创建web.config文件。针对整个服务器修改%windir%\system32\inetsrv\config\applicationHost.config文件修改前务必备份。编辑配置在system.webServer节点下添加或修改security和rewrite用于自定义头规则。以下是一个功能完整的web.config示例它同时做了三件事移除原始Server头、添加一个假的Server头、移除X-Powered-By头ASP.NET等框架也会泄露信息。?xml version1.0 encodingUTF-8? configuration system.webServer !-- 1. 移除默认的 Server 头 -- security requestFiltering removeServerHeadertrue / /security !-- 2. 移除 X-Powered-By 头 (如果存在) -- httpProtocol customHeaders remove nameX-Powered-By / remove nameX-AspNet-Version / !-- 3. 可选添加一个假的 Server 头迷惑扫描器 -- add nameServer valueApache/2.4.1 (Unix) / /customHeaders /httpProtocol !-- 以下是一个可选的URL重写规则作为另一种移除Server头的方法与上面requestFiltering任选其一即可 -- !-- rewrite outboundRules rule nameRemove Server header match serverVariableRESPONSE_Server pattern.* / action typeRewrite value / /rule /outboundRules /rewrite -- /system.webServer /configuration保存并生效保存web.config文件。IIS会自动检测到文件变更并应用新配置。无需重启IIS或应用池。验证效果打开命令提示符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 nameServer /然后再add一个自定义值或者不配置此项。5. 实操步骤二安装与配置URLScan 3.15.1 安装URLScan运行安装程序如果下载的是MSI包直接以管理员身份运行安装。安装过程很简单基本一路“Next”即可。安装程序会自动将urlscan.dll注册为全局ISAPI筛选器并在%windir%\system32\inetsrv\urlscan目录下创建配置文件和日志目录。手动部署如果没有MSI将urlscan.dll复制到%windir%\system32\inetsrv\目录。将urlscan.ini复制到%windir%\system32\inetsrv\urlscan\目录可能需要手动创建该目录。以管理员身份打开命令提示符执行以下命令注册DLLcd %windir%\system32\inetsrv\ regsvr32 urlscan.dll5.2 配置URLScan规则关键步骤URLScan的行为完全由urlscan.ini配置文件控制。默认配置文件比较严格可能会阻断一些正常的请求。我们的目标是安全且可用因此需要根据实际应用进行调整。配置文件通常位于%windir%\system32\inetsrv\urlscan\。下面我们逐部分解析关键配置项1[Options] 部分 - 基础选项[Options] ; 是否启用URLScan。1启用0停用 UseAllowVerbs0 UseAllowExtensions0 NormalizeUrlBeforeScan1 VerifyNormalization1 AllowHighBitCharacters0 ; 通常设为0防止Unicode攻击 AllowDotInPath0 ; 设为0防止路径遍历 RemoveServerHeader1 ; 与之前操作呼应再次移除Server头 ; 日志级别0无1仅错误2警告3信息4详细调试 LoggingLevel2 LoggingDirectoryC:\Windows\System32\inetsrv\urlscan\logs ; 日志路径UseAllowVerbs和UseAllowExtensions设为0表示使用“拒绝列表”模式。即我们定义哪些动词HTTP方法和扩展名是不允许的。另一种模式是设为1使用“允许列表”只放行明确允许的更严格但配置更复杂。新手建议从“拒绝列表”开始。NormalizeUrlBeforeScan和VerifyNormalization务必设为1。这能确保URL在被扫描前被规范化解码URL编码防止攻击者通过双重编码等手段绕过过滤。2[AllowVerbs] 和 [DenyVerbs] 部分 - 控制HTTP方法[AllowVerbs] ; 如果UseAllowVerbs1则只允许下面列出的方法 GET HEAD POST [DenyVerbs] ; 如果UseAllowVerbs0则拒绝下面列出的方法 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]中删除它当UseAllowVerbs0时。这是一个常见的配置冲突点。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] 部分当UseAllowExtensions0时此部分无效。如果设为1则需要在这里穷举所有允许的静态文件和动态处理程序扩展名如.html,.htm,.js,.css,.jpg,.png,.gif,.aspx,.php等配置非常繁琐容易遗漏导致网站部分功能失效。5.3 将URLScan应用到IIS站点安装并配置好urlscan.ini后需要将其与IIS的站点关联。打开IIS管理器。在左侧选择你要保护的网站或者为了全局生效点击服务器节点。在主窗口中间双击“ISAPI 筛选器”。在右侧操作面板点击“添加”。在弹出的对话框中筛选器名称输入URLScan。可执行文件点击浏览定位到%windir%\system32\inetsrv\urlscan.dll。点击“确定”。现在URLScan筛选器就添加到了该网站。IIS会在启动该网站时加载它。如果你是在服务器节点添加的则对所有站点生效。5.4 测试与验证重启IIS或对应应用池为了使URLScan配置生效最简单的方法是重启一下该网站对应的应用程序池或者在命令行执行iisreset影响所有站点。测试正常访问用浏览器正常访问你的网站确保所有功能页面浏览、表单提交、静态资源加载都正常。测试恶意请求尝试访问http://yoursite.com/../../windows/win.ini路径遍历。应该收到一个404.7 - URL Scan或类似的拒绝访问错误。尝试使用PUT方法请求一个URLcurl -X PUT http://yoursite.com/test.txt。应该收到404.5 - HTTP verb rejected错误。尝试访问一个不存在的危险扩展名http://yoursite.com/web.config。应该被拒绝。检查日志查看%windir%\system32\inetsrv\urlscan\logs\目录下的日志文件以日期命名里面会记录被拦截的请求详情包括原因、客户端IP等这对于安全分析和规则调优至关重要。6. 高级配置与疑难问题排查6.1 针对特定场景的规则调优场景网站使用Web APIASP.NET Web API, RESTful API问题API可能需要使用PUT,DELETE,PATCH等方法。解决不能简单地在[DenyVerbs]中删除这些方法这样会降低安全性。更好的做法是将API部署在一个独立的应用程序或虚拟目录下例如/api/。为该/api/应用单独设置一个web.config并在其中使用remove filter /移除URLScan筛选器或者为该路径配置更宽松的URLScan规则需要更复杂的配置。更常见的做法是在API层如ASP.NET Core Middleware或Spring Security实现方法级别的认证和授权而在IIS层只放行必要方法。场景前端报告CORS错误问题浏览器控制台报错 “has been blocked by CORS policy”。排查首先确认是预检请求被拦截。预检请求使用OPTIONS方法。检查URLScan的[DenyVerbs]是否包含了OPTIONS。如果包含将其移除或移到[AllowVerbs]。CORS响应头如Access-Control-Allow-Origin需要在后端应用代码或IIS的HTTP响应头模块中设置URLScan不负责添加这些头。场景网站部分功能如下载、上传异常问题上传文件功能失效或某些特定URL的请求被拦截。排查检查扩展名上传的文件扩展名是否在[DenyExtensions]列表中例如如果允许上传.txt文件要确保.txt不在拒绝列表里。检查URL序列上传的URL可能包含或?等字符。查看[DenyUrlSequences]是否过于严格。通常这些字符在查询字符串中是允许的URLScan会智能区分。但如果你的URL路径部分包含这些字符不常见就可能被拦截。查看日志这是最直接的方法。找到被拦截的请求日志查看Rejection Reason字段它会明确告诉你是因为Verb、Extension还是Sequence被拒绝。6.2 URLScan常见问题与解决方案速查表问题现象可能原因解决方案网站所有页面返回404.7 - URL Scan[DenyUrlSequences]规则过于严格拦截了正常路径字符如/被误加或UseAllowExtensions1但[AllowExtensions]列表为空/不全。1. 检查urlscan.ini的[DenyUrlSequences]部分移除对正常字符如/的限制默认不应有。2. 如果UseAllowExtensions1确保[AllowExtensions]列出了网站需要的所有扩展名如.html,.aspx,.php,/等。建议新手先将UseAllowExtensions改回0。网站静态资源CSS, JS, 图片无法加载静态资源的文件扩展名如.css,.js,.png被列入了[DenyExtensions]或者UseAllowExtensions1时未在[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-2183SSL/TLS、CVE-2010-2730FastCGI这类IIS相关漏洞。这是最根本的。最小化权限原则为IIS应用池配置独立的、低权限的账户运行。确保网站目录的NTFS权限严格仅授予该账户必要的读/写权限。配置请求筛选与限制除了URLScanIIS自带的“请求筛选”模块Request Filtering也非常强大可以设置URL长度、查询字符串长度、文件上传大小等限制应与URLScan配合使用。启用动态IP限制防止暴力破解可以配置同一IP在短时间内最大请求数。使用Web应用防火墙对于高安全要求的场景应考虑部署专业的WAF如ModSecurity for IIS它提供比URLScan更强大、更灵活的规则引擎。完成上述所有步骤后你的IIS服务器在信息泄露和基础Web攻击防护方面已经有了显著的提升。记住安全是一个持续的过程定期审查URLScan日志、关注IIS和Windows的安全公告、并根据应用的变化调整安全配置才是长治久安之道。这套组合拳打下来无论是应对日常扫描还是满足等保测评中对中间件安全配置的检查项都能让你心里更有底。