An toàn thông tin

Các vấn đề và giải pháp đảm bảo an toàn định tuyến trên Internet

Phan Xuân Dũng, Nguyễn Xuân Trường • 06/06/2024 11:00

Ngày nay, mạng Internet có mặt ở khắp mọi nơi và là một phần không thể thiếu trong cuộc sống hiện đại.

“
Tóm tắt:
- Tìm hiểu về giao thức định tuyến dữ liệu (BGP):
+BGPlàgì?
+ Vai trò của BGP đối với Internet;
+ BGP hoạt động như thế nào?
- Các vấn đề an toàn định tuyến BGP.
- Một số giải pháp giảm thiểu rủi ro trong định tuyến.

Internet có thể nói là một kho chứa đựng những kiến thức khổng lồ, thế giới giải trí, phương tiện kết nối mọi người, mua sắm trực tuyến, làm việc… Border Gateway Protocol (BGP) là một giao thức định tuyến liên mạng được thiết kế để kết nối các hệ thống tự trị (AS) trên Internet, giúp xác định đường đi tốt nhất cho gói tin khi đi qua các mạng này. Việc đảm bảo an toàn thông tin (ATTT) cho BGP có vai trò đặc biệt quan trọng để đảm bảo truy cập an toàn.

BGP là gì?

Giao thức BGP là giao thức được thiết kế để trao đổi thông tin định tuyến giữa các hệ thống tự trị (AS) trên Internet. BGP có khả năng mở rộng đáng kết với việc hỗ trợ quản lý hàng triệu dải tiền tố IP (prefix) kèm theo hàng triệu tuyến đường (path) trong bảng định tuyến Internet toàn cầu.

Ngoài ra, BGP được phân chia làm 02 loại: internal BGP (iBGP) là BGP được triển khai và thực hiện trao đổi thông tin định tuyến giữa các thiết bị nằm trong cùng một hệ thống tự trị (AS) mà không cần chia sẻ với các AS khác; external BGP (eBGP) là BGP được triển khai để kết nối giữa các AS khác nhau cho phép các AS có thể sử dụng đa hướng kết nối (multi-homing) dẫn đến tăng độ linh hoạt và tính dự phòng cho mạng lưới. Phiên bản hiện tại của BGP là phiên bản 4 (BGP4), được tiêu chuẩn hóa theo RFC 4271 vào năm 2006. BGP hỗ trợ thiết lập chính sách định tuyến giúp quản lý và kiểm soát lưu lượng mạng bằng việc sử dụng các thuộc tính. Trong BGP được quy ước 4 nhóm thuộc tính (attribute):

- Well-known mandatory: thiết bị định tuyến chạy BGP phải biết và xử lý được attribute này. Các thuộc tính loại này luôn được gửi ra cùng với route khi update.

- Well-known discretionary: thiết bị định tuyến chạy BGP phải biết và xử lý được attribute này. Các thuộc tính loại này có thể có hoặc không được gửi ra cùng với route khi update.

- Optional nontransitive: thiết bị định tuyến chạy BGP có thể không cần xử lý attribute này, và không gửi attribute này ra peer khi quảng bá route.

- Optional transitive: thiết bị định tuyến chạy BGP có thể không cần xử lý attribute này, nhưng phải gửi attribute này nếu route nhận được có attribute này.

Vai trò của BGP với Internet

Giao thức BGP vận hành hoạt động của Internet thông qua định tuyến dữ liệu. Định tuyến BGP rất quan trọng vì bản chất Internet được tạo thành từ hàng trăm nghìn ASN. Mỗi ASN là một mạng nhỏ được quản lý cấp phát bởi IANA và các tổ chức vùng hoặc quốc gia. Dữ liệu di chuyển giữa các ASN từ nguồn đến đích. BGP hỗ trợ ASN các hoạt động sau:

- Tìm tuyến tốt nhất
- Khám phá các thay đổi kết nối mạng - Quản trị các chính sách định tuyến.

BGP hoạt động như thế nào?

BGP thuộc họ giao thức path vector, trong đó thông tin định tuyến được trao đổi quan trọng nhất là các tiền tố địa chỉ IP (prefixes) và các tuyến đường phải đi qua để đến đích (path). Thông tin được trao đổi được gọi là thông tin về khả năng tiếp cận lớp mạng (NLRI). Để hai thiết bị định tuyến có thể trao đổi NLRI thì chúng phải kết nối ngang hàng với nhau (peering) bằng cách thiết lập phiên làm việc trên giao thức TCP.

