Библиотека Интернет Индустрии I2R.ru

Технология подлога

Рассмотрим первый и второй методы атаки из перечисленных выше. Оба состоят в том, что злоумышленник в ответ на запрос об адресе узла www.goodbank.com посылает на атакуемый хост (компьютер-клиент host.victim.com или DNS-сервер ns.victim.com) подложный DNS-ответ со сфальсифицированными данными. Чтобы такой ответ был воспринят атакуемым хостом, злоумышленнику необходимо выполнить следующие условия.
1. IP-адрес отправителя датаграммы, содержащей ответ, равен IP-адресу сервера, на который атакуемый хост послал запрос (предположим, это ns.goodbank.com).
2. Номер порта, на который отправлен ответ, равен номеру порта, с которого был выслан запрос.
3. Каждое DNS-сообщение содержит поле Идентификатор (ID). Идентификатор ответа должен быть равен идентификатору запроса.
Кроме того, очевидно, что ответ должен содержать затребованные данные (в нашем примере - запись типа А для имени www.goodbank.com) и прийти раньше ответа от ns.goodbank.com (если только против ns.goodbank.com не произведена атака отказ в обслуживании).
В случае, когда злоумышленник может подслушать или иным образом перехватить трафик между атакуемым хостом и сервером ns.goodbank.com, выполнение всех трех условий не составит труда.
Гораздо больший интерес представляет общая ситуация, когда злоумышленник не находится на пути между атакуемым хостом и сервером ns.goodbank.com. В качестве атакуемого хоста будем рассматривать сервер ns.victim.com, как более привлекательную для злоумышленника цель, тем более, что хосты домена victim.com скорее всего не будут производить поиск в DNS самостоятельно, а обратятся к ns.victim.com. Механизм подобной атаки - отравление кэша - описан в статье [2].
Для выполнения атаки злоумышленник должен угадать момент, когда ns.victim.com отправит запрос об адресе хоста www.goodbank.com, и выслать подложный ответ, удовлетворяющий вышеприведенным условиям 1-3. Очевидно, что угадать верный момент можно только одним способом - спровоцировать ns.victim.com на отправку нужного запроса. Если этого сделать невозможно, то атака не является осуществимой. Злоумышленник также бессилен, если правильный адрес www.goodbank.com уже находится в кэше сервера ns.victim.com; в этом случае злоумышленнику придется ждать, пока время жизни записи истечет.

Рассмотрим способы провокаций. Их два: прямая и косвенная провокация.
Выполняя прямую провокацию, злоумышленник сам посылает серверу ns.victim.com рекурсивный запрос об адресе www.goodbank.com. Поскольку запрос является рекурсивным, то ns.victim.com начинает поиск требуемого адреса, который приведет его к посылке нужного злоумышленнику запроса. Очевидным методом защиты от такой провокации является запрет на обработку рекурсивных запросов, поступивших не от узлов своего домена, то есть ns.victim.com не должен обрабатывать рекурсивные запросы, поступившие не от хостов домена victim.com. Впрочем, эта мера не поможет, если злоумышленник находится внутри домена victim.com или администратор сети victim.com не предпринял меры по защите от имперсонации (spoofing) датаграмм.
Второй способ - косвенная провокация - состоит в том, чтобы вынудить какой-либо из узлов домена victim.com обратиться к серверу ns.victim.com с необходимым рекурсивным запросом. Сделать это достаточно просто. Многие программы Интернет-сервисов, получив запрос на соединение (SYN-сегмент TCP), проводят двойное DNS-преобразование, то есть запрашивают доменное имя для IP-адреса отправителя SYN-сегмента, а потом запрашивают IP-адрес для полученного доменного имени. Ирония состоит в том, что это делается с целью обеспечения безопасности: чтобы убедиться, что подсоединяющийся клиент обладает легальным, зарегистрированным IP-адресом. Второй запрос и есть то, чего добивается злоумышленник. Злоумышленнику остается только отправить TCP SYN-сегмент от имени настоящего IP-адреса www.goodbank.com на какой-либо сервер в домене victim.com, выполняющий двойное DNS-преобразование. Найти такой сервер в victim.com можно предварительным тестированием: если злоумышленник контролирует DNS-сервер ns.cracked.com какого-либо домена cracked.com или может прослушивать сегмент сети, к которому сервер подключен, то, отправляя TCP SYN-сегменты от имени некоего хоста host.cracked.com на серверы домена victim.com, он может отслеживать, поступили ли на ns.cracked.com запросы от ns.victim.com относительно IP-адреса host.cracked.com.

