Защо Интернет все още е онлайн?

Интернетът изглежда като силна, независима и непоклатима структура. В теорията, здравината на мрежата е достатъчна, за да оцелее след ядрена експлозия. В реалността, интернет може да рухне заради един малък рутер. Всичко е заради това, че интернетът е натрупване на противоречия, уязвимости, грешки и видеа с котки. Основата на интернет е протокола BGP, който съдържа куп проблеми. Удивително е, че той все още функционира. Освен грешките в самия интернет, той се нарушава от всеки, който не му е приятно: големи интернет доставчици, корпорации, правителства и DDoS атаки. Какво да правим с това и как да живеем с него?

Отговорът знае Алексей Учaкин (Night_Snake) — лидер на екипа от мрежови инженери в компанията IQ Option. Основната му задача е да осигури достъпността на платформата за потребителите. В разшифровката на лекцията на Алексей на Saint HighLoad++ 2019 ще говорим за BGP, DDoS атаки, прекъсване на интернет връзката, грешки на доставчиците, децентрализация и случаи, когато малък рутер е изпратил интернет на сън. В края — няколко съвета как да преживеем всичко това.

Денят, в който Интернетът се счупи

Ще дам само няколко инцидента, когато интернетът е загубил свързаност. Това е достатъчно, за да добием пълна представа.

«Инцидентът с AS7007». За първи път интернетът се счупи през април 1997. В софтуера на един рутер от автономната система 7007 имаше грешка. В някакъв момент рутерът анонсира своята вътрешна таблица за маршрутизиране на съседите си и изпрати половината от мрежата в черна дупка.

«Пакистан срещу 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 000! Мрежата все още е децентрализирана, затова не всичко се пробива и не всички са засегнати. Но инцидентите се случват хиляди, а всички те са свързани с протокола BGP, на който е изградена интернет мрежата.

BGP и неговите проблеми

Протокол BGP — Протокол за граничен шлюз, за първи път е описан през 1989 г. от двама инженери от IBM и Cisco Systems на три «салфетки» — листове с формат А4. Тези «салфетки» до днешен ден лежат в главния офис на Cisco Systems в Сан Франциско като реликва на мрежовия свят.

В основата на протокола е взаимодействието на автономни системи — Автономни системи или накратко — AS. Автономната система е просто определен ID, зад който в публичния регистър са записани IP мрежи. Рутер с такъв ID може да анонсира тези мрежи в света. Съответно, всеки маршрут в интернет може да се представи под формата на вектор, наречен AS Path. Векторът се състои от номера на автономни системи, които трябва да преминем, за да достигнем мрежата на целта.

Например, има мрежа от определен брой автономни системи. Трябва да преминем от система AS65001 в система AS65003. Пътят от една система е представен със AS Path на схемата. Той се състои от две автономни системи: 65002 и 65003. За всеки адрес на целта има вектор AS Path, който се състои от номера на автономни системи, които трябва да преминем.

И така, какви са проблемите на BGP?

BGP е протокол на доверие

Протоколът BGP е базиран на доверие. Това означава, че по подразбиране ние вярваме на нашия съсед. Това е характеристика на много протоколи, разработвани в самото начало на интернет. Нека разберем какво означава «вярваме».

Няма аутентификация на съседа. Формално има 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 — Интернет Рутинг Регистър. Това са регистри на регионални интернет регистратори. Често в регистрите има остаряла или некоректна информация, или и двете.

Кои са тези регистратори?

Всички адреси в интернет принадлежат на организациите IANA — Internet Assigned Numbers Authority. Когато купувате мрежа IP от някого, вие не купувате адресите, а правото да ги използвате. Адресите са нематериален ресурс и по общо споразумение всички те принадлежат на агенцията IANA.

Системата работи по следния начин. IANA делегира управлението на IP адресите и номерата на автономни системи на пет регионални регистратора. Те раздават автономни системи LIR — локални интернет регистратори. После LIR предоставя IP адреси на крайните потребители.

