泉州高防服务器高防WAF的自定义规则怎么写才能不影响正常用户?

去年双十一期间，泉州一家做鞋服电商的老板阿福，差点没被气出心脏病。他们公司为了应对大促期间的各种网络攻击，特意租了一台高防服务器，还配上了高防WAF。结果大促当天，攻击倒是没挡住几个，自家的正常用户却大批量被误拦截了。客户下单下不了，购物车加不进，客服电话被打爆，后台的防护日志里密密麻麻全是拦截记录。阿福盯着屏幕，脸上写满了无奈：这WAF到底是保护我们的，还是来砸场子的?

阿福遇到的这个问题，在泉州这座民营经济极其活跃的城市里，实在是太常见了。晋江的鞋服企业、石狮的服装批发市场、南安的水暖厨卫工厂、安溪的茶企，随着线上业务的比重越来越大，越来越多的泉州老板开始给自己的服务器配备高防WAF。但问题也随之而来：自定义规则写得太松，防不住攻击。写得太死，正常用户被误伤。这个度到底该怎么把握?

我今天就想结合自己在泉州本地帮助各个电商和外贸企业配置WAF自定义规则的真实经历，把那些让人头疼的问题和背后的门道，好好说一说。

先搞清楚一个问题：WAF为什么会误伤正常用户

很多泉州的企业主对WAF有一个误解，觉得它就像一个智能的门卫，能自动分清好人和坏人。但实际上，WAF没有真正的智能。它只会按照你给它设定的规则来判断。规则说，URL里包含“select”这个词的一律拦截。那用户搜索“Please select your size”的时候，URL里出现了“select”，WAF就会毫不留情地把它拦住。它不会去想这个用户到底是不是在选尺码。

WAF误伤正常用户，本质上就是自定义规则的匹配条件过于宽泛或者不够精准。你把网撒得太大，想捞的鱼没捞着，虾米倒是捞了一大堆。

泉州丰泽区一家做软件外包的公司就遇到过这种情况。他们给服务器配了一条规则，用来拦截SQL注入攻击。规则里写的是，只要请求参数里包含“and”、“or”、“select”这类SQL关键字，就一律拦截。结果呢?他们的客户在系统里搜索产品型号，型号里刚好带一个“or”，比如“ABC-OR-123”，请求被拦了。客户在备注里写“select red color”，请求又被拦了。一天下来，几十个正常操作被当成了攻击，客户投诉不断。

所以写自定义规则的第一条原则就是，不要用太宽泛的匹配条件。能用精确匹配的就不要用模糊匹配，能用白名单的就不要用黑名单，能限流量的就不要直接拦截。

了解你的业务特征，是写好规则的前提

在我接触过的泉州企业里，很多技术员拿到WAF控制台的第一件事，就是去抄网上的规则模板。把这个规则复制进来，把那个规则粘贴进去，然后就算完事了。这种做法其实很危险。每个企业的业务场景都不一样，别人家适用的规则，搬到你家可能就是灾难。

泉州德化一家做陶瓷电商的公司，他们的业务特点是大量的用户会在晚上集中下单，而且订单备注里经常包含各种特殊符号，比如“#”、“@”、“&”这些。他们之前抄了一份网上的防护规则，里头有一条是“请求参数包含特殊符号的一律拦截”。结果这条规则一开启，晚上高峰期的订单直接掉了四成。因为用户下单时填写的地址信息里包含“某某路某某号”的“号”字的拼音缩写，或者备注里打了表情符号，全被拦了。

后来我帮他们重新梳理了规则。先把WAF切换到观察模式，跑了整整一周的流量日志。把这一周里所有被规则命中的请求全部导出来，一条一条人工过。哪些是真正的攻击，哪些是正常的用户请求，分门别类地标记好。然后再根据这些真实的流量特征，去调整规则的匹配条件。比如特殊符号那条规则，改成了“请求参数包含特殊符号并且请求频率超过每分钟20次”才触发拦截。因为正常的用户不会在一分钟里连续下几十个订单，但攻击脚本会。这样一来，正常用户的零星特殊符号请求不会被误拦，而高频的恶意请求会被精准识别。

这个案例给我的启发很深。写WAF自定义规则，不是坐在办公室里拍脑袋想出来的，而是要基于你对业务流量的真实理解。你首先得知道，你的正常用户长什么样，他们的请求有什么特征，他们通常在什么时间访问，他们会传什么样的数据。把这些搞清楚了，你才知道哪些请求该放行，哪些请求该拦截。

区分不同类型的用户，给不同的人不同的待遇

很多泉州企业犯的另一个错误，就是“一刀切”。把所有的访问者都当成一样的对待，不管你是注册用户还是游客，不管你是从泉州本地访问还是从海外访问，都用同一套规则来筛。

