BGP AS_PATH 首跳验证：防范路由劫持的最后一道防线

2026 年 4 月，Spamhaus 报告的多起路由劫持事件揭示了一个令人担忧的趋势：攻击者开始系统性地伪造 AS_PATH 属性，通过构造虚假路径来隐藏真实身份并劫持流量。Cloudflare 的后续分析发现，这些攻击之所以能够成功，很大程度上是因为大量网络运营商未启用一项本应在二十年前就成为标配的安全机制 ——First AS 验证。

AS_PATH 伪造攻击的运作原理

在 BGP 协议中，AS_PATH 属性记录了路由通告经过的所有自治系统序列，既用于路径选择，也用于环路检测。然而，BGP 的设计建立在信任基础之上，AS_PATH 可以被轻易操纵 —— 无论是出于合法的流量工程目的（如 AS Prepending），还是恶意的攻击意图。

近期观察到的攻击呈现出特定的模式：攻击者首先获取未使用的 ASN，然后向上游提供商（如 Gcore AS199524）发送完全伪造的 AS_PATH，其中不包含攻击者自身的 ASN。例如，在一次针对 Orange S.A. 前缀的劫持中，攻击者构造的路径 "48237 1299 199524 270118 17072 41128" 暗示一个未使用的 Orange ASN 通过墨西哥 ISP 购买 transit，这在商业关系上完全不合理。

这种攻击的精妙之处在于，即使目标网络部署了 RPKI ROA（路由起源授权）和 ASPA（自治系统提供商授权），攻击者仍可通过仅保留合法的起源 AS 来绕过这些防护。当上游提供商未验证 First AS 时，伪造路径被接受并传播至整个互联网。

First AS 验证的技术机制

RFC 4271 第 6.3 节明确定义了 First AS 检查的要求：当从外部 BGP 对等体接收 UPDATE 消息时，本地系统应当验证 AS_PATH 中最左侧的 AS 是否等于发送该消息的邻居 AS 号。如果不匹配，应将错误子代码设置为 "Malformed AS_PATH"。

RFC 7606 进一步改进了错误处理机制，建议采用 "treat-as-withdraw" 方式处理格式错误的 AS_PATH—— 即仅丢弃特定前缀而非重置整个 BGP 会话。这种细粒度的错误处理对于生产网络的稳定性至关重要。

从实现角度看，First AS 验证需要在每个 EBGP 会话上执行以下检查逻辑：

接收路由时：
  提取AS_PATH的第一个AS号
  比对邻居配置的remote-as
  如果不匹配：
    根据策略丢弃路由（treat-as-withdraw）
    记录日志供审计

正在制定中的 ASPA 标准草案明确指出：First AS 验证是 ASPA 无法处理缺少足够 AS_PATH 信息的情况时的必要补充。换言之，没有 First AS 验证，ASPA 的防护能力存在根本性缺口。

Cloudflare 实测：Tier 1 网络的安全现状

为了评估 First AS 验证的实际部署情况，Cloudflare 设计了一项主动测试：向 Tier 1 网络邻居发送故意违反 First AS 规则的通告，在 AS_PATH 前添加一个非 13335 的 Cloudflare 自有 ASN（AS402542），观察这些网络是否会正确丢弃无效路由。

测试结果揭示了令人担忧的现实 ——一半的 Tier 1 网络未强制执行 First AS 规则。

正确丢弃无效通告的 Tier 1 网络：

• AS174 (Cogent)
• AS1299 (Arelion)
• AS3257 (GTT)
• AS3491 (PCCW)
• AS5511 (Orange S.A.)
• AS6453 (Tata)
• AS7018 (AT&T)

接受无效通告的 Tier 1 网络：

• AS701 (Verizon)
• AS2914 (NTT)
• AS3356 (Lumen/Colt/Cirion)
• AS6461 (Zayo)
• AS6762 (Sparkle)
• AS6830 (Liberty Global)
• AS12956 (Telefonica)

值得注意的是，大多数未通过测试的 Tier 1 网络运行 Juniper 设备。这揭示了厂商默认配置对互联网安全的深远影响。

主流厂商默认配置对比

不同 BGP 实现对 First AS 验证的默认策略存在显著差异：

厂商默认禁用 First AS 验证的主要原因是为了兼容互联网交换点（IX）的路由服务器场景。路由服务器需要透明地分发路由而不将自己的 AS 添加到 AS_PATH 中，因此接收方需要禁用 First AS 检查。然而，生产网络中面向 IX 路由服务器的会话数量远少于普通对等会话，采用 "默认启用 + 显式例外" 的安全模型显然更为合理。

部署建议与配置清单

核心配置原则

1. 默认启用：在所有 EBGP 会话上启用 First AS 验证，仅在 IX 路由服务器会话上显式禁用
2. 错误处理：确保设备支持 RFC 7606 的 treat-as-withdraw 行为，避免会话重置
3. 监控告警：建立监控机制，记录并告警 First AS 不匹配事件

各厂商配置示例

Cisco IOS-XR：

router bgp 64500
 neighbor 192.0.2.1
  remote-as 64501
  address-family ipv4 unicast
   enforce-first-as

Juniper Junos（需显式启用）：

protocols {
    bgp {
        group external-peers {
            type external;
            neighbor 192.0.2.1 {
                peer-as 64501;
                enforce-first-as;
            }
        }
    }
}

Arista EOS：

router bgp 64500
   neighbor 192.0.2.1 remote-as 64501
   neighbor 192.0.2.1 enforce-first-as

监控检查清单

• 定期审计 BGP 配置，确认 First AS 验证状态
• 监控 BGP 日志中的 Malformed AS_PATH 事件
• 验证 treat-as-withdraw 行为而非会话重置
• 对关键前缀实施 RPKI ROV + ASPA + First AS 验证的多层防护
• 建立与对等方的 SLA，明确路由过滤责任

总结

First AS 验证是 BGP 安全架构中不可或缺的一环，它填补了 RPKI 和 ASPA 在应对完全伪造路径攻击时的防护盲区。Cloudflare 的实测数据表明，即使是互联网骨干的 Tier 1 网络，仍有大量运营商未部署这一基本防护机制。

对于网络管理员而言，启用 First AS 验证的成本极低 —— 只需几行配置即可显著提升路由安全性。考虑到 BGP 劫持可能导致的数据泄露、服务中断和声誉损失，这项投入的风险收益比是极其有利的。

安全默认值的重要性不容忽视。厂商应当重新审视其 BGP 实现的默认配置，向 "安全开箱即用" 的方向演进。同时，网络运营商应当主动审计现有配置，确保 First AS 验证在生产环境中得到正确部署。

参考来源：

• Cloudflare Blog: "Enforcing the First AS in BGP AS_PATHs" (2026-06-03)
• RFC 4271: A Border Gateway Protocol 4 (BGP-4), Section 6.3
• RFC 7606: Revised Error Handling for BGP UPDATE Messages

security