İstanbul'da iş ilanları

Tag: traffic engineering

TCP Connection Reset Remote Exploit ile BGP Oturumunu Sıfırlama

TCP protokolünden zaten birkaç kez bahsettim, bu yüzden kendimi tekrar etmeyeceğim. Sadece temel bilgileri özetleyeceğim: İletim Kontrol Protokolü (TCP), RFC 793’te açıklanmıştır ve avantajı, internet üzerinden bir makineden diğerine güvenilir veri iletimi sağlamasıdır. Bu, TCP’nin güvenilir veri iletimini garanti ettiği ve düşen veya hasar görmüş paketleri otomatik olarak algıladığı anlamına gelir. Tasarımında önemli olan nedir?

Tipik olarak, bir TCP paket başlığı şöyle görünür:

Nmap veya Metasploit, bir veri arabelleğini TCP yığınına iletir. Yığın daha sonra bu veriyi bölümlere ayırır ve veri kümeleri halinde paketler. Bu veri kümeleri, ağ üzerinden iletilen paketleri oluşturmak için kullanılır. Bağlantının diğer ucunda, ters işlem gerçekleşir. Veri kümesi ve bölümleri paketlerden çıkarılır, ardından bölümler TCP yığınına iletilir, burada analiz edilir, yeniden birleştirilir ve hedef işlem birimine gönderilir.

Sequence numbers

Veriler, alıcıya ayrı ayrı paketler halinde ağ üzerinden gönderilen segmentlere ayrılır. Paketlerin hedeflerine sırasız bir şekilde ulaşması mümkündür. Bu alan, segmentin sıra numarasını belirten 32 bitlik bir sayıdır. Her paketle birlikte artar ve verilerin doğru sırada yeniden birleştirilmesini sağlar. Genel olarak, bu değer bir paketin aktif bir oturuma ait olup olmadığını belirler.

Window

TCP ayrıca sunucuların ne kadar veri almak istediklerini iletmeleri için bir mekanizma sağlar. Bu, TCP başlığındaki 16 bitlik bir sayı olan Pencere alanıdır. Ayarlandığında, sunucuya kesinlikle sınırlı miktarda veri alınacağını ve kalan paketlerin atılacağını bildirir. Alma kuyruğu doluysa, sunucu diğer uca daha fazla veri almayacağını bildirmek için alma penceresini 0’a ayarlayabilir.

Kontrol bitleri (SYN, ACK, PSH, URG, RST ve FIN) birçok kez ele alındı, bu nedenle içeriklerini burada tekrar etmeyeceğim.

TCP RESET saldırısı

Temel fikir, bir paket oluşturarak kurulmuş bir TCP bağlantısını sonlandırmaktır. A ana bilgisayarından B ana bilgisayarına olan bir bağlantıyı ele alalım. Üçüncü bir ana bilgisayar olan C, A ana bilgisayarının kaynak portunu ve IP adresini, B ana bilgisayarının hedef portunu ve IP adresini ve A ile B arasındaki aktif TCP bağlantısının mevcut sıra numarasını belirten bir paket oluşturur. C ana bilgisayarı pakete RTS bitini ekler, böylece B paketi aldığında bağlantı hemen sonlandırılır. Bu, yeni bir BGP oturumu kurulana kadar BGP oturumunu kesintiye uğratır.

Protokol hatası, yönlendirici için oldukça tatsız bir durum olan “yönlendirme atlamalarına” yol açabilir.

Güvenlik açığı

Bu güvenlik açığını keşfeden Paul Watson, böyle bir saldırının daha önce düşünüldüğü kadar zor olmadığını açıklıyor. Önceki hesaplamalar, bir sıra numarasına yönelik kaba kuvvet saldırısının 1’den 4.294.967.295’e kadar tüm sayıları denemeyi gerektireceğini öne sürüyordu. Ancak bu tamamen doğru değil. Örneğin, A ana bilgisayarındaki TCP yığını 16K’lık bir pencereyle sınırlıysa, yığın bu pencere içindeki tüm paketleri almalıdır. Saldırganın, RTS ayarı tüm SN dizisi boyunca ayarlanmış paketler göndermesi gerekmez, bunun yerine TCP, pencere boyutuyla tanımlanan bir aralıktaki herhangi bir sıra numarasını kabul edeceğinden, kendisini her olası pencereyle sınırlandırır. Bu nedenle, saldırganın tüm kullanılabilir pencereleri vurmak için 4.294.967.295 / 16.384 = 262.143 denemesi gerekir.

