Rò rỉ tuyến đường BGP dẫn đến mất kết nối hàng loạt trên Internet

Công ty Cloudflare được phát hành báo cáo về sự việc ngày hôm qua, dẫn đến ba giơ từ 13:34 đến 16:26 (MSK) đã xảy ra sự cố về khả năng truy cập vào nhiều tài nguyên trên mạng toàn cầu, bao gồm cơ sở hạ tầng của Cloudflare, Facebook, Akamai, Apple, Linode và Amazon AWS. Các vấn đề trong cơ sở hạ tầng Cloudflare, nơi cung cấp CDN cho 16 triệu trang web, Được Quan sát từ 14:02 đến 16:02 (MSK). Cloudflare ước tính khoảng 15% lưu lượng truy cập toàn cầu đã bị mất trong thời gian ngừng hoạt động.

Vấn đề là gây ra Rò rỉ tuyến đường BGP, trong đó khoảng 20 nghìn tiền tố cho 2400 mạng đã được chuyển hướng không chính xác. Nguồn rò rỉ là do nhà cung cấp DQE Communications sử dụng phần mềm Trình tối ưu hóa BGP để tối ưu hóa việc định tuyến. BGP Optimizer chia tiền tố IP thành các tiền tố nhỏ hơn, ví dụ như chia 104.20.0.0/20 thành 104.20.0.0/21 và 104.20.8.0/21, và do đó, DQE Communications giữ lại một số lượng lớn các tuyến cụ thể ghi đè nhiều hơn các tuyến đường chung (tức là thay vì các tuyến chung đến Cloudflare, các tuyến chi tiết hơn đến các mạng con Cloudflare cụ thể đã được sử dụng).

Các tuyến điểm này đã được thông báo cho một trong những khách hàng (Allegheny Technologies, AS396531), người này cũng có kết nối thông qua một nhà cung cấp khác. Allegheny Technologies phát sóng các tuyến đường kết quả tới một nhà cung cấp dịch vụ vận chuyển khác (Verizon, AS701). Do thiếu khả năng lọc thích hợp các thông báo BGP và hạn chế về số lượng tiền tố, Verizon đã chọn thông báo này và phát 20 nghìn tiền tố thu được tới phần còn lại của Internet. Tiền tố không chính xác, do tính chi tiết của chúng, được coi là có mức độ ưu tiên cao hơn vì một tuyến đường cụ thể có mức độ ưu tiên cao hơn tuyến đường chung.

Kết quả là, lưu lượng truy cập của nhiều mạng lớn bắt đầu được định tuyến qua Verizon đến nhà cung cấp nhỏ DQE Communications, nhà cung cấp này không thể xử lý lưu lượng truy cập tăng đột biến, dẫn đến sự cố sập mạng (hiệu ứng này có thể so sánh với việc thay thế một phần đường cao tốc đông đúc bằng một đường cao tốc đông đúc). đường quê).

Để ngăn chặn những sự cố tương tự xảy ra trong tương lai
khuyến khích:

• Để sử dụng xác minh thông báo dựa trên RPKI (Xác thực nguồn gốc BGP, chỉ cho phép chấp nhận thông báo từ chủ sở hữu mạng);
• Giới hạn số lượng tiền tố tối đa nhận được cho tất cả các phiên EBGP (cài đặt tiền tố tối đa sẽ giúp loại bỏ ngay việc truyền 20 nghìn tiền tố trong một phiên);
• Áp dụng tính năng lọc dựa trên sổ đăng ký IRR (Đăng ký định tuyến Internet, xác định các AS thông qua đó cho phép định tuyến các tiền tố được chỉ định);
• Sử dụng cài đặt chặn mặc định được đề xuất trong RFC 8212 trên bộ định tuyến ('từ chối mặc định');
• Hãy ngừng sử dụng các trình tối ưu hóa BGP một cách liều lĩnh.

Nguồn: opennet.ru