Dyn превратила управляемый DNS в зону ответственности за непрерывность выручки

Краткое содержание

• Подтверждено:21 октября 2016 года Dyn сообщила о DDoS-атаках на свою инфраструктуру управляемого DNS (Managed DNS). В публичном заявлении говорилось, что первая волна началась около 7:00 утра по восточному времени, затронула пользователей, направлявшихся к серверам Dyn на Восточном побережье США, и была отражена примерно через два часа. Вторая, более глобальная волна началась незадолго до полудня и была отражена чуть более чем за час. Dyn также сообщила, что третья попытка атаки была отражена без влияния на клиентов.
• Наблюдения:ThousandEyes зафиксировала высокий процент сбоев DNS-запросов из своих глобальных точек наблюдения и сообщила, что в пик атаки около 75 % её точек отправляли запросы, на которые серверы Dyn не отвечали. Компания также наблюдала примерно 1 200 затронутых сайтов и сервисов среди тех, что отслеживали её клиенты, и обнаружила, что многие уязвимые клиенты использовали только серверы имён Dyn, а не нескольких DNS-провайдеров.
• Ограниченная атрибуция:Dyn сообщила, что анализ Flashpoint и Akamai подтвердил: одним из источников трафика были устройства, заражённые Mirai. DOJ позже объявило о признании вины создателями Mirai, а также об отдельном признании вины лицом, чей ботнет на основе варианта Mirai 21 октября 2016 года затронул Dyn и сделал такие сайты, как Sony, Twitter, Amazon, PayPal, Tumblr, Netflix и Southern New Hampshire University, недоступными или работающими с перебоями в течение нескольких часов. Публичные материалы не доказывают, что один субъект, один ботнет или один вектор атаки объясняет весь трафик, который Dyn наблюдала в тот день.
• Оценка:Инцидент стал сбоем общей зависимости (common-mode dependency failure). Dyn контролировала свою платформу управляемого DNS, партнёров по смягчению атак, коммуникации и архитектуру инфраструктуры. Клиенты контролировали, диверсифицирован ли авторитетный DNS по нескольким провайдерам и соответствуют ли практики TTL, аварийного переключения и мониторинга их собственным заявлениям о доступности. Вендоры IoT, владельцы устройств, интернет-провайдеры, регуляторы и злоумышленники контролировали отдельные части проблемы ботнетов.

Перечень публичных источников и их использование

В этой статье в качестве многоуровневых доказательств используются публичное заявление Dyn, независимые измерения DNS, документы DOJ, стандарты DNS, исследования в области безопасности, рекомендации по DDoS и рыночный контекст. Таблица не утверждает, что каждый цитируемый источник доказывает убытки каждого пострадавшего клиента; она объясняет, какие публичные источники поддерживают анализ ответственности.

DNS отказал раньше, чем веб-приложение

Пользователь обычно замечает DNS, только когда тот ломается. Имя сайта выглядит нормально. Браузер работает. Соединение пользователя может быть в порядке. Целевое приложение может продолжать работать. Но если путь авторитетного DNS не может ответить, сервис может исчезнуть так, словно сами серверы пропали. Именно это сделало инцидент с Dyn таким дезориентирующим. Многие сервисы не обязательно были сломаны на уровне собственных приложений. Их имена просто не могли разрешаться достаточно надёжно, чтобы пользователи могли до них добраться.

Инцидент октября 2016 года находится на пересечении двух форм аутсорсинга. Во-первых, многие цифровые компании передавали авторитетный DNS управляемому провайдеру, потому что он мог обеспечить глобальную anycast-доступность, управление трафиком, операционную экспертизу и подготовку к DDoS, которые многие клиенты не могли экономически выстроить самостоятельно. Во-вторых, миллионы домохозяйств и организаций разместили в открытом интернете незащищённые подключённые устройства, часто со слабыми стандартными учётными данными или плохими путями обновления. Mirai превратил второй выбор аутсорсинга в атакующий трафик против первого.

Собственное заявление Dyn, сохранённое в публичной PDF-копиизаявления Dyn об атаке 21.10.2016, гласило, что компания подверглась DDoS-атакам на свою инфраструктуру Managed DNS. В нём описывалась первая волна, начавшаяся около 7:00 утра по восточному времени, восстановление примерно через два часа, вторая, более глобальная волна незадолго до полудня, восстановление около 13:00 и третья попытка атаки, которую, по словам Dyn, отразили без влияния на клиентов. Dyn также заявила, что в любой момент не испытывала общесистемного сбоя и что некоторые пользователи — например, те, кто в первую волну обращался к затронутым сайтам с Западного побережья США, — могли успешно получить доступ.