Некоторые FTP-серверы прямо заявляют о том, что они выполняют двойное преобразование - стоит только внимательно прочесть пригласительное сообщение, которое сервер выдает клиенту. Вариант этой же провокации: упоминание www.goodbank.com в SMTP-сеансе. Злоумышленник находит в DNS почтовый сервер домена victim.com (путем запроса записи типа MX) или определяет, на каких узлах в victim.com запущены SMTP-серверы методом сканирования. После этого злоумышленник соединяется с обнаруженным SMTP-сервером mail.victim.com и в качестве аргумента команды MAIL FROM: указывает адрес user@www.goodbank.com. Опять же в целях обеспечения безопасности и борьбы с принудительной рассылкой (спамом) почтовый сервер, как правило, производит проверку адреса отправителя. То есть, после того как злоумышленник подал команду MAIL FROM:, хост mail.victim.com отправил своему серверу ns.victim.com рекурсивный запрос о доменном имени www.goodbank.com, чего и добивался злоумышленник.
Адекватной защиты от косвенной провокации не существует. Можно отделить публичные серверы от внутренних серверов и пользовательских станций: каждая группа будет обслуживаться своим сервером DNS. Поскольку на <внутренних> компьютерах не должно быть серверов, принимающих соединения из Интернета, то DNS-сервер, обслуживающий эту группу компьютеров, нельзя спровоцировать. В то же время DNS-сервер, обслуживающий группу публичных Интернет-серверов организации спровоцировать можно, а, следовательно, это делает возможным осуществление атаки и подмену DNS-данных, которыми пользуются компьютеры этой группы. Поэтому с этих компьютеров должны быть по возможности удалены все <исходящие> сервисы, то есть сервисы, предоставляемые по запросам пользователей своего домена. Например, в этой группе не следует размещать прокси-сервер WWW, обслуживающий пользователей организации, или почтовый сервер для исходящих сообщений,- они должны пользоваться DNS-сервером для <внутренней> группы.

Итак, предположим, что злоумышленнику удалось спровоцировать сервер ns.victim.com на отправку запроса об адресе хоста www.goodbank.com. Однако успешная провокация атакуемого DNS-сервера еще не означает, что атака удалась. Теперь злоумышленник должен сфабриковать DNS-ответ, удовлетворяющий вышеприведенным условиям 1-3. Напомним, что у злоумышленника нет возможности подслушать запрос, следовательно, ему не известен наверняка ни один из нужных для конструирования ответа параметров.
Запрос был направлен одному из официальных серверов зоны goodbank.com. Таких серверов, как минимум, два - их адреса можно найти, сделав соответствующий запрос. Злоумышленнику придется отправить несколько подложных ответов - по одному от имени каждого из официальных серверов goodbank.com, потому что злоумышленник точно не знает, к какому из них обратился ns.victim.com.
Ситуация с определением номера исходящего порта и идентификатора запроса гораздо сложнее. Злоумышленник, скорее всего, попытается протестировать поведение сервера ns.victim.com, спровоцировав его на отправку запросов подконтрольному ему серверу ns.cracked.com. Определив динамику изменения номера порта и идентификатора запроса (если они вообще изменяются), злоумышленник, наконец, спровоцирует ns.victim.com на отправку запроса об адресе www.goodbank.com и сфабрикует несколько подложных ответов с наиболее вероятными параметрами.
Очевидно, что если сервер ns.victim.com генерирует номер исходящего порта и идентификатор запроса случайным образом, то атака становится невозможной, даже если атакуемый сервер удалось спровоцировать на отправку нужных злоумышленнику тестовых и целевого запросов. (Напомним, что речь идет только о ситуации, когда злоумышленник не может перехватить трафик между ns.victim.com и ns.goodbank.com.)