262.000 büyük bir sayı gibi görünse de aslında öyle değil. Birincisi, iyi bir bağlantıyla, bir saldırgan saniyede on binlerce paket üretebilir. İkincisi, saldırı birden fazla sunucuya dağıtılabilir. Örneğin, standart bir DSL hattı saniyede 250 paket üretebilir ve tüm olası paketleri 17 dakikada tüketebilir. 2 Mbps’lik bir bağlantıyla bu, sadece 60 saniyede 4.730 paket anlamına gelir.

Örneğimde 16K’lık bir pencere kullanılıyor, ancak RFC’ye göre bu alan 16 bit olup maksimum pencere boyutu 64K’dır. Tam pencere boyutu kullanılırsa, saldırgan yalnızca 65.537 paket veya sırasıyla 4 ve 15 saniye alacaktır. Bunun maksimum süre olduğunu unutmayın; ortalama olarak bunun yarısı kadar olacaktır (pratikte 3 dakika 8 saniye). Güvenlik açığında açıklanan dört pakete gelince, bu yalnızca pencere ölçeklendirmesi, bir TCP uzantısı (bkz. RFC 1323) kullanıldığında meydana gelir; burada pencere boyutu 16 bitten 30 bite çıkarılır (örneğin, yukarıda açıklanan BGP’de uygulanır). Maksimum pencere boyutuyla, saldırganın TCP sıfırlamasını tetiklemek için yalnızca dört paket göndermesi yeterli olacaktır.

Source Port

Yukarıdaki örneklerin tümü, saldırganın hedef port ve IP adresinin yanı sıra kaynak port ve kaynak adresini de bilmesine dayanmaktadır. İlk iki parametreyi elde etmek ve belirlemek kolaydır. Hedef IP adresini belirlemek de kolaydır; bu, oluşturulan paketin hedeflendiği istemci adresidir. Tek soru kaynak porttur. Örneğin, işletim sistemi 1025 ile 49152 arasında değişen bir havuzdan rastgele bir port atarsa (OpenBSD’nin yaptığı gibi), bu, her port numarasıyla bir sıra numarasını eşleştirmeyi gerektireceğinden, deneme sayısını tam olarak 48127 kat artıracaktır. İyi haber şu ki, Linux ve Windows dahil olmak üzere çoğu işletim sistemi bu mekanizmayı kullanmıyor, bu da bu savunmayı geçersiz kılıyor.

reset-tcp.c güvenlik açığı

Paul Watson, alışılmadık derecede cömert davranarak yazdığı reset-tcp.c güvenlik açığını çevrimiçi olarak yayınladı. Bu açığı basit bir Debian Linux sisteminde bile oluşturmak oldukça kolay.

Derlemeye başlamadan önce, sistemde gerekli libnet-1.1.1 kütüphanesinin bulunup bulunmadığını kontrol etmenizi ve eksikse yüklemenizi öneririm:

apt-get install libnet1-dev

Kütüphaneyi sisteme başarıyla kurduktan sonra, istismar dosyasını oluşturmaya geçiyoruz:

gcc reset-tcp.c -o reset-tcp /usr/lib/libnet.a

veya

gcc -o reset-tcp reset-tcp.c -lnet

Ayrıca, kullanım sırasında internet sağlayıcınızla ilgili gereksiz sorunlardan kaçınmak için MAC adresini (enet_src/enet_dst) kod içinde önceden değiştirebilirsiniz.

Örnek başlatma:

reset-tcp [interface] [src ip] [src port] [dst ip] [dst port] [window size]

[root@orc EuroTransTelecom]# ./reset-tcp eth1 172.16.0.1 1 172.16.0.2 2 65536

