DDoS Spamhaus 2013: открытая DNS-рекурсия как тест подотчётности

Резюме

CLOUDFLARE сообщила о первоначальной атаке, которая насытила канал связи Spamhaus, и о последующих волнах отражённого DNS-трафика, наблюдавшихся с более высокими скоростями, однако эти наблюдения провайдера не устанавливают универсальный пик интернета или глобальный сбой. [1][2]
Исполняемый путь объединил поддельный исходный адрес, открытый рекурсивный резолвер, усиленный ответ и общие звенья маршрутизации или смягчения атаки. Рекурсивный и авторитативный DNS остаются разными ролями. [4][10]
RFC 5358 уже рекомендовал ограничивать рекурсию, а BCP 38 и BCP 84 возлагали проверку исходных адресов на границы сетей доступа, клиентских и многосетевых сетей. [4][5][6]
Операторы резолверов, сети доступа, провайдеры смягчения атак, вышестоящие сети, точки обмена и Spamhaus контролировали разные части рабочего пути; ответственность требует доказательств, привязанных к конкретному пути, а не институциональных ярлыков.
Недоступность веб-сайта не доказывала, что распределённые блок-листы Spamhaus перестали работать глобально. Заявления об уровне сервиса должны указывать конечную точку, путь и окно наблюдения. [3]
Более поздние механизмы DNS, материалы RIPE, MANRS, DNS-OARC и исследования дают полезные инструменты сравнения и проверки, но их нельзя проецировать назад как средства контроля, доступные в том же виде в марте 2013 года. [7]–[9][14]–[19]
Проверка подотчётности — операционная: закрыть непреднамеренную рекурсию, проверять исходные адреса, документировать изменения маршрутизации и смягчения, сохранять доказательства координации и проверять устранение сбоев извне затронутого пути.

Схема подотчётности

Атака на Spamhaus в марте 2013 года стала проверкой подотчётности для обычных сетевых средств контроля, а не просто легендой об одном огромном потоке. С 18 по 27 марта трафик сначала нарушил работу веб-сайта Spamhaus, а затем затронул инфраструктуру, используемую провайдерами CLOUDFLARE и поверхностью пиринга. Путь объединил независимо управляемые системы: поддельные исходные адреса, открытые рекурсивные DNS-серверы, принимавшие запросы, увеличенные ответы, направленные на поддельный адрес назначения, и общие каналы, несущие совокупную нагрузку.

Современные событию публикации CLOUDFLARE фиксируют это событие; более ранние стандарты показывают, какие операторы контролировали ключевые части этого пути [1][2][4][5][6].

Рекурсивный и авторитативный DNS — разные роли. Авторитативный сервер публикует данные для зон, которые он обслуживает; рекурсивный резолвер выполняет запросы для клиентов. Резолвер, открытый для произвольных внешних клиентов, может стать отражателем, не имея никаких отношений с целью [4][10]. RFC 5358 уже рекомендовал ограничивать рекурсивное обслуживание, а BCP 38 и BCP 84 описывали проверку исходных адресов на границах сетей доступа, клиентских и многосетевых сетей [4][5][6]. Первое средство ограничивает отражение; второе блокирует поддельные пакеты.

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

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

Ограниченная запись события

Граница события — кампания 18–27 марта против Spamhaus, а затем частей поверхности провайдеров и пиринга CLOUDFLARE. CLOUDFLARE сообщила, что Spamhaus обратился за смягчением атаки после того, как атака насытила его канал и сделала веб-сайт недоступным. Сообщалось о первоначальной скорости около 10 Гбит/с, затем о волнах около 75–90 Гбит/с, в основном отражённых через открытые рекурсивные резолверы [1]. В последующей публикации описывалась эскалация до примерно 120 Гбит/с и перенос трафика с клиентского адреса на каналы провайдеров и точки обмена [2].

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