Рассмотрим директивы BIND, которые можно использовать для защиты от отравления кэша (все директивы помещаются в раздел options):

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

Пример:

разрешены рекурсивные запросы от хостов своей сети,

  # запросы от всех остальных хостов будут

  # обрабатываться итеративно

  allow-recursion {1.16.196.0/24; 1.16.197.0/24; };

  fetch-glue no;    // по умолчанию в BIND 9

по умолчанию в BIND 9

};

Подчеркнем, что эти меры, достаточно эффективные против злоумышленника, не находящегося на пути передаваемых данных, не защитят от фальсификации, если злоумышленник может перехватывать трафик между DNS-клиентом и сервером. Полная защита обеспечивается только механизмом DNSSEC.
Если намерения злоумышленника более масштабны, чем введение в заблуждение хостов конкретного домена victim.com, или направлены против домена goodbank.com, то злоумышленник попытается подменить базу данных на официальном сервере зоны goodbank.com. Таким образом, все DNS-серверы Интернета, обратившиеся за информацией к пораженному официальному серверу, получат в ответ сфальсифицированные данные, которые, к тому же, надолго осядут в их кэшах. Доступ к серверам домена goodbank.com может быть частично или полностью прекращен.
Достичь своей цели злоумышленник может двумя методами, которые упоминались в начале статьи.
Во-первых, если злоумышленник находится на пути между первичным и вторичным серверами зоны goodbank.com, то, используя методы перехвата данных или десинхронизации TCP-соединения, злоумышленник может внедриться в процесс передачи зоны на вторичный сервер ns2.goodbank.com и изменить передаваемые данные в своих интересах. После этого вторичный сервер ns2.goodbank.com, который с точки зрения всего остального мира является не менее официальным, чем ns.goodbank.com, будет распространять искаженные данные.
Во-вторых, если разрешено динамическое обновление зоны и злоумышленник может выдать себя за один из хостов, авторизованных производить такое обновление, то злоумышленник может изменить базу данных на первичном сервере. Эта атака имеет наиболее серьезные последствия. После нее как первичный, так и все вторичные серверы goodbank.com будут выдавать искаженную информацию о своем домене. Подчеркнем также простоту осуществления этой атаки: достаточно отправить одно UDP-сообщение от имени авторизованного хоста; обратной связи между атакуемым сервером и злоумышленником не требуется.

