dxdt.ru: занимательный интернет-журнал

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

На слуху сейчас пара методов защиты DNS, а также косвенно связываемый с DNS метод защиты доступа, реализующий аутентификацию по имени (TLS). Пара методов, относящихся непосредственно к DNS, это криптографическое расширение самой системы – DNSSEC, а кроме того защита трафика при помощи TLS – DNS-over-TLS (далее – DoT, сюда же относится “надстройка” в виде DNS-over-HTTPS, DoH). При этом часто можно услышать, что TLS, используемый для веба, – то есть, HTTP-over-TLS, – решает вопрос подмены DNS, так как позволяет аутентифицировать веб-узел по имени.

Действительно, TLS позволяет клиенту проверить подлинность сервера, к которому он подключается, при помощи серверного TLS-сертификата. Если DNS-ответ подменён и программа-клиент подключается к подменному узлу по TLS, то эта программа может проверить сертификат: предполагается, что подменный узел не имеет корректного ключа от доверенного сертификата, DNS-имя задано клиенту при обращении и должно сходиться с указанным в сертификате, поэтому подмена будет обнаружена. Последнее, конечно, подходит для большинства практических случаев, но в случае общем – просто не верно: подставной, но доверенный, сертификат для другого ключа мог быть выпущен либо при помощи всё той же подмены DNS, осуществлённой в направлении систем УЦ, либо при помощи перехвата трафика, идущего к легитимному узлу. Уже это наблюдение приводит к мысли, что TLS для веба никак не может отменить необходимость защиты DNS тем или иным способом – ведь это инструменты, работающие на разных шагах и на разных уровнях: если бы клиент обнаружил подмену DNS, то этот клиент не подключался бы к подменному узлу, так что подменный сертификат по описанной схеме не получилось бы применить (это, впрочем, не исключает применения “в разрыв”, то есть, на промежуточном узле).

Основное отличие TLS, как метода защиты в вебе, для HTTPS, от защиты DNS состоит в том, что для срабатывания TLS в вебе клиент всё же должен подключиться к атакующему, подменному узлу. А это совсем другая поверхность атаки. Например, атакующий узел может “проэксплуатировать” какие-то дефекты клиентской реализации TLS, что отменит требование о наличии легитимного сертификата: в особо продвинутых случаях ни один HTTP-запрос даже не будет отправлен, но клиент окажется взломан, получив код с атакующего узла. DNS, срабатывая раньше, позволяет предотвратить _само_ _подключение_ к подменному узлу по TLS. То есть, эффективная защита DNS предоставляет тут дополнительный рубеж безопасности. Поэтому предположение, что использование TLS с сертификатами в HTTP-over-TLS достаточно для защиты клиента, и поэтому не нужно защищать DNS, так как TLS решит все проблемы выше уровня IP, – ошибочно. (Не будем, впрочем, забывать, что TLS-сертификаты можно получить для IP-адресов тоже, даже в Let’s Encrypt автоматом.)

Но с защитой DNS есть свои проблемы. Вернёмся к паре упомянутых выше методов такой защиты. Первый из них – DNSSEC. Эта технология крайне мало распространена в доменных зонах. Зато DNSSEC касается буквально всех пользователей валидирующих резолверов, так как используется в корневом домене. Всего лишь несколько десятичных цифр позволяют отломить зону верхнего уровня целиком, при этом аварию DNSSEC в большой зоне замечают все и сразу, очередной раз демонстрируя, что про DNS мало кто вообще в курсе, пока эта технология работает, но как только ломается – о DNS узнаёт едва ли не каждый. Второй метод защиты, – DoT/DoH, – распространён существенно больше, поскольку на клиенте встроен прямо в браузеры, но касается только тех сессий, в которых используется. Так вышло потому, что эти технологии тоже принципиально различаются: и по шагам использования, и по уровню применения (почти как HTTP-over-TLS).

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

Если TLS позволяет удостоверить только узлы в рамках сессии, но не на уровне DNS, то DNSSEC, архитектурно, работает в другой плоскости: информация в DNS касается не сессий и узлов, а правил определения узлов и создания сессий. Поэтому, если поступили данные с DNSSEC-подписями, то DNS-клиенту всё равно, какой узел эти данные прислал, если подписи сходятся. В TLS, несомненно, тоже есть аутентификация передаваемых данных, однако эта аутентификация возможна только по конкретным сессионным ключам, то есть, здесь всё на уровне “передачи данных”. В TLS возможно только узнать, что данные передаёт тот сервер, у которого есть секретный ключ от ключа в сертификате, но ничего нельзя узнать про сами передаваемые данные. Поэтому, если требуется проверить сами данные, TLS не помогает, а нужны дополнительные методы.

Вспомним теперь, что DoH используется только на “последней DNS-миле”, то есть, от клиента к рекурсивному резолверу. DoT может использоваться и на авторитативных серверах (например, поддерживается NS wikimedia.org и facebook.com), но, всё же, распространена эта технология тоже только на “последней DNS-миле”. Таким образом, DoT/DoH не позволяют проверить подлинность DNS-данных, как их видит резолвер, но позволяют аутентифицировать резолвер и зашифровать данные на “последней DNS-миле”. DoT/DoH скрывают трафик от пассивно прослушивающей канал стороны – обычные DNS-пакеты, напротив, ходят в открытом виде, так как DNSSEC никакого зашифрования не предусматривает. Но “последняя миля” тут очень важна: трафик DNS к резолверу, соответствующий запросу клиента, всё равно ходит в открытом виде (если, конечно, резолвер не использует только DoT в направлении авторитативных серверов, но так сейчас работать DNS не будет на практике). В DNS-запросы могут быть встроены маркеры, которые позволят различать источники этих запросов на промежуточных узлах “за резолвером”.

Интересно, что в DNS, как в систему, давно встроены базовые методы защиты от спуфинга ответов. Встроены они на уровне пакетов и UDP-обмена. Классический элемент пакета – это поле TransactionID, которое содержит 16-битный идентификатор: предполагается, что корректный ответ сервера будет содержать TransactionID, совпадающий с присланным в запросе, и это позволит клиенту (резолверу) отличить настоящий ответ от “подспуфленного”, который присылает узел, не видевший запроса. Второй элемент – номер порта источника, указываемый в UDP-пакете. Работать должно аналогично схеме с TransactionID, но с учётом особенностей транспорта: то есть, ответ на тот же номер порта, который указан в качестве источника (и тут необходимо “передать привет” NAT). Есть и более экзотическая схема, построенная на рандомизации регистра символов имени (DNS Case Randomisation). Эти методы работают где-то между DNSSEC и DNS-over-TLS: сторона, видевшая запрос, всё равно может подделать ответ.

(Эту заметку я первоначально выложил на “Хабре” как статью, однако там отметили, что в такой статье “нет описания самих протоколов”, и это обманывает ожидания кликающих. Замечание резонное, скорее всего, так и есть – но я и не планировал описывать здесь детали устройства самих протоколов, идея публикации, действительно, архитектурная. В общем, на “Хабре” я статью пока убрал в раздел “Черновики”, чтобы не беспокоить аудиторию уважаемого ресурса, а здесь – опубликовал.)

Адрес записки: https://dxdt.ru/2025/02/19/15056/