Механизм был конкретным. CLOUDFLARE сообщила, что запросы использовали поддельные исходные адреса, обращались к открытым рекурсивным резолверам за данными ripe.net и вызывали увеличенные ответы, сходящиеся на жертве. CLOUDFLARE сообщила о более чем 30 000 участвовавших резолверов и оценила усиление примерно в сто раз для наблюдаемой формы запроса и ответа [1][2]. Каждый резолвер или исходная сеть мог вносить локально скромный трафик, в то время как тысячи таких путей складывались в поток, насыщающий каналы.

Фраза «почти сломал интернет» была современной публицистической рамкой, включая собственный заголовок CLOUDFLARE, а не доказанным выводом о глобальном сбое [2]. Ни одна из приведённых записей не устанавливает конкретный сбой всей точки обмена, универсальное нарушение или юридически установленную личность атакующего для этого ограниченного описания. Эти утверждения остаются за пределами доказательств.

Что и где измерялось

Каждая цифра скорости в заголовке нуждается в указании наблюдателя и контекста измерения. Цифры около 10 Гбит/с и 75–90 Гбит/с были сообщены CLOUDFLARE в её отчёте о смягчении атаки для клиента [1]. Движение к 120 Гбит/с и часто повторяемый пик 300 Гбит/с относятся к более позднему повествованию CLOUDFLARE со стороны провайдера [2]. Поэтому цифра 300 Гбит/с — это заявление, основанное на наблюдениях провайдера, а не измерение публичного интернета в целом. Ни одну из этих цифр нельзя рассматривать как универсальный пик без синхронизированных, независимо документированных наблюдений в соответствующих сетях.

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

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

Более поздние руководства уточняют эту модель доказательств. DNS Cookies, сокращённое поведение ответов на запросы ANY и архитектура для крупных авторитативных сервисов дают современные точки сравнения [7][8][9]. Материалы RIPE и DNS-OARC также поддерживают инвентаризацию, закрытие рекурсии, контроль ответов, разделение ролей и операционную проверку [14][16][17][19]. Эти источники не доказывают, что каждое более позднее средство было доступно или применимо в том же виде во время атаки.

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

Исполняемый путь отражения

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

Посредником был открытый рекурсивный резолвер. Он принимал запросы с произвольных интернет-адресов, получал запрошенные данные и возвращал результат заявленному клиенту. CLOUDFLARE сообщила о запросах дляripe.net, более чем 30 000 участвовавших резолверов и усилении примерно в сто раз для наблюдаемой формы запроса и ответа [1]. Эти цифры — наблюдение CLOUDFLARE, а не перепись всех резолверов или пакетов. Повторение создавало операционный эффект: множество небольших поддельных запросов вызывало увеличенные ответы, сходящиеся на одном адресе назначения.

Таким адресом мог быть жертва, точка anycast-смягчения или канал на стороне провайдера, несущий защищённый сервис. Давление, следовательно, могло исчерпать пропускную способность сети до достижения приложения. CLOUDFLARE описывает трафик против Spamhaus, а затем трафик, затрагивающий её путь смягчения и провайдера [1][2]. Отражённый пакет на этом пути доказывает, что ответ прибыл; он не раскрывает исходный бот, полное распределение исходных автономных систем или универсальный пик интернета.

Рекурсивный и авторитативный DNS различаются. Авторитативный сервер публикует ответы для зон, которые он обслуживает. Рекурсивный резолвер принимает вопрос клиента, при необходимости следует по иерархии DNS, кэширует результаты и возвращает разрешённый ответ [10]. Одна машина может выполнять обе функции, но роли остаются разделимыми. Этот путь использовал внешне доступную рекурсию, а не «DNS-серверы» как один класс. Авторитативные сервисы могут допускать другие схемы усиления, но это не делает каждого авторитативного оператора оператором открытого резолвера.

Рекурсия — средство контроля оператора

RFC 5358 описал эту проблему отражателя в 2008 году, за пять лет до кампании против Spamhaus. Его центральное операционное распределение ответственности прямое: операторы рекурсивных серверов имён должны предоставлять рекурсию только предназначенным клиентам, а сетевые операторы должны не допускать выхода пакетов с поддельными исходными адресами из своих сетей [4]. Закрытие рекурсии не означает отключение публичного авторитативного DNS. Это означает определение того, кто имеет право пользоваться рекурсивным сервисом, и соблюдение этой границы с помощью контроля доступа, политики интерфейсов или отдельно управляемого резолвера.

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

