DDoS-атака Route 53: проверка подотчётности координации DNS

Краткое изложение

Сохранённое сообщение AWS указывает, что Amazon обнаружила и смягчила DDoS-атаку на Route 53 22 октября 2019 года. Атака была направлена на определённые DNS-имена и пути, в частности глобальные имена, используемые для бакетов S3. Запросы достигали Route 53 через рекурсивные резолверы, работавшие в других точках интернета. [1]
AWS заявила, что небольшое число интернет-провайдеров, управляющих затронутыми резолверами, применили собственные стратегии смягчения. Эти меры привели к сбоям при поиске через эти резолверы для небольшого числа имён AWS. AWS сообщила, что выявляет и связывается с операторами, чтобы улучшить меры смягчения. [1]
Современные сообщения описывали периодические ошибки разрешения, пометку легитимных запросов при смягчении и влияние на конечные точки сервисов AWS, зависящих от публичного DNS. Позже в отчёте приводились слова AWS о том, что периодические ошибки происходили с 10:30 до 18:30 по тихоокеанскому времени, а более высокий уровень ошибок для очень небольшого числа имён начался в 17:16. Эти детали остаются приписанными сообщениями, а не полной независимой записью пакетов. [21]
Документированная архитектура Route 53 использует множество пограничных узлов, разнообразные подключения, shuffle sharding и anycast striping. AWS также описывала фильтрацию и приоритезацию трафика. Эти заявления о проектировании объясняют доступные средства защиты, но не доказывают, как каждый узел, резолвер или правило вели себя во время события 2019 года. [2]
Независимый анализ Whalebone указал, что трафик соответствовал шаблону медленного капания (slow-drip) или случайных поддоменов, и обсуждал агрессивное негативное кэширование DNSSEC как возможную защиту. AWS не подтвердила эту характеристику в сохранённом сообщении. Это остаётся приписанной гипотезой, а не установленной причиной. [22]
Авторитативный DNS и рекурсивное разрешение — это разные плоскости контроля. Оператор авторитативного сервера публикует и обслуживает данные зоны. Рекурсивные резолверы выбирают авторитативные серверы, кэшируют ответы, повторяют попытки при сбоях и применяют локальные политики. Крупные anycast-развёртывания также зависят от интернет-маршрутизации и неравномерного распределения нагрузки. [11][19][20]
Защитные меры резолверов могут приводить к побочным сбоям. Блокировка, ограничение скорости, сброс или перенаправление подозрительного трафика может сохранить работоспособность резолвера, но подавить корректные запросы. Предоставление устаревших данных может улучшить непрерывность в некоторых условиях, но жертвует актуальностью ради доступности и не может считаться включённым в данном событии. [13]-[15]
Отказоустойчивость на уровне записей Route 53 может перемещать имя приложения между конечными точками. Она не предоставляет автоматически независимый авторитативный DNS-провайдер. Клиентам необходимо различать отказоустойчивость конечной точки и диверсификацию плоскости управления. [9][10]
Подотчётность следует за практическим контролем: AWS контролировала авторитативную границу Route 53 и собственные меры смягчения; операторы резолверов и интернет-провайдеров контролировали локальные правила и кэши; другие сети контролировали проверку источника и доставку трафика; клиенты контролировали отображение зависимостей и архитектуру в рамках реальных контрактных ограничений.
Стандарт восстановления — это согласованная цепочка доказательств: уровни авторитативных ответов, ложные срабатывания для каждого имени и класса запросов, состояние распределения anycast-нагрузки, различия правил резолверов, записи об истечении срока и отмене мер, многосетевые проверки, уведомления клиентов и доказательства восстановления корректных имён.

Публичные данные определяют границу смягчения