Эта деталь важна. Инцидент не был простым бинарным сбоем, при котором каждый клиент Dyn исчезал везде. Это был сбой доступности, определяемый географией, anycast, поведением резолверов, временем жизни записей (TTL), конфигурацией доменов клиентов и меняющейся интенсивностью DDoS-трафика. Это затрудняло коммуникацию. Клиент мог проверить доступность из одной сети и увидеть успех, пока пользователи в других местах видели сбой. Владелец платформы мог иметь здоровые серверы приложений и всё равно получать жалобы, что сервис лежит. Пользователь мог дождаться истечения кэшированного DNS-ответа и внезапно потерять доступ.

Общая зависимость была видна в измерениях

Анализ ThousandEyes —«DDoS-атака на DNS-инфраструктуру Dyn»— даёт наиболее ясное публичное объяснение зависимости на стороне клиента. Его мониторинг зафиксировал три фазы: первоначальное воздействие, сконцентрированное на Восточном побережье США, более широкое глобальное воздействие и последующее смягчение с остаточными атаками или блокировкой (blackholing). В пик атаки примерно три четверти её глобальных точек наблюдения отправляли DNS-запросы, на которые серверы Dyn не отвечали. Компания также сообщила примерно о 1 200 затронутых сайтах и сервисах среди доменов, которые отслеживали её клиенты.

Технический момент был прост, но серьёзен. Dyn обслуживала авторитетные серверы для доменов клиентов. Если резолвер ещё не имел свежего кэшированного ответа и не мог достучаться до авторитетных серверов Dyn, он не мог получить адрес, необходимый для подключения. Более короткие значения TTL могут делать управление трафиком более гибким в обычной работе, но они также заставляют пользователей чаще зависеть от успешного авторитетного разрешения. Низкий TTL сам по себе не плох; это компромисс.

Во время DDoS-события у DNS-провайдера он может сократить время между «кэш ещё знает, куда идти» и «резолвер должен снова спросить недоступный авторитетный сервер».

ThousandEyes также описала популярность Dyn для управления трафиком. Управляемый DNS был не просто статической телефонной книгой. Он помогал крупным сервисам направлять пользователей к ближайшим дата-центрам, перераспределять трафик и оптимизировать производительность. Это означает, что продукт, повышавший устойчивость и скорость в обычных условиях, одновременно становился зависимостью, деградация которой могла затронуть многих клиентов сразу. Чем сильнее ценностное предложение провайдера, тем привлекательнее он становился как общая контрольная плоскость.

Самым важным выводом ThousandEyes для ответственности была архитектура клиентов. Многие пострадавшие клиенты Dyn использовали только серверы имён Dyn, а не диверсифицировали DNS по нескольким провайдерам. Анализ противопоставлял клиентов с одним управляемым DNS-провайдером Amazon.com, который использовал более одного провайдера и столкнулся с замедлением загрузки, а не с той же полной недоступностью, которую видели многие другие. Это не значит, что каждый клиент мог мгновенно включить мультипровайдерный DNS. Это значит, что риск был архитектурным, заметным и частично контролируемым клиентами.

Материал AP, перепечатанный Chicago Sun-Times, зафиксировал публичный опыт: косвенные последствия для пользователей, пытавшихся попасть на популярные сайты в США и Европе, при этом Twitter, Netflix и PlayStation Network от Sony выглядели среди затронутых сервисов. Всовременном репортаже Guardianперечислялись Netflix, Twitter, Spotify, Reddit, CNN, PayPal, Pinterest, Fox News и крупные газеты среди сервисов, которые, по сообщениям, были недоступны или работали с нарушениями. Эти сообщения полезны для оценки масштаба и общественного восприятия; они не доказывают, что каждый названный сервис испытал одинаковый тип технического сбоя или одинаковую продолжительность.

Общий отказ прячется внутри «избыточного» DNS

В DNS избыточность встроена в саму конструкцию. Домены перечисляют несколько серверов имён. Резолверы могут пробовать альтернативы. Авторитетные серверы могут быть географически распределены. Проблема в том, что избыточность может быть формальной, не будучи независимой от отказов.

RFC 2182ещё с 1997 года говорит, что одна из главных причин наличия нескольких DNS-серверов — сохранение доступности информации о зоне, даже когда один сервер недостижим, и что вторичные серверы должны быть географически и топологически распределены. Документ предостерегает от конфигураций, в которых все серверы разделяют один и тот же локальный режим отказа. Простыми словами: нескольких серверов имён недостаточно, если они отказывают вместе.