Đầu tiên, một trong hai thiết bị định tuyến (client) để khởi tạo kết nối bằng cách gửi gói TCP SYN đến thiết bị định tuyến còn lại (server) với cổng nguồn ngẫu nhiên và cổng đich là 179. Tiếp theo, server nhận được gói tin TCP SYN sẽ phản hồi lại gói tin SYN ACK với cổng nguồn là 179 và cổng đích là giá trị cổng khởi tạo ban đầu ở bước thứ nhất. Cuối cùng, client sau khi nhận được gói tin SYN ACK sẽ phản hồi lại gói tin ACK với phía server.

Hình 1: Quá trình thiết lập phiên BGP

Giai đoạn thiết lập phiên BGP bao gồm việc trao đổi các bản tin điều khiển BGP. Các bản tin này là OPEN, KEEPALIVE, NOTIFICATION và UPDATE. Các bản tin này được gửi và nhận ở ba trạng thái cuối cùng của BGP: Opensent, Openconfirm và Established. Ở trạng thái Opensent, thiết bị định tuyến chạy BGP đã gửi bản tin OPEN tới thiết bị ngang hàng của đối tác và đang chờ phản hồi bằng bản tin OPEN. Khi điều này xảy ra, trạng thái sẽ chuyển sang trạng thái Openconfirm trong đó thiết bị định tuyến chạy BGP so sánh các thuộc tính trong bản tin OPEN của thiết bị đối tác với thuộc tính của chính nó. Nếu các điều khoản được chấp nhận, thiết bị định tuyến chạy BGP sẽ phản hồi bằng bản tin KEEPALIVE và trạng thái sẽ chuyển sang Established.

Sau đó, các bản tin UPDATE được gửi để trao đổi thông tin về NRLI và phiên kết nối này được duy trì bằng việc gửi các bản tin KEEPALIVE 19 byte mỗi 60 giây (mặc định) để xác minh thiết bị của đối tác ngang hàng vẫn hoạt động. Bản tin NOTIFICATION được gửi ở cả ba trạng thái để chỉ ra tình trạng lỗi.

Ví dụ: nếu trong bản tin OPEN chứa tham số không được chấp nhận, bản tin NOTIFICATION sẽ được gửi với bản chất chính xác của lỗi và trong hầu hết các trường hợp, trạng thái của phiên sẽ chuyển trở lại Idle. Đối với việc thiết lập phiên BGP, bản tin OPEN là quan trọng nhất.

Như đã đề cập, ở trạng thái Openconfirm, mỗi thiết bị định tuyến chạy BGP sẽ gửi một bản tin OPEN chứa các thuộc tính cục bộ của nó để xây dựng mối quan hệ BGP. Có sáu tham số chính có trong bản tin OPEN: phiên bản BGP đang sử dụng, số hiệu mạng (ASN), hold timer của thiết bị định tuyến, mã định danh BGP của thiết bị định tuyến và các tham số tùy chọn mà thiết bị định tuyến hỗ trợ.

Sau khi thiết lập thành công phiên BGP, thiết bị định tuyến sẽ nhận thông tin định tuyến qua các BGP Peer vào bảng định tuyến đầu vào (Adj- RIB-In) và qua bộ lọc chính sách định tuyến đầu vào để đưa vào bảng định tuyến BGP, các tuyến đường tốt nhất sẽ được chuyển sang bảng định tuyến nội bộ của thiết bị và thông qua bộ lọc chính sách định tuyến đầu ra để đưa vào bảng định tuyến đầu ra (Adj-RIB-Out) và gửi cho các BGP Peer.

Hình 2: Quá trình xử lý định tuyến của thiết bị định tuyến

Các vấn đề an toàn định tuyến BGP và ví dụ thực tế

Như chúng ta biết về hoạt động của giao thức BGP ở trên, BGP phiên bản 4 (RFC 4271) giải quyết các nhu cầu về kết nối và khả năng mở rộng nhưng không cân nhắc đến vấn đề bảo mật vì BGP được xây dựng dựa trên sự tin cậy và không có tích hợp an toàn trong thiết kế cũng như không có sự xác nhận tính hợp lệ các địa chỉ IP và AS. Các vấn đề bảo mật được chia làm hai loại: liên quan đến giao thức của BGP và liên quan đến thông tin mà BGP xử lý.

Đầu tiên, BGP không có cơ chế nội bộ để bảo vệ tính toàn vẹn và tính xác thực và bảo mật đối với bản tin BGP từ đó dẫn đến các cuộc tấn công có thể được thực hiện bằng cách khai thác các bản tin TCP hoặc BGP. Như đã đề cập ở trên, BGP sử dụng TCP/IP 179 nên nó có nguy cơ tấn công DoS/DDoS khi kẻ tấn công có thể gửi các bản tin TCP SYN làm quá tải thiết bị định tuyến, hoặc TCP RESET hoặc IP giả mạo để ngắt phiên BGP giữa các BGP speaker.

