IIS请求过滤本质上是一个运行在Web服务器核心层的防火墙模块，它能在HTTP请求到达你的ASP.NET、PHP等应用程序之前，就根据你设定的规则对请求进行阻断。这意味着，你不需要修改一行业务代码，就能在IIS层面直接拦截掉大量具有明显攻击特征的恶意流量。比如，当攻击者尝试利用某个已知的CMS漏洞，在URL中附加恶意的Java反序列化字符串时，请求过滤就能通过检查URL中的特定字符组合，直接返回404或拒绝连接，从而将攻击拒之门外。
理解请求过滤的核心模块与工作流
要驾驭请求过滤，必须先理解它的两个核心组件：请求筛选模块和请求限制运行时。请求筛选模块是一个内核模式或用户模式的过滤器，它检查HTTP请求的各个部分，包括URL、查询字符串、HTTP头以及请求体。请求限制运行时则负责执行具体的拒绝操作，并记录日志。它的检查顺序通常是：先检查HTTP动词，然后是URL长度、查询字符串长度，接着是URL中的特定字符序列，最后才是HTTP头和实体主体。理解这个顺序很重要，因为一旦请求在前一个检查点被拒绝，后续的检查就不会再进行。这可以让你有针对性地设计规则，将最可能被攻击且性能消耗最小的检查放在逻辑上的最前端。
精准防御SQL注入攻击的规则配置
SQL注入是最古老的Web攻击方式之一，至今仍活跃在各种扫描器中。IIS请求过滤可以通过过滤URL和查询字符串中的SQL关键字和特殊字符来提供第一道防线。你可以在IIS管理器的“请求筛选”功能中，进入“规则”选项卡，添加拒绝规则。例如，针对查询字符串，你可以设置拒绝包含“xp_cmdshell”的请求，因为这是SQL Server中一个极其危险且常被利用的存储过程。更精细的配置是使用“拒绝字符串”和“拒绝URL序列”。你可以设置拒绝字符串“;--”，这是SQL注入中常用的注释符，用于截断原始SQL语句。同时，对于URL序列，可以拒绝包含“union(*select”的模式，因为“union select”是联合查询注入的典型特征。需要注意的是，这些规则可能会对正常的业务输入造成误伤，比如一个论坛帖子中用户可能真的需要讨论“union select”的用法。因此，最佳实践是结合“始终允许”的URL或参数，为特定安全的后台管理路径或已知的富文本输入字段设置例外。
阻断跨站脚本攻击的请求特征过滤
XSS攻击的核心是在返回给浏览器的页面中注入恶意脚本。IIS请求过滤可以在请求阶段就识别并阻断包含这些脚本特征的输入。在“请求筛选”的“规则”中，你可以添加针对查询字符串和请求体的过滤规则。常见的做法是拒绝包含“javascript:”伪协议的请求，以及包含基础脚本标签“<script”的输入。更进一步，你可以设置更复杂的模式，例如拒绝包含事件处理器属性“onerror=”、“onload=”的请求，这些都是无脚本XSS攻击中常用的触发器。为了防御编码绕过的尝试，你还可以考虑过滤“%3C”和“%3E”，它们分别是“<”和“>”的URL编码形式。但直接过滤编码字符极易产生误报，一个更稳健的策略是，IIS请求过滤会默认对URL进行解码后再匹配规则，因此你只需配置针对解码后明文字符的规则即可。同样，为你的富文本编辑器上传接口或后台内容管理页面设置“始终允许”的例外至关重要，否则正常的内容提交也会被拦截。
防御恶意文件上传与路径遍历的规则设计
攻击者经常试图上传WebShell或利用路径遍历漏洞访问服务器上的敏感文件。请求过滤可以通过文件名扩展和路径检查来防御这些攻击。在“请求筛选”中，你可以直接编辑“文件扩展名拒绝”列表，默认情况下IIS已经拒绝了许多危险扩展名，如“.asp”、“.aspx”、“.php”等，但这通常用于防止在非脚本执行目录中意外执行脚本。对于上传目录，你应该明确拒绝“.exe”、“.bat”、“.dll”等可执行文件扩展名，即使它们不能被IIS直接解析，也可能被用于其他攻击链。对于路径遍历，攻击者常使用“../”或“..\”序列来跳出Web根目录。你可以在“隐藏段”中配置拒绝的URL片段，添加一个隐藏段，其“段”值为“..”，这样任何包含“..”的URL都会被拒绝。但这会完全禁止URL中使用“..”，可能影响某些使用相对路径的应用。更精细的做法是使用“拒绝URL序列”，添加“../”和“..\”作为拒绝序列，这样只针对路径遍历模式进行拦截。
利用请求限制进行速率控制与DoS防护
除了特征过滤，请求过滤模块还提供了强大的请求限制功能，用于防御应用层DDoS攻击和暴力破解。你可以对URL、查询字符串和HTTP头的长度进行严格限制。例如，将“最大URL长度”设置为2048字节，“最大查询字符串长度”设置为1024字节，这能有效拦截那些试图通过超长URL或参数发起缓冲区溢出或消耗服务器资源的攻击。更重要的是“限制动词”和“限制标头”的功能。你可以将PUT、DELETE、TRACE等不常用且具有潜在风险的HTTP方法直接拒绝。对于HTTP头，你可以设置“最大允许内容长度”，这是防御大流量POST请求上传的关键参数，根据你的业务需求，将其设置为一个合理的值，比如30MB，可以有效防止攻击者通过上传超大文件耗尽服务器磁盘或内存资源。这些限制不是基于内容特征的，而是基于请求的物理属性，因此误报率极低，是性价比最高的防御措施之一。
进阶实战：编写自定义过滤规则脚本
当图形化界面的配置无法满足复杂的逻辑判断时，你可以通过编辑IIS的XML配置文件或使用PowerShell、AppCmd.exe命令行工具来实现更动态、更精细的规则管理。以下是一个使用PowerShell批量添加拒绝查询字符串规则的脚本示例，它可以快速为服务器群集部署统一的防御策略：
# 导入IIS管理模块
Import-Module WebAdministration
# 定义要拒绝的SQL注入和XSS模式列表
$denyPatterns = @(
'xp_cmdshell',
'union(*select',
'1=1--',
'<script',
'javascript:',
'onerror=',
'../',
'..\'
)
# 遍历所有站点
Get-ChildItem IIS:\Sites | ForEach-Object {
$siteName = $_.Name
Write-Host "正在为站点 '$siteName' 配置请求过滤规则..."
# 获取站点的请求筛选配置路径
$filterPath = "IIS:\Sites\$siteName"
# 为每个模式添加拒绝查询字符串规则
foreach ($pattern in $denyPatterns) {
# 检查规则是否已存在，避免重复添加
$existingRule = Get-WebConfigurationProperty -Filter "system.webServer/security/requestFiltering/denyQueryStringSequences" -Name "." -PSPath $filterPath | Where-Object { $_.sequence -eq $pattern }
if (-not $existingRule) {
Add-WebConfigurationProperty -Filter "system.webServer/security/requestFiltering/denyQueryStringSequences" -Name "." -Value @{sequence=$pattern} -PSPath $filterPath
Write-Host " 已添加拒绝序列: $pattern"
} else {
Write-Host " 规则已存在，跳过: $pattern"
}
}
}
Write-Host "所有站点请求过滤规则配置完成。"这个脚本展示了如何通过编程方式批量管理规则，这对于维护大量站点或需要快速响应新型攻击模式（如Log4j漏洞利用中的“${jndi:ldap://”模式）时非常高效。你只需将新的攻击特征字符串添加到"$denyPatterns"数组中，重新运行脚本即可完成全站策略更新。
日志监控与规则调优的闭环管理
部署规则只是开始，持续监控和调优才是安全运维的核心。当IIS请求过滤拦截请求时，它会将事件记录到IIS日志中，状态码通常是“404.19”或“404.18”等以404为前缀的子状态码。你需要配置一个集中式日志分析系统，定期检索这些特定的子状态码。分析日志时，重点关注被拦截最多的规则和URL。如果某个规则产生了大量误报，例如，一个正常的业务API因参数中包含“select”而被“拒绝查询字符串”规则拦截，你就需要为该特定URL或参数设置“始终允许”例外，而不是简单地删除整个规则。反之，如果你在日志中发现了新的攻击模式，比如针对一个新爆出漏洞的扫描特征，你就应该立即创建新的过滤规则并部署。这种“监控-分析-调优-新增”的闭环，能让你的请求过滤规则库成为一个不断进化的、贴合业务实际的动态防御体系。
深入理解请求过滤的局限性与纵深防御
IIS请求过滤是一个强大的基于特征和协议规范的防御层，但它并非万能药。它难以防御零日漏洞中那些完全符合HTTP规范且无已知恶意特征的请求。例如，一个精心构造的、针对业务逻辑漏洞的JSON请求，其所有参数名和值都是合法的，请求过滤对此无能为力。因此，你必须建立纵深防御体系：请求过滤作为最外层的大门，负责过滤掉大部分已知的、嘈杂的攻击流量；在其之后，你的Web应用程序自身必须具备严格的输入验证和参数化查询；最后，定期进行渗透测试和代码审计，发现并修复业务逻辑漏洞。将请求过滤视为整体安全策略中的一个高效环节，而不是全部，这才是成熟运维人员的正确心态。