Дело Dyn перевело этот принцип из физического расположения в зависимость от провайдера. Клиент может перечислить несколько серверов имён Dyn и всё равно иметь одного провайдера, одни коммерческие отношения, один путь операционной поддержки, один набор учётных данных управления DNS и одну экспозицию к крупной атаке на этого провайдера. С точки зрения домена эти серверы имён могут выглядеть разнообразными. С точки зрения ответственности они всё ещё часть общей зависимости от одного провайдера.

Статья«Отсутствие избыточности в DNS-резолвинге крупных сайтов и сервисов»рассматривала концентрацию и диверсификацию DNS после инцидента с Dyn. Она выявила растущую концентрацию среди небольшого числа DNS-провайдеров и сильную тенденцию доменов не использовать нескольких провайдеров управления DNS. В её выборке доля доменов, использующих только одного провайдера, составляла примерно от 91 % до 93 % до атаки и снизилась с 92,2 % до 89,4 % в период с октября 2016 года по ноябрь 2016 года. Среди клиентов Dyn доля недиверсифицированных доменов резко упала после инцидента и продолжала снижаться к маю 2017 года.

К этим цифрам следует относиться как к исследовательским результатам в рамках конкретного набора данных, а не как к точной переписи всего интернета. Тем не менее они подтверждают практический урок. DNS делал диверсификацию провайдеров возможной, однако многие клиенты предпочли операционную простоту независимости от отказов. Это не иррационально. Мультипровайдерный авторитетный DNS вносит сложность: согласованные данные зон, подпись и управление ключами DNSSEC, поведение проверок здоровья, различия в управлении трафиком, задержки распространения, риск split-brain, мониторинг и договорную ответственность. Цена разнообразия реальна.

Атака на Dyn показала, что цена отказа от диверсификации тоже может стать реальной — и прийти через поставщика, а не через собственную инфраструктуру клиента.

Anycast мощен, но не волшебен

Инфраструктура Dyn, как и многих глобальных DNS-платформ, использовала anycast. Anycast позволяет нескольким локациям объявлять один и тот же IP-адрес, чтобы интернет-маршрутизация могла направлять резолвер к ближайшему или предпочтительному экземпляру. Это улучшает задержку и поглощает многие локальные сбои, потому что трафик может обходить сеть. Это одна из причин, по которой управляемые DNS-провайдеры могут предлагать широкий охват и быстрый ответ.

Anycast не делает ёмкость бесконечной. Он может распределять трафик, но может и распределять атакующее давление. Если атака достаточно крупная, широкая или нацелена так, чтобы перегружать вышестоящие каналы, пиринг или общие префиксы, локации anycast могут отказывать вместе или нестабильно «флапать». ThousandEyes наблюдала, что многие запросы не могли пройти через интернет-провайдеров Dyn или сетевой край Dyn, и что серверы имён внутри одного созвездия и группы показывали коррелированную производительность. Это наблюдение не доказывает, что внутренняя архитектура Dyn была небрежной.

Оно показывает, почему «у нас несколько точек присутствия» — не то же самое, что «у нас независимая доступность при всех правдоподобных условиях DDoS».

Dyn в своём заявлении говорила, что отрабатывала сценарии, имела плейбуки, использовала партнёров по смягчению атак и запустила управление инцидентом и коммуникацию с клиентами. Она также сообщила, что атаки были высокораспределёнными, включали десятки миллионов отдельных IP-адресов, связанных с Mirai, и использовали множество векторов и интернет-локаций. Провайдера нельзя оценивать так, будто смягчение DDoS — это просто покупка достаточной пропускной способности.

Очень крупные распределённые атаки создают ошибки измерения, штормы повторных запросов, сопутствующий трафик, нестабильность маршрутов и трудные компромиссы между фильтрацией атакующего трафика и сохранением легитимных запросов.

Тем не менее клиенты покупают управляемый DNS именно потому, что провайдер заявляет экспертизу в этой самой операционной области. Поэтому Dyn несла провайдерскую часть устойчивости: планирование ёмкости, координацию с вышестоящими операторами, архитектуру anycast, дизайн созвездий серверов имён, коммуникацию о статусе, поддержку клиентов, готовность партнёров по смягчению и посмертные доказательства. Справедливая оценка ответственности может удерживать обе идеи одновременно. Атака была злонамеренной и крупной. Бизнес Dyn состоял в том, чтобы поддерживать доступность авторитетного DNS во враждебных условиях.

Mirai перенёс риск потребительских устройств в инфраструктуру

Mirai сделал атаку культурно запоминающейся, потому что ботнет был построен в основном из обычных подключённых к интернету устройств: камер, роутеров, видеорегистраторов и подобных встраиваемых систем.Статья USENIX «Понимание ботнета Mirai»описывает Mirai как состоящий в первую очередь из встраиваемых и IoT-устройств и сообщает, что он вырос до пика примерно в 600 000 заражений. В статье утверждается, что простота метода заражения и быстрый рост показали: относительно неискушённые техники способны скомпрометировать достаточно много недорогих устройств, чтобы угрожать хорошо защищённым целям.

