Крупная утечка маршрутов повлияла на большие секторы интернета, включая Cloudflare
Что случилось?
24.06 в 10:30 UTC в интернете случился коллапс: на небольшую компанию на севере Пенсильвании хлынул поток трафика из множества маршрутов, проходящих через крупного провайдера Verizon (AS701), — с тем же успехом навигатор мог бы отправить поток машин с многополосного шоссе на узкую улочку. В результате у многих веб-сайтов на Cloudflare и многих других провайдеров возникли проблемы с доступом. Этого вообще не должно было произойти, ведь Verizon не должен был рассылать эти маршруты всему интернету. Чтобы узнать, как так вышло, читайте дальше.
Мы уже писали о подобных происшествиях раньше, время от времени они случаются, но на этот раз последствия ощутили по всему миру. Проблему усугубил BGP Optimizer от Noction. У него есть функция, которая разбивает полученные IP-префиксы на более мелкие и конкретные. Например, наш IPv4-маршрут 104.20.0.0/20 разделился на 104.20.0.0/21 и 104.20.8.0/21. Как если бы дорожный указатель на Пенсильванию заменили на два других: «Питтсбург, штат Пенсильвания» и «Филадельфия, штат Пенсильвания». Разделяя большие блоки IP на мелкие, сеть управляет трафиком внутри себя, но это разделение не должно было стать общедоступным. Иначе возникают вот такие неприятности.
Чтобы объяснить, что случилось дальше, давайте сначала вспомним, по какой схеме работает интернет. По сути интернет — это сеть, состоящая из сетей, которые называются автономными системами. У каждой автономной системы свой уникальный идентификатор. Все сети связаны друг с другом по протоколу Border Gateway Protocol (BGP). BGP соединяет эти сети и образует структуру интернета, в которой трафик проходит, допустим, от вашего интернет-провайдера к популярному веб-сайту в другой части света.
Через BGP сети обмениваются сведениями о маршрутах, а именно: как добраться до них из любой точки. Эти маршруты могут быть конкретными (как определенный город на карте) или общими (как область). Тут-то и случилась беда.
Один интернет-провайдер в Пенсильвании (AS33154 — DQE Communications) использовал в своей сети BGP Optimizer, то есть в их сети было много конкретных маршрутов. Конкретные маршруты имеют приоритет над общими (в том же навигаторе, например, маршрут до Букингемского дворца будет более конкретным, чем маршрут до Лондона).
DQE предоставил эти конкретные маршруты своему клиенту (AS396531 — Allegheny Technologies Inc), а оттуда они попали к транзитному провайдеру (AS701 — Verizon), который разнес эти «оптимальные» маршруты по всему интернету. Оптимальными они кажутся потому, что в них больше деталей и конкретики.
И все это не должно было выйти за пределы Verizon. И хотя существуют эффективные способы защиты от таких сбоев, отсутствие у Verizon фильтров привело к коллапсу, затронувшему множество сервисов, таких как Amazon, Linode и Cloudflare.
В итоге на Verizon, Allegheny и DQE обрушился вал пользователей, пытающихся получить доступ к этим сервисам через их сети. Они не были предназначены для такого мощного трафика, что и привело к перебоям. И даже если бы ресурсов хватило, DQE, Allegheny и Verizon не должны были рассказывать всем об идеальном маршруте к Cloudflare, Amazon, Linode и т д.
Процесс утечки BGP с BGP Optimizer.
В худшие моменты сбоя мы наблюдали потерю приблизительно 15% мирового трафика.
Уровни трафика в Cloudflare во время инцидента.
Как можно было предотвратить утечку?
Есть несколько способов.
Для BGP-сессии можно настроить жесткий лимит принимаемых префиксов, и если количество префиксов превысит порог, роутер прервет сессию. Если бы у Verizon был такой лимит на префиксы, ничего бы не случилось. Такому провайдеру, как Verizon, установить его ничего бы не стоило. Почему лимитов не было? У меня одна версия: небрежность и лень.
Еще один способ предотвратить такие утечки — фильтрация на основе IRR. IRR (Internet Routing Registry) — это распределенная база данных интернет-маршрутов, в которую сети добавляют записи. Другие сетевые операторы используют эти записи в IRR, чтобы создавать списки конкретных префиксов для BGP-сессий с другими сетями. Если бы использовались фильтры IRR, ни одна из этих сетей не приняла бы ошибочные конкретные маршруты. Невероятно, но у Verizon вообще не было такой фильтрации в BGP-сессиях с Allegheny Technologies, хотя IRR-фильтрация используется (и прекрасно задокументирована) уже больше 24 лет. IRR-фильтры ничего бы не стоили Verizon и никак бы не ограничили их сервис. И снова — небрежность и лень.
В прошлом году мы реализовали и развернули платформу RPKI, которая как раз предотвращает подобные утечки. Она устанавливает фильтры по исходной сети и размеру префикса. Cloudflare объявляет префиксы с максимальным размером 20. RPKI указывает, что более конкретные префиксы принимать нельзя, независимо от пути. Чтобы этот механизм работал, в сети нужно включить BGP Origin Validation. Многие провайдеры, например, AT&T уже успешно применяют RPKI в своей сети.
Если бы в Verizon использовали RPKI, они бы увидели, что предложенные маршруты недопустимы, и роутер автоматически отклонил бы их.
Cloudflare советует всем сетевым операторам развернуть RPKI прямо сейчас!
Предотвращение утечки маршрутов с помощью IRR, RPKI и лимита на префиксы.
Все эти рекомендации прекрасно описаны в нормах MANRS (Mutually Agreed Norms for Routing Security).
Как решили проблему
Команда по сетям Cloudflare связалась с пострадавшими сетями AS33154 (DQE Communications) и AS701 (Verizon). Это было непросто — может, потому, что когда все началось, на восточном побережье США было еще раннее утро.
Скриншот письма в Verizon.
Один из наших сетевых инженеров быстро связался с DQE Communications, и после небольшой задержки нас соединили с тем, кто мог решить проблему. При нашей поддержке по телефону DQE смогли прекратить рассылку «оптимизированных» маршрутов к Allegheny Technologies Inc. Мы благодарны им за помощь. Все стабилизировалось и пришло в норму.
Скриншот попыток связаться со службами поддержки DQE и Verizon
К сожалению, несмотря на все наши попытки связаться с Verizon по телефону и электронной почте, на момент написания статьи (после инцидента прошло уже более 8 часов), нам так никто и не ответил, и мы не знаем, предпринимают ли они хоть что-нибудь.
Мы в Cloudflare не хотели бы повторения подобного, но делается для этого, к сожалению, очень мало. Отрасли пора принять более эффективные меры, чтобы обеспечить безопасность маршрутизации, например, с помощью таким систем, как RPKI. Мы надеемся, что крупные провайдеры последуют примеру Cloudflare, Amazon и AT&T и начнут проверять маршруты. Особенно это касается вас, Verizon. Мы все еще ждем ответа.
И хотя мы не могли повлиять на случившееся, приносим свои извинения за перебои в обслуживании. Мы заботимся о наших клиентах, и инженеры в США, Великобритании, Австралии и Сингапуре вышли на связь через несколько минут после того, как мы обнаружили проблему.
Другие статьи с тегом BGP.