Технологии защиты
TSIG
Из сказанного выше следует, что безопасность передачи данных DNS, а особенно передачи зоны и динамического обновления имеет исключительно большое значение. Документ RFC-2845 вводит механизм защиты передаваемых данных с помощью алгоритма MD5. Механизм называется TSIG и заключается в том, что в каждое DNS-сообщение добавляется виртуальная запись, содержащая хэш сообщения и секретного ключа, известного только отправителю и получателю. Запись TSIG называется виртуальной, потому что она не находится в базе данных, а формируется динамически для каждого DNS-сообщения.
Для вычисления хэша на вход алгоритма MD5 подается блок данных, содержащий секретный ключ, хэш запроса (если данное DNS-сообщение является ответом), заголовок DNS-сообщения (не включая TCP- или UDP-заголовок), записи, содержащиеся в сообщении, и переменные TSIG, среди которых имя ключа, время создания сообщения и допустимое расхождение часов отправителя и получателя. После того, как хэш вычислен, в конец сообщения добавляется запись TSIG, содержащая вышеуказанные переменные и собственно вычисленный хэш.
Получатель сообщения тоже вычисляет хэш, как описано выше, используя свою копию секретного ключа, и если вычисленный хэш совпадает с полученным в сообщении, это значит, что сообщение было действительно отправлено легитимным узлом и не было изменено по дороге.
Отметим, что при вычислении хэша DNS-ответа в него включается хэш соответствующего запроса с тем, чтобы отправитель запроса мог удостовериться, что он получил ответ действительно на свой запрос и запрос не был подменен в пути - это важно при выполнении динамического обновления. Также отметим, что в хэш включается время отправки сообщения. Это делается для того, чтобы предотвратить атаки воспроизведением (когда злоумышленник, перехватив и записав сообщение, отправляет его повторно через некоторое время). Соответственно, часы отправителя и получателя должны быть синхронизированы [2]. Допустимая разница между моментом отправки сообщения по часам отправителя и моментом получения по часам получателя указывается в сообщении и включается в хэш.
Механизм TSIG позволяет аутентифицировать любые DNS-сообщения: передачу зоны, динамическое обновление и обычные запросы и ответы,- но только между хостами, знающими секретный ключ (каждая пара хостов может иметь свой секретный ключ). Очевидно, что это решение не масштабируется для всего Интернета и не поможет в борьбе с отравлением кэша, но хорошо подходит для защиты передачи данных между заранее определенными хостами: между первичным и вторичными серверами зоны; между первичным сервером и хостами, авторизованными для выполнения динамического обновления; между сервером DNS и клиентами из его домена.
Последний вариант предназначен для защиты клиентов от ложных ответов, посылаемых злоумышленником, находящимся в том же домене. В крупной сети, конечно, не имеет смысла устанавливать на каждой рабочей станции секретный ключ (после этого он, скорее всего, перестанет быть секретным) - достаточно организовать работу с сервисами Интернета так, чтобы все пользователи обращались за услугами Интернета к определенным серверам-посредникам, например к WWW-прокси-серверу организации. Прокси-сервер - критически важный узел - при отправке DNS-запросов и получении ответов на них будет использовать TSIG.
Для того чтобы задействовать механизм TSIG, в конфигурационный файл /etc/named.conf необходимо внести следующие директивы. На первичном сервере ns.goodbank.com:

Ключ определяется по имени, которое выбирается произвольно,

# но должно выглядеть как некоторое доменное имя.

# Один и тот же ключ на всех использующих его хостах

# должен иметь одно и то же имя.

key ns-ns2.goodbank.com. {

                                algorithm hmac-md5;

            # значение ключа

                                secret "skrKc4Twy/cIgIykQu7JZA==";

};

# определим еще один ключ для аутентификации

# запросов на динамическое обновление

key updates.goodbank.com. {

                                algorithm hmac-md5;

                                secret "mZiMNOUYQPMNwsDzrX2ENw==";

};

zone "goodbank.com." {

                type master;

                file "goodbank.hosts";

                # разрешить передачу зоны только в ответ на запросы,

      # защищенные ключом ns-ns2.goodbank.com.

                allow-transfer { key ns-ns2.goodbank.com.; };

                # если требуется динамическое обновление,

      # то разрешить его только по запросам,

      # защищенным ключом updates.goodbank.com.

                allow-update { key updates.goodbank.com.; };

};

# IP-адрес сервера ns.goodbank.com, запросы к которому

# должны защищаться ключом ns-ns2.goodbank.com.

server 1.222.223.224 {

                                keys { ns-ns2.goodbank.com.; };

};

zone "goodbank.com." {

                type slave;

                file "goodbank.hosts.bak";

                allow-update { key updates.goodbank.com.; };

                # запретить передачу зоны с этого сервера

                allow-transfer { none; };

};

Значение ключа представляет собой набор бит, закодированный для текстового представления по алгоритму Base64. Сгенерировать ключ можно с помощью программы dnssec-keygen (входит в поставку BIND 9).