В объявлении Министерства юстиции 2017 года«Минюст США объявляет о предъявлении обвинений и признании вины по трём делам о компьютерных преступлениях, связанных с крупными DDoS-атаками»говорилось, что Paras Jha, Josiah White и Dalton Norman признали вину в управлении ботнетом Mirai, который нацеливался на IoT-устройства, такие как беспроводные камеры, роутеры и цифровые видеорегистраторы. DOJ сообщило, что в пике Mirai состоял из сотен тысяч скомпрометированных устройств и что участие оригинальных создателей в исходном варианте Mirai закончилось, когда Jha опубликовал исходный код на криминальном форуме осенью 2016 года. После этого, по словам DOJ, другие субъекты использовали варианты Mirai в других атаках.

В объявлении Министерства юстиции 2020 года«Физическое лицо признало вину в участии в кибератаке на устройства интернета вещей в 2016 году»более прямо связывало ботнет на основе варианта Mirai с днём атаки на Dyn. В нём говорилось, что лицо, ранее бывшее несовершеннолетним, признало вину в связи с кибератакой октября 2016 года. Согласно DOJ, это лицо и другие использовали ботнет для запуска нескольких DDoS-атак 21 октября 2016 года, пытаясь вывести из строя Sony PlayStation Network; атаки затронули Dyn, из-за чего такие сайты, как Sony, Twitter, Amazon, PayPal, Tumblr, Netflix и Southern New Hampshire University, стали недоступными или работали с перебоями в течение нескольких часов.

К этой записи об атрибуции следует относиться осторожно. Она не утверждает, что несовершеннолетний субъект был единственной причиной всех последствий для Dyn, и не означает, что весь трафик Dyn исходил от одного ботнета. Сама Dyn заявила, что одним из источников атакующего трафика были устройства, заражённые Mirai. Провайдер также описывал множество векторов и интернет-локаций. Самый безопасный вывод: Mirai и его варианты были материально вовлечены, а слой преступных действий отделён от слоя архитектуры устойчивости.

Предупреждение CISA об угрозе Miraiпредупреждало, что вредоносное ПО Mirai сканирует уязвимые IoT-устройства и что публичная публикация исходного кода Mirai повышает риск появления новых ботнетов. Позднейший отчёт Министерства торговли и Министерства внутренней безопасности, размещённый NIST,«Повышение устойчивости интернет- и коммуникационной экосистемы к ботнетам и другим автоматизированным распределённым угрозам», описывал проблему как экосистемную: автоматизированные распределённые атаки глобальны, эффективные инструменты широко не используются, продукты должны защищаться на всём жизненном цикле, стимулы несогласованы, и ни одно сообщество заинтересованных сторон не может решить проблему в одиночку.

Эта экосистемная рамка подходит инциденту с Dyn лучше, чем узкая история о вине. Злоумышленники злоупотребляли устройствами, которые им не принадлежали. Производители устройств часто выпускали недорогие продукты без сильных механизмов обновления, идентификации и контроля жизненного цикла. Владельцы устройств редко понимали, что камера или видеорегистратор в чулане может участвовать в атаке на DNS-инфраструктуру. Интернет-провайдеры имели частичную видимость трафика заражённых устройств, но смешанные стимулы и практические ограничения. DNS-провайдеры видели атаку, когда она достигала их сетевого края.

Клиенты видели её, когда их имена переставали разрешаться. Пользователи видели её только как сайт, который не загружается.

Более поздний документNISTIR 8259A «Базовая линия возможностей кибербезопасности устройств IoT»не существовал в 2016 году, и его нельзя трактовать как ретроспективную юридическую обязанность Dyn. Он всё ещё полезен как свидетельство того, что экосистема научилась ценить: идентификацию устройств, безопасную настройку, защиту данных, логический доступ, возможность обновления ПО, осведомлённость о состоянии кибербезопасности и документацию. Mirai преуспел потому, что слишком многие устройства не могли управляться как ответственные участники интернета.

Контроль клиентов был реальным, но неравномерным

Клиенты управляемого DNS не были пассивными наблюдателями. Владелец домена контролирует выбор делегирования, выбор провайдера, мониторинг, политику TTL, дизайн аварийного переключения и то, смогут ли критичные сервисы пережить потерю одного DNS-провайдера. Но контроль не был равным среди клиентов. Крупная платформа с глубокой инфраструктурной командой могла запускать нескольких авторитетных провайдеров, частично размещать стек у себя, поддерживать автоматизацию согласованности и тестировать разрешение из многих сетей.