Đây cũng là điểm yếu của giao thức BGP khi không có cơ chế xác thực để reset phiên BGP như gửi các bản tin OPEN để reset các phiên BGP ở trạng thái Active, các bản tin KEEPALVIE không đồng bộ, hoặc gửi bản tin NOTIFICATION để reset ngắt phiên BGP như một hình thức tấn công DoS/DDoS. Kẻ tấn công có thể gửi các gói tin giả mạo có trong các bản tin Update, Route Refressh tới các BGP Speaker chứa các thông tin định tuyến sai lệch hoặc làm quá tải năng lực xử lý. Tiếp theo, BGP không có cơ chế nào để xác thực quyền của AS được phép quảng bá địa chỉ IP cũng như cơ chế xác minh tính xác thực của các thuộc tính trong bản tin cập nhật BGP.

Từ vấn đề trên sẽ dẫn đến nguy cơ bất kỳ AS nào cũng có thể quảng bá bất kỳ địa chỉ IP nào hay bất kỳ AS nào cũng có thể thêm bất kỳ ASN nào vào đường dẫn AS. Đây là vấn đề đang xảy ra phổ biến trên định tuyến Internet toàn cầu và được đề cập với tên gọi: BGP Hijack và BGP Route Leak.

BGP Hijack có thể được chia thành hai loại: Tấn công lỗ đen và tấn công đánh chặn. Sự khác biệt giữa cả hai loại này dựa trên cách thức lượng bị tấn công. Trong các cuộc tấn công hố đen, lưu lượng truy cập đến dịch vụ bị tấn công sẽ giảm và thu hút về nguồn quảng bá (lỗ đen). Ngược lại, cuộc tấn công đánh chặn thay vì loại bỏ các gói tin thì vẫn chuyển tiếp chúng đến đích ban đầu tuy nhiên kẻ tấn công sẽ đứng ở giữa (Man in the midle) để có thể đọc và thay đổi thông tin gói tin.

Một ví dụ nổi bật về tấn công lỗ đen là cuộc tấn công dịch vụ của Youtube ở Pakistan. Đây cũng là một ví dụ điển hình cho thấy ngay cả việc vô tình cấu hình sai cũng có thể gây ra tác hại lớn. Năm 2008, Chính phủ Pakistan lên kế hoạch chặn dịch vụ của Youtube trên toàn quốc đã chỉ thị cho Pakistan Telecom thực hiện việc này. Họ đã cố gắng quảng bá tiền tố IP cụ thể hơn tiền tố IP mà Youtube đang quảng bá và bằng cách này đã thu hút phần lớn lưu lượng truy cập đến dịch vụ của Youtube từ Pakistan đến lỗ đen tại mạng của Pakistan Telecom.

Hình 3: Minh họa cuộc tấn công lỗ đen của Pakistan Telecom với dịch vụ Youtube (Nguồn: NANOG)

Pakistan Telecom đã quảng bá dải địa chỉ 208.65.153.0/24 của Youtube với origin AS là 17557. Như đã đề cập ở trên, vì cơ chế ưu tiên độ dài của tiền tố IP nên /24 đã được lựa chọn thay vì /22 trên các thiết bị định tuyến. Do đó lưu lượng truy cập đến dịch vụ của Youtube bị điều hướng về lỗ đen trên mạng của Pakistan Telecom.

Khả năng ảnh hưởng của cuộc tấn công này đúng ra phải nằm trong phạm vi Pakistan, tuy nhiên vì sai sót trong cấu hình phiên kết nối giữa Pakistan Telecom và PCCW, một upstream cấp cao nhất (tier 1) dẫn đến dải địa chỉ 208.65.153.0/24 được quảng bá rộng rãi ra môi trường Internet toàn cầu. Cuộc tấn công này đã khiến dịch vụ của Youtube ngừng hoạt động trong khoảng hai giờ và chỉ được xử lý khi Youtube thực hiện quảng bá lại vùng địa chỉ IP cụ thể tương đương và PCCW chặn quảng bá sai đến từ Pakistan Telecom.

