Транзакции DNS

Защита транзакции с использованием НМАС (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).

Процесс верификации состоит в извлечении соответствующего секретного ключа, вычислении хэша от полученного сообщения и секретного ключа, и сравнении вычисленного хэша с полученным хэшем (в TSIG-записи). В процессе верификации name-сервер выполняет следующие проверки:

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

В BIND версии 8.2 были впервые введены возможности TSIG, но полностью TSIG был реализован только в BIND 9.х. Поддержка в BIND 9.х возможностей TSIG обеспечена и для транзакций зонных пересылок, и для транзакций динамического обновления.

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

• системные часы name-серверов (первичного и вторичного), участвующих в DNS-транзакциях, должны быть синхронизованы (например, с помощью NTP);
• должна существовать утилита генерации секретного ключа, которая может создавать ключи требуемой длины с достаточной энтропией. Файл ключа (файл, содержащий строку секретного ключа) должен быть безопасно передан двум серверам, участвующим в транзакции;
• информация о ключе должна быть указана в конфигурационном файле с помощью соответствующих утверждений (например, утверждения key и утверждения server в конфигурационном файле named.conf BIND 9.х).

Создание ключа

Чтобы обеспечить возможность выполнять аутентификацию зонных пересылок (запросов и ответов), необходимо создать ключи для каждой пары 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.

Определение ключей для взаимодействующих 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-серверу использовать ключи во всех транзакциях

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

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

server 192.249.249.1 {
  keys { ns1-ns2.example.ru.; };
};

где параметр keys является именем ключа.

Подведем итоги:

1. TSIG должен создавать МАС длиной минимум 128 бит.
2. Для каждого типа транзакций (зонная пересылка, динамическое обновление и т.п.) должен быть создан уникальный TSIG-ключ.
3. После того как строка ключа скопирована в файл ключа на name- сервере, оба файла, созданные программой dnssec-keygen, должны быть сделаны доступными только аккаунту администратора сервера (например, root на Unix), или, еще лучше, удалены. Бумажные копии этих файлов также должны быть уничтожены.
4. Файл с ключом должен быть безопасно передан name-серверам, которые будут взаимодействовать с name-сервером, где создан ключ.
5. Утверждение в конфигурационном файле (обычно находящимся в /etc/named.conf для BIND, выполняющихся на Unix), которое описывает TSIG-ключ (имя ключа (ID), алгоритм и строка ключа) не должно непосредственно содержать строку ключа. Когда строка ключа находится в конфигурационном файле, риск компрометации ключа возрастает в тех окружениях, в которых требуется делать конфигурационный файл читаемым кому-либо, кроме администратора зоны. Вместо этого строка ключа должна быть определена в отдельном файле ключа, на который должна быть сделана ссылка с помощью директивы include в утверждении key в конфигурационном файле. Каждый TSIG-ключ должен храниться в отдельном файле ключа.
6. Собственником файла ключа должен быть аккаунт, от имени которого выполняется ПО name-сервера. Биты разрешения должны быть установлены таким образом, чтобы файл ключа мог читаться и модифицироваться только аккаунтом, от имени которого выполняется ПО name-сервера.
7. Ключ TSIG, используемый для аутентификации и обеспечения целостности сообщений между парой серверов, должен быть указан в утверждении server у обоих взаимодействующих серверов. Это необходимо, чтобы гарантировать, что и для сообщения запроса, и для сообщения транзакции вычислены МАС и тем самым обеспечена их безопасность.