BGP route leak koruması ve RPKI validation, yanlış yönlendirilen veya ele geçirilen prefix'lerin trafiği yanlış AS path'e çekmesini engellemek için güvendiğim mekanizmalardır. Route leak, bir ağın bir komşudan öğrendiği prefix'leri yanlışlıkla başka bir komşuya geri tanıtması durumunda oluşur ve RPKI üzerinden Origin Validation olmadan downstream router'ların bu duyurunun meşru olduğuna dair kriptografik bir kanıtı olmaz. Çözüm, Resource Public Key Infrastructure validation kurmak, ROA kapsamındaki invalid prefix'leri edge'de reddetmek ve sadece beklenen rotaların yayılması için prefix-list'leri sıkılaştırmaktır. İşte bunu production ortamında nasıl yapılandırdığım.
BGP Route Leak Nedir ve Neden Zararlıdır
Route leak, tam bir prefix hijack ile aynı şey değildir. Hijack kötü niyetlidir — biri sahip olmadığı bir prefix'i tanıtır. Leak ise genellikle kazayla olur: bir müşteri veya peer, upstream'ünden aldığı rotaları herkese tanıtmaya başlar ve BGP varsayılan olarak güven ettiği için bu rotalar küresel olarak yayılır.
Zararı gerçektir. Güneydoğu Asya'daki küçük bir ISP'nin büyük CDN'ler için route leak yaptığı ve internetin yarısından gelen trafiğin dakikalar içinde doyusan bir 10G link üzerinden akmaya başladığı olaylar gördüm. DNS sorguları zaman aşımına uğradı, ödeme ağgeçitleri karanlığa gömüldü ve müşteriler aramaya başlayana kadar kimse fark etmedi.
Klasik vakalar:
- YouTube Pakistan Telecom (2008): Pakistan, YouTube'u yerel olarak engellemek için /24 prefix'ini küresel olarak yanlışlıkla leak etti. Dünya çapındaki trafik onların router'larına çarptı.
- MainOne / Google (2018): Bir Nijeryalı ISP, Google, Cloudflare ve Amazon için rotaları leak etti. İnternetin büyük bölümleri yaklaşık iki saat boyunca Nijerya üzerinden yeniden yönlendirildi.
- China Telecom (2010, 2019): Batı ağlarından gelen trafiğin Çin altyapısı üzerinden çekildiği birden fazla leak.
Bunların her biri RPKI Origin Validation ile engellenebilirdi.
RPKI Route Leak'leri Nasıl Önler
RPKI (Resource Public Key Infrastructure), bir prefix sahibinin bir Route Origin Authorization (ROA) kriptografik olarak imzalamasını sağlar. ROA, belirli bir prefix'i bir Origin AS'ye bağlar ve izin verilen maksimum prefix uzunluğunu belirtir. Edge router'larımd bir BGP duyurusu aldığında, ROA'yı yerel bir validation cache'ine karşı kontrol eder ve rotayı Valid, Invalid veya NotFound olarak işaretler.
- Valid: BGP güncellemesindeki origin AS, ROA ile eşleşir. Kabul et.
- Invalid: Origin AS eşleşmiyor veya prefix uzunluğu ROA'nın izin verdiğinden fazla. Düşür.
- NotFound: Bu prefix için ROA yok. Kabul et ama körü körüne güvenme.
Kilit nokta şudur: edge'de Invalid rotaları reddetmek leak'leri fiilen durduran şeydir. Onları kabul edip daha düşük bir local-pref atarsanız, leak path selection sırasında hala trafik çekebilir. Ben her harici peering oturumunda Invalid'ları doğrudan reddederim.
Daha önce VLAN izolasyonu yazımda (https://furkanikkan.com/urun/vlan-yapilandirmasi-ag-trafigini-dogru-sekilde-izole-etme-60) belirttiğim gibi, segmentasyon ancak enforcement boundary temizse çalışır. RPKI, BGP katmanında o boundary'dir.
FRRouting ile RPKI Validation Kurulumu
Birkaç edge router'ımda Linux üzerinde FRRouting çalıştırıyorum. İşte bir RPKI cache çekmek ve invalid rotaları reddetmek için kullandığım yapılandırma.
Önce yerel bir RPKI validator kurun ve başlatın. Ben Routinator 3000 kullanıyorum:
# Debian/Ubuntu üzerinde Routinator kurulumu
apt install routinator
systemctl enable --now routinator
# RTR bağlantıları için 3323 portunu dinlerArdından FRR'yi cache'i kullanacak ve validation uygulayacak şekilde yapılandırın:
router bgp 65000
bgp rpki server 127.0.0.1 port 3323
neighbor 192.0.2.1 remote-as 64512
neighbor 192.0.2.1 ebgp-requires-policy
!
address-family ipv4 unicast
neighbor 192.0.2.1 activate
neighbor 192.0.2.1 route-map RPKI-IN in
exit-address-family
!
route-map RPKI-IN permit 10
match rpki invalid
set local-preference 0
!
route-map RPKI-IN deny 20
match rpki invalid
!
route-map RPKI-IN permit 30Cisco IOS-XE RPKI Yapılandırması
IOS-XE çalışan Cisco edge router'larımda yapılandırma oldukça basittir. Router'ı bir RPKI cache'ine yönlendirir ve ardından invalid'ları reddetmek için bir route-map kullanırsınız:
router bgp 65000
bgp rpki server tcp 127.0.0.1 port 3323 refresh 300
neighbor 192.0.2.1 remote-as 64512
address-family ipv4 unicast
neighbor 192.0.2.1 route-map RPKI-REJECT in
exit-address-family
!
ip extcommunity-list standard RPKI-INVALID permit rt 65000:0
route-map RPKI-REJECT deny 10
match extcommunity RPKI-INVALID
route-map RPKI-REJECT permit 20İpucu: IOS-XE 17.x, native bgp rpki bestpath use validity desteğini ekledi. Dağıtımdan önce sürümünüzü kontrol edin — eski 15.x code train'leri bunu farklı şekilde ele alır.
Prefix-List'ler ve IRR Filtreleme: Derinlemesine Savunma
RPKI tek başına her şeyi yakalayamaz. Her prefix'in yayınlanmış bir ROA'sı yoktur ve NotFound rotaları hala kabul edilir. Boşlukları kapatmak için IRR (Internet Routing Registry) filtrelemesini bunun üzerine katmanlandırıyorum.
Her harici peer için yaklaşımım:
bgpq4kullanarak peer'ın IRR kaydından AS-SET'ini çekin.- Sadece yetkili oldukları prefix'leri izin veren bir prefix-list oluşturun.
- O prefix-list'i peering oturumunda inbound olarak uygulayın.
- Filtreyi cron ile günlük olarak yenileyin — AS-SET'ler değişir.
İşte bgpq4 ile hızlı bir örnek:
bgpq4 -b -4 -l PEER-IN AS-EXAMPLE
# Platformunuz için dönüştürebileceğiniz Bird formatında bir prefix-list oluştururRoute Leak'ler İçin İzleme ve Uyarı
RPKI ve IRR filtrelemesi olsa bile, bir şeyler yanlış görünüyorsa hemen bilmek istiyorum. Şunları izliyorum:
- Beklenmeyen route churn: Tek bir peer'dan gelen BGP güncellemelerinde ani sıçramalar genellikle bir leak veya upstream'de bir yanlış yapılandırma anlamına gelir.
- Mevcut peer'lardan yeni prefix'ler: Bir peer aniden AS-SET'i dışında prefix'ler tanıtmaya başlarsa, filtrem yakalar — ama sessiz bir düşürme değil bir uyarı istiyorum.
- RPKI cache sağlığı: Cache çökerse router'ım validation yapamaz. Cache bağlantı hatalarında uyarı alırım.
Küresel routing değişikliklerini gerçek zamanlı izlemek için CAIDA'dan bgpstream ve peer başına route sayıları için basit bir Prometheus exporter kullanıyorum. Bir peer'ın route sayısı beş dakikada %20'den fazla artarsa, sayfalama alırım.
MTTD rehberimde (https://furkanikkan.com/urun/veri-ihlalini-ne-kadar-hizli-tespit-edersiniz-mttd-rehberi-57) ele aldığım gibi, tespit süresi önemlidir. 30 saniyede tespit edilen bir route leak bir olay değildir. 30 dakikada tespit edilirse, bir kesinti raporudur.
RPKI Dağıtımı İçin Pratik Kontrol Listesi
Sıfırdan başlıyorsanız, önerdiğim sıra:
- Kendi prefix'leriniz için ROA oluşturun RIR'niz (RIPE, ARIN, APNIC) üzerinden. Bu, sizi başkaları tarafından leak edilmenizden korur.
- Yerel bir RPKI validator dağıtın — upstream'inizin validation'ına güvenmeyin. Routinator veya OctoRPKI ikisi de iyi çalışır.
- Edge router'larda RPKI validation'ı etkinleştirin ve Invalid'ları düşürmeden önce loglamaya başlayın. False positive'leri izleyin.
- Bir hafta temiz logdan sonra reject moduna geçin.
- ROA kapsamı olmayan peer'lar için IRR tabanlı prefix filtreleme ekleyin.
- Cache sağlığı ve route sayısı anomalileri için izleme kurun.
Kendi ağımında 3. ve 4. adımları dikkatlice geçtim. İlk loglama haftası bir transit sağlayıcıdan üç Invalid route yakaladı — hepsi deprecated bir AS'den kalma eski duyurulardı. Meşru trafikte false positive yoktu. Reject moduna geçtiğimde geçiş görünmezdi.
Son Düşünceler
BGP, güvenin varsayıldığı bir dönemde tasarlandı. Bu varsayım son yirmi yılda milyarlarca dolarlık kesinti hasarına neden oldu. RPKI mükemmel değil — benimseme hala büyüyor ve NotFound rotaları bir boşluk olarak kalıyor — ancak edge'de Invalid rotaları reddetmek, BGP altyapımı sağlamlaştırmak için yaptığım tek en etkili değişiklik oldu. Hala peer'larınızın gönderdiği her rotayı kabul ediyorsanız, bir sonraki küresel olayın parçası olmaya bir yanlış yapılandırma uzaktasınız.
Kapak görseli: Unknown · CC0 (Openverse / kamu malı) · https://www.rawpixel.com/image/6038427/photo-image-public-domain-technology-line