Соответствующие доказательства столь же конкретны. Оператор должен иметь возможность предоставить текущую инвентаризацию резолверов, внешне выполненные тесты рекурсии, конфигурацию с разрешёнными диапазонами клиентов, разделение ролей там, где оно используется, и журналы или измерения, показывающие, что устранение пережило перезапуск и отказоустойчивый переход. Ограничения скорости ответов могут снизить вред, а более поздние методы могут затруднить подделку некоторых обменов, но они дополняют, а не заменяют границу рекурсии [7][19]. Важна дата RFC 5358 до атаки: ограничение рекурсии — не средство, придуманное задним числом под инцидент.

У ответственности есть и пределы. Резолвер обычно видит исходный адрес, представленный в UDP-пакете; он не контролирует удалённую сеть, в которой этот адрес был подделан. Наоборот, провайдер доступа, допускающий подделку, не администрирует списки доступа рекурсии удалённого резолвера. Если одна организация управляет обеими системами, к ней относятся обе обязанности, но это два разных средства с разными доказательствами. Подотчётность следует за компонентом, который оператор мог настроить и проверить.

Подделка адресов на границе сети

BCP 38, опубликованный как RFC 2827, возлагает практическое средство контроля на сеть, ближайшую к источнику: фильтровать трафик, приходящий от клиентской или внутренней сети, если его заявленный источник не является легитимно достижимым с этого интерфейса [5]. Хотя с точки зрения провайдера это называется фильтрацией входящего трафика, её результат — защита исходящего трафика для более широкого интернета. Клиент или предприятие контролирует, что излучают его хосты; провайдер доступа контролирует проверку на границе, обращённой к клиенту.

Именно там назначенные префиксы и отношения интерфейсов дают наиболее сильное основание для отклонения поддельного источника.

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

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

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

Сохраняющиеся пробелы внедрения делают такую проверку более полезной, чем общее заявление о соответствии [15].

RFC 5358 и BCP 38/84 рассматривают противоположные концы одного пути. Ограниченная рекурсия устраняет отражатель, доступный произвольным запрашивающим; проверка исходных адресов останавливает поддельный запрос до того, как он достигнет любого отражателя [4][5][6]. Ни одно из средств не переносит обязанность другого оператора. Усиленный ответ становится возможным только тогда, когда эти независимые сбои совпадают, поэтому путь пакета также является картой подотчётности.

Агрегирование превращает локальную халатность в сетевой внешний эффект

Открытый рекурсивный резолвер может выглядеть как небольшая локальная ошибка: один сервер отвечает клиентам, которых он не должен был обслуживать, а сеть доступа пропускает пакеты с исходными адресами, которые она никогда не назначала. Ни одно из действий не кажется значимым при локально видимой скорости. Отражение меняет единицу учёта. Поддельный запрос называет жертву своим источником, резолвер отправляет ответ этой жертве, а ответ больше запроса умножает трафик. RFC 5358 описал эту схему и рекомендовал ограничивать рекурсию ещё до атаки 2013 года [4].

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

На каждом переходе программное обеспечение и конфигурация, а не абстрактная принадлежность, определяют, продолжается ли цепочка.

Агрегирование происходит потому, что каждый участник вносит пропускную способность, не видя кампанию. Один резолвер, излучающий несколько мегабит в секунду, может оставаться ниже порога тревоги. Одна широкополосная или хостинговая сеть может нести разреженные поддельные запросы от многих клиентов. Однако десятки тысяч резолверов могут отвечать параллельно. CLOUDFLARE сообщила о более чем 30 000 участвовавших резолверов в кампании против Spamhaus и оценила усиление примерно в сто раз для наблюдаемой схемы запроса и ответа [1].

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

