Mọi thứ đều rất tệ hoặc một kiểu chặn giao thông mới

Ngày 13 tháng XNUMX tới nhóm công tác chống lạm dụng RIPE một lời đề nghị đã được nhận coi việc chiếm quyền điều khiển BGP (hjjjack) là vi phạm chính sách RIPE. Nếu đề xuất được chấp nhận, nhà cung cấp Internet bị tấn công bởi việc chặn lưu lượng truy cập sẽ có cơ hội gửi yêu cầu đặc biệt để vạch mặt kẻ tấn công. Nếu nhóm đánh giá thu thập đủ bằng chứng hỗ trợ, LIR là nguồn chặn BGP sẽ bị coi là kẻ xâm nhập và có thể bị tước trạng thái LIR. Cũng có một số tranh luận chống lại điều này những thay đổi.

Trong ấn phẩm này, chúng tôi muốn đưa ra một ví dụ về một cuộc tấn công trong đó không chỉ kẻ tấn công thực sự bị nghi ngờ mà còn cả toàn bộ danh sách các tiền tố bị ảnh hưởng. Hơn nữa, một cuộc tấn công như vậy một lần nữa đặt ra câu hỏi về động cơ của việc chặn loại lưu lượng truy cập này trong tương lai.

Trong vài năm qua, chỉ có những xung đột như MOAS (Hệ thống tự trị đa nguồn gốc) mới được báo chí đưa tin dưới dạng chặn BGP. MOAS là trường hợp đặc biệt khi hai hệ thống tự trị khác nhau quảng cáo các tiền tố xung đột với các ASN tương ứng trong AS_PATH (ASN đầu tiên trong AS_PATH, sau đây gọi là ASN gốc). Tuy nhiên, ít nhất chúng ta có thể kể tên 3 loại bổ sung chặn lưu lượng, cho phép kẻ tấn công thao túng thuộc tính AS_PATH cho nhiều mục đích khác nhau, bao gồm bỏ qua các phương pháp hiện đại để lọc và giám sát. Kiểu tấn công đã biết Pilosova-Kapely - kiểu đánh chặn cuối cùng như vậy, nhưng không hề quan trọng. Rất có thể đây chính xác là kiểu tấn công mà chúng ta đã thấy trong những tuần qua. Sự việc như vậy có tính chất dễ hiểu và hậu quả khá nghiêm trọng.

Những ai đang tìm phiên bản TL;DR có thể tìm đến phụ đề "Perfect Attack".

Nền mạng

(để giúp bạn hiểu rõ hơn về các quy trình liên quan đến vụ việc này)

Nếu bạn muốn gửi một gói và bạn có nhiều tiền tố trong bảng định tuyến chứa địa chỉ IP đích thì bạn sẽ sử dụng tuyến cho tiền tố có độ dài dài nhất. Nếu có nhiều tuyến đường khác nhau cho cùng một tiền tố trong bảng định tuyến, bạn sẽ chọn tuyến đường tốt nhất (theo cơ chế chọn đường dẫn tốt nhất).

Các phương pháp lọc và giám sát hiện tại cố gắng phân tích các tuyến đường và đưa ra quyết định bằng cách phân tích thuộc tính AS_PATH. Bộ định tuyến có thể thay đổi thuộc tính này thành bất kỳ giá trị nào trong quá trình quảng cáo. Chỉ cần thêm ASN của chủ sở hữu vào đầu AS_PATH (là ASN gốc) có thể đủ để bỏ qua các cơ chế kiểm tra nguồn gốc hiện tại. Hơn nữa, nếu có một tuyến đường từ ASN bị tấn công đến bạn, bạn có thể trích xuất và sử dụng AS_PATH của tuyến đường này trong các quảng cáo khác của mình. Mọi kiểm tra xác thực chỉ AS_PATH cho thông báo được tạo của bạn cuối cùng sẽ vượt qua.

Vẫn còn một số hạn chế đáng nói. Thứ nhất, trong trường hợp nhà cung cấp tuyến trên lọc tiền tố, tuyến đường của bạn vẫn có thể bị lọc (ngay cả với AS_PATH chính xác) nếu tiền tố không thuộc về hình nón máy khách của bạn được định cấu hình ở tuyến trên. Thứ hai, AS_PATH hợp lệ có thể trở nên không hợp lệ nếu tuyến đã tạo được quảng cáo theo hướng không chính xác và do đó vi phạm chính sách định tuyến. Cuối cùng, bất kỳ tuyến đường nào có tiền tố vi phạm độ dài ROA đều có thể bị coi là không hợp lệ.

