Безопасность и приватность DNS для конечного пользователя

Бенно Оверайндер

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

Повсеместное шифрование. Эта инициатива в техническом сообществе возникла в ответ на откровения Эдварда Сноудена о крупномасштабной слежке и мониторинге Интернета американскими спецслужбами. Отрезвляющий эффект от этой информации был таков, что массово начали разрабатываться и внедряться новые меры безопасности, такие как новый уровень шифрования для мобильных телефонов или службы защиты веб-трафика, такие как Let’s Encrypt.
Все эти усилия направлены на то, чтобы на пути от пользователя до сервиса не оставалось лазеек для прослушивания. А значит, аутентификация и шифрование должны применяться уже на краю сети, т.е. у конечного пользователя. И поскольку едва ли не все действия в Интернете начинаются с запроса доменного имени, DNS занимает центральное место в обеспечении такой безопасности.
Предстоящую задачу простой не назовешь, так как мы умудрились превратить край сети, где обитает конечный пользователь, в крайне сложную и запутанную конструкцию: тут вам и NAT поверх Carrier Grade NAT, и брандмауэры, и мешанина IPv4/IPv6 с механизмами перевода между ними, и сетевые приставки, которые переписывают пакеты полностью или просто теряют их… Но во всей этой каше перед нами стоит две задачи, касающихся DNS:

Обеспечить подлинность и целостность данных DNS.
Защитить обмен данными между пользователем и DNS от посторонних ушей.

Проверку подлинности данных DNS берет на себя DNSSEC. Протокол DANE (DNS-based Authentication of Named Entities) позволяет произвести аутентификацию сервиса по открытому ключу (его также можно использовать для настройки сеанса TLS). С этой точки зрения ключевым компонентом для достижения полной и сквозной безопасности и конфиденциальности становится тупиковый резолвер DNS.
Хотя в инфраструктуре DNS тупиковый резолвер (stub resolver) считается простым компонентом, он должен работать и обеспечивать сквозную безопасность в описанной выше переусложненной среде. На приведенной ниже диаграмме виден уровень сложности служб DNS по сравнению с уровнем сложности сквозной безопасности.
Тупиковые резолверы должны иметь дело с самыми сложными на сегодняшний момент функциями сквозной безопасности, но не стоит забывать, что некоторые резолверы DNS не пересылают данные в формате DNSSEC дальше, что создает еще одну проблему.
Рассмотрим поподробнее описанные осложнения и варианты их решения.
Проблемы DNSSEC для оконечных точек
Здесь имеется множество различных проблем с проверкой DNSSEC и аутентификацией DANE. Мы не ставим своей целью осветить в этом разделе все ситуации, а взамен сосредоточимся лишь на важнейших.
Обход блокировок DNSSEC
Обход блокировок DNSSEC (DNSSEC Roadblock Avoidance) касается проверки DNSSEC в оконечных точках, которая зачастую бывает крайне затруднена из-за применения домашних маршрутизаторов и модемов (бюджетного класса), а также и других сетевых приставок на пути от оконечной точки до сервиса. Для решения этой задачи разработан документ RFC8027 , описывающий ряд сложных механизмов обращения к рекурсивным резолверам выше по потоку.
В оконечной точке применение этих методов поможет определить возможности рекурсивных резолверов выше по потоку и, если ни одно из промежуточных решений не сработает, применить резервную стратегию – задействовать собственный валидирующий резолвер, который будет опрашивать ответственные серверы имен непосредственно.
NAT64/DNS64

