自建CDN通常由分布在不同地域的Nginx、HAProxy或自研边缘节点组成，流量路径复杂，攻击面比单机房应用更大。中心化WAF只能覆盖经过它的请求，如果某个PoP节点存在单独入口或回源链路被绕过，攻击者就能直接利用该节点发起扫描、撞库、CC攻击。NDR旁路部署在交换机镜像端口或分光器上，不介入原有转发链路，能够捕获东西向和南北向会话，正好补上CDN边缘侧的安全盲区。

自建CDN为什么需要NDR而不是只靠WAF

WAF工作在第7层，依赖请求头、Cookie、POST参数等特征做拦截。CDN节点往往会缓存静态内容，部分请求可能不会回源，WAF若只部署在源站前面，就无法看清边缘节点与用户之间的完整交互。NDR在第3到7层做深度检测，可以还原TCP会话，识别慢速连接、半开连接、异常分片、DNS隧道等WAF难以覆盖的威胁。

另一个关键区别是响应能力。WAF一般直接拦截请求，但误报会影响用户体验，而且当攻击流量到达WAF时已经消耗了CDN节点资源。NDR在旁路分析，发现可疑行为后可以通过API通知调度中心，让边缘节点执行有针对性的限速、重定向或封禁。这样检测与响应分离，对正常业务影响更小。

在自建CDN场景中，边缘节点数量多，每个节点都要采集流量。如果把NDR探测器随节点部署，成本会上升，但能够获得更完整的本地流量视图。也可以采用集中式分析集群，把各地镜像流量通过VXLAN或GRE隧道回传，但带宽成本高。通常比较实际的做法是在重要PoP点部署轻量探测器，本地做初步过滤，再将元数据或摘要发送到中心NDR平台做关联分析。

流量镜像的实现要点与配置示例

流量镜像在自建CDN中有三种常见方式。第一种是硬件分光器或交换机SPAN端口，适合物理服务器，对主机完全透明但需要交换机支持。第二种是虚拟交换机镜像，比如在Open vSwitch中创建镜像端口，把虚拟网卡的流量复制到NDR虚拟机。第三种是主机内抓包，使用Linux内核的AF_PACKET、PF_RING或eBPF程序直接从网卡捕获数据包，灵活但会消耗少量CPU。

下面以Open vSwitch为例，假设边缘节点上有一个网桥br0，业务虚拟机接在veth0上，我们要把它的收发流量镜像到NDR端口。命令如下：

# 创建镜像端口，把veth0流量复制到ndr0
ovs-vsctl add-port br0 ndr0 -- set interface ndr0 type=internal
ovs-vsctl --id=@p get port veth0 \
    --id=@m create mirror name=mirror0 select-all=true output-port=@p \
    -- add bridge br0 mirrors @m

如果节点运行在云主机上，没有交换机权限，可以使用tc的clsact钩子配合matchall过滤器做入方向镜像，不过出方向镜像需要结合ifb接口。由于tc配置较繁琐，很多团队偏好直接部署eBPF程序，例如通过XDP或TC-BPF把数据包复制到用户态缓冲区。eBPF方案对内核版本有要求，在Linux 5.x以上可以稳定运行，而且可以按五元组过滤，只镜像HTTP或HTTPS流量，降低NDR分析压力。

无论采用哪种方式，都要注意镜像流量不参与原路径回包。NDR探测器通常是单臂部署，只接收不发送。如果探测器要主动发送RST包阻断连接，必须单独接一个管理网口，并且配置严格防火墙规则，防止误伤正常业务。

NDR检测规则实战与Suricata配置

NDR平台常见的有Suricata、Zeek、Corelight等。Suricata支持多线程抓包和丰富的规则语法，适合在边缘节点本地运行。对自建CDN来说，威胁检测不能只靠IP黑名单，因为CDN面向大量正常用户，误封代价高。需要结合行为基线：统计单个IP的连接速率、请求间隔、User-Agent分布、请求路径熵值等。

以下是一个Suricata规则片段，用于检测User-Agent为空的HTTP请求。很多扫描器和简单脚本不发送UA头，虽然正常爬虫也可能不带，但连续高频出现就是重要信号。

alert http any any -> any any (msg:"HTTP request with empty User-Agent"; \
    flow:to_server,established; \
    http.header_names; content:"User-Agent"; nocase; \
    http.header; content:!"User-Agent"; within:100; \
    threshold:type both, track by_src, count 20, seconds 10; \
    classtype:attempted-recon; sid:900001; rev:1;)

上面的规则中，http.header_names用于检查头字段名，content:!"User-Agent"表示必须不包含User-Agent头。threshold限制10秒内同一源IP触发20次才告警，避免单个请求误报。实际使用时要结合具体CDN日志调整阈值。

另一个值得关注的是HTTP慢速攻击。攻击者发送不完整的请求头，占用连接资源。Suricata可以通过流超时和HTTP解析异常来检测。例如：

alert http any any -> any any (msg:"Possible slowloris attack"; \
    flow:to_server,established; \
    http.start; content:"POST"; nocase; \
    flowbits:set,http_post_start; \
    detection_filter:track by_src, count 50, seconds 30; \
    classtype:denial-of-service; sid:900002; rev:1;)

这条规则标记了同一源IP在30秒内发起50个未完成的POST请求。但需要结合flowbits做状态跟踪，实际生产环境中建议使用Suricata内置的HTTP事件类型，或者直接分析EVE日志中的http字段，用Python脚本做二次检测更灵活。

自动化响应流程与误报控制

NDR的价值不仅在于告警，还在于打通响应链路。自建CDN一般有自己的调度中心或API网关，可以接收封禁指令。当Suricata产生告警后，通过读取EVE JSON日志，提取源IP、目标域名、攻击类型和置信度，再调用CDN控制API下发封禁或限速。下面是一段简化的Python响应脚本。

import json
import requests
EVE_LOG = "/var/log/suricata/eve.json"
CDN_API = "https://cdn-api.ipipp.com/ban"
def handle_alert(alert):
    src_ip = alert.get("src_ip")
    dest_ip = alert.get("dest_ip")
    signature = alert.get("alert", {}).get("signature", "")
    if "empty User-Agent" in signature or "slowloris" in signature:
        payload = {
            "ip": src_ip,
            "action": "rate_limit",
            "duration": 300,
            "reason": signature
        }
        requests.post(CDN_API, json=payload, timeout=5)
with open(EVE_LOG, "r") as f:
    for line in f:
        try:
            event = json.loads(line)
            if event.get("event_type") == "alert":
                handle_alert(event)
        except json.JSONDecodeError:
            continue

注意这个脚本只做演示，生产环境需要加入去重、白名单检查、告警聚合等逻辑。例如某个IP可能是出口NAT，封禁会误伤大量移动用户。更好的做法是先标记观察，通过Redis计数，确认攻击占比超过阈值再执行限速，而不是直接封禁。

另一个响应手段是通过BGP FlowSpec或RTBH黑洞路由。当DDoS攻击流量超过NDR检测到的阈值，可以通知上游路由器丢弃去往目标IP的流量。但CDN节点本身就分布广，黑洞通常用于大规模流量清洗，且需要运营商配合。对应用层攻击，调用边缘节点的Nginx动态配置下发deny指令更加直接。

流量镜像与NDR结合后，自建CDN的安全运营可以从被动查看日志转变为主动发现威胁。建议在每个PoP点先部署一个NDR探测器试运行两周，收集正常流量基线，再逐步开启自动响应。通过对比镜像流量与源站日志，可以评估漏报率和误报率，持续优化规则。