Интернет кажется сильной, независимой и нерушимой структурой. В теории, прочности сети хватит, чтобы пережить ядерный взрыв. В реальности, интернет может уронить один маленький роутер. Все из-за того, что интернет — это нагромождение противоречий, уязвимостей, ошибок и роликов про котиков. Основа интернета — протокол 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 000! Сеть все еще децентрализованная, поэтому ломается не все и не у всех. Но инциденты происходят тысячами, и все они связаны с протоколом 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 сложнее, чем просто фильтры на границе.
Почему не работают фильтры?
Nobody cares. Это главная причина — всем все равно. Админ маленького провайдера или компании, которая подключилась к провайдеру по 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, за исключением одного, которое принимается по умолчанию всеми. Мы не можем быть уверены, что это community все примут и правильно интерпретируют. Поэтому, в лучшем случае, если вы договоритесь со своим uplink, он поймет, что вы от него хотите по community. Но может не понять его сосед, либо оператор просто сбросит вашу метку, и вы не достигнете того, чего хотели.
RPKI + ROA решает только малую часть проблем. RPKI — это Resource Public Key Infrastructure — специальный фреймворк для подписывания маршрутной информации. Хорошая идея, чтобы заставить LIR-ов и их клиентов вести актуальную базу адресного пространства. Но с ним есть одна проблема.
RPKI это еще и иерархическая система открытых ключей. У IANA есть ключ, от которого создаются ключи RIR, а от них ключи LIR? которыми они подписывают своё адресное пространство c помощью 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 Джефф Хьюстон из APNIC представил . В нем говорится, что мы привыкли, что взаимодействие, потоки денег и трафик в интернете вертикальны. У нас есть маленькие провайдеры, которые платят за связанность более крупным, а те уже платят за связанность глобальному транзиту.
Сейчас у нас такая вертикально-ориентированная структура. Все бы хорошо, но мир меняется — крупные игроки строят свои трансокеанские кабели для постройки собственных 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, модули для Splunk. На крайний случай есть ваш поставщик DDoS-защиты. Ему тоже можно сливать NetFlow и на его основании он будет оповещать вас об атаках в вашу сторону.
Выводы
Не питайте иллюзий — интернет обязательно сломается. Сломается не всё и не у всех, но 14 тысяч инцидентов за 2017 год намекают, что инциденты будут.
Ваша задача — заметить проблемы как можно раньше. Как минимум, не позже, чем ваш пользователь. Мало того, что необходимо заметить, всегда держите в запасе «план Б». План — это стратегия, что вы будете делать, когда все сломается: резервные операторы, ДЦ, CDN. План — это отдельный чек-лист, по которому проверяете работу всего. План должен работать без привлечения сетевых инженеров, потому что их обычно мало, и они хотят спать.
На этом все. Желаю вам высокой доступности и зеленого мониторинга.
На следующей неделе в Новосибирске ожидается солнце, хайлоад и высокая концентрация разработчиков на . В Сибири прогнозируется фронт докладов про мониторинг, доступность и тестирование, безопасность и менеджмент. Ожидаются осадки в виде исписанных конспектов, нетворкинга, фотографий и постов в соцсетях. Рекомендуем отложить все дела 24 и 25 июня и . Ждем вас в Сибири!
Источник: habr.com