Недостатък на системата е, че всеки от регионалните регистратори води своите регистри по различен начин. Всеки има свои виждания относно това каква информация трябва да съдържа регистърът и кой трябва или не трябва да я проверява. В резултат на това получаваме бъркотия, която съществува в момента.

Как може да се борим с тези проблеми?

IRR — посредствено качество. С IRR е ясно — всичко е зле.

BGP-communities. Това е определен атрибут, описан в протокола. Можем да закачим, например, специално community на нашия анонс, за да предотвратим съседът да изпраща нашите мрежи на своите съседи. Когато имаме P2P линк, ние обменяме само нашите мрежи. За да предотвратим случайно маршрутът да отиде в други мрежи, ние закачаме community.

Community не са транзитивни. Това винаги е договор между двама, и това е техният недостатък. Не можем да закачим каквото и да е community, освен едно, което се приема по подразбиране от всички. Не можем да бъдем сигурни, че това community ще бъде прието и правилно интерпретирано. Затова, в най-добрия случай, ако се разберете със своя uplink, той ще разбере какво искате от него по community. Но може да не разбере неговият съсед или операторът просто да сброси вашата етикетка и вие да не постигнете това, което искате.

RPKI + ROA решава само малка част от проблемите. RPKI е Resource Public Key Infrastructure  — специален фреймуърк за подписване на маршрутна информация. Добра идея е да накараме LIR-ите и техните клиенти да поддържат актуална база данни на адресното пространство. Но с него има един проблем.

RPKI е също така йерархична система за открити ключове. IANA притежава ключ, от който се генерират ключовете на RIR, а от тях — ключовете на LIR, с които подписват своето адресно пространство с помощта на ROA — Удостоверения за произход на маршрути:

— Уверявам, че този префикс ще бъде анонсиран от името на тази автономна система.

Освен ROA, има и други обекти, но за тях по-късно. Изглежда, че е нещо добро и полезно. Но не ни предпазва от изтичане, от думата 'все същото' и не решава всички проблеми с кражбата на префикси. Затова играчите не бързат да я внедрят. Въпреки това, вече има уверения от крупни играчи, като AT&T и големи IX, че префиксите с невалидна ROA запис ще бъдат отхвърляни.

Възможно е да го правят, но досега имаме огромно количество префикси, които никак не са подписани. От една страна, не е ясно дали те са валидни за анонсиране. От друга страна, не можем да ги отхвърляме по подразбиране, защото не сме сигурни, дали е правилно.

Какво още има?

BGPSec. Това е готина концепция, измислена от академици за мрежата на розовите пони. Те казаха:

— Имаме RPKI + ROA — механизъм за удостоверяване на подписа за адресно пространство. Нека създадем отделен BGP атрибут и да го наречем BGPSec Path. Всеки рутер ще подписва с подписа си анонсите, които анонсира на съседите. Така ще получим доверен път от верига от подписани анонси и ще можем да го проверим.

В теорията е добре, но на практика има много проблеми. BGPSec нарушава много от съществуващите механизми на BGP по отношение на избора на next-hop и управлението на входящия/изходящия трафик непосредствено на маршрутизатора. BGPSec не работи, докато 95% от участниците на пазара не го внедрят, което само по себе си е утопия.

BGPSec има огромни проблеми с производителността. На текущото оборудване скоростта на проверка на анонсите е около 50 префикса в секунда. За сравнение: текущата таблица на интернет с 700 000 префикса ще се обнови за 5 часа, за които още 10 пъти ще се смени.

BGP Open Policy (Роля-базирано BGP). Свежо предложение на базата на модела Гао-Рексфорда. Това са двама учени, които проучват BGP.

Моделът на Гао-Рексфорда е следният. Ако опростим, в случая с BGP има малко на брой типове взаимодействия:

• Provider Customer;
• P2P;
• вътрешно взаимодействие, да предположим, iBGP.

