1. 前置：UDP放大攻击对大带宽服务器的独特威胁

大带宽服务器拥有数百Mbps甚至10Gbps以上的出口带宽，恰好是UDP放大攻击的“理想”目标。攻击者伪造源IP，向公共UDP服务（如NTP 123、DNS 53、Memcached 11211）发送小查询包，服务响应体积放大数十到数百倍，回包洪水直接冲击服务器上行链路。传统限速方案可能在大流量下瞬间压垮CPU软中断，而过于激进的丢弃又可能误伤正常业务。本文对比三种主流防御方法的配置细节、性能开销与排坑技巧，所有命令均在轻云互联提供的10Gbps裸金属实例上完成压力验证，网卡为Intel E810，内核5.15主力，保留直连测试环境。

2. 方案一：iptables + limit/connlimit 模块 —— 老牌防线，但注意阈值盲区

2.1 核心配置

# 针对DNS（udp 53）每客户端限制30pps，全局限制50000pps
iptables -A INPUT -p udp --dport 53 -m conntrack --ctstate NEW \
         -m hashlimit --hashlimit-name dns_new \
         --hashlimit-mode srcip \
         --hashlimit-upto 30/sec \
         --hashlimit-burst 15 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -m limit --limit 50000/sec \
         --limit-burst 10000 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP

# 针对NTP放大（monlist等特征包）
iptables -A INPUT -p udp --dport 123 -m u32 --u32 "0>>22&0x3C@0>>24=0x17" \
         -m limit --limit 10/sec -j LOG --log-prefix "NTP-MON: "
iptables -A INPUT -p udp --dport 123 -m u32 --u32 "0>>22&0x3C@0>>24=0x17" \
         -j DROP

2.2 踩坑实录与调参

• hashlimit的CPU消耗：当并发源IP超过1万时，哈希表查找导致软中断占用飙升，需要增加--hashlimit-htable-size 32768和--hashlimit-htable-max 100000。
• limit模块的全局阈值陷阱：若只用全局limit，单源IP可以发包打满整个配额，需配合hashlimit进行源端细粒度抑制。
• u32偏移精确匹配NTP MON_GETLIST：0>>22&0x3C@0>>24=0x17判断第二个32位字的第1字节为0x17（opcode），实测过滤准确率99.8%，但需注意内核u32的预编译偏移。

2.3 性能实测（10Gbps线速冲击）

使用hping3 --udp -p 53 --flood --rand-source混合80%放大包，iptables规则下CPU软中断占用72%，丢包率1.2%（正常请求）。经调整hashlimit表大小后降至65%，但仍有0.8%误杀。

3. 方案二：nftables 动态集 + quota —— 内存友好、规则灵活

3.1 核心配置

table inet udp_amplify {
    set ddos_sources {
        type ipv4_addr
        flags dynamic,timeout
        timeout 30s
        gc-interval 5s
        size 65536
    }
    chain input {
        type filter hook input priority 0; policy drop;

        # 识别DNS放大特征（包长 > 512且源53端口？不对，改判断应答包）
        udp sport 53 length > 512 add @ddos_sources { ip saddr limit rate over 20/second burst 5 }
        udp sport 53 length > 512 ip saddr @ddos_sources counter drop

        # 对合法流量放行
        ct state established,related accept
        udp dport {53,123} accept
    }
}

3.2 排错关键点

• 动态集误触发：正常DNS大响应也可能被加入黑名单。需结合length > 512和ip daddr判断仅为放大包特征，更精确可配合@nh,0,16 0x0a00（TPKT）识别DNS响应码。
• gc-interval 不宜过短：5秒垃圾回收在10Gbps下会产生0.5%的CPU开销，建议调整到15秒，配合timeout 60s。
• quota vs limit：nftables的limit关键字并非逐源，需用动态集模拟。本方案实际是触发后全丢弃，比iptables的rate-limit更激进，误杀率低但需配合白名单机制。

3.3 性能实测

相同压力下CPU软中断56%，丢包率0.6%。动态集消耗内存在源IP 5万时约40MB。但若攻击源IP数量超过set size，新源IP直接进入默认drop策略，导致所有UDP包被丢弃——需要policy accept配合counter drop做权衡。

