BGP işleme hatası internet yönlendirmesinde kararsızlığa yol açtı
(blog.benjojo.co.uk)- 20 Mayıs 2025 07:00 UTC'de yayılan bozuk bir BGP mesajı, iki büyük uygulamada beklenmedik davranışlara yol açtı; çok sayıda internet bağlantılı BGP oturumu sıfırlandı ve bazı ağlarda yönlendirme kararsızlığı ya da kısa süreli bağlantı kaybı yaşandı
- Sorunlu güncelleme, internet BGP güncellemelerinde normalde beklenmeyen bir BGP Prefix-SID Attribute içeriyordu ve iç verisi tamamen
0x00olan bozuk durumdaydı - RFC7606 tabanlı hata toleransını uygulayan IOS-XR/Nokia SR-OS bunu filtreledi, ancak JunOS bunu iletti ve Arista EOS oturumu sıfırladı; bu da JunOS tabanlı transit carrier'a bağlı Arista kullanıcılarını etkilemiş olabilir
- bgp.tools gözlemlerinde AS9304, AS135338, AS151326 ve AS138077 tekrar tekrar görüldü; kusurlu özniteliği ekleyen tarafın büyük olasılıkla Starcloud AS135338 veya Hutchison AS9304 olduğu düşünülüyor
- Olay sırasında bgp.tools route collector'ın 10 saniyelik ortalama mesaj oranı, normalde saniyede 20.000~30.000 iken 150.000/s üzerine çıktı; bu da BGP hata işleme farklarının gerçek internet rota istikrarını sarsabileceğini gösteriyor
20 Mayıs 2025 BGP güncelleme olayı
- 20 Mayıs 2025 Salı günü 07:00 UTC'de yayılan bir BGP mesajı, internet trafiği taşımada sık kullanılan iki büyük BGP uygulamasında beklenmedik davranışları tetikledi
- Çok sayıda internet bağlantılı BGP oturumu otomatik olarak sonlandı ve etki yayıldı
- Bazı ağlarda yönlendirme kararsızlığı doğrulandı
- En kötü durumda kısa süreli bağlantı kaybı yaşanmış olabilir
Sorunlu BGP mesajı
- bgp.tools'a beslenen oturumlarda görülen güncelleme, /16 için nispeten sıradan bir BGP Update idi, ancak sorunlu BGP Prefix-SID Attribute'u içeriyordu
- Bu öznitelik iki nedenle tehlikeliydi
- İnternet tablosundaki BGP güncellemelerinde görülmesi beklenen bir öznitelik değildi
- İç verisi tamamen
0x00olan bozuk bir öznitelikti
- IOS-XR/Nokia SR-OS gibi çoğu uygulama, RFC7606 tabanlı “BGP error tolerance” etkin olduğunda bunu doğru şekilde filtreleyip soruna yol açmadı
- JunOS ve Arista EOS kombinasyonunda ise farklı bir sonuç ortaya çıktı
- JunOS bozuk mesajı iletti
- Arista EOS cihazları, JunOS cihazlarından gelmiş görünen bu mesajı aldığında oturumu sıfırladı
- Pek çok internet transit carrier, JunOS çalıştıran Juniper donanımı kullandığı için, Arista EOS işleten ve JunOS tabanlı üst transit carrier yönlendiricilerine bağlı ağların bir süre internete erişimi kesilmiş olabilir
- Sürenin en fazla yaklaşık 10 dakika olduğu tahmin ediliyor
Kusurlu özniteliği ekleyen aday AS'ler
- İlgili dönemdeki bgp.tools arşivleri filtrelendiğinde, birden çok origin AS'nin olaya dahil göründüğü tespit edildi
- Bu da özniteliğin prefix'i origin eden ağ tarafından değil, daha geniş internete giden ara bir carrier tarafından eklenmiş olabileceğine işaret ediyor
- Sorunlu mesajların tamamında tekrar tekrar görülen adaylar şu dört AS oldu
- bgp.tools,
[…] 151326 138077 […]yolunda kusurlu BGP özniteliği olmadan etkilenen prefix'i gözlemledi- Bu nedenle kusurlu özniteliği ekleyen tarafın büyük olasılıkla Starcloud AS135338 veya Hutchison AS9304 olduğu düşünülüyor
- Özniteliği içeren güncellemelerde gözlemlenen bazı prefix'ler şunlardı
156.230.0.0/16138.113.116.0/24163.171.102.0/24163.171.103.0/24163.171.104.0/24
İnternet exchange'lere yayılan rota
- Olay, Hutchison/AS9304'ün çok sayıda internet exchange'e bağlı olması nedeniyle büyüdü
- Sorunlu mesajlar IX route server'lara gönderildi ve bu route server'lar genellikle bird çalıştırıyor
- Bird, BGP SID desteği sunmadığı için mesajı filtreleyemedi ve bunu çok sayıda multi-terabit internet exchange'e olduğu gibi dağıttı
- Sonuç olarak karışıklık, internet transit oturumlarının ötesine geçerek daha geniş bir alana yayıldı
BGP Prefix-SID'nin niteliği
- BGP Prefix-SID Attribute normalde yalnızca dahili BGP oturumlarında görülmeli
- RFC8669 içinde tanımlanan amacı, tek bir ağ içinde trafiğin hedefe giderken hangi yolu izleyeceğini belirlemeye yardımcı olmaktır
- Bu özniteliğin global routing table'a sızmasının nedeni, harici BGP oturumlarının dahili oturumlar gibi yapılandırılmış olması olabilir
Etkilenen ağlar ve gözlem metrikleri
- Tam olarak kimlerin etkilendiğini kesin olarak söylemek zor olsa da, ilk sorunlu BGP mesajının hemen ardından ağ büyüklüğüne kıyasla churn'ün çok yüksek olduğu yerlere bakıldığında yaklaşık 100 ağın sorun yaşadığı hesaplandı
- Yüksek güvenle verilen örnekler şunlar
- Normalde bgp.tools route collector saniyede yaklaşık 20.000~30.000 mesaj topluyor
- Bu olay sırasında 10 saniyelik ortalama mesaj oranı 150.000/s değerini açık ara aştı
- Bu, birçok internet rotasında ciddi bozulma yaşandığını gösteriyor
Tedarikçilere göre hata işleme farkları
- Kök neden veya gerçek tetikleyici taraf tamamen net olmasa da, kusurlu mesajın internet ölçeğinde yayılması BGP hata işlemenin risklerini gösteriyor
- Diğer tedarikçiler kusurlu özniteliği tespit edip rota duyurusunu bastırırken, Juniper bunu peer'lara iletti
- Mesaj Arista cihazlarına ulaştıktan sonra ise BGP error tolerance kodunun olmaması veya hatalı olması oturum sıfırlanmasına yol açtı
- Juniper'in JunOS BGP error tolerance dokümantasyonu, JunOS'un mesajın tüm bölümlerini incelemediğini belirtiyor
- Bu davranış, JunOS'un kendisinin uzaktan tetiklenen oturum sıfırlamasından kaçınırken aynı mesajı diğer peer'lara veya müşterilere iletmesi sonucunu doğurdu
Operasyonel çıkarımlar
- Bu outage kısa sürdü, ancak daha büyük etkilere yol açabilirdi
- Daha fazla hizmet IP tabanlı hale geldikçe, internet kesintilerinin kapsamı e-postaya erişememekten daha ileriye gidebilir
- TV yayınlarının kesilmesi
- Acil servis telefonlarında kesinti
- Bu tür hatalar, gerçek dünyada can kaybına yol açma ya da mevcut zararı ağırlaştırma ihtimalini artırıyor
- Tüm routing table'a sahip ağ operatörleri, gelecekteki olayların hata ayıklamasına yardımcı olmak için bgp.tools'a veri akışı sağlayabilir
- Halihazırda 2570 çalışan oturum bgp.tools'a veri sağlıyor
- Kurulum yöntemi bgp.tools veri akışı kurulum dokümanında açıklanıyor
1 yorum
Hacker News yorumları
Standart yaklaşım, kabul ederken hoşgörülü, dışarı verirken katı olmak gerektiğidir.
Seçenekler bozuk mesajları filtrelemek, atmak, bozuk özniteliği yok sayıp iletmek ya da bozuk öznitelik yüzünden bozulmaktır; gerçekten kabul edilmesi zor olanın yalnızca 4. seçenek, yani Arista tarzı davranış olduğunu düşünüyorum. 3. seçenek olan Juniper tarzı davranış arzu edilir değil ama ölümcül de değil.
Yeniden okuyunca Arista’nın 4. seçenekten çok 2. seçeneğe yakın olduğunu, tamamen çökmediğini; hatalı bir bağlantı olarak görüp kapattığını anladım. Kullanıcı açısından iyi değil, ama tartışmalı da olsa kabul edilebilir sayılır.
En yaygın yöntem treat-as-withdraw; yani rota duyuru güncellemesini, mevcut duyurulan rotanın geri çekilmesi gibi ele almak. Bozuk mesajı sadece atarsanız, artık geçerli olmayan eski durumu korumaya devam edersiniz; bu yüzden böyle yapılmamalı.
1980’ler ve 90’ların internetin eski tarihinden çıkan bir fikir; bugünse protokol katılaşmasına ve çok sayıda güvenlik sorununa yol açmış hatalı bir fikir olarak yaygın biçimde anlaşılıyor.
Artık birçok sistem bu davranışa bağımlı ve bu “özelliğin” olumsuz yanlarını yaşıyoruz.
Dışarıdan bakınca bu “özellik”, iletilen bilginin etkilerini anlamayan sistemler üzerinden bilinmeyen bilgilerin körlemesine yayılmasına yol açtığı için çok kötü bir fikir gibi görünüyor. Ama bu özellik sayesinde Large Communities gibi şeylerin daha hızlı ve yaygın biçimde dağıtılabildiği, hatta yeni BGP özelliklerinin dağıtımının mümkün hale geldiği de söylenebilir.
Tüm ağda CVE-2023-4481’i düzeltmek için deliler gibi koşturduğumu hâlâ hatırlıyorum.
Bu tür hatalarla uğraşmak gerçekten kâbus olmalı; BGP’nin tasarlanma ve uygulanma biçimi yüzünden bu davranışı düzeltmek çok uzun sürecek.
Onlarca yıl önce olsa da bir telekom ekipmanı şirketinde BGP özellikleri geliştirmiştim.
Hâlâ BGP’nin fazla karmaşık olduğunu düşünüyorum; insanlar sürekli yeni özellikler ekliyor, üreticiler de RFC standartlarına veya taslaklarına göre sürekli uygulama geliştiriyor.
BGP’nin kullanımdan kalkacak gibi görünmemesi nedeniyle bu tür hatalar gelecekte de tekrar tekrar bulunacak gibi.
Kişisel olarak korkutucu derecede karmaşıktı, ama birileri için epey kârlıydı.
HGC Global Communications Limited, daha önce Hutchison Global Communications Limited olarak bilinen ve Hong Kong merkezli bir internet servis sağlayıcısıdır.
https://en.wikipedia.org/wiki/HGC_Global_Communications
Bizim IOS XR şasilerimiz de bu paketlerden bazılarını aldı ve bu, yüksek BGP rota ilanlarıyla aynı zamana denk geldi. Üst sağlayıcının hangi ekipmanı kullandığını açıkçası bilmiyorum.
BGP protokolünün düzgün biçimde fuzzing’e tabi tutulup tutulmadığını merak ediyorum. Belki de çok kritik olduğu için herkesin bozmayı denemekten çekindiği bir alan.
Bir BGP fuzzer yazmak kolay olabilir, ama çökme nedenini teşhis etmek çok zor olur gibi.
BGP’yi, sorun çıkardığını duyana kadar hiç öğrenmemiş gibiyim. TCP/IP gibi internet için vazgeçilmez olmasına rağmen TCP/IP’yi üniversitede de öğreniyoruz, kariyer boyunca da karşımıza çıkıyor, hakkında çok kitap da okudum; ama BGP’ye üniversitede, işte ya da kitaplarda neredeyse hiç rastlamadım.
TCP/IP’yi evde oyuncak projelerle “kurcalayarak” öğrenebilirsiniz; BGP içinse ne yapmak gerektiğini bilmiyorum. Evde BGP öğrenmek için ne yapmak gerekir?
Yazıda bird geçiyor; ayrıca çok popüler bir uygulama olarak FRR (free range routing) var. İki Docker container’ı çalıştırıp aralarında bir BGP oturumu kurmak ve örneğin içeride yapılandırdığınız statik rotaları duyurmak oldukça basit.
Rehberli eğitimleri seviyorsanız https://blog.ipspace.net/2023/08/bgp-labs-basic-setup/ oldukça iyi; biraz daha ileri konulara da genişliyor. Takip etmek için gereken her şey özgür yazılım.
Herhangi bir ağ teknolojisinde doğrudan deneyim kazanmanın en kolay yolu muhtemelen GNS3’tür.
[1]: https://wiki.dn42.us/home
Denemenin bir yolu şudur: https://www.eve-ng.net/
Başka bir yol, birkaç ağ arayüzü olan bir iki sanal makine oluşturup aralarında bir ağ kurmak ve BGP yönlendirme daemon’u kullanmaktır.
https://bird.network.cz/
https://www.nongnu.org/quagga/
gibi seçenekler var.
Birden fazla AS’yi simüle eden bir Python paketi kullanmıştık; hangi paket olduğunu hatırlamıyorum.
BGP’yi denemek için bu yazının yazarı gibi bir ağ simülatörü kullanabilirsiniz. Derste, profesörün lisansüstü öğrencilerinden biri tarafından yapılmış gibi duran gini[1]’yi kullanmıştık; yazar ise Cisco’ya özel bir ns3 sürümü gibi görünen gns3 kullanmış gibi. ns3’ü bir kez denedim, öğrenme eğrisi dikti. gini simülatörünün kullanıcı arayüzü daha temel, ama muhtemelen daha az güçlüdür.
[1] https://citelab.github.io/gini5/
[2] https://docs.gns3.com/docs/
Birden fazla donanım üreticisi bu tür işleri ele almanın standart bir yolu üzerinde anlaşsaydı, BGP çok daha kararlı olurdu gibi görünüyor.
Asıl sorun, her üreticinin kilitleme etkisi istediği için standardizasyona gitmemesi mi?
Yine de BGP konusundaki anlayışım sığ ve zayıf; uzman değilim.
Bu tür bir hatanın etkisi düşünüldüğünde, birlikte çalışabilirlik test paketi olan bir konsorsiyum olmaması şaşırtıcı.
Belki vardır da bu belirli sorun test paketinde yer almıyordur. Öyleyse, olası tüm paket hatalarını fuzzing ya da makineyle üretilmiş yöntemlerle tarayıp test vakaları oluşturmamaları şaşırtıcı. Paketin çalışması saatler ya da günler sürse de sorun olmazdı.
Bu yazının yazarı belli bir kapsama sahip bir fuzzer oluşturmuş ve daha önce de benzer bir sorunla karşılaşmış gibi. Üreticilerin bu çalışmayı aktif biçimde benimsememesi şaşırtıcı.
Birden fazla üretici geçmişte bu hatayı yaşamıştı: https://www.kb.cert.org/vuls/id/347067
CVE-2023-4481 (Juniper), CVE-2023-38802 (FRR), CVE-2023-38283 (OpenBGPd), CVE-2023-40457 (EXOS) vardı.
O dönemde Arista etkilenmemişti.
İnternet tesisatı kadar büyük ölçekli ve rastlantısal karmaşıklığı Bizans usulü birbirine dolanmış başka bir şey var mı, emin değilim.