Наиболее важным источником, относящимся к событию, является сообщение AWS, сохранённое SRE Weekly, поскольку исторический статусный сайт AWS было трудно просматривать и давать прямые ссылки. В сохранённом тексте говорится, что AWS обнаружила, а затем смягчила DDoS-атаку на Route 53 22 октября 2019 года. Также отмечается, что атака сначала ощущалась многими другими операторами DNS-серверов, когда запросы проходили через интернет-резолверы к Route 53. Были атакованы определённые DNS-имена и пути, особенно те, которые используются для доступа к глобальным именам бакетов S3. [1]

Следующий абзац является поворотным для подотчётности. AWS описала атаку как широко распределённую. Небольшое число интернет-провайдеров, управляющих затронутыми DNS-резолверами, внедрили собственные стратегии смягчения. AWS заявила, что эти меры приводили к сбоям DNS-поиска через эти резолверы для небольшого числа имён AWS. Организация пыталась выявить и связаться с этими операторами, чтобы доработать меры смягчения так, чтобы они не влияли на корректные запросы. [1]

Это заявление указывает не только на сбой. Оно определяет по меньшей мере две различные домены защиты:

Авторитативный сервис Route 53 обнаружил и смягчил вредоносный трафик.
Операторы рекурсивных резолверов заметили последствия и развернули локальные меры смягчения.

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

Современные сообщения добавляют запись о времени и симптомах, но к ним нужно подходить осторожно. The Register сообщил, что служба поддержки AWS описала DDoS-атаку, заявила, что меры смягчения поглощают большую часть трафика, но помечают некоторые легитимные запросы клиентов, и предложила использовать региональные имена конечных точек S3 в качестве обходного пути для некоторых клиентов S3. Также сообщалось о периодических влияниях на другие конечные точки сервисов AWS, требующих разрешения публичного DNS.

В более позднем обновлении издание процитировало AWS: периодические ошибки для некоторых имён AWS DNS происходили с 10:30 до 18:30 по тихоокеанскому времени, а для очень небольшого числа имён повышенный уровень ошибок начался в 17:16. [21]

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

DNS-запрос пересекает независимо управляемые системы

Пользователь, вводящий имя приложения, обычно не отправляет запрос напрямую авторитативному серверу домена. Стаб-резолвер на устройстве отправляет запрос рекурсивному резолверу. Этот резолвер может ответить из кэша. Если пригодного кэшированного ответа нет, он следует по цепочке делегирования DNS и запрашивает авторитативные серверы. RFC 1034 и RFC 1035 определяют концепции и поведение сообщений, лежащие в основе этого процесса. [19][20]

RFC 9199, написанный для крупных операторов авторитативного DNS, ясно излагает различие. Авторитативный сервер знает содержимое зоны и отвечает из своей локальной копии. Рекурсивный резолвер итеративно опрашивает авторитативные и другие серверы от имени клиентов. Резолвер решает, к какому доступному авторитативному серверу обратиться и как реагировать на задержки или сбои. [11]

Таким образом, транзакция пересекает несколько практических точек контроля:

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

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

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

Архитектура Route 53 объясняет защиты, но не конкретное событие

AWS публично описывала устойчивость Route 53 к DDoS до атаки 2019 года. В публикации AWS 2016 года говорилось, что сервис работал на многочисленных пограничных узлах, создавая большую глобальную поверхность для DNS-трафика. Описывались множественные интернет-подключения на каждом узле, shuffle sharding и anycast striping. Согласно версии AWS, каждый сервер имён в наборе делегирования клиента соответствует уникальному набору пограничных узлов, уменьшая пересечение между клиентами. Если один сервер имён недоступен, клиент может повторить попытку с другим. Anycast striping распределяет запросы и может уменьшать задержку. [2]

AWS также описывала детерминированную пакетную фильтрацию и приоритезацию трафика на пограничных узлах. [2] Более поздние материалы AWS говорили, что Route 53 и CloudFront выигрывают от глобальной пограничной ёмкости и встроенного смягчения. В обзоре угроз 2020 года отмечалось, что отражение DNS остаётся распространённым вектором на уровне инфраструктуры, наблюдаемым AWS Shield, в то время как флуд-запросы на уровне приложений могут создавать непропорциональную нагрузку при меньшем трафике. [3]