Sự cố

Một vài tuần trước, chúng tôi đã nhận được khiếu nại từ một trong những người dùng của chúng tôi. Chúng tôi đã thấy các tuyến đường có tiền tố ASN và /25 gốc của anh ấy, trong khi người dùng khẳng định rằng anh ấy không quảng cáo chúng.

TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||

Ví dụ về các thông báo vào đầu tháng 2019 năm XNUMX

NTT trong đường dẫn tiền tố /25 khiến nó đặc biệt đáng ngờ. LG NTT không hề biết về tuyến đường này vào thời điểm xảy ra sự cố. Vì vậy, có, một số toán tử tạo toàn bộ AS_PATH cho các tiền tố này! Kiểm tra các bộ định tuyến khác sẽ phát hiện một ASN cụ thể: AS263444. Sau khi xem xét các tuyến đường khác có hệ thống tự động này, chúng tôi gặp phải tình huống sau:

TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.0/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.128/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.96.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.112.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||

Hãy thử đoán xem có điều gì sai ở đây

Có vẻ như ai đó đã lấy tiền tố từ tuyến đường, chia nó thành hai phần và quảng cáo tuyến đường có cùng AS_PATH cho hai tiền tố đó.

TABLE_DUMP2|1554076800|B|xxx|263444|1.6.36.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|263444|1.6.38.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|61775|1.6.36.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|61775|1.6.38.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.36.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.38.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||

Các tuyến đường ví dụ cho một trong các cặp tiền tố được phân chia

Một số câu hỏi phát sinh cùng một lúc. Có ai thực sự đã thử kiểu đánh chặn này trong thực tế chưa? Có ai đã đi những con đường này chưa? Tiền tố nào bị ảnh hưởng?

Đây là nơi bắt đầu chuỗi thất bại của chúng ta và thêm một đợt thất vọng nữa với tình trạng hiện tại của Internet.

Con đường thất bại

Điều đầu tiên trước tiên. Làm cách nào chúng tôi có thể xác định bộ định tuyến nào đã chấp nhận các tuyến bị chặn như vậy và lưu lượng truy cập của ai có thể được định tuyến lại ngay hôm nay? Chúng tôi nghĩ mình nên bắt đầu với tiền tố /25 vì chúng "đơn giản là không thể phân phối toàn cầu". Như bạn có thể đoán, chúng tôi đã rất sai lầm. Số liệu này hóa ra quá ồn ào và các tuyến đường có tiền tố như vậy có thể xuất hiện ngay cả từ các nhà khai thác Cấp 1. Ví dụ: NTT có khoảng 50 tiền tố như vậy và phân phối cho khách hàng của chính mình. Mặt khác, thước đo này không tốt vì những tiền tố như vậy có thể bị lọc ra nếu người vận hành sử dụng lọc tiền tố nhỏ, trong tất cả các hướng. Do đó, phương pháp này không phù hợp để tìm tất cả các nhà khai thác có lưu lượng truy cập bị chuyển hướng do sự cố như vậy.

Một ý tưởng hay khác mà chúng tôi nghĩ đến là xem xét POV. Đặc biệt đối với các tuyến đường vi phạm quy tắc maxLength của ROA tương ứng. Bằng cách này, chúng tôi có thể tìm thấy số lượng ASN gốc khác nhau có trạng thái Không hợp lệ được hiển thị cho một AS nhất định. Tuy nhiên, có một vấn đề "nhỏ". Giá trị trung bình (trung bình và chế độ) của số này (số ASN gốc khác nhau) là khoảng 150 và ngay cả khi chúng tôi lọc ra các tiền tố nhỏ, nó vẫn ở trên 70. Tình trạng này có một lời giải thích rất đơn giản: chỉ có một một số nhà khai thác đã sử dụng bộ lọc ROA với chính sách “đặt lại các tuyến đường không hợp lệ” tại các điểm đầu vào, để bất cứ nơi nào một tuyến đường có vi phạm ROA xuất hiện trong thế giới thực, nó có thể lan truyền theo mọi hướng.

Hai cách tiếp cận cuối cùng cho phép chúng tôi tìm những người vận hành đã nhìn thấy sự cố của chúng tôi (vì nó khá lớn), nhưng nhìn chung chúng không thể áp dụng được. Được rồi, nhưng chúng ta có thể tìm ra kẻ đột nhập không? Các tính năng chung của thao tác AS_PATH này là gì? Có một số giả định cơ bản:

  • Tiền tố này chưa từng được nhìn thấy ở bất kỳ đâu trước đây;
  • ASN gốc (lời nhắc: ASN đầu tiên trong AS_PATH) là hợp lệ;
  • ASN cuối cùng trong AS_PATH là ASN của kẻ tấn công (trong trường hợp hàng xóm của nó kiểm tra ASN của hàng xóm trên tất cả các tuyến đến);
  • Cuộc tấn công bắt nguồn từ một nhà cung cấp duy nhất.