В нынешний переходный период между IPv4 и IPv6 инфраструктура DNS должна работать в ситуации, когда оконечные точки, поддерживающие только IPv6, обращаются к сервисам, поддерживающим (только) IPv4. Скорее всего, в обозримом будущем эта ситуация не изменится, поэтому здесь тоже необходимо надежное и основательное решение.
Для сред, в которых поддерживается только IPv6, NAT64 выполняет преобразование доступа к адресному пространству IPv4, сопоставляя эти адреса с адресами IPv6 с конкретным префиксом, а DNS64 выдает синтезированные адреса IPv6. Обратите внимание, что “обычный” DNS выдал бы IPv4-адрес службы. Очевидно, такие синтезированные сообщения DNS не являются подлинными и не пройдут проверку DNSSEC.
Чтобы можно было использовать DNSSEC в средах NAT64/ DNS64, валидирующий тупиковый резолвер должен обнаружить, что находится в сети NAT64/DNS64, и выполнить синтез IPv6 самостоятельно, как описано в RFC7050. Таким образом, оконечная точка, не поддерживающая IPv4, сможет проверять ответы DNS – подлинные адреса IPv4 – с помощью DNSSEC.
С момента создания RFC7050 возникла еще одна неожиданная ситуация, в которой от тупикового резолвера требуются подобные возможности, а именно, если ваше устройство настроено на работу с обеспечивающими приватность рекурсивными резолверами, такими как Quad9, в мобильной или сотовой сети IPv6 без поддержки IPv4.
Поддержка точки доверия DNSSEC
Каждый раз, говоря о проверке DNSSEC, мы на самом деле говорим о проверке подписи, которой подписаны данные DNS. Проверка DNSSEC – это создание цепочки доверия, которая начинается с доверенного ключа DNSSEC и распространяется на ключ DNSSEC, которым подписывается ответ DNS.
Доверенный ключ DNSSEC, с которого начинается каждая проверка DNSSEC, называется точкой доверия (trust anchor) – как правило, это тот самый ключ, которым подписывается корневая зона (формально он называется ключом подписания корневых ключей – Root Key Signing Key).

Управление точкой доверия жизненно важно для правильности работы валидирующих (тупиковых) резолверов DNSSEC. Поэтому появился документ RFC5011), в котором предлагается отслеживать изменения точки доверия DNSSEC.
Разработчики этого документа исходили из того, что валидирующий резолвер – это непрерывно выполняемый процесс с правами системного администратора.
Проверка DANE выполняется на уровне приложения и использует тупиковый резолвер с пользовательскими привилегиями, как видно на диаграмме выше. Здесь нет никаких гарантий того, когда и в течение какого времени будет выполняться приложение тупикового резолвера, и полагаться на RFC5011 для отслеживания изменений точки доверия нельзя. Однако нет пока и стандартов, описывающих, как приложения должны поддерживать точку доверия. Один из методов для приложений пользовательского пространства называется DNSSEC с нулевой конфигурацией (zero-configuration DNSSEC) и основан на механизмах начальной загрузки точки доверия DNSSEC, описанных в RFC7958. (Этот механизм разработан и применяется для getdns API, см. следующий раздел).
Путь вперед
Для адекватной безопасности и приватности первым условием является надежный тупиковый резолвер. В цепочке преобразования DNS тупиковый резолвер жизненно важен для выдачи проверенных на подлинность данных DNS и обеспечения приватности в оконечной точке.
API
Мы еще не касались вопроса о том, как предоставить проверенные данные DNS и проверку DANE приложению. Мы рассмотрели, как тупиковый резолвер может надежно получать проверенные данные DNSSEC, но пока не рассуждали о том, как приложение может получить к ним доступ. Необходимо дать разработчикам приложений простой в использовании и гибкий API.
Два свежих примера DNS API – это интерфейс systemd-resolved и проект getdns API.
Systemd использует systemd-resolved для реализации функционала DNS. Оба компонента являются частью проекта freedesktop.org, и приложения могут использовать интерфейс D-Bus для полного доступа к systemd-resolved, например, в целях проверки DNSSEC.
Проект getdns API совместно разрабатывается NLnet Labs. Цель проекта – создать гибкий и современный асинхронный DNS API для разработчиков приложений. При разработке API учитывались пожелания разработчиков приложений и систем, чтобы соответствовать потребностям и ожиданиям тех, кому, в конечном счете, придется с этим API работать.
В любом случае стандартизация DNS API и его доступность на различных платформах необходимы – так мы сможем улучшить нынешнюю ситуацию и добиться более массового распространения DNSSEC и DANE на рынке приложений.
Например, в проекте getdns API реализованы многие новейшие стандарты, направленные на то, чтобы сделать проверку DNSSEC и аутентификацию DANE доступными в оконечных точках: в частности, обход блоков DNSSEC, синтез IPv6 для сред NAT64/DNS64 и DNSSEC с нулевой конфигурацией.
Приватность DNS и DNS поверх TLS
Разработка и реализация getdns API также вплотную следует за развитием стандарта приватности DNS (DNS поверх TLS), описанного в RFC7858. Этот механизм обеспечивает пользователю новый уровень безопасности, так как запросы DNS-клиента становятся невидимыми для пассивного наблюдателя. Однако стоит помнить, что все равно остается возможность утечки, поскольку ваши запросы и ответы на них известны не только вам. В системе, где между вами и авторитетными серверами DNS имеются посредники (резолверы), абсолютной конфиденциальности быть не может. Даже если вы будете направлять запросы авторитетным серверам DNS напрямую, они все равно будут знать, что вы запрашивали у них эту информацию. Поэтому имеет смысл внимательно изучить политику конфиденциальности вашего поставщика услуг DNS перед тем, как делать выбор.

