Что происходит в IETF: устойчивость инфраструктуры и DNS

Андрей Робачевский

Андрей Робачевский

Давайте посмотрим, что происходит в IETF в области устойчивости интернет-инфраструктуры и DNS. Многие разработки IETF попадают в эту категорию, но здесь я хотел бы взглянуть на область марш­рутизации, а именно на ее защищенность, на область передачи данных, в частности, нежелательного трафика атак распределенного отказа в обслуживании (DDoS). После откровений Эдварда Сноудена область DNS обрела вторую жизнь в IETF. Основная работа направлена на решение задачи конфиден­циальности этой фундаментальной интернет-услуги.

Маршрутизация, ее устойчивость и защищенность

Сегодня в IETF можно увидеть много новых идей, особенно оперативного характера, направленных на повышение защищенности и устойчивости инфра­структуры Интернета, поэтому я хотел бы представить некоторые из них вам. Стандартный путь предложить решение проблемы в IETF и пригласить специалистов к его обсуждению – это направить т.н. интернет-проект, или Internet Draft (I-D). Но имейте в виду – I-D не обязательно указывает на одобрение IETF, тем более что он является стандартом, и может даже не привести к какой-либо работе в IETF.

Итак, давайте посмотрим на то, что происходит в краю BGP.

Могут ли сообщества быть вредными?

Да, если речь идет о «сообществах» BGP (BGP community). В недавней научной статье «BGP Communities: Even more Worms in the Routing Can» авторы демонстрируют, что сообщества BGP могут использоваться удаленными сторонами для влияния на маршрутизацию непреднамеренным способом. Частично из-за своей плохо определенной семантики сообщества BGP часто распространяются гораздо дальше, чем один маршрутный скачок, хотя их предполагаемая область действия обычно ограничена соседними автономными системами (Autonomous system, AS). Как следствие, уда­ленные злоумышленники могут использовать сообщества BGP для запуска удаленного терминирования (blackhole), управления трафиком и манипулирования маршрутами даже без захвата префиксов. См. рисунок 1.

*— Источник «BGP Communities: Even more Worms in the Routing Can»

Проблема плохо определенной семантики усугубляется тем фактом, что текущие реализации маршрутизаторов непоследовательно манипулируют сообществами BGP и особенно «общеизвестными» сообществами (well-known communities). В нескольких популярных реализаци­ях BGP есть различия в результатах команды set. Например, в ОС Junos производителя Juniper Networks команда «community set» удаляет все полученные сообщества, общеизвестные или нет, в то время как в IOS XR Cisco команда «set community» удаляет все получен­ные сообщества, кроме нескольких.

Проект I-D «Well-Known Community Policy Behavior» описывает текущие поведенческие различия, чтобы помочь операторам в создании согласованной политики мани­пуляции сообществами в среде гетерогенного оборудования от многих производителей, а также для предотвращения введения дальнейших расхождений в реализации.

В документе также содержится настоятельный призыв к операторам сетей никогда не полагаться на предпола­гаемую политику обработки BGP-community соседней автономной системы. Например, прежде чем объявлять префиксы с NO_EXPORT или любым другим сообществом соседней сети, оператор должен подтвердить с этим соседом, как это сообщество будет обрабатываться.

BGP Large Communities в среде IXP

Некоторые сети участвуют в нескольких точках обмена траффиком (IXP), чтобы улучшить связность и оптимизиро­вать маршрутизацию. Также распространено, что в случае использования сервера маршрутизации (Route Server, RS) для реализации многосторонних пиринговых отношений BGP Large Communities используются для инструктирования RS, как обрабатывать анонсы (например, не рекламировать определенную сеть) или предоставлять участникам допол­нительную информацию, например, статус проверки RPKI.

I-D «BGP Large Communities applications for IXP Route Servers» пытается документировать часто используемые BGP Large Communities, чтобы упростить согласованность их использования для множества IXP.

Создание более надежной политики маршрутизации с максимальным пределом числа анонсируемых префиксов

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

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