Эти документы помогают объяснить набор инструментов контроля:

географическое и сетевое распределение;
множественные авторитативные серверы имён;
распределение anycast-нагрузки;
изоляция клиентов через shuffle sharding;
разнообразные подключения;
фильтрация;
формирование трафика;
мониторинг и встроенное смягчение.

Они не устанавливают, какой механизм отказал или сработал 22 октября 2019 года. Блог 2016 года предшествует событию, но является объяснением продукта и архитектуры, а не трассировкой пакетов. Обзор 2020 года следует за событием и сообщает о более широких наблюдениях Shield, а не о ретроспективном разборе Route 53. Текущие технические документы и руководства описывают современные рекомендации, а не полное историческое состояние контроля. [2]-[7]

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

Anycast распределяет нагрузку и усложняет наблюдение

Крупные авторитативные DNS-системы часто сочетают несколько адресов серверов имён с anycast. Один и тот же IP-адрес сервиса может анонсироваться из многих физических мест. Интернет-маршрутизация затем сопоставляет резолвер с экземпляром в соответствии с маршрутами, видимыми из сети этого резолвера. [11]

Такая архитектура даёт оператору ёмкость и географическое распределение, но не делает систему однородной. RFC 9199 отмечает, что поведение резолвера, связность маршрутизации и дизайн развёртывания влияют на то, какой авторитативный сервер и экземпляр получает запросы. Большее количество точек не автоматически лучше, чем хорошо подключённые точки. Нагрузка может распределяться неравномерно, и изменение маршрутизации может перемещать нагрузку между экземплярами способами, которые трудно предсказать, исходя из простого подсчёта узлов. [11]

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

Документ рекомендует операторам готовить обе стратегии и выбирать их на основе измеряемых условий. [11]

Публичные данные 2019 года не говорят, какие экземпляры Route 53 использовали какую стратегию. Нет карт нагрузки, изменений маршрутов или показателей ответов на каждом узле. Это отсутствие данных важно, потому что пользователи в разных сетях могли испытывать разные результаты в одно и то же время.

Таким образом, надёжная запись инцидента должна включать:

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

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

Парадокс смягчения на стороне резолвера

Сохранённое сообщение AWS говорит, что некоторые управляемые интернет-провайдерами резолверы внедрили меры смягчения, которые привели к сбоям корректных запросов для небольшого числа имён AWS. [1] Это классический парадокс защитного контроля: контроль может снизить один риск, одновременно увеличивая другой.

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

Каким бы ни был механизм, возникают четыре вопроса управления.

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

Во-вторых, какой существовал тест на корректность запроса? До и после развёртывания оператор мог протестировать фиксированный набор заведомо корректных имён, типов запросов, состояний DNSSEC и размеров ответа через тот же производственный путь. Мера смягчения, которая проходит проверку работоспособности инфраструктуры, но не обеспечивает разрешение реальных имён, является неполной.

В-третьих, каким было поведение при истечении срока и откате? Экстренные правила накапливают риск, когда у них нет временного ограничения, владельца и условия удаления. Тот факт, что AWS пришлось выявлять и связываться с операторами, предполагает, что координация не была мгновенной. Долговременное правило должно фиксировать, кто его развернул, почему, какой трафик оно затрагивает, когда истекает и какие измерения разрешают откат.

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

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

Отражение — это релевантный контекст, но не доказанная причина

DNS часто используется в атаках с отражением и усилением, поскольку UDP допускает подделку адреса источника, а некоторые DNS-запросы могут порождать ответы, большие по размеру, чем запросы. RFC 5358 описывает, как открытые рекурсивные резолверы могут использоваться в качестве отражателей, и подчёркивает, что крупномасштабная фильтрация входящего трафика является фундаментальной защитой от использования поддельных источников. Он также рекомендует ограничивать рекурсивное обслуживание предполагаемыми клиентами и разделять рекурсивные и авторитативные роли, где это практически возможно. [12]