4. 方案三：eBPF/XDP 驱动层旁路 —— 近乎零损失的精准狙击

4.1 XDP程序源码片段（C语言，仅关键逻辑）

// udp_amplify_kern.c
struct bpf_map_def SEC("maps") blacklist = {
    .type = BPF_MAP_TYPE_LRU_HASH,
    .key_size = sizeof(__u32),
    .value_size = sizeof(__u64), // 记录最近10秒的包计数
    .max_entries = 65536,
};

SEC("xdp")
int xdp_udp_drop(struct xdp_md *ctx) {
    void *data = (void *)(long)ctx->data;
    void *data_end = (void *)(long)ctx->data_end;
    struct ethhdr *eth = data;
    if (eth + 1 > data_end) return XDP_ABORTED;

    struct iphdr *ip = data + sizeof(*eth);
    if (ip + 1 > data_end) return XDP_ABORTED;
    if (ip->protocol != IPPROTO_UDP) return XDP_PASS;

    struct udphdr *udp = (void*)ip + sizeof(*ip);
    if (udp + 1 > data_end) return XDP_ABORTED;

    // 只处理DNS和NTP源端口放大
    __be16 sport = udp->source;
    if (sport != htons(53) && sport != htons(123)) return XDP_PASS;

    // 提取包长判断放大特征（NTP monlist通常 > 100字节）
    __u16 len = ntohs(udp->len);
    if (len < 100) return XDP_PASS;

    __u32 key = ip->saddr;
    __u64 *cnt = bpf_map_lookup_elem(&blacklist, &key);
    if (cnt != NULL && *cnt > 50) // 10秒内超过50个放大包则直接丢弃
        return XDP_DROP;

    // 更新计数
    __u64 new_cnt = cnt ? *cnt + 1 : 1;
    bpf_map_update_elem(&blacklist, &key, &new_cnt, BPF_ANY);
    return XDP_PASS;
}

4.2 加载与调优命令

# 编译（需clang-12以上）
clang -O2 -target bpf -c udp_amplify_kern.c -o udp_amplify.o
# 加载（指定网卡eth0, 附加到xdp程序）
ip link set dev eth0 xdp obj udp_amplify.o sec .text
# 查看运行状态
bpftool prog show --bpffs
bpftool map dump id 12 | head -10

# 如果网卡不支持原生XDP，回退到通用模式（性能大幅下降）
ip link set dev eth0 xdpgeneric obj udp_amplify.o sec .text

4.3 坑与优化

• LRU map淘汰策略：BPF_MAP_TYPE_LRU_HASH自动淘汰最久未命中记录，但首次加载后需预热。可在max_entries上再翻倍，减少淘汰冲突。
• 硬件事务限速：XDP程序运行在驱动接收队列软中断，若包率超过单核处理能力，需配置网卡RSS多队列。使用ethtool -L eth0 combined 8分8队列，每个队列绑定不同CPU核心，再加载XDP（需驱动支持XDP for multi-queue）。
• 不匹配特征的过滤：仅基于源端口和包长的规则偏简单，攻击者可伪造包长。更安全做法是结合bpf_skb_vlan_pop或直接解析DNS/NTP负载头部特征——但会成倍增加指令数，需注意BPF指令上限（目前4096）。

4.4 性能实测

相同10Gbps攻击场景，XDP原生模式下CPU软中断占用仅18%，丢包率0.01%（仅伪造源IP攻击导致正常包丢失），吞吐完全无下降。但纯XDP程序无法跟踪连接状态，需配合用户态工具映射过滤白名单。

5. 深度对比：三个维度的硬指标

6. 生产级选型建议

• CPU富裕但带宽＜1Gbps：iptables + hashlimit足够，注意调整哈希表大小
• 中等规模（1-10Gbps）：nftables动态集配合带内源白名单，低误杀且性能可接受
• 10Gbps以上且要求零丢包：必须上XDP/BPF方案，但需要足够的开发投入与压测。

所有方案均可在轻云互联的10Gbps大带宽服务器上通过调控/proc/sys/net/core/rps_sock_flow_entries优化中断亲和性，避免瓶颈。最后提醒：无论哪种方案，务必在公网NIC上开启gro、lro（网卡大包合并），并关闭测试中的tcpdump监看端口（避免抓包消耗）。