• Предел числа префиксов на входящие анонсы, до применения какой-либо политики (например, фильтрации). Эти ограничения особен­но полезны, чтобы помочь смягчить последствия утечки полной таблицы маршрутов и исчерпания памяти, когда реализация хранит отклоненные маршруты.
• Предел числа префиксов на входящие анонсы после применения политики импорта. Они полезны для пре­дотвращения истощения FIB и предотвращения случай­ного прерывания сеанса BGP из-за префиксов, которые в любом случае не приняты политикой.
• Предел числа префиксов на исходящие анонсы. Дости­жение этого предела инициирует прекращение сеанса BGP с соседней сетью. Такие ограничения полезны, чтобы помочь смягчить негативные последствия неправильной конфигурации локальной политики. Во многих случаях было бы более желательно разорвать сеанс BGP, чем на­воднять соседей неправильно настроенными анонсами.

Эти рекомендации взяты из более широкого подхода, представленного Job Snijders на конференции RIPE77 в прошлом году. См. рисунок 2.

**— Во многих случаях число префиксов, прошедших через фильтры, все же выше предела, что вызывает прекращение сеанса. В то же время, этот подход связан с большим риском исчерпания ресурсов маршрутизатора. Источник: https://ripe77.ripe.net/wp-content/up­loads/presentations/59-RIPE77_Snijders_Routing_Policy_Architecture.pdf

Использование RPKI в рамках проверенной операционной практики

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

В случае, когда существуют только прямые взаимоот­ношения с клиентами (то есть клиенты сети являются «тупиковыми сетями»), задача относительно проста – нужно собирать префиксы, законно анонсируемые этими сетями. Чаще всего это делается с помощью выборки из регистрату­ры маршрутизации IRR и сбора соответствующих объектов «route». Однако внедрение RPKI может оказаться более надежной альтернативой, предоставляя криптографически проверяемый объект ROA (Route Origin Authorization), который служит аналогичной цели.

Если вы являетесь более крупной сетью и некоторые из ваших клиентов также предоставляют услуги транзита для небольших сетей, задача будет более сложной. Как опреде­лить, кто является клиентами ваших клиентов и так далее?

Чтобы помочь с этой задачей, существует специальный объект IRR – «as-set». Этот объект представляет собой список номеров AS – ASN или других объектов «as-set», – которые определяют «клиентский конус» конкретной AS.

Однако когда речь идет о RPKI, у оператора нет такой возможности ввиду отсутствия необходимой информации,

предоставляемой объектом «as-set», что затрудняет создание значимых префиксных фильтров для собственного «клиентского конуса».

I-D «RPKI Autonomous Systems Cones: A Profile To Define Sets of Autonomous Systems Numbers To Facilitate BGP Filtering» пытается решить эту проблему путем введения нового объекта аттестации RPKI, называемого AS-Cone. AS-Cone – это объект с цифровой подписью, целью которого является предоставление операторам возможности определять набор непосредственных клиентов, или транзитных сетей со своими клиентами, облегчая построение префиксных фильтров для данной сети с использованием технологии RPKI.

Используя RPKI, AS-Cone также решает фундаментальную проблему с традиционными объектами «as-set»: одно и то же имя объекта «as-set» может существовать в нескольких регистратурах IRR, и проверяющая сторона не обязательно знает, какой «as-set» принадлежит какой сети, и какой следует использовать.

Улучшение проверки AS-PATH

Протокол маршрутизации BGP был разработан без механизмов для проверки атрибутов BGP. Возможность манипулировать одним из них – AS_PATH – создает одну из серьезных уязвимостей системы интернет-маршрутизации. BGPsec был разработан для решения проблемы корректно­сти AS_PATH.

Но, по словам авторов нового I-D «Verification of AS_PATH Using the Resource Certificate Public Key Infrastructure and Autonomous System Provider Authorization», даже оставляя в стороне сложность BGPsec, необходимость поддержки «небезопасного» BGP позволяет злоумышленнику провести атаку с понижением уровня защищенности, чтобы свести на нет всю работу подписыва­ния AS_PATH.

