利用IIS请求筛选构建轻量级WAF：从原理到实战部署

1. 项目概述为什么IIS请求筛选规则是构建轻量级WAF的基石如果你负责运维一个或多个基于Windows Server和IIS的Web应用那么“安全”这个词一定是你每天都要面对的课题。从简单的SQL注入、跨站脚本XSS攻击到复杂的路径遍历、恶意文件上传攻击手段层出不穷。很多团队的第一反应是采购商业Web应用防火墙WAF这当然有效但成本高昂且规则配置往往不够灵活难以贴合自身业务逻辑。实际上对于许多中小型项目或对安全有定制化需求的场景我们完全可以从手边的工具开始构建第一道精准的防线——那就是深入挖掘IIS自带的“请求筛选”功能。很多人对IIS请求筛选的印象可能还停留在“禁止某些文件扩展名”或“限制URL长度”这种基础层面。这实在是小看了它。经过合理的规则编排与组合请求筛选模块可以化身为一个功能强大、逻辑清晰的轻量级WAF核心引擎。它工作在IIS请求处理管道的早期阶段能对HTTP请求的URL、查询字符串、头部、正文等各个部分进行基于字符串模式、正则表达式、长度、HTTP谓词等多维度的检查与拦截。其优势在于零额外成本、深度集成、性能损耗极低、规则可编程化。你可以针对自己应用的特定漏洞、已知的攻击载荷特征编写高度定制化的防御规则实现“精准打击”而不是依赖通用WAF的“模糊拦截”。最近在社区里我看到不少朋友在讨论Windows 11或新版本Windows Server上安装IIS时遇到的各种报错比如“组件存储损坏”、“功能添加错误”等。这恰恰说明了即便是在部署基础环境这一步也需要清晰的认知和正确的操作。一个稳固的WAF体系必须构建在一个健康、完整的IIS基础之上。因此本文不仅会带你从零开始利用请求筛选规则构建一套可管理、可扩展的防御体系还会穿插解决那些在IIS安装、配置、日志分析中常见的“坑”确保你的防御工事从一开始就建立在坚实的地基上。2. 核心思路将请求筛选模块系统化、策略化在动手写第一条规则之前我们必须先建立一个系统性的认知。IIS的请求筛选功能本身是分散的——你可以为每个站点、每个目录甚至每个文件单独配置。但如果作为WAF来使用这种分散的管理方式会迅速演变成一场灾难规则难以统一更新配置容易遗漏排查问题如同大海捞针。因此我们的核心思路是集中化管理分层式防御策略化部署。2.1 集中化管理告别“散兵游勇”IIS允许通过applicationHost.config文件进行服务器级别的配置。我们将把核心的、通用的WAF规则定义在这里。这意味着任何部署在这台服务器上的站点默认都会继承这些安全规则实现了“一次配置全局生效”。对于需要特殊处理的站点例如某个API站点需要允许更大的请求体我们再在站点级的web.config中进行例外配置或规则覆盖。这种模式确保了安全基线的统一性。2.2 分层式防御构建纵深防线一个有效的WAF不应该只有一层薄薄的过滤网。我们将防御分为几个层次协议与格式层过滤明显不符合HTTP协议规范或可能引发服务器处理异常的请求例如畸形的URL编码、过长的请求行、非常规的HTTP方法。通用攻击特征层拦截跨所有Web应用的通用攻击模式如经典的SQL注入关键词union select,sleep(、XSS载荷script,javascript:、路径遍历序列../。应用逻辑层针对特定业务逻辑的防御。例如你的用户ID参数只可能是数字那么可以定义规则只允许数字字符你的上传接口只允许image/jpeg类型则可以严格过滤Content-Type。2.3 策略化部署兼顾安全与灵活规则不是一成不变的。我们将规则分组形成不同的“策略”。例如基础防护策略包含协议层和通用攻击特征层规则适用于所有生产环境站点。严格防护策略在基础之上增加更严格的正则表达式匹配和更低的阈值适用于核心业务或曾遭受过攻击的站点。审计策略不直接拦截请求而是将匹配的请求详情记录到日志中用于安全分析和规则调优适用于测试环境或灰度上线新规则。通过这样的设计请求筛选就从IIS的一个孤立功能升级为一个有架构、可运营的轻量级WAF系统。3. 环境准备与IIS健康检查在部署任何安全规则之前确保IIS本身是健康、完整安装的至关重要。很多后续的诡异问题其根源都在于安装阶段。3.1 规避安装陷阱解决“组件存储损坏”等问题在Windows 11或Windows Server 2022/2019上使用“启用或关闭Windows功能”图形界面安装IIS时有时会遇到“组件存储损坏”或安装失败的错误。这通常是因为Windows Update的缓存文件出现问题。可靠的操作流程如下以管理员身份运行PowerShell或CMD。这是所有后续操作的前提。使用DISM工具修复系统映像。这是解决“组件存储损坏”的核心命令。DISM /Online /Cleanup-Image /RestoreHealth这个命令会连接Windows Update服务器或你指定的源下载并替换损坏的系统文件。执行时间可能较长需耐心等待完成。使用SFC工具扫描系统文件。sfc /scannow在DISM修复后运行检查并修复受保护的系统文件。使用PowerShell命令安装IIS。强烈推荐使用命令行而非图形界面因为它更清晰、可脚本化、且易于排错。# 安装包含常用功能静态内容、默认文档、目录浏览、HTTP错误、ASP.NET等的IIS Enable-WindowsOptionalFeature -Online -FeatureName IIS-WebServerRole, IIS-WebServer, IIS-CommonHttpFeatures, IIS-DefaultDocument, IIS-DirectoryBrowsing, IIS-HttpErrors, IIS-StaticContent, IIS-HealthAndDiagnostics, IIS-HttpLogging, IIS-Performance, IIS-Security, IIS-RequestFiltering, IIS-HttpCompressionStatic, IIS-WebServerManagementTools -All关键点注意命令中包含了IIS-RequestFiltering这就是我们本文的核心功能模块必须确保它被安装。验证安装。安装完成后打开浏览器访问http://localhost应该能看到IIS的默认欢迎页面。同时在IIS管理器中选中服务器节点右侧应出现“请求筛选”图标。注意如果公司网络环境限制访问Windows UpdateDISM命令可能会失败。此时需要事先下载对应的Windows版本ISO文件将其挂载例如到D:盘然后使用/Source参数指定源路径DISM /Online /Cleanup-Image /RestoreHealth /Source:D:\sources\install.wim:1 /LimitAccess。具体索引号:1可以通过DISM /Get-ImageInfo /ImageFile:D:\sources\install.wim查看。3.2 配置请求筛选的“作战室”日志与分析一个WAF如果只有拦截功能而没有日志那就是一个“瞎子”。你不知道它挡住了什么更不知道攻击者正在尝试什么。IIS的请求筛选模块的拦截日志默认是不单独记录的它会被合并到站点的访问日志中。我们需要做两件事来激活日志分析能力确保站点日志开启并配置合理字段。在IIS管理器中选中你的站点双击“日志”。建议使用“W3C”扩展日志格式并在“选择字段”中确保勾选以下关键字段cs-uri-query(请求查询字符串)cs(User-Agent)(用户代理)cs(Referer)(来源)sc-status(状态码)sc-substatus(子状态码)-- 这个非常重要sc-win32-status(Win32状态码)IIS请求筛选模块在拒绝请求时通常会返回404 Not Found、400 Bad Request或403 Forbidden并在sc-substatus中填入更具体的理由代码。例如404.7表示“文件扩展名被拒绝”403.18表示“URL被拒绝”。这些子状态码是我们事后分析拦截原因的关键。配置失败请求跟踪可选但推荐。对于复杂问题仅靠日志可能不够。可以在IIS中为站点启用“失败请求跟踪”。当请求因筛选规则被拒且状态码符合你设定的条件如400-999时IIS会生成一个详细的XML跟踪日志里面包含了请求在管道中每一步的处理情况能清晰看到是哪个筛选规则、在哪个阶段拦截了请求。这是调试复杂规则的终极利器。4. 构建核心防御规则集现在我们进入实战环节开始编写规则。我们将通过修改applicationHost.config文件位于C:\Windows\System32\inetsrv\config\来添加服务器级规则。修改前请务必备份。4.1 第一层协议与格式合规性过滤这一层的目标是拦截“畸形”请求防止它们冲击应用层甚至消耗服务器资源。system.webServer security requestFiltering !-- 限制请求URL最大长度字节防缓冲区溢出攻击 -- requestLimits maxUrl4096 maxQueryString2048 / !-- 限制请求正文最大长度字节防大数据包攻击 -- requestLimits maxAllowedContentLength30000000 / !-- 约30MB -- !-- 限制HTTP请求头总长度 -- requestLimits maxRequestBytes16384 headerLimits add headerContent-type sizeLimit100 / add headerUser-Agent sizeLimit512 / /headerLimits !-- 只允许常见的HTTP方法 -- verbs allowUnlistedfalse add verbGET allowedtrue / add verbPOST allowedtrue / add verbPUT allowedtrue / add verbDELETE allowedtrue / add verbHEAD allowedtrue / add verbOPTIONS allowedtrue / /verbs !-- 隐藏技术栈信息禁止访问特定扩展名的文件 -- fileExtensions allowUnlistedtrue add fileExtension.config allowedfalse / add fileExtension.cs allowedfalse / add fileExtension.vb allowedfalse / add fileExtension.asax allowedfalse / add fileExtension.csproj allowedfalse / /fileExtensions /requestFiltering /security /system.webServer实操心得maxAllowedContentLength的单位是字节需要根据业务实际情况调整。对于纯API站点可以设小对于文件上传站点则要设大。verbs设置allowUnlistedfalse是一种“白名单”思维更安全。但务必确认你的应用包括前端框架、第三方库不会使用TRACE、CONNECT等非常规方法。禁止.config等文件扩展名是基础中的基础能防止源代码或配置文件泄露。4.2 第二层通用攻击特征识别与拦截这是WAF的核心我们使用filteringRules和denyStrings来定义黑名单。system.webServer security requestFiltering filteringRules !-- 规则组1SQL注入防御 -- filteringRule nameBlockCommonSQLi scanUrltrue scanQueryStringtrue scanHeaders add requestHeaderContent-Type / /scanHeaders appliesTo add fileExtension.aspx / add fileExtension.ashx / add fileExtension.asmx / add fileExtension.php / !-- 如果你的IIS也跑PHP -- add fileExtension.jsp / /appliesTo denyStrings !-- 使用转义字符注意XML格式 -- add stringunion%20select / add stringselect%20*%20from / add stringinsert%20into / add stringdrop%20table / add stringsleep( / add stringwaitfor%20delay / add stringexec%20( / add stringxp_cmdshell / !-- 单引号、双引号、分号的异常组合 -- add string%27%20or%20%27 / !-- or -- add string%22%20or%20%22 / !-- or -- /denyStrings denyUrlSequences add sequence-- / !-- SQL注释 -- add sequence/* / /* SQL注释 */ /denyUrlSequences /filteringRule !-- 规则组2XSS与脚本攻击防御 -- filteringRule nameBlockXSS scanUrltrue scanQueryStringtrue scanAllRawtrue appliesTo add fileExtension.aspx / add fileExtension.html / add fileExtension.htm / /appliesTo denyStrings add stringlt;script / add stringjavascript: / add stringonload / add stringonerror / add stringonclick / add stringalert( / add stringeval( / add stringdocument.cookie / /denyStrings /filteringRule !-- 规则组3路径遍历与目录攻击 -- filteringRule nameBlockPathTraversal scanUrltrue denyUrlSequences add sequence.. / add sequence\.\ / add sequence%2e%2e / !-- URL编码的 .. -- add sequence%252e%252e / !-- 双重URL编码的 .. -- /denyUrlSequences /filteringRule /filteringRules /requestFiltering /security /system.webServer关键点解析与避坑指南scanAllRawtrue这个属性非常强大它会让IIS在匹配规则前先对URL进行解码包括双重解码。这对于防御使用URL编码绕过的攻击至关重要。强烈建议在XSS和SQLi规则上启用。但要注意它可能增加性能开销且需要更谨慎地设计规则字符串避免误杀正常编码的参数。appliesTo用于指定该规则仅对哪些文件扩展名生效。这能有效减少误报。例如SQLi规则只应用于动态脚本页面.aspx,.php而不应用于静态图片.jpg。字符串的转义在XML中、、等字符需要转义。我们写的是lt;scriptIIS实际匹配的是script。务必注意这一点否则规则会无效。规则的顺序与性能IIS会按规则定义的顺序进行匹配。应将匹配概率高、计算简单的规则如路径遍历..放在前面将复杂、耗时的正则表达式规则放在后面。4.3 第三层高级正则表达式匹配对于更复杂的模式denyStrings的简单字符串匹配就不够了。我们需要使用rule元素它支持patternSyntax设置为“ECMAScript”即JavaScript风格的正则表达式。system.webServer security requestFiltering rules !-- 规则1防御特定格式的命令注入例如|, , -- rule nameBlockCmdInjectionPattern patternSyntaxECMAScript stopProcessingtrue match url.* / conditions add input{QUERY_STRING} pattern(\|\||\\|\|\$\(|\n\r) / /conditions action typeCustomResponse statusCode403 statusReasonForbidden: Potentially Malicious Input statusDescriptionRequest blocked by security policy. / /rule !-- 规则2严格限制ID参数格式只允许数字 -- rule nameStrictNumericId patternSyntaxECMAScript match url.* / conditions add input{QUERY_STRING} pattern(^|)id[^0-9] / /conditions action typeCustomResponse statusCode400 statusReasonBad Request: Invalid parameter format / /rule !-- 规则3检测异常的User-Agent如扫描器、自动化工具常见UA -- rule nameBlockSuspiciousUA patternSyntaxECMAScript match url.* / conditions add input{HTTP_USER_AGENT} pattern(nikto|sqlmap|wget|curl|dirbuster|nessus|acunetix|netsparker) ignoreCasetrue / /conditions action typeCustomResponse statusCode403 statusReasonForbidden / /rule /rules /requestFiltering /security /system.webServer经验之谈stopProcessingtrue表示一旦此规则匹配就跳过后续所有规则。对于高置信度的恶意请求拦截规则可以使用以提升效率。CustomResponse可以自定义返回的状态码和原因短语。返回404可以隐藏安全规则的存在返回403或400则更明确。根据你的安全策略选择。正则表达式性能过于复杂的正则表达式会成为性能瓶颈。尽量使用精确匹配和字符集[a-zA-Z0-9]避免贪婪匹配.*和复杂的回溯。输入变量{QUERY_STRING}、{HTTP_USER_AGENT}、{REQUEST_URI}等都是可用的服务器变量。{REQUEST_BODY}在某些条件下也可用但处理POST数据需要额外配置且性能影响较大需慎用。5. 规则的管理、测试与调优规则上线不是终点而是运营的开始。一套无法维护、无法验证的规则是危险的。5.1 规则的管理版本化与注释永远不要直接在生产服务器的applicationHost.config上盲目修改。你应该使用版本控制系统如Git。将配置文件的更改作为代码进行管理每次修改都有记录可以回滚。在配置文件中添加详细注释。XML支持!-- 注释 --。为每个规则组、每条复杂规则写明其目的、添加日期、负责人以及已知的例外情况。!-- 规则组BlockCommonSQLi 创建日期2023-10-27 负责人安全团队 目的拦截常见的SQL注入攻击模式。 适用范围所有动态页面(.aspx, .ashx, .php等) 注意规则字符串已进行URL编码。scanAllRawtrue启用双重解码检查。 已知例外无 --分环境部署先在测试或预发布环境的IIS上应用新规则观察日志进行充分的业务测试确认无误后再同步到生产环境。5.2 规则的测试模拟攻击与验证部署规则后必须进行测试。使用工具可以利用curl、Postman 或简单的浏览器地址栏来模拟攻击。测试SQLi访问http://yoursite/test.aspx?id1%20or%2011测试XSS访问http://yoursite/page.html?msgscriptalert(1)/script测试路径遍历访问http://yoursite/images/../../web.config查看结果预期应该收到403/400等拦截状态码。同时立即去查看IIS日志确认sc-substatus字段记录了拦截详情并且请求确实被你的规则命中可以通过在规则的自定义响应中添加特定标识符来辅助判断。业务回归测试用正常的业务流程用户登录、搜索、下单等全面测试一遍确保没有“误杀”正常请求。这是最重要的环节。5.3 规则的调优分析日志与处理误报/漏报WAF规则运营的核心是持续调优。分析拦截日志定期如每天分析IIS日志筛选出sc-status为403、404且sc-substatus为特定值的请求。分析这些被拦截的请求误报False Positive正常用户请求被拦截。例如一篇技术文章里包含了select * from这个字符串被当作SQLi拦截了。你需要调整规则或者将该URL路径/articles/加入规则的白名单使用appliesTo的逆向逻辑或在站点级web.config中使用clear/和remove/移除特定规则。漏报False Negative攻击请求没有被拦截。你需要分析攻击载荷的特征补充新的规则字符串或优化正则表达式。处理误报IIS请求筛选允许在更细的粒度上做排除。你可以在站点或目录的web.config中使用clear/移除继承的服务器级规则然后只添加你需要的或者使用remove segmentdefault document /这样的方式移除特定默认文档的筛选。更精细的控制需要结合URL重写模块来实现条件豁免。迭代更新安全是动态的。新的攻击手法如新型的绕过编码和新的业务接口如新的上传格式都可能需要更新规则集。建立一个简单的流程监控日志 - 分析异常 - 评估风险 - 更新测试规则 - 预发布验证 - 生产部署。6. 高级应用与集成考量将基础的请求筛选用熟后可以探索一些更高级的用法让它更好地融入你的DevSecOps流程。6.1 与URL重写模块联动实现复杂逻辑IIS的URL重写模块功能极其强大它可以访问服务器变量、使用条件判断并能执行重定向、自定义响应等操作。我们可以将请求筛选作为第一道粗筛再用URL重写实现更精细的逻辑。例如你想实现只有当请求来自非公司内网IP且User-Agent为空或异常时才触发严格的SQL注入检测规则。单纯用请求筛选很难实现这种“与”逻辑。但可以配合URL重写请求筛选规则放松只检测最明显的攻击。在URL重写规则中设置条件rule nameStrictCheckForExternalAndSuspicious stopProcessingtrue match url.* / conditions logicalGroupingMatchAll add input{REMOTE_ADDR} pattern^192\.168\.1\.\d$ negatetrue / !-- 非内网IP -- add input{HTTP_USER_AGENT} pattern^$|(scanner|bot) ignoreCasetrue / !-- UA为空或包含扫描器关键词 -- /conditions action typeRewrite url/SecurityCheck.aspx?originalUrl{URL} / !-- 重写到专门的安全检查页面 -- /rule然后在这个SecurityCheck.aspx页面中进行更深入、更耗时的请求内容分析比如完整的POST体解析、语义分析如果发现恶意请求再记录日志并阻断。6.2 编码问题与中文处理这是一个非常实际的坑。IIS请求筛选在处理包含中文字符的URL时如果规则字符串编写不当很容易因为编码问题导致规则失效或误报。核心原则规则中尽量使用URL编码后的字符串进行匹配。错误示例你想拦截“测试”这个词直接在denyStrings里写add string测试 /。这很可能无效因为用户请求中的“测试”可能是UTF-8编码的%E6%B5%8B%E8%AF%95而IIS内部匹配的编码方式可能不一致。正确做法使用scanAllRawtrue。这是首选它让IIS帮你处理解码。如果不能用scanAllRaw则在规则中直接写入URL编码后的字符串。你需要知道你的应用默认的编码通常是UTF-8。可以使用在线工具将“测试”转换为%E6%B5%8B%E8%AF%95然后写add string%E6%B5%8B%E8%AF%95 /。对于正则表达式规则可以使用Unicode字符集例如[\u4e00-\u9fa5]来匹配任意中文字符但这通常用于“允许”而非“拒绝”的场景如只允许中文、数字、字母。实测建议在添加涉及非ASCII字符的规则后务必用编码后的URL进行测试并检查日志确认规则按预期工作。6.3 性能监控与影响评估虽然IIS请求筛选是原生模块性能极高但不当的规则仍可能带来开销。避免过多正则表达式尤其是包含贪婪量词.*或复杂回溯的正则在高压下可能成为瓶颈。限制规则作用范围充分利用appliesTo让规则只作用于必要的文件类型。监控性能计数器在Windows性能监视器中添加Web Service下的Total Rejected Requests和Current Requests等计数器观察拦截请求的速率和总体请求量的关系。如果拦截率异常高可能是遭遇CC攻击或者规则误报严重。压力测试在规则上线前使用工具如Apache JMeter, VS Load Test对关键业务接口进行压力测试对比开启规则前后的响应时间TP95, TP99和吞吐量确保在可接受的性能损耗范围内。7. 从“功能”到“体系”构建你的WAF管理台对于拥有大量服务器的团队手动维护每台服务器的applicationHost.config是不现实的。我们可以将这套方法体系化、自动化。规则模板化将上述分层的规则集协议层、通用攻击层、正则层保存为标准的XML模板片段。配置即代码使用PowerShell Desired State Configuration (DSC)、Ansible、Chef或简单的PowerShell脚本将规则模板推送到目标服务器并修改applicationHost.config。这确保了配置的一致性。集中日志收集与分析使用ELK StackElasticsearch, Logstash, Kibana或SIEM安全信息和事件管理系统将所有IIS服务器的日志集中收集。在Kibana中你可以轻松地创建仪表盘可视化展示被拦截请求的Top来源IP。被触发最多的规则排名。随时间变化的攻击趋势图。自动化响应当日志分析系统发现某个IP在短时间内触发了大量不同的安全规则攻击试探可以自动调用脚本通过防火墙或主机防火墙临时封禁该IP。走到这一步你已经不仅仅是在使用IIS的一个功能而是在运营一个基于原生组件构建的、可编程、可观测、可自动化的轻量级Web应用防火墙体系。它成本低廉却能与你的基础设施和业务逻辑深度集成提供不亚于商业WAF的精准防御能力。安全是一个持续的过程而你现在拥有了一个强大且可控的起点。