企业官网建设流程全解析

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不应该只有一层薄薄的过滤网。我们将防御分为几个层次：

1. 协议与格式层：过滤明显不符合HTTP协议规范或可能引发服务器处理异常的请求，例如畸形的URL编码、过长的请求行、非常规的HTTP方法。
2. 通用攻击特征层：拦截跨所有Web应用的通用攻击模式，如经典的SQL注入关键词（union select,sleep(）、XSS载荷（<script>,javascript:）、路径遍历序列（../）。
3. 应用逻辑层：针对特定业务逻辑的防御。例如，你的用户ID参数只可能是数字，那么可以定义规则只允许数字字符；你的上传接口只允许image/jpeg类型，则可以严格过滤Content-Type。

2.3 策略化部署：兼顾安全与灵活

规则不是一成不变的。我们将规则分组，形成不同的“策略”。例如：

• 基础防护策略：包含协议层和通用攻击特征层规则，适用于所有生产环境站点。
• 严格防护策略：在基础之上，增加更严格的正则表达式匹配和更低的阈值，适用于核心业务或曾遭受过攻击的站点。
• 审计策略：不直接拦截请求，而是将匹配的请求详情记录到日志中，用于安全分析和规则调优，适用于测试环境或灰度上线新规则。

通过这样的设计，请求筛选就从IIS的一个孤立功能，升级为一个有架构、可运营的轻量级WAF系统。

3. 环境准备与IIS健康检查

在部署任何安全规则之前，确保IIS本身是健康、完整安装的至关重要。很多后续的诡异问题，其根源都在于安装阶段。

3.1 规避安装陷阱：解决“组件存储损坏”等问题

在Windows 11或Windows Server 2022/2019上，使用“启用或关闭Windows功能”图形界面安装IIS时，有时会遇到“组件存储损坏”或安装失败的错误。这通常是因为Windows Update的缓存文件出现问题。

可靠的操作流程如下：

1. 以管理员身份运行PowerShell或CMD。这是所有后续操作的前提。
2. 使用DISM工具修复系统映像。这是解决“组件存储损坏”的核心命令。

   DISM /Online /Cleanup-Image /RestoreHealth

   这个命令会连接Windows Update服务器（或你指定的源），下载并替换损坏的系统文件。执行时间可能较长，需耐心等待完成。
3. 使用SFC工具扫描系统文件。

   sfc /scannow

   在DISM修复后运行，检查并修复受保护的系统文件。
4. 使用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，这就是我们本文的核心功能模块，必须确保它被安装。
5. 验证安装。安装完成后，打开浏览器访问http://localhost，应该能看到IIS的默认欢迎页面。同时，在IIS管理器中，选中服务器节点，右侧应出现“请求筛选”图标。

注意：如果公司网络环境限制访问Windows Update，DISM命令可能会失败。此时需要事先下载对应的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的请求筛选模块的拦截日志，默认是不单独记录的，它会被合并到站点的访问日志中。

我们需要做两件事来激活日志分析能力：

1. 确保站点日志开启并配置合理字段。在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被拒绝”。这些子状态码是我们事后分析拦截原因的关键。

2. 配置失败请求跟踪（可选但推荐）。对于复杂问题，仅靠日志可能不够。可以在IIS中为站点启用“失败请求跟踪”。当请求因筛选规则被拒，且状态码符合你设定的条件（如400-999）时，IIS会生成一个详细的XML跟踪日志，里面包含了请求在管道中每一步的处理情况，能清晰看到是哪个筛选规则、在哪个阶段拦截了请求。这是调试复杂规则的终极利器。

4. 构建核心防御规则集

现在，我们进入实战环节，开始编写规则。我们将通过修改applicationHost.config文件（位于C:\Windows\System32\inetsrv\config\）来添加服务器级规则。修改前请务必备份。

4.1 第一层：协议与格式合规性过滤

这一层的目标是拦截“畸形”请求，防止它们冲击应用层，甚至消耗服务器资源。

<system.webServer> <security> <requestFiltering> <!-- 限制请求URL最大长度（字节），防缓冲区溢出攻击 --> <requestLimits maxUrl="4096" maxQueryString="2048" /> <!-- 限制请求正文最大长度（字节），防大数据包攻击 --> <requestLimits maxAllowedContentLength="30000000" /> <!-- 约30MB --> <!-- 限制HTTP请求头总长度 --> <requestLimits maxRequestBytes="16384" headerLimits> <add header="Content-type" sizeLimit="100" /> <add header="User-Agent" sizeLimit="512" /> </headerLimits> <!-- 只允许常见的HTTP方法 --> <verbs allowUnlisted="false"> <add verb="GET" allowed="true" /> <add verb="POST" allowed="true" /> <add verb="PUT" allowed="true" /> <add verb="DELETE" allowed="true" /> <add verb="HEAD" allowed="true" /> <add verb="OPTIONS" allowed="true" /> </verbs> <!-- 隐藏技术栈信息：禁止访问特定扩展名的文件 --> <fileExtensions allowUnlisted="true"> <add fileExtension=".config" allowed="false" /> <add fileExtension=".cs" allowed="false" /> <add fileExtension=".vb" allowed="false" /> <add fileExtension=".asax" allowed="false" /> <add fileExtension=".csproj" allowed="false" /> </fileExtensions> </requestFiltering> </security> </system.webServer>

实操心得：

• maxAllowedContentLength的单位是字节，需要根据业务实际情况调整。对于纯API站点，可以设小；对于文件上传站点，则要设大。
• verbs设置allowUnlisted="false"是一种“白名单”思维，更安全。但务必确认你的应用（包括前端框架、第三方库）不会使用TRACE、CONNECT等非常规方法。
• 禁止.config等文件扩展名是基础中的基础，能防止源代码或配置文件泄露。

4.2 第二层：通用攻击特征识别与拦截

这是WAF的核心，我们使用<filteringRules>和<denyStrings>来定义黑名单。

<system.webServer> <security> <requestFiltering> <filteringRules> <!-- 规则组1：SQL注入防御 --> <filteringRule name="BlockCommonSQLi" scanUrl="true" scanQueryString="true"> <scanHeaders> <add requestHeader="Content-Type" /> </scanHeaders> <appliesTo> <add fileExtension=".aspx" /> <add fileExtension=".ashx" /> <add fileExtension=".asmx" /> <add fileExtension=".php" /> <!-- 如果你的IIS也跑PHP --> <add fileExtension=".jsp" /> </appliesTo> <denyStrings> <!-- 使用转义字符，注意XML格式 --> <add string="union%20select" /> <add string="select%20*%20from" /> <add string="insert%20into" /> <add string="drop%20table" /> <add string="sleep(" /> <add string="waitfor%20delay" /> <add string="exec%20(" /> <add string="xp_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> <!-- 规则组2：XSS与脚本攻击防御 --> <filteringRule name="BlockXSS" scanUrl="true" scanQueryString="true" scanAllRaw="true"> <appliesTo> <add fileExtension=".aspx" /> <add fileExtension=".html" /> <add fileExtension=".htm" /> </appliesTo> <denyStrings> <add string="&lt;script" /> <add string="javascript:" /> <add string="onload=" /> <add string="onerror=" /> <add string="onclick=" /> <add string="alert(" /> <add string="eval(" /> <add string="document.cookie" /> </denyStrings> </filteringRule> <!-- 规则组3：路径遍历与目录攻击 --> <filteringRule name="BlockPathTraversal" scanUrl="true"> <denyUrlSequences> <add sequence=".." /> <add sequence="\.\" /> <add sequence="%2e%2e" /> <!-- URL编码的 .. --> <add sequence="%252e%252e" /> <!-- 双重URL编码的 .. --> </denyUrlSequences> </filteringRule> </filteringRules> </requestFiltering> </security> </system.webServer>

关键点解析与避坑指南：

• scanAllRaw="true"：这个属性非常强大，它会让IIS在匹配规则前，先对URL进行解码（包括双重解码）。这对于防御使用URL编码绕过的攻击至关重要。强烈建议在XSS和SQLi规则上启用。但要注意，它可能增加性能开销，且需要更谨慎地设计规则字符串，避免误杀正常编码的参数。
• appliesTo：用于指定该规则仅对哪些文件扩展名生效。这能有效减少误报。例如，SQLi规则只应用于动态脚本页面（.aspx,.php），而不应用于静态图片（.jpg）。
• 字符串的转义：在XML中，<、>、&等字符需要转义。我们写的是<script，IIS实际匹配的是<script。务必注意这一点，否则规则会无效。
• 规则的顺序与性能：IIS会按规则定义的顺序进行匹配。应将匹配概率高、计算简单的规则（如路径遍历..）放在前面，将复杂、耗时的正则表达式规则放在后面。

4.3 第三层：高级正则表达式匹配

对于更复杂的模式，<denyStrings>的简单字符串匹配就不够了。我们需要使用<rule>元素，它支持patternSyntax设置为“ECMAScript”（即JavaScript风格的正则表达式）。

<system.webServer> <security> <requestFiltering> <rules> <!-- 规则1：防御特定格式的命令注入（例如：|, &&, `） --> <rule name="BlockCmdInjectionPattern" patternSyntax="ECMAScript" stopProcessing="true"> <match url=".*" /> <conditions> <add input="{QUERY_STRING}" pattern="(\|\||\&\&|\`|\$\(|\n\r)" /> </conditions> <action type="CustomResponse" statusCode="403" statusReason="Forbidden: Potentially Malicious Input" statusDescription="Request blocked by security policy." /> </rule> <!-- 规则2：严格限制ID参数格式（只允许数字） --> <rule name="StrictNumericId" patternSyntax="ECMAScript"> <match url=".*" /> <conditions> <add input="{QUERY_STRING}" pattern="(^|&)id=[^0-9]+" /> </conditions> <action type="CustomResponse" statusCode="400" statusReason="Bad Request: Invalid parameter format" /> </rule> <!-- 规则3：检测异常的User-Agent（如扫描器、自动化工具常见UA） --> <rule name="BlockSuspiciousUA" patternSyntax="ECMAScript"> <match url=".*" /> <conditions> <add input="{HTTP_USER_AGENT}" pattern="(nikto|sqlmap|wget|curl|dirbuster|nessus|acunetix|netsparker)" ignoreCase="true" /> </conditions> <action type="CustomResponse" statusCode="403" statusReason="Forbidden" /> </rule> </rules> </requestFiltering> </security> </system.webServer>

经验之谈：

• stopProcessing="true"：表示一旦此规则匹配，就跳过后续所有规则。对于高置信度的恶意请求拦截规则可以使用，以提升效率。
• CustomResponse：可以自定义返回的状态码和原因短语。返回404可以隐藏安全规则的存在，返回403或400则更明确。根据你的安全策略选择。
• 正则表达式性能：过于复杂的正则表达式会成为性能瓶颈。尽量使用精确匹配和字符集（[a-zA-Z0-9]），避免贪婪匹配（.*）和复杂的回溯。
• 输入变量：{QUERY_STRING}、{HTTP_USER_AGENT}、{REQUEST_URI}等都是可用的服务器变量。{REQUEST_BODY}在某些条件下也可用，但处理POST数据需要额外配置，且性能影响较大，需慎用。

5. 规则的管理、测试与调优

规则上线不是终点，而是运营的开始。一套无法维护、无法验证的规则是危险的。

5.1 规则的管理：版本化与注释

永远不要直接在生产服务器的applicationHost.config上盲目修改。你应该：

1. 使用版本控制系统（如Git）。将配置文件的更改作为代码进行管理，每次修改都有记录，可以回滚。
2. 在配置文件中添加详细注释。XML支持<!-- 注释 -->。为每个规则组、每条复杂规则写明其目的、添加日期、负责人，以及已知的例外情况。

   <!-- 规则组：BlockCommonSQLi 创建日期：2023-10-27 负责人：安全团队 目的：拦截常见的SQL注入攻击模式。 适用范围：所有动态页面(.aspx, .ashx, .php等) 注意：规则字符串已进行URL编码。scanAllRaw=true启用双重解码检查。 已知例外：无 -->

3. 分环境部署：先在测试或预发布环境的IIS上应用新规则，观察日志，进行充分的业务测试，确认无误后再同步到生产环境。

5.2 规则的测试：模拟攻击与验证

部署规则后，必须进行测试。

• 使用工具：可以利用curl、Postman 或简单的浏览器地址栏来模拟攻击。
  • 测试SQLi：访问http://yoursite/test.aspx?id=1'%20or%20'1'='1
  • 测试XSS：访问http://yoursite/page.html?msg=<script>alert(1)</script>
  • 测试路径遍历：访问http://yoursite/images/../../web.config
• 查看结果：预期应该收到403/400等拦截状态码。同时，立即去查看IIS日志，确认sc-substatus字段记录了拦截详情，并且请求确实被你的规则命中（可以通过在规则的自定义响应中添加特定标识符来辅助判断）。
• 业务回归测试：用正常的业务流程（用户登录、搜索、下单等）全面测试一遍，确保没有“误杀”正常请求。这是最重要的环节。

5.3 规则的调优：分析日志与处理误报/漏报

WAF规则运营的核心是持续调优。

1. 分析拦截日志：定期（如每天）分析IIS日志，筛选出sc-status为403、404且sc-substatus为特定值的请求。分析这些被拦截的请求：
   • 误报（False Positive）：正常用户请求被拦截。例如，一篇技术文章里包含了select * from这个字符串，被当作SQLi拦截了。你需要调整规则，或者将该URL路径（/articles/）加入规则的白名单（使用<appliesTo>的逆向逻辑，或在站点级web.config中使用<clear/>和<remove/>移除特定规则）。
   • 漏报（False Negative）：攻击请求没有被拦截。你需要分析攻击载荷的特征，补充新的规则字符串或优化正则表达式。
2. 处理误报：IIS请求筛选允许在更细的粒度上做排除。你可以在站点或目录的web.config中，使用<clear/>移除继承的服务器级规则，然后只添加你需要的；或者使用<remove segment="default document" />这样的方式移除特定默认文档的筛选。更精细的控制需要结合URL重写模块来实现条件豁免。
3. 迭代更新：安全是动态的。新的攻击手法（如新型的绕过编码）和新的业务接口（如新的上传格式）都可能需要更新规则集。建立一个简单的流程：监控日志 -> 分析异常 -> 评估风险 -> 更新测试规则 -> 预发布验证 -> 生产部署。

6. 高级应用与集成考量

将基础的请求筛选用熟后，可以探索一些更高级的用法，让它更好地融入你的DevSecOps流程。

6.1 与URL重写模块联动实现复杂逻辑

IIS的URL重写模块功能极其强大，它可以访问服务器变量、使用条件判断，并能执行重定向、自定义响应等操作。我们可以将请求筛选作为第一道粗筛，再用URL重写实现更精细的逻辑。

例如，你想实现：只有当请求来自非公司内网IP，且User-Agent为空或异常时，才触发严格的SQL注入检测规则。

单纯用请求筛选很难实现这种“与”逻辑。但可以配合URL重写：

1. 请求筛选规则放松，只检测最明显的攻击。
2. 在URL重写规则中，设置条件：

   <rule name="StrictCheckForExternalAndSuspicious" stopProcessing="true"> <match url=".*" /> <conditions logicalGrouping="MatchAll"> <add input="{REMOTE_ADDR}" pattern="^192\.168\.1\.\d+$" negate="true" /> <!-- 非内网IP --> <add input="{HTTP_USER_AGENT}" pattern="^$|(scanner|bot)" ignoreCase="true" /> <!-- UA为空或包含扫描器关键词 --> </conditions> <action type="Rewrite" 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内部匹配的编码方式可能不一致。
• 正确做法：
  1. 使用scanAllRaw="true"。这是首选，它让IIS帮你处理解码。
  2. 如果不能用scanAllRaw，则在规则中直接写入URL编码后的字符串。你需要知道你的应用默认的编码（通常是UTF-8）。可以使用在线工具将“测试”转换为%E6%B5%8B%E8%AF%95，然后写<add string="%E6%B5%8B%E8%AF%95" />。
  3. 对于正则表达式规则，可以使用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是不现实的。我们可以将这套方法体系化、自动化。

1. 规则模板化：将上述分层的规则集（协议层、通用攻击层、正则层）保存为标准的XML模板片段。
2. 配置即代码：使用PowerShell Desired State Configuration (DSC)、Ansible、Chef或简单的PowerShell脚本，将规则模板推送到目标服务器，并修改applicationHost.config。这确保了配置的一致性。
3. 集中日志收集与分析：使用ELK Stack（Elasticsearch, Logstash, Kibana）或SIEM（安全信息和事件管理）系统，将所有IIS服务器的日志集中收集。在Kibana中，你可以轻松地创建仪表盘，可视化展示：
   • 被拦截请求的Top来源IP。
   • 被触发最多的规则排名。
   • 随时间变化的攻击趋势图。
4. 自动化响应：当日志分析系统发现某个IP在短时间内触发了大量不同的安全规则（攻击试探），可以自动调用脚本，通过防火墙或主机防火墙临时封禁该IP。

走到这一步，你已经不仅仅是在使用IIS的一个功能，而是在运营一个基于原生组件构建的、可编程、可观测、可自动化的轻量级Web应用防火墙体系。它成本低廉，却能与你的基础设施和业务逻辑深度集成，提供不亚于商业WAF的精准防御能力。安全是一个持续的过程，而你现在拥有了一个强大且可控的起点。