RFC 2827 и RFC 3704 описывают проверку адреса источника для обычных и многодомных сетей. Эти меры контроля находятся вне прямых полномочий Route 53, когда пакеты исходят или проходят через не связанные с ним сети. Они показывают, почему подотчётность при DDoS может распространяться на сети, которые никогда не управляют сервисом-жертвой. [17][18]

Но релевантность — это не доказательство. Сохранённое сообщение AWS называет событие широко распределённым и описывает целевые имена и пути. Там не говорится, что атака была атакой с отражением, не указываются поддельные источники и не называется ботнет. Обзор Shield 2020 года говорит, что отражение DNS было распространённым в наблюдениях AWS, но он касается более позднего агрегированного набора данных. [1][3]

Поэтому два утверждения должны оставаться раздельными:

Отражение и подделка — хорошо известные механизмы DDoS-атак на DNS, и у сетевых операторов есть признанные обязанности по проверке источника.
Доступные публичные данные не подтверждают, что эти механизмы вызвали событие с Route 53 в октябре 2019 года.

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

Гипотеза «медленного капания» должна оставаться приписанной

Whalebone опубликовала независимый анализ через три дня после события. В нём говорилось, что инцидент, по-видимому, мог соответствовать шаблону «медленного капания» (slow-drip), при котором атакующий отправляет множество запросов для несуществующих псевдослучайных поддоменов авторитативным серверам имён. Поскольку имена новы, обычное позитивное кэширование менее эффективно, и авторитативный сервис многократно обрабатывает промахи. Whalebone заявила, что наблюдаемый ею трафик включал характерные запросы, и сообщила о более раннем всплеске 19 октября, который она сочла возможной проверкой. [22]

Этот анализ предлагает правдоподобный механизм, объясняющий важность рекурсивного поведения. В нём также обсуждается агрессивное использование проверенной DNSSEC информации негативного кэширования, где записи NSEC или NSEC3 могут позволить проверяющему резолверу сделать вывод, что дополнительные имена не существуют, без отправки каждого запроса авторитативному сервису. [22]

У гипотезы есть ограничения.

Whalebone не является AWS. Её анализ не раскрывает полный общий набор данных, универсальные точки наблюдения или внутреннюю телеметрию AWS. В сохранённом сообщении AWS не используется фраза «медленное капание». Оно не подтверждает псевдослучайные поддомены, состояние DNSSEC или проверочный цикл. Таким образом, данные подтверждают формулировку «Whalebone оценила», а не категорическое утверждение «атака была».

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

Такая ограниченная трактовка полезна, потому что превращает спекулятивное утверждение о первопричине в проверяемый запрос на данные:

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

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

Кэширование — компромисс между актуальностью, гибкостью и непрерывностью

Кэширование — часть устойчивости DNS, поскольку резолвер может отвечать на повторяющиеся вопросы, не связываясь каждый раз с авторитативным сервисом. Большие значения времени жизни (TTL) могут снизить нагрузку на авторитативный сервис и сохранять ответы при кратковременном перерыве. Короткие TTL делают запланированные изменения и управление трафиком более оперативными. RFC 9199 подчёркивает, что не существует единого значения TTL, подходящего для всех систем, поскольку устойчивость и гибкость тянут в разные стороны. [11]

Предоставление устаревших данных добавляет ещё одну опцию. RFC 8767 определяет метод, позволяющий рекурсивным резолверам использовать истёкшие кэшированные данные, когда авторитативные серверы недоступны, в заданных пределах и с операционными гарантиями. [14] Цель — непрерывность, а не создание видимости, что ответ актуален.

RFC 8906 добавляет диагностическое ограничение: с точки зрения резолвера, сервер, который не отвечает, может быть неотличим от потери пакетов. Тайм-аут не объясняет, произошёл ли сбой авторитативного процесса, был ли перегружен путь, отозван ли anycast-экземпляр или фильтр отбросил обмен. [15]

