Однією з основних функцій сервісу моніторингу та аналітики 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 з боку вашого інтернет-провайдера.
Leave a Reply