На базата на ролята на маршрутизатора, вече можем по подразбиране да приложим някои политики за внос/износ. Администраторът не трябва да конфигурира списъците с префикси. На базата на ролята, за която маршрутизаторите ще се споразумеят помежду си и която може да бъде зададена, вече получаваме определени подразбиращи се филтри. В момента това е проект, който се обсъжда в IETF. Надявам се скоро да видим това под формата на RFC и имплементация на хардуер.

Големи интернет доставчици

Нека разгледаме примера на доставчика CenturyLink. Това е третият по големина доставчик в САЩ, който обслужва 37 щата и притежава 15 дата центъра. 

През декември 2018 г. CenturyLink беше неактивен на пазара в САЩ в продължение на 50 часа. По време на инцидента имаше проблеми с работата на банкомати в два щата, а номер 911 не работеше в продължение на няколко часа в пет щата. Освен това, лотарията в Айдахо бе отменена. Във връзка с този инцидент, Комисията по електронни съобщения на САЩ в момента провежда разследване.

Причината за трагедията е в една мрежова карта в един дата център. Картата се е повредила, изпращала е некоректни пакети и всички 15 дата центъра на доставчика са били неактивни.

За този доставчик не сработи идеята «твърде голям, за да падне». Тази идея изобщо не работи. Може да вземете всеки голям играч и да го повалите с нещо дребно. В САЩ все още е относително добре със свързаността. Клиентите на CenturyLink, които имаха резерв, масово преминаха към него. По-късно, алтернативни оператори се оплакваха от претоварване на техните линии.

Ако се провали условният «Казахтелеком», цялата страна ще остане без интернет.

Корпорации

Навярно интернетът се крепи на Google, Amazon, FaceBook и други корпорации? Не, и те го чупят.

През 2017 г. в Санкт Петербург на конференцията ENOG13 Джеф Хюстон от APNIC представи представи доклад «Смърт на транзита». В него се казва, че сме свикнали взаимодействията, потокът на пари и трафикът в интернет да са вертикални. Имаме малки доставчици, които плащат за свързаност на по-големи, а те плащат на глобалния транзит.

Сега имаме такава вертикално ориентирана структура. Всичко би било наред, но светът се променя — големите играчи изграждат свои трансокеански кабели за изграждане на свои собствени backbones.

Новина за CDN кабела.

През 2018 година TeleGeography публикува проучване, в което се установява, че повече от половината трафик в интернет вече не е интернет, а backbones CDN на големи играчи. Това е трафик, който има отношение към интернет, но вече не е същата мрежа, за която говорихме.

Интернет се разпада на голям набор слабо свързани помежду си мрежи.

Microsoft има своя мрежа, Google - своя, и те слабо се пресичат помежду си. Трафикът, който е започнал някъде в САЩ, минава през каналите на Microsoft през океана към Европа, където се свързва с CDN, след това през CDN или IX се свързва с вашия доставчик и стига до вашия рутер.

Децентрализацията изчезва.

Тази силна страна на интернет, която ще му помогне да оцелее след ядрена експлозия, се губи. Появяват се места на концентрация на потребители и трафик. Ако спре условният Google Cloud - много хора ще пострадат наведнъж. Частично го усетихме, когато Роскомнадзор блокира AWS. А на примера на CenturyLink е видно, че за това е достатъчно и малко.

Преди не всичко се счупваше и не при всички. В бъдеще можем да стигнем до положение, в което, оказвайки влияние върху един голям играч, можем да破ем много неща, на много места и за много хора.

Държави

Следващите на ред са държавите, и обикновено се случва така.

Нашият Роскомнадзор съвсем не е пионер в това. Подобна практика за спиране на интернет съществува в Иран, Индия, Пакистан. В Англия има законопроект за възможността за отключване на интернет.

