exploiting-bgp-hijacking-vulnerabilities

利用 BGP 劫持漏洞

何时使用

• 评估组织对 BGP 前缀劫持和路由泄露攻击的暴露程度
• 测试 RPKI（资源公钥基础设施）部署和路由源验证的有效性
• 验证 BGP 监控和告警系统能否检测到未经授权的路由通告
• 在隔离的实验环境中模拟 BGP 劫持，以培训网络运维团队
• 评估 ISP 前缀过滤和路由源授权（ROA）配置

请勿使用本内容在真实互联网上执行实际的 BGP 劫持、在未经授权的情况下针对 BGP 对等体，或破坏真实的互联网路由基础设施。针对生产系统的 BGP 攻击是违法的，可能导致大范围互联网中断。

前提条件

• 使用 GNS3、EVE-NG 或 Containerlab 搭配虚拟路由器（FRRouting、BIRD 或 Cisco IOS）搭建的隔离 BGP 实验环境
• 了解 BGP 路径属性、AS 路径、前缀通告和路由选择
• 可访问 BGP looking glass 服务器和 RPKI 验证器，以监控真实世界的路由状态
• 用于路由监控的 bgpstream、RIPEstat 和 BGPalerter 工具
• 针对任何涉及真实 AS 号或前缀通告的测试的书面授权

工作流

第 1 步：搭建隔离的 BGP 实验环境

# Install Containerlab for BGP simulation
sudo bash -c "$(curl -sL https://get.containerlab.dev)"

# Create a BGP lab topology file
cat > bgp-lab.clab.yml << 'EOF'
name: bgp-hijack-lab
topology:
  nodes:
    # Legitimate AS (AS65001) announcing 10.0.0.0/24
    legitimate-router:
      kind: linux
      image: frrouting/frr:v8.5.0
      binds:
        - legitimate-frr.conf:/etc/frr/frr.conf
    # Attacker AS (AS65002) that will hijack the prefix
    attacker-router:
      kind: linux
      image: frrouting/frr:v8.5.0
      binds:
        - attacker-frr.conf:/etc/frr/frr.conf
    # Transit provider (AS65000) connecting both
    transit-router:
      kind: linux
      image: frrouting/frr:v8.5.0
      binds:
        - transit-frr.conf:/etc/frr/frr.conf
    # Victim network receiving routes
    victim-router:
      kind: linux
      image: frrouting/frr:v8.5.0
      binds:
        - victim-frr.conf:/etc/frr/frr.conf
  links:
    - endpoints: ["legitimate-router:eth1", "transit-router:eth1"]
    - endpoints: ["attacker-router:eth1", "transit-router:eth2"]
    - endpoints: ["transit-router:eth3", "victim-router:eth1"]
EOF

# Configure legitimate router (AS65001)
cat > legitimate-frr.conf << 'EOF'
frr defaults traditional
hostname legitimate-router
router bgp 65001
 bgp router-id 1.1.1.1
 neighbor 10.0.1.2 remote-as 65000
 address-family ipv4 unicast
  network 10.0.0.0/24
  neighbor 10.0.1.2 activate
 exit-address-family
!
interface eth1
 ip address 10.0.1.1/30
!
interface lo
 ip address 10.0.0.1/24
EOF

# Configure attacker router (AS65002) -- initially not announcing the prefix
cat > attacker-frr.conf << 'EOF'
frr defaults traditional
hostname attacker-router
router bgp 65002
 bgp router-id 2.2.2.2
 neighbor 10.0.2.2 remote-as 65000
 address-family ipv4 unicast
  neighbor 10.0.2.2 activate
 exit-address-family
!
interface eth1
 ip address 10.0.2.1/30
EOF

# Deploy the lab
sudo containerlab deploy -t bgp-lab.clab.yml

第 2 步：验证合法的 BGP 路由

# Connect to victim router and verify route to 10.0.0.0/24
docker exec -it clab-bgp-hijack-lab-victim-router vtysh -c "show ip bgp"
docker exec -it clab-bgp-hijack-lab-victim-router vtysh -c "show ip route 10.0.0.0/24"

# Expected: Route via AS65000 AS65001 (legitimate path)
# Verify traceroute follows the legitimate path
docker exec -it clab-bgp-hijack-lab-victim-router traceroute 10.0.0.1