Nếu tất cả các giả định đều đúng thì tất cả các tuyến không chính xác sẽ hiển thị ASN của kẻ tấn công (ngoại trừ ASN gốc) và do đó, đây là điểm "quan trọng". Trong số những kẻ không tặc thực sự có AS263444, mặc dù vẫn có những kẻ khác. Ngay cả khi chúng tôi loại bỏ các lộ trình sự cố khỏi việc xem xét. Tại sao? Một điểm tới hạn có thể vẫn quan trọng ngay cả đối với các tuyến đường chính xác. Nó có thể là kết quả của khả năng kết nối kém trong một khu vực hoặc những hạn chế về tầm nhìn của chúng ta.

Do đó, có một cách để phát hiện kẻ tấn công, nhưng chỉ khi đáp ứng tất cả các điều kiện trên và chỉ khi mức chặn đủ lớn để vượt qua ngưỡng giám sát. Nếu một số yếu tố này không được đáp ứng thì liệu chúng ta có thể xác định được các tiền tố bị chặn như vậy không? Đối với một số nhà khai thác nhất định - có.

Khi kẻ tấn công tạo một tuyến đường cụ thể hơn, tiền tố đó sẽ không được chủ sở hữu thực sự quảng cáo. Nếu bạn có một danh sách động gồm tất cả các tiền tố của nó, thì bạn có thể so sánh và tìm ra các tuyến đường cụ thể hơn bị bóp méo. Chúng tôi thu thập danh sách tiền tố này bằng cách sử dụng các phiên BGP của mình, vì chúng tôi không chỉ được cung cấp danh sách đầy đủ các tuyến đường hiển thị cho nhà điều hành ngay bây giờ mà còn có danh sách tất cả các tiền tố mà họ muốn quảng cáo ra thế giới. Thật không may, hiện nay có hàng chục người dùng Radar không hoàn thành chính xác phần cuối cùng. Chúng tôi sẽ sớm thông báo cho họ và cố gắng giải quyết vấn đề này. Mọi người khác có thể tham gia hệ thống giám sát của chúng tôi ngay bây giờ.

Nếu quay lại sự việc ban đầu, cả kẻ tấn công và khu vực phân phối đều bị chúng tôi phát hiện bằng cách tìm kiếm các điểm quan trọng. Đáng ngạc nhiên là AS263444 không gửi các tuyến đường giả cho tất cả khách hàng của mình. Mặc dù có một khoảnh khắc xa lạ.

BGP4MP|1554905421|A|xxx|263444|178.248.236.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||
BGP4MP|1554905421|A|xxx|263444|178.248.237.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||

Một ví dụ gần đây về nỗ lực chặn không gian địa chỉ của chúng tôi

Khi những cái cụ thể hơn được tạo cho tiền tố của chúng tôi, AS_PATH được tạo đặc biệt sẽ được sử dụng. Tuy nhiên, AS_PATH này không thể được lấy từ bất kỳ tuyến đường nào trước đây của chúng tôi. Chúng tôi thậm chí không có liên lạc với AS6762. Nhìn vào các tuyến đường khác trong vụ việc, một số tuyến đường trong số đó có AS_PATH thật đã được sử dụng trước đó, trong khi những tuyến đường khác thì không, ngay cả khi nó trông giống tuyến đường thật. Ngoài ra, việc thay đổi AS_PATH không có ý nghĩa thực tế nào vì dù sao thì lưu lượng truy cập cũng sẽ được chuyển hướng đến kẻ tấn công, nhưng các tuyến có AS_PATH “xấu” có thể được lọc bởi ASPA hoặc bất kỳ cơ chế kiểm tra nào khác. Ở đây chúng tôi nghĩ về động cơ của tên không tặc. Hiện tại chúng tôi không có đủ thông tin để xác nhận rằng vụ việc này là một cuộc tấn công có kế hoạch. Tuy nhiên, điều đó là có thể. Chúng ta hãy thử tưởng tượng một tình huống, mặc dù vẫn chỉ là giả thuyết, nhưng có khả năng khá thực tế.

Cuộc tấn công hoàn hảo