Всяка голяма държава желае да има ключ за отключване на интернет, или напълно, или на части: Twitter, Telegram, Facebook. Те не зовсъм, че никога няма да могат да го направят, но много искат. Приложат ключа като правило за политически цели - за отстраняване на политически конкуренти, или наближава избори, или руски хакери отново са счупили нещо.

DDoS атаки

Няма да отнемам хляба на колегите от Qrator Labs, те го правят много по-добре от мен. Те имат годишен отчет за стабилността на интернет. И ето какво написаха в отчета за 2018 година.

Средната продължителност на DDoS атаките пада до 2.5 часа. Атакуващите също започват да броят парите, и ако ресурсът не е паднал веднага, бързо го оставят на спокойствие.

Увеличава се интензивността на атаките. През 2018 година видяхме 1.7 Tb/s в мрежата на Akamai, и това не е предел.

Появяват се нови вектори на атаки и се засилват старите. Появяват се нови протоколи, податливи на амплификация, и нови атаки на съществуващите протоколи, особено на TLS и подобни.

По-голямата част от трафика е мобилни устройства. В същото време интернет трафикът преминава на мобилни клиенти. С това трябва да се работи както от страна на атакуващите, така и от страна на защитниците.

Няма неуязвими. Това е основната мисъл - не съществува и не може да съществува универсална защита, която да защити от всякакъв DDoS.

Системата не може да бъде срината, само ако не е свързана с интернет.

Надявам се, че ви уплаших достатъчно. Нека сега помислим какво да правим с това.

Какво да правим?!

Ако имате свободно време, желание и познания по английски - участвайте в работни групи: IETF, RIPE WG. Това са отворени мейл-листове, абонирайте се за бюлетини, участвайте в дискусии, идвайте на конференции. Ако имате статус LIR, можете да гласувате, например, в RIPE за различни инициативи.

За обикновените смъртни - това мониторинг. За да знаете какво е счупено.

Мониторинг: какво да проверявате?

Обычен Ping, и не само бинарна проверка - работи ли или не. Записвайте RTT в историята, за да можете по-късно да видите аномалии.

Traceroute. Това е служебна програма за определяне на маршрутите на данни в мрежи TCP/IP. Помага при откриване на аномалии и блокировки.

HTTP checks - проверки на custom URL и TLS сертификата ще помогнат за откриване на блокировки или подмяна на DNS за атака, което практически е едно и също. Блокировките често се извършват чрез подмяна на DNS и със завиване на трафика на страница със заглушка.

Ако имате възможност, проверявайте резолв на вашия origin от различни места, ако имате приложение. Така ще откриете аномалии в DNS интерсепцията, които понякога провайдерите извършват.

Мониторинг: откъде да проверявате?

Няма универсален отговор. Проверявайте от там, откъдето идва потребителят. Ако потребителите са в Русия - проверявайте от Русия, но не се ограничавайте до нея. Ако вашите потребители живеят в различни региони - проверявайте от тези региони. Но е по-добре от целия свят.

Мониторинг: с какво да проверявате?

Придумал съм три начина. Ако знаете повече - напишете в коментарите.

• RIPE Atlas.
• Търговски мониторинг.
• Собствена мрежа от виртуални машини.

Нека поговорим за всеки от тях.

RIPE Atlas — това е такава малка кутийка. За тези, които познават домашния "Ревизор" — това е същата кутийка, но с друг етикет.

RIPE Atlas — безплатна програма. Регистрирате се, получавате по пощата рутер и го включвате в мрежата. За това, че някой друг ползва вашата проба, ви капят някои кредити. С тези кредити можете сами да провеждате някакви изследвания. Можете да тествате по различен начин: ping, traceroute, да проверявате сертификати. Покритие има доста голямо, много възли. Но има нюанси.

Системата на кредитите не позволява изграждането на продакшн-решения. Кредитите не стигат за постоянни изследвания или търговски мониторинг. Кредитите са достатъчни само за кратки изследвания или one-time проверки. Дневната норма с една проба се изразходва за 1-2 проверки.