Packets sent: 8192 Sequence guess: 536805376
Packets sent: 16384 Sequence guess: 1073676288
Packets sent: 24576 Sequence guess: 1610547200
Packets sent: 32768 Sequence guess: 2147418112
Packets sent: 40960 Sequence guess: 2684289024
Packets sent: 49152 Sequence guess: 3221159936
Packets sent: 57344 Sequence guess: 3758030848
packets sent: 65535

SYN saldırısı

Sıfırlama saldırısı, RST biti olmadan da gerçekleştirilebilir. Bunun yerine, SYN biti ayarlanarak yukarıda açıklanan saldırının aynısı yapılabilir. Çoğu TCP yığın uygulamasında, tekrarlanan bir SYN, sıra numarası içeren bir RST ile sonuçlanır. SYN mevcut oturum penceresi içindeyse, RST yanıtı yerine oturum sonlandırılır ve sistem büyük olasılıkla yeniden başlatılır.

Kör veri enjeksiyonu

Son olarak, üçüncü ama kesinlikle son olmayan senaryo. Önceki durumlarda olduğu gibi, sıra numarasını bulmak için kaba kuvvet yöntemi kullanılıyor, ancak boş SYN veya RST paketleri göndermek yerine geçerli bir veri paketi oluşturuluyor. Bu durumda bağlantı kesilmeyecek, ancak kullanıcının bilgisayarının göreceği şey tamamen bir gizem olacak. İletilen veriler felaket derecede bozulmuş olacak.

Bu konuyu benimle özel mesaj yoluyla daha detaylı olarak görüşebilirsiniz. İletişim bilgilerim bu web sitesinin ilgili bölümünde yer almaktadır.

10.02.2026
BGP Yönlendirme Sızıntıları ve BGP Saldırıları arasındaki fark nedir?
BGP izleme ve analiz hizmetinin temel özelliklerinden biri, BGP yönlendirme sızıntısı veya BGP ele geçirme olarak adlandırabileceğimiz bir olaya yol açabilecek belirli anormallikleri izlemektir.

Her ikisi de, anormallik olmayan duruma kıyasla, trafiği üçüncü taraflara yönlendirir, ancak farklı şekillerde. Son birkaç yıldır bu sorunları çözmek için çok çaba sarf edildi, ancak neyin ne olduğu ve farklı araçların farklı sorunları çözmeye nasıl yardımcı olduğu konusunda hala yanlış anlamalar var.

BGP ilişkileri modelini, RFC 7908 yayınlanmadan birkaç yıl önce, BGP rota sızıntısının ne olduğunu tanımlamaya çalışarak toplamaya başladık. Bu iki olay arasındaki iki temel fark şu şekilde açıklanmıştır:
- Yanlış ASN’ler/bağlantılar üzerinden yönlendirilen rotalar (Rota sızıntıları), RFC 7908’de 1-4 tipleri olarak tanımlanmıştır.
- Yanlış ASN’lere yönlendirilen rotalar (Yönlendirme kaçırma), RFC 7908’de 5 ve 6 tipleri olarak tanımlanmıştır.
Bir BGP yönlendirme sızıntısı sırasında, ağınıza yönlendirilen trafik büyük olasılıkla verimsiz bir şekilde akacak ve bu da ağ gecikmesinin artmasına ve paket kaybına yol açabilir. Bununla birlikte, (kötü niyetli bir saldırganın kötü niyeti gibi) kritik bir ağ tıkanıklığı olmadığı sürece, trafik neredeyse kesinlikle ağınıza ulaşacaktır. Bir BGP ele geçirme durumunda ise, ağınıza yönlendirilen trafik üçüncü bir tarafa yönlendirilir ve orada kalır. Ayrıca, bu tür anormallikleri oluşturma mekanizmaları da farklıdır. Bir yönlendirme sızıntısı oluşturmak için, iyi bir rotayı uygun olmayan bir komşu ISS’ye aktarmanız gerekir. Bir ele geçirme oluşturmak için, ya geçerli bir önekin alt öneki/daha spesifik bir önekiyle bir rota duyurmanız (istediğiniz AS_PATH ile bu duyuruyu alan tüm ISS’lerden gelen trafiği çekmek için) ya da ağınızdan üçüncü taraf bir önekle bir rota duyurusu oluşturmanız gerekir. Yönlendirme anormalliklerini oluşturma mekanizmaları farklılık gösterdiğinden, olay tespit mekanizmaları ve önleme/azaltma yöntemleri de farklı olmalıdır.

