- Nhiều lần rò rỉ tuyến BGP (route leak) đã xảy ra trong mạng CANTV (AS8048) của Venezuela, khiến một số đường đi mạng bị lan truyền bất thường
- Theo dữ liệu từ Cloudflare Radar, đã xác nhận 11 sự kiện rò rỉ kể từ tháng 12, và nhiều khả năng đây là lỗi kỹ thuật do chính sách định tuyến chưa đầy đủ
- Vụ việc này diễn ra theo cách AS8048 chuyển tiếp lại các tuyến nhận từ nhà cung cấp AS6762 (Sparkle) sang một nhà cung cấp khác là AS52320 (V.tal GlobeNet), một cấu trúc rò rỉ hairpin Type 1 điển hình
- Xác thực nguồn gốc tuyến (ROV) dựa trên RPKI không hiệu quả trong trường hợp này, và cần các tiêu chuẩn mới như ASPA (Autonomous System Provider Authorization) và RFC9234 để ngăn chặn những vụ rò rỉ như vậy
- Do cấu trúc dựa trên niềm tin của BGP, các sự cố kiểu này xảy ra khá thường xuyên, và việc áp dụng các công nghệ như ASPA, Peerlock, RFC9234 là then chốt để vận hành Internet an toàn
Khái niệm rò rỉ tuyến BGP
- BGP (Route Gateway Protocol) là giao thức trao đổi đường đi giữa các hệ tự trị (AS) trên Internet
- Quan hệ giữa các mạng được tổ chức theo dạng khách hàng-nhà cung cấp (customer-provider) hoặc peer (peer-peer)
- Rò rỉ tuyến (route leak) được RFC7908 định nghĩa là “sự lan truyền thông tin định tuyến vượt ra ngoài phạm vi dự kiến”
- Ví dụ: khách hàng phát tán lại cho một nhà cung cấp khác các tuyến mà họ nhận được từ nhà cung cấp
- Những vụ rò rỉ như vậy là hành vi vi phạm quy tắc định tuyến valley-free, khiến lưu lượng đi theo các đường đi bất thường
- Kết quả là phát sinh các vấn đề như tắc nghẽn mạng, độ trễ và mất lưu lượng
Trường hợp rò rỉ tuyến của AS8048 (CANTV)
- Cloudflare Radar xác nhận rằng AS8048 (CANTV) đã chuyển tiếp sang AS52320 (V.tal GlobeNet) các tuyến mà họ nhận từ AS6762 (Sparkle)
- Đây là một dạng rò rỉ tuyến rõ ràng
- Nguồn gốc của tuyến bị rò rỉ là AS21980 (Dayco Telecom), một mạng khách hàng của AS8048
- Quan hệ giữa hai AS này được xác nhận là quan hệ nhà cung cấp-khách hàng qua dữ liệu của Cloudflare Radar và bgp.tools
- Trên đường đi có AS8048 được prepend nhiều lần
- Prepend là kỹ thuật làm cho đường đi kém hấp dẫn hơn để hướng lưu lượng sang đường khác
- Vì vậy, khả năng đây là một cuộc MITM (tấn công trung gian) có chủ đích là thấp
- Rò rỉ xảy ra nhiều lần trong khoảng 15:30~17:45 UTC ngày 2 tháng 1 năm 2026, và có khả năng là hiện tượng do lỗi chính sách mạng hoặc vấn đề hội tụ
- Theo ghi nhận của Cloudflare Radar, đã có 11 vụ rò rỉ tương tự kể từ tháng 12, cho thấy đây là tình trạng thiếu sót chính sách kéo dài
Nguyên nhân kỹ thuật và vấn đề chính sách
- Có khả năng AS8048 đã cấu hình lỏng lẻo chính sách export định tuyến đối với nhà cung cấp AS52320
- Nếu chỉ dùng prefix list dựa trên IRR thay vì thẻ BGP community của khách hàng, có thể xảy ra việc chuyển tiếp nhầm các tuyến sai
- Những lỗi chính sách như vậy có thể được ngăn chặn bằng thuộc tính Only-to-Customer (OTC) của RFC9234
- OTC xác định rõ vai trò BGP (khách hàng, nhà cung cấp, peer) để chặn việc lan truyền tuyến sai
Vai trò của RPKI và ASPA
- Sparkle (AS6762) chưa triển khai đầy đủ RPKI Route Origin Validation (ROV),
- nhưng vụ việc này là một bất thường về đường đi (path) nên không thể ngăn bằng ROV
- ASPA (Autonomous System Provider Authorization) cung cấp cơ chế xác thực dựa trên đường đi
- Mỗi AS khai báo danh sách các nhà cung cấp cấp trên được ủy quyền, từ đó tự động chặn các đường đi bất thường
- Ví dụ: nếu AS6762 khai báo “không có nhà cung cấp cấp trên”, các mạng khác có thể từ chối những đường đi sai có chứa AS6762
- ASPA hoạt động dựa trên RPKI và có hiệu quả trực tiếp trong việc ngăn chặn rò rỉ tuyến
Đề xuất để xây dựng BGP an toàn
- BGP về bản chất là một giao thức dựa trên niềm tin, nên rò rỉ do lỗi chính sách hoặc sai sót xảy ra thường xuyên
- Nếu áp dụng song song các công nghệ như ASPA, RFC9234, Peerlock/Peerlock-lite
- tăng cường xác thực đường đi
- chặn lan truyền các tuyến sai
- cải thiện độ ổn định của mạng
- RIPE hiện đã hỗ trợ tạo đối tượng ASPA,
- và các nhà vận hành nên gửi yêu cầu triển khai RFC9234 tới các nhà cung cấp thiết bị mạng
- Việc áp dụng các tiêu chuẩn mang tính hợp tác như vậy là biện pháp then chốt để phòng ngừa các sự cố BGP như trường hợp Venezuela
1 bình luận
Ý kiến trên Hacker News
Diễn biến bình luận ở đây hơi bất ngờ. Mọi người đều nói về nỗi sợ đối với các công ty Mỹ, nhưng có vẻ không liên quan nhiều đến nội dung bài viết
Bài của Cloudflare chỉ đơn giản giải thích cách BGP hoạt động và chỉ ra rằng rò rỉ tuyến từ ISP ở Venezuela đã xảy ra khá thường xuyên
Tất nhiên Cloudflare có thể sai hoặc đang che giấu điều gì đó, nhưng không có chỗ nào trong bài nói rằng họ đã trực tiếp can thiệp. Không rõ mọi người dựa vào đâu mà lại chắc chắn như vậy
Tuy vậy, nhìn vào các vụ Stuxnet hay Dual EC DRBG thì không nên đánh giá thấp khả năng chính phủ tận dụng 0-day
Bạn tôi từng làm ở một công ty FANG và nói rằng đã thấy họ cung cấp trực tiếp luồng dữ liệu cho chính phủ. Backdoor ở ISP cũng là chuyện có thật (Room 641A)
Nếu Cloudflare đã hợp tác theo lệnh của tòa, liệu họ có thể viết một bài phủ nhận điều đó về mặt pháp lý không?
Vì thế tôi nghĩ sự hoài nghi cơ bản của mọi người là có cơ sở. Kết luận của Cloudflare rằng “đây là vấn đề cũ nên không có gì to tát” nghe hơi yếu
Tôi cũng muốn biết liệu trong cấu trúc BGP có lý do nào khiến Mỹ làm chuyện này dễ hơn các nước khác không
Dạo này dư luận về chính phủ Mỹ vốn đã rất hoài nghi, nên cả sự cố nhỏ cũng dễ bị nghi ngờ
Hoặc cũng có thể chỉ là tài khoản xã hội của Nga hay Trung Quốc, nhưng ai mà biết được
Ngoài ra, bài CNN nói rằng Trump đã nhắc tới khả năng hành động quân sự cả với đồng minh
Với chính quyền hiện tại thì tôi còn nghĩ họ sẽ công khai khoe kiểu tấn công này. Nên hiện giờ tôi vẫn nghiêng về khả năng “lỗi cấu hình đơn thuần”
Dù vậy, việc người ta ngày càng mất niềm tin cũng là điều tự nhiên khi mỗi lần Mỹ xuất hiện trên tin tức lại là đe dọa, rút lui hoặc trừng phạt
Tôi đang buồn ngủ nhưng vẫn thấy bài viết rất thú vị. Phân tích AS path prepending củng cố khá tốt giả thuyết “tai nạn”
Nếu một quốc gia muốn chặn bắt lưu lượng, sẽ không có lý do gì để cố tình làm đường đi dài hơn
Khả năng cao chỉ là một lỗi cấu hình định tuyến đơn thuần. BGP vẫn là một hệ thống dựa trên niềm tin nên chỉ một lỗi gõ nhỏ cũng có thể ảnh hưởng toàn cầu
Bộ lọc export bị thiếu nghe hợp lý hơn là ác ý
Trên thực tế cũng có tác nhân phi nhà nước thao túng lưu lượng quảng cáo
Dù vậy, từ góc độ vận hành mạng thì những lỗi kiểu này rất thường gặp, và các script điều chỉnh lưu lượng tự động đôi khi còn làm vấn đề tệ hơn
Cuối cùng, vấn đề vẫn là lỗ hổng cấu trúc của BGP. Bảo mật và BGP đến giờ vẫn là hai từ khó đi cùng nhau
Một tài liệu đáng tham khảo là NSA Network Shaping 101, một trong các tài liệu Snowden
Đây là tài liệu viết năm 2007, giải thích về ASIN và điều khiển lưu lượng lớp 3
Nó chỉ ở mức giải thích cấu trúc mà lưu lượng gửi tới một IP cụ thể sẽ đi qua liên kết đó
Sau khi đọc bài, tôi lại thấy rợn người vì mức độ gắn kết giữa doanh nghiệp Mỹ và chính phủ sâu đến mức nào
Đây là điều tôi vốn đã biết từ trước, nhưng lần này có cảm giác niềm tin đã sụp đổ hoàn toàn. Nó giống như một bước ngoặt của thời đại
Loại hạ tầng giám sát này đã tồn tại từ rất lâu, và Nhật Bản cũng từng giám sát lưu lượng thời gian thực vào năm 2003
Giờ đây công nghệ DPI đã quá dễ để triển khai
Người mới vào ngành thường bắt đầu rất ngây thơ, rồi cuối cùng cũng nhận ra cấu trúc gắn bó chặt chẽ giữa chính phủ và doanh nghiệp và mất niềm tin
Một thời gian sau lại có thế hệ mới lặp lại đúng quá trình đó
Ý chính của bài là Hanlon’s razor, tức là nên nghi ngờ sai sót trước khi nghi ngờ ác ý
Tất nhiên nếu Cloudflare bóp méo sự thật thì họ đáng bị chỉ trích, nhưng hiện vẫn chưa có bằng chứng nào như vậy
Nghĩ tới hạ tầng cũ kỹ của Venezuela thì tôi tự hỏi liệu có cần đến một cuộc tấn công mạng cao cấp hay không
Thực tế là các nhà thầu tham nhũng đã bàn giao những hệ thống tồi tệ
So với tấn công mạng thì cấu trúc tham nhũng mới là vấn đề lớn hơn nhiều
Cuối cùng tôi phải đưa tiền cho một kỹ thuật viên đang làm ngoài đường để giải quyết, mà số điện thoại đó lại là số của một hãng taxi
Trong môi trường như vậy, bàn về tấn công BGP nghe hơi vô nghĩa
Bài này là một màn ôn lại BGP khá hay
Hồi còn làm kỹ sư mạng, tôi dùng rất nhiều BGP community magic, và
nếu BGP chỉ biểu diễn ba loại là provider, customer và peer thì có lẽ mọi thứ đã đơn giản hơn nhiều
Cũng giống như trên Google Maps, nếu bỏ dữ liệu giao thông hay đèn tín hiệu thì tính toán sẽ dễ hơn nhưng kết quả lại tệ hại
Trước đây Google Maps từng dẫn tôi từ đường cao tốc vào bãi đỗ xe Walmart rồi vòng sang một đường cao tốc khác
Khi đó tôi nghĩ chỉ là lỗi thuật toán, nhưng nếu nó dẫn tôi qua drive-thru của McDonald’s thì chắc tôi đã nghi là có âm mưu
Vụ này cũng tương tự, nhìn theo hướng lỗi đơn thuần có vẻ thuyết phục hơn
Tôi thấy hơi đáng sợ khi hạ tầng cốt lõi của Internet lại được vận hành chủ yếu bởi các công ty Mỹ
Có lẽ giờ các nước khác cũng nên xây dựng những cấu trúc độc lập
Vậy thì ai mới nên là người quản lý thay thế?
Tôi đã quan sát các sự cố BGP từ lâu và luôn cảm thấy rất khó phân biệt giữa thay đổi có chủ đích, sai sót và sự cố cấu trúc
Vì vậy tôi thường đặt trước ba câu hỏi: phạm vi ảnh hưởng có tăng dần không, đường đi có thay đổi đối xứng không, và quá trình khôi phục có gọn gàng không
Rồi tôi xem trước các thay đổi trong AS-path prepending và so sánh mức độ quan sát được theo từng khu vực
Cuối cùng tôi truy dấu xem “ai là người hưởng lợi”. Tôi tò mò không biết người khác dùng chỉ số nào để phát hiện vấn đề
Độ phủ toàn cầu của Cloudflare thực sự rất ấn tượng
Dù vậy, họ là một tổ chức thiên về kỹ thuật, nên rất giỏi công khai những phân tích như thế này