Это сетевой внешний эффект: сторона, оставляющая рекурсию открытой или допускающая подделку, получает удобство или избегает затрат на устранение, а удалённый сервис, провайдер смягчения, оператор связи или канал на точке обмена поглощает перегрузку. Вред может мигрировать. Отчёты CLOUDFLARE перешли от трафика, направленного на Spamhaus, к более поздним волнам, направленным на поверхности провайдеров и пиринга, где ограниченным ресурсом больше не было только клиентское соединение [1][2]. Anycast может распределять нагрузку по площадкам, а ёмкость пиринга и транзита определяет, где концентрация превращается в отказ.

Пик на стороне провайдера описывает его точку измерения, а не состояние всего интернета [2].

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

BCP 38 и BCP 84 помещают эту обязанность на границы доступа, клиентские и многосетевые границы [5][6].

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

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

Более поздние механизмы, такие как DNS Cookies и минимизированные ответы ANY, полезны для сравнения, но не доказывают, что идентичные средства были доступны или развёрнуты в марте 2013 года [7][8]. Тесты должны разделять рекурсивную и авторитативную роли.

Провайдер доступа должен хранить политику исходных префиксов для каждого интерфейса, покрытие развёртывания, реестры исключений, счётчики неудачной проверки и результаты контролируемых тестов подделки. Многосетевому клиенту или транзитному оператору нужны доказательства того, что фильтрация отражает реально возможные обратные пути, а не хрупкое предположение об одном восходящем канале — проблему, рассмотренную в BCP 84 [6]. Уведомления об abuse должны указывать клиента, интерфейс, автономную систему, временное окно, принятые меры и повторный тест.

Формулировка «BCP 38 включён» слаба, если оператор не показывает, какие границы проверены, а какие остаются исключёнными. Сохраняющаяся операционная сложность проверки исходных адресов усиливает потребность в измеряемом покрытии, а не в декларациях о политике [15].

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

Материалы RIPE и DNS-OARC связывают наблюдаемую нагрузку усиления с контрмерами и измерениями, а не рассматривают общую инфраструктуру как одну недифференцированную жертву [16][17].

Провайдер смягчения должен хранить отпечатки атак, методологию выборки, точки измерения, правила дедупликации, нагрузку на anycast-площадки, решения по очистке, изменения маршрутов и запросы к вышестоящим сетям. Публичные заявления о скоростях требуют временных меток, точек наблюдения и различий между полученным, отброшенным и доставленным клиенту трафиком. Сообщённая цифра 300 Гбит/с принадлежит повествованию CLOUDFLARE со стороны провайдера и не должна становиться глобально измеренным сбоем [2]. Пост-инцидентные доказательства должны показывать, сохранил ли механизм смягчения веб-сайт в некоторых точках или защитил путь провайдера шире.

Более поздние руководства для крупных авторитативных сервисов могут помогать при проверке устойчивости, не переписывая возможности 2013 года [9].

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

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

Anycast, транзит и пиринг изменили домен отказа

Когда CLOUDFLARE начала смягчать атаку, защита вышла за пределы одного сервера. Первоначальный поток насытил канал Spamhaus и сделал его веб-сайт недоступным. CLOUDFLARE описала трафик около 10 Гбит/с, затем волны около 75–90 Гбит/с, при этом открытые рекурсивные резолверы отражали DNS-ответы на защищаемый адрес [1]. Anycast изменил то, куда трафик мог приходить и где поглощаться.

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

CLOUDFLARE сообщила, что кампания позже вышла за пределы исходного адреса назначения Spamhaus, достигнув примерно 120 Гбит/с и целясь в провайдеров и каналы на пути к её сети [2]. Её отчёт также связывал инцидент с пиком около 300 Гбит/с [2]. Эти цифры описывают наблюдения, сделанные в пределах видимости провайдера смягчения. Они не являются универсальным измерителем всего интернет-трафика и не устанавливают, что каждая сеть на каждом пути испытывала ту же нагрузку.