Bir rota sızıntısının nedenini tespit etmek için, bağlı iki operatör arasındaki ilişkiyi bulmanız ve Gao-Rexford biçimsel modelini bozan BGP rotalarını (bir BGP toplayıcısından) bulmanız gerekir; daha fazla bilgi için lütfen CAIDA’nın “AS ilişkileri” bölümüne bakın. Saldırıları tespit etmek için, hangi ön eklerin hangi ISS’lere ait olduğu konusunda gerçek bir bilgiye ihtiyacınız vardır ve çoğu durumda, kayıtlı olmayan bir ön ek ISS çifti göründüğünde alarm verin veya harekete geçin.

Saldırıları önlemek/azaltmak için, tek bir Önek Kaynak Doğrulama çerçevesi içinde iki standart yaklaşım vardır. IRR’nize bir Rota nesnesi kaydedebilir veya bir ROA nesnesi oluşturabilirsiniz. Ekibimiz, RIPE79 sırasında bu yaklaşımlar arasındaki farkları açıkladı. Ancak ortak olan şey, her ikisinin de hangi öneklerin hangi operatörlere ait olduğunu (operatörlerin kendileri tarafından) belirtmesi ve kayıtlı olmayan öneklere sahip bir ISP’den gelen rotaları (transit ISP’ler tarafından) engellemeye çalışmasıdır. Saf rota sızıntılarını önlemek/azaltmak için, bir BGP açık politikası oluşturulmasına katılıyoruz. Diğer bir yaklaşım ise eş kilitlemedir – AS_PATH’te beklenmeyen komşulara/ISP’lere sahip rotaları engellemek. ASPA IETF taslağı, saf saldırı/rota sızıntısı önlemesinden biraz ayrı duruyor çünkü daha çok kötü AS_PATH’leri engellemekle ilgili (kötü AS_PATH manipülasyonu olan veya olmayan rota sızıntısı durumları ve saldırılar).

ROA ve Yönlendirme Sızıntıları

Peki, ROA imzalama ve ROA filtreleme uygularsanız ağınız güvenli mi? Hayır, çünkü ASPA veya eşdeğeri olmadan, ROA tek başına başkalarının yönlendirme sızıntısı yapmasını engelleyemez. Umarız şimdi bu sorunun ne kadar karmaşık olduğunu ve modern alanlar arası yönlendirmenin temelini oluşturan Sınır Ağ Geçidi Protokolü’nü güvence altına almak için ayrı yaklaşımlara ihtiyaç duyulduğunu anlıyorsunuzdur.

ROA İmzalama ve ROA Filtreleme Karşılaştırması

ROA ile ilgili bir diğer yaygın yanılgı da şudur: ROA algoritmalarında iki taraf bulunur: imzalayan taraf – operatör, sahip olduğu ön ekler hakkında gerçek bilgileri sağlar; ve filtreleyen taraf – geçiş operatörü, imzalayan tarafın sağladığı bilgilere göre kötü rotaları filtreler.

Bir uç operatör (yani yalnızca bir yukarı akış sağlayıcısı olan bir AS) olarak, filtreleme taraflarının sayısını etkileyebileceğiniz yol sayısı sınırlıdır. Bunların sayısı ne kadar fazla olursa, ön ekleriniz o kadar güvenli olur (bir korsanın ön eklerinize saldırmaya karar vermesi durumunda etkilenen bölge sayısı o kadar az olur). Ön eklerinizi imzalamaya karar verirseniz, yakın gelecekte yalnızca büyüyecek olan mevcut bir filtreleme altyapısını kullanabilirsiniz. Dahası, AS’nizin arkasındaki ağın büyüklüğünden bağımsız olarak, tam olarak bunu yapmanızı teşvik ediyoruz.

