Перехват публичного DNS в Турции (2014): маршрутизация и подотчёт

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

С 29 марта по 7 апреля 2014 года данные Google и RIPE Atlas показали, что трафик, адресованный публичным DNS-резолверам, мог достигать отвечающих систем внутри турецких сетей, а не ожидаемых внешних сервисов. Наблюдения подтверждают перехват в измеренных точках, но не одинаковую общенациональную конфигурацию.
Подотчётность следует за механизмами, определяющими путь и ответ: объявление и установка маршрута, пересылка, идентификация резолвера, целостность DNS-ответа, независимые измерения и верифицированное восстановление. Реестровые записи, DNSSEC, RPKI и шифрованный DNS решают лишь часть этой цепочки.

Знакомый адрес — незнакомый сервис

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

Это различие стало операционно заметным в турецких сетях в период с 29 марта по 7 апреля 2014 года. Измерения показали, что трафик, адресованный IP-адресам публичных резолверов, достигает отвечающих систем внутри турецкой инфраструктуры, а не ожидаемых внешних сервисов. Google заявила, что подтвердила достоверные сообщения о перехвате её публичного DNS-сервиса большинством турецких интернет-провайдеров. Измерения RIPE Atlas предоставили независимые наблюдения: у некоторых зондов в Турции наблюдались резкие изменения задержек и ответы, связанные с турецкой инфраструктурой. Другие зонды такого поведения не показали.

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

Публичные данные не позволяют свести всё к единому простому механизму. В отчётах BGPMon и Internet Society описывались весьма специфичные объявления BGP, включая объявление /32 для адреса резолвера Google. В материалах, представленных на RIPE 68, также обсуждалась маршрутизация как средство перехвата. Реконструкция Стефана Борцмейера добавила важное уточнение: looking glass Turk Telekom не показывал перенаправление как обычный BGP-маршрут с ожидаемым видимым путём, что позволяет предположить, что, по крайней мере, часть эффекта могла быть вызвана локальным статическим или внутренним маршрутом.

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

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

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

Ограниченное событие: с 29 марта по 7 апреля

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

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

Заявление также не предоставляло полные внутренние журналы турецких операторов и не идентифицировало лицо, санкционировавшее каждую конфигурацию.

RIPE Atlas предоставил вторые часы, основанные на измерениях, а не на корпоративном утверждении. Зонды в Турции ранее достигали anycast-резолвера Google с одной картиной задержек. Во время инцидента некоторые зафиксировали внезапное снижение до менее десяти миллисекунд. Резолвер, который, по-видимому, достигался так быстро из этих сетей доступа, не соответствовал предыдущему пути к ожидаемому экземпляру Google и согласовывался с гораздо более близкой отвечающей системой. DNS-тесты также возвращали адрес, связанный с инфраструктурой Turk Telekom, для некоторых зондов.

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

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

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

Что подтвердила Google — и что осталось за пределами её поля зрения

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

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

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

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

Что измерил RIPE Atlas

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

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

Сочетание было существенно сильнее, чем каждое наблюдение по отдельности.

Возвращаемые DNS-данные были ещё одним сигналом. В отчёте RIPE сообщалось об ответах, указывающих на инфраструктуру Turk Telekom, для некоторых тестов. Эти данные касаются информации, выдаваемой отвечающим резолвером. Сами по себе они не показывают, как запрос туда попал. Локальный политический маршрут, статический маршрут хоста, внутренний протокол маршрутизации, более специфичное объявление BGP или некоторая система перенаправления пакетов — все могут изменить принимающий сервис, оставляя разные следы в записях плоскости управления. Ответ помогает идентифицировать, что произошла подмена сервиса; это не полная трассировка маршрута.

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

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

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

Семь фактов, которые нельзя сводить к «перехвату DNS»

Фраза «перехват DNS» удобна, но она может скрыть цепочку контроля. Данные 2014 года становятся яснее, если разделить их на семь отдельных фактов.