Эти механизмы создают проблему сбора данных во время DDoS:

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

Данные 2019 года не показывают, какие резолверы обслуживали устаревшие данные, переопределяли TTL, агрессивно повторяли попытки или подавляли запросы. Это вопросы расследования, а не факты, которые можно изобрести.

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

DNS Cookies — условный инструмент

RFC 7873 определяет DNS Cookies — лёгкий механизм, предназначенный для того, чтобы помочь серверам отличать легитимных клиентов от поддельного трафика вне пути и обеспечивать некоторую устойчивость к усилению и злоупотреблению типа «отказ в обслуживании». [16]

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

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

Вопрос подотчётности не в том, существует ли документ стандарта. А в том, знают ли операторы, какие клиенты поддерживают этот механизм, какое резервное поведение сохраняет обслуживание, как контроль работает при наблюдаемом классе атаки и какие данные о ложных срабатываниях сохраняются.

Это ещё один пример примата работающего кода. Опция протокола в документации — это потенциал. Согласованное поведение, наблюдаемый трафик и измеренные результаты — это операционный факт.

Отказоустойчивость конечной точки не является диверсификацией авторитативного провайдера

Route 53 поддерживает проверки работоспособности и записи отказоустойчивости DNS. Владелец приложения может настроить основной и резервный ресурс, связать проверки работоспособности и получать от Route 53 ответ с работоспособной целью в соответствии с настроенной политикой. [10]

Это полезная отказоустойчивость приложения. Сама по себе она не делает авторитативный путь Route 53 независимым.

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

Независимые авторитативные провайдеры могут уменьшить эту общую моду, но создают другие обязательства. Данные зоны должны оставаться согласованными. Делегирования и glue-записи должны быть корректными. Ключи и подписи DNSSEC требуют согласованной модели. Семантика работоспособности не должна приводить к тому, что провайдеры возвращают противоречивые ответы. TTL, последовательность изменений, контроль доступа и владение инцидентом требуют репетиций. RFC 9199 предостерегает от рассмотрения одного дизайна как универсально оптимального. [11]

Правильный вопрос клиента не «Используем ли мы двух провайдеров?», а «Какие домены сбоев независимы, и что доказывает, что переключение работает?»

Данные могут включать:

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

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

Глобальные имена S3 показывают, что именование — это инфраструктура

В сохранённом сообщении AWS говорится, что атака особенно сильно затронула пути, используемые для доступа к глобальным именам бакетов S3. [1] The Register сообщил, что поддержка AWS предложила региональные имена конечных точек S3 для некоторых пострадавших клиентов и описала влияние на публичный DNS для других конечных точек сервисов AWS. [21]

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

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

Ответственный урок — не отказ от DNS, а инвентаризация зависимостей именования так же серьёзно, как каналов и серверов.

Для каждого критического вызова приложения оператор должен знать:

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

Такая инвентаризация превращает расплывчатую «облачную зависимость» в конкретную цепочку разрешения.

Подотчётность следует за возможностями, а не только за видимостью

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

Amazon Web Services

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

AWS не контролировала каждый рекурсивный резолвер, фильтр интернет-провайдера, клиентское приложение или сеть-источник. Строгий отчёт не должен приписывать эти решения AWS только потому, что затронутые имена были именами AWS.

Операторы рекурсивных резолверов и интернет-провайдеры

Операторы резолверов контролировали локальные кэши, повторы, ограничения скорости, фильтры, выбор сервера и ответ или ошибку, возвращаемые клиентам. Заявление AWS прямо указывает на меры смягчения на стороне резолверов как на источник сбоя корректных запросов для некоторых имён. [1]

Эти операторы могли иметь меньшую видимость внутренней классификации атаки AWS. Эта информационная асимметрия усиливает необходимость быстрого контакта для abuse-сообщений и пути координации. Она не снимает обязанности тестировать ложные срабатывания и удалять экстренные правила.