DNSSEC
Для обеспечения достоверной передачи DNS-данных в масштабе Интернета в систему DNS вводятся расширения, называемые DNSSEC (RFC-2535, а также RFC-2536, 2537, 2541, 3008). Основная идея DNSSEC состоит в использовании асимметричного шифрования для присоединения цифровой подписи к передаваемым данным.
Как известно, асимметричное шифрование предполагает наличие открытого и секретного ключей. Секретный ключ известен только администратору первичного сервера зоны. Записи из базы данных зоны пропускаются через хэширующий алгоритм (как правило, MD5), и получившийся <отпечаток> шифруется с помощью секретного ключа - так получается цифровая подпись. Она заносится в базу данных зоны в виде записи специального типа SIG и присоединяется к передаваемым данным при ответе на запрос (рис. 1). Подчеркнем, что сами данные передаются в открытом виде (можно было бы шифровать и собственно данные, но алгоритмы асимметричного шифрования требуют большого объема вычислений, а данные DNS по своей природе являются открытой информацией, требуется только удостоверить ее подлинность, следовательно, целесообразнее шифровать короткий хэш, чем весь объем данных).
Открытый ключ известен всем потенциальным получателям; он хранится в базе данных зоны в записи специального типа KEY и может быть востребован с помощью обычного запроса. Приняв данные и подпись, получатель расшифровывает подпись с помощью открытого ключа. Потом он вычисляет хэш полученных данных и сравнивает с тем, что получился после расшифровки подписи (рис. 2). Если хэши совпадают, то, во-первых, данные действительно были отправлены владельцем секретного ключа, и, во-вторых, данные не были изменены при передаче.

В отличие от TSIG, DNSSEC не требует от получателя знания секретного ключа, что позволяет обойти неразрешимую задачу распространения секретного ключа по всем возможным DNS-серверам глобальной сети и решить проблему обеспечения достоверности передачи DNS-данных в масштабе Интернета. Платой за это является существенное (в несколько раз) увеличение базы данных каждой зоны и повышенные требования к процессорной мощности DNS-серверов, которая требуется для выполнения операций асимметричного шифрования и дешифрации.
Для реализации механизма DNNSEC вводятся три новых типа записей: KEY, SIG и NXT. Подчеркнем, что все указанные записи генерируются автоматически, а не составляются вручную.
Запись типа KEY содержит открытый ключ зоны, закодированный для текстового представления с помощью алгоритма Base64.
Запись типа SIG содержит цифровую подпись для набора записей. Набором являются все записи одного типа для одного доменного имени: например, все записи типа MX для exmpl.ru. Получив запрос определенного набора записей, сервер возвращает требуемые данные, а вместе с ними - запись SIG, которая их удостоверяет. Цифровая подпись также кодируется с помощью Base64. Кроме собственно цифровой подписи запись SIG содержит время создания подписи и момент истечения ее срока годности.
Особый случай в контексте DNSSEC представляет собой отсутствие требуемых записей. Обычно в ответ на запрос несуществующей записи сервер возвращает сообщение с кодом ошибки, но при этом не передается никаких данных, которые можно было бы снабдить цифровой подписью. Получается, что сообщение об отсутствии требуемой записи не содержит подписи и поэтому может быть сфабриковано злоумышленником. Для решения этой проблемы вводятся записи типа NXT. Запись типа NXT указывает на следующее по алфавиту доменное имя зоны, например:

exmpl.ru.       IN  NXT gw.exmpl.ru. SOA NS MX SIG NXT

gw.exmpl.ru.    IN  NXT ns.exmpl.ru. A SIG NXT

ns.exmpl.ru.    IN  NXT specmail.exmpl.ru. A SIG NXT

Первая запись, например, говорит, что следующим после имени exmpl.ru в зоне exmpl.ru следует имя gw.exmpl.ru, при этом также указывается, что для имени exmpl.ru имеются записи типов SOA, NS, MX, SIG и NXT.
Теперь, если кто-либо запросит, например, записи типа А для knight.exmpl.ru, ему будет возвращена запись gw.exmpl.ru.    IN  NXT ns.exmpl.ru. A SIG NXT, которая говорит о том, что за gw сразу следует ns, и, следовательно, knight отсутствует в базе данных. Вместе с этой записью передается подписывающая ее запись SIG, которая таким образом удостоверяет информацию об отсутствии knight.exmpl.ru.
Если же, например, будет получен запрос на запись типа MX для ns.exmpl.ru, то будет возвращена запись ns.exmpl.ru.   IN  NXT specmail.exmpl.ru. A SIG NXT означающая, что, хотя ns и имеется в базе данных, но для этого доменного имени существуют только записи типов A, SIG и NXT, а, следовательно, запись типа MX отсутствует. Этот ответ, разумеется, также будет сопровождаться записью SIG.