这种做法显然是不合理的。泉州晋江一家做跨境电商的公司，他们的网站有大量海外客户访问。他们之前配置了一条地理位置访问控制规则，把来自某些国家和地区的IP全部封禁了。理由是这些地区经常发起攻击。结果封完之后才发现，有几个重要的海外代理商正好就在这些地区，人家的采购员想登录系统查库存，发现网站打不开，直接打电话来问是不是公司倒闭了。

正确的做法是给不同的用户群体分配不同的防护策略。比如注册用户，尤其是已经登录的、有正常购物行为的用户，可以给予更高的信任度，对它们的请求放宽检测。而对于未登录的游客，尤其是那些访问频率异常高的、访问路径特别规整的，就要严加防范。

泉州安溪一家做茶叶批发的公司，他们的做法就很聪明。他们在WAF里配置了一条规则，专门识别已经登录的用户。只要用户的请求里携带了有效的登录凭证，就自动跳过后面的很多检测环节。而对于未登录的用户，则会进行更严格的检查，比如限制访问频率、检查User-Agent是否合理、检查请求路径是否符合正常的浏览行为。这样一来，注册用户的购物体验几乎没有受到任何影响，而那些来爬取产品信息的恶意脚本则被挡在了门外。

白名单机制是你的好朋友

在泉州帮企业调试WAF的过程中，我发现很多人把注意力都放在了黑名单上，想着怎么把坏人拦在外面，却忽略了白名单的作用。其实，白名单比黑名单更重要，也更安全。

黑名单的逻辑是，我知道哪些是坏人，我把他们拦住，剩下的都是好人。但问题是，坏人的手段在不停地变，你永远不可能把所有坏人的特征都列出来。白名单的逻辑正好相反，我知道哪些是好人，我把他们放进来，其他的都不信任。虽然会牺牲一些灵活性，但安全等级要高得多。

泉州石狮一家做服装批发的平台，他们有一个给核心供应商使用的API接口。这个接口不需要对公众开放，只对固定的几十家供应商开放。他们之前用黑名单的方式来防护，结果供应商的IP经常变动，每次变动都会被误拦，供应商烦不胜烦。

后来我帮他们把规则改成了白名单模式。把这几十家供应商的出口IP地址全部收集起来，在WAF里配置了一条白名单规则，只有来自这些IP的请求才能访问这个API接口，其他的全部拒绝。这样一来，供应商无论用什么设备、什么浏览器，只要IP在白名单里，就能正常访问。而外部的恶意扫描连这个接口的地址都探测不到，因为没有白名单IP的请求会被直接丢弃，不会返回任何信息。

这个例子说明，白名单机制虽然看起来不那么“开放”，但对于特定的业务场景来说，它是最安全、最不容易误伤正常用户的方式。

利用速率限制代替简单拦截

很多WAF误伤的情况，不是因为你拦截了不该拦截的请求，而是因为你拦截了不该拦截的用户。换句话说，单个请求本身是正常的，但用户的整体行为模式看起来可疑。这种情况下，直接拦截请求可能会误伤，但用速率限制来处理就会温和得多。

泉州鲤城区一家做餐饮系统的公司，他们的服务器经常遭到撞库攻击。攻击者用大量的用户名和密码组合去尝试登录。他们一开始的做法是，检测到多次登录失败就封IP。结果呢?公司附近的几家餐厅用的都是同一个商业宽带，共享同一个公网IP。其中一家餐厅的前台小妹忘记密码，连续输了五次都错了，触发了封IP规则，导致这个IP下所有餐厅的系统都登不上去了。

后来他们改用了更精细的速率限制策略。不是简单地封IP，而是在WAF里配置了针对不同维度的限制。同一个IP在一分钟内尝试登录超过十次，触发人机验证。同一个用户名在一分钟内尝试登录超过五次，暂时锁定这个用户名的登录功能，但不影响该用户名下的其他操作。同一个设备指纹在一小时内尝试登录失败的次数达到二十次，才考虑封禁。这样一来，正常的用户偶尔输错密码不会被误伤，而恶意的撞库攻击则被有效限制了。

速率限制的核心思想是，不要轻易地对一个请求说“不”，而是要温柔地让恶意行为变得“成本高昂”。人机验证、滑动验证、逐步延长的等待时间，这些方式对正常用户的体验影响很小，但对攻击脚本的影响是致命的。

善用观察模式和灰度发布

我在泉州见过太多这样的情况：技术员写了一条新规则，直接在WAF里点了一个“拦截”，然后就去干别的事了。过了半天，客服冲进来说网站出问题了，他才知道自己闯了祸。