Небольшой издатель, ритейлер, поставщик ПО, некоммерческая или муниципальная служба могли купить управляемый DNS именно для того, чтобы не нуждаться в такой экспертизе.

Здесь зависимость от облачных сервисов становится вопросом ответственности. Поставщик может продавать экспертизу, но клиентам всё равно нужно решать, какой уровень отказа поставщика они могут допустить. Вопрос не в том, «должен ли каждый сайт запускать собственную глобальную DNS-сеть?» Это было бы экономически абсурдно. Вопрос в том, соответствуют ли обещания доступности клиента его карте зависимостей. Бизнес, считающий онлайн-доступность критически важной, должен знать, является ли единственный управляемый DNS-провайдер единой точкой отказа.

Он должен знать, как быстро можно изменить делегирование у регистратора, сколько будут жить кэшированные NS-записи, есть ли у второго провайдера актуальная зона, продолжит ли DNSSEC валидацию и можно ли протестировать аварийное переключение без публичного инцидента.

Для небольших организаций практический ответ может быть не идеальной мультипровайдерной архитектурой, а более узким планом восстановления: второй провайдер, настроенный для самых важных записей, более длинные TTL для стабильных активов, где это уместно, учётные данные регистратора, доступные более чем одному доверенному лицу, внешние страницы статуса, кэшированные аварийные контакты и мониторинг, отличающий сбой DNS-разрешения от сбоя приложения. Это менее элегантно, чем полностью автоматизированное разнообразие, но всё же лучше, чем обнаружить зависимость во время глобального инцидента у поставщика.

Риск распространяется и на нижестоящих пользователей. Маркетплейс, издатель, SaaS-провайдер или платёжный сервис, ставший недоступным, перекладывает издержки на рекламодателей, продавцов, команды поддержки, подрядчиков и клиентов. Пользователь не видит, вызвана ли проблема DNS, DDoS, облачным хостингом, маршрутизацией ISP или ошибкой приложения. Он просто не может совершить операцию. Поскольку управляемый DNS находится так рано в пути, его сбой делает всю последующую избыточность неактуальной, пока не вернётся разрешение имён.

Коммуникация должна была работать на две аудитории

Перед Dyn стояли две коммуникационные проблемы. Она должна была сообщить прямым клиентам, что происходит и чего ожидать. Она также должна была коммуницировать с более широким интернет-сообществом, потому что сбой был виден далеко за пределами договорной клиентской базы Dyn. Публичные пользователи, журналисты, регуляторы, инфраструктурные коллеги и конкуренты — все были заинтересованы в понимании того, был ли это целевой сбой платформы, более широкая нестабильность интернета, чрезвычайная ситуация с ботнетом или проблема концентрации DNS.

Заявление Dyn дало аккуратное провайдерское повествование: не общесистемный сбой, регионально изменчивый, две волны с влиянием на клиентов, отражённая третья попытка, активировано управление инцидентом, привлечены партнёры по смягчению, Mirai подтверждён как один из источников трафика, а больше деталей скрыто для сохранения будущих защит. Такой баланс защитим. Провайдер DDoS-защиты не должен публиковать полный план смягчения во время активной или повторяемой атаки.

Однако клиентам нужно было больше, чем заверения. Им нужна была поддержка решений. Менять ли немедленно DNS-провайдера? Менять ли TTL? Сообщать ли пользователям об outage? Задерживается ли распространение зон? Затронуты ли все регионы? Целы ли DNS-записи клиентов? Какие группы серверов имён деградировали? Ожидается ли повторение? Чем больше провайдер продаёт себя как интернет-инфраструктуру, тем больше его коммуникация о статусе становится частью сервиса.

Инцидент также показал, почему клиентам нужен независимый мониторинг. Страница статуса провайдера может отставать или упрощать. Собственные проверки приложений клиента могут пропустить DNS-сбой, если они выполняются из сети с тёплыми кэшами. Мониторинг должен тестировать авторитетный запрос, рекурсивное разрешение из нескольких регионов, доступность приложений и специфичные для зависимостей сбои. Публичный анализ ThousandEyes был силён потому, что отделял сбой DNS-запросов от общего ощущения пользователей, что «интернет лёг».

Кэши, повторные запросы и подготовка изменили форму ущерба

Сбой DNS переживается неравномерно, потому что рекурсивный слой находится между пользователями и авторитетными провайдерами. Если у рекурсивного резолвера уже есть валидный кэшированный ответ, пользователь может продолжать получать доступ к сервису, даже пока авторитетные серверы нарушены. Если кэшированный ответ истёк или резолвер не имеет ответа, тот же сервис может внезапно стать недоступным из этой сети. Два пользователя в одном городе могут сообщать о разных результатах, потому что их резолверы, кэши и тайминг запросов различаются.

