Dyn показал, что аутсорсинг DNS может стать отказом по общей причине

Главное

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

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

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

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

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

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

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

Анализ ThousandEyes —The DDoS Attack on Dyn's DNS Infrastructure— даёт самое ясное публичное объяснение зависимости со стороны клиента. Мониторинг зафиксировал три фазы: первоначальное воздействие, сосредоточенное на Восточном побережье США, более широкое глобальное воздействие и последующее отражение атаки с остаточными атаками или сбросом трафика (блэкхолингом). На пике атаки примерно три четверти её глобальных точек наблюдения отправляли 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 и игровая сеть Sony PlayStation Network.Тогдашний репортаж The Guardianперечислял Netflix, Twitter, Spotify, Reddit, CNN, PayPal, Pinterest, Fox News и крупные газеты среди сервисов, которые, по сообщениям, были недоступны или работали с нарушениями. Эти материалы полезны для понимания масштаба и общественного восприятия; они не доказывают, что каждый названный сервис испытал один и тот же технический сбой или одинаковую продолжительность проблем.

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

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

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

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

СтатьяThe Lack of Redundancy in DNS Resolution by Major Websites and Servicesрассматривала концентрацию и диверсификацию DNS после инцидента с Dyn. В ней выявлена растущая концентрация у небольшого числа DNS-провайдеров и сильная тенденция доменов не использовать нескольких провайдеров управления DNS. В выборке доля доменов с одним провайдером составляла примерно 91–93 % до атаки и снизилась с 92,2 % до 89,4 % в период с октября по ноябрь 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 Understanding the Mirai Botnetописывает Mirai как состоящий в основном из встраиваемых устройств и устройств интернета вещей и говорит, что он вырос до пика примерно в 600 000 заражений. В статье утверждается, что простота метода заражения и быстрый рост показали: относительно несложные методы способны скомпрометировать достаточно много дешёвых устройств, чтобы угрожать хорошо защищённым целям.

В объявлении Министерства юстиции о Mirai 2017 года —Justice Department Announces Charges and Guilty Pleas in Three Computer Crime Cases Involving Significant DDoS Attacks— говорилось, что Paras Jha, Josiah White и Dalton Norman признали вину в управлении ботнетом Mirai, который нацеливался на IoT-устройства, такие как беспроводные камеры, роутеры и видеорегистраторы. Минюст сообщил, что на пике Mirai состоял из сотен тысяч скомпрометированных устройств и что участие первоначальных создателей в исходном варианте Mirai закончилось, когда Jha осенью 2016 года опубликовал исходный код на криминальном форуме.

После этого, по данным Минюста, другие лица использовали варианты Mirai в других атаках.

Объявление Министерства юстиции 2020 года —Individual Pleads Guilty to Participating in Internet-of-Things Cyberattack in 2016— связало ботнет на базе варианта Mirai с днём атаки на Dyn более прямо. В нём говорилось, что человек, ранее бывший несовершеннолетним, признал вину в связи с кибератакой на устройства интернета вещей в октябре 2016 года.

По данным Минюста, этот человек и другие использовали ботнет для запуска нескольких 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, —Enhancing the Resilience of the Internet and Communications Ecosystem Against Botnets and Other Automated, Distributed Threats— описал проблему как общеэкосистемную: автоматизированные распределённые атаки глобальны, эффективные инструменты не используются широко, продукцию следует защищать на всём жизненном цикле, стимулы искажены, и ни одно сообщество заинтересованных сторон не сможет решить проблему в одиночку.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Исследования после инцидента сделали тот же вывод под другим углом. СтатьяWhen the Dike Breaks: Dissecting DNS Defenses During DDoSутверждает, что кэширование — важный фактор устойчивости DNS и что разные уровни DNS могут переживать DDoS очень по-разному. В статье инцидент с Dyn используется как пример видимого сбоя, затронувшего домены, использующие Dyn в качестве DNS-провайдера, при этом другие DNS-цели, например корневые серверы, поглощали атаки без видимых сбоев сервиса. Урок не в том, что один уровень DNS безопасен, а другой слаб.

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

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

Изменения DNS зависят от времени; план восстановления, предполагающий мгновенное глобальное распространение, — не план восстановления.

Общие рекомендации по DDoS укрепляют ту же операционную дисциплину.Подборка рекомендаций Denial of ServiceНационального центра кибербезопасности Великобритании (NCSC) строится вокруг четырёх практик: понять сервис, понять защиты, создать план реагирования и протестировать реагирование.Понимание DoS-атак (Understanding Denial-of-Service Attacks)от CISA объясняет базовую проблему доступности: легитимные пользователи не могут получить доступ к информационным системам, устройствам или сетевым ресурсам.

Более поздние материалы CISA, ФБР и MS-ISAC —Understanding and Responding to Distributed Denial-of-Service Attacks— шире DNS, но принцип подходит: организациям нужны заблаговременная подготовка, координация с поставщиками услуг, базовые показатели трафика, процедуры реагирования и планы коммуникации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Урок, который останется

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

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

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

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