Подпись публичного ключа вышестоящей зоной
Вернемся к ситуации, когда сервер ns.victim.com посылает запрос серверу ns.goodbank.com на предмет IP-адреса хоста www.goodbank.com. Теперь оба сервера поддерживают DNSSEC, то есть ns.goodbak.com снабжает отправляемые данные цифровой подписью, а ns.victim.com производит проверку подписи при получении данных. Предположим, злоумышленник способен перехватить трафик между ns.victim.com и ns.goodbank.com. Если злоумышленник изменит данные, возвращаемые сервером ns.goodbank.com - то есть, IP-адрес хоста www.goodbank.com, - то измененные данные не будут соответствовать цифровой подписи и ns.victim.com не примет сообщение. Привести цифровую подпись в соответствие с измененными данными злоумышленник не сможет, потому что не знает секретного ключа, которым шифруется хэш данных.
Однако, поскольку перехват трафика возможен по условию задачи, злоумышленник может применить более радикальный подход: он полностью заблокирует посылку данных от ns.goodbank.com к ns.victim.com и сам будет выступать от имени ns.goodbank.com. При этом данные он будет подписывать с помощью своего собственного секретного ключа. Что предпримет ns.victim.com, чтобы проверить подпись в сообщении, сфабрикованном злоумышленником? Ns.victim.com считает, что данные получены от ns.goodbank.com, следовательно, для проверки подписи требуется открытый ключ зоны goodbank.com. Чтобы получить его, надо запросить запись типа KEY для имени goodnank.com. Соответствующий запрос направляется серверу ns.goodbank.com и перехватывается злоумышленником, который в ответ от имени ns.goodbank.com возвращает свой открытый ключ, парный тому секретному ключу, с помощью которого он подписывает сфабрикованные сообщения. В итоге проверка подписи проходит успешно, и ns.victim.com принимает сфальсифицированные данные: отравление кэша состоялось
Для решения описанной проблемы требуется механизм удостоверения того факта, что данный открытый ключ действительно принадлежит зоне goodbank.com, а не сфабрикован злоумышленником, перехватывающим трафик. Решение состоит в том, что запись типа KEY для goodbank.com тоже снабжается цифровой подписью, то есть, записью типа SIG. Но эта цифровая подпись генерируется не с помощью секретного ключа зоны goodbank.com, а с помощью секретного ключа вышестоящей зоны, то есть зоны com. Для этого администратор goodbank.com должен отправить в администрацию зоны com свой открытый ключ вместе с какими-нибудь документами, подтверждающими то, что данный ключ действительно принадлежит goodbank.com. Естественно, что состав и способ передачи этих документов выходит за рамки DNSSEC. Администрация зоны .com подписывает открытый ключ goodbank.com с помощью своего секретного ключа и возвращает результат в виде SIG-записи администратору goodbank.com (рис. 3).
Таким образом, запросив открытый ключ зоны goodbank.com, ns.victim.com получает вместе с ним и запись типа SIG, содержащую цифровую подпись для этого ключа. Чтобы проверить подпись, серверу ns.victim.com требуется открытый ключ зоны com, который он запрашивает с ее официального сервера.

