1. 项目概述为什么IIS请求筛选是Web安全的“第一道门”在Windows Server上跑Web应用IISInternet Information Services是绕不开的角色。很多朋友部署完网站配好SSL证书就觉得万事大吉了。但真正的挑战往往来自那些看不见的“访客”——恶意爬虫、自动化扫描器、SQL注入攻击脚本。它们不会在日志里留下“我是坏人”的签名而是伪装成正常请求试图寻找你应用的每一个缝隙。我见过太多案例一个看似正常的网站后台日志里塞满了对/phpmyadmin/、/wp-admin/、/admin/login.php的扫描请求或是充斥着‘ OR ‘1’’1这类经典的SQL注入试探。这些请求不仅消耗服务器资源更暴露了潜在的安全风险。而IIS自带的“请求筛选”功能恰恰是应对这类基础但高频攻击的利器。它不像WAFWeb应用防火墙那样复杂和昂贵而是集成在IIS管理器内部通过定义规则在HTTP请求到达你的应用代码之前就将其拦截或拒绝。简单来说你可以把它理解为你家小区的门禁系统。WAF可能是聘请的专业保安团队而请求筛选规则就是你在大门口自己设置的一套“访客黑名单”和“物品禁入清单”。比如禁止任何携带特定危险工具如某些可疑的URL参数或HTTP头的人入内或者直接拒绝来自某些已知“捣乱分子”恶意IP或User-Agent的访问。今天我就结合自己多年在Windows服务器运维中的实战经验手把手带你配置这套“门禁系统”并分享一套经过验证的、可直接套用的规则模板帮你有效屏蔽那些烦人的恶意爬虫和基础的SQL注入攻击。2. 核心思路与规则设计原理2.1 请求筛选的工作机制与拦截点在深入配置之前我们必须先搞清楚IIS请求筛选是在哪个环节生效的。这对于理解其能力和局限至关重要。IIS处理一个HTTP请求的流水线大致如下接收请求IIS从网络接口接收到原始的HTTP请求数据包。协议解析IIS解析HTTP协议提取出方法GET、POST等、URL、协议版本、头部Headers、主体Body等信息。请求筛选介入正是在协议解析之后请求被递交给具体的处理程序如ASP.NET模块、静态文件处理器之前请求筛选模块会介入。它会根据我们设定的规则对请求的各个部分进行检查。规则匹配与动作如果请求的任何部分匹配了某条“拒绝”规则IIS会立即终止该请求的处理并直接向客户端返回一个HTTP错误通常是404 - Not Found或400 - Bad Request而不会将请求传递到后端的应用程序如你的ASP.NET Core或PHP代码。如果请求通过了所有筛选才会进入后续的处理流程。这个拦截点意味着高效恶意请求在非常早的阶段就被丢弃不会消耗后端应用池Application Pool的进程资源也不会执行任何数据库查询或业务逻辑。底层它作用于IIS层面与你用哪种后端技术.NET Framework, .NET Core, PHP, Python无关提供了统一的基础防护。局限它主要基于请求的“语法”特征如URL中是否包含某些字符串、请求头是否异常进行匹配对于复杂的、依赖上下文逻辑的业务层攻击如精心构造的业务逻辑漏洞利用它无能为力。那是WAF和应用代码自身安全该负责的领域。2.2 针对恶意爬虫与SQL注入的规则设计策略我们的目标是两个一是赶走那些无益的、贪婪的爬虫二是堵住SQL注入这种基础但危害巨大的漏洞。规则设计需要有不同的侧重点。对于恶意爬虫恶意爬虫或扫描器通常有显著的行为特征我们可以从以下几个维度进行识别和拦截User-Agent标识很多扫描工具、漏洞利用框架如sqlmap、nikto或低级的爬虫会使用特定的、非常规的User-Agent字符串或者干脆没有User-Agent。我们可以建立一个“黑名单”。请求频率与模式单纯的请求筛选规则难以处理频率问题这需要更高级的模块如“动态IP限制”。但我们可以针对爬虫常访问的敏感路径进行拦截例如直接禁止访问常见的后台管理路径、配置文件路径、版本控制文件等。非常规HTTP方法正常的浏览器交互主要使用GET和POST。而一些扫描或攻击会使用PUT、DELETE、TRACE、OPTIONS等方法进行探测。我们可以限制只允许必要的方法。对于SQL注入攻击SQL注入攻击的本质是将恶意SQL代码通过Web表单的输入域或URL参数插入到后台数据库查询中。其payload有效载荷通常包含一些特殊的字符和关键字组合。特征字符串匹配这是请求筛选最擅长的地方。我们可以定义一组典型的SQL注入攻击特征如包含单引号‘、分号;、--SQL注释、UNION SELECT、xp_cmdshell、EXEC(等字符串的请求参数。重点检查位置SQL注入的payload主要出现在两个地方查询字符串Query String和POST请求体Body。我们的规则需要同时覆盖这两个部分。避免误杀这是关键难点。比如一个正常的博客搜索功能用户可能搜索包含“O‘Henry”这样的内容里面就有单引号。如果粗暴地拦截所有带单引号的请求就会影响正常用户。因此规则需要精细化和组合使用。基于以上分析我们的规则集将是一个组合拳包含“拒绝特定字符串”、“拒绝特定文件路径”、“限制HTTP方法”和“过滤特定User-Agent”等多个维度。3. 实战配置手把手配置请求筛选规则理论讲完我们进入实战环节。我将以IIS 10Windows Server 2016/2019/2022为例进行演示其他版本IIS 7.5, 8, 8.5界面可能略有不同但核心路径和概念一致。3.1 打开请求筛选功能界面打开IIS管理器。在左侧连接面板中选择你要保护的网站。如果你想为服务器上所有网站设置全局规则可以选择顶层的服务器节点。但通常建议在网站级别配置更灵活。在主窗口中间的功能视图区域找到并双击“请求筛选”图标。如果没找到可能需要先安装该功能服务器管理器 - 添加角色和功能 - Web服务器 - 安全 - 请求筛选。进入后你会看到几个选项卡文件扩展名、规则、URL、请求头、查询字符串、拒绝字符串序列。我们主要操作规则和拒绝字符串序列。3.2 配置“拒绝字符串序列”屏蔽SQL注入特征“拒绝字符串序列”是防御SQL注入的核心。它检查请求的URL和Body中是否包含你定义的恶意字符串。切换到“拒绝字符串序列”选项卡。点击右侧操作面板的“添加拒绝字符串...”。在弹出的窗口中输入你要拦截的字符串。这里就是放置我们规则模板的地方。重要提示添加规则时务必考虑你的应用实际情况。以下是一个基础的、相对安全的SQL注入特征黑名单你可以在此基础上增删。基础SQL注入防护规则模板‘ -- 单引号最常见的注入尝试 ; -- 分号用于结束一条SQL语句并开始下一条 -- -- SQL单行注释 /* -- SQL多行注释开始 */ -- SQL多行注释结束 version -- 尝试获取数据库版本信息 char( -- 可能用于构造字符串绕过 exec( -- 执行命令或存储过程 xp_ -- SQL Server扩展存储过程前缀如xp_cmdshell UNION -- UNION注入攻击关键字 SELECT -- 通常与UNION搭配 INSERT -- 可能用于盲注或数据篡改 UPDATE -- 可能用于盲注或数据篡改 DELETE -- 可能用于盲注或数据篡改 DROP -- 删除表或数据库 CREATE -- 创建对象 ALTER -- 修改对象操作将上面每一行作为一个单独的字符串依次添加进去。IIS会进行大小写不敏感的匹配。原理当请求的URL或POST数据体中包含上述任意字符串时IIS会直接拒绝该请求返回404.11错误URL包含双重转义序列被拒绝或404.13错误内容长度超出限制常用于POST数据过滤从而阻止payload到达后端。注意事项与避坑指南误杀风险这是最大的坑。比如你的网站有一个“用户评价”功能用户完全可能输入“It‘s great!”。如果拦截了单引号‘这个正常请求就会被阻断。解决方案是“白名单”思维不要在全站粗暴应用。你可以通过“规则”功能为特定的、已知安全的URL路径如/api/submit-comment创建“允许规则”在其设置中“允许”某些字符串如单引号从而覆盖全局的“拒绝”设置。这需要你对应用路由非常清楚。编码绕过攻击者可能会对payload进行URL编码如%27代表单引号‘。幸运的是IIS的“拒绝字符串序列”检查是在URL解码之后进行的所以能有效识别%27。但对于双重编码或其他混淆技术可能需要更复杂的WAF规则。性能影响列表越长对每个请求的检查开销就越大。建议从关键特征开始逐步添加并观察服务器性能。3.3 配置“规则”综合防护恶意爬虫与路径扫描“规则”功能更强大允许我们创建更复杂的匹配条件并组合多个过滤条件。规则1屏蔽常见敏感路径和文件很多爬虫和扫描器会批量请求诸如/admin/、/phpmyadmin/、/wp-login.php、/.git/、/web.config等路径试图发现后台或泄露信息。切换到“规则”选项卡。点击右侧“添加过滤规则...”。在“添加过滤规则”对话框名称输入一个描述如BlockCommonSensitivePaths。扫描URL保持默认。在“条件”区域点击“添加条件...”选择“URL路径”。匹配方式选择“包含”。模式这里我们可以使用竖线|作为分隔符一次性添加多个模式。输入/admin/|/phpmyadmin/|/wp-admin/|/wp-login.php|/.git/|/.svn/|/.env|/web.config|/config.php|/backup/|/database/操作类型选择“拒绝”。点击确定。规则2过滤恶意User-Agent再次“添加过滤规则...”。名称BlockBadUserAgents。添加条件选择“请求头”。请求头输入User-Agent。匹配方式选择“包含”。模式同样使用|分隔。输入一些常见的恶意爬虫、扫描器或空User-Agent标识sqlmap|nikto|acunetix|nessus|metasploit|dirbuster|gobuster|hydra|python-requests|Java|curl|libwww|masscan|zgrab|^$注意^$是一个正则表达式表示空字符串。但IIS请求筛选的“包含”模式不支持标准正则^$在这里可能被当作普通字符串匹配。更可靠的做法是单独创建一条规则设置“User-Agent”头“不存在”则拒绝。更精确的做法添加两条规则。规则2.1: 条件为“请求头”User-Agent“不存在”操作“拒绝”。用于拦截没有User-Agent的请求。规则2.2: 条件为“请求头”User-Agent“包含”模式为sqlmap|nikto|acunetix|...操作“拒绝”。操作类型选择“拒绝”。点击确定。警告过滤User-Agent要格外小心。python-requests、Java、curl这些也可能是你自家微服务或API客户端在用的。这条规则更适合用于拦截明确已知的恶意扫描器并且最好在测试环境验证无误后再上生产。一个更安全的做法是只拦截那些100%确定为恶意的标识如sqlmap、Acunetix等。规则3限制HTTP方法可选但推荐如果你的网站只是一个普通的展示型或交互型网站使用GET获取页面POST提交表单可以禁用其他方法。添加过滤规则...。名称AllowOnlyGetPost。添加条件选择“HTTP谓词”即HTTP Method。匹配方式选择“不等于”。模式输入GET|POST|HEAD。HEAD方法通常用于检查资源是安全的。操作类型选择“拒绝”。这样任何非GET/POST/HEAD的请求如PUT, DELETE, TRACE, CONNECT, OPTIONS等都会被拒绝。3.4 配置“查询字符串”与“请求头”过滤除了在“规则”里综合设置我们还可以在专门的选项卡进行更细致的控制。查询字符串切换到“查询字符串”选项卡你可以“拒绝未指定的查询字符串”这意味着只允许你明确列出的参数名。这对于API接口固定参数的情况非常有用可以防止攻击者尝试传递任意参数进行探测。但对于普通网站限制太强容易误杀慎用。请求头切换到“请求头”选项卡你可以设置允许或拒绝的请求头列表。例如你可以“拒绝未指定的请求头”或者添加特定的请求头并设置最大长度限制防止过长的头部导致缓冲区溢出等问题。4. 规则模板汇总与导入导出经过以上步骤我们已经配置了一套组合规则。为了便于你快速部署我将核心配置整理成一个可以参照的模板。请注意IIS请求筛选规则没有直接的“一键导入”功能但你可以通过操作applicationHost.config文件或使用PowerShell来批量管理。4.1 规则模板清单供手动配置参考A. 拒绝字符串序列防SQL注入‘;--/**/versionchar(exec(xp_UNIONSELECTINSERTUPDATEDELETEDROPCREATEALTERB. 过滤规则防爬虫与路径扫描规则名BlockSensitivePaths条件URL路径包含/admin/|/phpmyadmin/|/wp-admin/|/wp-login.php|/.git/|/.svn/|/.env|/web.config|/config.php|/backup/|/database/操作拒绝规则名BlockEmptyUserAgent条件请求头User-Agent不存在操作拒绝规则名BlockKnownScanners(谨慎使用)条件请求头User-Agent包含sqlmap|nikto|acunetix|nessus操作拒绝规则名AllowOnlyGetPostHead条件HTTP谓词不等于GET|POST|HEAD操作拒绝4.2 通过配置文件备份与部署IIS的配置最终保存在%SystemRoot%\System32\inetsrv\config\applicationHost.config文件中。请求筛选的规则位于对应站点的security-requestFiltering节点下。你可以在测试环境配置好规则后找到该站点对应的requestFiltering节点XML内容。将其复制在生产环境的applicationHost.config文件的对应位置粘贴。在IIS管理器中点击右侧操作面板的**“重新启动**”站点或运行iisreset命令使配置生效。更安全的方式是使用PowerShell的WebAdministration模块# 导入模块 Import-Module WebAdministration # 为指定站点添加一个拒绝字符串 Add-WebConfigurationProperty -Filter /system.webServer/security/requestFiltering/denyQueryStringSequences -PSPath IIS:\ -Location MySiteName -Name . -Value {sequence‘} # 添加一条过滤规则示例阻止访问/admin/ Add-WebConfiguration -Filter /system.webServer/security/requestFiltering/filteringRules -PSPath IIS:\ -Location MySiteName -Value { name‘BlockAdminPath‘; scanUrl‘true‘; scanQueryString‘false‘; applyTo‘url‘; denyStrings‘/admin/‘; denyAction‘Deny‘ }使用脚本可以方便地在多台服务器间同步规则也便于版本管理。5. 效果验证、问题排查与高级技巧配置完成后不能一配了之必须验证效果并监控日志。5.1 如何验证规则是否生效模拟攻击测试使用浏览器访问你的网站在URL后尝试添加一个包含单引号的参数如https://yoursite.com/test?id1‘。如果配置正确你应该会立即收到一个404.11或400错误页面而不是你的网站正常页面或错误信息。尝试访问一个被屏蔽的路径如https://yoursite.com/admin/同样应该被拒绝。使用curl或Postman等工具发送一个User-Agent为sqlmap/1.0的请求应该被拒绝。查看IIS日志IIS日志默认位于%SystemDrive%\inetpub\logs\LogFiles下。打开日志文件查找sc-status状态码为404.11、404.13、400或405方法不允许的条目。查看对应的cs-uri-query查询字符串和cs(User-Agent)确认正是被你的规则拦截的请求。这是最直接的证据。5.2 常见问题与排查技巧问题1规则配置了但好像没效果攻击请求还是到了我的应用检查位置确认规则是添加在正确的网站或应用程序节点下而不是父节点如服务器节点上且父节点没有覆盖或冲突的规则。检查顺序IIS请求筛选规则没有明确的优先级顺序所有规则同时生效。但如果存在“允许”规则在“规则”条件中设置“允许”操作它会覆盖全局的“拒绝字符串序列”。检查是否有此类规则。缓存修改配置后确保重启了网站或应用程序池。特征匹配确认攻击payload确实匹配了你定义的字符串。攻击者可能使用了编码或变形。你可以尝试在规则中使用更宽泛或变形的模式。问题2正常功能被拦截了误杀定位触发规则查看IIS日志找到被拦截的正常请求记录其状态码和URL。根据状态码判断是哪个模块拦截的404.11是查询字符串404.13是内容长度或请求体405是HTTP方法。创建允许规则这是解决误杀的最佳实践。例如你的/api/search接口允许用户输入带单引号的关键词。那么为这个特定的URL路径/api/search创建一条新的过滤规则在规则的设置里找到“允许字符串序列”或相应的允许设置将单引号‘添加进去。这样对于/api/search的请求即使包含单引号也会因为这条更具体的“允许”规则而被放行而其他URL的请求仍受全局“拒绝”规则约束。调整规则粒度如果误杀频繁说明你的黑名单过于宽泛。考虑移除一些过于常见的字符如单引号或者将其替换为更具体的攻击模式如‘ OR、‘;--。问题3攻击者好像绕过了规则编码与混淆基础的字符串匹配无法应对双重URL编码、Unicode编码、大小写变换IIS默认不区分大小写所以没问题、插入注释等高级绕过技术。请求筛选是基础防护不能替代代码层面的参数化查询和输入验证。规则更新攻击手段在进化你的规则也需要定期维护和更新。关注安全社区将新的常见攻击payload加入黑名单。5.3 高级技巧与建议分层防御永远记住IIS请求筛选只是安全体系中的一层。它应该与以下措施结合使用代码安全使用参数化查询如SqlParameter或ORM框架从根本上杜绝SQL注入。输入验证在应用层对所有输入进行严格的类型、格式、长度验证。WAF对于高价值或高风险业务部署专业的WAF如ModSecurity for IIS或云WAF服务它能提供基于正则表达式、语法分析、机器学习等更强大的防护能力。网络层限制使用防火墙或NSG网络安全组限制不必要的入站端口。日志监控与分析不要设完规则就不管了。定期分析IIS日志特别是那些被拦截的请求4xx状态码。这能帮你发现新的攻击趋势调整规则甚至发现你未曾察觉的应用漏洞。性能考量每条规则都会增加一点CPU开销。如果规则列表非常长比如有成百上千条可能会对高并发网站产生可感知的影响。定期审查和优化规则列表移除那些从未触发过的或过时的条目。测试环境先行任何安全规则的修改务必先在测试环境充分验证确保不影响正常业务功能然后再部署到生产环境。可以编写简单的自动化测试脚本模拟正常用户和恶意请求验证规则的拦截效果和误杀情况。配置IIS请求筛选规则更像是一个持续优化的过程而不是一劳永逸的设置。它需要你对自己的应用流量有基本的了解并在安全与可用性之间找到平衡点。从一套保守的规则开始观察日志逐步调整你会逐渐建立起一道有效的、轻量级的边界防线为你的Windows服务器Web应用挡住大部分“噪音”和低层次攻击让你能更专注于业务逻辑本身的安全与稳定。 IIS请求筛选实战：配置规则防御SQL注入与恶意爬虫
1. 项目概述为什么IIS请求筛选是Web安全的“第一道门”在Windows Server上跑Web应用IISInternet Information Services是绕不开的角色。很多朋友部署完网站配好SSL证书就觉得万事大吉了。但真正的挑战往往来自那些看不见的“访客”——恶意爬虫、自动化扫描器、SQL注入攻击脚本。它们不会在日志里留下“我是坏人”的签名而是伪装成正常请求试图寻找你应用的每一个缝隙。我见过太多案例一个看似正常的网站后台日志里塞满了对/phpmyadmin/、/wp-admin/、/admin/login.php的扫描请求或是充斥着‘ OR ‘1’’1这类经典的SQL注入试探。这些请求不仅消耗服务器资源更暴露了潜在的安全风险。而IIS自带的“请求筛选”功能恰恰是应对这类基础但高频攻击的利器。它不像WAFWeb应用防火墙那样复杂和昂贵而是集成在IIS管理器内部通过定义规则在HTTP请求到达你的应用代码之前就将其拦截或拒绝。简单来说你可以把它理解为你家小区的门禁系统。WAF可能是聘请的专业保安团队而请求筛选规则就是你在大门口自己设置的一套“访客黑名单”和“物品禁入清单”。比如禁止任何携带特定危险工具如某些可疑的URL参数或HTTP头的人入内或者直接拒绝来自某些已知“捣乱分子”恶意IP或User-Agent的访问。今天我就结合自己多年在Windows服务器运维中的实战经验手把手带你配置这套“门禁系统”并分享一套经过验证的、可直接套用的规则模板帮你有效屏蔽那些烦人的恶意爬虫和基础的SQL注入攻击。2. 核心思路与规则设计原理2.1 请求筛选的工作机制与拦截点在深入配置之前我们必须先搞清楚IIS请求筛选是在哪个环节生效的。这对于理解其能力和局限至关重要。IIS处理一个HTTP请求的流水线大致如下接收请求IIS从网络接口接收到原始的HTTP请求数据包。协议解析IIS解析HTTP协议提取出方法GET、POST等、URL、协议版本、头部Headers、主体Body等信息。请求筛选介入正是在协议解析之后请求被递交给具体的处理程序如ASP.NET模块、静态文件处理器之前请求筛选模块会介入。它会根据我们设定的规则对请求的各个部分进行检查。规则匹配与动作如果请求的任何部分匹配了某条“拒绝”规则IIS会立即终止该请求的处理并直接向客户端返回一个HTTP错误通常是404 - Not Found或400 - Bad Request而不会将请求传递到后端的应用程序如你的ASP.NET Core或PHP代码。如果请求通过了所有筛选才会进入后续的处理流程。这个拦截点意味着高效恶意请求在非常早的阶段就被丢弃不会消耗后端应用池Application Pool的进程资源也不会执行任何数据库查询或业务逻辑。底层它作用于IIS层面与你用哪种后端技术.NET Framework, .NET Core, PHP, Python无关提供了统一的基础防护。局限它主要基于请求的“语法”特征如URL中是否包含某些字符串、请求头是否异常进行匹配对于复杂的、依赖上下文逻辑的业务层攻击如精心构造的业务逻辑漏洞利用它无能为力。那是WAF和应用代码自身安全该负责的领域。2.2 针对恶意爬虫与SQL注入的规则设计策略我们的目标是两个一是赶走那些无益的、贪婪的爬虫二是堵住SQL注入这种基础但危害巨大的漏洞。规则设计需要有不同的侧重点。对于恶意爬虫恶意爬虫或扫描器通常有显著的行为特征我们可以从以下几个维度进行识别和拦截User-Agent标识很多扫描工具、漏洞利用框架如sqlmap、nikto或低级的爬虫会使用特定的、非常规的User-Agent字符串或者干脆没有User-Agent。我们可以建立一个“黑名单”。请求频率与模式单纯的请求筛选规则难以处理频率问题这需要更高级的模块如“动态IP限制”。但我们可以针对爬虫常访问的敏感路径进行拦截例如直接禁止访问常见的后台管理路径、配置文件路径、版本控制文件等。非常规HTTP方法正常的浏览器交互主要使用GET和POST。而一些扫描或攻击会使用PUT、DELETE、TRACE、OPTIONS等方法进行探测。我们可以限制只允许必要的方法。对于SQL注入攻击SQL注入攻击的本质是将恶意SQL代码通过Web表单的输入域或URL参数插入到后台数据库查询中。其payload有效载荷通常包含一些特殊的字符和关键字组合。特征字符串匹配这是请求筛选最擅长的地方。我们可以定义一组典型的SQL注入攻击特征如包含单引号‘、分号;、--SQL注释、UNION SELECT、xp_cmdshell、EXEC(等字符串的请求参数。重点检查位置SQL注入的payload主要出现在两个地方查询字符串Query String和POST请求体Body。我们的规则需要同时覆盖这两个部分。避免误杀这是关键难点。比如一个正常的博客搜索功能用户可能搜索包含“O‘Henry”这样的内容里面就有单引号。如果粗暴地拦截所有带单引号的请求就会影响正常用户。因此规则需要精细化和组合使用。基于以上分析我们的规则集将是一个组合拳包含“拒绝特定字符串”、“拒绝特定文件路径”、“限制HTTP方法”和“过滤特定User-Agent”等多个维度。3. 实战配置手把手配置请求筛选规则理论讲完我们进入实战环节。我将以IIS 10Windows Server 2016/2019/2022为例进行演示其他版本IIS 7.5, 8, 8.5界面可能略有不同但核心路径和概念一致。3.1 打开请求筛选功能界面打开IIS管理器。在左侧连接面板中选择你要保护的网站。如果你想为服务器上所有网站设置全局规则可以选择顶层的服务器节点。但通常建议在网站级别配置更灵活。在主窗口中间的功能视图区域找到并双击“请求筛选”图标。如果没找到可能需要先安装该功能服务器管理器 - 添加角色和功能 - Web服务器 - 安全 - 请求筛选。进入后你会看到几个选项卡文件扩展名、规则、URL、请求头、查询字符串、拒绝字符串序列。我们主要操作规则和拒绝字符串序列。3.2 配置“拒绝字符串序列”屏蔽SQL注入特征“拒绝字符串序列”是防御SQL注入的核心。它检查请求的URL和Body中是否包含你定义的恶意字符串。切换到“拒绝字符串序列”选项卡。点击右侧操作面板的“添加拒绝字符串...”。在弹出的窗口中输入你要拦截的字符串。这里就是放置我们规则模板的地方。重要提示添加规则时务必考虑你的应用实际情况。以下是一个基础的、相对安全的SQL注入特征黑名单你可以在此基础上增删。基础SQL注入防护规则模板‘ -- 单引号最常见的注入尝试 ; -- 分号用于结束一条SQL语句并开始下一条 -- -- SQL单行注释 /* -- SQL多行注释开始 */ -- SQL多行注释结束 version -- 尝试获取数据库版本信息 char( -- 可能用于构造字符串绕过 exec( -- 执行命令或存储过程 xp_ -- SQL Server扩展存储过程前缀如xp_cmdshell UNION -- UNION注入攻击关键字 SELECT -- 通常与UNION搭配 INSERT -- 可能用于盲注或数据篡改 UPDATE -- 可能用于盲注或数据篡改 DELETE -- 可能用于盲注或数据篡改 DROP -- 删除表或数据库 CREATE -- 创建对象 ALTER -- 修改对象操作将上面每一行作为一个单独的字符串依次添加进去。IIS会进行大小写不敏感的匹配。原理当请求的URL或POST数据体中包含上述任意字符串时IIS会直接拒绝该请求返回404.11错误URL包含双重转义序列被拒绝或404.13错误内容长度超出限制常用于POST数据过滤从而阻止payload到达后端。注意事项与避坑指南误杀风险这是最大的坑。比如你的网站有一个“用户评价”功能用户完全可能输入“It‘s great!”。如果拦截了单引号‘这个正常请求就会被阻断。解决方案是“白名单”思维不要在全站粗暴应用。你可以通过“规则”功能为特定的、已知安全的URL路径如/api/submit-comment创建“允许规则”在其设置中“允许”某些字符串如单引号从而覆盖全局的“拒绝”设置。这需要你对应用路由非常清楚。编码绕过攻击者可能会对payload进行URL编码如%27代表单引号‘。幸运的是IIS的“拒绝字符串序列”检查是在URL解码之后进行的所以能有效识别%27。但对于双重编码或其他混淆技术可能需要更复杂的WAF规则。性能影响列表越长对每个请求的检查开销就越大。建议从关键特征开始逐步添加并观察服务器性能。3.3 配置“规则”综合防护恶意爬虫与路径扫描“规则”功能更强大允许我们创建更复杂的匹配条件并组合多个过滤条件。规则1屏蔽常见敏感路径和文件很多爬虫和扫描器会批量请求诸如/admin/、/phpmyadmin/、/wp-login.php、/.git/、/web.config等路径试图发现后台或泄露信息。切换到“规则”选项卡。点击右侧“添加过滤规则...”。在“添加过滤规则”对话框名称输入一个描述如BlockCommonSensitivePaths。扫描URL保持默认。在“条件”区域点击“添加条件...”选择“URL路径”。匹配方式选择“包含”。模式这里我们可以使用竖线|作为分隔符一次性添加多个模式。输入/admin/|/phpmyadmin/|/wp-admin/|/wp-login.php|/.git/|/.svn/|/.env|/web.config|/config.php|/backup/|/database/操作类型选择“拒绝”。点击确定。规则2过滤恶意User-Agent再次“添加过滤规则...”。名称BlockBadUserAgents。添加条件选择“请求头”。请求头输入User-Agent。匹配方式选择“包含”。模式同样使用|分隔。输入一些常见的恶意爬虫、扫描器或空User-Agent标识sqlmap|nikto|acunetix|nessus|metasploit|dirbuster|gobuster|hydra|python-requests|Java|curl|libwww|masscan|zgrab|^$注意^$是一个正则表达式表示空字符串。但IIS请求筛选的“包含”模式不支持标准正则^$在这里可能被当作普通字符串匹配。更可靠的做法是单独创建一条规则设置“User-Agent”头“不存在”则拒绝。更精确的做法添加两条规则。规则2.1: 条件为“请求头”User-Agent“不存在”操作“拒绝”。用于拦截没有User-Agent的请求。规则2.2: 条件为“请求头”User-Agent“包含”模式为sqlmap|nikto|acunetix|...操作“拒绝”。操作类型选择“拒绝”。点击确定。警告过滤User-Agent要格外小心。python-requests、Java、curl这些也可能是你自家微服务或API客户端在用的。这条规则更适合用于拦截明确已知的恶意扫描器并且最好在测试环境验证无误后再上生产。一个更安全的做法是只拦截那些100%确定为恶意的标识如sqlmap、Acunetix等。规则3限制HTTP方法可选但推荐如果你的网站只是一个普通的展示型或交互型网站使用GET获取页面POST提交表单可以禁用其他方法。添加过滤规则...。名称AllowOnlyGetPost。添加条件选择“HTTP谓词”即HTTP Method。匹配方式选择“不等于”。模式输入GET|POST|HEAD。HEAD方法通常用于检查资源是安全的。操作类型选择“拒绝”。这样任何非GET/POST/HEAD的请求如PUT, DELETE, TRACE, CONNECT, OPTIONS等都会被拒绝。3.4 配置“查询字符串”与“请求头”过滤除了在“规则”里综合设置我们还可以在专门的选项卡进行更细致的控制。查询字符串切换到“查询字符串”选项卡你可以“拒绝未指定的查询字符串”这意味着只允许你明确列出的参数名。这对于API接口固定参数的情况非常有用可以防止攻击者尝试传递任意参数进行探测。但对于普通网站限制太强容易误杀慎用。请求头切换到“请求头”选项卡你可以设置允许或拒绝的请求头列表。例如你可以“拒绝未指定的请求头”或者添加特定的请求头并设置最大长度限制防止过长的头部导致缓冲区溢出等问题。4. 规则模板汇总与导入导出经过以上步骤我们已经配置了一套组合规则。为了便于你快速部署我将核心配置整理成一个可以参照的模板。请注意IIS请求筛选规则没有直接的“一键导入”功能但你可以通过操作applicationHost.config文件或使用PowerShell来批量管理。4.1 规则模板清单供手动配置参考A. 拒绝字符串序列防SQL注入‘;--/**/versionchar(exec(xp_UNIONSELECTINSERTUPDATEDELETEDROPCREATEALTERB. 过滤规则防爬虫与路径扫描规则名BlockSensitivePaths条件URL路径包含/admin/|/phpmyadmin/|/wp-admin/|/wp-login.php|/.git/|/.svn/|/.env|/web.config|/config.php|/backup/|/database/操作拒绝规则名BlockEmptyUserAgent条件请求头User-Agent不存在操作拒绝规则名BlockKnownScanners(谨慎使用)条件请求头User-Agent包含sqlmap|nikto|acunetix|nessus操作拒绝规则名AllowOnlyGetPostHead条件HTTP谓词不等于GET|POST|HEAD操作拒绝4.2 通过配置文件备份与部署IIS的配置最终保存在%SystemRoot%\System32\inetsrv\config\applicationHost.config文件中。请求筛选的规则位于对应站点的security-requestFiltering节点下。你可以在测试环境配置好规则后找到该站点对应的requestFiltering节点XML内容。将其复制在生产环境的applicationHost.config文件的对应位置粘贴。在IIS管理器中点击右侧操作面板的**“重新启动**”站点或运行iisreset命令使配置生效。更安全的方式是使用PowerShell的WebAdministration模块# 导入模块 Import-Module WebAdministration # 为指定站点添加一个拒绝字符串 Add-WebConfigurationProperty -Filter /system.webServer/security/requestFiltering/denyQueryStringSequences -PSPath IIS:\ -Location MySiteName -Name . -Value {sequence‘} # 添加一条过滤规则示例阻止访问/admin/ Add-WebConfiguration -Filter /system.webServer/security/requestFiltering/filteringRules -PSPath IIS:\ -Location MySiteName -Value { name‘BlockAdminPath‘; scanUrl‘true‘; scanQueryString‘false‘; applyTo‘url‘; denyStrings‘/admin/‘; denyAction‘Deny‘ }使用脚本可以方便地在多台服务器间同步规则也便于版本管理。5. 效果验证、问题排查与高级技巧配置完成后不能一配了之必须验证效果并监控日志。5.1 如何验证规则是否生效模拟攻击测试使用浏览器访问你的网站在URL后尝试添加一个包含单引号的参数如https://yoursite.com/test?id1‘。如果配置正确你应该会立即收到一个404.11或400错误页面而不是你的网站正常页面或错误信息。尝试访问一个被屏蔽的路径如https://yoursite.com/admin/同样应该被拒绝。使用curl或Postman等工具发送一个User-Agent为sqlmap/1.0的请求应该被拒绝。查看IIS日志IIS日志默认位于%SystemDrive%\inetpub\logs\LogFiles下。打开日志文件查找sc-status状态码为404.11、404.13、400或405方法不允许的条目。查看对应的cs-uri-query查询字符串和cs(User-Agent)确认正是被你的规则拦截的请求。这是最直接的证据。5.2 常见问题与排查技巧问题1规则配置了但好像没效果攻击请求还是到了我的应用检查位置确认规则是添加在正确的网站或应用程序节点下而不是父节点如服务器节点上且父节点没有覆盖或冲突的规则。检查顺序IIS请求筛选规则没有明确的优先级顺序所有规则同时生效。但如果存在“允许”规则在“规则”条件中设置“允许”操作它会覆盖全局的“拒绝字符串序列”。检查是否有此类规则。缓存修改配置后确保重启了网站或应用程序池。特征匹配确认攻击payload确实匹配了你定义的字符串。攻击者可能使用了编码或变形。你可以尝试在规则中使用更宽泛或变形的模式。问题2正常功能被拦截了误杀定位触发规则查看IIS日志找到被拦截的正常请求记录其状态码和URL。根据状态码判断是哪个模块拦截的404.11是查询字符串404.13是内容长度或请求体405是HTTP方法。创建允许规则这是解决误杀的最佳实践。例如你的/api/search接口允许用户输入带单引号的关键词。那么为这个特定的URL路径/api/search创建一条新的过滤规则在规则的设置里找到“允许字符串序列”或相应的允许设置将单引号‘添加进去。这样对于/api/search的请求即使包含单引号也会因为这条更具体的“允许”规则而被放行而其他URL的请求仍受全局“拒绝”规则约束。调整规则粒度如果误杀频繁说明你的黑名单过于宽泛。考虑移除一些过于常见的字符如单引号或者将其替换为更具体的攻击模式如‘ OR、‘;--。问题3攻击者好像绕过了规则编码与混淆基础的字符串匹配无法应对双重URL编码、Unicode编码、大小写变换IIS默认不区分大小写所以没问题、插入注释等高级绕过技术。请求筛选是基础防护不能替代代码层面的参数化查询和输入验证。规则更新攻击手段在进化你的规则也需要定期维护和更新。关注安全社区将新的常见攻击payload加入黑名单。5.3 高级技巧与建议分层防御永远记住IIS请求筛选只是安全体系中的一层。它应该与以下措施结合使用代码安全使用参数化查询如SqlParameter或ORM框架从根本上杜绝SQL注入。输入验证在应用层对所有输入进行严格的类型、格式、长度验证。WAF对于高价值或高风险业务部署专业的WAF如ModSecurity for IIS或云WAF服务它能提供基于正则表达式、语法分析、机器学习等更强大的防护能力。网络层限制使用防火墙或NSG网络安全组限制不必要的入站端口。日志监控与分析不要设完规则就不管了。定期分析IIS日志特别是那些被拦截的请求4xx状态码。这能帮你发现新的攻击趋势调整规则甚至发现你未曾察觉的应用漏洞。性能考量每条规则都会增加一点CPU开销。如果规则列表非常长比如有成百上千条可能会对高并发网站产生可感知的影响。定期审查和优化规则列表移除那些从未触发过的或过时的条目。测试环境先行任何安全规则的修改务必先在测试环境充分验证确保不影响正常业务功能然后再部署到生产环境。可以编写简单的自动化测试脚本模拟正常用户和恶意请求验证规则的拦截效果和误杀情况。配置IIS请求筛选规则更像是一个持续优化的过程而不是一劳永逸的设置。它需要你对自己的应用流量有基本的了解并在安全与可用性之间找到平衡点。从一套保守的规则开始观察日志逐步调整你会逐渐建立起一道有效的、轻量级的边界防线为你的Windows服务器Web应用挡住大部分“噪音”和低层次攻击让你能更专注于业务逻辑本身的安全与稳定。