# Check BGP table on transit router
docker exec -it clab-bgp-hijack-lab-transit-router vtysh -c "show ip bgp 10.0.0.0/24"

第 3 步：模拟前缀劫持（更具体路由）

# On the attacker router, announce more-specific prefixes
docker exec -it clab-bgp-hijack-lab-attacker-router vtysh << 'VTYSH'
configure terminal
router bgp 65002
 address-family ipv4 unicast
  network 10.0.0.0/25
  network 10.0.0.128/25
 exit-address-family
!
interface lo
 ip address 10.0.0.1/25
 ip address 10.0.0.129/25
exit
end
write memory
VTYSH

# Verify the hijack on the victim router
docker exec -it clab-bgp-hijack-lab-victim-router vtysh -c "show ip bgp 10.0.0.0/24 longer-prefixes"

# The victim should now prefer the /25 routes via the attacker
# because more-specific routes always win in IP routing
docker exec -it clab-bgp-hijack-lab-victim-router vtysh -c "show ip route 10.0.0.1"
# Expected: Route now via AS65000 AS65002 (attacker)

第 4 步：模拟 AS 路径预置和源劫持

# Origin hijack: Attacker announces the exact /24 prefix
docker exec -it clab-bgp-hijack-lab-attacker-router vtysh << 'VTYSH'
configure terminal
router bgp 65002
 address-family ipv4 unicast
  network 10.0.0.0/24
  no network 10.0.0.0/25
  no network 10.0.0.128/25
 exit-address-family
end
write memory
VTYSH

# Check which route the victim prefers
# With equal prefix length, shortest AS path wins
docker exec -it clab-bgp-hijack-lab-victim-router vtysh -c "show ip bgp 10.0.0.0/24"
# Both routes visible, attacker may win based on AS path length

# Analyze how BGP path selection determines the winner
docker exec -it clab-bgp-hijack-lab-transit-router vtysh -c "show ip bgp 10.0.0.0/24 bestpath-compare"

第 5 步：测试 RPKI 路由源验证

# Set up RPKI validator (Routinator)
docker run -d --name routinator \
  -p 3323:3323 -p 8323:8323 \
  nlnetlabs/routinator:latest

# Configure transit router to use RPKI validation
docker exec -it clab-bgp-hijack-lab-transit-router vtysh << 'VTYSH'
configure terminal
rpki
 rpki cache 172.17.0.1 3323 preference 1
exit
!
route-map RPKI-FILTER permit 10
 match rpki valid
!
route-map RPKI-FILTER deny 20
 match rpki invalid
!
route-map RPKI-FILTER permit 30
 match rpki notfound
!
router bgp 65000
 address-family ipv4 unicast
  neighbor 10.0.2.1 route-map RPKI-FILTER in
 exit-address-family
end
write memory
VTYSH

# Verify RPKI status
docker exec -it clab-bgp-hijack-lab-transit-router vtysh -c "show rpki prefix-table"
docker exec -it clab-bgp-hijack-lab-transit-router vtysh -c "show ip bgp 10.0.0.0/24"
# Attacker's announcement should be marked as RPKI Invalid if ROA exists

第 6 步：监控和检测 BGP 异常

# Install BGPalerter for real-time monitoring
npm install -g bgpalerter
bgpalerter generate -o /etc/bgpalerter

# Configure BGPalerter to monitor your prefixes
cat > /etc/bgpalerter/prefixes.yml << 'EOF'
10.0.0.0/24:
  description: Production Network
  asn: 65001
  ignoreMorespecifics: false
  group: production
EOF

# Start monitoring
bgpalerter

# Use bgpstream to query historical routing data
pip3 install pybgpstream

python3 << 'PYEOF'
import pybgpstream

# Query for historical prefix announcements
stream = pybgpstream.BGPStream(
    from_time="2024-03-14 00:00:00",
    until_time="2024-03-15 00:00:00",
    collectors=["route-views2", "rrc00"],
    record_type="updates",
    filter="prefix more 10.0.0.0/24"
)

for rec in stream.records():
    for elem in rec:
        if elem.type == "A":  # Announcement
            print(f"Time: {elem.time}")
            print(f"Prefix: {elem.fields['prefix']}")
            print(f"AS Path: {elem.fields['as-path']}")
            print(f"Peer: {elem.peer_asn}")
            print("---")
PYEOF

# Check RPKI status via RIPEstat
curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS65001&prefix=10.0.0.0/24" | python3 -m json.tool