Поэтому выражение «на стороне точки обмена» требует осторожного толкования. Трафик атаки может достигать площадки смягчения через частный пиринг, порт точки обмена, транзитный канал или комбинацию, выбранную BGP. Насыщение на одном таком пути может затронуть использующие его сети, не доказывая, что точка обмена в целом отказала. Зафиксированная запись поддерживает эскалацию в сторону поверхностей провайдеров и пиринга [2]; она не поддерживает выдумывание сбоя всей точки обмена. Большой поток, наблюдаемый вблизи точки обмена, также не определяет, какой участник, порт, маршрут или физический канал был связывающим ограничением.

Точная атрибуция требует доказательств, привязанных к конкретному пути.

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

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

Ограничения измерений столь же важны. CLOUDFLARE сообщила, что видела более 30 000 участвовавших резолверов, и описала схему запроса и ответа с усилением примерно в сто раз [1]. Это устанавливает масштаб в пределах её наблюдения, но не полную инвентаризацию исходных автономных систем или знание операторов. Полное распределение исходных автономных систем, объём сопутствующей перегрузки и причинная доля каждого пути остаются неизвестными. Современный язык о том, что атака «почти сломала интернет», следует рассматривать как публицистическую рамку, привязанную к повествованию провайдера, а не как доказанный вывод о глобальном сбое [2].

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

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

Доступность веб-сайта не означала доступность DNSBL

Первый видимый сбой сервиса был конкретным: трафик насытил канал Spamhaus, и его веб-сайт стал недоступен [1]. Более поздние фазы затронули среду CLOUDFLARE на стороне провайдера и вспомогательные пути [2]. Spamhaus также описал атаки на хосты, DNS-партнёров и вспомогательные сервисы, заявив, что его распределённые антиспам-данные оставались доступными [3]. Эти факты входят в одну историю инцидента, но они не описывают один неделимый сервис.

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

Это различие также ограничивает утверждения о downstream-фильтрации электронной почты. Имеющиеся доказательства не показывают, что глобальная фильтрация остановилась. Заявление Spamhaus поддерживает более узкое утверждение о том, что его распределённый сервис данных продолжал работать во время атак на другие части инфраструктуры [3]. Оно не доказывает, что каждый пользователь, резолвер, регион или сетевой путь имел непрерывный доступ. Локальные сбои и деградация на конкретных путях не могут быть ни выведены, ни исключены на основании недоступности веб-сайта.

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

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

Стандарты до и после 2013 года

Кампания 2013 года не выявила проблему контроля, которую органы стандартизации ещё не определили. RFC 5358, опубликованный в 2008 году, описывает DNS-усиление с использованием поддельных адресов жертв и публично доступных рекурсивных серверов. Он рекомендует ограничивать рекурсию предназначенными клиентами и отмечает, что ограничение сервисов, генерирующих ответы, устраняет отражение в одной точке, а проверка исходных адресов — подделку в другой [4]. Это различие является правильным современным эталоном для Spamhaus: оператор резолвера и сеть, несущая поддельный запрос, контролировали разные звенья одной исполняемой цепочки.

RFC 2827, BCP 38, с 2000 года призывал к фильтрации входящего трафика на гранях, обращённых к клиенту, чтобы трафик с исходными адресами вне легитимного клиентского префикса не распространялся [5]. RFC 3704 расширил операционную модель для многосетевых сетей, обсуждая строгие и практически возможные проверки обратного пути и другие методы фильтрации там, где асимметричная маршрутизация усложняет простые правила [6]. Вместе эти тексты показывают, что к марту 2013 года две соответствующие обязанности были задокументированы: не предлагать неограниченную рекурсию и не экспортировать явно поддельный трафик.

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

Более поздние материалы должны уточнять сегодняшнюю проверку, а не проецироваться назад, как если бы они были базовой линией 2013 года. DNS Cookies могут добавить устойчивость к подделке там, где обе конечные точки их поддерживают [7]; минимизация ответов ANY может сократить одну исторически полезную форму усиления [8]; более поздние руководства по архитектуре авторитативных сервисов касаются устойчивости и операционного проектирования в масштабе [9]. Ничто из этого не заменяет закрытие непреднамеренной рекурсии или фильтрацию поддельных источников.

