И вот Алиса ищет IP-адрес bob.com и узнает, что он равен 42.9.9.9. Как мы знаем, это адрес Труди, которая провела успешную атаку типа «человек посередине», не выходя из своей комнаты. Последовательность предпринятых ею шагов, пронумерованных в соответствии с рассмотренным выше вариантом, показана на рис. 8.43. Избежать атак описанного типа можно, заставив DNS-серверы использовать случайные идентификаторы в своих запросах вместо того, чтобы просто инкрементировать их. К сожалению, заткнув одну «дыру», мы обнаруживаем другую. Например, ID всего лишь шестнадцатибитовые, так что работать со всеми ними легко, когда компьютер совершает подстановки.
Рис. 8.43. Обман провайдера Алисы
Защита DNS
Настоящая проблема в том, что служба DNS разрабатывалась в те времена, когда Интернет был чисто исследовательской сетью, работавшей в нескольких сотнях университетов, и ни Алиса, ни Боб, ни Труди на этот праздник жизни приглашены не были. Вопрос защиты информации тогда еще не стоял; задача максимум была заставить Интернет функционировать. Но с годами среда, в которой приходилось выживать Интернету, сильно изменилась, поэтому в 1994 году IETF основала рабочую группу, задачей которой было защитить DNS. Этот (продолжающийся) проект известен под названием DNSsec (DNS Security — защита DNS); первые результаты работы группы опубликованы в RFC 2535. К сожалению, DNSsec до сих пор не удается развернуть в больших масштабах, поэтому многие DNS-серверы продолжают подвергаться нападениям злоумышленников.
Концептуально система DNSsec очень проста. Она основана на шифровании с открытыми ключами. Каждая зона DNS (в терминах рис. 7.2) обладает парой ключей, а именно открытым и закрытым. Вся информация, отправляемая DNS-сервером, подписывается с помощью закрытого ключа зоны отправителя, поэтому аутентичность может быть запросто проверена принимающей стороной.
DNSsec предоставляет три основные услуги.
1. Подтверждение места отправления данных.
2. Распространение открытых ключей.
3. Аутентификацию транзакций и запросов.
Самой главной является первая услуга, с ее помощью проверяется то, что пришедшие данные были подтверждены их отправителем. Вторая услуга полезна для безопасного хранения и извлечения открытых ключей. Третья позволяет защититься от атак повторного воспроизведения и обмана сервера. Обратите внимание: секретность здесь не обеспечивается, этой задачи нет, поскольку вся информация DNS считается открытой. Так как процесс введения DNSsec в строй, скорее всего, будет продолжаться в течение нескольких лет, важно предоставить возможность общения между собой серверам, снабженным системой защиты и не снабженным ею. Это неявно подразумевает, что протокол изменять нельзя. Рассмотрим теперь эту систему чуть более детально.
Записи DNS группируются в наборы, называемые RRSet (Resource Record Set — набор записей ресурсов). В набор входят все записи с одинаковыми именами, классами и типами. Скажем, в наборе может быть несколько записей A, если имя DNS соответствует первичному и вторичному IP-адресам. Наборы расширяются за счет некоторых новых типов записей (обсуждаются ниже). Каждый RRSet хэшируется (например, с использованием SHA-1). Хэш подписывается при помощи закрытого ключа зоны (например, по алгоритму RSA). Единицей передаваемой клиентам информации является подписанный RRSet. Получив его, клиент может проверить, действительно ли для генерации подписи был взят закрытый ключ зоны отправителя. Если подпись корректна, данные принимаются. Так как каждый RRSet содержит собственную подпись, наборы можно кэшировать где угодно, даже на не слишком надежных серверах, не опасаясь за их судьбу.
Система DNSec вводит несколько новых типов записей. Первая из них — это запись KEY. В ней хранятся открытый ключ зоны, пользователя, хоста или другого принципала, криптографический алгоритм генерации подписи, наименование протокола передачи и еще несколько бит. Открытый ключ хранится в незащищенном виде. Сертификаты X.509 не используются из-за их громоздкости. В поле алгоритма рекомендуемое значение, соответствующее MD5/RSA, равно 1, для других комбинаций используются другие значения. Поле протокола может указывать на использование IPsec или другого протокола защиты соединений (если таковой вообще применяется).
Второй новый тип записей — SIG. В такой записи содержится подписанный хэш, сформированный в соответствии с алгоритмом, указанным в KEY. Подпись охватывает все записи RRSet, включая все записи KEY, однако не включая саму себя. Здесь также содержатся время начала и конца действия подписи, имя владельца подписи и некоторая дополнительная информация.
Система DNSsec устроена так, что закрытый ключ зоны может храниться в автономном режиме. Один или два раза в день содержимое базы данных зоны можно вручную переносить (например, записав компакт-диск) на машину, работающую в автономном режиме и хранящую закрытый ключ. Там можно сгенерировать подписи для всех наборов, и полученные таким образом записи SIG можно снова записать на компакт-диск и перенести на главный сервер. Таким образом, закрытый ключ можно хранить на компакт-диске, запертом в сейфе и вынимаемом только для того, чтобы подписать на автономной машине ежедневное обновление наборов типа RR-Set. По окончании генерации подписей все копии ключа удаляются из памяти, а диск и компакт-диск возвращаются в сейф. Эта процедура превращает электронную защиту информации в физическую, что гораздо понятнее пользователям.
Метод предварительного подписания наборов значительно ускоряет процесс обработки запросов, так как отпадает необходимость в шифровании «на лету». Платой за это является большой объем дискового пространства, необходимого для хранения всех ключей и подписей в базах данных DNS. Из-за этого некоторые записи увеличиваются в размере десятикратно.
Получив подписанный RRSet, клиент должен применить открытый ключ зоны для расшифровки хэша, затем вычислить хэш самостоятельно и сравнить два значения.
В случае их соответствия данные считаются корректными. Тем не менее эта процедура не решает вопрос получения клиентом открытого ключа зоны. Одним из способов является запрос ключа у надежного сервера и передача его по защищенному соединению (например, при помощи IPsec).
Однако на практике предполагается, что у клиентов уже есть открытые ключи всех доменов верхнего уровня. Если Алиса пожелает посетить сайт Боба, она запросит у службы DNS набор RRSet для bob.com, в котором будет содержаться IP-адрес и запись KEY с открытым ключом Боба. RRSet будет подписан доменом верхнего уровня (com), поэтому Алиса запросто сможет проверить подлинность набора. Пример содержимого набора RRSet приведен в табл. 8.4.
Таблица 8.4. Пример набора RRSet для bob.com. Запись KEY содержит открытый ключ Боба. Запись SIG — это хэш A и KEY, подписанный сервером домена верхнего уровня (com) для проверки их аутентичности
Имя домена
Время жизни
Класс
Тип
Значение
bob.com.
86400
IN
A
36.1.2.3
bob.com.
86400
IN
KEY
3682793A7B73F731029CE2737D™
bob.com.
86400
IN
SIG
86947503A8B848F5272E53930C...
Теперь, вооружившись заверенной копией открытого ключа Боба, Алиса может узнать у DNS-сервера Боба IP-адрес www.bob.com. Этот RRSet будет подписан закрытым ключом Боба, поэтому Алиса сможет проверить подлинность подписи возвращенного Бобом набора. Если злоумышленнику каким-то образом удастся внедрить фальшивый RRSet в один из кэшей, Алиса заметит это, так как запись SIG будет неправильной.
Тем не менее DNSsec также предоставляет криптографический механизм для связывания ответов с соответствующими запросами, предотвращающий атаки типа той, что показана на рис. 8.43. Эта (необязательная) мера заключается в добавлении к ответу хэша запроса, подписанного закрытым ключом опрашиваемого. Поскольку Труди неизвестен закрытый ключ сервера верхнего уровня (домена com), она не сможет подделать ответ этого сервера на запрос провайдера Алисы. Она, конечно, может опередить настоящий ответ, но фальшивка будет замечена по неправильной подписи хэшированного запроса.