Авторы предлагают более прагматичный подход, который может помочь использовать преимущества RPKI без необходимости повсеместного развертывания BGPsec. Идея заключается в том, что любая AS может объявлять своих восходящих провайдеров и пиров – сети, которые могут распространять анонсы этой AS. Чем больше сетей это будет делать – тем больше будет шансов обнаружить неправильную конфигура­цию (вредоносную или нет).

В проекте определяется семантика объектов авторизации провайдеров автономных систем (Autonomous System Provider Authorization, ASPA), которые должны стать частью RPKI. ASPA – это объекты с цифровой подписью, которые связывают ASN провайдера с номером AS клиента и подписываются владельцем AS клиента. ASPA подтверждает, что владелец AS клиента (CAS) уполномочил конкретный AS провайдера (PAS) распро­странять анонсы клиента далее, например, анонсируя их восходящим поставщикам или пирам провайдера.

Смягчение DDoS-атак

Распределенные атаки отказа в обслуживании (DDoS-а­таки) – это постоянная и растущая угроза в Интернете. А поскольку DDoS-атаки быстро развиваются с точки зрения объема и сложности, требуется более эффективное сотрудничество между жертвами и сторонами, которые могут помочь в смягчении таких атак. Способность быстро и точно реагировать на начинающуюся атаку, передавая точную информацию поставщикам услуг по снижению риска, имеет решающее значение.

Решение этой проблемы – в этом состоит задача рабочей группы DOTS (DDoS Open Threat Signaling). Целью DOTS является разработка основанного на стандартах подхода для сигнализации в реальном времени связанных с DDoS телеметрии, а также запросов обработки угроз и данных между элементами, связанными с обнаружением, классификацией, отслежи­ванием и смягчением атак DDoS. Этот протокол должен поддерживать запросы на услуги по смягчению послед­ствий DDoS и обновления статуса через межведомственные административные границы.

Другим интересным случаем, приобретающим все большую важность, особенно с появлением потреби­тельских устройств Интернета вещей (IoT), является снижение DDoS-атак, исходящих из домашней сети. I-D «Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home» предлагает решение для этих случаев. Это расширение протокола сигнального канала DOTS позволит серверу DOTS инициировать безопасное соединение с клиентом DOTS, который в свою очередь сможет передать информацию о трафике атаки на сервер DOTS.

В типичном сценарии развертывания сервер DOTS является частью клиентского оконечного оборудования (CPE), а клиент DOTS находится в сети ISP. В этом случае сервер DOTS в домашней сети инициирует запрос в мирное время, а затем впоследствии клиент DOTS в среде ISP может инициировать запрос на смягчение, когда провайдер обнаруживает, что в домене сервера DOTS есть атака от скомпрометированного устройства. Впослед­ствии сервер DOTS будет использовать информа­цию о трафике DDoS-атаки для идентификации ском­прометированного устройства в своем домене, запускающего DDoS-атаку, может уведомить администратора сети и предпринять соответствующие действия по смягчению последствий (например, для помещения в карантин скомпрометированного устройства или блокиров­ки его трафика для атаки цели, пока запрос на смягчение не будет отозван).

Конфиденциальность в DNS и ее последствия

Будь то посещение веб-сайта, обмен почтовыми сообще­ниями или общение в социальной сети, для определения фактического нахождения ресурса, а именно его IP адреса, необходима система DNS. Эта система обеспечивает трансляцию имени ресурса (например, facebook.com) в его IP-адрес (например, 2a03:2880:f129:83:face:b00c::25de), необхо­димый для установления связи. Таким образом, транзакции DNS могут быть связаны с приложениями, которые мы используем, с сайтами, которые мы посещаем, а иногда даже с людьми, с которыми мы общаемся.

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

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