Первый — этообъявление маршрута. В BGP сеть объявляет достижимость для IP-префикса с атрибутами источника и пути. В отчётах BGPMon и Internet Society описывались весьма специфичные объявления для публичных DNS-адресов, включая /32 для адреса резолвера Google. Это свидетельство о сообщении плоскости управления, как о нём сообщили эти наблюдатели. Это не автоматически доказательство того, что каждая сеть приняла объявление или что одно и то же объявление было видно глобально.

Второй — этоустановленный маршрут. Маршрутизатор оценивает изученные маршруты и локальную политику, затем выбирает записи для своего состояния маршрутизации и пересылки. Маршрут может быть установлен из-за BGP, внутреннего протокола маршрутизации, маршрутизации на основе политик, статической записи или другого локального механизма. Данные looking glass Борцмейера важны на этом уровне: ожидаемое обычное представление BGP отсутствовало в рассмотренном представлении, что подтверждает возможность локального или статического перенаправления по крайней мере для части трафика. Установленный маршрут может управлять пакетами, не появляясь как новое событие глобального происхождения.

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

Четвёртый — этоидентичность резолвера. Система, принимающая UDP- или TCP-трафик на порт 53, может представлять себя как рекурсивный резолвер и отвечать на запросы, но владение трафиком для адреса не является доказательством того, что это сервис, ожидаемый пользователем. Обычный DNS не предоставлял криптографической привязки канала между открытым запросом к IP-адресу и операционной идентичностью Google. Anycast добавляет законную множественность сервису, но несанкционированный локальный получатель не становится законным только потому, что адрес является anycast-адресом.

Пятый — этоDNS-ответ. Подставной резолвер может вернуть правильный ответ, поддельный ответ, ошибку, отсутствие ответа или разные ответы для разных имён. Наблюдение RIPE о том, что политика для запросов, связанных с Twitter, изменилась до того, как исчез неожиданный резолвер, демонстрирует, почему ответ и идентичность резолвера должны тестироваться раздельно. Правильный ответ от неверного сервиса не доказывает восстановления предполагаемого пути. Ложный ответ доказывает проблему с данными для этого запроса, а не изменение каждого запроса.

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

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

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

Сообщения о /32 и данные о локальных маршрутах

Префикс IPv4 /32 идентифицирует один адрес. Объявление такого высокоспецифичного маршрута может быть эффективным способом привлечения трафика там, где сети его принимают, поскольку совпадение по самому длинному префиксу обычно предпочитает наиболее специфичный установленный маршрут. Поэтому описания BGPMon и Internet Society предлагают правдоподобный механизм целевого перехвата адреса резолвера без отведения более крупного окружающего префикса. Их отчёты заслуживают места в реконструкции и не должны размываться до расплывчатого утверждения, что «была задействована маршрутизация».

Их также не следует расширять за пределы того, что подтверждается записью. Объявление, наблюдаемое системой мониторинга, имеет масштаб распространения, определяемый политикой экспорта, импорта и фильтрации. Некоторые сети отклоняют префиксы длиннее обычных операционных пределов; другие могут принимать или сохранять их в ограниченных контекстах. Существование зарегистрированного /32 не доказывает, что оно достигло каждого турецкого маршрутизатора доступа, что каждый маршрутизатор выбрал его или что оно вызвало каждый результат RIPE Atlas.

Данные Борцмейера указывают на другой, потенциально дополняющий путь. В рассмотренном им представлении looking glass Turkish Telecom перенаправление не выглядело как обычный BGP-маршрут с обычным путём AS. Его реконструкция предполагала, что локальный статический маршрут или другой маршрут, внутренний для оператора, мог бы объяснить по крайней мере часть наблюдаемого поведения. Такой маршрут мог бы направлять абонентский трафик на близлежащий резолвер, оставаясь невидимым для внешних сборщиков. Он также мог бы сосуществовать с объявлениями BGP, видимыми в других местах.

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

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

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

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

Anycast: стабильный адрес, множество легитимных экземпляров

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

Легитимный anycast не стирает идентичность сервиса. Несколько экземпляров управляются как часть одного и того же ожидаемого сервиса, под авторизованным контролем маршрутизации и эксплуатации. Система внутри несвязанной сети доступа не становится резолвером Google лишь потому, что получает пакеты, адресованные 8.8.8.8. Различие заключается в авторизованной эксплуатации, данных маршрутизации, поведении сервиса и, где доступно, аутентифицированном транспорте, а не в визуальной знакомости адреса.

