13 martda RIPE-nin sui-istifadə ilə mübarizə işçi qrupuna BGP-nin hücumu (hjjack) RIPE siyasətini pozma kimi müzakirə olunmasını. Təklif qəbul edildiyi halda, trafik hücumuna məruz qalmış internet provayderi, zəifliyi açmaq üçün xüsusi müraciət göndərmə imkanına sahib olacaqdı. Əgər ekspert qrupu kifayət qədər sübut toplaya bilsə, BGP hücumuna mənbə olan belə bir LIR pozucu sayılacaq və LIR statusunu itirə bilərdi. Buna qarşı bəzi arqumentlər də var idi dəyişikliklər.
Bu nəşrdə, yalnız real hücumçunun deyil, həm də zərər çəkmiş prefixlərin tam siyahısının sual altında olduğu bir hücumun nümunəsini göstərmək istəyirik. Üstəlik, belə bir hücum bu cür trafik hücumlarının gələcək motivləri ilə bağlı suallar doğurur.
Son bir neçə ildə mətndə BGP hücumları yalnız MOAS (Çoxsaylı Mənşə Avtonom Sistemləri) tipli toqquşmalarla bağlı işıqlandırılıb. MOAS — bu, iki fərqli avtonom sistemin AS_PATH içində müvafiq ASN nömrələri ilə toqquşan prefixləri elan etməsi halıdır (AS_PATH içindəki ilk ASN, daha sonra mətndə - mənşə ASN). Lakin biz ən azı trafik hücumunu adlandıra bilərik ki, bu da hücumçuya müxtəlif məqsədlər üçün AS_PATH atributunu manipulyasiya etməyə imkan tanıyır, o cümlədən müasir filtrasiya və monitorinq yanaşmalarını aşmaq məqsədilə. Məşhur hücum növü — bu cür hücumun son tipidir, lakin əhəmiyyətinə görə tamamilə deyil. Mümkündür ki, biz, məhz belə bir hücumu son həftələrdə müşahidə etmişik. Belə bir hadisənin izahı var və kifayət qədər ciddi nəticələri var.
TL;DR versiyasını axtaranlar «İdeal hücum» başlığına keçə bilərlər.
Şəbəkə arxa planı
(bu insidentdə istifadə olunan prosesləri daha yaxşı başa düşməyiniz üçün)
Əgər siz paket göndərmək istəyirsinizsə və yönləndirmə cədvəlindəki bir neçə prefixdə hədəf IP adresini varsa, siz maksimum uzunluğa malik prefix üçün marşrutu istifadə edəcəksiniz. Əgər yönləndirmə cədvəlində bir prefix üçün bir neçə fərqli marşrut varsa, ən yaxşısını seçəcəksiniz (ən yaxşı yolun seçilməsi mexanizminə əsasən).
Mövcud filtrasiya və monitorinq yanaşmaları, marşrutları analiz edərək AS_PATH atributunu araşdırmağa çalışır. Marşrutlaşdırıcı bu atributu elan edərkən istədiyi hər hansı bir dəyərə dəyişə bilər. Sahibi olan ASN-in AS_PATH-ın əvvəlində sadəcə əlavə edilməsi (origin ASN olaraq) cari mənbə yoxlama mexanizmlərini keçmək üçün kifayət edə bilər. Üstəlik, əgər hücuma məruz qalmış ASN-dən sizə doğru bir marşrut varsa, bu marşrutun AS_PATH-ını çıxarmaq və digər elanlarınızda istifadə etmək imkanı yaranır. Sizin düzəldilmiş elanlarınız üçün yalnız AS_PATH-ın etibarlılığını yoxlamaq nəticədə uğur qazanacaq.
Həmçinin, qeyd edilməyə dəyər bir neçə məhdudiyyət mövcuddur. Birincisi, yuxarıdakı provayder tərəfindən prefikslərin filtrasiya edilməsində marşrutunuz hələ də filtrelənə bilər (doğru AS_PATH ilə belə), əgər prefiks sizin müştəri konusunuzu əhatə etmirsə. İkincisi, etibarlı AS_PATH, yaradılmış marşrut qeyri-dəqiq istiqamətlərdə elan edildikdə qeyri-etibarsız hala gələ bilər və bu, marşrutlaşdırma siyasətini pozur. Və nəhayət, ROA length-ini pozan hər hansı bir prefiks, qeyri-etibarsız hesab oluna bilər.
Hadisə
Bir neçə həftə əvvəl bir istifadəçidən şikayət aldıq. Onun origin ASN-i ilə /25 prefiksləri ilə marşrutlar gördük, halbuki istifadəçi bunları elan etmədiyini iddia edirdi.
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||
2019-cu il aprel ayının əvvəli üçün elan nümunələri
NTT, /25 prefiks üçün marşrutda olduğu üçün xüsusilə şübhəlidir. Hadisə zamanı LG NTT bu marşrut haqqında heç bir məlumatı yox idi. Beləliklə, bəli, bir operator bu prefikslər üçün tam bir AS_PATH yaradır! Digər marşrutlaşdırıcılarda yoxlama apararaq bir xüsusi ASN: AS263444 seçildi. Bu avtonom sistemdəki digər marşrutlara baxdığımızda, aşağıdakı vəziyyətlə qarşılaşdıq:
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||
Burada nəyin səhv olduğunu tapmağa çalışın
Görünür, kimsə marşrutdan prefiksi götürüb, iki hissəyə ayırıb və həmin iki prefiks üçün eyni AS_PATH ilə marşrutu elan edib.
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||
Ayırdılmış prefikslərin bir cütü üçün marşrut nümunələri
Bir neçə sual yaranır. Gerçəkdən kiminsə belə bir intervalları praktiki olaraq sınayıb? Kimlərsə bu marşrutları qəbul ediblərmi? Hansı prefikslər təsir olunub?
Burada İnternetin cari sağlamlıq vəziyyətindəki nümunə uğursuzluqlarımıza və bir daha məyus olmağımıza başlayırıq.
Uğursuzluq yolu
Hamısını ardıcıl olaraq izah edək. Hansı marşrutlaşdırıcıların bu cür tutulmuş marşrutları qəbul etdiyini və bugün hansı trafiklərin yönləndirilə biləcəyini necə müəyyən edə bilərik? Biz, 25 / prefiksindən başlamağı düşünürdük, çünki onların "qlobal yayılma imkanları yoxdur". Təbii ki, burada ciddi yanıldığımızı başa düşdünüz. Bu metriya çox səs-küylü oldu və belə prefiksə sahib marşrutlar Tier-1 operatorlarından belə meydana çıxa bilər. Məsələn, NTT-nin müştəri bazasında yaydığı təxminən 50 belə prefiksi var. Digər tərəfdən, bu metriya pisdir, çünki bu cür prefikslər, əgər operator kiçik prefiksləri filtr edirsə, süzülə bilər. , bütün istiqamətlərdə. Buna görə də, bu metod, belə bir hadisənin nəticəsində tıxanmış trafiklərini yönləndirmiş bütün operatorları tapmaq üçün uyğun deyil.
Bununla yanaşı, daha bir yaxşı fikir olaraq noktalarına baxmağı düşündük. Xüsusən də müvafiq ROA-nın maxLength qaydasını pozan marşrutlara. Beləliklə, bu AS tərəfindən görünən, Invalid statusuna malik müxtəlif origin ASN-lərin sayını tapa bilərdik. Lakin, "kiçik" bir problem var. Bu sayın orta dəyəri (medyan və moda) təxminən 150-dir və kiçik prefiksləri süzsək belə, o 70-dən yuxarı qalacaq. Bu cür vəziyyətin sadə bir izahı var: yalnız bir neçə operator, ROA filtr siyasətini tətbiq edir ki, "Invalid marşrutları" giriş nöqtələrində ləğv etsin, buna görə də, real dünyada ROA-nı pozan bir marşrut ortaya çıxdığı zaman, o hər istiqamətdə yayıla bilər.
Son iki yanaşma, hadisəmizi gördüyü üçün operatorları tapmağa imkan verir (çünki kifayət qədər geniş idi), amma ümumilikdə onlar tətbiq oluna bilən deyil. Yaxşı, amma biz, zərərçəkəni tapa bilərikmi? AS_PATH manipulyasiyasının ümumi xüsusiyyətləri nədir? Bir neçə əsas fərziyyə var:
- Prefiks əvvəlcə heç bir yerdə görünməmişdir;
- Origin ASN (xatırlatma: AS_PATH-dakı ilk ASN) etibarlıdır;
- AS_PATH-dakı son ASN hücumçunun ASN-dir (əgər qonşusu bütün daxil olan marşrutlardakı qonşu ASN-i yoxlayırsa);
- Saldırı tək bir provayderdən gəlir.
Bütün ehtimallar doğrudur, o zaman bütün qeyri-dəqiq marşrutlarda təcavüzkarın ASN-i (origin ASN-dan başqa) görünəcək və beləliklə, bu «tənqidi» bir nöqtədir. Həqiqi oğurlayanlar arasında AS263444 da var idi, amma başqaları da var idi. Hadisənin marşrutlarını müzakirədən çıxardıqdan sonra belə. Niyə? Tənqidi bir nöqtə düzgün marşrutlar üçün də tənqidi olaraq qalır. Bu, ya bir bölgədə pis əlaqənin nəticəsidir, ya da öz görünürlüğümüzün məhdudiyyətləridir.
Nəticə olaraq: təcavüzkara aydın olan bir yol var, lakin yalnız yuxarıda sadalanan bütün şərtlərə uyğun olduğu təqdirdə və yalnız keçid kifayət qədər böyük olduqda izləmə həddini keçməsi üçün. Əgər bu faktorlardan bəzi cəhətlər qeyri-uyğundursa, oxşar bir keçiddən zərər çəkmiş prefiksleri qeyd edə bilərikmi? Bəzi operatorlar üçün - bəli.
Hücumçu daha spesifik bir marşrut yaratdıqda, bu prefiks həqiqi sahibi tərəfindən elan edilmir. Əgər siz onun dinamik prefikslərinin bütün siyahısını əldə etmisinizsə, müqayisə imkanınız olur və daha spesifik marşrutları tapmaq mümkündür. Bu prefikslerin siyahısını BGP seanslarımız vasitəsilə toplayırıq, çünki bizə yalnız hazırda operatorun görünən bütün marşrutların tam siyahısını vermir, həm də dünya ilə elan etmək istədiyi bütün prefikslerin siyahısını təqdim edir. Təəssüf ki, hazırda Radar istifadəçilərinin bir neçə onla, son hissəni tamamlamada düzgün etmirlər. Tezliklə onlara xəbər verəcəyik və bu problemi həll etməyə çalışacağıq. Qalan hər kəs indi monitoring sistemimizə qoşula bilər.
İlk hadisəyə qayıtsaq, həm təcavüzkar, həm də yayılma sahəsi tənqidi nöqtələri axtarışımız vasitəsilə aşkar edildi. Təəccüblüdür ki, AS263444 saxta marşrutları bütün müştərilərinə göndərmirdi. Daha da qəribə bir məqam var.
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||
Son vaxtlarda ünvan sahəmizi ələ keçirmək cəhdinin nümunəsi
Our prefixes’ more specific routes were created using a specially designated AS_PATH. However, this AS_PATH could not be derived from any of our previous routes. We don’t even have a connection to AS6762. Looking at other routes in the incident, some of them had a legitimate AS_PATH that was used earlier, while others did not, even if they appeared genuine. Additional alterations to the AS_PATH hold no practical significance, as the traffic will ultimately be redirected to the attacker anyway, but routes with a 'bad' AS_PATH could be filtered out by ASPA or any other validation mechanism. Here, we questioned the motivation of the hijacker. We currently lack the data to assert that this incident was a planned attack. However, it remains possible. Let’s consider a hypothetical yet potentially real scenario.
Ideal Attack
What do we have? Suppose you are a transit provider broadcasting routes for your clients. If your clients have multiple presences (multihome), you'll only capture part of their traffic. But the more traffic you have, the higher your revenue. Therefore, if you start announcing subnet prefixes of those same routes with the same AS_PATH, you'll receive the remainder of their traffic. Consequently, the remaining portion of their revenue.
Will ROA help here? Possibly, yes, if you decide to completely abandon its use. . Additionally, it is highly undesirable to have ROA records with overlapping prefixes. For some operators, such restrictions are unacceptable.
Considering other routing security mechanisms, in this case, ASPA will also not help (since it uses the AS_PATH from an allowable route). BGPSec is still not an ideal option due to a low adoption rate and the ongoing risk of downgrade attacks.
Thus, we have a clear profit for the attacker and a lack of security. A perfect mix!
What needs to be done?
Aydındır ki, ən radikal addım cari yönləndirmə siyasətinizi yenidən gözdən keçirməkdir. Ünvan boşluğunuzu sizin yalnızca elan etmək istədiyiniz ən kiçik parçalara (kəsişmədən) bölün. Onlar üçün ROA-nı yalnız imzalayın, maxLength parametrindən istifadə etmədən. Bu halda, cari POV sizi belə bir hücumdan qoruya bilər. Lakin, yenə də, bəzi operatorlar üçün bu yanaşma daha spesifik marşrutların tək istifadə olunması səbəbindən məqsədəuyğun deyil. Cari ROA və marşrut obyektlərinin vəziyyətinin bütün problemləri yaxın gələcəkdəki materiallarımızda təsvir olunacaq.
Bundan başqa, belə müdaxilələri izləməyə çalışa bilərsiniz. Bunun üçün prefikslerinizə dair dəqiq məlumat lazımdır. Beləliklə, əgər BGP seansını kollektorumuzla qurarsanız və şəbəkə görünlülüyünüz haqda məlumatınızı bizə ötürsəniz — digər hadisələr üçün yayıqlama sahəsini müəyyənləşdirə bilərik. Hələ də monitoring sistemimizə qoşulmamış olanlar üçün əvvəlcə yalnız sizin prefikslerinizdən olan marşrutlar siyahısı kifayət edəcək. Əgər bizimlə seansınız varsa, xahiş edirik, bütün marşrutlarınızın göndərildiyindən əmin olun. Təəssüf ki, buna diqqət yetirmək vacibdir, çünki bəzi operatorlar bir və ya iki prefiksini unutmağa meyllidirlər və beləliklə, axtarış metodlarımızda maneə yaradırlar. Hər şey düzgün edildikdə, prefiksleriniz haqda etibarlı məlumatlarımız olacaq ki, bu da gələcəkdə belə (və digər) trafik müdaxilələrini avtomatik müəyyənləşdirməkdə sizə kömək edə bilər.
Əgər real vaxtda trafikinizin belə müxalifətindən xəbərdar oldunuzsa, özünüz mübarizə aparmağa çalışa bilərsiniz. İlk yanaşma — bu prefikslerle marşrutları özünüz elan etməkdir. Bu prefikslerə qarşı yeni bir hücum olarsa — eyni addımları təkrarlamaqla.
İkinci yanaşma — təcavüzkəri cəzalandırmaq və onun kritik nöqtəsi olanları (yaxşı marşrutlar üçün) sizin marşrutlarınızın təcavüzkərə daxil olmasının qarşısını almaqdır. Bunu köhnə marşrutlarınızın AS_PATH-a təcavüzkərin ASN-nı əlavə edərək edə bilərsiniz və beləcə, onları BGP-dəki döngü aşkar etmə mexanizmi vasitəsilə bu AS-dən qaçmağa məcbur edə bilərsiniz. .
Mənbə: habr.com