Một ví dụ khác về BGP Hijack nhưng thuộc kiểu tấn công đánh chặn là cuộc tấn công mạng DNS thuộc AWS để trộm tiền điện tử xảy ra vào tháng 4 năm 2018. Kẻ tấn công đã tấn công chiếm đoạt địa chỉ IP của Amazon nơi đặt dịch vụ phân giải tên miền (DNS) cho tên miền MyEtherWallet. com. Kết quả là nhiều khách hàng đã bị chuyển hướng truy cập trang web giả mạo được đặt tại Nga và bị đánh cắp tiền điện tử etherum trị giá 150.000 USD.

BGP Route Leaks là rò rỉ định tuyến BGP khi việc quảng bá các tuyến đường BGP vượt quá phạm vi của AS đó hoặc có thể hiểu là quảng bá không đúng với chính sách định tuyến và đã được đề cập trong RFC7908. Các nguyên nhân dẫn đến lỗi trên như xuất phát từ lỗi con người, lỗi cấu hình hay lỗi lọc định tuyến giữa các BGP Peer dẫn đến định tuyến không chính xác hoặc không tối ưu. Phạm vi định tuyến thường được xác định cụ thể là các chính sách định tuyến giữa các miền dựa trên mối quan hệ giữa các hệ thống tự trị. Các mối quan hệ này được phân loại thành ba loại: khách hàng, nhà cung cấp dịch vụ chuyển tiếp và ngang hàng.

Hình 4: Minh họa các mối quan hệ trong định tuyến (Nguồn: Cloudflare)

Trong mối quan hệ khách hàng - nhà cung cấp dịch vụ, AS của khách hàng có thỏa thuận với mạng của nhà cung cấp dịch vụ để chuyển tiếp lưu lượng truy cập của nó đến Internet toàn cầu. Trong mối quan hệ ngang hàng, hai AS đồng ý trao đổi lưu lượng song phương trong phạm vi hai mạng hay trong một số trường hợp sẽ bao gồm cả mạng khách hàng của hai AS đó. Trong RFC7908 định nghĩa ra các trường hợp rò rỉ định tuyến BGP như sau:

- Trường hợp 1: “Nhà cung cấp dịch vụ - Khách hàng - nhà cung cấp dịch vụ” hiểu đơn giản là khi một AS có kết nối multihomed học được prefix từ một nhà cung cấp dịch vụ sẽ quảng bá lại cho nhà cung cấp dịch vụ khác. Đây là loại rò rỉ định tuyến được biết đến nhiều nhất và có tác động rất lớn. Trong nhiều trường hợp, kênh đi qua mạng khách hàng được ưu tiên hơn kênh ngang hàng hoặc kênh của nhà cung cấp.

Hình 5: Minh họa về rò rỉ định tuyến trường hợp 1

Trong minh hoạt trên, ISP-01 có thể ưu tiên lưu lượng truy cập đến ISP-02 qua Customer thay vì các kênh ngang hàng hoặc kênh của nhà cung cấp khác, khiến Customer vô tình trở thành mạng chuyển tiếp lưu lượng. Điều này có thể ảnh hưởng đáng kể đến hiệu suất của lưu lượng truy cập liên quan đến các prefix bị rò rỉ hoặc gây ra tình trạng ngừng dịch vụ khi lưu lượng lớn hơn khả năng xử lý của mạng Customer. Ví dụ thực tế, vào ngày 01/08/2022, Akamai là một nhà cung cấp dịch vụ mạng phân phối nội dung và điện toán đám mây của Hoa Kỳ đã làm rò rỉ 660 tuyến mạng của 203 đơn vị (ASN) thuộc 58 quốc gia và thời gian sự cố kéo dài 3 giờ 9 phút.

- Trường hợp 2: “Nhà cung cấp dịch vụ - nhà cung cấp dịch vụ – nhà cung cấp dịch vụ” là trường hợp nhà cung cấp dịch vụ làm rò rỉ định tuyến giữa các BGP peer với nhà cung cấp dịch vụ khác khiến quan hệ “ngang hàng” vô tình chuyển thành quan hệ “khách hàng”. Trường hợp này ít khi xảy ra tình trạng nghẽn mạng nhưng có thể làm tăng độ trễ mạng và ảnh hưởng đến chất lượng dịch vụ của nhà mạng khác.

Hình 6: Minh họa về rò rỉ định tuyến trường hợp 2

- Trường hợp 3: “Nhà cung cấp – Ngang hàng” là trường hợp nhà cung cấp dịch vụ sau khi nhận được prefix từ hướng upstream quảng bá tiếp cho đối tác khác trong mối quan hệ thiết lập là ngang hàng dẫn đến lưu lượng transit bị đi vòng sang hướng peering. Trường hợp này có mức độ ảnh hưởng tương tự trường hợp trên.