这是一个很不好的习惯。任何一条新的WAF自定义规则，都不应该直接上线到拦截模式。正确的做法是，先把它设置为“仅记录”或者“观察”模式，跑一段时间看看。观察这条规则在真实流量下会命中多少请求，命中的这些请求是真正的攻击还是正常的访问。通过观察日志，你会发现很多你写规则时没有想到的边界情况。

泉州台商投资区一家做智能家居的公司，他们在上线一条防止越权访问的规则之前，先在观察模式下跑了两周。结果发现这条规则会误伤到一个正常的功能，就是用户分享设备给家人的那个页面。因为那个页面的请求参数里包含了被分享者的用户ID，而规则的设计是把所有非本人的用户ID访问都视为越权。通过观察日志发现了这个问题之后，他们在规则里加了一个例外条件，放行了“分享”这个特定路径下的请求。如果这条规则直接上线，那所有使用分享功能的用户都会被误拦。

观察模式跑完之后，如果确认误报率很低，可以再切换到“拦截+记录”模式，但建议先只针对一小部分流量开启，比如先对百分之一的用户生效。这就是灰度发布。观察这百分之一的用户在真实场景下会不会遇到问题，如果没有问题，再逐步扩大到所有流量。这个过程虽然慢一些，但胜在稳妥，不会因为一条规则导致大面积的业务中断。

及时处理误报，把救火变成日常

即便做了再充分的测试，也不可能保证每一条规则都百分之百不误伤。总有你想不到的业务场景，总有你漏掉的边界情况。所以，建立一套快速的误报处理机制非常重要。

泉州很多做得好的企业，都会安排专人不定期地查看WAF的防护日志。不是等用户投诉了才去看，而是主动去看。每天上班第一件事，打开WAF控制台，筛选出拦截记录，过一遍。发现有可疑的拦截，立刻确认是真正的攻击还是误报。如果是误报，马上通过白名单机制把对应的请求特征加白。

我在泉州某客户那里见过一个高效的流程。他们公司在WAF控制台的告警和钉钉群做了集成，每一条拦截事件都会实时推送到群里。运维人员和业务人员一起盯着这个群，一旦发现某条拦截看起来不正常，比如拦截的URL是某个正常的商品详情页，拦截的参数是正常的用户评论内容，立刻就有人去处理。处理的方式也很简单，直接在拦截事件上点“误报处理”，系统会自动把对应的规则ID和请求特征添加到白名单里。从发现问题到解决问题，前后不到五分钟。用户可能还没来得及刷新第二次，问题就已经解决了。

这个案例告诉我们，误报不可怕，可怕的是没有快速响应的机制。只要你能够在用户注意到问题之前就把问题解决掉，用户甚至都不知道曾经有过问题。

关于规则优先级，你必须知道的事

WAF的自定义规则是按照优先级顺序执行的。优先级数字越小的规则，越先被执行。这个特性用得好，可以帮你实现很多精细化的控制，用得不好，规则之间互相打架，会让你头疼不已。

泉州惠安一家做石雕工艺品电商的公司，他们配置了两条规则。第一条规则是白名单，允许所有来自公司办公网络的IP直接放行，优先级设为1。第二条规则是黑名单，拦截所有来自海外的POST请求，优先级设为2。这个顺序是正确的。因为白名单的优先级更高，所以来自公司办公网络的请求会被直接放行，根本不会走到后面的黑名单那里去。反过来，如果把黑名单的优先级设成1，白名单设成2，那么来自公司办公网络的请求会先被黑名单检查，如果它恰好是一个海外IP的POST请求，就会被拦截，根本等不到白名单来放行。

所以在你配置多条规则的时候，一定要想清楚规则的执行顺序。通常情况下，白名单规则应该放在最前面，优先级最高。其次是那些基于特定业务场景的精确规则。最后才是那些通用的、拦截范围较广的规则。

总结

写到这儿，我想起泉州一位老运维跟我说过的一句话。他说，写WAF自定义规则，本质上就是在这个世界的善恶之间划一条线。线划得太松，坏人进来了，你守不住。线划得太紧，好人进不来了，你守的就没有意义。

在泉州这座充满烟火气的城市里，每天都有无数个正常用户在访问着大大小小的网站和系统。他们可能是一个在石狮服装城进货的批发商，可能是一个在安溪茶叶店下单的茶客，可能是一个在晋江鞋都看鞋的年轻人。作为技术的守护者，我们的任务不是把所有人都挡在门外，而是在坏人面前竖起一堵墙，同时给好人留一扇门。

写好WAF自定义规则，需要我们了解业务、精准匹配、善用白名单、巧用速率限制、做好灰度验证、建立快速响应的误报处理机制。这不是一蹴而就的事情，而是一个需要持续观察、持续调整、持续优化的过程。