Покритието е неравномерно. Тъй като програмата е безплатна от двете страни, покритието е добро в Европа, в европейската част на Русия и в някои региони. Но ако ви е нужна Индонезия или Нова Зеландия, ситуацията е значително по-лоша — 50 проби на страна може да не бъдат достигнати.

Няма да можете да проверявате http с проба. Това е предизвикано от технически нюанси. Обещават да поправят в новата версия, но засега http не може да се проверява. Можете да проверите само сертификата. Някаква http проверка може да се проведе само до специално устройство RIPE Atlas, наречено Anchor.

Вторият начин е търговският мониторинг. С него всичко е наред, нали плащате пари? Обещават ви десетки или стотици точки за мониторинг по целия свят, рисуват красиви табла "от кутията". Но, отново, има проблеми.

Това е платно, на места много. Мониторинг с ping, проверки от цял свят и множество http проверки могат да струват хиляди долари на година. Ако финансите позволяват и ви харесва това решение — моля.

Покритията може да не стигат в интересуващия ви регион. С пинга уточняват максимум абстрактните части на света — Азия, Европа, Северна Америка. Редки системи за мониторинг могат да детализират пробата до конкретна страна или регион.

Слаба поддръжка на custom-тестовете. Ако ви трябва нещо по-специфично, а не просто "курлык" на url, то с това също има проблеми.

Третият начин е вашият мониторинг. Това е класика: "А да напишем своето!"

Вашият мониторинг се превръща в разработка на софтуерен продукт, като е разпределен. Търсите инфраструктурен доставчик, гледате как да го деплойвате и мониторите – мониторингът трябва да се следи, нали? И освен това е необходима поддръжка. Помислете сто пъти, преди да се захванете с това. Може да е по-просто да платите на някого, който да го направи вместо вас.

Мониторинг на BGP аномалии и DDoS атаки

Тук по достъпните ресурси всичко е още по-просто. BGP аномалиите се откриват с помощта на специализирани услуги като QRadar, BGPmon. Те получават full view таблица от множество оператори. На базата на това, което виждат от различни оператори, могат да открият аномалии, да търсят амплификатори и др. Обикновено регистрацията е безплатна – въвеждате номера на вашата автономка, подписвате се за уведомления на имейл и услугата ви известява за проблемите.

При мониторинга на DDoS атаките също всичко е просто. Обикновено това е основаващо се на NetFlow и логове. Има специализирани системи като FastNetMon, модули за Splunk. В краен случай, вашият доставчик на DDoS защита може да получи NetFlow, и на неговата база той ще ви уведомява за атаки към вас.

Изводи

Не си създавайте илюзии – интернетът задължително ще се срине. Няма да се срине всичко и не у всички, но 14 хиляди инцидента за 2017 година намекват, че инцидентите ще продължат.

Вашата задача е да забележите проблемите възможно най-скоро. Както минимум, не по-късно от вашите потребители. Освен, че трябва да забележите, винаги имайте в резерв "план Б". Планът е стратегията, която ще следвате, когато всичко се срине: резервни оператори, ДЦ, CDN. Планът е отделен чеклист, с който проверявате работата на всичко. Планът трябва да работи без да се налага да се привлекат мрежови инженери, защото обикновено те са малко и искат да спят.

На това е всичко. Пожелавам ви висока наличност и зелен мониторинг.

Следващата седмица в Новосибирск се очаква слънце, хайлоад и висока концентрация на разработчици на HighLoad++ Siberia 2019. В Сибир се прогнозира фронт на доклади за мониторинг, наличност и тестване, сигурност и управление. Очакват се валежи във вида на изпълнени конспекти, нетворкинг, снимки и постове в социалните мрежи. Препоръчваме ви да отложите всички дела на 24 и 25 юни и да резервирате билети. Очакваме ви в Сибир!

Източник: habr.com