Hình 7: Minh họa về rò rỉ định tuyến trường hợp 3

- Trường hợp 4: “Ngang hàng - Nhà cung cấp” là trường hợp trái ngược với trường hợp vừa đề cập ở trên, nhà cung cấp dịch vụ sau khi nhận được prefix từ hướng peering quảng bá tiếp cho upstream dẫn đến lưu lượng chiều về từ Internet sẽ vòng sang hướng peering. Trường hợp này có thể làm tăng độ trễ mạng và ảnh hưởng đến chất lượng dịch vụ của nhà mạng.

Hình 8: Minh họa về rò rỉ định tuyến trường hợp 4

Một số giải pháp giảm thiểu rủi ro trong định tuyến

Trước tiên, để bảo vệ an toàn BGP cần bảo vệ thiết bị định tuyến BGP (BGP Speaker) và phiên BGP (BGP Session). Việc tấn công chiếm đoạt quyền điều khiển thiết bị định tuyến rất khó xảy ra khi địa chỉ IP quản trị thiết bị đặt trong phân mạng có tính bảo mật cao, có các lớp tường lửa để bảo vệ. Các kênh kết nối cần sử dụng kết nối trực tiếp (connected) khi thiết lập phiên eBGP giữa các AS và thiết lập các chính sách kiểm soát truy cập trên thiết bị định tuyến. Điều này sẽ hạn chế việc các gói tin điều khiển bị chặn lọc trong cùng broadcast domain cũng như các gói tin giả mạo đến từ các đối tác không mong muốn.

Ngoài ra, BGP authentication là một giải pháp được sử dụng để bảo mật việc trao đổi thông tin định tuyến giữa các thiết bị định tuyến chạy BGP, thường là giữa các hệ thống tự trị (AS). Nó đảm bảo rằng các cập nhật BGP trao đổi giữa các thiết bị định tuyến đến từ nguồn tin cậy và không bị thay đổi trong quá trình truyền tải. BGP authentication thường được triển khai bằng cách sử dụng một cơ chế đơn giản bằng việc sử dụng một mật khẩu, được gọi là khóa xác thực BGP được chia sẻ giữa các thiết bị định tuyến đối tác. Khi thiết bị định tuyến thiết lập một phiên BGP sẽ trao đổi mật khẩu này và các bản tin BGP tiếp theo được xác thực bằng cách sử dụng mật khẩu được đã được thống nhất.

Các thiết bị định tuyến sử dụng BGP authentication sẽ chứa một giá trị hàm băm (hash) của mật khẩu được chia sẻ. Thiết bị định tuyến sẽ tính toán giá trị băm bằng cách sử dụng bản tin đã nhận và bản sao của mật khẩu được chia sẻ của nó. Nếu giá trị băm tính toán khớp với giá trị nhận được trong bản tin được coi là được xác thực. Ngược lại, nếu một thiết bị định tuyến nhận được một bản tin BGP với giá trị hàm băm xác thực không chính xác hoặc không bật xác thực, nó có thể loại bỏ bản tin hoặc thực hiện hành động phù hợp dựa trên cấu hình đã được người quản trị thiết lập.

Tiếp theo, để xác thực thông tin định tuyến trong quảng bá BGP cần sử dụng các cơ sở dữ liệu về thông tin định tuyến, các giải pháp mã hóa bổ sung trong BGP để thiết lập các chính sách lọc định tuyến cho phù hợp nhằm giảm thiểu BGP Hijack hay BGP Route leak. IRR là cơ sở dữ liệu thông tin định tuyến được phân phối trên toàn cầu. Được thành lập vào năm 1995, mục đích của IRR là đảm bảo tính ổn định và nhất quán của việc định tuyến trên toàn Internet bằng cách chia sẻ thông tin giữa các nhà khai thác mạng. IRR thực sự bao gồm một số cơ sở dữ liệu nơi các nhà khai thác mạng công bố chính sách định tuyến và thông báo định tuyến của họ để các nhà khai thác mạng khác có thể sử dụng dữ liệu này. IRR và cho phép các nhà khai thác Internet:

- Gỡ lỗi các vấn đề định tuyến
- Tự động cấu hình bộ định tuyến đường trục - Thực hiện quy hoạch mạng IRR chứa các tuyến đường và chính sách định tuyến được công bố ở định dạng chung mà các nhà khai thác mạng có thể sử dụng để định cấu hình bộ định tuyến đường trục của họ. Điều này hỗ trợ quản lý mạng theo một số cách:

- Lọc tuyến đường: Lưu lượng truy cập có thể được lọc định tuyến dựa trên các tuyến đường đã đăng ký, ngăn ngừa sự cố mạng do các thông báo định tuyến vô tình hoặc độc hại gây ra. Lọc định tuyến cho biết định tuyến có thể được tạo giữa: Mạng ngang hàng nơi các peer đồng ý lọc định tuyến chỉ dựa trên các tuyến đường đã đăng ký. Nếu tuyến đường không được đăng ký, nó sẽ bị loại bỏ; Mạng của ISP và khách hàng nơi ISP bảo vệ mạng của mình khỏi các thông báo định tuyến vô tình của khách hàng. Khách hàng phải đăng ký tuyến đường của mình trước ISP.

-Khắc phục sự cố mạng: Giúp xác định các sự cố định tuyến bên ngoài mạng của bạn dễ dàng hơn. Sử dụng danh bạ của ASN được liên kết với tuyến đường có vấn đề để giải quyết các vấn đề về định tuyến lưu lượng.

-Cấu hình bộ định tuyến: Các công cụ như IRRToolset có thể tạo cấu hình bộ định tuyến. Kiểm tra các đối tượng ASN và các tuyến đường của chúng đăng ký. Thực hiện kiểm tra cú pháp RPSL trên ASN đã đăng ký trong IRR.

Điểm yếu chính của IRR không được quản lý thống nhất và phân mảnh tại nhiều tổ chức như APNIC, RIPE NCC, LACNIC, AFRNIC, RADB, Level3, NTT... theo thời gian dữ liệu cũ thường thiếu cập nhật và thông tin bị sai lệch. Kết quả là trong số tất cả thông tin về bản ghi định tuyến được công bố, rất khó để xác định đâu là dữ liệu hợp pháp, xác thực và đâu là dữ liệu

không. Để giải quyết vấn đề của IRR gặp phải, một giải pháp mới đã được giới thiệu và chuẩn hóa trong RFC6486 với tên gọi “RPKI”. Đây là công nghệ mã hóa tài nguyên Internet bao gồm địa chỉ IP, số hiệu mạng (ASN) thành một dạng dữ liệu mã hóa dựa trên các tiêu chuẩn chứng chỉ PKI (X.509) để có thể sử dụng trong xác thực thông tin định tuyến trên Internet. RPKI bao gồm hai quá trình chính:

-Khởi tạo dữ liệu bản ghi: Route Origin Authorization (ROA) là một bản ghi được mã hóa cho biết hệ thống mạng độc lập (Autonomous System) được uỷ quyền để sở hữu một dải địa chỉ IP. Một bản ghi ROA cung cấp 03 trường thông tin:

+ Prefix: dải địa chỉ IP mà hệ thống mạng độc lập sử dụng.

+ Origin ASN: số hiệu mạng gốc quảng bá dải địa chỉ IP đó.

+ Max length: kích thước tối đa của dải địa chỉ IP có thể quảng bá

- Xác thực thông tin nguồn gốc định tuyến: Route Origin Validation (ROV) là quá trình kiểm tra tính hợp lệ của thông tin định tuyến mạng dựa trên thông tin chứa trong các bản ghi ROA).

Hình 9: Nguyên lý hoạt động của RPKI

Hình 10: Minh họa về uỷ quyền trong RPKI

RPKI hoạt động bằng cách mã hóa thông tin tài nguyên Internet (IP,ASN) được cấp cho chủ sở hữu tài nguyên bằng việc sử dụng chứng chỉ PKI (X.509) hay còn gọi là việc khởi tạo bản ghi ROA. Điều này thể hiện quyền sở hữu và thông tin trạng thái khác liên quan đến tài nguyên Internet cụ thể. Khi sử dụng chứng chỉ RPKI, tài nguyên số Internet sẽ được liên kết với chữ ký số.

RPKI hoạt động bằng cách hình thành hệ thống phân cấp các chứng chỉ ký kết lẫn nhau. Chứng chỉ "gốc" ký trên chứng chỉ con và chứng chỉ con ký trên chứng chỉ con của chúng. Cơ quan đăng ký Internet khu vực (RIR) ký chứng chỉ cho thành viên trực tiếp và cho Cơ quan đăng ký Internet quốc gia (NIR). Bản ghi ROA cùng với chữ ký số sau đó được lưu trữ và phân phối trên mạng Internet thông qua các kho lưu trữ của các cơ quan quản lý Internet khu vực (RIR).

Nguyên lý hoạt động của ROV (Route Origin Validation) liên quan đến việc kiểm tra tính hợp lệ của thông tin định tuyến mạng dựa trên các bản ghi ROA trong hệ thống RPKI. Dưới đây là các bước và nguyên lý hoạt động cụ thể của ROV:

- Thu thập ROA: Trước tiên, hệ thống ROV cần thu thập các bản ghi ROA từ cơ sở dữ liệu RPKI. Các bản ghi ROA này chứa thông tin về địa chỉ IP được ủy quyền và chữ ký số tương ứng của chúng dựa trên giao thức RSYNC (TCP/873) hoặc RRDP, với mã định danh tài nguyên thống nhất (URI) được xác định bởi RFC5781.

- Xác thực chữ ký số: Hệ thống ROV sử dụng các chứng chỉ số từ các tổ chức Certificate Authority (CA) để xác thực tính hợp lệ của chữ ký số đính kèm trong các bản ghi ROA. Nếu chữ ký số được xác thực thành công, thông tin trong bản ghi ROA được coi là hợp lệ.- Gửi thông tin tài nguyên Internet đã được ký số đến thiết bị định tuyến qua giao thức RTR (TCP/8282).

- Kiểm tra tính hợp lệ của tuyến đường (route): Khi thiết bị định tuyến nhận được một route từ đối tác (thông qua giao thức BGP) sẽ kiểm tra với dữ liệu tài nguyên Internet đã được ký số để xác định trạng thái của tuyến đường đi này, biểu diễn như sau: Valid (hợp lệ), Invalid (không hợp lệ), Unknown (không tìm thấy dữ liệu).

Tuy nhiên, giải pháp này dễ dàng bị qua mặt khi kẻ tấn công sử dụng kỹ thuật “prepend as- path” khi thực hiện quảng bá định tuyến dù ban đầu đây là kỹ thuật được sử dụng để lái lưu lượng nhờ sự thay đổi độ dài của as-path trong quảng bá định tuyến. Do vậy, để giải quyết vấn đề này cần đến xác thực tuyến đường, được đề cập trong BGPSec – phần mở rộng của giao thức BGP.

Trong BGPSec, thuộc tính AS PATH được thay thế bằng thuộc tính BGPSec PATH để chứa thông tin bổ sung dưới dạng chữ ký. Mỗi chữ ký tương ứng với một số AS trong tuyến đường và do đó tuyến đường càng dài thì càng chứa nhiều chữ ký. Thiết bị định tuyến quảng bá tiền tố IP sẽ tạo chữ ký dựa trên thông tin về tiền tố IP được quảng bá, số hiệu mạng quảng bá và số hiệu mạng được chuyển tiếp bản tin UPDATE (số hiệu mạng của phiên kết nối ngang hàng BGP). Mặt khác, thiết bị định tuyến nhận bản tin UPDATE sẽ sử dụng chữ ký trước đó thay vì tạo mới, mỗi chữ ký này sẽ kèm theo một mã khóa định danh chủ thể (SKI).

Hình 11: Minh họa cơ chế hoạt động của BGPSec

Hình trên cho thấy một quá trình định tuyến sử dụng BGPSec trong đó AS1 quảng bá tiền tố IP là 203.119.0.0/24 và thiết bị định tuyến sẽ tạo chữ ký tương ứng với AS của nó. Khi AS2 nhận được bản tin UPDATE do AS1 gửi, nó xác thực tất cả các chữ ký trong khối chữ ký và sau đó gắn số AS của chính nó vào BGPSec path kèm một chữ ký mới vào khối chữ ký. Sau đó, nó chuyển tiếp bản tin UPDATE tới AS3.

Thiết bị định tuyến tại AS3 sau đó xác nhận lại thông tin. Vì hiện tại có hai chữ ký được chứa trong khối chữ ký nên bộ định tuyến tại AS3 phải xác thực hai chữ ký. Nó sẽ xét chữ ký gần nhất được thêm vào, trong ví dụ này là sig2. Để xác thực, thiết bị định tuyến ở AS3 thực hiện truy vấn chứng chỉ phù hợp với SKI2 và AS2. Nếu tìm thấy chứng chỉ phù hợp, nó sẽ sử dụng khóa chung để xác thực chữ ký. Nếu việc xác thực này không thành công hoặc không tìm thấy chứng chỉ nào thì bản tin UPDATE sẽ bị coi là không hợp lệ. Sau đó, thiết bị định tuyến xác nhận chữ ký tiếp theo theo cách tương tự. Dựa trên các chữ ký được xác thực, thiết bị định tuyến khi nhận được bản tin UPDATE có thể đảm bảo rằng mỗi AS trong tuyến đường đều có các thiết bị định tuyến đã tạo chữ ký.