Это поведение усложняет и обвинение, и реагирование. Владелец сервиса может смотреть на свои origin-серверы и видеть нормальное здоровье. Управляемый DNS-провайдер может видеть смесь атакующего трафика, легитимных повторов резолверов, эффектов устаревшего кэша и изменений маршрутов. Рекурсивные операторы могут усиливать давление запросов, повторяя попытки при таймаутах. Пользователи видят прерывистую доступность и могут предполагать, что приложение сломано.

Публичная картина становится «крупные сайты лежат», тогда как техническая реальность больше похожа на «некоторые резолверы не могут получить или обновить авторитетные ответы для некоторых доменов в некоторые окна времени».

Заметка RIPE Labs«Краткий взгляд на атаку на Dyn»использовала измерения RIPE Atlas, чтобы наблюдать событие из распределённых проб. Сопутствующая заметка RIPE Labs«Размышления о DNS-DDoS»подчёркивала, что повторный трафик рекурсивных запросов может усиливать воздействие и что отличать легитимный DNS-трафик от атакующего во время DDoS на самом DNS-протоколе сложно. Это не юридические оценки Dyn. Это объяснения, почему смягчение DNS-DDoS грязнее, чем блокировка одного враждебного источника или добавление одного резервного сервера.

Исследования после инцидента сделали тот же вывод под другим углом. Статья«Когда дамба прорывается: разбор DNS-защит во время DDoS»утверждает, что кэширование — важный фактор устойчивости DNS и что разные DNS-слои могут переживать DDoS очень по-разному. Статья использует инцидент с Dyn как пример видимого сбоя, затронувшего домены, использующие Dyn как DNS-провайдера, отмечая при этом, что другие DNS-цели, такие как корневые серверы, поглощали атаки без видимых сбоев сервиса. Урок не в том, что один DNS-слой безопасен, а другой слаб.

Он в том, что архитектура, кэширование, разнообразие, объём трафика и практика операторов вместе определяют публичное воздействие.

Для клиента управляемого DNS это означает, что подготовка должна включать больше, чем имя вендора в реестре рисков. Клиенту нужно знать, какие записи достаточно стабильны для более долгой жизни в кэше, какие записи требуют динамического управления, какие рекурсивные резолверы важны для его пользователей и как устаревшие ответы могут повлиять на аварийное переключение. Также нужно решить, полезна ли аварийная смена TTL до инцидента или в основном символична, когда кэши уже держат старое значение. DNS-изменения зависят от времени; план восстановления, предполагающий мгновенное глобальное распространение, — не план восстановления.

Общие рекомендации по DDoS подкрепляют ту же операционную дисциплину. Подборка рекомендаций Национального центра кибербезопасности Великобританиипо отказам в обслуживанииописывает подготовку через четыре практики: понять сервис, понять защиты, создать план реагирования и проверить его. Материал CISA«Понимание атак типа „отказ в обслуживании“»объясняет базовую проблему доступности: легитимные пользователи не могут получить доступ к информационным системам, устройствам или сетевым ресурсам.

Более поздний документ CISA, FBI и MS-ISAC«Понимание и реагирование на распределённые атаки типа „отказ в обслуживании“»шире, чем DNS, но принцип тот же: организациям нужны заблаговременная подготовка, координация с сервис-провайдерами, базовые показатели трафика, процедуры реагирования и планы коммуникации.

Эти практики обнажают неудобную правду об облачных зависимостях. Клиент может передать эксплуатацию DNS на аутсорсинг, но не может передать знание того, как сбой DNS влияет на его собственный бизнес. Dyn могла смягчать атаки на свою инфраструктуру; она не могла знать приемлемое деградированное состояние каждого клиента. Банк, маркетплейс, издатель, университет, игровая сеть и портал записи в больницу имеют разную терпимость к медленному разрешению, устаревшим ответам и потере региональной доступности.

План непрерывности клиента должен переводить статус провайдера в бизнес-решения: уведомлять ли пользователей, менять каналы, приостанавливать транзакции, открывать доступ (fail open), закрывать доступ (fail closed) или принимать частичную доступность, пока DNS не стабилизируется.

Для Dyn тот же принцип подготовки действовал в обратном направлении. Управляемый DNS-провайдер должен понимать, что DDoS-событие против его собственной инфраструктуры — не только технический инцидент внутри его сети. Это одновременный кризис клиентов. Клиентам нужно достаточно информации, чтобы не усугубить событие импровизированными изменениями делегирования, сокращением TTL, непоследовательным переносом зон или шквалом обращений в поддержку. Поэтому плейбуки провайдера должны включать смягчение, сегментацию клиентов, точность статуса и рекомендации для клиентов с разным уровнем DNS-компетенции.

