Posted inNetworking

Bảo Mật BGP với RPKI: Cấu Hình Route Origin Validation và Đăng Ký ROA để Ngăn Chặn BGP Hijacking

Networking tutorial - IT technology blog
Networking tutorial - IT technology blog

BGP hijacking là một trong những kiểu tấn công nghe có vẻ lý thuyết — cho đến khi nó xảy ra với người quen của bạn. Năm 2018, một router bị cấu hình sai tại ISP MainOne của Nigeria vô tình chuyển hướng toàn bộ lưu lượng Google qua Lagos trong khoảng một giờ. Năm 2020, Rostelecom ngắn ngủi quảng bá các route thuộc về Cloudflare, Amazon và hàng chục mạng lớn khác. Không phải khai thác lỗ hổng tinh vi — chỉ là route leak BGP mà internet chấp nhận mà không hề nghi ngờ.

Bạn đang vận hành ASN của riêng mình? Quản lý hạ tầng kết nối với internet công cộng? RPKI là thứ bạn cần đưa vào danh sách ưu tiên. RPKI (Resource Public Key Infrastructure) là giải pháp gần nhất mà ngành công nghiệp có được để thực sự giải quyết vấn đề này. Cái tên nghe đáng sợ hơn quy trình cài đặt thực tế.

Bắt Đầu Nhanh: RPKI trong 5 Phút

Trước khi đi sâu, đây là phiên bản tóm tắt để bạn nắm hướng nhanh.

RPKI làm hai việc:

  • ROA (Route Origin Authorization) — một bản ghi được ký mã hóa xác nhận “AS12345 được phép quảng bá prefix 203.0.113.0/24”
  • ROV (Route Origin Validation) — router của bạn kiểm tra các thông báo BGP đến dựa trên các bản ghi ROA đó và loại bỏ những cái không hợp lệ

Luồng hoạt động như sau:

  1. Bạn đăng ký ROA với RIR của mình (ARIN, RIPE, APNIC, v.v.)
  2. Các router trên toàn thế giới lấy dữ liệu ROA qua các RPKI validator
  3. Khi ai đó quảng bá prefix của bạn từ một ASN không được phép, route của họ sẽ bị đánh dấu là INVALID và bị loại bỏ

Để kiểm tra xem một prefix đã có ROA coverage hay chưa, hãy truy vấn RIPE RPKI validator API:

# Kiểm tra tính hợp lệ ROA cho một prefix
curl -s "https://rpki-validator.ripe.net/api/v1/validity/AS15169/8.8.8.0%2F24" | python3 -m json.tool

Một phản hồi hợp lệ trông như thế này:

{
  "validated_route": {
    "route": {
      "origin_asn": "AS15169",
      "prefix": "8.8.8.0/24"
    },
    "validity": {
      "state": "valid",
      "description": "Ít nhất một VRP khớp với Route Prefix"
    }
  }
}

Tìm Hiểu Sâu: BGP Hijacking Thực Sự Hoạt Động Như Thế Nào

Vấn Đề Với Mô Hình Trust của BGP

BGP được thiết kế vào năm 1989 cho một internet nhỏ và đáng tin cậy. Mỗi AS tin tưởng tuyệt đối vào lời nói của các AS khác — nếu AS9999 tuyên bố sở hữu 192.0.2.0/24, BGP không có cơ chế tích hợp nào để xác minh điều đó.

Kẻ tấn công (hoặc router bị cấu hình sai) khai thác điều này bằng cách quảng bá các prefix mà chúng không sở hữu. Vì BGP ưu tiên các route cụ thể hơn, việc quảng bá 192.0.2.0/25 sẽ kéo lưu lượng khỏi thông báo hợp lệ 192.0.2.0/24. Lưu lượng bị chặn, bị hủy hoặc bị chuyển hướng âm thầm — đôi khi không bị phát hiện trong nhiều giờ.

Bản Ghi ROA Trông Như Thế Nào

ROA là một tuyên bố được ký mã hóa: “ASN này được phép quảng bá prefix này, tối đa đến độ dài prefix tối đa này.” Trường max-length có vai trò quan trọng thực sự. Nếu không có nó, không có gì ngăn được ai đó phân mảnh /24 của bạn thành 256 /32 cụ thể hơn và hút lưu lượng từng subnet một.

Ví dụ ROA:
  ASN:        AS64496
  Prefix:     203.0.113.0/24
  Max Length: 24
  Validity:   2024-01-01 đến 2026-01-01