getdns API обеспечивает приватность DNS для старых приложений посредством системного компонента Stubby (https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+Stubby). Он выполняется в виде демона на локальной машине, рассылая запросы DNS резолверам по зашифрованному соединению TLS.
Можно задать вопрос – чем это отличается от Unbound, другого проекта NLnet Labs: ведь он тоже может быть настроен как локальный транслятор пакетов, использующий DNS поверх TLS для пересылки запросов. В настоящий момент Unbound не обладает всем набором функционала TCP/TLS, реализованным в Stubby. Например, он не поддерживает режим Strict (https://tools.ietf.org/html/draft-ietf-dprive-dtls-and-tls-profiles) или паддинг запросов с целью маскировки размера пакета, а кроме того, он открывает отдельное соединение для каждого запроса DNS (Stubby использует соединения повторно).
В общем и целом, Unbound – более зрелый и стабильный демон, но мы стремимся сделать Stubby настолько же добротным. Обратите внимание, что оба демона можно использовать совместно: Unbound для кэширования, а Stubby – для канала TLS вверх по потоку (https://github.com/getdnsapi/stubby/issues/32).
И наконец, getdns API также удобен и полезен для разработчиков приложений на платформах Android и iOS. Защита данных и конфиденциальности для мобильных устройств в последующие годы приобретет особую остроту, и планы поддержки getdns API для этих платформ становятся все более конкретными.
DNS поверх HTTPS
Результатом недавней попытки IETF повысить целостность и конфиденциальность запросов DNS стал DNS поверх HTTPS Е (https://tools.ietf.org/html/draft-hoffman-dns-over-https). Компонент конфиденциальности в DNS поверх HTTPS реализован, в сущности, путем создания зашифрованного канала TLS – ведь именно он отвечает за букву S в названии HTTPS, – и в этом смысле данное решение мало чем отличается от DNS поверх TLS. Похоже, само по себе оформление двоичного запроса DNS в виде HTTP не дает никаких новых преимуществ, но в этом решении имеется два интересных аспекта с точки зрения внедрения и приватности.
Как упоминалось выше, доставка данных DNSSEC в оконечные точки сопряжена со множеством трудностей: достаточно вспомнить и о потере пакетов при прохождении через неправильно функционирующие сетевые промежуточные устройства, и о резолверах, которые не пересылают данные DNSSEC дальше, и о многом другом. Иногда пакеты DNS прослушиваются или просто блокируются – вспомните гостиничные Captive-порталы, которые зачастую пропускают только веб-трафик и электронную почту. Потому DNS поверх HTTPS, использующий порт 443, наверняка найдет применение во многих ситуациях, где другие методы, такие как UDP или TLS, результата не дадут.
Второй момент – в процессе преобразования запросов DNS, например, при загрузке веб-страницы, происходит обращение к нескольким серверам DNS и соответственная утечка информации, добавляя в копилку повсеместного прослушивания. Минимизация имен запросов [RFC7816] помогает обеспечить конфиденциальность за счет того, что резолвер DNS отправляет ответственному серверу имен минимально необходимый объем информации. Но в DNS поверх HTTPS запросы DNS пересылаются вместе с трафиком HTTPS для загрузки веб-страниц. Дополнительным преимуществом перед минимизацией имен является то, что трафик DNS не сходит с пути, и потому меньше информации становится доступно третьим сторонам.

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

Источник: Bringing DNS Security and Privacy to the End User

Бенно Оверайндер (Benno Overeinder) – исполнительный директор нидерландской некоммерческой исследовательской компании NLnet Labs. Интересы Бенно лежат в средне- и долгосрочном планировании (стратегическом и тактическом) работы NLnet Labs, а помимо того – в области интернет-архитектуры, DNS, маршрутизации, стабильности и безопасности.