Авторитетные name-серверы
Существует два типа авторитетных name-серверов: master (или первичный) name-сервер и slave (или вторичный) name-сервер. Для обеспечения большей надежности от сбоев может существовать несколько slave name-серверов для каждого master-сервера. Master name-сервер содержит зонные файлы, которые создаются и редактируются вручную администратором зоны. Иногда master name-сервер допускает, чтобы зонный файл мог динамически изменяться авторизованными DNS-клиентами. Slave name-сервер также содержит авторитетную информацию для зоны, но его зонный файл является репликацией зонного файла связанного с ним master name-сервера. Репликация осуществляется с помощью транзакции, называемой зонной пересылкой, которая пересылает все ресурсные записи из зонного файла в master name-сервере на slave name-сервер. Так как запрос разрешения имени выполняется для конкретной ресурсной записи, зонная пересылка на самом деле рассматривается как категория запроса разрешения имен с кодом типа AXFR, который означает "все ресурсные записи для зоны, которая запрашивается". Всякий раз, когда содержимое зонного файла изменяется на master name-сервере, slave name-сервер уведомляется об изменении с помощью транзакции, называемой DNS NOTIFY. Когда slave name-сервер получает данное сообщение, он инициализирует запрос зонной пересылки к master name-серверу. Для обозначения данных типов name-серверов могут использоваться также термины первичный и вторичный name-сервера.
Безопасность DNS
Рассмотрим общие принципы безопасного развертывания сервисов DNS. Начнем с анализа целей безопасности и согласованных подходов к защите всех компонентов DNS.
Объекты, безопасность которых следует обеспечивать, определяются на основе анализа возможных угроз каждому компоненту DNS.Безопасное развертывание каждого компонента DNS определяется с помощью опций в соответствующих конфигурационных файлах.
Спецификации механизмов безопасного развертывания сервисов DNS приводятся в следующих документах:
спецификации DNSSEC описаны IETF в RFC 4033, 4034, 4035 и 3833;спецификации Transaction Signature (TSIG) описаны IETF в RFC 2845 и 3007.
Безопасность окружения DNS
Окружение, в котором выполняются сервисы DNS, состоит из следующих элементов:
Платформа хоста (ОС, файловая система, стек коммуникационных протоколов).ПО DNS (name-сервера, resolver’а).Данные DNS (зонный файл, конфигурационный файл).
Рассмотрим угрозы и возможные подходы к защите для окружения DNS.
Данные DNS и ПО DNS
Двумя основными компонентами ПО DNS являются name-сервер и resolver. Основные функции name-сервера состоят в обслуживании базы данных (называемой зонным файлом), содержащей информацию о зоне, и в предоставлении ответов на запросы разрешения имени посредством авторитетных ответов или referral’ов. Основной функцией ПО resolver’а является запрос или серия запросов разрешения имени. Основными данными DNS является зонный файл; другим типом данных DNS является конфигурационный файл. Сначала обсудим структуру зонного файла, а затем функции различных типов name-серверов и resolver’ов. Обсуждение name-серверов и resolver’ов будет вестись в контексте уровня предприятия и может быть неприменимо к аналогичным сущностям уровней root и TLD.
Динамические обновления
Если происходит добавление, удаление или перемещение сетевых ресурсов (например, серверов баз данных, web-серверов, почтовых серверов или name-серверов), соответствующие изменения необходимо делать в зонном файле, содержащим информацию о доменах, в которых размещены эти ресурсы. На ранних стадиях развития DNS администратор зоны делал такие изменения вручную. Когда такие изменения становятся большими и частыми, ручное изменение затрудняется, поэтому было введено понятие динамического обновления. Независимо от объема и частоты обновлений, существуют некоторые приложения, которые требуют немедленных автоматических изменений зонного файла с помощью прикладных программ. Примерами этого являются серверы DHCP.
DHCP-сервер динамически связывает IP-адрес с хостом, затем добавляет данную информацию (хост и назначенный ему IP-адрес) как ресурсную запись с типом A. DHCP-сервер удаляет данную ресурсную запись с типом A после того, как IP-адрес возвращается хостом.
В некоторых случаях DNS-сервер может использоваться в качестве репозитория сертификатов открытого ключа. При этом СА получает открытый ключ от пользователя, подписывает его своим закрытым ключом для создания сертификата и хранит данный сертификат в ресурсной записи с типом CERT (CERT RR) в зонном файле.
В RFC 2136 описан механизм динамического изменения, который затем был реализован в BIND 8-й версии и поддерживается во всех последующих версиях.
Возможность динамического изменения определяет операции для добавления и удаления ресурсных записей в зонном файле.
Набор операций для динамического изменения определен следующим образом:
Добавить или удалить отдельные ресурсные записи для существующего домена.Удалить конкретные RRSets (множество ресурсных записей с одним и тем же именем владельца, классом или RRType – например, множество ресурсных записей с RRType NS для имени домена example.ru) для существующего домена.Удалить существующий домен (все ресурсные записи для данного доменного имени – например, все ресурсные записи для домена example.ru).Добавить новый домен (одну или более ресурсных записей для нового домена – например, добавление ресурсной записи типа А для нового домена new.example.ru).
Зоны DNS, которые допускают динамическое изменение, открыты для дополнительных атак. Далее будет приведен полный список потенциальных атак и возможное решение для ограничения возможности выполнить эти атаки.
DNS NOTIFY
Всякий раз, когда выполняются изменения в зонном файле первичного (master) DNS-сервера, вторичные (slave) DNS-серверы, которые содержат идентичные данные, должны быть уведомлены об изменениях. Такое уведомление выполняется посредством сообщения DNS NOTIFY, которое указывает, что вторичному DNS-серверу следует начать зонную пересылку. Сообщение DNS NOTIFY является более быстрым и эффективным способом поддержки синхронизации вторичных серверов с первичным сервером, чем альтернативный подход, при котором вторичные серверы запрашивают первичный сервер об изменениях с помощью значения времени в SOA Refresh.
Посылка сообщения DNS NOTIFY, называемая операцией notify, является способом синхронизации по умолчанию в BIND 9.x. Возникает вопрос: как name-сервер узнает, каким серверам сообщение DNS NOTIFY должно быть послано? В BIND 9.x уведомление посылается серверам, которые определены в NS ресурсных записях для зоны. Если существуют дополнительные серверы, которым администратор зоны хочет посылать сообщение DNS NOTIFY (так называемые невидимые slave-серверы), администратор DNS может добавить IP-адреса этих серверов в конфигурационный файл BIND. Администратор может также с помощью конфигурационных опций не разрешать серверу посылать сообщения NOTIFY о некоторых зонах, обслуживаемых данным name-сервером.
После того как вторичный сервер получил сообщений DNS NOTIFY, он посылает запрос зонной пересылки к первичному серверу, независимо от того, как давно в последний раз зонная пересылка осуществлялась. Данная процедура позволяет распространять изменение зоны всем вторичным name-серверам более быстро.
Так как сообщение DNS NOTIFY запускает зонную пересылку, ложные сообщения DNS NOTIFY могут привести к ненужным зонным пересылкам и, следовательно, потенциальным DoS-атакам.
Инфраструктура DNS
Инфраструктура DNS состоит из вычислительных и коммуникационных элементов, географически распределенных по всему миру. Для того, чтобы понять инфраструктуру DNS, необходимо, во-первых, проанализировать структуру доменных имен. Пространство доменных имен организовано в виде иерархической структуры. Самым верхним уровнем иерархии является root domain, который представим в виде точки ("."). Следующий уровень называется top-level domain (TLD) (домен верхнего уровня). Существует только один root domain, но много TLDs. Каждый TLD называется дочерним доменом от домена root. В данном контексте root домен является родительским доменом, потому что он на один уровень выше TLD. Каждый TLD, в свою очередь, может иметь много дочерних доменов. Дочерние домены для TLDs называются second-level или enterprise-level доменами (доменами второго уровня).
Символ, обозначающий root-домен, обычно опускается. Например, рассмотрим доменное имя marketing.example.ru. Самая правая часть данного доменного имени (".ru") является TLD. Следующая часть ("example") есть домен второго или enterprise уровня. Самая левая часть ("marketing") есть домен третьего уровня. Также возможно существование доменов четвертого, пятого и т.д. уровней. Каждая из частей в marketing.example.ru называется доменом, конкатенация всех этих частей от текущего уровня до TLD называется полностью определенным доменным именем (Fully Qualified Domain Name – FQDN). Однако часто FQDN называется просто доменным именем.
Существует только один root домен. Существуют более 250 TLDs, разделенных на следующие категории:
TLDs кода страны (country-code TLDs – ccTLDs) – домены, связанные со странами и территориями. Определено более 240 ссTLDs. Примерами являются .ru, .uk, .jp.Общие спонсируемые TLDs (sponsored generic TLDs – gTLDs) – специализированные домены, представляющие сообщества по интересам. Данные TLDs включают .edu, .gov, .int, .mil, .aero, .coop и .museum.Общие неспонсируемые TLDs (unsponsored generic TLDs – gTLDs) – домены без спонсорской организации.
Список неспонсируемых TLDs включает .com, .net, .org, .biz, .info, .name и .pro.
Имеется несколько миллионов доменов второго уровня.
В инфраструктуре DNS насчитывается большое количество name-серверов. Каждый name-сервер содержит информацию о части пространства доменных имен и связан с определенным уровнем. Существует 13 name-серверов, связанных с уровнем root; они называются root servers. Два из этих серверов расположены в частной корпорации VeriSign в США; остальные функционируют в добровольных организациях по всему миру. Организации, в которых функционируют name-серверы, связанные с TLD, называются registries. Обычно ссTLDs поддерживаются специально назначенными регистрационными органами в каждой стране, gTLDs поддерживаются глобальными регистрационными органами. Например, VeriSign в настоящее время управляет name-серверами для .org и .net TLDs, непрофицитная организация, называемая Public Internet Registry (RIP), управляет name-серверами для .org TLD; другая непрофицитная организация, называемая EDUCAUSE, управляет name-серверами для .edu TLD. Однако все эти регистрационные органы могут быть изменены. Name-серверы, связанные с доменами второго уровня и ниже, выполняются либо непосредственно в организациях, которые владеют этими доменами, либо у Интернет Сервис Провайдера (ISP) или провайдеров других сервисов.
Инфраструктура DNS функционирует посредством соглашения среди различных участников, включая организации, в которых функционируют root-серверы, registries, в которых функционируют TLDs, и т.п. Непрофицитная корпорация Internet Corporation for Assigned Names and Numbers (ICANN) действует в качестве технического координатора всех аспектов, касающихся DNS. Например, ICANN формулирует политики для управления root-серверами. ICANN также отвечает за создание новых TLDs.
Пользователь (как индивид, так и корпорация), желающий зарегистрировать доменное имя (которое может быть не выше второго уровня), должен обратиться к своему уполномоченному органу, называемому регистратором (registrar).
Регистраторами являются компании, которые уполномочены выделять доменные имена в конкретном TLD конечным пользователям или организациям. Регистраторы существуют во всем мире. Когда регистратор получает запрос на регистрацию, он проверяет в соответствующем реестре, что имя свободно, и регистрирует его в данном реестре.
Владельцы доменных имен второго уровня часто создают дочерние домены, чтобы различные ресурсы, расположенные в их домене, могли быть доступны в Интернете. Например, собственник имени домена example.ru может создать поддомен unit для того, чтобы ресурсы, связанные с подразделением, могли быть доступны в Интернете. Аналогично, поддомены могут создавать свои поддомены (в данном контексте, домены третьего уровня) для доступа к своим ресурсам из Интернета. Очень часто в некоторой организации, которая является собственником домена второго уровня, определено много доменов третьего уровня, но в каждом из них существует всего несколько ресурсов, доступных из Интернета (web-серверов, прикладных серверов и т.п.). Следовательно, неэкономично связывать уникальный name-сервер с каждым из доменов третьего и более низкого уровня. Более того, с точки зрения администрирования, удобнее сгруппировать всю информацию, относящуюся к основному домену организации (например, домену второго уровня) и всем его поддоменам, в единый ресурс и управлять им как одним блоком.
Чтобы облегчить возможность такого группирования, в DNS определено понятие "зоны". Зоной может являться либо весь домен, либо домен с группой поддоменов. Зона является конфигурируемой сущностью внутри name-сервера, которая описывает все ресурсы Интернета, относящиеся к домену и выбранному множеству поддоменов. Таким образом, зоны — это административно созданные блоки пространства имен DNS, а домены — структурно созданные блоки. Как результат, термин зона обычно используется и для ссылки на домен, который управляется как отдельная административная единица (например, зона root, зона .ru). Будем использовать термин зона для ссылки на ресурсные записи, которые содержат информацию о доменных именах для одного или более доменов и управляются как единая административная сущность.
Другими словами, зона есть конфигурируемый ресурс внутри развернутого name-сервера.
Имея общее представление об инфраструктуре DNS (name-серверах и resolver’ах), доменных именах, зонах, name-серверах различного уровня (например, root-сервера и TLD-сервера) и resolver’ах, функцию разрешения имени теперь можно определить более детально. Когда пользователь вводит URL ресурса (например, www.example.ru) в web-браузер, программа браузера соединяется с resolver’ом, тип которого называется stub resolver, который, в свою очередь, соединяется с локальным name-сервером (называемым рекурсивным name-сервером или resolving name-сервером). Рекурсивный name-сервер проверяет свой кэш, чтобы узнать, имеется ли там корректная информация (информация определяется как корректная на основе критерия, который будет описан далее) об IP-адресе для этого ресурса. Если такой информации нет, то рекурсивный name-сервер проверяет кэш, чтобы узнать, имеется ли информация, относящаяся к name серверу для зоны example.ru (так как считается, что эта зона содержит ресурс www.example.ru). Если IP-адрес name-сервера есть в кэше, следующий запрос resolver’а будет перенаправлен на данный name-сервер. Если IP-адреса name-сервера для example.ru нет в кэше, то resolver определяет, имеется ли у него информация о name-сервере для зоны, которая расположена на один уровень выше, чем example.ru (т.е. ru).
Если полный поиск в кэше (как описано выше) не принес требуемой информации, рекурсивный name-сервер не имеет альтернативы и начинает свой поиск с запроса name-сервера самой верхней зоны в иерархии пространства имен DNS (т.е. root-сервера). Если поиск в кэше успешен, то рекурсивный name-сервер запрашивает name-серверы в одном из уровней ниже зоны root (в нашем случае либо example.ru, либо .ru). Так как множество итеративных запросов, начинающихся от root-сервера, аналогично множеству запросов, начинающихся от любых серверов более низкого уровня, опишем процесс разрешения имен, который начинается с запроса, посылаемого к root-серверу рекурсивным name-сервером второго уровня.
Соединение с root- сервером возможно благодаря файлу, называемому root.hint, который есть в каждом name-сервере. Файл root.hint содержит IP-адреса нескольких root-серверов. Root-сервер, в свою очередь, содержит информацию о name-серверах в своих дочерних зонах (т.е. TLDs). TLD (например, .ru) содержит информацию о name-серверах для своих дочерних зон (например, example.ru). Информация name-сервера о name-серверах в своих дочерних зонах называется информацией делегирования. Информация делегирования является информацией, которая используется для перенаправления запросов разрешения имен для ресурса, расположенного ниже, чем данный, в иерархии доменных имен. Пусть запрос разрешения имени относится к ресурсу в домене третьего уровня (www.example.ru). Root сервер перенаправляет запрос name-серверу более низкого уровня. Ответ рекурсивному name-серверу, который включает посылку информации делегирования, называется referral. В данном случае referral предоставляет IP-адрес name-сервера для TLD-зоны, которая соответствует запросу (т.е. .ru зона, так как запрос выполняется для ресурса в example.ru). Используя данный referral, рекурсивный name-сервер затем формулирует и посылает запрос к name-серверу зоны .ru. Данный сервер уже предоставит referral на example.ru name-сервер. Если www.example.ru ресурс существует в зоне example.ru, то запрос name-сервера для www.example.ru предоставит IP-адрес для ресурса www.example.ru Диаграмма процесса разрешения имени (без операций поиска в кэше) приведена на рис. 6.1.
Рис. 6.1. Последовательность запросов и ответов при разрешения имен
Name-сервер выполняет следующие функции:
предоставляет referral к дочерней зоне;предоставляет отображение доменного имени на IP-адрес, называемое разрешением доменного имени, или IP-адрес на доменное имя, называемое инверсным разрешением;предоставляет сообщение об ошибке, если запрос сделан для записи DNS, которой не существует.
Name-сервер выполняет эти три функции, используя некоторую базу данных, которая называется зонным файлом.Класс информации, называемый информацией делегирования, содержит информацию name-сервера о дочерних зонах в родительской зоне и использует ее при выполнении функции предоставления referral’а. Функция отображения выполняется классом информации в файле зоны, называемом авторитетной информацией, и обеспечивается набором записей, которые перечислены в ресурсах для данной зоны вместе с их доменными именами и соответствующими IP-адресами. Так как ресурсы принадлежат данной зоне, предоставляемая информация считается авторитетной. Таким образом, файл зоны содержит две категории информации: авторитетную информацию (информацию обо всех ресурсах во всех доменах в зоне) и информацию делегирования (информацию о name-серверах в дочерних зонах). Строки в файле зоны, в которых указывается информация делегирования, называются точками делегирования. Уровень файла зоны есть уровень самого верхнего домена, для которого он содержит авторитетную информацию.
Кэширующие name-серверы
Кэширующий name-сервер обычно является локальным name-сервером, выполняющим функции разрешения имен для различных клиентов. Кэширующий name-сервер также является рекурсивным name-сервером. Функция разрешения имен выполняется кэширующим name-сервером в ответ на запросы от stub resolver’а. Процесс поиска, выполняемый при разрешении имен, означает либо поиск в своем собственном кэше, либо последовательность запросов к различным авторитетным серверам.
Конкретный name-сервер может быть сконфигурирован и как авторитетный, и как рекурсивный. При такой конфигурации один и тот же name-сервер предоставляет авторитетную информацию на запросы, относящиеся к своей зоне, и выполняет рекурсивные функции для запросов, относящихся к другим зонам. Для выполнения рекурсивной функции он должен поддерживать рекурсивные запросы. Любой сервер, который поддерживает рекурсивные запросы, является более уязвимым для атак, чем сервер, который такие запросы не поддерживает. Одним из результатов атак может быть компрометация авторитетной информации. Следовательно, с точки зрения безопасности, не считается оптимальной практикой конфигурирование одного и того же name-сервера для выполнения как авторитетных, так и рекурсивных функций.
Компоненты DNS и понятие безопасности для них
Перед тем как определять смысл безопасности, следует описать блоки, из которых состоит DNS. DNS включает следующие сущности:
платформа (аппаратура и ОС), на которой выполняются name-сервер и resolver’ы;ПО name-сервера и resolver’а;транзакции DNS;репозиторий DNS (зонные файлы);конфигурационные файлы для name-сервера и resolver’а.
Технология сетевого доступа (например, Ethernet-сеть, соединяющая stub resolver и локальный рекурсивный name-сервер) не рассматривается при описании DNS.
Безопасность в общем случае обеспечивается с помощью сервисов конфиденциальности, целостности, доступности и аутентификации источника, которые являются общими для любой электронной системы. Однако заметим, что сервисы DNS предназначены для предоставления информации об именах и адресах любого публично доступного ресурса Интернета. Следовательно, сервис конфиденциальности не нужен для обеспечения безопасности DNS. Гарантирование аутентичности информации и поддержка целостности информации при передаче являются важными для обеспечения корректного функционирования Интернета, для которого DNS обеспечивает сервис разрешения имен. Следовательно, целостность и аутентификация источника являются основными сервисами безопасности DNS.
Name-серверы
Существует два основных типа name-серверов: авторитетные name-серверы и кэширующие name-серверы. Термин авторитетный относится к зоне. Если name-сервер содержит ресурсные записи, касающиеся конкретной зоны, он называется авторитетным name-сервером для данной зоны. Такой сервер предоставляет ответы на запросы разрешения имен для данной зоны, используя ресурсные записи в своем собственном зонном файле. Кэширующий name-сервер, в противоположность предыдущему типу name-сервера, предоставляет ответы посредством серии запросов либо к авторитетным name-серверам, расположенным выше в иерархии доменов, либо из кэша, полученного из ответов на предыдущие запросы.
Основные механизмы безопасности для сервисов DNS
Основные механизмы безопасности для сервисов DNS описаны в документах IETF, специфицирующих DNSSEC и TSIG. Рассмотрим эти спецификации, конфигурационные опции и список необходимых действий для различных компонент DNS и систем, на которых они развернуты.
Окружение, в котором выполняются сервисы DNS: платформа хоста (ОС, файловая система, стек протокола);ПО DNS (name-сервера, resolver’а);данные DNS (зонный файл, конфигурационный файл).Транзакции DNS: запрос / ответ DNS;зонные пересылки;динамические обновления;DNS NOTIFY.Администрирование DNS с учетом требований безопасности: выбор алгоритмов и размеров ключей (TSIG и DNSSEC);управление ключом (создание, хранение и использование);опубликование открытого ключа и определение доверенных корневых ключей;восстановление ключа (плановое и аварийное).
Resolver’ы
Такое ПО, как web-браузеры и e-mail клиенты, которые требуют доступа к ресурсам Интернета, используют DNS-клиент, называемый client resolver или stub resolver. Stub resolver формулирует запрос на разрешение имени для ресурса, который отыскивается в Интернете, и посылает этот запрос кэширующему name-серверу. Как правило, stub resolver сконфигурирован таким образом, чтобы иметь список кэширующих name-серверов для обеспечения большей надежности данной операции. Stub resolver обычно называется просто resolver’ом. Кэширующий name-сервер, который получил запрос от stub resolver’а, также формирует запросы для посылки их авторитетным name-серверам (если он не может ответить на запрос из своего кэша), и, следовательно, также иногда указывается как resolver, потому что он имеет рекурсивную компоненту и компоненту кэширования.
Сервисы DNS
Интернет представляет собой самую большую компьютерную сеть. С точки зрения пользователя, каждый узел или ресурс в этой сети идентифицируется уникальным именем – так называемым доменным именем. Некоторыми примерами ресурсов Интернет, для которых определяются доменные имена, являются:
Web-серверы;Mail-серверы.
С точки зрения сетевого оборудования (например, роутера), которое перенаправляет коммуникационные пакеты по Интернет, уникальный ресурс идентифицируется IP-адресом, который представляет собой набор из четырех чисел, разделенных точками (например, 123.67.43.245). Для доступа к ресурсам Интернета по доменным именам, понятным пользователям, а не по этим IP-адресам, пользователям нужна система, которая преобразовывает доменные имена в IP-адреса и обратно. Такое преобразование является первоочередной задачей сервисов, называемых Domain Name System (DNS).
Пользователи получают доступ к ресурсам Интернета (например, web-серверу) с помощью соответствующей клиентской программы (например, web-браузера), указывая доменное имя этого ресурса. Для соединения с web-сервером и получения соответствующей web-страницы браузеру необходим IP-адрес этого имени. Браузер вызывает функцию DNS для получения данной информации. Функция отображения доменных имен в IP-адреса, которую предоставляет DNS, называется name resolution (разрешение имен). Протокол, который используется для выполнения функции разрешения имен, называется DNS-протокол.
Функция DNS, описанная выше, включает следующие составные части. Во-первых, необходимо иметь репозиторий для хранения доменных имен и соответствующих им IP-адресов. Так как количество доменных имен весьма велико, то основными требованиями являются масштабируемость и эффективность. Это означает, что данный репозиторий должен быть распределенным. Доменные имена могут также нуждаться в репликации для защиты от разного рода сбоев. Также должно существовать ПО, которое управляет этим репозиторием и предоставляет функцию разрешения имен. Эти две функции (управление репозиторием доменных имен и предоставление сервиса разрешения имен) выполняются компонентой DNS, называемой name-сервер. Существует несколько категорий name-серверов, различаемых по типу обрабатываемых данных и выполняемым функциям. Для доступа к сервисам, предоставляемым name-сервером, от имени пользовательских программ, существует другой компонент DNS, называемый resolver. Существуют две основных категории resolver’ов – рекурсивный name-сервер и stub resolver, различающиеся по своим возможностям. Коммуникационный протокол, различные компоненты DNS, политики, которые определяют конфигурацию этих компонент, процедуры создания, хранения и использования доменных имен составляют инфраструктуру DNS.
Транзакции DNS
Существуют следующие типы DNS-транзакций:
запрос / ответ DNS;зонная пересылка;динамические обновления;DNS NOTIFY.
Опишем каждый из этих типов.
Угрозы для данных DNS
Существует два типа данных DNS: зонные файлы и конфигурационные файлы. Содержимое обоих типов файлов имеет отношение к безопасности. Содержимое конфигурационных файлов является составной компонентой безопасного развертывания сервисов DNS. Рассмотрим угрозы для содержимого DNS-данных только относительно данных зонного файла, а именно следующих аспектов этих данных:
Значения параметров для некоторых ключевых полей в ресурсных записях различных типов.Наличие некоторых ресурсных записей в зонном файле.
Различные типы нежелательного содержимого в зонном файле могут привести к различным воздействиям на безопасность и в дальнейшем к следующим потенциальным угрозам:
Угроза Т6 – неправильное делегирование: данная ошибка возникает, когда FQDN и/или IP-адреса name-серверов были изменены в дочерней зоне, но родительская зона не изменила информацию о делегировании (NS ресурсные записи и связанные с ними записи). В такой ситуации дочерняя зона становится недостижимой (DoS-атака).Угроза Т7 – дрейф зоны и DoS-атака: если поля Refresh, Retry, Expiry и Min TTL в SOA ресурсной записи первичного name-сервера установлены очень большими, это может привести к несоответствию между первичным и вторичным name-серверами. Данная ошибка называется дрейф зоны; ее результатом являются некорректные данные зоны на вторичных name-серверах. Если Refresh и Min TTL поля в SOA RR установлены очень маленькими, вторичный сервер будет инициировать зонные пересылки очень часто. Результатом этого является сильная загрузка как первичного, так и вторичного name-серверов. Такие некорректные данные и возросшая при этом загрузка могут явиться причиной DoS-атаки.Угроза Т8 – информация для атак на определенные цели: ресурсные записи, такие как HINFO и TXT, предоставляют информацию о названии и версиях ПО (например, для таких ресурсов, как web-серверы и почтовые серверы), что дает возможность хорошо осведомленному атакующему использовать известные уязвимости в версиях ПО и запускать атаки на эти ресурсы.
Подходы, обеспечивающие защиту от этих угроз, будут обсуждаться далее.
Угрозы и обеспечение защиты платформы хоста
Угрозы для платформы, на которой выполняется ПО DNS, не отличаются от угроз, с которыми сталкивается любой хост в Интернете. Рассмотрим с точки зрения сервисов DNS эти общие угрозы и их воздействие на DNS:
Угроза Т1: ОС или ПО любого другого приложения, выполняющегося на хосте DNS, может быть уязвимо для таких атак, как переполнение буфера, в результате чего не сможет функционировать сервис разрешения имен.Угроза Т2: стек TCP/IP на DNS-хосте (stub resolver’е, кэширующем или авторитетном name-сервере) может являться целью для атак наводнения пакетами (flooding), в результате чего произойдет нарушение связи. Аналогом такой атаки на прикладном уровне является посылка большого количества ложных DNS-запросов для переполнения авторитетного или рекурсивного name-сервера.Угроза Т3: враждебно настроенный сотрудник, который имеет доступ к локальному сегменту сети (LAN), где расположен DNS, может вызвать атаку, подделывая ARP (spoofing), что разрушит поток сообщений DNS.Угроза Т4: конфигурационный файл (например, resolv.conf и host.conf, named.conf, root.hint и т.п. на UNIX-платформе) может быть испорчен вирусами или червями на уровне платформы или стать объектом неавторизованных модификаций при неадекватной защите на уровне файловой системы, в результате чего будет нарушено взаимодействие между хостами DNS (например, между stub resolver’ом и рекурсивным name-сервером, между рекурсивным name-сервером и авторитетным name-сервером).
Обеспечение защиты и/или уменьшению угроз для платформы хоста DNS состоит в следующем:
использование безопасной ОС;безопасное конфигурирование и развертывание ОС.
Угрозы ПО DNS
Угрозы для самого ПО DNS могут серьезно повлиять на безопасность. Большинство общих проблем, связанных с ПО, следующие:
Угроза Т5: ПО DNS (name-сервер или resolver) могут иметь такие уязвимости, как переполнение буфера, в результате чего станут возможны разного рода атаки типа DoS-атак и получение неавторизованного доступа.
Наилучшими подходами к обеспечению защиты ПО DNS являются следующие:
Выполнение самых последних версий ПО name-сервера или применение соответствующих patches к более ранней версии.Выполнение ПО name-сервера с ограниченными привилегиями.Изолирование ПО name-сервера.Установка выделенного экземпляра name-сервера для каждой функции.Удаление ПО name-сервера с непредназначенных для этого хостов.Создание топологически и географически распределенных name- серверов для защиты от сбоев.Ограничение информации об ИТ-ресурсах, раскрываемой посредством наличия двух различных зонных файлов в одном и том же физическом name-сервере (так называемый split DNS) или развертывая отдельные name-серверы для различных классов клиентов.
и принципы его безопасного развертывания,
Рассмотрим сервис DNS и принципы его безопасного развертывания, а именно следующее:
Основные функции и свойства протокола DNS и инфраструктуры DNS. Также обсудим, что означает безопасность для сервисов DNS.Основные компоненты DNS, такие как зонный файл, содержащий DNS-данные, name-серверы и resolver’ы, которые предоставляют DNS-сервисы.Различные типы DNS-транзакций и типы информации, участвующие в этих транзакциях.Возможные угрозы различным информационным объектам DNS.Способы обеспечения безопасности для сервисов DNS.Обеспечение безопасности для DNS Query/Response транзакций.Способы минимизации информации, раскрываемой посредством сервисов DNS.Способы администрирования, обеспечивающие безопасность DNS.
Запрос / ответ DNS
Это наиболее распространенная транзакция в DNS. Запрос DNS исходит от resolver’а; получателем является авторитетный или кэширующий name-сервер. Наиболее распространенным запросом является поиск ресурсной записи по имени владельца или типу. Ответ может состоять из единственной ресурсной записи, множества ресурсных записей или сообщения о соответствующей ошибке.
Существует два типа запросов: нерекурсивный и рекурсивный. DNS-resolver’ы, которые обычно посылают нерекурсивные запросы, как правило, предоставляют более стабильные ответы, потому что они могут переходить по referral’ам для получения окончательного ответа на запрос. Если они также имеют кэш DNS, они могут обладать достаточно полной информацией о пространстве name-серверов в DNS, полученной из ответов на предыдущие запросы. Это может быть использовано для уменьшения времени ответа на последующие запросы. Рекурсивные запросы обычно посылаются от stub resolver’ов, которые не имеют возможности выполнять сложные операции DNS. Вместо этого они полагаются на вышележащий сервер DNS (обычно name-сервер с кэшем, который посылает нерекурсивные запросы от имени нескольких stub resolver’ов) для выполнения запроса и возврата окончательного ответа.
Запросы DNS посылаются в виде одного UDP-пакета. Ответ обычно также является одним UDP-пакетом, но данные могут быть усечены – в этом случае выполняется повторный запрос с использованием ТСР. UDP используется потому, что он требует меньше вычислительных ресурсов и является более быстрым, чем ТСР, который требует процедуры установления соединения.
Запросы DNS посылаются в открытом виде, но при этом хотелось бы, чтобы полученный ответ являлся корректным и пришел от аутентичного источника. Как результат, для активного атакующего существует возможность перехватить (и изменить) или сфабриковать ответы обратно к клиенту. Далее более детально проанализируем угрозы для транзакций запрос / ответ DNS и предложим соответствующие решения.
Зонная пересылка
Зонная пересылка является способом, которым вторичный (slave) сервер обновляет все содержимое своего зонного файла от первичного (master) сервера. Этот процесс дает возможность вторичному name-серверу поддерживать свой зонный файл в синхронном состоянии с первичным name-сервером. Транзакция зонной пересылки начинается в виде запроса от вторичного name-сервера к первичному name-серверу. Запрос зонной пересылки – в противоположность запросу DNS – запрашивает все ресурсные записи из зоны вместо конкретных ресурсных записей для данного владельца или типа. Этот запрос начинается с вторичного name-сервера либо в ответ на сообщение DNS NOTIFY, либо основываясь на значении элемента данных Refresh в поле RData в Start of Authority (SOA) ресурсной записи.
Зонная пересылка имеет большое отношение к безопасности систем, указанных в DNS, потому что при зонной пересылке раскрывается большее количество информации, чем при обычном DNS-запросе, и потому что при этом возрастает количество ресурсов, требуемых для сообщения. В дальнейшем мы обсудим угрозы для транзакции зонной пересылки и соответствующие механизмы защиты.
Зонный файл
Зонный файл содержит информацию о различных ресурсах в данной зоне. Информация о каждом ресурсе представлена в записи, называемой Resource Record (RR). Так как зона может содержать несколько доменов и несколько типов ресурсов внутри каждого домена, формат каждой RR содержит поля для указания этой информации. В частности, ресурсная запись состоит из следующих основных полей:
Owner name: имя домена или имя ресурса;TTL: время жизни в секундах;Class: существует только один класс IN, обозначающий Интернет;RRType: тип ресурса;RData: информация о ресурсе (зависит от RRType);
Некоторые наиболее часто используемые типы ресурсов:
A: адрес. Ресурсная запись данного типа предоставляет IP-адрес имени хоста;MX: Mail Exchanger. Ресурсная запись данного типа указывает имя хоста почтового сервера для домена;NS: Name Server. Ресурсная запись данного типа указывает имя хоста name-сервера для домена.
В RFC 1035 приведен полный формат допустимых RRType в DNS. Множество ресурсных записей с одним и тем же именем собственника, TTL, классом и RRType называется RRSet. Следовательно, логически зонный файл можно представить состоящим из нескольких RRSets.
Безопасность динамических обновлений с использованием TSIG
Ограничения динамических обновлений, основанные на ключах TSIG, могут быть указаны в BIND 8.2 и более поздних версиях использованием подутверждения allow-update утверждения zone. Аргументом данного утверждения является ключевое слово key, за которым следует имя TSIG-ключа.
zone "example.ru" { type master; file "zonedb.example.ru"; allow-update { key {dhcp-server.example.ru.}; }; };
Заметим, что, хотя строка dhcp-server.example.ru. выглядит как FQDN, на самом деле она обозначает имя TSIG-ключа. В данном примере любой хост, который обладает ключом с именем dhcp-server.example.ru., может посылать запросы динамического обновления (добавления, удаления или модификации ресурсных записей) зонного файла (для зоны example.ru), который расположен на первичном авторитетном name-сервере.
Безопасность платформы
На платформе, на которой выполняется ПО name-сервера, должна быть установлена ОС, удовлетворяющая требованиям безопасности. Большинство инсталляций DNS осуществляется либо на ОС Unix, либо на ОС Windows. В любом случае необходимо гарантировать следующее:
установлены последние обновления ОС;рекомендуемые конфигурации ОС можно найти, например, на сайте CERT/CC. Данные рекомендации основаны на найденных уязвимостях, относящихся к ПО name-сервера. В частности, ОС, на которой выполняется ПО name-сервера, не должна предоставлять никаких других сервисов и, следовательно, должна быть сконфигурирована для получения только трафика DNS. Другими словами, должны быть разрешены только входящие и исходящие сообщения на порты 53/UDP или 53/TCP.
Безопасность ПО DNS
Обеспечение безопасности ПО DNS включает выбор версии, установку последних обновлений, выполнение ПО с ограниченными привилегиями, ограничение других приложений, выполняющихся под управлением данной ОС, создание выделенных экземпляров DNS-сервера для выполнения каждой функции и ограничение информации, раскрываемой данными зонного файла или выполнением двух экземпляров ПО name-серверов, которые обслуживают различные категории клиентов.
Безопасность транзакций DNS
Ранее были перечислены угрозы, цели безопасности и способы обеспечения защиты для различных транзакций DNS. Сейчас рассмотрим шаги, необходимые для реализации этих способов защиты. Перечислим типы способов обеспечения защиты:
Ограничение участников транзакций на основе IP-адреса. В данном случае name-серверы и клиенты, участвующие в DNS-транзакциях, ограничены доверенным множеством хостов, которые указаны по их IP-адресам в соответствующих утверждениях управления доступом. Защита, которая обеспечивается утверждениями управления доступом, основанными на IP-адресе, может быть подвергнута таким атакам, как IP-spoofing (подделка IP-адреса). Следовательно, данное решение не рекомендуется для DNS-транзакций запросов и ответов, зонной пересылки и динамических обновлений, которые имеют высокую степень угроз. Однако для транзакции DNS NOTIFY, для которой существует только угроза ложного уведомления, управление доступом, основанное на IP-адресе, вполне приемлемо. Хотя данное решение и не рекомендуется в общем случае, описание механизмов управления доступом, использующих IP-адреса, будет приведено далее, потому что аналогичные утверждения применяются для идентификации хостов на основе поименованных ключей, которые реализуют защиту транзакций, используя коды аутентификации сообщений (МАС), основанные на хэшах. Данный подход реализован для всех транзакций DNS.
Защита транзакций с помощью кодов аутентификации сообщений, основанных на хэшах (спецификация TSIG). В данном способе защита транзакции обеспечивается созданием и проверкой кодов аутентификации сообщений, основанных на хэш-функциях (НМАС ). Так как эти коды хранятся в специальной ресурсной записи, тип которой есть TSIG, описание защиты DNS-транзакций с использованием НМАС называется TSIG . Спецификации TSIG даны в RFC 2845 и 3007. Применение спецификаций TSIG для защиты транзакций зонных пересылок и динамических обновлений будет изложено далее.
Защита транзакций с помощью цифровых подписей (спецификация DNSSEC). Данный способ, который называется расширениями безопасности DNS (DNSSEC), описан в семействе RFC 4033, 4034 и 4035. Ключевыми сервисами, предоставляемыми DNSSEC, являются аутентификация исходных данных и обеспечение их целостности. DNSSEC в основном используется для обеспечения безопасности транзакций запросов и ответов DNS. Проблемы, связанные с развертыванием DNSSEC, будут рассмотрены далее.
Безопасность зонных пересылок с использованием TSIG
Для пары серверов, участвующих в транзакциях зонных пересылок, указывается, что они должны использовать ключ, определенный в утверждении key. Такая пара обычно состоит из первичного name-сервера и вторичного name-сервера. Первичный name-сервер конфигурируется таким образом, чтобы принимать запросы зонной пересылки только от вторичных name-серверов, которые посылают МАС с использованием поименованного ключа, передаваемого в сообщении запроса зонной пересылки. Конфигурация создается с использованием подутверждения allow-transfer в утверждении zone. Пример подутверждения allow-transfer, которое указывает, что первичный name-сервер должен разрешать запросы зонной пересылки только для зоны example.ru от name-серверов, использующих ns1-ns2.example.ru ключ, выглядит следующим образом:
zone "example.ru" { type master; file "zonedb.example.ru"; allow-transfer { key {ns1-ns2.example.ru}; }; };
Вторичному name-серверу указывается использовать ключ ns1-ns2.example.ru в запросе зонной пересылки к первичному name-серверу, задействуя утверждение server.
Использование расчлененных зонных файлов
Авторитетные name-серверы организации получают запросы как от внешних, так и от внутренних клиентов. Во многих случаях внешние клиенты должны получать ресурсные записи, которые относятся только к публичным сервисам, таким, как web-сервер, почтовый сервер и т.п. Внутренние клиенты должны получать ресурсные записи, которые относятся как к публичным сервисам, так и к внутренним хостам. Следовательно, зонная информация, которая содержит эти ресурсные записи, может быть разделена на два представления, каждое из которых заключает в себе информацию, предназначенную для определенного типа клиентов: один для внешних клиентов, другой – для внутренних. Такой способ реализации зонного файла называется split DNS.
Рекомендация:
Для реализации split DNS должно быть как минимум два представления, еще называемых views. Одно должно содержать информацию, предназначенную исключительно для разрешения имен для хостов, которые расположены в локальной сети. Оно также может содержать множества ресурсных записей для обслуживания запросов из внешней сети. Другое представление или view должно обеспечивать разрешение имен только для хостов, расположенных во внешней сети или в DMZ, и не предоставлять данный сервис ни для каких хостов, расположенных во внутренней сети.
Для конфигурирования split DNS в BIND следует использовать специальное утверждение в конфигурационном файле BIND. Например, для конфигурирования авторитетного view в зоне sales.mycom.ru для внутренних хостов следует использовать утверждение
view "insider" { match-clients { internal_hosts; }; recursion yes; zone sales.mycom.ru { type master; file "sales_internal.db"; }; };
В данном утверждении указывается, что файл sales_internal.db содержит авторитетную информацию для зоны sales.mycom.ru, и вводится ограничение, что данная информация может быть запрошена со списка адресов, перечисленных в internal_hosts. Как задать данный список, будет объяснено ниже. Чтобы сконфигурировать view в некоторой зоне только для обслуживания запросов от внешних хостов, используется следующее утверждение в конфигурационном файле:
view "outsider" { match-clients { any }; match-destination { public_hosts; }; recursion no; zone sales.mycom.ru { type master; file "sales.external.db"; }; };
Данное утверждение очень похоже на предыдущее, за исключением того, что файл с view зоны есть sales.external.db и список клиентов указан как any, — это означает, что запросы могут быть как извне, так и изнутри сети. Вместе эти утверждения позволяют внутренним клиентам видеть как внутренние, так и внешние хосты, а внешние хосты, расположенные вне данной сети, могут видеть только информацию DNS, содержащуюся во внешнем view зоны, где адрес получателя соответствует адресам, перечисленным в public_host.
Использование самой последней версии ПО name-сервера
Каждая последующая версия ПО name-сервера, (особенно это касается BIND), обычно лишена уязвимостей, найденных в более ранних версиях. Если установлены старые версии, то эти уязвимости могут использоваться атакующим, чтобы осуществить атаку. Таким образом, хорошей практикой считается выполнение самой последней версии BIND, потому что теоретически она самая безопасная. Но даже если используется ПО самой последней версии, небезопасно выполнять его в режиме "по умолчанию". Администратор должен свободно владеть всеми установками безопасности для этой последней версии.
В некоторых случаях невозможен немедленный переход на самую последнюю версию BIND. В этой ситуации следует понять уязвимости, обнаруженные в существующей версии, и использовать соответствующие обновления, относящиеся к безопасности.
Рекомендации:
При инсталляции версии ПО name-сервера администратор должен сделать необходимые изменения в конфигурационных параметрах, чтобы использовать преимущества новых возможностей, связанных с безопасностью.
Выполнить следующие действия:
Подписаться на список рассылки ISC, называемый "bind-announce". Периодически проверять найденные уязвимости BIND на http://www.isc.org/product/BIND/bind-security.html. Проверять базу данных уязвимостей CERT/CC на http://www.kb.cert.org/vuls/ и NIST NVD базу данных на http://nvd.nist.gov/.
Использования отдельных name-серверов для различных типов клиентов
Вместо того чтобы иметь одно и то же множество авторитетных name-серверов, обслуживающих различные типы клиентов, можно развернуть два различных множества авторитетных name-серверов. Одно множество, называемое external name-серверы, может быть расположено внутри DMZ; это должны быть только те name-серверы, которые доступны внешним клиентам и которые содержат ресурсные записи, относящимся к хостам с публично доступными сервисами (web-серверы, которые обрабатывают внешние web-страницы или предоставляют В2С-сервисы, почтовые серверы и т.п.). Другое множество, называемое internal name-серверы, расположено за firewall’ом и должно быть сконфигурировано таким образом, чтобы эти серверы не были доступны извне и, следовательно, предоставляли сервисы разрешения имен исключительно для внутренних клиентов. Целью обеих архитектур (т.е. создания двух различных множеств name-серверов и split DNS) является предотвращение раскрытия IP-адресов внутренних хостов.
Изоляция ПО name-сервера
Даже если ПО DNS (например, BIND) выполняется на безопасной ОС, уязвимости в другом ПО на данной платформе могут нарушить безопасность ПО DNS. Следовательно, необходимо гарантировать, что платформа, на которой выполняется ПО DNS, не содержит программ, которые не являются необходимыми для функционирования DNS.
Конфигурирование более точных ограничений динамического обновления с использованием TSIG-ключей
Подутверждение allow-update определяет ограничения динамического обновления, которые основаны на отправителях запросов динамических обновлений (конкретное множество хостов, идентифицируемых по IP-адресу или обладающих TSIG-ключом), но не на содержимом зонных записей. Для указания ограничений доступа (grant или deny) к динамическим обновлениям, основанным на комбинации имен домена или поддомена и типов ресурсных записей (A, MX, NS и т.п.), BIND 9 и более поздние версии предоставляют подутверждение update-policy в утверждении zone. Эти ограничения в подутверждении update-policy основаны на TSIG-ключе. Другими словами, подутверждение update-policy указывает, каким TSIG ключам (держателям ключей) разрешено выполнять динамические обновления для каких доменов или поддоменов и типов ресурсных записей внутри данного домена или поддомена.
Общая форма update-policy утверждения следующая:
update-policy { (grant | deny) TSIGkey nametype name [type] };
где семантика каждого компонента утверждения такова:
grant / deny – разрешить / запретить динамическое обновление для комбинации, которая следует далее.
TSIGkey – имя TSIG-ключа, используемого для аутентификации запроса обновления.
nametype – может быть одним из следующих значений, с соответствующей семантикой:
name – ограничение, применяемое к имени домена, которое указано в следующем поле name.
subdomain – ограничение, применяемое к поддоменам домена, который указан в следующем поле name.
wildcard – ограничение, применяемое к множеству доменов, которые указаны с использованием wildcard синтаксиса (например, *) в следующем поле name.
self – ограничение, применяемое к домену, который является тем же самым, что и в поле TSIGkey (например, имя домена, чьи записи являются модифицируемыми, такое же, что и у ключа, используемого для аутентификации запроса динамического обновления). При таком использовании содержимое поля name становится лишним, но, тем не менее, должно использоваться в утверждении (т.е. поле name не может быть пустым).
name – применяется для указания имени домена. Используемый синтаксис и домены, которые указывает данный параметр, основаны на значении, заданном в поле nametype (например, если поддомен является значением поля nametype, то все поддомены используемого имени домена охватываются данным утверждением).
type – необязательное поле, которое может содержать любой существующий тип ресурсных записей (за исключением NSEC-типа) или wildcard тип ANY (ANY означает все типы ресурсных записей, за исключением NSEC-типа). Если параметр опущен, то это означает все типы ресурсных записей, за исключением SOA, NS, RRSIG и NSEC. Также возможно использование нескольких типов ресурсных записей, разделенных пробелами (например, A NS).
Примеры update-policy утверждений и связанная с ними семантика приведены ниже.
Предположим, что существует домен sales.example.ru внутри example.ru и что name-сервер использует TSIG ключ, который имеет то же самое имя, что и имя его домена (т.е. sales.example.ru). Все динамические обновления от sales.example.ru могут быть ограничены ко всем ресурсным записям данного домена следующим образом:
zone "example.ru" { type master; file "zonedb.example.ru"; update-policy { grant sales.example.ru. self sales.example.ru.; }; };
Все динамические обновления от sales.example.ru могут быть ограничены только типами ресурсных записей A и MX данного домена следующим образом:
zone "example.ru" { type master; file "zonedb.example.ru"; update-policy { grant sales.example.ru. self sales.example.ru. A MX; }; };
Конфигурирование ограничений перенаправления динамических обновлений с использованием ключей TSIG
Динамическим обновлениям разрешено копирование зонного файла на первичный авторитетный name-сервер только потому, что он является "writable". При этом автоматически не предполагается, что только первичный авторитетный name-сервер может принимать запросы динамического обновления. В BIND 9.1.0 и более поздних версиях разрешается вторичным name-серверам принимать запросы динамического обновления и перенаправлять их первичному авторитетному name-серверу. В данном сценарии, если не существует ограничений, основанных на идентификации хостов, с которых вторичный name-сервер может перенаправлять такие запросы динамического обновления, это эквивалентно обходу ограничений динамического обновления, указанным в первичном name-сервере, потому что запрос может исходить с любого хоста к вторичному name-серверу и перенаправляться на первичный name-сервер. Для решения данной проблемы было добавлено новое подутверждение allow-update-forwarding в версии BIND, которые имеют возможность перенаправления динамических обновлений. Пример такого allow-update-forwarding утверждения с использованием TSIG-ключей следующий:
zone "example.ru" { type slave; file "backupdb.example.ru"; allow-update-forwarding { key {dhcp-server.example.ru.}; }; };
Ограничение рекурсивных запросов (специальный случай DNS Query/Response)
Авторитетный name-сервер обеспечивает сервис разрешения имен для клиента, исходя из своих собственных данных. Следовательно, конфигурирование авторитетного name-сервера должно быть сделано таким образом, чтобы он мог принимать запросы от любых хостов. Обеспечение безопасности авторитетного name-сервера состоит в выключении возможности рекурсивного запроса, чтобы этот сервер не испортил свой кэш, запрашивая другие (возможно, скомпрометированные) name-серверы. Локальный рекурсивный name-сервер может быть сконфигурирован таким образом, чтобы принимать запросы только от внутренних хостов, что защитит его от DoS-атак, а также от порчи кэша. Однако возможны ситуации, когда экономически нежелательно иметь выделенные серверы для авторитетного сервиса и сервиса разрешения имен, и рекурсивный name-сервер должен выполняться как авторитетный сервер для одной или более зон. В такой ситуации возможны следующие стратегии с использованием BIND 9.х name-сервера:
Ограничение всех принимаемых запросов конкретным множеством IP-адресов внутренних клиентов и после этого перекрытие данного множества только для авторитетных зон, чтобы любой DNS-клиент мог получать информацию о ресурсах в данной зоне.
Ограничение рекурсивных запросов конкретным множеством IP-адресов внутренних клиентов с помощью соответствующей конфигурационной опции.
Создание различных ответов для различных клиентов с помощью определения views.
Ограничение на уровне сервера с перекрытием для авторитетных зон
В этом случае определяется допустимое множество внутренних клиентов, которые могут передавать запросы к name-серверу. Для этого соответствующее acl утверждение таково:
acl "internal_hosts" { 192.158.43.3, 192.158.43.6, 192.158.44.56; };
Опцией на уровне сервера следует указать ограничение, чтобы запросы могли исходить только от данных клиентов:
options { allow_query { internal_hosts; }; };
Опция может быть перекрыта указанием зон, для которых данный name-сервер является авторитарным (тем самым разрешая запросы, касающиеся ресурсов в данной зоне от всех клиентов):
zone "example.ru" { type master; file "zonedb.example.ru"; allow_query { any; }; };
Ограничение всех рекурсивных запросов конкретным множеством IP-адресов
Ограничение на уровне сервера:
options { allow_recursion { internal_hosts; }; };
Ограничение рекурсии с помощью views
Цель создания views состоит в логической комбинации клиентов (на основе IP-адресов) и зон, для которых будут поддерживаться рекурсивные запросы и для которых они не будут поддерживаться. В следующем примере view recursion_view дает возможность определить область IP-адресов и зон, которым разрешено передавать рекурсивные запросы; no_recursion_view означает запрещение рекурсии.
view recursion_view { match-clients ( internal_hosts; }; recursion yes; }; view no_recursion_view { math-client { any; }; recursion no; };
Ограничение участников транзакции динамического обновления
Динамические обновления зонного файла могут осуществляться только для зонного файла, находящегося на первичном name-сервере зоны. По умолчанию динамические обновления отключены как в BIND 8, так и в BIND 9. Динамические обновления управляются использованием одного из следующих двух утверждений в BIND:
allow-update;
update-policy (доступно только в версиях BIND 9).
Эти утверждения могут быть указаны только на уровне зоны, а не на уровне сервера. Следовательно, они являются подутверждениями внутри утверждения zone. Подутверждение allow-update дает возможность указать ограничения динамического обновления на основе IP-адресов и разделяемого секрета (также называемого TSIG key). Сначала обсудим использование allow-update с помощью указания только IP-адресов, а затем — использование утверждения allow-update с TSIG-ключами.
Утверждение update-policy дает возможность указать ограничения динамического обновления только на основе TSIG-ключей, при этом ограничения могут быть указаны более детально. Подутверждение allow-update определяет права доступа, касающиеся модификаций, ко всем записям в зоне. Подутверждение update-policy может быть использовано для ограничения прав доступа по модификации к одному или более типам ресурсных записей (например, A ресурсные записи).
Для использования утверждения allow-update должен быть создан список соответствующих адресов. Команда для создания ACL DU_Allowed_List с одним IP-адресом следующая:
acl "DU_Allowed_List" { 192.249.12.21; };
ACL DU_Allowed_List (содержащий IP-адреса хостов, которым разрешено посылать запросы динамического обновления для изменения содержимого зоны example.ru) используется внутри подутверждения allow-update утверждения zone следующим образом:
zone "example.ru" { type master; file "zonedb.example.ru"; allow-update { DU_Allowed_List; }; };
Запросы динамического обновления обычно исходят от таких хостов, как DHCP-серверы, которые динамически связывают IP-адреса с хостами. После того, как они назначат IP-адрес новому хосту, им нужно сохранить информацию отображения доменного имени на IP-адрес (созданием A ресурсной записи) и отображения адреса на доменное имя (созданием PTR ресурсной записи) в первичном авторитетном name-сервере для зоны. Создание данной информации происходит посредством динамических обновлений.
Ограничение участников транзакции DNS NOTIFY
После того как зонные пересылки между серверами установлены, хорошо бы гарантировать, что вторичные name-серверы будут информироваться об изменениях в данных зонного файла посредством получения уведомления. По умолчанию сообщение уведомления посылается всякий раз, когда первичный name-сервер определил, что было сделано изменение в зонном файле. Он посылает сообщение DNS NOTIFY каждому name-серверу, перечисленному в NS-множестве ресурсных записей в зоне, потому что эти серверы считаются вторичными name-серверами зоны. Администратор DNS должен оставить выполнение этой транзакции, потому что это позволяет быстро распространять обновления на вторичные name-серверы. Однако, если администратор хочет выключить данную функциональность для конкретной зоны, следует использовать подутверждение notify в утверждении zone для данной зоны:
zone "example.ru" { type master; notify no; file "zonedb.example.ru"; };
Если существуют дополнительные серверы, на которые администратор хочет посылать сообщение DNS NOTIFY (например, "невидимый" вторичный сервер), должно быть добавлено подутверждение also-notify в утверждение zone, и IP-адреса дополнительных серверов должны быть указаны в качестве значений параметров следующим образом:
zone "example.ru" { type master; also-notify { 192.168.25.2; }; file "zonedb.example.ru"; };
Получатель сообщения DNS NOTIFY, которым является вторичный name-сервер, по умолчанию разрешает получать сообщения уведомления только от первичного name-сервера. То, что данный name-сервер является вторичным для первичного name-сервера, указывается посредством подутверждения masters в утверждении zone. Если вторичный name-сервер хочет получать сообщения уведомления также и от других серверов, следует добавить подутверждение allow-notify в утверждение zone, и соответствующие IP-адреса этих серверов:
zone "example.ru" { type slave; allow-notify { 193.168.25.4; }; file "zonebak.example.ru"; masters { 192.168.25.1; }; };
Ограничение участников транзакции DNS Query/Response
Рассмотрим пример использования подутверждения allow-query для указания ограничений для транзакции Query / Response, определяя допустимые IP-адреса / подсети в запросах DNS) как на уровне сервера, так и на уровне зоны (для зоны example.ru):
options { allow-query {254.10.20.10; 239.10.30.0/24; }; }; zone "example.ru." { type master; file "zonedb.example.ru"; allow-query {192.249.249.1; 192.249.249.4; }; };
Указывая список IP-адресов или IP-префиксов внутри утверждений options или zone, можно внести путаницу в конфигурационный файл. Более того, список IP-адресов и IP-префиксов может быть одним и тем же для многих утверждений управления доступом внутри name-сервера, и ошибка может возникнуть, если сделано какое-то одно добавление или удаление в данный список. Чтобы избежать таких проблем, в BIND существует способ создания поименованных списков адресов, которые называются access control lists (ACLs). Эти ACLs могут использоваться в тех местах, где допустимо использование списка IP-адресов или IP-префиксов (в качестве аргумента списка соответствующих адресов) в утверждениях управления доступом.
ACLs создаются с использованием утверждения acl в BIND 9.х. Общий синтаксис утверждения acl следующий:
acl acl-list-name { address_match_list };
acl-list-name есть определенная пользователем строка (например, "internal_hosts"). Address_match_list может быть списком IP-адресов, префиксами IP-адресов (обозначающих подсети) или криптографическими ключами. Пример утверждения acl, который использует IP-адрес и подсеть в address_match_list, приведен ниже. В примере 254.10.20.10 обозначает IP-адрес хоста, IP-префикс 239.10.30.0/24 обозначает подсеть класса С.
acl "internal_hosts" { 254.10.20.10; 239.10.30.0/24; };
Можно использовать ACL internal_hosts в тех местах, где используется список IP-адресов или IP-префиксов в утверждениях options и zone следующим образом:
options { allow-query { internal_hosts; }; }; zone "example.ru." { type master; file "zonedb.example.ru"; allow-query { internal_hosts; }; };
Параметр списка соответствующих адресов в утверждении управления доступом может содержать любое из следующих значений:
IP-адрес или список IP-адресов;IP-префикс или список IP-префиксов;ACLs;комбинация перечисленных выше значений.
Определение ACLs является важным элементом при конфигурировании ограничений транзакций DNS. Следовательно, администратор первым делом должен задать ACLs, относящиеся к различным транзакциям DNS.
Рекомендация:
Необходимо, чтобы администратор создал поименованный список доверенных хостов (или черный список хостов) для каждого типа транзакций DNS. В общем случае следует рассмотреть следующие категории хостов для включения их в соответствующий ACL:
хосты в DMZ, доступные во всех зонах предприятия;
все вторичные name-серверы, которым разрешено инициировать зонные пересылки;
внутренние хосты, которым разрешено выполнять рекурсивные запросы.
Дополнительно к IP-адресам, IP-префиксам или ACL, параметр списка соответствующих адресов в утверждениях управления доступом может принимать следующие специальные значения:
none: нет соответствующих хостов;
any: все хосты;
localhost: соответствует всем IP-адресам сервера, на котором выполняется name-сервер.
localnets: соответствует всем IP-адресам и маскам подсетей сервера, на котором выполняется name-сервер.
Приведем несколько примеров команд для создания ACLs и использования ACLs в утверждениях options и zone:
acl "local_hosts" { 254.10.20.10; 239.10.30.0/24; }; acl "fake-net" { 0.0.0.0/8; 1.0.0.0/8; {; options { allow-query { any; }; blackhole { fake-net; }; }; zone "example.ru" { type master; file "zonedb.example.ru"; allow-query {local_hosts; }; };
Во фрагменте named.conf, приведенном выше, определены два ACLs, local_hosts и fake_net. На уровне сервера разрешены DNS-запросы с любого хоста. Никакие транзакции не разрешены с хостов, включенных в fake-net. Запросы для зоны example.ru могут быть инициированы только хостами, включенными в ACL local_hosts, потому что любое ограничение, указанное в утверждении zone, перекрывает ограничение, указанное в утверждении options.
Ограничение участников транзакции зонной пересылки
Авторитетные name-серверы (особенно первичные) должны быть сконфигурированы с утверждением управления доступом allow-transfer, содержащим список хостов, с которых запросы зонной пересылки могут приниматься. Это ограничивает DoS-атаки и использование возможных ошибок (exploits), а также неконтролируемое распространение информации о внутренних ресурсах. Единственными name-серверами, которым необходимо периодическое обновление своих зонных файлов, являются вторичные name-серверы. Следовательно, зонная пересылка от первичного name-сервера должна разрешаться только к вторичным name-серверам. Зонная пересылка должна быть полностью запрещена на вторичных name-серверах. Аргумент списка соответствующих адресов в подутверждении allow-transfer должен состоять из IP-адресов вторичных name-серверов, которые указаны в NS множества ресурсных записей, и "невидимых" вторичных name-серверов, которые указаны только в этом подутверждении.
Команда для создания ACL valid_secondary_NS с IP-адресами трех вторичных name-серверов следующая:
acl "valid_secondary_NS" { 224.10.229.5; 224.10.235.6; 224.10.245.25; };
Подутверждение allow-transfer может быть использовано в утверждении zone и в утверждении options. Если оно используется в утверждении zone, то ограничивает зонную пересылку для данной зоны; если используется в утверждении options, ограничивает зонную пересылку для всех зон в name-сервере.
Подутверждение allow-transfer на уровне сервера является следующим:
options { allow-transfer { valid_secondary_NS; }; };
Подутверждение allow-transfer на уровне зоны является следующим:
zone "example.ru" { type master; file "zonedb.example.ru"; allow-transfer { valid_secondary_NS; }; };
Предыдущие утверждения используются на первичных name-серверах. На вторичных и невидимых name-серверах зонная пересылка должна быть запрещена, как показано ниже:
zone "example.ru" { type slave; masters { 224.239.5.1 }; file "zonedb_bak.example.ru"; allow-transfer { none; }; };
Ограничение участников транзакций на основе IP-адреса
Некоторые реализации name-сервера, такие как BIND 9.x, предоставляют утверждения для управления доступом, с помощью которых можно указать хосты, которые могут участвовать в конкретной DNS-транзакции. Хосты могут быть указаны по их IP-адресам или указанием их IP-подсети (называемой IP-префиксом) в данных утверждениях.
Список, содержащий эти IP-адреса и/или IP-префиксы, называется списком соответствия адресов. Список соответствия адресов может быть создан на основе не только IP-адресов, но и IP-префиксов. Этот список используется в качестве аргумента в различных утверждениях управления доступом, которые определены в конфигурационных файлах BIND. Существуют отдельные утверждения управления доступом для каждого типа транзакции DNS. Синтаксис таких утверждений и транзакции DNS, для которых они используются, приведен ниже.
| allow-query {address_match_list } | DNS Query/Response |
| allow-recursion {address_match_list } | Рекурсивный запрос |
| allow-transfer {address_match_list } | Зонная пересылка |
| allow-update {address_match_list } | Динамическое обновление |
| allow-update-forwarding {address_match_list } | Динамическое обновление |
| allow-notify (address_match_list } | DNS NOTIFY |
| blackhole {address_match_list } | Хосты, попавшие в черный список |
Цель каждого из этих утверждений управления доступом состоит в следующем:
allow-query: указывает список хостов, которым разрешено запрашивать все зоны name-сервера или конкретную зону внутри name-сервера.
allow-recursion: указывает список хостов, которым разрешено создавать рекурсивные запросы к name-серверу для всех зон или для конкретной зоны, обслуживаемой name-сервером.
allow-transfer: указывает список хостов, которым разрешено инициировать запросы зонной пересылки к name-серверу для всех зон или для конкретной зоны внутри name-сервера. Данное утверждение обязательно требуется в конфигурации первичного name-сервера.
allow-update: указывает список хостов, которым разрешено инициировать запросы динамического обновления.
allow-update-forwarding: указывает список хостов, которым разрешено перенаправление запросов динамического обновления (независимо от того, кто является источником запроса).
allow-notify: указывает список хостов, с которых можно принимать сообщения DNS NOTIFY, говорящих об изменениях в зонном файле. Данный список относится только к конфигурации вторичного name-сервера.
blackhole: указывает список хостов, которые входят в черный список (запрещен доступ) для инициализации любых транзакций с данным name-сервером.
Перечисленные утверждения управления доступом являются в действительности подутверждениями, которые могут использоваться в контексте утверждений options и zone в конфигурационном файле named.conf в BIND 9.x. Когда они используются внутри утверждения zone, они определяют ограничения управления доступом для соответствующей транзакции для указанной зоны. Когда они используются как часть утверждения options, они определяют ограничения управления доступом для соответствующей транзакции для всего name-сервера, который может обслуживать несколько зон.
Определение ключей для взаимодействующих name-серверов
Ключ, созданный с использованием утилиты dnssec-keygen, должен быть указан внутри конфигурационных файлов named.conf двух взаимодействующих серверов (обычно это один первичный name-сервер и один вторичный name-сервер). Это достигается использованием утверждения key в BIND:
key "ns1-ns2.example.ru." { algorithm hmac-md5; include "/var/named/keys/secretkey.conf"; };
где файл secretkey.conf содержит слово secret и реальную строку ключа:
secret "Mdkhhladasdka;"
Поддельный или выдуманный ответ
Поддельный или выдуманный ответ – это ответ, который отличается от того, который посылает законный авторитетный name-сервер. Поддельный ответ может быть получен от:
скомпрометированного авторитетного name-сервера (на запросы, исходящие от рекурсивного name-сервера);испорченного кэша кэширующего name-сервера (на запросы, исходящие от stub resolver’а).
Поддельный ответ может быть создан в результате:
атаки на уровне ОС с использованием уязвимостей на уровне стека протоколов TCP/IP. Скомпрометированный name-сервер, контролируемый противником, посылает ложные ответы на запросы от рекурсивных name-серверов;
перехвата пакета. В этом случае атакующий подсматривает запрос, создает и посылает ответ, подделываясь под name-сервер, до того, как реальный ответ от законного авторитетного name-сервера достигнет рекурсивного name-сервера.
Последствия для систем, которым требуются сервисы name-сервера, имеющего испорченный кэш или скомпрометированный зонный файл:
DoS-атака. Если некоторые важные ресурсные записи, такие как А, NS, MX ресурсные записи, подделаны, система, которая запрашивает данную информацию, никогда не сможет установить соединение с требуемым хостом.
Перенаправление клиента на неверный адрес. Перенаправление клиента на неверный адрес осуществляется с использованием выборочно испорченных ресурсных записей, у которых элемент RDATA содержит некоторое имя. Примерами таких записей являются CNAME, NS и MX. Информация разрешения имени (т.е. IP-адрес) для имен, содержащихся в этих записях, отыскивается в множестве ресурсных записей, называемых glue (склеенные) записями. Обычно запрашивающий эту информацию клиент получает склеенные записи с помощью последовательных запросов (также называемых triggered-запросами). Ответы на такие запросы также могут быть скомпрометированы атакующим с помощью вставки поддельных записей. Атакующий может ввести имена, выбранные им, в часть RDATA ресурсных записей; затем атакующий может вставить IP-адреса серверов (выбранные атакующим) в соответствующие склеенные записи, которые передаются в качестве ответа на последовательные запросы. Данный тип атаки на два множества соответствующих ответов называется атакой на цепочку имен. Общий эффект от этого состоит в неправильном перенаправлении клиентов, которые используют сервисы данного name-сервера. Результатом будет перенаправление пользователей к узлам атакующего, что может дать возможность атакующему перехватить разного рода чувствительную информацию.
Сетевое и географическое расположение авторитетных name-серверов
Большинство предприятий имеют авторитетный первичный name-сервер и авторитетные вторичные name-серверы. Важно, чтобы эти авторитетные name-серверы были расположены в различных сетевых сегментах. Такое расположение гарантирует доступность авторитетного name-сервера не только в ситуациях, когда некоторый роутер или коммутатор (switch) даст сбой, но также и при событиях, включающих атаки на весь сетевой сегмент. В дополнение в сетевому разнесению, авторитетные name-серверы должны быть также разнесены географически. Другими словами, в дополнение к размещению в разных сетевых сегментах, авторитетные name-серверы не должны располагаться в одном и том же здании. Один из подходов состоит в том, что организация размещает некоторые name-серверы в своем здании, а другие у Интернет-провайдера или в организациях партнеров.
Рекомендация:
Авторитетные name-серверы предприятия должны быть как географически распределенными, так и распределенными в смысле сетевой топологии. Сетевая распределенность гарантирует, что все серверы не будут расположены за одним и тем же роутером или коммутатором в одной подсети. Географическая распределенность гарантирует, что не все name-серверы будут находиться в одном и том же физическом месте и в любом случае будет доступен по крайней мере один авторитетный name-сервер.
Создание безопасного окружения для сервисов DNS
Создание безопасной конфигурации для окружения DNS-хостинга должно обеспечивать следующее:
безопасность платформы, на которой выполняется DNS;безопасность ПО DNS;управление содержимым зонного файла.
Рассмотрим рекомендации для каждого перечисленного выше пункта.
Создание ключа
Чтобы обеспечить возможность выполнять аутентификацию зонных пересылок (запросов и ответов), необходимо создать ключи для каждой пары name-серверов. Ключ также может использоваться для обеспечения безопасности других транзакций, таких как динамические обновления, запросы и ответы DNS. Битовая строка ключа, которая создается большинством утилит генерации ключа, используемых с DNSSEC, указывается в виде Base64. Программой, которая создает ключ в BIND 9.х, является dnssec-keygen. Приведем пример вызова этой программы для создания секретного ключа. Следует заметить, что программа может также создавать и другие типы ключей, например, открытый и закрытый ключи:
dnssec-keygen –a HMAC-MD5 –b 128 –n HOST ns1-ns2.example.ru
где параметры команды означают следующее:
-a: название алгоритма хэширования, который будет использоваться (HMAC-MD5).
-b: длина ключа (128 бит).
-n: тип ключа (HOST).
Последний параметр: имя ключа (ns1-ns2.example.ru).
Программа dnssec-keygen создает следующие файлы, содержащие строку ключа:
Kns1-ns2.example.ru.+157+34567.key Kns1-ns2.example.ru.+157.34567.private
Когда программа создает пару ключей (открытый и закрытый), файл с расширением key будет содержать строку открытого ключа, а файл с расширением private будет содержать закрытый ключ. Так как в нашем случае создается только секретный ключ, строки ключа в обоих файлах будут одинаковыми. Строка ключа из любого из этих файлов затем копируется в файл, называемый файлом ключа. Данный файл указывается в утверждении include внутри утверждения key.
Удаление некоторых ресурсных записей
Кроме вставки поддельных данных в ответ, атакующий может удалить некоторые ресурсные записи из ответа. Результатом будет невозможность выполнить разрешение имени, что приведет в дальнейшем к DoS-атаке.
Удаление ПО name-сервера с не предназначенных для этого хостов
ПО DNS не должно выполняться или присутствовать на хостах, которые не предназначены для функционирования на них name-серверов. Вероятность такого присутствия существует, потому что ПО DNS BIND во многих версиях Unix (включая версии Solaris и Linux) инсталлировано по умолчанию. Следовательно, необходимо проверить наличие инсталляций BIND на рабочих станциях и серверах и удалить его с тех хостов, которые не предназначены для функционирования в качестве name-серверов.
Угрозы для динамических обновлений и способы обеспечения защиты
Динамические обновления означают, что клиенты могут делать изменения в данных зоны авторитетного name-сервера в реальном режиме времени. Клиентами, которые обычно выполняют динамические обновления, являются СА-серверы, DHCP-серверы или Интернет Multicast Address серверы. Рассмотрим некоторые основные угрозы, основанные на том факте, что динамические обновления означают модификацию данных, передаваемых по сети.
Угроза Т14 – неавторизованные модификации: неавторизованные модификации могут иметь несколько опасных последствий для содержимого зоны. Это включает:
(i) добавление незаконных ресурсов (новый FQDN и новые ресурсные записи в файл зоны);
(ii) удаление законных ресурсов (весь FQDN или конкретные ресурсные записи);
(iii) изменение информации делегирования (NS-ресурсные записи, ссылающиеся на дочерние зоны).
Угроза Т15: данные в запросе динамического обновления могут быть подделаны.
Угроза Т16 – replay-атаки: сообщения запроса обновления могут быть перехвачены и повторены позднее, тем самым вызвав ненужные модификации.
Угрозы Т14 и Т15 могут быть ликвидированы аутентификацией участников и обеспечением способов определения подделанных сообщений. Так как данные цели безопасности в случае зонной пересылки могут быть решены TSIG-механизмом, тот же самый TSIG-механизм используется для защиты динамических обновлений. TSIG также обеспечивает способ защиты от replay-атак (угроза Т16) включением поля с отметкой времени в запрос динамического обновления таким образом, чтобы отметка времени также была аутентифицирована. Данная отметка времени дает возможность серверу определить своевременность запроса динамического обновления, используя ограничения времени, указанные в конфигурации.
Угрозы для транзакций DNS
Угрозы транзакциям DNS зависят от типа транзакции. Запросы и ответы разрешения имен (DNS Query/Response) между DNS-клиентами (stub resolver или рекурсивным name-серверы) и DNS-серверами (кэширующий и авторитетный name-сервер) могут проходить через любые узлы в Интернете; следовательно, угроз для этих транзакций намного больше, чем для транзакций зонной пересылки, динамического обновления или DNS NOTIFY. Как правило, хосты, участвующие в транзакциях зонной пересылки, динамических обновлениях и DNS NOTIFY, находятся внутри одного административного домена. Единственным исключением являются первичный или вторичный name-серверы организации, которые часто расположены у Интернет-провайдера или в других организациях. При этом обычно предполагается наличие заранее существующего отношения доверия между первичным и вторичным name-серверами. Тем не менее возможны случаи, когда потребуется установить тот или иной способ взаимной аутентификации при зонных пересылках DNS.
Угрозы DNS NOTIFY и способы обеспечения защиты
DNS NOTIFY является сообщением, посылаемым первичным name-сервером вторичному, которое содержит информацию, что зонный файл изменился и что вторичному name-серверу следует выполнить зонные пересылки для поддержания своих зонных файлов в синхронном состоянии. Так как сообщение NOTIFY является сигнальным, то существует минимальный риск безопасности, связанный с данным сообщением. Считается, что основной риск состоит в следующем:
Угроза Т17 – поддельные сообщения NOTIFY: вторичные name-серверы могут получить поддельные сообщения DNS NOTIFY из других источников, отличных от первичного name-сервера.
Единственным воздействием при получении поддельного сообщения DNS NOTIFY является возрастание нагрузки на первичный и вторичный name-серверы из-за более частых зонных пересылок. Так как происходит небольшое воздействие, подход к обеспечению защиты состоит в конфигурировании вторичного name-сервера для получения сообщения DNS NOTIFY только от конкретного первичного name-сервера.
Угрозы DNS-запросам и ответам и способы обеспечения защиты
Обычные запросы и ответы сервиса разрешения имен содержат неподписанные и незашифрованные UDP-пакеты. Возможные угрозы транзакциям DNS Query/Response описаны в RFC 3833 и могут быть классифицированы следующим образом:
Угроза Т9: поддельный (выдуманный) ответ.
Угроза Т10: удаление некоторых ресурсных записей из ответа.
Угроза Т11: некорректные правила расширения, примененные к wildcard в ресурсных записях в зонном файле.
Угрозы зонной пересылке и способы обеспечения защиты
Зонные пересылки выполняют репликацию зонных файлов на несколько серверов для защиты от сбоев DNS-сервиса. Первая угроза, DoS, является общей для любой сетевой транзакции. Вторая угроза основана на использовании знания, которое получено из информации, указанной в зонных пересылках.
Угроза Т12 – DoS: так как зонные пересылки включают пересылку всех данных зоны, они требуют больше сетевых ресурсов, чем обычные DNS-запросы. Случайные или преднамеренно частые запросы зонных пересылок могут сильно загрузить сервер первичной зоны, в результате чего возникнет DoS-атака для законных пользователей.
Угроза Т13 – сообщение ответа зонной пересылки может быть перехвачено и подделано.
DoS-атака может быть минимизирована, если серверы, которым разрешено делать запросы зонных пересылок, ограничены множеством известных участников. Для конфигурирования подобного множества известных участников в первичном name-сервере должны существовать значения, идентифицирующие этих участников. ПО name-сервера, такое как BIND, предоставляет возможность с помощью конфигурационных опций ограничить запросы зонных пересылок множеством указанных IP-адресов. Однако, поскольку IP-адреса могут быть подделаны, такой способ конфигурации не обеспечивает безопасного ограничения выполнения зонных пересылок.
Был разработан альтернативный механизм, называемый transaction signature (TSIG) , при использовании которого взаимная аутентификация серверов основана на разделяемом секретном ключе. Так как количество серверов, включенных в зонную пересылку, ограничено (обычно это name-серверы в одном и том же административном домене), двухсторонняя модель доверия, основанная на разделяемом секретном ключе, является адекватной для большинства случаев, — исключением могут быть только очень большие организации. TSIG описывает, как разделяемый секретный ключ используется не только для взаимной аутентификации, но и для аутентификации запросов и ответов зонных пересылок. Следовательно, это обеспечивает защиту от подделки сообщений запросов зонной пересылке (угроза Т13). Защита самих данных DNS в сообщении зонной пересылке также может быть обеспечена с помощью проверки подписи для ресурсных записей зоны, созданной name-сервером. Эти подписи, однако, не охватывают всю информацию в зонном файле (например, информацию делегирования). Более того, они позволяют проверить только отдельные множества ресурсных записей, а не все сообщение запроса зонной пересылке.
Указание name-серверу использовать ключи во всех транзакциях
В каждом конфигурационном файле пары серверов, которые разделяют секретный ключ в зоне, должно быть указано имя ключа, используемого во всех коммуникациях между ними (с помощью утверждения server в конфигурационном файле).
Команда для указания серверу использовать ключ во всех транзакциях (запрос / ответ DNS, зонная пересылка, динамическое обновление и т.п.) следующая:
server 192.249.249.1 { keys { ns1-ns2.example.ru.; }; };
где параметр keys является именем ключа.
Подведем итоги:
TSIG должен создавать МАС длиной минимум 128 бит. Для каждого типа транзакций (зонная пересылка, динамическое обновление и т.п.) должен быть создан уникальный TSIG-ключ.
После того как строка ключа скопирована в файл ключа на name- сервере, оба файла, созданные программой dnssec-keygen, должны быть сделаны доступными только аккаунту администратора сервера (например, root на Unix), или, еще лучше, удалены. Бумажные копии этих файлов также должны быть уничтожены.
Файл с ключом должен быть безопасно передан name-серверам, которые будут взаимодействовать с name-сервером, где создан ключ.
Утверждение в конфигурационном файле (обычно находящимся в /etc/named.conf для BIND, выполняющихся на Unix), которое описывает TSIG-ключ (имя ключа (ID), алгоритм и строка ключа) не должно непосредственно содержать строку ключа. Когда строка ключа находится в конфигурационном файле, риск компрометации ключа возрастает в тех окружениях, в которых требуется делать конфигурационный файл читаемым кому-либо, кроме администратора зоны. Вместо этого строка ключа должна быть определена в отдельном файле ключа, на который должна быть сделана ссылка с помощью директивы include в утверждении key в конфигурационном файле. Каждый TSIG-ключ должен храниться в отдельном файле ключа.
Собственником файла ключа должен быть аккаунт, от имени которого выполняется ПО name-сервера. Биты разрешения должны быть установлены таким образом, чтобы файл ключа мог читаться и модифицироваться только аккаунтом, от имени которого выполняется ПО name-сервера.
Ключ TSIG, используемый для аутентификации и обеспечения целостности сообщений между парой серверов, должен быть указан в утверждении server у обоих взаимодействующих серверов. Это необходимо, чтобы гарантировать, что и для сообщения запроса, и для сообщения транзакции вычислены МАС и тем самым обеспечена их безопасность.
Управление содержимым зонного файла
Как уже отмечалось, для управления содержимым зонного файла должен использоваться подход, обеспечивающий защиту на уровне ОС, с использованием различных инструментальных средств проверки целостности. Эффективность этих средств зависит от возможностей, имеющихся в них. Следовательно, процесс развертывания состоит из разработки правильных ограничений и определения правильных значений некоторых ключевых полей различных типов ресурсных записей.
Выделенный экземпляр name-сервера для каждой функции
Авторитетный name-сервер обслуживает ресурсные записи своей собственной зоны; данная функция называется авторитетной функцией. Обслуживание ресурсных записей из своего кэша (создавая кэш динамически, используя итеративные запросы) называется рекурсивной функцией. Name-сервер может быть сконфигурирован как авторитетный name-сервер, рекурсивный name-сервер или как и то, и другое одновременно. Так как существуют такие атаки, как порча кэша, то политика безопасности, при которой выполняется рекурсивный name-сервера, отличается от политики безопасности, при которой выполняется авторитетный name-сервер. Следовательно, name-сервер должен всегда быть сконфигурирован либо как авторитетный name-сервер, либо как рекурсивный name-сервер.
Авторитетный name-сервер только обеспечивает разрешение имен для зон, для которых он имеет авторитетную информацию. Следовательно, политика безопасности не должна допускать рекурсию для данного типа name-сервера. Запрещение рекурсии означает невозможность посылки запросов от имени других name-серверов и создания кэша из полученных ответов. В BIND рекурсия запрещается использованием утверждения options в конфигурационном файле:
options { recursion no; };
Рекурсивный name-сервер предназначен для обработки запросов от имени клиентов. Таким образом, защита рекурсивных name-серверов может быть обеспечена ограничением конкретных типов транзакций для определенных хостов. Это достигается использованием различных конфигурационных опций.
Выполнение ПО name-сервера с ограниченными привилегиями
Если ПО name-сервера выполняется от имени привилегированного пользователя (например, root на Unix-системах), то любая ошибка в ПО может иметь катастрофические последствия для ресурсов, расположенных на той же платформе. Следовательно, необходимо выполнять ПО name-сервера от имени непривилегированного пользователя с ограничением доступа только к указанным директориям, чтобы уменьшить ущерб от возможных ошибок.
Ограничение доступа к другим директориям может быть выполнено с помощью команды chroot в Unix. Такой подход называется выполнением name-сервера в jail (тюрьме). Должна быть выполнена следующая команда:
chroot –u named –g other –t /var/named
где:
-u указывает userID, от имени которого name-сервер будет выполняться после старта. Аккаунт данного пользователя должен быть создан до выполнения команды chroot.
-g указывает groupID, которой userID должен принадлежать. Если –g не указано, name-сервер выполняется от имени основной группы для userID.
-t указывает директорию, к которой name-сервер будет иметь доступ.
с ними угрозы, цели безопасности
Просуммируем транзакции DNS и связанные с ними угрозы, цели безопасности и механизмы безопасности, обеспечивающие защиту от этих угроз.
| DNS Query/Response | (a) Изменение или вставка ложного ответа (b) Удаление ресурсных записей в ответах (c) Некорректные правила расширения wildcard | (a) Аутентификация исходных данных (b) Проверка целостности данных | DNSSEC |
| Зонная пересылка | (a) DoS-атака (b) Изменение сообщений | (a) Взаимная аутентификация участников (b) Проверка целостности данных | TSIG |
| Динамическое обновление | (a) Неавторизованные модификации (b) Изменение сообщений (c) Replay-атака | (a) Взаимная аутентификация участников (b) Проверка целостности данных (c) Подписанные отметки времени | TSIG |
| DNS NOTIFY | (a) Ложные уведомления | (a) Предотвращение DoS-атак, возникающих из-за возрастания нагрузки | Конфигурационные опции |
Защищенный подход для DNS Query/Response – DNSSEC
Ликвидация угрозы, связанной с DNS Query/Response (т.е. подделанного ответа), состоит в обеспечении целостности данных DNS, возвращаемых в ответе. Следовательно, целью безопасности является проверка целостности каждого полученного ответа. Составной частью проверки целостности является гарантирование того, что данные получены из нужного источника. Установление доверия к источнику называется аутентификацией источника. Итак, целями безопасности для транзакций DNS Query/Response являются аутентификация источника и проверка целостности данных.
Эти сервисы могут быть предоставлены для установления доверия к источнику с помощью проверки подписи данных, посланных источником. Описание использования механизма цифровой подписи в контексте инфраструктуры DNS называется стандартом DNSSEC. Преследуемые цели, дополнительные ресурсные записи и содержание сообщений DNS специфицированы в RFC 4033, 4034 и 4035. В DNSSEC доверие к открытому ключу источника, который используется для проверки подписи, устанавливается не с помощью третьей стороны или цепочки третьих сторон (как в инфраструктуре открытого ключа PKI), а наличием доверенного name-сервера (такого как root name-сервер) и установлением цепочки доверия вниз к текущему источнику ответа с помощью проверок подписи, созданной в родительском домене для открытого ключа потомка. Открытый ключ доверенных name-серверов называется trust anchor.
После аутентификации источника DNSSEC выполняет аутентификацию ответа. Для этого требуется, чтобы ответы состояли не только из запрошенных ресурсных записей, но также и из аутентификатора, связанного с ними. В DNSSEC таким аутентификатором является цифровая подпись для множества ресурсных записей. Эта цифровая подпись хранится в специальном типе ресурсной записи, называемом RRSIG. Клиент DNS, используя доверенный открытый ключ (доверие к которому уже установлено), проверяет цифровую подпись для определения действительности ответа.
Для гарантии того, что ресурсные записи, указанные в запросе, на самом деле отсутствуют в зонном файле и не были удалены при передаче, механизм DNSSEC определяет способ аутентификации несуществующей ресурсной записи.
Создается специальная ресурсная запись, называемая NSEC RR, в которой перечислены типы ресурсных записей, связанные с конкретным именем, а также следующее имя в зонном файле. Данная специальная ресурсная запись посылается вместе с подписью для нее к рекурсивному name-серверу. Проверяя данную подпись, поддерживающий DNSSEC рекурсивный name-сервер может определить, какие существуют авторитетные имена в зоне и какие существуют авторитетные типы ресурсных записей для этих имен.
Для защиты от атак некорректного применения правил расширения для wildcard в ресурсных записях механизм DNSSEC предоставляет значения для сравнения действительной ресурсной записи в wildcard с NSEC-ресурсной записью, и тем самым проверяет, что name-сервер корректно применил в созданном ответе правила расширения wildcard.
DNSSEC гарантирует целостность ответов разрешения имен DNS-клиентам, предоставляя клиентам возможность выполнить проверку подписи. Однако во многих случаях эти DNS-клиенты являются stub resolver’ами, в которых не реализован DNSSEC. Если проверка подписи выполняется рекурсивным name-сервером, который предоставляет сервис разрешения имен для своих клиентов, то end-to-end целостность данных ответа может быть гарантирована только защитой коммуникационного канала между рекурсивным name-сервером и stub resolver’ом.
Данные DNS считаются публичными, следовательно, конфиденциальность не является целью безопасности DNSSEC. DNSSEC не разрабатывался непосредственно для защиты от DoS-атак, хотя он делает это косвенно, обеспечивая целостность сообщения и аутентификацию источника.
Защита транзакции с использованием НМАС (TSIG)
Процесс аутентификации источника сообщения и обеспечение целостности сообщения с помощью НМАС определяются в наборе спецификаций DNS, известных как TSIG. Термин НМАС используется для обозначения кода аутентификации сообщений, созданного с применением хэш-функции и ключа.
Функция НМАС использует два параметра – сообщение и секретный ключ – и создает выход, называемый кодом аутентификации сообщения (МАС) или хэшем. Отправитель сообщения использует функцию НМАС для создания МАС и посылает данный МАС вместе с сообщением получателю. Получатель, который разделяет тот же самый секретный ключ, использует ключ и ту же самую хэш-функцию для вычисления МАС для полученного сообщения. Затем получатель сравнивает вычисленный МАС с полученным МАС; если два значения совпали, существует определенная гарантия, что сообщение передано корректно и что отправитель знает тот же самый секретный ключ. Таким образом, выполняется одновременно аутентификация источника сообщения и проверка целостности.
Хэш-алгоритм создает МАС фиксированной длины из сообщения произвольной длины. Функция НМАС для TSIG, специфицированная в RFC 2845, определяет только один хэш-алгоритм (MD5), идентификатор алгоритма есть HMAC-MD5. Поддержка других алгоритмов (например, SHA-1 и SHA-256) может быть задана в дальнейшем.
Защита транзакции посредством НМАС с использованием разделяемого секрета не является масштабируемым решением. Это основная причина, по которой TSIG в основном используется для транзакций зонной пересылки и динамического обновления. Данные транзакции происходят либо между серверами в одном и том же административном домене, либо между серверами в доменах, между которыми ранее уже выполнялись транзакции.
МАС, создаваемый отправителем DNS-сообщения, помещается в новую ресурсную запись, называемую TSIG записью, которая добавляется к DNS-сообщению. Запись TSIG в дополнение к созданному хэшу содержит следующее:
имя хэш-алгоритма;имя ключа;
время создания хэша (timestamp); "Fudge-фактор" — время в секундах (обычно 5), используемое для определения продолжительности интервала времени, в течение которого МАС должен считаться действительным; используется, чтобы сгладить возможное расхождение часов у различных хостов.
Поле timestamp указывает время, когда был создан МАС. Цель данного поля состоит в защите от replay-атак. При replay-атаке атакующий может перехватить пакет, содержащий МАС, и послать его позднее. Для гарантирования того, что этого не произойдет, получатель анализирует время создания МАС и текущее время и проверяет, был ли создан МАС в "допустимое время", которое вычисляется с использованием "Fudge-фактора".
Для того чтобы обеспечить безопасность транзакции на основе МАС, отправитель вычисляет хэш от всего DNS-сообщения и секретного ключа и записывает результат в TSIG ресурсную запись в конец сообщения. На стороне получателя запись TSIG извлекается из сообщения и обрабатывается. Процесс, при котором получатель использует запись TSIG для проверки целостности полученного DNS-сообщения, называется верификацией . Процесс верификации использует название хэш-алгоритма для определения хэш-функции и имя ключа для определения ключа, используемого для верификации записи TSIG. Значение Fudge-фактора используется для возможной корректировки времени создания хэша. Тем самым Fudge-фактор определяет допустимый период действительности МАС относительно времени его создания.
Указание имени ключа в записи TSIG дает возможность проверяющей стороне (т.е. получателю) использовать правильный ключ, а также дает возможность проверить, что ключ действительно является одним из ключей, разделяемых отправителем и получателем. Цель поля timestamp в записи TSIG состоит в информировании получателя сообщения о времени создания МАС. Получатель сравнивает данное значение с текущим значением часов на машине получателя для гарантии того, что МАС был создан в допустимый интервал времени. Цель использования timestamp состоит в предотвращении replay-атак. Для корректной проверки времени создания относительно текущего времени особенно важно, чтобы системные часы участников транзакции были синхронизованы. В этих целях может использоваться такой протокол, как Network Time Protocol (NTP).
Поле timestamp указывает время, когда был создан МАС. Цель данного поля состоит в защите от replay-атак. При replay-атаке атакующий может перехватить пакет, содержащий МАС, и послать его позднее. Для гарантирования того, что этого не произойдет, получатель анализирует время создания МАС и текущее время и проверяет, был ли создан МАС в "допустимое время", которое вычисляется с использованием "Fudge-фактора".
Для того чтобы обеспечить безопасность транзакции на основе МАС, отправитель вычисляет хэш от всего DNS-сообщения и секретного ключа и записывает результат в TSIG ресурсную запись в конец сообщения. На стороне получателя запись TSIG извлекается из сообщения и обрабатывается. Процесс, при котором получатель использует запись TSIG для проверки целостности полученного DNS-сообщения, называется верификацией . Процесс верификации использует название хэш-алгоритма для определения хэш-функции и имя ключа для определения ключа, используемого для верификации записи TSIG. Значение Fudge-фактора используется для возможной корректировки времени создания хэша. Тем самым Fudge-фактор определяет допустимый период действительности МАС относительно времени его создания.
Указание имени ключа в записи TSIG дает возможность проверяющей стороне (т.е. получателю) использовать правильный ключ, а также дает возможность проверить, что ключ действительно является одним из ключей, разделяемых отправителем и получателем. Цель поля timestamp в записи TSIG состоит в информировании получателя сообщения о времени создания МАС. Получатель сравнивает данное значение с текущим значением часов на машине получателя для гарантии того, что МАС был создан в допустимый интервал времени. Цель использования timestamp состоит в предотвращении replay-атак. Для корректной проверки времени создания относительно текущего времени особенно важно, чтобы системные часы участников транзакции были синхронизованы. В этих целях может использоваться такой протокол, как Network Time Protocol (NTP).
