DNSSEC и безопасность DNS в вашей локальной сети

Информатек Диджитал » Ресурсы » DNSSEC и безопасность DNS в вашей локальной сети

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

Раньше приоритетом было просто обеспечение работоспособности всех систем; сегодня мы понимаем, что этого недостаточно. DNS появился в 80-х годах, не предполагая масштабных кибератак, но теперь он необходим не только для разрешения имен, но и для проверки подлинности и целостности каждого ответа . Именно здесь на помощь приходит DNSSEC, а в последнее время появились и такие предложения, как E-DNSSEC, которые направлены на обеспечение конфиденциальности — ключевого фактора, если вас беспокоит безопасность вашей локальной или корпоративной сети.

Что такое DNS и почему он так важен для безопасности?

Система доменных имен (DNS ) — это своего рода телефонная книга интернета: она преобразует легко запоминающиеся имена (например, www.example.com) в числовые IP-адреса, понятные компьютерам (например, 192.168.2.15 или IPv6-адрес). Без этого механизма нам пришлось бы запоминать цифры вместо имен, что совершенно непрактично.

Эта инфраструктура организована как распределенная база данных в древовидной структуре , с корневой зоной наверху, за которой следуют домены верхнего уровня (TLD, такие как .es, .com, .org), а ниже — домены и поддомены. Каждая часть этой базы данных называется « зоной » и размещается на одном или нескольких авторитетных серверах имен, которые публикуют «официальную» информацию для каждого домена.

Когда ваш компьютер, мобильный телефон или любое другое устройство хочет получить доступ к веб-сайту, оно сначала обращается к заглушке DNS-сервера , который является частью операционной системы. Этот DNS-сервер отправляет запрос на рекурсивный DNS-сервер (обычно это сервер вашего интернет-провайдера, вашей компании или общедоступный, такой как Google Public DNS , OpenDNS или Quad9). Затем этот рекурсивный сервер ищет ответ, обращаясь к нескольким авторитетным серверам, пока не найдет правильный IP-адрес.

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

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

Ограничения безопасности традиционной DNS

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

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

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

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

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

Что такое DNSSEC и какой вклад он вносит в безопасность?

В ответ на все эти недостатки были разработаны расширения безопасности системы доменных имен (DNSSEC) . DNSSEC не заменяет классический DNS, а расширяет его, добавляя уровень безопасности, позволяющий проверить, являются ли полученные данные легитимными и не были ли они изменены.

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

Когда рекурсивный сервер запрашивает домен с помощью DNSSEC, помимо обычной информации (например, IP-адреса, связанного с именем), он также получает цифровые подписи и открытые ключи, необходимые для проверки . Рекурсивный сервер проверяет подписи на соответствие опубликованным открытым ключам; если проверка проходит успешно, данные считаются подлинными и неизменными с момента их подписания.

Если проверка не удалась, обработчик запросов понимает, что что-то не так (например, попытка подделки или изменения данных во время передачи) и отправляет клиенту код ошибки, обычно SERVFAIL . Таким образом, пользователь не получает потенциально вредоносные данные, хотя с его точки зрения он увидит только то, что страница «не загружается» или отображает ошибку.

DNSSEC также вводит концепцию цепочки доверия , которая использует существующую иерархию DNS. Корневая зона подписывает ключи доменов верхнего уровня (таких как .es, .com), которые, в свою очередь, подписывают ключи своих дочерних доменов и так далее, так что любой домен может быть проверен с помощью единой точки доверия: открытого ключа корневой зоны.

Ключи KSK и ZSK, записи и цепочка доверия.

Для повышения уровня безопасности DNSSEC использует два разных типа ключей: ключ подписи ключа (KSK) и ключ подписи зоны (ZSK) . Хотя технически они одинаковы (с точки зрения криптографии), их функции в системе различаются.

Ключ ZSK используется для подписи всех записей ресурсов в зоне (A, AAAA, MX и т. д.). Как правило, его часто меняют, чтобы минимизировать риски, поскольку любая компрометация этого ключа повлияет на все записи в зоне. Ключ KSK, с другой стороны, в основном используется для подписи самого ключа зоны (ZSK), а его хеш публикуется в качестве записи DS (Delegation Signer) в родительской зоне.

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