Сети доступа, транзита и источника

Сети, несущие трафик, контролировали ёмкость, маршрутизацию, фильтрацию и, во многих случаях, проверку адреса источника. BCP 38 и BCP 84 описывают обязанности по предотвращению подделки. [17][18] Публичные данные не доказывают, что поддельный трафик двигал эту атаку, поэтому эти обязанности остаются более широким уровнем предотвращения, а не специфичным для инцидента выводом.

Клиенты

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

Клиенты не контролировали пограничное смягчение Route 53 или правило резолвера интернет-провайдера. «Разделённая ответственность» не должна становиться фразой, перекладывающей контролируемые провайдером сбои на клиентов.

Разработчики стандартов и реализаций ПО

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

Abuse-контакты — это операционный контроль

AWS заявила, что выявляет и связывается с операторами резолверов, чтобы улучшить их меры смягчения. [1] Это предложение раскрывает зависимость управления, которую технические диаграммы часто упускают: инцидент нельзя было полностью устранить, изменяя только Route 53.

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

Качество контактов можно тестировать.

Существует ли актуальный круглосуточный контакт для резолвера или сети?
Может ли сообщающая сторона идентифицировать себя и аутентифицировать инцидент?
Могут ли обе стороны обмениваться индикаторами без излишнего раскрытия данных клиентов?
Имеет ли принимающий оператор полномочия изменить или удалить правило?
Существует ли общий для организаций идентификатор инцидента?
Можно ли привязать каждое действие к временной метке и соотнести с измерениями?
Есть ли резервный вариант, когда основной канал не отвечает?

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

Коммуникация должна описывать отказавший уровень

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

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

Например:

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

Это более действенно, чем «ошибки DNS», и более честно, чем объявлять о полном восстановлении с одной точки наблюдения.

Коммуникация о восстановлении также должна отличать авторитативное восстановление от очистки резолвера. Граничный узел Route 53 может отвечать корректно, в то время как резолвер сохраняет блокировку, состояние сбоя или кэшированный результат. Многосетевые пробы и сообщения клиентов могут показать, когда сквозной путь восстановился.

Матрица проверки для смягчения DNS-атак

Событие предполагает конкретную систему сбора данных.

Состояние авторитативного сервиса

Интенсивность запросов по классу имён, типу запроса, коду ответа и anycast-экземпляру
Показатели корректных ответов, тайм-аутов и сброшенных запросов
Сигналы ёмкости и насыщения
Изменения фильтрации и формирования с указанием владельца, охвата и срока истечения
Изменения зон нагрузки и маршрутов
Результаты проверок заведомо корректных запросов из независимых сетей

Состояние рекурсивного резолвера

Показатели попаданий в кэш, промахов, вышестоящих тайм-аутов и кодовSERVFAIL
Различия экстренных правил и количество совпавших запросов
Тестовые примеры заведомо корректного и заведомо вредоносного трафика
Поведение повторов и выбора авторитативного сервера
Политика обслуживания устаревших ответов и её использование
Время отката и проверка после удаления правила

Состояние сети

Достижимость каждого авторитативного адреса
Измерения пути и потери пакетов из нескольких сетей доступа
Позиция проверки источника, где релевантно
Запросы на вышестоящую фильтрацию и их длительность
Свидетельства перемещения нагрузки после изменений маршрутизации

Состояние клиента

Инвентаризация критических имён
Зависимости от резолвера и авторитативного сервиса
Поведение глобальных и региональных конечных точек
Обработка сбоев и лимиты повторов
Поддерживаемые обходные пути и откат
Видимое пользователем восстановление по географии и провайдеру доступа

Состояние координации

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

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

Как выглядело бы доказательство исправления

Обещание после инцидента слабее, чем повторное упражнение.

