From: Andrey
Newsgroups: email
Date: Mon, 15 Aug 2005 14:31:37 +0000 (UTC)
Subject: Защита DNS используя механизм TSIG
> Как оказалось, автор стати скопироал, с некоторыми сокращениями,
> оригинальный текст 11 главы книги "DNS и BIND",
> авторы - Пол Альбитц и Крекет Ли, четвертое издание, Санкт-Питербург 2002.
> издательство: Символ-Плюс
В этой статье я постараюсь поверхностно рассказать вам про DNS, а
именно про его защиту, которая надо сказать очень сильно страдает. Я
постараюсь вам рассказать, что такое TSIG и как быстро можно поднять
данный механизм. На сколько профессионально написана данная статья я
не знаю, СУДИТЬ ВАМ, но я старался изложить все как можно коротко и
точно.
Чтобы защитить пользователей от нарушений работы DNS-сервера (к
примеру от несанкционированной отправки кэша крупных DNS-серверов
расположенных по всему миру, заставив их думать, что адресом для имени
"Вася.ру" в действительности является адрес "Катя.ру") необходимо
обеспечить безопасность DNS. Безопасность DNS можно обеспечить
несколькими способами. Можно обеспечить безопасность транзакций -
запросов, ответов и всех прочих сообщений, посылаемых и получаемых
DNS.
Можно задуматься о безопасности от так называемых избирательных
отказов в выполнении запросов, динамических обновлений и передаче
зональных данных - для неавторизованных адресов. Люди которые на
профессиональном уровне сталкивались с обеспечением безопасности
крупных DNS серверов, могут помнить, что в BIND 8.2 появился
принципиально новый механизм обеспечения безопасности для сообщений
DNS, который называется TSIG, в нем используется механизм общих
секретов и вычислительно необратимой хеш - функции для проверки
подлинности DNS сообщений (как правило в ответах и обновлениях). При
настроенном и работающем механизме TSIG DNS-сервер или автор
обновления добавляет TSIG запись в раздел дополнительных данных
сообщения DNS и подтверждает, что отправитель сообщения обладает общим
с получателем криптографическим ключом и что сообщение не изменилось
после того как было отправлено.
TSIG обеспечивает идентификацию и целостность данных посредством
использования специального вида математических формул, эта
хеш-функция известная наверное многим под названием криптографической
контрольной суммы или дайджеста сообщения, вычисляет хеш-значение
фиксированной длины на основе исходных данных произвольного объема.
Чудесность вычислительно необратимой хеш-функции заключается в том,
что она полностью зависит от каждого бита исходных данных. Если
изменить единственный бит исходных данных, хеш значение тоже
измениться.
Я не стану подробно рассматривать синтаксис TSIG записи, поскольку
нам нет необходимости его знать. TSIG-это мета запись, которая никогда
не отображается в данных зоны и никогда не кэшируется сервером и
клиентом. Отправитель сообщения DNS подписывает его с помощью TSIG
записи, а получатель удаляет и проверяет запись, прежде, чем выполнить
какие либо действия, например, кэширование данных сообщения.
Следует знать, что TSIG запись содержит хэш значение, вычисленного для
полного сообщения DNS (для начинающих администраторов хочу сказать,
что "вычисленное для" имеется в виду, что сообщение DNS в двоичном
формате и дополнительные поля (понятно какие ? (для особо одаренных))
обрабатываются алгоритмом HMAC-MD5 с целью получения хэш значения).
Хэш значения модифицируется по ключу, который является общим секретом
отправителя и получателя. К примеру дополнительные поля TSIG записи
включают время подписи сообщения DNS. Это позволяет отображать (мои
любимые) атаки повторного воспроизведения (replay attacks), суть этих
простых действий заключается в том, что хакер перехватывает
авторизованную транзакцию с подписью (например, динамическое
обновление, или удаление "важной" RR записи) и воспроизводит ее позже.
Получатель подписного сообщения DNS проверяет время подписи, чтобы
убедиться, что это время находиться в пределах допустимого (это время
определяется в отдельных полях TSIG).
Прежде чем начинать использовать TSIG для идентификации, необходимо
создать один или несколько TSIG ключей для сторон обменивающихся
данными.К примеру, если необходимо с помощью TSIG обезопасить передачу
зоны с DNS мастер-сервера, daun.ru на вторичный, следует настроить оба
сервера на использование общего ключа:
ny-ti.daun.ru аргумент оператора key в приведенном примере (вот-вот)
является в действительности именем ключа. Помните, что очень важно,
чтобы имя ключа, а не только двоичные данные ключа - было одинаковым
для обеих сторон, участвующих в транзакциях. В противном случае
получатель в попытке проверить TSIG запись обнаружит, что ничего не
знает о ключе который тут упоминается и был использован для вычисления
хэш значения. Вся эта ... приводит к получению Даун - ошибки:
Nov 10 00:00:00 ny-ti named-xfer[20252]: SOA TSIG verification from server
[xxx.xxx.xxx.xxx], zone daun.ru: message had BADKEY set (17)
В настоящие время значение алгоритма всегда hmac-md5. Секрет
представляет собой ключ в кодировки (я думаю некоторым известной)
Base64, созданной с помощью программы dnssec-keygen, которая как вы
могли догадаться входит в состав BIND 9, или dnskeygen в BIND8. Вот
пример создания ключа с помощью dnssec-keygen
# dns-keygen -a HMAK-MD5 -b 128 -n HOST ny-ti.daun.ru.
dnssec-keygen и dnskeygen создают в своих рабочих каталогах файлы,
содержащие созданные ключи. dnssec-keygen печатает основу имен файлов
на стандартный вывод. В приведенном выше примере, были созданы файлы
ny-ti.daun.ru.+141+29664.key и ny-ti.daun.ru. +141+29664.private. Ключ
можно извлечь из любого файла. Если вас интересует, что это за цифры,
то скажу вам, что это не номера телефонов, а номера алгоритма DNSSEC
для ключа (141 соответствует алгоритму HMAC-MD5) и карта (fingerprint)
ключа 29664. Карта ключа абсолютно без полезна в контексте TSIG, но в
DNSSEC реализована поддержка нескольких ключей для зоны, поэтому важно
иметь возможность идентифицировать ключ по его карте. К примеру файл
ny-ti.daun.ru.+141+29664.key содержит строку:
ny-ti.daun.ru. IN KEY 545 4 141 asdhjKf/faTghjfv73H==
Ну а в конце концов можно просто выбрать свой собственный ключ, и
перекодировать его с помощью софтины "mmencode" вот пример:
mmencode
mydilkin
Zm9FcdHdgm3
Существует проблема, которая крайне часта встречается при
использовании TSIG (ну и конечно опытные админы bind'a догадались,
если вы себя таким считаете и не смогли сразу понять, что это за
проблема, то вы ...). А проблема эта очень простая, синхронизация
времени, отметка времени в TSIG записи крайне полезна для
предотвращения атак, основанных на воспроизведении, но
работоспособность этого свойства изначально уменьшается тем фактом,
что часы DNS не синхронизированы. Это приводит к получению таких
ерроров:
Nov 10 00.00.00 ny-ti named-xfer[20252]: SOA TSIG verification from server
[xxx.xxx.xxx.xxx], zone daun.ru: BADTIME (-14)
Ну ведь мы с вами просто супер админы, и в момент избавляемся от этой
... простым использованием NTP.
Урааааа, теперь, после того как я вам рассказал, что это такое за
TSIG, можно переходить к его использованию, а именно мы с вами сейчас
настроим наши серверы на практическое применение этих ключей. Основой
настройки является предписание keys инструкции server, которое
сообщает DNS серверу, что ему нужно подписывать обычные запросы и
запросы на передачу зоны, направляемые определенному удаленному DNS
серверу. К примеру все делается очень просто, наша задача состоит в
том, что DNS ny-ti.daun.ru будит подписывать все запросы идущие на
xxx.xxx.xxx.xxx polniy.daun.ru
server xxx.xxx.xxx.xxx {
keys { polniy.daun.ru. ; };
};
на узле polniy.daun.ru мы можем очень просто ограничить передачу зоны
до пакетов, подписанных ключом polniy.daun.ru, вот пример
zone "daun.ru" {
type master;
file "db.daun.ru";
allow-transfer { key polniy.daun.ru. ;
};
};
Ну и конечно существует возможность ограничить динамические обновления
с помощью TSIG, используя предписание allow-update и update-policy (я
надеюсь, что вы знаете как это делать, !вы ведь суп. админы!).
Программы nsupdate, которые входят в состав bind'a поддерживают
посылку динамических обновлений с TSIG записями. Если ключевые файлы,
созданные софтиной dnssec-keygen все еще у вас существуют, имя любого
из них можно указать в качестве аргумента ключа -k
nsupdate -k ny-ti.daun.ru.+141+29664.key
или
nsupdate -k ny-ti.daun.ru.+141+29664.private
Если файлов под рукой нет, можно указать все параметры прямо в
командной строке
Vova