Инцидент октября 2016 года был разрушительным отчасти потому, что показал тонкость общего подготовительного слоя. Инженеры DNS понимали кэширование, anycast и авторитетное разрешение. Многие бизнес-лидеры и пользователи — нет. Некоторые клиенты понимали диверсификацию провайдеров. Многие её не внедрили. Эксперты по безопасности IoT понимали риски стандартных учётных данных и неуправляемых парков устройств. Миллионы устройств уже были экспонированы. Общий отказ часто происходит именно тогда, когда специализированные знания существуют в раздельных сообществах, но не превращены в общие операционные обязательства.

Юридическая граница уже, чем операционный урок

Публичная запись устанавливает злонамеренную DDoS-активность, нарушение сервиса Dyn, проблемы с доступностью у клиентов, вовлечённость Mirai и последующие уголовные признания. Она не устанавливает, что Dyn нарушила конкретный контракт, что у каждого пострадавшего клиента отсутствовала разумная архитектура, что каждый производитель IoT нарушил юридическую обязанность или что все убытки можно возложить на одного ответчика. Условия индивидуальных контрактов Dyn, соглашений об уровне сервиса, страховых полисов и третьесторонних зависимостей не являются публичными в той степени, которая поддерживает широкие юридические выводы.

Эта граница не должна ослаблять операционный урок. Она делает его яснее. Юридическая вина привязана к конкретной юрисдикции и форуму. Операционный контроль виден в проектных решениях. Dyn контролировала устойчивость на уровне провайдера и коммуникации. Клиенты контролировали диверсификацию DNS-провайдеров и планирование непрерывности. Вендоры IoT контролировали стандартные учётные данные, пути обновления и поддержку жизненного цикла. Владельцы устройств контролировали развёртывание и базовое усиление лишь в той мере, в какой продукция делала это практичным.

Интернет-провайдеры и охранные фирмы контролировали обнаружение, уведомление и выбор мер смягчения.

Правительства контролировали стимулы, стандарты, реакцию правоохранительных органов и публично-частную координацию.

Инцидент принадлежит анализу ответственности, потому что ни один слой не мог исправить весь сбой сам. Идеальный мультипровайдерный DNS-клиент всё равно мог пострадать от массированного ботнета в другом месте своего стека. Хорошо построенная линейка IoT-продуктов не диверсифицировала бы авторитетный DNS клиента. Блестящий DNS-провайдер всё равно мог столкнуться с беспрецедентным враждебным трафиком с устройств, которые он не продавал. Правительственный отчёт мог рекомендовать безопасность жизненного цикла, но не мог мгновенно заменить миллионы экспонированных устройств. Общий отказ возник из состыковки этих слоёв.

Рыночный сигнал после инцидента

Через месяц после атаки Oracle объявила, что договорилась о приобретении Dyn. Впресс-релизе OracleDyn описывалась как ведущий облачный провайдер интернет-производительности и DNS, сообщалось, что её сеть ежедневно принимает 40 миллиардов решений по управлению трафиком для более чем 3 500 корпоративных клиентов, и назывались такие клиенты, как Netflix, Twitter, Pfizer и CNBC. Приобретение не следует интерпретировать как следствие атаки без доказательств; в релизе этого не говорилось. Тем не менее это полезный контекст рыночной роли Dyn. Это был не нишевый любительский сервис, а крупная платформа управляемого DNS для громких цифровых бизнесов.

Именно эта рыночная позиция объясняет, почему инцидент до сих пор важен. Облачная концентрация часто даёт реальные выгоды: лучшую экспертизу, больший глобальный охват, более быстрое смягчение, специализированный персонал и экономию масштаба. Она также меняет режим отказа. Когда многие клиенты сходятся на одном провайдере, их независимые заявления о непрерывности бизнеса могут стать коррелированными. Платформа может передать функцию на аутсорсинг и при этом нести последствия архитектуры аутсорсинга.

Отчёт Министерства торговли и Министерства внутренней безопасности 2018 года утверждал, что рыночные стимулы для устойчивости к ботнетам были несогласованы. Аналогичная проблема стимулов существовала на клиентской стороне управляемого DNS. Одиночный DNS проще купить, настроить, мониторить и поддерживать. Мультипровайдерный DNS снижает общий риск, но увеличивает инженерную сложность и вероятность ошибок конфигурации. Клиент, избегающий этой сложности, может никогда не быть наказан в обычные времена.

Наказание появляется только когда поставщик отказывает под нагрузкой, и к этому моменту многие клиенты могут переживать одно и то же событие вместе.

Практические проверки ответственности