Для Route 53 доказательство могло бы включать контролируемое воспроизведение представительных классов вредоносных запросов в изолированной или безопасной для производства среде, показывающее, что корректные запросы продолжают получать ответы в заданных пределах ошибок. Тестирование anycast могло бы показать, что смягчение на одном экземпляре не перегружает другой. Оператор мог бы сохранять версии правил, результаты канареечных проверок, измерения для каждого экземпляра и пороги автоматического отката.

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

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

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

Самое сильное доказательство — не совершенное утверждение о предотвращении. Это доказательство того, что система обнаруживает, сдерживает и обращает вспять сбой, сохраняя легитимное обслуживание.

Почему тезис о сетевой инфраструктуре нельзя удалить

Этот случай подотчётности — не общая история о корпоративном кризисном управлении.

Причинная цепочка зависит от:

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

Уберите эти факты, и аргумент исчезнет. Нет эквивалентного тезиса об общем бизнес-сбое, репутации бренда или внутренней управленческой культуре.

Центральный принцип заключается в том, что работающее состояние превосходит номинальные записи. Домен может быть зарегистрирован. Размещённая зона может содержать корректные данные. Может существовать SLA. Заявка на смягчение может быть одобрена. Ни один из этих фактов не гарантирует, что резолвер получит и вернёт корректный ответ.

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

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

Ограничения источников

SRE Weekly сохраняет наиболее важный текст сообщения AWS, но это архив статусного заявления, а не полный разбор инцидента AWS. Процитированный текст устанавливает описание AWS события и эффектов мер смягчения на стороне резолвера. Он не предоставляет сырую телеметрию, идентификаторы резолверов или полную временную шкалу. [1]

Пост AWS 2016 года о Route 53 и Shield описывает архитектуру и дизайн смягчения. Обзор угроз 2020 года предоставляет более поздние агрегированные наблюдения. Текущие технические документы AWS и документация Route 53 описывают средства контроля и опции для клиентов. Ничто из этого не доказывает точную конфигурацию или использование средств контроля 22 октября 2019 года. [2]-[10]

RFC 9199 был опубликован в 2022 году. Он обобщает исследования по эксплуатации крупных авторитативных DNS и предлагает полезные соображения по anycast, маршрутизации и TTL. Это не отчёт о событии и не консенсусный стандарт IETF. [11]

Остальные RFC определяют механизмы, риски или операционные практики. Они не устанавливают, что отражение, подделка, обслуживание устаревших данных, DNS Cookies или конкретная мера смягчения присутствовали во время события. [12]-[20]

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

Whalebone предлагает независимый анализ шаблона атаки. Её интерпретация «медленного капания», наблюдение от 19 октября и предложение негативного кэширования DNSSEC остаются приписанными утверждениями. Заявление AWS, сохранённое SRE Weekly, не подтверждает их. [22]

Публичные источники не устанавливают:

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

Эти неизвестные являются частью записи о подотчётности. Более сильное расследование запросило бы отсутствующие данные, а не заполняло пробелы уверенностью.

Заключение

DDoS-атака на Route 53 в 2019 году показала, что смягчение — это проблема распределённых систем.

AWS контролировала крупный авторитативный DNS-сервис и заявила, что обнаружила и смягчила атаку. Операторы резолверов увидели событие через свою инфраструктуру и развернули локальные защиты. Некоторые из этих защит затем вызвали сбои корректных запросов имён AWS. AWS пришлось выявлять и связываться с операторами для улучшения правил. [1]

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

Таким образом, подотчётный стандарт — сквозной:

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

Релевантные доказательства — это наблюдаемое состояние: показатели ответов, совпадения правил, поведение кэша, измерения маршрута и достижимости, пробы заведомо корректных запросов, записи отката и видимое пользователем восстановление из множества сетей.

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

Урок более узок и требователен, чем «наращивайте мощность». Мощность важна. Anycast важен. Кэширование важно. Протокольные защиты важны. Ни одно из них нельзя оценивать изолированно.

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

DDoS-атака 2019 года на Route 53 превратила координацию DNS-защиты в проверку подотчётности