摘要：# 当僵尸大军压境，你的自建高防CDN能撑多久？ 我最近跟几个自己搭高防CDN的朋友聊天，发现一个挺有意思的现象：大家配置规则时都挺自信，真遇到大规模僵尸网络攻击时，却总有点手忙脚乱。 说白了，很多方案在PPT上看着无懈可击——什么智能识别、动态学习、…

当僵尸大军压境，你的自建高防CDN能撑多久？

我最近跟几个自己搭高防CDN的朋友聊天，发现一个挺有意思的现象：大家配置规则时都挺自信，真遇到大规模僵尸网络攻击时，却总有点手忙脚乱。

说白了，很多方案在PPT上看着无懈可击——什么智能识别、动态学习、实时拦截，一套套的。可真当几十万、上百万个僵尸节点从全球各地涌过来，模拟着正常用户的请求行为时，不少自建系统就开始露馅了。

问题出在哪？往往不是防护没上，而是建模和过滤的思路，从一开始就跑偏了。

一、僵尸网络早就不“傻”了，你的规则还在刻舟求剑

先说个大实话：现在稍微有点规模的僵尸网络，早就不玩那种固定IP段、固定User-Agent的“复古攻击”了。

我去年看过一个真实案例。一个中型电商站的自建高防CDN，配置了基于IP信誉库和请求频率的规则，觉得够用了。结果被一个新型僵尸网络打穿了。事后分析日志才发现，攻击者用了云函数+动态住宅代理IP池，每个IP只打几下就换，请求间隔完全模拟真人浏览节奏——点开商品页，滑动几下，加购物车，犹豫一会儿再请求结算页。

这种攻击，你单看任何一个IP的瞬间行为，它都“干净”得像个真实用户。传统的“每秒请求数超过X就封”或者“来自某个ASN就拦”的规则，在这种攻击面前基本就是摆设。

所以，自建高防CDN的第一课，就是得彻底放弃“一招鲜”的幻想。 僵尸网络是活的，它会进化。你的防护模型，也得是活的。

二、IP行为建模：别只看“它做了什么”，想想“它为什么这么做”

建模这事儿，听起来挺学术，其实核心就一个问题：你怎么区分一个顶着“人皮”的机器，和一个真人？

很多方案喜欢堆砌指标：请求频率、访问深度、鼠标移动轨迹、甚至光标抖动……指标越多越安心。但真到实战时，维度太多反而可能拖垮系统性能，或者产生大量误判。

我自己折腾过一阵子，后来发现，与其面面俱到，不如抓住几个关键的非对称性特征。僵尸网络再逼真，它在两个层面几乎一定会露出马脚：

1. 行为的“目的性”过于纯粹 正常用户访问一个网站，行为是发散的、带探索性的。比如看新闻，可能从首页热点点进去，也可能突然想起什么去搜个旧闻，看完文章还可能顺手点开相关推荐或者评论区。 僵尸网络的行为，哪怕模拟得再像，其底层逻辑通常是为了完成一个明确的攻击任务——比如刷某个API接口、占满某个资源、或者遍历爬取内容。这就导致它的访问路径，在统计学上会呈现出异常的“集中度”和“序列规律性”。你可以通过分析大量IP的访问路径图谱，找出那些目的性过强、缺乏随机“闲逛”行为的异常集群。

2. 身份的“背景噪音”缺失 一个真实的互联网用户，他的访问会带着丰富的“背景噪音”。比如，他的IP可能偶尔会同时访问其他无关网站（跳出去查个资料），他的请求头里可能带着各种浏览器插件留下的“指纹”，他的访问时间分布会符合人类作息（哪怕夜猫子，也有疲劳周期）。 而僵尸节点，尤其是云主机或代理池里的节点，它的“背景”往往很干净。它可能只访问你的网站，请求头高度标准化或随机化得不自然，活动时间可以7x24小时保持稳定输出。建模时，给IP的“生活丰富度”打个分，往往比单纯分析请求参数更有效。

三、特征过滤：别追求“绝对干净”，要计算“容忍成本”

过滤规则设置上，最容易犯的错就是追求“零误杀”。一看到有正常用户被误拦，就赶紧把规则调松。结果就是，攻击流量稍微一伪装，就又溜进来了。

这里有个很现实的权衡：业务容忍度。

• 对于核心交易接口、登录入口，你可以把规则设得极其严格，哪怕误杀率有0.1%，也能通过二次验证（如短信、滑块）把真人捞回来。因为这里的风险成本极高。
• 对于资讯浏览、商品展示这类公开页面，规则就可以更宽松一些，容忍一定的“灰色流量”，把防护重心放在资源消耗限制上（比如单个IP的并发连接数、带宽占用）。只要它不把你服务器拖垮，就允许它存在。

过滤的本质是分流，不是灭绝。 好的过滤系统，应该像一套多层筛子：

1. 第一层（粗筛）：基于IP信誉、ASN、地理位置等硬指标，拦住已知的“坏蛋”和明显异常的流量。这部分规则可以凶一点，更新要快。
2. 第二层（细筛）：也就是我们前面说的IP行为建模分析层。这里是核心战场，通过实时分析会话行为序列、意图图谱，把那些“穿着人皮的机器”识别出来，打上可疑标签，送入“慢速通道”或挑战通道。
3. 第三层（动态决策）：根据当前系统负载、被攻击的严重程度，动态调整前两层的过滤阈值。攻击猛的时候，宁可错杀，也要保服务不挂；风平浪静的时候，就放宽一点，提升用户体验。

四、几个容易被忽略，但贼好用的“土办法”

除了高大上的算法模型，一些结合业务特性的“土办法”往往有奇效。这些办法小众，但实用。

• 业务逻辑埋点：在关键业务流程里，埋一些只有真人交互才会触发的“暗桩”。比如，在商品列表页到详情页的跳转中，加入一个极短时长的JS计算挑战（对用户无感），或者检查页面某些元素的鼠标悬停事件。僵尸程序为了效率，通常会绕过这些“无意义”的客户端交互，一绕，就暴露了。
• “蜜罐”资源：故意在网站里放一些对正常用户不可见、但爬虫或扫描程序很容易触发的“蜜罐”链接或API。一旦有IP访问了这些资源，直接标记为高危，后续请求进行严格限制。这招对付无差别扫描的僵尸网络特别好用。
• 慢速攻击识别：现在很多高级攻击主打一个“慢”，用很低的速率但超长的连接时间耗你资源。对付这种，连接时长和请求总量的监控比瞬时频率更重要。可以给每个IP建立一个“资源消耗积分”，随时间缓慢衰减，一旦积分超过阈值，就算它每秒请求一次，也照样掐掉。

五、最后说点扎心的

自建高防CDN，听起来很酷，掌控感十足。但它本质上是一场持续的成本、技术和精力的军备竞赛。你需要不断维护IP情报库、调整模型参数、分析新的攻击模式。

如果你的业务不是特别敏感，或者团队里没有能持续投入的运维专家，那么上云，用成熟的高防服务，可能才是更经济、更踏实的选择。 毕竟，专业的安全团队是7x24小时在和全球的黑产对抗，他们看到的样本和迭代的速度，个人或小团队很难跟上。

当然，如果你就是好这一口，享受这种“魔高一尺道高一丈”的技术对抗乐趣，或者有不得不自建的合规要求，那么希望上面这些关于IP行为建模和特征过滤的碎碎念，能给你带来一点不一样的视角。

记住，防护没有银弹。最好的模型，永远是那个能理解你的业务，并且随时准备被推翻重来的模型。 行了，就聊这么多，该去检查日志了。