Anycast также делает недостаточными упрощённые тесты задержки. Меньшая задержка может быть результатом легитимного нового сайта, изменения политики маршрутизации или несанкционированного близлежащего получателя. Во время турецкого инцидента падение задержки приобрело значение, потому что совпало с неожиданными DNS-ответами и подтверждением перехвата со стороны Google. В изоляции «быстрее, чем вчера» не установило бы правонарушения или даже неисправности.

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

DNS-ответы и ограниченная роль DNSSEC

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

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

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

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

Следовательно, подотчётная оценка DNS задаёт четыре отдельных вопроса: Получил ли предполагаемый резолвер запрос? Вернул ли отвечающий резолвер ожидаемые данные? Были ли подписанные данные валидированы корректно? Был ли сервис доступен? DNSSEC отвечает на третий вопрос и может влиять на второй. Он не может сам ответить на первый и не может гарантировать четвёртый.

Шифрованный DNS — более поздний контекст, а не ретроактивное требование

DNS over TLS и DNS over HTTPS были стандартизированы после событий 2014 года. Их следует использовать для объяснения средств контроля, доступных в настоящее время для идентичности резолвера и конфиденциальности, а не для переписывания исторического базиса или предположения, что турецкие сети не смогли развернуть стандарты, которые ещё не существовали в их более поздней форме.

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

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

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

Валидация источника маршрута и слепое пятно локальной маршрутизации

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

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

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

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

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

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

Фильтрация также требует точности. Общее правило о /32 не является адекватным уроком инцидента. Соответствующее требование состоит в том, чтобы оператор документировал, что он принимает, почему существуют исключения и как проверяется фактическая пересылка к критическому пункту назначения. Фильтрация может снизить риск, оставляя локальную конфигурацию и подмену сервиса непротестированными.

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

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

Ответственность следует за практическим контролем

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

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

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

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

Измерительные организации и сетевые исследователиконтролировали независимые зонды, методы сбора, временные метки, анализ и публикацию ограничений. RIPE Atlas мог показать, что поведение пути и ответа изменилось в определённых точках наблюдения. Мониторинг BGP мог записывать объявления, видимые его сборщикам. Анализ looking glass мог тестировать то, что оператор показывал с выбранных маршрутизаторов. Каждая система имела границу видимости, и ответственная отчётность требовала сохранения этой границы привязанной к выводу.

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

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

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

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

Тест на восстановление и повторяемость с сохранением доказательств

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

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

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

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

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

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

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

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

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

Неизвестные, правовые ограничения и дисциплина атрибуции

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

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

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

Атрибуция одинаково важна и для позитивных утверждений. Заявление Google о «большинстве турецких интернет-провайдеров» принадлежит Google. Описание /32 принадлежит отчётности BGPMon и Internet Society. Наблюдения о задержке, ответах, вариациях зондов и восстановлении принадлежат RIPE Atlas. Квалификация локального/статического маршрута принадлежит реконструкции Борцмейера. Сохранение этих ярлыков не позволяет вторичному отчёту приобрести больше уверенности, чем его основные доказательства.

Маршрутизация резолверов как проверка подотчётности

Перехват публичного DNS в Турции в 2014 году выявил разрыв между сконфигурированной идентичностью и операционной реальностью. Пользователь мог сохранить 8.8.8.8 в панели настроек, в то время как сеть доступа доставляла пакет другому рекурсивному резолверу. Ни одна запись не закрывает этот разрыв. Сообщения о /32 не доказывают универсальный механизм; looking glass может пропустить состояние пересылки; RIPE Atlas может показать подмену, но не внутреннего утверждающего; DNSSEC не аутентифицирует маршрут; валидация источника может пропустить локальный статический маршрут; а аутентифицированный шифрованный DNS не может гарантировать достижимость.

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

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

Перехват публичных DNS в Турции в 2014 году: маршрутизация резолверов как тест на подотчётность