Bu makale yine de bir uyarı ile sona eriyor: mevcut filtreleme altyapısı hala kusursuz olmayabilir ve bazı durumlarda, seçilen maksimum uzunluk seçeneği ve ISS’nizin tarafındaki ROA filtrelemesi nedeniyle etkilenen bir bölgeden gelen trafiğinizi geri döndüremeyebilirsiniz.

Bu materyalin pratik uygulaması hakkında benimle özel mesaj yoluyla daha detaylı görüşebilirsiniz. İletişim bilgileri bu web sitesinin ilgili bölümünde yer almaktadır.
06.02.2026
В чём разница между утечками маршрутов BGP leaking и перехватом BGP hijack?
Одной из основных функций служб мониторинга и аналитики глобальной маршрутизации BGP является отслеживание специфических аномалий, которые могут привести к сетевому инциденту, который мы бы далее будем называть утечкой маршрута BGP route leaking или захватом BGP route hijack.

Оба инструмента перенаправляют трафик третьей стороне по сравнению с состоянием маршрутизации без аномалий, но по-разному. За последние несколько лет было приложено много усилий для решения проблем утечек маршрутов, но до сих пор существуют недопонимание относительно того, что к чему и как всевозможные инструменты мониторинга помогают решать разные проблемы с безопасностью маршрутизации.

Мы начали собирать данные о модели сетевых взаимосвязей BGP за пару лет до появления RFC 7908, пытаясь определить, что является утечкой маршрутов, а что преднамеренным захватом адресного пространства с использованием BGP. Два основных различия между этими событиями были описаны следующим образом:
- Маршруты, перенаправленные через неправильные ASN/каналы (утечки маршрутов), описанные как типы 1-4 RFC 7908.
- Маршруты, перенаправленные на неправильные ASN (перехват трафика), описанные как типы 5 и 6 RFC 7908.
Трафик при утечке маршрута BGP, предназначенный для вашей сети, скорее всего, будет передаваться неэффективно, что может привести к увеличению задержки прохождения пакетов к вашей сети или их полной потере. Тем не менее, в этом случае трафик почти наверняка всегда достигнет вашей сети, если нет критической перегрузки сети по какой-либо причине (например, из-за злонамеренных действий нарушителя правил маршрутизации). При перехвате маршрута BGP трафик, предназначенный для вашей сети, перенаправляется третьей стороне и приземляется где-то там. Кроме того, механизмы создания таких аномалий также различаются. Для создания утечки маршрута необходимо передать корректный маршрут неподходящему соседнему интернет-провайдеру. Для создания перехвата маршрута необходимо либо объявить маршрут с более коротким или как его ещё называют специфичным для допустимого префикса, чтобы привлечь весь трафик от интернет-провайдеров, получивших такое объявление, с любым желаемым AS_PATH, либо начать анонсировать маршрут с префиксом третьей стороны из вашей сети. Поскольку механизмы создания маршрутных аномалий различаются, механизмы обнаружения инцидентов и предотвращения или смягчения последствий тоже будут различаться.

Для обнаружения причины утечки маршрута необходимо выяснить взаимосвязь между каждым из двух подключенных операторов и найти такие маршруты BGP (из коллектора BGP), которые нарушают формальную модель Gao-Rexford, для получения дополнительной информации смотрите раздел «Взаимосвязи AS» в документации CAIDA. Для обнаружения перехватов трафика необходимы достоверные данные о том, какие префиксы принадлежат каким интернет-провайдерам, и в большинстве случаев, когда появляется незарегистрированная пара префикс/ISP, — необходимо создать оповещение или принять меры.

Для предотвращения или смягчения последствий перехвата трафика в рамках единой системы проверки происхождения префиксов используются два стандартных подхода. Можно зарегистрировать объект Route в вашем IRR или создать объект ROA. Наша команда описала различия между этими подходами на конференции RIPE79. Однако общим является то, что оба подхода определяют, какие префиксы принадлежат каким операторам, и пытаются блокировать маршруты от интернет-провайдера в случае анонсирования им незарегистрированных за ним префиксов (внезапно ставшим транзитным интернет-провайдером). Для предотвращения или смягчения последствий чистых утечек маршрута мы участвуем в создании открытой политики BGP. Другой подход — блокировка маршрутов с неожиданными соседями или провайдерами интернет-услуг в AS_PATH. Проект ASPA IETF несколько отличается от чистого предотвращения перехвата трафика или утечек маршрутов, поскольку он больше направлен на блокировку некорректных AS_PATH в случае утечки маршрутов и перехвата без или с некорректной обработкой AS_PATH.

ROA против утечек маршрутов

Итак, безопасна ли ваша сеть, если вы используете подписи и фильтрацию ROA? Нет, потому что без ASPA или любого аналогичного протокола сам по себе ROA не предотвратит утечки маршрутов другими пользователями. Мы надеемся, что теперь вы понимаете, насколько сложна эта проблема, где для обеспечения безопасности основ современной междоменной маршрутизации — протокола Border Gateway Protocol — необходим отдельный подход.

Подписи ROA против фильтрации ROA

Ещё одно распространённое заблуждение связано с алгоритмом ROA. В алгоритмах ROA участвуют две стороны: подписывающая сторона — оператор связи, предоставляющий достоверную информацию о принадлежащих ему префиксах, и фильтрующая сторона — магистральный или транзитный оператор, отфильтровывающий некорректные маршруты на основе информации, предоставленной подписывающей стороной.

Как оператор-заглушка (то есть автономная система с одним вышестоящим провайдером), вы ограничены в количестве способов влияния на число фильтрующих сторон. Чем больше их, тем безопаснее будут ваши префиксы (тем меньше регионов пострадает, если нарушитель маршрутизации решит захватить ваши префиксы). Если вы решите подписать свои префиксы, вы можете использовать существующую инфраструктуру фильтрации, которая будет только расти в ближайшем будущем. Более того, мы рекомендуем вам сделать именно это в любом случае, независимо от размера сети вашей автономной системы.

В конце статьи все же следует предупредить – существующая инфраструктура фильтрации может быть несовершенной, и в некоторых случаях вы не сможете вернуть себе свой трафик из затронутого региона из-за выбранного параметра максимальной длины и фильтрации ROA со стороны вашего интернет-провайдера.

Более подробно обсудить со мной вопрос практического применения этого материала можно в личных сообщениях. Контактные данные указаны в соответствующем разделе этого сайта.
01.02.2026
Яка різниця між витоками BGP Route Leaks та BGP Hijacks?
Однією з основних функцій сервісу моніторингу та аналітики BGP є моніторинг певних аномалій, які можуть призвести до інциденту, який ми б далі назвали або витоком маршруту BGP, або перехопленням BGP.

Обидва вони перенаправляють трафік третім сторонам, порівняно зі станом без аномалій, але по-різному. Протягом останніх кількох років було вкладено багато зусиль у вирішення цих проблем, але все ще існують непорозуміння щодо того, що є що і як різні інструменти допомагають вирішувати різні проблеми.

Ми почали збирати модель зв’язків BGP за кілька років до появи RFC 7908, намагаючись визначити, що таке витік маршруту BGP. Дві основні відмінності між цими подіями за часом були описані як:
- Маршрути, перенаправлені через неправильні ASN/посилання (витоки маршруту), описані як типи 1-4 RFC 7908
- Маршрути, перенаправлені на неправильні ASN (перехоплення), описані як типи 5 та 6 RFC 7908
Під час витоку маршруту BGP трафік, призначений для вашої мережі, найімовірніше, буде проходити неефективно, що може призвести до збільшення затримки мережі та втрати пакетів. Тим не менш, він майже напевно досягне вашої мережі, якщо немає критичного перевантаження мережі з якоїсь причини (наприклад, через злий намір зловмисника). Під час захоплення BGP трафік, призначений для вашої мережі, перенаправляється до третьої сторони та залишається там. Крім того, механізми створення таких аномалій також різні. Щоб створити витік маршруту, вам потрібно передати хороший маршрут невідповідному сусідньому інтернет-провайдеру. Щоб створити захоплення, вам потрібно або оголосити маршрут із підпрефіксом/точніше, з дійсним префіксом (щоб залучити весь трафік від інтернет-провайдерів, які отримали таке оголошення, з будь-яким AS_PATH), або створити оголошення маршруту зі стороннім префіксом з вашої мережі. Оскільки механізми створення аномалій маршрутизації різняться, механізми виявлення та запобігання/пом’якшення інцидентів повинні бути різними.

Щоб виявити причину витоку маршруту, вам потрібно з’ясувати зв’язок між кожним із двох підключених операторів та знайти такі BGP-маршрути (від колектора BGP), які порушують формальну модель Гао-Рексфорда. Для отримання додаткової інформації зверніться до “AS-зв’язків” CAIDA. Щоб виявити викрадання, вам потрібна достовірна інформація про те, які префікси належать яким інтернет-провайдерам, і в більшості випадків, коли з’являється незареєстрована пара префіксів ISP, створіть тривогу або вживіть заходів.

Для запобігання/пом’якшення викрадань існує два стандартні підходи в рамках єдиної системи перевірки походження префіксів. Ви можете зареєструвати об’єкт Route у своєму IRR або створити об’єкт ROA. Наша команда описала відмінності між цими підходами під час RIPE79. Однак спільне те, що вони обидва вказують, які префікси належать яким операторам (самими операторами) та намагаються блокувати маршрути від інтернет-провайдера з незареєстрованими префіксами (транзитними інтернет-провайдерами). Щоб запобігти/пом’якшити витоки чистих маршрутів, ми беремо участь у створенні політики відкритості BGP. Інший підхід — це блокування вузлів — блокування маршрутів з неочікуваними сусідами/провайдерами в AS_PATH. Проект ASPA IETF дещо стоїть осторонь від чистого запобігання перехопленням/витокам маршрутів, оскільки він більше стосується блокування поганих AS_PATH (випадків витоків маршрутів та перехоплень без/з поганою маніпуляцією AS_PATH).

ROA проти витоків маршрутів

Отже, чи безпечна ваша мережа, якщо ви впровадите підписання ROA та фільтрацію ROA? Ні, тому що без ASPA або будь-якого еквівалента, ROA сам по собі не зупинить витік маршрутів іншими. Ми сподіваємося, що тепер ви бачите, наскільки складною є ця проблема, де потрібні окремі підходи для забезпечення основи сучасної міждоменної маршрутизації – протоколу Border Gateway Protocol.

Підписання ROA проти фільтрації ROA

Ще одна поширена помилка пов’язана з ROA. В алгоритмах ROA є дві сторони: сторона підписання – оператор, який надає достовірну інформацію про префікси, якими він володіє; і є сторона фільтрації – транзитний оператор, який фільтрує погані маршрути відповідно до інформації, наданої стороною підписання.

Як оператор-заглушка (тобто AS лише з одним постачальником вище), ви обмежені в кількості способів впливу на кількість сторін фільтрації. Чим більше їх, тим безпечнішими будуть ваші префікси (тим менше регіонів постраждає, якщо зловмисник вирішить атакувати ваші префікси). Якщо ви вирішите підписати свої префікси, ви можете використовувати існуючу інфраструктуру фільтрації, яка лише зростатиме найближчим часом. Більше того, ми закликаємо вас робити саме це в будь-якому випадку, тобто незалежно від розміру мережі за вашим ASN.

Ця стаття все одно закінчиться попередженням: поточна інфраструктура фільтрації може бути недосконалою, а в деяких випадках ви не можете повернути свій трафік із ураженого регіону через обраний варіант максимальної довжини та фільтрацію ROA з боку вашого інтернет-провайдера.

Детальніше обговорити зі мною питання практичного застосування цього матеріалу можна в особистих повідомленнях. Контактні дані наведено у відповідному розділі цього сайту.
20.01.2026