Теперь, если злоумышленник попытается выдать свой открытый ключ за открытый ключ зоны goobank.com, он не сможет создать для него цифровую подпись, потому что не знает секретного ключа зоны com. Следовательно, ns.victim.com откажется принимать открытый ключ злоумышленника в качестве ключа goodbank.com, и, соответственно, откажется принимать все данные, посылаемые злоумышленником от имени goodbank.com, потому что не может проверить их подлинность из-за отсутствия открытого ключа.
Однако злоумышленник, который в состоянии перехватить весь трафик от хоста ns.victim.com может выступить и от имени официального сервера зоны com и выдать свой ключ за ключ зоны com. Чтобы этого не случилось, открытый ключ зоны com тоже подписывается с помощью секретного ключа вышестоящей (корневой) зоны. Что касается открытых ключей самой верхней, корневой зоны, то считается, что они будут широко известны и, следовательно, их фальсификация будет немедленно обнаружена любым сервером DNS.
Очевидно, описанная схема будет работать только в том случае, когда все зоны от данной (goodbank.com) и до корневой включительно используют DNSSEC. Если же, например, у зоны com (еще) нет пары ключей, то администрации зоны goodbank.com придется распространить свой открытый ключ по всем заинтересованным серверам каким-то другим надежным способом (курьером?). Тогда, например, ns.victim.com внесет полученный ключ в свой файл /etc/named.conf:

trusted-keys {

goodbank.com. 256 3 1

"AQPdWbrGbVv1eDhNgRhpJMPonJfA3reyEo82ekwRnjbX7+uBxB11BqL7LAB7/C+eb0vCtI53FwMhkkNkTmA6bI8B";

};

чем защитит себя от обмана злоумышленником.

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

Инструментарий DNSSEC
В заключение раздела, посвященного DNSSEC, перечислим программы из пакета BIND 9, предназначенные для генерации ключей и записей SIG и NXT.

Напомним, что создание подписей необходимо периодически производить заново, так как записи SIG имеют ограниченный срок годности (по умолчанию - 30 дней).
Если разрешено динамическое обновление зоны, то при добавлении или удалении записи из базы данных, все необходимые записи SIG и NXT будут рассчитываться (пересчитываться) автоматически, на лету. Естественно, что администратор зоны должен обеспечить безопасность при выполнении динамического обновления, то есть задействовать механизм TSIG для аутентификации команд, иначе использование DNSSEC для данной зоны не имеет смысла.

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

Возможно, некоторые организации не хотели бы, чтобы на них можно было составить подобное досье. С помощью директивы allow-transfer BIND позволяет ограничить список хостов, которым разрешена передача зоны:

zone "exmpl.ru." {
   type master;
   file "exmpl.hosts";
   allow-transfer {1.16.193.34 ; };
};
zone "sub.exmpl.ru." {
   type slave;
   masters { 1.16.196.130; };
   file "sub.exmpl.hosts";
   allow-transfer { none ; };
};

Тем не менее, при использовании DNSSEC это ограничение не имеет большого смысла, поскольку, запрашивая по цепочке записи NXT, любой желающий может получить список всех записей зоны, а при необходимости, естественно, запросить и любую запись.
Подчеркнем, что правила хорошего тона требуют, чтобы все компьютеры организации, имеющие непосредственный доступ в Интернет, были зарегистрированы в DNS - как в <прямой>, так и в обратной зонах. Корректная регистрация компьютера является признаком того, что данный IP-адрес, домен или доменное имя легитимны и находятся под определенным административным контролем. Многие программы-серверы проводят проверку адреса подсоединяющегося клиента двойным DNS-преобразованием. Транспортные агенты электронной почты также проверяют доменные имена в адресах отправителя и получателя. Некорректная регистрация компьютера (несоответствие данных <прямой> и обратной зон) или вовсе отсутствие регистрации может привести к тому, что пользователю будет отказано в обслуживании многими серверами Интернета.
Если администратор хочет сделать информацию о своей сети действительно конфиденциальной, ему следует поместить компьютеры, не имеющие публичных Интернет-сервисов, за брандмауэр, а в открытой сети (и, соответственно, в доступной из Интернета базе данных DNS) оставить только узлы, которым необходимо непосредственно взаимодействовать с узлами Интернет. Как минимум, это почтовый сервер организации, публичный WWW-сервер, сам DNS-сервер, прокси-сервер (брандмауэр), маршрутизатор-шлюз.
По возможности, узлам, видимым из Интернета, следует давать нейтральные имена, не отражающие их функционального назначения. Предположим, злоумышленник, прослушивающий сеть в своей организации, определяет, с какими узлами взаимодействуют компьютеры его сети, и выполняет над IP-адресами обратные DNS-преобразования. При этом есть основания полагать, что сеанс связи с хостом corn-flower.goodbank.com заинтересует его гораздо меньше, чем если бы этот хост назывался user-account-server.goodbank.com. Конечно, не стоит таким образом изменять имена публичных серверов: WWW-сервера, сервера DNS, почтового сервера.