Операционные руководства RIPE, материалы MANRS, презентации DNS-OARC и исследования измерений аналогично дают сравнения, методы тестирования и данные о сохраняющейся открытости [14][15][16][17][18][19]. Они могут показать, как сегодня выглядит зрелое обеспечение. Они не могут установить, что каждая более поздняя методика была доступна, равномерно применима или фактически развёрнута во время события 18–27 марта. Исторический вывод должен оставаться более узким: основные категории средств контроля уже были публичными, а их внедрение и проверка были фрагментированы.

Программа проверки для операторов

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

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

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

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

Телеметрия должна связывать эти две плоскости контроля. Журналы резолверов или выборочные записи потоков должны показывать частоту нежелательных запросов, запрашиваемые имена и типы, размеры ответов, усечение и действия по ограничению скорости без хранения излишних пользовательских данных. Граничная телеметрия должна показывать отбрасывание поддельных пакетов по интерфейсам и клиентским политикам, а записи маршрутов и ёмкости — где входил отражённый трафик. Операторы должны сохранять достаточно деталей, чтобы ответить: был ли резолвер доступен? Мог ли исходный адрес запроса быть подделан? Какой ответ он сгенерировал? Какой канал его перенёс?

Какое средство изменилось? Уведомление об abuse на уровне автономной системы должно включать интервалы UTC, адрес назначения и видимый источник, протокол, репрезентативные пакетные доказательства, метод измерения и контактируемый идентификатор дела — а не просто список IP-адресов.

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

Более поздние механизмы можно включать как эшелонированную защиту: тестируйте согласование DNS Cookie, сокращённое поведение ANY, разделение авторитативной и рекурсивной ролей и отказоустойчивость крупных сервисов в соответствии с их фактическими условиями развёртывания [7][8][9]. Используйте более поздние материалы RIPE, MANRS и DNS-OARC для уточнения сегодняшнего покрытия, особенно когда открытость сохраняется через организационные границы [14][15][17][19].

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

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

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

Ежеквартальную выборку следует дополнять тестами после слияний, перепроектирования сети, обновлений резолверов, нового транзита или крупных изменений маршрутной политики. Исследования и современные измерения могут помогать при выборке и ожидаемых режимах отказа [18][19], но оператор проходит проверку только предъявляя актуальные, привязанные к конкретному пути доказательства из собственной работающей системы.

Границы публичной записи

Публичная запись уже легенды вокруг кампании 18–27 марта 2013 года. Современные событию публикации CLOUDFLARE описывают первоначальную атаку, сделавшую веб-сайт Spamhaus недоступным, трафик около 10 Гбит/с, последующие волны около 75–90 Гбит/с и эскалацию до примерно 120 Гбит/с по мере перемещения давления с клиентского адреса на инфраструктуру, обращённую к провайдерам и точкам обмена.[1][2] Широко повторяемая цифра 300 Гбит/с относится к наблюдению CLOUDFLARE со стороны провайдера. Она не является универсальным измерением трафика, проходящего через публичный интернет.

Точно так же «почти сломал интернет» было публицистической рамкой, а не доказанным выводом о глобальном сбое.[2]

Механизм установлен лучше, чем общий масштаб. Атакующие отправляли DNS-запросы с поддельными адресами жертв на публично доступные рекурсивные резолверы. Эти резолверы возвращали ответы, значительно превышающие запросы, на поддельные адреса, превращая небольшие исходящие пакеты в совокупный входящий поток. CLOUDFLARE сообщила о запросах, связанных с данными ripe.net, более чем 30 000 участвовавших резолверов и усилении примерно в сто раз для наблюдаемой формы запроса и ответа.[1][2] Это атрибутированные наблюдения, а не полная перепись.

Рекурсивный сервис также следует отличать от авторитативного DNS: операционный дефект заключался в неограниченной рекурсии в сочетании с подделываемым трафиком, а не в самом существовании DNS-серверов.[4][10]