关键概念

术语	定义
BGP 劫持	由并不拥有某些 IP 前缀的 AS 未经授权地通告这些前缀，将流量引流经攻击者的网络
更具体劫持	通告比受害者更长（更具体）的前缀，由于最长前缀匹配规则，这类前缀在 IP 路由中总是优先
RPKI（资源 PKI）	一种密码学框架，允许 IP 前缀持有者通过路由源授权（ROA）授权特定 ASN 源发其路由
路由源授权（ROA）	一种数字签名对象，授权某个 AS 源发特定 IP 前缀，从而支持基于 RPKI 的路由验证
AS 路径预置	一种 BGP 技术，通过在 AS 路径中添加重复的 AS 号使某条路由优先级降低，也用于防御劫持
路由泄露	BGP 路由通告传播超出其预期范围，例如客户将中转提供商的路由再通告给其他提供商

工具与系统

• Containerlab：网络实验编排工具，用于使用 Docker 容器部署虚拟路由器拓扑
• FRRouting（FRR）：开源路由套件，支持 BGP、OSPF、IS-IS，并具备 RPKI 验证能力
• BGPalerter：实时 BGP 监控工具，可检测前缀劫持、路由泄露和 RPKI 状态变化
• Routinator：RPKI 依赖方软件，用于验证 ROA 并向路由器提供经过验证的前缀源数据
• pybgpstream：用于分析来自 RouteViews 和 RIPE RIS 收集器的历史及实时 BGP 数据的 Python 库

常见场景

场景：评估组织的 BGP 劫持抵御能力

背景：一家云托管公司（AS12345）为其面向客户的服务宣告 203.0.113.0/24。他们需要评估自身对 BGP 劫持攻击的抵御能力，并验证其 RPKI 部署是否有效。评估包括实验环境模拟和真实环境监控验证。

方法：

1. 构建一个 Containerlab 拓扑，复现该组织与两个上游 ISP 的 BGP 对等互联
2. 使用 RIPEstat 验证该组织所有前缀的 ROA 记录均已正确发布
3. 模拟来自恶意 AS 的更具体前缀劫持（/25），并验证启用了 RPKI 验证的上游 ISP 会丢弃这些无效路由
4. 模拟精确匹配的源劫持，并验证 RPKI ROV 会将该路由标记为无效
5. 测试客户 AS 重新宣告提供商前缀的路由泄露场景
6. 在生产环境中部署 BGPalerter，持续监控未经授权的宣告
7. 验证该组织的 ISP 已配置正确的前缀过滤（基于 IRR 和 RPKI）

陷阱：

• 在真实互联网基础设施上测试 BGP 劫持，而非在隔离的实验环境中进行
• 假设仅靠 RPKI 就能阻止所有劫持——许多网络仍不验证 RPKI
• 未测试更具体前缀宣告，若 ROA 中未设置 max-length，这类宣告会绕过源验证
• 忽视路由泄露场景，即已授权的对等方无意中重新分发路由

Output Format

## BGP Security Assessment Report

**Organization**: Cloud Hosting Co. (AS12345)
**Prefixes Assessed**: 203.0.113.0/24, 198.51.100.0/24
**Assessment Date**: 2024-03-15

### RPKI Status

| Prefix | ROA Exists | Max Length | Origin AS | Status |
|--------|-----------|------------|-----------|--------|
| 203.0.113.0/24 | Yes | /24 | AS12345 | Valid |
| 198.51.100.0/24 | No | N/A | AS12345 | Not Found |

### Lab Simulation Results

| Attack Type | RPKI Validation | Result |
|-------------|-----------------|--------|
| More-specific /25 hijack | Enabled | BLOCKED (Invalid origin) |
| More-specific /25 hijack | Disabled | SUCCESSFUL (traffic diverted) |
| Exact-match origin hijack | Enabled | BLOCKED (Invalid origin) |
| Route leak via customer | Enabled | NOT BLOCKED (valid origin, wrong path) |

### Recommendations
1. Create ROA for 198.51.100.0/24 (currently unprotected)
2. Set max-length to /24 in ROAs to prevent more-specific hijacks
3. Request upstream ISPs enable RPKI Route Origin Validation
4. Deploy BGPalerter for continuous prefix monitoring
5. Register with IRR databases and request prefix filtering from peers