DNS и брандмауэры
Рассмотрим особенности работы DNS в сети предприятия, защищенной брандмауэром. Наличие брандмауэра оказывает воздействие на работу и использование DNS:

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

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

Расщепленные зоны
Политика безопасности предприятия может быть такова, что некоторым (обычно - большинству) хостам внутренней сети запрещено обмениваться датаграммами с любыми узлами Интернета. Сервисы Интернета предоставляются для таких хостов с помощью прокси-серверов, а датаграммы, направленные к или от прокси-серверов пропускаются фильтрующим маршрутизатором.
Таким образом, нет никакой необходимости вносить информацию о невидимых для Интернета хостах в базу данных DNS предприятия, по которой обслуживаются запросы, приходящие из Интернет. Кроме того, из общих соображений безопасности следует по возможности избегать предоставления избыточной информации о своем предприятии (пример того, как она может быть использована, приводился выше).
С другой стороны внутренние хосты должны иметь возможность взаимодействовать друг с другом в рамках корпоративной сети. Следовательно, должно существовать две версии базы данных DNS: одна для внутреннего пользования, другая - видимая из Интернета, являющаяся подмножеством первой. Такой подход называется расщеплением зоны (split namespace).
Очевидно, что все DNS-серверы, находящиеся во внутренней сети, пользуются полной версией. Форвардер, расположенный во внешней сети, должен иметь обе версии: по сокращенной версии он обслуживает запросы, поступающие из Интернета, а полную версию использует сам для связи с внутренними хостами. Форвардер выступает также как первичный сервер сокращенного варианта зоны.
Сконфигурировать сервер для работы с двумя версиями зоны можно с помощью функции view, имеющейся в BIND 9. Пример конфигурации форвардера приведен ниже.
Определяем список адресов клиентов, которым

# разрешено пользоваться внутренней, полной версией.

# Включаем туда свой локальный адрес 127.0.0.1

acl "internal" {

                                127/8; 1.16.195.0/24;

};

# определяем <вид изнутри>

view "internal" {

                                match-clients { "internal"; };

                                recursion yes;

                                zone "exmpl.ru" {

                                                type slave;

                                                masters { 1.16.195.98; };

                                                file "exmpl.hosts.tmp";

                                };

# ...

# аналогично перечисляем все зоны предприятия,

# не забывая обратные - для краткости пропущено

# ...

                                zone "." {

                                                type hint;

                                                file "root.cache";

                                };

};

# определяем <вид снаружи> - используются

# другие файлы баз данных

view "external" {

                                match-clients { any; };

                                recursion no;

# наш вторичный сервер, размещенный у провадера

                                acl "ns1.isp.net" { 1.2.3.4; };

                                zone "exmpl.ru.edu" {

                                                # для внешнего варианта первичный сервер - мы

                                                type master;

                                                file "exmpl.ru.external";

                                                allow-transfer { "ns1.isp.net"; };

                                };

# ...

# аналогично перечисляем другие зоны предприятия,

# видимые снаружи, указывая файлы, содержащие их

# <внешние> версии - для краткости пропущено.

# Отметим, что некоторые внутренние зоны могут быть

# вообще снаружи не видны и соответственно здесь

# не указываются.

# ...

                                zone "." {

                                                type hint;

                                                file "root.cache";

                                };

};

Литература

[1] Мамаев М., Петренко С. <Технологии защиты информации в Интернете> - СПб: <Питер>, 2002.

[2] Карпов Г. <Атака на ДНС> (http://www.hackzone.ru/articles/dns-poison.html)