DNSSEC добавляет в протокол DNS несколько типов специальных записей, предназначенных для поддержки подписи и проверки данных. К числу наиболее важных относятся DNSKEY, RRSIG, DS, NSEC/NSEC3 и NSEC3PARAM . Все они позволяют создавать логику аутентификации без изменения базовой работы запросов.

Запись DNSKEY хранит открытый ключ зоны , необходимый для проверки подписей. Запись RRSIG содержит цифровую подпись, связанную с определенным набором записей («набором ресурсных записей»). Запись DS представляет собой хеш DNSKEY дочерней зоны, который публикуется в родительской зоне и служит звеном в цепочке доверия.

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

Проверка цепочки доверия и ответа DNSSEC

Так называемая цепочка доверия в DNSSEC строится путем связывания записей DNSKEY и DS от корневого домена с доменом, который мы хотим проверить . Отправной точкой является открытый ключ корневой зоны, который выступает в качестве якоря доверия и обычно настраивается непосредственно в рекурсивных резолверах.

Например, если вы хотите проверить домен типа mywebsite.es, логический процесс будет следующим: резолвер доверяет открытому ключу корневого домена, который подписывает ключ .es; зона .es публикует запись DS, соответствующую ключу KSK mywebsite.es; проверив эту запись DS с помощью ключа .es, резолвер доверяет ключу DNSKEY mywebsite.es и, исходя из этого, может проверить RRSIG для всех своих записей.

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

Эта иерархическая структура также означает, что для того, чтобы DNSSEC был действительно эффективным, недостаточно подписать только вашу зону : родительская зона (например, .es) и корневая зона также должны быть подписаны, и их DNS-записи должны быть корректно опубликованы. В настоящее время корневая зона DNS и практически все общие домены верхнего уровня (gTLD), а также многие домены верхнего уровня с кодом страны (ccTLD) уже подписаны.

Когда рекурсивный сервер с включенной проверкой DNSSEC обнаруживает несоответствие подписи или отсутствие ссылки, он обычно отправляет клиенту ответ с кодом ошибки RCODE SERVFAIL. Это может сбивать с толку конечного пользователя («веб-сайт не работает»), но с точки зрения безопасности это защитная мера от потенциальной манипуляции данными.

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

Атаки, предотвращаемые DNSSEC, и их связь с TLS/HTTPS.

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

Кроме того, DNSSEC снижает риск отравления кэша на рекурсивных серверах , предотвращая принятие измененных ответов, не прошедших проверку подписи. Это также усложняет атаки типа «человек посередине» (MITM) на DNS-трафик, при которых злоумышленник изменяет ответы в процессе передачи: если ответ не проходит проверку, резолвер его отбрасывает.

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

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

Такие организации, как ICANN и IETF, уже много лет продвигают широкое внедрение DNSSEC среди реестров, регистраторов, интернет-провайдеров и сетевых операторов. Цель состоит в том, чтобы все больше и больше зон были подписаны, а все больше резолверов активно проверяли их, чтобы обычный пользователь мог воспользоваться этими криптографическими гарантиями без каких-либо специальных действий.

DNSSEC в доменах .es и обязанности владельцев

В частности, в случае Испании подразделение доменов ".es", управляемое компанией Red.es, уже давно внедряет дополнительные технологии и процедуры для повышения качества и безопасности DNS-сервиса под кодом страны .es. Среди этих мер — внедрение протокола безопасности DNSSEC в соответствии со спецификациями IETF.

Домены .es отвечают за подписание зоны верхнего уровня .ES и получение авторизации от корневого DNS-сервера, тем самым интегрируясь в глобальную цепочку доверия. Это означает, что если вы владеете доменом .es, вы можете использовать эту инфраструктуру для защиты своего собственного домена с помощью DNSSEC.