Hơn nữa, thiết bị định tuyến có thể đảm bảo rằng bước nhảy tiếp theo trong chữ ký tương ứng với số AS tiếp theo trong tuyến đường. Bằng cách này sẽ xác thực được tuyến đường đang quảng bá tiền tố IP. Về cơ bản, ý tưởng là tất cả các AS cần sử dụng BGPsec để nó có hiệu quả và qua mỗi AS phải thực hiện mã hóa nên thực tế với số lượng lớn trong bảng định tuyến toàn cầu (1,2 triệu tiền tố IPv4 và 270 nghìn tiền tố IPv6) sẽ dẫn đến mối quan tâm về năng lực thiết bị và bài toán đầu tư. Đây là một trở ngại lớn cho việc áp dụng rộng rãi, mặc dù có không ít người cho rằng BGPsec vẫn có thể mang lại giá trị ngay cả khi chỉ các upstream cấp cao nhất đồng ý sử dụng giao thức này với nhau.

Một giải pháp khác khả thi hơn là Uỷ quyền nhà cung cấp hệ thống tự trị (ASPA). Đây một giải pháp nhằm xác thực chính xác số hiệu mạng của nhà cung cấp dịch vụ được phép quảng bá chuyển tiếp các tuyến đường. Khác với cơ chế bảo mật trước đó sử dụng để xác thực nguồn gốc của tuyến đường, ASPA được sử dụng để xác thực AS_PATH và cho phép các thực thể khác từ chối tuyến đường khi AS_PATH không tồn tại trong bản ghi.

Các bản ghi ASPA được tạo và phân phối giống như ROA trong RPKI. Bằng việc áp dụng giải pháp này, AS có thể đảm bảo rằng không có AS nào trên tuyến đường không được phép quảng bá tiền tố IP. Ví dụ dưới đây cho thấy một bản ghi ASPA được AS945 khởi tạo và hiển thị năm nhà cung cấp được phép quảng bá các tiền tố IP là: AS1299, AS6939, AS32097, AS50058 và 61138.

Hình 12: Minh họa về bản ghi ASPA (Nguồn: MANRS)

Tổng kết

Như vậy để đảm bảo ATTT mạng của chúng ta cần phải bảo vệ thông tin định tuyến trên Internet. Hiểu rõ về hoạt động của giao thức định tuyến Internet BGP giúp chúng ta phòng ngừa các rủi ro có thể xảy ra trên Internet đối với mạng của mình. RPKI, BGPSec hay ASPA là một phần mở rộng được đề xuất cho BGP nhằm bổ sung xác thực tuyến đường góp phần ngăn chặn một số cuộc tấn công và hay sai sót trong cấu hình.

Tính bảo mật trên thường đi kèm với việc gia tăng chi phí về thiết bị từ việc tạo chữ ký và quá trình xác nhận mất nhiều thời gian hơn. Mặt khác, BGP là một giao thức ra đời từ lâu kéo theo các vấn đề mà các giao thức khác cùng thời đó gặp phải như DNS. Cuối cùng, các giải pháp bảo mật trên cần thêm nhiều thời gian để nghiên cứu, tối ưu và chuẩn hóa vào RFC cũng như thúc đẩy áp dụng triển khai trên phạm vi toàn cầu để đem lại hiệu quả cao nhất.

“
Tài liệu tham khảo:
1. Routing Security: BGP and AS Path Validation, Geoff Huston
(APNIC)
2. Best Practices for Enhancing BGP Security, Networkphil
3. BGPsec in the context of routing system security, CSNOG
[3]. https://circleid.com/posts/201...
[4]. google_disrupts_internet_in_japan
https://www.internetsociety.or...
6. https://2024.apricot.net/asset...
detect-f_1709087365.pdf
7. https://aws.amazon.com/
8. https://www.securityweek.com/c...
european-traffic-its-network-two-hours/
9. https://labs.ripe.net/author/e...
route-around-damage-a-case-study-using-ripe-atlas/
10.https://blog.lacnic.net/en/rou...
of-one-year-of-bgp-incidents
11. https://www.cloudflare.com/lea...
bgp-hijacking/
12. https://www.kentik.com/blog/a-...
internets-biggest-bgp-incidents/
13. https://www.kentik.com/kentipe...
14. https://www.coinbase.com/blog/...
analysis
15. https://www.kentik.com/blog/a-...
analysis-2023/
16. https://www.nanog.org/stories/...
the-internets-biggest-bgp-incidents/
17. https://sec.cloudapps.cisco.co...
protecting_border_gateway_protocol
18. https://blog.qrator.net/en/rep...