Затронутые сервисы требуют аналогичной точности. Веб-сайт Spamhaus и вспомогательные пути провайдеров были целями, но его распределённые данные блок-листа были отдельным сервисом и, по сообщениям, оставались доступными.[3] Трафик, направленный на провайдеров смягчения, вышестоящие сети или каналы на точках обмена, мог создавать издержки для сторон, не имевших спора со Spamhaus. Однако зафиксированная запись не позволяет приписывать конкретный сбой конкретной точке обмена и не измеряет всю перегрузку, испытанную несвязанными сетями.[2][16][18]

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

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

Проверка подотчётности на уровне реальности — центральный элемент: этот инцидент понятен только как работающая инфраструктура. Уберите открытую рекурсию, достижимость поддельных исходных адресов, усиление ответов, исполнение anycast, пути пиринга и транзита или непрерывность сервиса — и тезис о подотчётности исчезает. Легитимность здесь не вытекает из институционального статуса, риторики сообщества или морального согласия с блок-листами Spamhaus. Она вытекает из того, контролировали ли операторы реальные поверхности отказа, вели ли точные операционные записи и устранили ли то, что их системы фактически допускали.

Первый тест — возможность. Операторы резолверов могут ограничивать рекурсивное обслуживание предназначенными клиентами, разделять рекурсивные и авторитативные роли, инвентаризировать открытость и ограничивать поведение при злоупотреблении ответами. RFC 5358 описал риск отражателя и рекомендовал ограничивать рекурсию за годы до кампании.[4] Сети доступа могут не допускать выхода пакетов с неправдоподобными исходными адресами.

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

Второй тест — доказательства. Надёжный оператор резолвера должен уметь предъявить датированные сканирования открытости, конфигурацию контроля доступа, записи запросов и ограничений скорости, обработку заявок об abuse и проверку после устранения. Оператор доступа или транзита должен уметь показать политику проверки исходных адресов, тесты на границе клиента, исключения, записи уведомлений и проверку после сбоя. Сохраняющаяся сложность внедрения проверки источника делает такое доказательство более важным, а не менее.[15] Доказательства превращают общее обещание «лучших практик» в проверяемое утверждение о работающем коде.

CLOUDFLARE контролировала распределение anycast, решения по очистке, изменения маршрутов, решения о ёмкости, координацию с пирами и транзитными провайдерами, а также точность своих публичных измерений.[1][2] Anycast мог распределять нагрузку, но мог и переносить границу отказа на каналы или площадки с другим запасом. Пиры, точки обмена и вышестоящие сети контролировали координацию и реакцию на перегрузку; им, однако, не следует приписывать объём атаки или вину без доказательств, привязанных к конкретному пути.

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

Третий тест — внешний эффект. Один резолвер может излучать мало трафика, а одна сеть доступа — пропускать лишь тонкий поток поддельных запросов. Тысячи по отдельности запущенных средств контроля тем не менее могут объединиться в поток, насыщающий каналы. Локальная конфигурация, следовательно, создаёт издержки вне собственной сети оператора. Уведомления об abuse на уровне автономных систем, инвентаризации открытых резолверов, тесты подделки, телеметрия ограничения скорости, журналы координации транзита, записи изменений маршрутов и пост-инцидентная проверка дают практическую цепочку от наблюдаемого поведения к устранению.[16][17][19]

Более поздние стандарты уточняют эту модель доказательств, не переписывая 2013 год. DNS Cookies могут помогать сопротивляться подделке в поддерживаемых обменах; минимальные ответы ANY сокращают одну привлекательную форму ответа; более поздние руководства по авторитативным сервисам касаются устойчивой крупномасштабной архитектуры.[7][8][9] Это точки сравнения, а не доказательство того, что каждое более позднее средство существовало в идентичной, применимой форме во время кампании. Справедливый вопрос не в том, предвидел ли оператор 2013 года каждый будущий RFC.

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

Заключение

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

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

DDoS-атака на Spamhaus в 2013 году: открытая DNS-рекурсия как тест сетевой подотчётности