Chúng ta có gì? Giả sử bạn là nhà cung cấp dịch vụ chuyển tuyến phát sóng các tuyến đường cho khách hàng của mình. Nếu khách hàng của bạn có nhiều hiện diện (multihome), thì bạn sẽ chỉ nhận được một phần lưu lượng truy cập của họ. Nhưng lưu lượng truy cập càng nhiều thì thu nhập của bạn càng nhiều. Vì vậy, nếu bạn bắt đầu quảng cáo tiền tố mạng con của cùng các tuyến đường này với cùng AS_PATH, bạn sẽ nhận được phần lưu lượng truy cập còn lại của chúng. Kết quả là, phần còn lại của số tiền.

ROA có giúp ích gì ở đây không? Có lẽ có, nếu bạn quyết định ngừng sử dụng nó hoàn toàn độ dài tối đa. Ngoài ra, việc có các bản ghi ROA có tiền tố giao nhau là điều không mong muốn. Đối với một số nhà khai thác, những hạn chế như vậy là không thể chấp nhận được.

Xem xét các cơ chế bảo mật định tuyến khác, ASPA cũng sẽ không giúp ích gì trong trường hợp này (vì nó sử dụng AS_PATH từ một tuyến hợp lệ). BGPSec vẫn không phải là một lựa chọn tối ưu do tỷ lệ chấp nhận thấp và khả năng bị tấn công hạ cấp còn sót lại.

Vì vậy, chúng tôi có lợi ích rõ ràng cho kẻ tấn công và thiếu bảo mật. Sự pha trộn tuyệt vời!

Tôi nên làm gì đây?

Bước rõ ràng và quyết liệt nhất là xem lại chính sách định tuyến hiện tại của bạn. Chia không gian địa chỉ của bạn thành các phần nhỏ nhất (không trùng lặp) mà bạn muốn quảng cáo. Chỉ ký ROA cho họ mà không sử dụng thông số maxLength. Trong trường hợp này, POV hiện tại của bạn có thể cứu bạn khỏi một cuộc tấn công như vậy. Tuy nhiên, một lần nữa, đối với một số nhà khai thác, cách tiếp cận này không hợp lý do chỉ sử dụng các tuyến đường cụ thể hơn. Tất cả các vấn đề với trạng thái hiện tại của ROA và các đối tượng tuyến đường sẽ được mô tả trong một trong những tài liệu trong tương lai của chúng tôi.

Ngoài ra, bạn có thể thử theo dõi những lần chặn như vậy. Để làm điều này, chúng tôi cần thông tin đáng tin cậy về tiền tố của bạn. Do đó, nếu bạn thiết lập phiên BGP với người thu thập của chúng tôi và cung cấp cho chúng tôi thông tin về khả năng hiển thị trên Internet của bạn, chúng tôi có thể tìm thấy phạm vi cho các sự cố khác. Đối với những người chưa kết nối với hệ thống giám sát của chúng tôi, trước tiên, danh sách các tuyến đường chỉ có tiền tố của bạn là đủ. Nếu bạn có phiên làm việc với chúng tôi, vui lòng kiểm tra xem tất cả các tuyến đường của bạn đã được gửi chưa. Thật không may, điều này đáng ghi nhớ vì một số toán tử quên một hoặc hai tiền tố và do đó cản trở các phương pháp tìm kiếm của chúng tôi. Nếu thực hiện đúng, chúng tôi sẽ có dữ liệu đáng tin cậy về tiền tố của bạn, dữ liệu này trong tương lai sẽ giúp chúng tôi tự động xác định và phát hiện các loại chặn lưu lượng truy cập này (và các loại khác) đối với không gian địa chỉ của bạn.

Nếu bạn nhận thấy việc chặn lưu lượng truy cập của mình như vậy trong thời gian thực, bạn có thể cố gắng tự mình khắc phục. Cách tiếp cận đầu tiên là tự mình quảng cáo các tuyến đường có tiền tố cụ thể hơn này. Trong trường hợp có một cuộc tấn công mới vào các tiền tố này, hãy lặp lại.

Cách tiếp cận thứ hai là trừng phạt kẻ tấn công và những người mà anh ta coi là điểm quan trọng (đối với các tuyến đường tốt) bằng cách cắt quyền truy cập vào các tuyến đường của bạn đối với kẻ tấn công. Điều này có thể được thực hiện bằng cách thêm ASN của kẻ tấn công vào AS_PATH của các tuyến cũ của bạn và do đó buộc chúng tránh AS đó bằng cách sử dụng cơ chế phát hiện vòng lặp tích hợp trong BGP vì lợi ích của riêng bạn.

Nguồn: www.habr.com

Thêm một lời nhận xét