Tác dụng:
  203.0.113.0/24 từ AS64496  → VALID
  203.0.113.0/25 từ AS64496  → INVALID (cụ thể hơn max-length)
  203.0.113.0/24 từ AS99999  → INVALID (ASN nguồn sai)

Cài Đặt RPKI Validator

ROV trên router của bạn yêu cầu một RPKI validator cục bộ. Router truy vấn nó qua giao thức RTR (RPKI-to-Router) để lấy danh sách prefix được phép hiện tại. Hai tùy chọn được triển khai rộng rãi nhất là Routinator (từ NLnet Labs) và OctoRPKI (từ Cloudflare).

Cài đặt Routinator trên Ubuntu/Debian:

# Thêm repository NLnet Labs
curl -fsSL https://packages.nlnetlabs.nl/aptkey.asc | sudo gpg --dearmor -o /usr/share/keyrings/nlnetlabs-archive-keyring.gpg

echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/nlnetlabs-archive-keyring.gpg] https://packages.nlnetlabs.nl/linux/debian $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/nlnetlabs.list

sudo apt update && sudo apt install routinator -y

# Khởi tạo và chấp nhận ARIN RPA
routinator init --accept-arin-rpa

# Khởi động RTR server (cổng 3323) và HTTP API (cổng 8323)
routinator server --rtr 0.0.0.0:3323 --http 0.0.0.0:8323 &

Chờ vài phút để lần tải đầu tiên hoàn tất. Sau đó xác nhận nó đang hoạt động:

# Kiểm tra trạng thái xác thực qua HTTP API
curl http://localhost:8323/api/v1/status

# Kiểm tra một prefix cụ thể
curl "http://localhost:8323/api/v1/validity/AS15169/8.8.8.0/24"

Nâng Cao: Kích Hoạt ROV trên Router

Cấu Hình FRRouting (FRR)

FRR có hỗ trợ RTR client gốc, vì vậy nếu bạn đã chạy nó cho BGP, việc thêm lớp xác thực RPKI không đòi hỏi thay đổi lớn.

# Kết nối vào FRR vtysh
sudo vtysh
! Cấu hình RPKI cache server (instance Routinator của bạn)
rpki
  rpki cache 127.0.0.1 3323 preference 1
  exit

! Áp dụng route-map cho neighbor (route-map bên dưới xử lý việc thực thi)
router bgp 64496
  neighbor 198.51.100.1 route-map RPKI-FILTER in
  exit

! valid → chấp nhận, notfound → chấp nhận, invalid → loại bỏ
route-map RPKI-FILTER permit 10
  match rpki valid
  exit
route-map RPKI-FILTER permit 20
  match rpki notfound
  exit
route-map RPKI-FILTER deny 30
  match rpki invalid
  exit

Ba trạng thái route cần hiểu:

  • valid — ROA tồn tại và ASN nguồn + prefix khớp → chấp nhận
  • notfound — không có ROA nào tồn tại cho prefix này → chấp nhận (không thể xác minh theo cả hai hướng)
  • invalid — ROA tồn tại nhưng ASN nguồn không khớp → loại bỏ

Xác minh RPKI đang hoạt động trong FRR:

sudo vtysh -c "show rpki prefix-table"
sudo vtysh -c "show rpki cache-connection"
sudo vtysh -c "show bgp ipv4 unicast 8.8.8.0/24"

Đăng Ký ROA Của Riêng Bạn

Có không gian IP riêng? Hãy tạo ROA cho nó. Quy trình khác nhau tùy theo RIR:

RIPE NCC (Châu Âu/Trung Đông/Trung Á):

  1. Đăng nhập vào cổng RIPE NCC tại my.ripe.net
  2. Đến RPKI → Create ROA
  3. Chọn prefix của bạn, đặt ASN nguồn và max-length
  4. Ký và công bố

ARIN (Bắc Mỹ):

  1. Đăng nhập vào ARIN Online tại account.arin.net
  2. Điều hướng đến Manage → RPKI
  3. Tạo ROA cho tài nguyên của bạn

Đối với max-length, hãy khớp với độ dài prefix bạn thực sự quảng bá. Chỉ quảng bá /24? Đặt max-length thành 24. Đừng đặt thành 32 — điều đó cho phép bất kỳ route cụ thể hơn nào từ ASN của bạn, đây chính xác là những gì một cuộc tấn công deaggregation khai thác.

Tự Động Hóa Giám Sát ROA Bằng Script Python