Для владельца домена общая процедура включения DNSSEC включает в себя обеспечение публикации подписанной зоны вашими авторитетными DNS-серверами. Как правило, это включает в себя генерацию открытого ключа для вашей зоны, подписание записей, публикацию ключа DNS, а затем отправку материала ключа (или самой записи DS) в реестр или вашему регистратору, чтобы они могли создать соответствующую запись DS в родительской зоне.

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

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

DNSSEC в локальной сети: проверка на стороне пользователя.

С точки зрения конечного пользователя или компании, обеспокоенной безопасностью своей локальной сети, ключевой вопрос: что нужно сделать, чтобы получить выгоду от DNSSEC? Хорошая новость заключается в том, что вам не нужно ничего настраивать на каждом компьютере по отдельности , если ваш рекурсивный DNS-сервер (тот, который используют ваши компьютеры) поддерживает DNSSEC.

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

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

Чтобы проверить, защищен ли ваш домен с помощью DNSSEC, существует несколько онлайн-инструментов, таких как DNSSEC Analyzer и другие утилиты проверки . При вводе данных вашего домена вы должны увидеть записи, такие как RRSIG (криптографические подписи), DNSKEY (открытые ключи) и DS (хеш DNSKEY в родительской зоне). Если инструмент показывает, что с этими записями не связана цифровая подпись, ваш домен будет считаться «неподписанным» или «небезопасным».

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

Ограничения DNSSEC: конфиденциальность и другие аспекты.

Несмотря на все свои преимущества, DNSSEC не является панацеей от всех проблем безопасности DNS. Ключевая проблема заключается в том, что он не обеспечивает конфиденциальность запросов . DNS-пакеты, даже с DNSSEC, по-прежнему передаются в открытом виде, поэтому любой, кто имеет доступ к трафику (например, в незащищенной общедоступной сети Wi-Fi ), может видеть, какие домены запрашиваются.

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

С другой стороны, DNSSEC вносит некоторую операционную сложность: необходимо управлять парами ключей , осуществлять ротацию ZSK и KSK, координировать публикацию DS в родительской зоне и обеспечивать отсутствие несоответствий, нарушающих цепочку доверия. Ошибка в этих процедурах может привести к тому, что домен перестанет корректно проходить проверку, вызывая видимые сбои в работе сервиса.

В самом процессе DNSSEC в сообщениях присутствуют управляющие биты (например, бит CD в запросах и бит AD в ответах), которые влияют на то, как выполняется и представляется проверка. Злоумышленник, способный манипулировать этими битами в незащищенной среде, может попытаться ослабить защиту, обеспечиваемую рекурсивным резолвером. Поэтому рекомендуется, чтобы обмен данными между резолверами и клиентами с использованием DNSSEC происходил по защищенным каналам.

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

E-DNSSEC: На пути к аутентифицированной и зашифрованной DNS.

Для решения проблемы конфиденциальности, возникающей из-за DNSSEC, была предложена концепция E-DNSSEC (шифрованный DNSSEC) . Идея этого подхода заключается в добавлении шифрования к запросам DNSSEC, чтобы, помимо аутентификации и подписи, они также были защищены от проверки третьими лицами во время передачи через Интернет или локальную сеть.

Цель E-DNSSEC — объединить свойства DNSSEC (аутентичность и целостность) с механизмами шифрования, обеспечивающими конфиденциальность запросов между клиентом DNSSEC и сервером DNSSEC . Это повышает общую безопасность службы DNS, предотвращая возможность для внешних наблюдателей увидеть, какие доменные имена разрешаются.

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

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

Сегодня такие предложения, как E-DNSSEC, являются частью более широких усилий по усилению конфиденциальности DNS , наряду с такими технологиями, как DNS over TLS (DoT) и DNS over HTTPS (DoH). Основное направление ясно: DNS будущего должен быть одновременно аутентичным и конфиденциальным, и недостаточно просто быстро разрешать имена; это также должно делаться безопасно.

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

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

Связанная статья:

Как включить DNS через HTTPS (DoH) в Windows 11 и повысить уровень конфиденциальности