IP 欺骗让发送端伪造源地址，使数据包看似来自他处。文章解释了伪造报文如何利用 IP 协议不验证源地址的特性，结合 CAIDA Spoofer 项目的监测机制，说明为何大规模部署源地址验证（BCP38/BCP84）在工程上仍难推行。
CAIDA 监测体系与报告机制
CAIDA（应用互联网数据分析中心）运行 Spoofer 项目，向全网分布的测试节点发送伪造源地址的探测包，观察是否能穿越网络边界到达目标。APNIC 内部联系库记录了 23 个区域网络运营者组（NOG），这些邮件列表常收到 CAIDA 的欺骗报告提醒。报告会列出观测到的伪造源流量前缀、AS 编号及通过比例，供运营者核查自网是否实施了入向/出向过滤。原文未给出具体检测节点数量、报告发送频次或覆盖前缀总数。
伪造报文的攻击链路与放大效应
攻击者控制主机发送源地址被篡改的 IP 包，目标收到后按协议向伪造地址回复（如 ICMP Destination Unreachable、TCP RST 或 DNS 响应）。若目标为高带宽、高放大倍数的服务（如开放解析器、NTP、Memcached），单位伪造流量可放大数十倍打击受害者。文章用 “向农场订鸡粪却填校长地址” 类比：攻击者隐藏真实源，利用第三方放大流量指向受害者，实现反射放大 DDoS。原文未给出具体放大倍数、典型攻击带宽或近年攻击案例统计。
源地址验证部署的工程阻力
BCP38（RFC 2827）要求在网络边界对出向包做源地址合法性检查，BCP84 进一步细化了多归属、非对称路由场景下的部署指引。但实际部署面临：① 非对称路由导致合法流量被误丢；② 设备性能与 TCAM 资源限制，全表 uRPF 或 ACL 在高密度接入层难以全开；③ 多厂商设备配置不一致，运维成本高；④ 缺乏跨域协作激励，单网部署收益不明显。原文未给出各厂商设备支持矩阵、典型吞吐损耗数据或部署覆盖率统计。
对运维工程师而言，核心行动是：在自网出口启用可行的 uRPF loose 模式或 ACL 过滤，定期核对 CAIDA 报告中的自有前缀，推动上游/对等体同步部署，并在监控平台接入 Spoofer 主动探测结果，形成 “检测—溯源—封堵—验证” 闭环。唯有多方同步落地 BCP38/84，才能从根本上压缩伪造源地址的生存空间。
原文: APNIC Blog（2021-04-29）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog