自定义防护规则的核心价值在于把“通用防护”变成“站点专属免疫系统”。通用WAF或云防护产品默认规则覆盖常见攻击向量，但每个站点的业务逻辑、参数结构、用户交互方式完全不同，攻击者恰恰会利用这些“合法但异常”的接口行为绕过通用检测。要真正让防护规则贴合站点漏洞与攻击防护需求，第一步不是堆规则，而是建立一套“请求-业务”映射模型，明确哪些路径、参数、方法组合是合法的，哪些属于灰色地带，哪些必须直接拦截。
以电商站点为例，订单提交接口通常允许POST方法，参数包含商品ID、数量、收货地址、优惠券码。通用规则可能只检查SQL注入和XSS，但无法识别“优惠券码被批量枚举”或“商品ID被遍历查询库存”这类业务逻辑攻击。此时自定义规则应针对该接口设置参数白名单、参数长度限制、单IP请求频率阈值，并联动后端校验优惠券归属与使用次数。规则不是孤立的字符串匹配，而是一组与业务状态联动的判断条件。
规则编写前必须先做攻击面梳理。列出所有对外暴露的URL、API端点、文件上传入口、搜索功能、登录注册、密码找回、评论提交、WebSocket连接点。对每个入口标注：允许的HTTP方法、必需参数、可选参数、参数类型、参数长度范围、是否包含富文本、是否允许文件上传、是否涉及敏感数据返回。这份清单就是自定义规则的地基。很多站点被攻破不是因为缺少高级规则，而是因为某个冷门接口从未被纳入防护范围，攻击者从那里进入后横向移动。
针对SQL注入的自定义规则，不应只依赖正则匹配“union select”或“sleep(”。现代注入攻击大量使用编码绕过、注释符插入、参数污染、二次编码。有效做法是结合参数上下文：对纯数字型参数，直接限制只能出现0-9，长度不超过业务最大值；对字符串型参数，限制字符集为白名单字符，禁止出现数据库注释符、系统函数名、堆叠查询分隔符；对搜索类参数，允许更宽泛字符但必须转义或参数化处理。规则示例：
# 数字型ID参数严格校验
SecRule ARGS:product_id "!^[0-9]{1,10}$" "id:1001,phase:1,deny,status:403,msg:'Invalid product_id format'"
# 字符串参数禁止SQL注释符和危险函数
SecRule ARGS:keyword "@rx (/\*|\*/|--|#|union\s+select|sleep\s*\()" "id:1002,phase:1,deny,status:403,msg:'SQL injection pattern detected'"
XSS防护的自定义规则要区分输入场景。富文本编辑器允许部分HTML标签，普通文本框则完全不需要HTML。对普通输入框，规则应直接拒绝任何包含尖括号、事件属性、javascript伪协议的内容。对富文本区域，必须配合服务端HTML清洗库，规则只做第一层过滤，重点拦截script、iframe、object、embed、svg事件、base标签、meta refresh等危险结构。同时要检查输出点，因为存储型XSS的触发位置可能在管理后台、用户个人页、评论展示区，防护规则必须覆盖输出编码逻辑，而不是只在输入端拦截。
文件上传漏洞的防护规则需要从文件扩展名、MIME类型、文件头魔数、文件大小、文件名长度、存储路径可控性六个维度同时约束。仅靠黑名单扩展名很容易被php3、phtml、pht、phar、asp、aspx、jspx、war等绕过。规则应设置白名单：只允许jpg、png、gif、pdf、docx、xlsx等业务必需类型，并校验文件头与扩展名一致。对图片文件，还应强制进行重编码或元数据剥离，防止图片马。上传后的文件必须存储在非执行目录，或通过独立域名提供访问，规则中要包含对上传目录的访问控制：禁止直接以脚本方式执行该目录下任何文件。
# 限制上传文件扩展名白名单 SecRule FILES "@rx \.(php|phtml|php3|php4|php5|pht|phar|asp|aspx|jsp|jspx|war|sh|py|cgi|pl)$" "id:2001,phase:2,deny,status:403,msg:'Blocked executable file upload'" # 校验上传文件MIME与扩展名一致性 SecRule FILES_TMPNAMES "@inspectFile /usr/local/bin/file_mime_check.sh" "id:2002,phase:2,deny,status:403,msg:'MIME type mismatch'"
针对暴力破解与凭证填充，自定义规则必须超越简单的“单IP请求频率限制”。攻击者使用大规模代理池、慢速攻击、分布式僵尸网络时，IP维度限制几乎失效。有效规则应结合账号维度、设备指纹、行为特征：同一账号在短时间内从多个IP尝试登录，直接触发账号锁定；同一设备指纹尝试多个账号，标记为可疑并加强验证；登录失败后的成功登录，要求二次验证或延迟响应。规则中要设置梯度惩罚机制，第一次超阈值延迟响应，第二次要求验证码，第三次锁定账号并通知管理员。
API接口的防护规则与网页防护有本质区别。API返回JSON或XML，攻击面集中在参数篡改、越权访问、批量数据拉取、速率限制缺失。自定义规则应针对每个API端点定义：必需参数、参数类型、参数范围、返回字段白名单、单用户单时间段最大调用次数、分页最大值限制。例如用户信息接口只允许查询当前登录用户自己的数据，规则中必须校验路径中的user_id与token中的身份标识一致，不一致直接返回403。列表接口强制设置page_size上限，防止一次拉取全量数据。
针对Webshell检测，自定义规则要覆盖写入阶段和运行阶段。写入阶段重点监控敏感目录下出现的新文件，尤其是包含eval、base64_decode、system、exec、shell_exec、passthru、proc_open、assert等危险函数的文件内容。运行阶段监控异常进程、异常网络连接、异常文件包含。规则可以与主机层Agent联动，当检测到可疑文件写入时，立即阻断该IP后续请求，并隔离文件。仅靠流量层规则无法完全阻止Webshell，必须结合文件完整性监控和进程行为分析。
爬虫与自动化攻击的防护规则需要区分善意爬虫、恶意爬虫和正常用户。规则应基于TLS指纹、HTTP头顺序、JavaScript执行能力、鼠标轨迹、页面停留时间、请求序列合理性等多维度判断。对无头浏览器，检查navigator.webdriver属性、自动化框架特征；对请求频率异常但IP分散的，使用设备指纹聚合分析；对只请求数据接口不加载静态资源的，标记为高风险。规则响应可以是插入计算密集型挑战、要求浏览器执行JavaScript、返回混淆数据或直接阻断。
规则维护是持续过程，不是一次性配置。每次业务功能上线、接口变更、参数调整，都必须同步更新防护规则。建立规则变更流程：业务开发提交变更说明，安全团队评估攻击面变化，更新规则白名单和校验逻辑，测试环境验证，生产环境灰度发布。规则库要定期审计，删除过时规则、合并重复规则、优化匹配顺序。规则数量过多会拖慢请求处理速度，建议按攻击类型分层，高频规则放在前面，复杂规则放在后面，并利用缓存减少重复计算。
误报处理是自定义规则落地中最容易被忽视的环节。规则过严会拦截正常用户，导致业务损失；规则过松则形同虚设。必须建立误报反馈机制，让客服和运营人员能快速标记被误拦截的请求，安全团队根据误报样本调整规则。对于无法确定是否恶意的请求，采用“观察模式”记录日志但不阻断，积累数据后分析特征，再决定是否升级为阻断规则。规则中应设置tag和msg字段，便于日志检索和误报定位。
最后要强调的是，自定义防护规则不能替代代码层面的安全修复。规则是缓解措施，是争取修复时间的防线，不是漏洞本身的解药。如果站点存在SQL注入，正确的做法是修复代码使用参数化查询，而不是只靠WAF规则拦截。规则与代码修复并行推进，规则负责阻断已知攻击和缓解未知威胁，代码修复负责消除根本漏洞。只有把自定义规则作为纵深防御体系中的一层，与安全开发规范、代码审计、渗透测试、运行时防护、日志监控联动，才能真正满足站点漏洞与攻击防护需求。