Дело Dyn даёт руководителям несколько проверок, которые остаются полезными.

Зависимость от авторитетного DNS:Какой провайдер отвечает за каждый критичный домен и поддомен? Все ли перечисленные серверы имён управляются одним провайдером или через одну плоскость маршрутизации и управления? Какие сервисы откажут, если этот провайдер недоступен из крупного региона?

Независимость провайдера:Есть ли второй авторитетный DNS-провайдер с актуальными данными зоны? Если да, действительно ли он независим по сети, плоскости управления, учётным данным, каналу поддержки и смягчению DDoS? Если нет, осознанно ли организация приняла риск единственного провайдера?

Стратегия TTL и кэша:Отражают ли TTL реальную потребность организации в гибкости против терпимости к сбоям? Получают ли самые стабильные записи достаточно долгую жизнь в кэше, чтобы снизить избегаемую зависимость от частых авторитетных запросов во время временных проблем провайдера?

DNSSEC и контроль изменений:Если DNSSEC включён, переживут ли подписи, ключи и DS-записи мультипровайдерную работу или аварийную смену провайдера? Если нет, запасной вариант может безопасно отказывать (fail secure), что всё равно означает: пользователи не могут достичь сервиса.

Мониторинг:Может ли организация отличать сбой авторитетного DNS, проблемы рекурсивных резолверов, проблемы CDN, сбой origin и сбой приложения? Запускаются ли тесты из достаточного числа сетей и регионов, чтобы обнаружить anycast- или региональную DNS-проблему?

Восстановление через регистратора:Документированы ли учётные данные регистратора, регистратурные замки (registry locks), аварийные контакты и процедуры смены делегирования, защищены ли они и доступны во время инцидента? Резервный DNS-провайдер бесполезен, если никто не может безопасно сменить делегирование.

Коммуникация с поставщиком:Предоставляет ли управляемый DNS-провайдер детали статуса на том уровне, который нужен клиентам для принятия решений, не раскрывая оборонительные методы? Спроектированы ли каналы поддержки для события с одновременным воздействием, когда много клиентов просят помощи разом?

Экспозиция к ботнетам:Для организаций, которые производят, развёртывают или управляют подключёнными устройствами, спроектированы ли стандартные учётные данные, безопасное обновление, идентификация устройств, отчётность об уязвимостях и поддержка конца жизненного цикла так, чтобы парк устройств не стал чьей-то DDoS-мощностью?

Эти проверки — не абстрактная инженерная чистота. Так владелец домена узнаёт, означает ли «у нас избыточные серверы имён» настоящую независимость от отказов или просто несколько имён хостов внутри одной зависимости от провайдера.

Урок на будущее

Dyn не доказала, что управляемый DNS плох. Ближе к истине противоположное: управляемый DNS существует потому, что доступность DNS сложна, специализирована и глобально экспонирована. Многие клиенты были бы менее устойчивы, если бы им пришлось запускать собственную авторитетную инфраструктуру без экспертизы. Инцидент доказал, что аутсорсинг не стирает архитектуру. Он переносит часть архитектуры к поставщику, а затем требует от клиента решить, является ли поставщик компонентом или общей зависимостью.

И Mirai не доказал, что потребительский IoT можно винить в каждом инфраструктурном сбое. Он доказал, что незащищённые периферийные устройства могут быть агрегированы в силу, достаточную для угрозы ключевым сервисам. Домохозяйства и бизнесы, владевшие этими устройствами, не намеревались атаковать Dyn. Производители устройств могли не представлять свою продукцию как части интернет-инфраструктуры. Но публичный интернет сделал их участниками в любом случае.

Ответственная память об инциденте с Dyn должна быть многослойной. Преступные субъекты запускали атаки. Dyn защищала высокоценную DNS-платформу под экстремальным враждебным трафиком и всё же испытала нарушение, затронувшее клиентов. Многие клиенты зависели от одного провайдера авторитетного DNS и обнаружили, что несколько серверов имён не всегда означают диверсификацию провайдеров. Вендоры и владельцы IoT допустили, чтобы слабые устройства стали ресурсами атак. Правительства и органы стандартизации позже описали устойчивость к ботнетам как рыночную и экосистемную проблему, а не просто вопрос наказания одного злоумышленника.

Практический урок суров: доступность зависит от скучной контрольной плоскости. Компания может построить избыточные серверы приложений, несколько облаков, активно-активные регионы и сложное реагирование на инциденты — и всё равно исчезнуть из браузеров пользователей, если её зависимость от авторитетного DNS — единственный провайдер и он недоступен. Делегирование DNS — это власть. Относиться к нему как к строке закупок с низким риском — так управляемый сервис становится общим отказом.