Вообще говоря, в DNS существует два типа взаимодей­ствий: а) между пользовательским компьютером (через системное приложение, называемое резолвером-заглуш­кой, stub resolver) и рекурсивным резолвером, и б) между рекурсивным резолвером, который обычно находится в сети сервис-провайдера пользователя и выполняет рекурсивные запросы DNS от имени пользователя, и авторитетным сервером, содержащим информацию, относящуюся к запросу. Во избежание перехвата DNS-транзакции должны быть зашифрованы и аутентифицированы, но масштаб двух типов взаимодействий (stub resolver с рекурсивным резолвером и рекурсивный резолвер с авторитетными серверами) сильно отличается.

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

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

IETF использует два основных подхода для повышения конфиденциальности транзакций DNS:

• минимизация имени запроса (Query Name Minimisation) для уменьшения количества (частных) данных, которые несет запрос, и
• шифрование транзакций между резолверами-заглушка­ми и рекурсивными резолверами, чтобы предотвратить прослушивание этих данных третьими лицами.

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

Минимизация информации

Минимизация QNAME – это экспериментальное предло­жение, документированное в RFC7816 «DNS Query Name Minimisation to Improve Privacy», которое направлено на минимизацию объема информации, отправляемой в запросах DNS. Вместо повторной отправки одного и того же DNS-запроса на каждый авторитетный сервер имен, минимизация QNAME требует, чтобы рекурсивный резолвер учитывал иерархию DNS, запрашивая необходимые данные (обычно – записи авторитетных серверов дочернего домена) только для име­ни соответствующего уровня, начиная с домена верхнего уровня, и увеличивая один уровень в глубину домена для каждого последующего запроса. Например, для трансляции имени www.example.ru резолвер обратится к корневому серверу с запросом для имени «ru», и так далее.

В области шифрования IETF фокусируется на двух основ­ных технологиях:

DNS через TLS (DoT)

RFC7858 «Specification for DNS over Transport Layer Security (TLS)» определяет, как установить связь с рекурсивным резолвером по защищенному соединению TLS. Однако этот подход также может быть применен для улучшения свойств конфиденци­альности транзакций между рекурсивными резолверами и официальными серверами.

Протокол DoT использует отдельный номер порта, порт TCP 853, а не существующий порт службы DNS (53). Рекурсивные резолверы могут быть аутентифицированы с помощью ключа SPKI (подробности см. в разделе 3.2 и разделе 4 RFC7858).

DNS через HTTPS (DoH)

RFC8484 «DNS Queries over HTTPS (DoH)» определяет, как отправлять и получать DNS-запросы по HTTPS. Настройка сервера выполняется отдельно, а соединение с резолвером защи­щено, как и любой другой HTTPS-трафик. DoH в основном нацелен на веб-браузеры и вряд ли сможет быть применен для улучшения свойств конфиденциальности транзакций между рекурсивными резолверами и авторитетными серве­рами имен. Вот где начинается некоторое противоречие.

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

DoH имеет и другие спорные моменты. Использование протокола HTTPS позволяет идеально интегрировать операции по трансляции имен в общую работу браузера. Кэширование данных, оптимизация запросов и т.п. – все эти подходы для качественного предоставления веб-контента могут быть также применены к DNS. Зачем использовать системные функции резолвера-заглушки, использующего, возможно, слабо производительную инфраструктуру, если можно осуществить трансляцию необходимых имен в том же HTTPS-потоке? Еще лучше, если провайдер контента, CDN, также поддерживает рекурсивный резолвер по протоколу DoH.

Дискомфорт вызывают два факта: во-первых, игнориру­ются системные настройки, традиционно находящиеся под контролем пользователя. Во-вторых, такой подход ведет к консолидации функции разрешения имен, когда всего несколько мощных рекурсивных резолверов обрабатываю подавляющую массу DNS-запросов пользователей. И хотя DNS-транзакции обретают сильную защиту конфи­денциальности от возможных попыток транзитных сетей манипулировать или просматривать эти данные, консолида­ция запросов в DoH-резолвере работает в противоположном направлении.

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

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