Інтернет здається сильною, незалежною та непорушною структурою. Теоретично, міцності мережі вистачить, щоб пережити ядерний вибух. Насправді інтернет може впустити один маленький роутер. Все через те, що інтернет - це нагромадження протиріч, уразливостей, помилок та роликів про котиків. Основа інтернету – протокол BGP – містить купу проблем. Дивно, що він ще дихає. Крім помилок у самому інтернеті, його ще ламають усі кому не ліньки: великі інтернет-провайдери, корпорації, держави та DDoS-атаки. Що з цим робити і як із цим жити?
Відповідь знає Олексій Учакін () - Лідер команди мережевих інженерів в компанії IQ Option. Головне його завдання – доступність платформи для користувачів. У розшифровці доповіді Олексія на поговоримо про BGP, DDOS-атаки, рубильник від інтернету, помилки провайдерів, децентралізацію та випадки, коли маленький роутер відправив інтернет поспати. Насамкінець — пара порад, як усе це пережити.
День, коли Інтернет зламався
Я наведу лише кілька інцидентів, коли в Інтернеті ламався зв'язок. Це буде достатньо для повної картини.
"Інцидент з AS7007". Вперше інтернет зламався у квітні 1997. У ПЗ одного роутера з автономної системи 7007 була помилка. Раптом роутер проанонсував сусідам свою внутрішню таблицю маршрутизації і відправив половину мережі в black hole.
"Пакистан проти YouTube". 2008 року браві хлопці з Пакистану вирішили заблокувати у себе YouTube. Зробили вони це настільки добре, що без котиків залишилося півсвіту.
«Захоплення префіксів VISA, MasterCard та Symantec компанією Ростелеком». У 2017 році Ростелеком помилково почав анонсувати префікси VISA, MasterCard та Symantec. В результаті фінансовий трафік попрямував через канали, які контролює провайдер. Витік тривав недовго, але фінансовим компаніям було неприємно.
"Google проти Японії". У серпні 2017 року Google почав анонсувати в частині своїх аплінків префікси великих японських провайдерів NTT і KDDI. Трафік вирушив до Google як транзитний, швидше за все, помилково. Оскільки Google це не провайдер і транзитний трафік не пропускає, значна частина Японії залишилася без Інтернету.
"DV LINK захопив префікси Google, Apple, Facebook, Microsoft". У тому ж 2017 році російський провайдер DV LINK почав навіщось анонсувати мережі Google, Apple, Facebook, Microsoft і деяких інших великих гравців.
«eNet із США захопив префікси AWS Route53 та MyEtherwallet». У 2018 році провайдер з Огайо або хтось із його клієнтів проанонсував мережі Amazon Route53 та криптогаманець MyEtherwallet. Атака пройшла успішно: навіть незважаючи на самопідписаний сертифікат, попередження про яке з'являлося користувачеві при заході на сайт MyEtherwallet, багато гаманців викрали і вкрали частину криптовалюти.
Подібних інцидентів лише за 2017 рік було понад 14 тисяч! Мережа все ще децентралізована, тож ламається не все і не у всіх. Але інциденти відбуваються тисячами і всі вони пов'язані з протоколом BGP, на якому працює інтернет.
BGP та його проблеми
протокол BGP — Border Gateway Protocol, вперше був описаний у 1989 році двома інженерами з IBM та Cisco Systems на трьох "серветках" - аркушах формату А4. Ці досі лежать у головному офісі Cisco Systems у Сан-Франциско як реліквія мережевого світу.
В основі протоколу взаємодія автономних систем - Autonomous Systems або скорочено - AS. Автономна система - це просто певний ID, за яким у публічному реєстрі закріплені мережі IP. Роутер з таким ID може анонсувати ці мережі. Відповідно будь-який маршрут в інтернеті можна представити у вигляді вектора, який називають AS Path. Вектор складається з номерів автономних систем, які потрібно пройти, щоб досягти мережі призначення.
Наприклад, є мережа з певної кількості автономних систем. Потрібно потрапити із системи AS65001 в систему AS65003. Шлях однієї системи представлений AS Path на схемі. Він складається із двох автономок: 65002 та 65003. Для кожної адреси призначення є вектор AS Path, який складається з номерів автономних систем, які нам потрібно пройти.
То які у BGP проблеми?
BGP – це протокол довіри
Протокол BGP - trust based. Це означає, що ми за промовчанням довіряємо нашому сусідові. Це особливість багатьох протоколів, які розроблялися на зорі інтернету. Розберемося, що означає «довіряємо».
Немає аутентифікації сусіда. Формально є MD5, але MD5 у 2019 році — таке…
Немає фільтрації. У BGP є фільтри і вони описані, але ними не користуються або користуються неправильно. Пізніше поясню чому.
Дуже просто встановити сусідство. Налаштування сусідства в протоколі BGP майже на будь-якому роутері — кілька рядків конфігу.
Не потрібні права на керування BGP. Не потрібно складати іспити, які підтвердять вашу кваліфікацію. Ніхто не відбере права за налаштування BGP у п'яному вигляді.
Дві основні проблеми
Викрадення префіксів — prefix hijacks. Викрадення префікса — анонсування мережі, яка вам не належить, як у випадку з MyEtherwallet. Ми взяли деякі префікси, домовилися з провайдером або зламали його і через нього анонсуємо ці мережі.
Витоку маршрутів — route leaks. З витоками трохи складніше. Витік - це зміна AS Path. У кращому випадку зміна призведе до більшої затримки, тому що потрібно пройти маршрут довшим або менш ємним лінком. У гіршому — повториться нагода з Google і Японією.
Сам Google не є оператором і не транзитною автономною системою. Але коли він проанонсував своєму провайдеру мережі японських операторів, то трафік через Google за AS Path бачився як пріоритетніший. Трафік пішов туди і тремтів просто тому, що налаштування маршрутизації всередині Google складніше, ніж просто фільтри на кордоні.
Чому не працюють фільтри?
Всім все одно. Це головна причина – усім байдуже. Адмін маленького провайдера або компанії, яка підключилася до провайдера BGP, узяв MikroTik, налаштував на ньому BGP і навіть не знає, що там можна налаштовувати фільтри.
Помилки конфігурації. Щось дебажили, помилилися в масці, поставили не ту сіточку — і ось знову помилка.
Немає технічної можливості. Наприклад, у провайдерів зв'язку багато клієнтів. Розумно слід автоматично оновлювати фільтри для кожного клієнта — стежити, що у нього з'являється нова мережа, що він здав свою мережу комусь в оренду. Стежити за цим складно, руками ще складніше. Тому ставлять просто розслаблені фільтри або ставлять фільтри взагалі.
Винятки. Бувають винятки для улюблених та великих клієнтів. Особливо у випадку з міжоператорськими стиками. Наприклад, у Транстелеком та Ростелеком купа мереж і між ними стик. Якщо стик ляже - добре нікому не буде, тому фільтри розслаблюють або прибирають зовсім.
Застаріла або неактуальна інформація в IRR. Фільтри будуються на основі інформації, яка записана в IRR — Internet Routing Registry. Це реєстри регіональних інтернет-реєстраторів. Часто в реєстрах застаріла чи неактуальна інформація, або всі разом.
Хто такі ці реєстратори?
Усі адреси в інтернеті належать організації IANA - Internet Assigned Numbers Authority. Коли ви купуєте у когось мережу IP, то купуєте не адреси, а право їх використання. Адреси — це нематеріальний ресурс, і за загальною домовленістю вони належать агентству IANA.
Система працює так. IANA делегує управління IP-адресами та номерами автономних систем п'ятьом регіональним реєстраторам. Ті видають автономні системи LIR – локальним інтернет-реєстраторам. Далі LIR виділяють IP-адреси кінцевим користувачам.
Недолік системи в тому, що кожен із регіональних реєстраторів веде свої реєстри по-своєму. У кожного свої погляди на те, яка інформація має міститись у реєстрах, хто її повинен чи не повинен перевіряти. В результаті виходить бардак, який є зараз.
Як ще можна боротися із цими проблемами?
IRR - посередня якість. З IRR зрозуміло – там усе погано.
BGP-communities. Це деякий атрибут, описаний у протоколі. Ми можемо навісити, наприклад, спеціальну community на наш анонс, щоб сусід не відправляв наші мережі своїм сусідам. Коли у нас лінк P2P, ми обмінюємось лише своїми мережами. Щоб випадково маршрут не пішов до інших мереж, ми навішуємо community.
Community не транзитивні. Це завжди договір на двох, і це їхній недолік. Ми не можемо навісити якесь товариство, за винятком одного, яке приймається за умовчанням усіма. Ми не можемо бути впевнені, що це community все приймуть і правильно інтерпретують. Тому, в кращому випадку, якщо ви домовитеся зі своїм uplink, він зрозуміє, що ви від нього хочете по community. Але може не зрозуміти його сусіда, або оператор просто скине вашу мітку, і ви не досягнете того, чого хотіли.
RPKI + ROA вирішує лише малу частину проблем. RPKI - це Resource Public Key Infrastructure - Спеціальний фреймворк для підписування маршрутної інформації. Хороша ідея, щоб змусити LIR-ів та їх клієнтів вести актуальну базу адресного простору. Але із ним є одна проблема.
RPKI – це ще й ієрархічна система відкритих ключів. IANA має ключ, від якого створюються ключі RIR, а від них ключі LIR? якими вони підписують свій адресний простір за допомогою ROAs — Route Origin Authorisations:
— Я запевняю, що цей префікс анонсуватиметься від імені цієї автономки.
Крім ROA є й інші об'єкти, але про них якось потім. Здається, що штука хороша та корисна. Але вона не захищає нас від витоків від слова «зовсім» і не вирішує всі проблеми з угонами префіксів. Тому гравці не дуже поспішають її запроваджувати. Хоча вже від великих гравців типу AT&T і великих IX є запевнення, що префікси з invalid-записом ROA будуть дропатися.
Можливо вони це робитимуть, але поки що у нас величезна кількість префіксів, які ніяк не підписані. З одного боку, незрозуміло, чи вони анонсуються валідно. З іншого боку, ми не можемо їх тремтіти за замовчуванням, бо не впевнені в тому, правильно це чи ні.
Що ще є?
BGPSec. Це кльова штука, яку вигадали академіки для мережі рожевих поні. Вони сказали:
— У нас є RPKI+ROA — механізм засвідчення підпису адресного простору. Давайте заведемо окремий BGP-атрибут та назвемо його BGPSec Path. Кожен роутер підписуватиме своїм підписом анонси, які він анонсує сусідам. Так ми отримаємо довірений шлях із ланцюжка підписаних анонсів та зможемо його перевірити.
Теоретично добре, але в практиці багато проблем. BGPSec ламає багато існуючих механік BGP на вибір next-hop та управління вхідним/вихідним трафіком безпосередньо на маршрутизаторі. BGPSec не працює, поки його не впровадять 95% учасників всього ринку, що саме собою утопія.
BGPSec має величезні проблеми з продуктивністю. На поточному залозі швидкість перевірки анонсів приблизно 50 префіксів на секунду. Для порівняння: поточна таблиця інтернету в 700 000 префіксів заливатиметься 5 годин, за які ще 10 разів зміниться.
BGP Open Policy (Role-based BGP). Нова пропозиція на основі моделі Гао-Рексфорд. Це два вчені, які займаються дослідженням BGP.
Модель Гао-Рексфорда ось у чому. Якщо спрощувати, у випадку з BGP є невелика кількість типів взаємодій:
- Provider Customer;
- P2P;
- внутрішня взаємодія, припустимо, iBGP.
З ролі маршрутизатора вже можна за умовчанням навішувати деякі політики імпорту/експорту. Адміністратору не потрібно конфігурувати префікс-аркуші. На підставі ролі, про яку домовляться між собою маршрутизатори і яку можна виставити, ми вже отримуємо деякі дефолтні фільтри. Зараз це draft, який обговорюється у IETF. Сподіваюся, що скоро ми побачимо це у вигляді RFC та імплементації на залозі.
Великі Інтернет-провайдери
Розглянемо на прикладі провайдера CenturyLink. Це третій за величиною провайдер США, який обслуговує 37 штатів та має 15 дата-центрів.
У грудні 2018 року CenturyLink лежав на ринку США 50 годин. Під час інциденту були проблеми із роботою банкоматів у двох штатах, кілька годин не працював номер 911 у п'яти штатах. До купи зірвали лотерею в Айдахо. За цим інцидентом комісія з електрозв'язку США зараз розслідує.
Причина трагедії в одній мережній картці в одному центрі дату. Картка вийшла з ладу, відправляла некоректні пакети та всі 15 дата-центрів провайдера лягли.
Для цього провайдера не спрацювала ідея «занадто великий, щоб впасти». Ця ідея взагалі не працює. Можна взяти будь-якого великого гравця і покласти якоюсь дрібницею. У США все ще добре зі зв'язаністю. Клієнти CenturyLink, які мали резерв, масово пішли в нього. Потім альтернативні оператори скаржилися на навантаження своїх лінків.
Якщо ляже умовний «Казахтелеком», то вся країна залишиться без інтернету.
Корпорації
Напевно, на Google, Amazon, FaceBook та інших корпораціях тримається інтернет? Ні, вони його теж ламають.
У 2017 році у Санкт-Петербурзі на конференції ENOG13 Джефф Х'юстон з АПНІК представив . У ньому йдеться, що ми звикли, що взаємодія, потоки грошей та трафік в інтернеті вертикальні. У нас є маленькі провайдери, які платять за пов'язаність більшим, а ті вже платять за зв'язаність до глобального транзиту.
Нині ми маємо таку вертикально-орієнтовану структуру. Все б добре, але світ змінюється — великі гравці будують свої трансокеанські кабелі для власних backbones.
Новина про CDN-кабель.
У 2018 році TeleGeography випустив дослідження, що більше половини трафіку в інтернеті – це вже не інтернет, а backbones CDN великих гравців. Це трафік, який стосується Інтернету, але це вже не та мережа, про яку ми говорили.
Інтернет розпадається на великий набір мереж, що слабо пов'язані один з одним.
У Microsoft є своя мережа, у Google — своя, і вони слабко перетинаються. Трафік, який зародився десь у США, йде каналами Microsoft через океан до Європи десь на CDN, далі через CDN чи IX стикується з вашим провайдером і потрапляє до вас у роутер.
Децентралізація зникає.
Ця сильна сторона інтернету, яка допоможе йому вижити після ядерного вибуху, втрачається. З'являються місця концентрації користувачів та трафіку. Якщо ляже умовний Google Cloud — багато постраждалих разом. Частково ми це відчули, коли Роскомнагляд заблокував AWS. А на прикладі CenturyLink видно, що для цього вистачить і дрібниці.
Раніше ламалося не все та не у всіх. У майбутньому ми можемо прийти до того, що, вплинувши на одного великого гравця, можна поламати багато чого, де і багато у кого.
держави
Наступні на черзі держави і з ними відбувається зазвичай так.
Тут наш Роскомнагляд взагалі навіть жодного разу не є піонером. Подібна практика Internet shutdown є в Ірані, Індії, Пакистані. В Англії є законопроект щодо можливості відключення інтернету.
Будь-яка держава хоче отримати рубильник для відключення інтернету або повністю, або частинами: Twitter, Telegram, Facebook. Вони не те щоб не розуміють, що у них це ніколи не вийде, але дуже цього хочуть. Застосовують рубильник, як правило, з політичною метою — для усунення політичних конкурентів, або вибори на носі, або російські хакери знову щось зламали.
DDoS атаки
Не буду забирати хліб у товаришів з Qrator Labs, вони це роблять набагато краще за мене. У них є за стабільністю інтернету. І ось що вони написали у звіті за 2018 рік.
Середня тривалість DDoS-атак падає до 2.5 годин. Атакуючі теж починають рахувати гроші, і якщо ресурс не ліг відразу, то його швидко дають спокій.
Зростає інтенсивність атак. У 2018 році ми бачили 1.7 Тб/с на мережі Akamai, і це не межа.
З'являються нові вектори атак та посилюються старі. З'являються нові протоколи, схильні до ампліфікації, з'являються нові атаки на існуючі протоколи, особливо на TLS і подібні.
Більшість трафіку - мобільні пристрої. При цьому інтернет-трафік переходить на мобільних клієнтів. Із цим потрібно вміти працювати як тим, хто атакує, так і тим, хто захищається.
Невразливих – ні. Це головна думка - не існує і не з'явиться універсальний захист, який точно захистить від будь-якого DDoS.
Систему не можна покласти лише тоді, коли вона не підключена до інтернету.
Сподіваюся, я вас досить налякав. Тепер подумаємо, що з цим робити.
Що робити?!
Якщо у вас є вільний час, бажання та знання англійської мови — беріть участь у робочих групах: IETF, RIPE WG. Це відкриті mail-листи, підписуйтесь на розсилки, беріть участь у обговореннях, приїжджайте на конференції. Якщо ви маєте статус LIR, то можете голосувати, наприклад, у RIPE за різні ініціативи.
Для простих смертних це моніторинг. Щоб знати, що зламалося.
Моніторинг: що перевіряти?
Звичайний Ping, причому не лише бінарна перевірка – працює чи ні. Записуйте RTT в історію, щоб потім дивитися аномалії.
Traceroute. Це службова програма визначення маршрутів прямування даних у мережах TCP/IP. Допомагає виявляти аномалії та блокування.
HTTP checks-перевірки custom URL та TLS certificates допоможуть виявити блокування або заміну DNS для атаки, що майже одне й те саме. Блокування часто виконуються заміною DNS та з загортанням трафіку на сторінку заглушки.
Якщо є можливість, то з ваших клієнтів перевіряйте resolve вашого origin з різних місць, якщо у вас є додаток. Так ви знайдете аномалії перехоплення DNS, чим іноді грішать провайдери.
Моніторинг: звідки перевіряти?
Універсальної відповіді немає. Перевіряйте, звідки приходить користувач. Якщо користувачі сидять у Росії – перевіряйте з Росії, але не обмежуйтесь їй. Якщо ваші користувачі живуть у різних регіонах, перевіряйте з цих регіонів. Але найкраще з усього світу.
Моніторинг: чим перевіряти?
Я вигадав три способи. Якщо знаєте більше – напишіть у коментарях.
- RIPE Atlas.
- Комерційний моніторинг.
- Своя мережа віртуалок.
Поговоримо про кожного з них.
RIPE Atlas - Це така маленька коробочка. Для тих, хто знає вітчизняний «Ревізор» — це така сама коробочка, але з іншою наклейкою.
RIPE Atlas - безкоштовна програма. Ви реєструєтеся, отримуєте поштою роутер і вмикаєте його в мережу. За те, що хтось інший користується вашою пробою, вам капають деякі кредити. На ці кредити ви можете самі проводити якісь дослідження. Можна тестувати по-різному: ping, traceroute, перевіряти сертифікати. Покриття досить велике, багато нід. Але є нюанси.
Система кредитів не дозволяє будувати продакшн-рішення. Кредитів на постійне дослідження чи комерційний моніторинг не вистачить. Кредитів вистачає на коротке вивчення чи one-time перевірку. Денна норма з однієї проби з'їдається 1-2 перевірками.
Покриття нерівномірне. Так як програма безкоштовна в обидві сторони, покриття хороше в Європі, в європейській частині Росії і деяких регіонах. Але якщо вам потрібна Індонезія чи Нова Зеландія, то все гірше — 50 проб на країну може не набратися.
Не можна перевіряти http з проби. Це спричинено технічними нюансами. Обіцяють пофіксувати в новій версії, але поки що http перевіряти не можна. Можна перевірити лише сертифікат. Якийсь http check можна зробити лише до спеціального пристрою RIPE Atlas, який називається Anchor.
Другий спосіб - комерційний моніторинг. З ним все добре, ви ж гроші платите? Вам обіцяють кілька десятків або сотень точок моніторингу по всьому світу, малюють гарні дашборди із коробки. Але, знову ж таки, є проблеми.
Це платно, місцями дуже. Моніторинг пінгом, перевірки з усього світу та безліч http-перевірок можуть коштувати кілька тисяч доларів на рік. Якщо фінанси дозволяють і вам подобається це рішення, будь ласка.
Покриття може не вистачати в регіоні, що цікавить. Тим самим пінгом уточнюють максимум абстрактну частину світу — Азію, Європу, Північну Америку. Рідкісні системи моніторингу можуть деталізувати пробу конкретної країни чи регіону.
Слабка підтримка custom-тестів. Якщо вам потрібно щось кастомне, а не просто «курлик» на url, то із цим теж проблеми.
Третій спосіб – свій моніторинг. Це класика: "А давайте напишемо своє!"
Свій моніторинг перетворюється на розробку програмного продукту, причому розподіленого. Ви шукаєте провайдера інфраструктури, дивіться, як це деплоїти та моніторити — моніторинг треба моніторити, правильно? А ще потрібна підтримка. Десять разів подумайте, перш ніж за це візьметеся. Можливо, простіше заплатити будь-кому, хто це зробить за вас.
Моніторинг BGP-аномалій та DDoS-атак
Тут за доступними ресурсами все ще простіше. BGP-аномалії виявляються за допомогою спеціалізованих сервісів типу QRadar, BGPmon. Вони приймають full view-таблицю від багатьох операторів. На підставі того, що вони бачать від різних операторів, можуть виявити аномалії, шукати ампліфікатори та інше. Зазвичай реєстрація безкоштовна - забиваєте номер своєї автономки, підписуєтеся на повідомлення на пошту, і сервіс алертить ваші проблеми.
У моніторингу DDoS-атак також все просто. Як правило, це NetFlow-based та логи. Є спеціалізовані системи типу FastNetMon, модулі для Сплин. На крайній випадок є ваш постачальник DDoS захисту. Йому теж можна зливати NetFlow і на його підставі він сповіщатиме вас про атаки у ваш бік.
Висновки
Не маєте ілюзій — інтернет обов'язково зламається. Зламається не все і не у всіх, але 14 тисяч інцидентів за 2017 рік натякають, що інциденти будуть.
Ваше завдання — помітити проблеми якомога раніше. Як мінімум, не пізніше ніж ваш користувач. Мало того, що слід помітити, завжди тримайте в запасі «план Б». План — це стратегія, що ви робитимете, коли все зламається: резервні оператори, ДЦ, CDN. План — це окремий чек-лист, яким перевіряєте роботу всього. План повинен працювати без залучення мережевих інженерів, тому що їх зазвичай замало, і вони хочуть спати.
На цьому все. Бажаю вам високої доступності та зеленого моніторингу.
Наступного тижня у Новосибірську очікується сонце, хайлоад та висока концентрація розробників на . У Сибіру прогнозується фронт доповідей про моніторинг, доступність та тестування, безпеку та менеджмент. Очікуються опади у вигляді списаних конспектів, нетворкінгу, фотографій та постів у соцмережах. Рекомендуємо відкласти всі справи 24 та 25 червня та . Чекаємо на вас у Сибіру!
Джерело: habr.com