Привіт, мене звуть Олександр Азімов. В Яндексі я займаюся розробкою різних систем моніторингу, а також транспортною мережевою архітектурою. Але сьогодні йтиметься про протокол BGP.
Тиждень тому Яндекс увімкнув ROV (Route Origin Validation) на стиках з усіма пірінг-партнерами, а також із точками обміну трафіку. Про те, навіщо це було зроблено та як це вплине на взаємодію з операторами зв'язку, читайте нижче.
BGP і що з ним не так
Ви, напевно, знаєте, що BGP замислювався як протокол міждоменної маршрутизації. Однак за час шляху кількість юз-кейсів встигла підрости: сьогодні BGP, завдяки численним розширенням, перетворився на message bus, що покриває завдання від операторського VPN до модного нині SD-WAN, і навіть знайшов застосування як транспорт для SDN-like-контролера, що перетворює distance vector BGP у щось схоже на links sate-протокол.
Рис. 1.
Чому BGP отримав (і продовжує отримувати) стільки застосувань? Є дві основні причини:
- BGP - єдиний протокол, що працює між автономними системами (АС);
- BGP підтримує атрибути у форматі TLV (type-length-value). Так, у цьому протокол не самотній, але оскільки його нема чим замінити на стиках між операторами зв'язку, то завжди виявляється вигідніше приробити до нього ще один функціональний елемент, ніж підтримувати додатковий протокол маршрутизації.
Що ж із ним не так? Якщо коротко, у протоколі відсутні вбудовані механізми перевірки коректності отриманої інформації. Тобто BGP — це протокол апріорної довіри: хочете повідомити світ, що тепер вам належить мережа Ростелекому, МТС чи Яндекса, будь ласка!
Фільтр на основі IRRDB — найкращий із найгірших
Виникає питання — чому в такій ситуації інтернет досі працює? Так, працює більшість часу, але при цьому періодично вибухаючи, роблячи цілі національні сегменти недоступними. Незважаючи на те, що хакерська активність у BGP теж зростає, більшість аномалій, як і раніше, виникають завдяки помилкам. Приклад цього року у Білорусі, який на півгодини зробив недоступними значну частину Інтернету для користувачів Мегафону. Інший приклад - зламав одну з найбільших CDN-мереж у світі.
Мал. 2. Перехоплення трафіку Cloudflare
Але чому такі аномалії виникають раз на півроку, а не щодня? Тому що оператори зв'язку використовують зовнішні бази даних маршрутної інформації для перевірки того, що одержують від BGP сусідів. Таких баз даних багато, частина їх управляються реєстраторами (RIPE, APNIC, ARIN, AFRINIC), частина є незалежними гравцями (найвідоміший — RADB), і навіть є цілий набір реєстраторів, що належать великим компаніям (Level3, NTT та інших.). Саме завдяки цим баз даних міждоменна маршрутизація зберігає відносну стабільність своєї роботи.
Проте є нюанси. Перевірка маршрутної інформації здійснюється на основі об'єктів ROUTE-OBJECTS та AS-SET. І якщо перші мають на увазі авторизацію у частини IRRDB, то другого класу авторизація відсутня як клас. Тобто будь-хто можна додати в свої мережі будь-кого і тим самим обійти фільтри вищих постачальників. Більш того, унікальність іменування AS-SET між різними базами IRR не гарантується, що може призводити до дивовижних ефектів з раптовим зникненням зв'язності у оператора зв'язку, який зі свого боку нічого не змінював.
Додаткова проблема – це модель використання AS-SET. Тут два моменти:
- Коли в оператора з'являється новий клієнт, він додає його до свого AS-SET, але практично ніколи його не видаляє;
- Самі фільтри налаштовуються лише на стиках із клієнтами.
В результаті сучасний формат BGP-фільтрів - це фільтри, що поступово деградують, на стиках з клієнтами і апріорна довіра тому, що приходить від пірінг-партнерів і постачальників IP-транзиту.
Що ж змінюється префікс-фільтрам на основі AS-SET? Найцікавіше, що в короткостроковій перспективі нічого. Але з'являються додаткові механізми, що доповнюють роботу фільтрів на основі IRRDB, і в першу чергу це RPKI.
РПКІ
Спрощено можна представити архітектуру RPKI як розподілену базу даних, записи якої можна перевірити криптографічно. У разі ROA (Route Object Authorization) підписувачем виступає власник адресного простору, а сам запис є трійкою (prefix, asn, max_length). По суті, цей запис постулює наступне: власник адресного простору $prefix дозволив АС з номером $asn анонсувати префікси з довжиною не більше ніж $max_length. І маршрутизатори, використовуючи RPKI-кеш, здатні перевіряти на відповідність пару префікс-перша АС у дорозі.
Рис 3. Архітектура RPKI
ROA-об'єкти були стандартизовані вже досить давно, але досі фактично залишалися тільки на папері IETF-журналу. На мій погляд, причина цього страшно звучить — bad marketing. Після завершення стандартизації як стимул стверджувалося, що ROA захищають від угонів BGP — і це було неправдою. Зловмисники можуть легко оминути фільтри на основі ROA, вставивши коректний номер АС на початку шляху. І щойно це усвідомлення приходило, наступним закономірним кроком ставав відмови від використання ROA. І справді, навіщо нам технологія, якщо вона не працює?
Чому ж час змінити свою думку? Бо це не вся правда. ROA не захищає від хакерської активності у BGP, але захищає від випадкових викрадень трафікунаприклад, від витоків статики в BGP, яка зустрічається все частіше. Також, на відміну від фільтрів на основі IRR, ROV може застосовуватися не тільки на стиках із клієнтами, а й на стиках із бенкетами та вищими постачальниками. Тобто разом із впровадженням RPKI з BGP поступово йде апріорна довіра.
Наразі перевірка маршрутів на основі ROA поступово впроваджується ключовими гравцями: найбільші європейські IX вже відкидають некоректні маршрути, з Tier-1-операторів варто виділити AT&T, який увімкнув фільтри на стиках зі своїми пірінг-партнерами. Також до снаряду підходять найбільші постачальники контенту. А десятки транзитних операторів середнього розміру його вже тихо впровадили, нікому про це не сказавши. Навіщо всі ці оператори запроваджують RPKI? Відповідь проста: щоб захистити свій вихідний трафік від чужих помилок. Саме тому Яндекс одним із перших у РФ включає ROV на межі своєї мережі.
Що буде далі?
Наразі ми включили перевірку маршрутної інформації на стиках з точками обміну трафіку та приватними пірингами. У найближчому майбутньому перевірка буде також включена з вищими постачальниками трафіку.
Що це змінює вам? Якщо ви хочете підвищити захищеність маршрутизації трафіку між вашою мережею та Яндексом, ми рекомендуємо:
- Підписати свій адресний простір - Це просто, в середньому займає 5-10 хвилин. Це захистить нашу з вами зв'язність у разі, якщо хтось мимоволі зробить викрадення вашого адресного простору (а це обов'язково станеться рано чи пізно);
- Поставити один із open source RPKI-кешів (, ) і включити перевірку маршрутів на кордоні мережі — це вимагатиме більше часу, але технічних складнощів, знову-таки, не викличе.
Яндекс також підтримує розробку системи фільтрації на основі нового RPKI-об'єкта. (Autonomous System Provider Authorization). Фільтри на основі об'єктів ASPA і ROA здатні не тільки замінити "діряві" AS-SET, але й закрити питання MiTM-атак з використанням BGP.
Я детально розповідатиму про ASPA через місяць на конференції Next Hop. Ще там виступатимуть колеги з Netflix, Facebook, Dropbox, Juniper, Mellanox та Яндекса. Якщо вам цікавий мережевий стек та його розвиток у майбутньому — приходьте, .
Джерело: habr.com