Một script giám sát nhỏ kiểm tra các prefix bạn quảng bá dựa trên validator cục bộ và đánh dấu bất cứ điều gì bất thường:

#!/usr/bin/env python3
import requests
import json

MY_PREFIXES = [
    {"asn": "AS64496", "prefix": "203.0.113.0/24"},
    {"asn": "AS64496", "prefix": "198.51.100.0/24"},
]

VALIDATOR_URL = "http://localhost:8323/api/v1/validity"

def check_prefix(asn, prefix):
    encoded = prefix.replace("/", "%2F")
    url = f"{VALIDATOR_URL}/{asn}/{encoded}"
    try:
        r = requests.get(url, timeout=5)
        data = r.json()
        state = data["validated_route"]["validity"]["state"]
        return state
    except Exception as e:
        return f"lỗi: {e}"

for entry in MY_PREFIXES:
    state = check_prefix(entry["asn"], entry["prefix"])
    status = "OK" if state == "valid" else f"CẢNH BÁO: {state.upper()}"
    print(f"{entry['prefix']} ({entry['asn']}): {status}")
python3 check_rpki.py
# Đầu ra:
# 203.0.113.0/24 (AS64496): OK
# 198.51.100.0/24 (AS64496): OK

Mẹo Thực Tế

Bắt Đầu Ở Chế Độ Giám Sát, Không Phải Chế Độ Thực Thi

Đừng chuyển sang chế độ loại bỏ INVALID nghiêm ngặt ngay từ ngày đầu. Hãy ghi log những gì sẽ bị loại bỏ và xem xét trong một tuần trước. Một số peer hợp lệ có ROA bị cấu hình sai — cắt route của họ ngay lập tức sẽ phá vỡ kết nối trước khi bạn có cơ hội cảnh báo họ.

# Trên FRR: phát hiện route không hợp lệ mà không loại bỏ chúng
sudo vtysh -c "show bgp ipv4 unicast" | grep "invalid"

Đặt Nhắc Nhở Hết Hạn ROA

ROA có thời hạn. Hầu hết các RIR mặc định khoảng thời gian hiệu lực 1-2 năm. Đáng để đặt nhắc nhở lịch 30 ngày trước khi hết hạn — ROA hết hạn biến prefix của bạn thành notfound, và các router chạy lọc nghiêm ngặt có thể bắt đầu từ chối thông báo của bạn.

Kiểm Tra Những Gì Upstream Của Bạn Đang Làm

Đáng để biết liệu ISP hoặc IXP upstream của bạn có thực sự lọc các route INVALID hay không. Kiểm tra isbgpsafeyet.com hoặc bảng thống kê RPKI của APNIC để tìm hiểu. Nếu họ không lọc, công việc ROV của bạn bảo vệ phần còn lại của internet khỏi các route giả mạo tuyên bố đến từ bạn. Nó không bảo vệ bạn khỏi các route bị chiếm đoạt đến qua các upstream đó.

Validator Dự Phòng Quan Trọng

Routinator bị dừng sẽ không ngay lập tức phá vỡ routing của bạn — hành vi mặc định của FRR khi mất kết nối RTR là đánh dấu tất cả route là notfound, không phải invalid. Kết nối vẫn duy trì. Tuy nhiên, hãy chạy ít nhất hai validator để đảm bảo khả năng phục hồi:

rpki
  rpki cache 127.0.0.1 3323 preference 1
  rpki cache 192.168.1.10 3323 preference 2
  exit

Theo Dõi Mức Độ Áp Dụng RPKI Toàn Cầu

Tính đến năm 2025, hơn 40% route toàn cầu có ROA coverage — tăng từ khoảng 10% vào năm 2020. Xu hướng đó quan trọng. Càng nhiều mạng triển khai ROV, BGP hijacking càng trở nên khó khăn hơn trên toàn diện, không chỉ cho bạn. Cloudflare Radar, bảng thống kê RIPE NCC và HTTP API của Routinator đều cung cấp cho bạn khả năng hiển thị vào số lượng valid/notfound/invalid trên bảng routing toàn cầu.

Công việc ban đầu là thực: đăng ký ROA, khởi động validator, điều chỉnh chính sách lọc. Hãy dành vài giờ. Sau đó, bạn chủ yếu chỉ gia hạn ROA mỗi một hoặc hai năm một lần. Điều bạn nhận lại là sự bảo vệ thực sự chống lại một lớp tấn công mà BGP đã bỏ ngỏ hơn 35 năm. Đây là sự đánh đổi xứng đáng.

Share:
Tags: