Другими словами, у «злых хакеров», хорошо владеющих интернет-технологиями, есть возможность направить по ложному адресу даже те пользовательские компьютеры, которые подключены к Интернету через добросовестных провайдеров, чьи сетевые администраторы следят за работой своих DNS-серверов. Более того, существует целый класс атак на DNS, которые используют особенности меж-серверного взаимодействия внутри системы доменных имен. Здесь непосредственной целью являются сами DNS-серверы (а точнее – данные в их адресных таблицах), но конечная задумка практически всякой такой атаки – введение в заблуждение либо компьютеров конечных пользователей, либо других серверов (не имеющих отношения к DNS). Для чего? Обычно для того, чтобы получить доступ к закрытым информационным ресурсам, перехватить пароли для управления теми или иными сервисами, считать из удаленной и обособленной (в организационном плане) компьютерной сети какие-либо данные.

Атаки через уязвимости DNS могут быть чрезвычайно эффективны. Тем не менее системной защиты от них в Интернете пока нет (2013 год), она только вводится в строй. Впрочем, неверно думать, будто специалисты лишь недавно разгадали уязвимости DNS. О фундаментальных недостатках этого механизма адресации известно уже много лет, можно сказать, с самого рождения DNS.

Возникает вопрос: почему за все эти годы не внедрили какие-нибудь исправления протоколов, корректирующие ситуацию? Ответ на этот вопрос такой: только недавно практический ущерб от уязвимостей DNS стал выглядеть весомым в глазах достаточного числа специалистов, продвигающих и внедряющих новые интернет– технологии. Ранее возможные затраты на внедрение изменений в работе DNS в сумме с риском вовсе потерять связность доменной системы имен в процессе изменения протоколов легко перевешивали практический вред от использования уязвимостей. Другими словами, довольно сложно убедить инертное провайдерское сообщество Интернета (у членов которого, будем говорить прямо, проблемы безопасности конечных пользователей не являются первоочередными) ввести ту или иную новую сложную технологию в дополнение к хорошо работающей и простой или вместо нее. Нужно заметить, что внедрение в DNS всякой функциональности «управления доверием» значительно усложняет систему, повышает требования к оборудованию и обслуживающему персоналу. То есть в конечном итоге защита DNS напрямую связана с прибыльностью провайдеров.

Впрочем, это лишь одна часть проблемы. Другая часть, не менее важная, имеет отношение к политическим факторам, как и следует ожидать в Глобальной сети. Подробнее о них – чуть ниже, а сейчас остановимся на том решении проблем безопасности DNS, непосредственное внедрение которого в Глобальной сети начато в 2010 году.

Итак, для реализации «более безопасной DNS» используется технология DNSSEC. Она позволяет, с одной стороны, удостоверять данные в адресных таблицах и, с другой стороны, дает в руки конечным клиентам средства для проверки достоверности сообщаемой тем или иным сервером адресной информации. DNSSEC – расширение DNS, подразумевающее внесение изменений в структуры данных, используемые доменной системой, и в программное обеспечение, реализующее функции DNS на серверах и клиентах. Важнейшим моментом здесь является внедрение системы именно на клиентских компьютерах, на компьютерах обычных пользователей. Такое возможно, например, на уровне браузера или операционной системы.

В рамках этой книги мы не станем подробно изучать криптографические механизмы, лежащие в основе DNSSEC, чтобы не перегружать читателя технической информацией. Однако для понимания принципов работы одного из главнейших обновлений DNS нужно в самых общих чертах представить себе основные понятия новой системы. Такие знания тем более полезны, что DNSSEC использует стандартные подходы, встречающиеся в большом количестве других современных систем безопасности.

Несколько десятков лет назад криптографами были разработаны методы, позволяющие создавать так называемые цифровые подписи, удостоверяющие подлинность заданного набора данных. Предположим, что у нас имеется запись о соответствии имени домена и IP-адреса. В рамках DNSSEC в строгое соответствие этой записи ставится специальная последовательность байтов, представляющая собой цифровую подпись. Главная особенность «подписывания» заключается в том, что есть простые и, самое главное, публично доступные (открытые) методы проверки достоверности подписи, а вот генерирование подписи для произвольных данных требует наличия секретного ключа в распоряжении подписывающего. То есть проверить подпись может каждый участник системы, а подписать что-либо, используя доступные вычислительные ресурсы и за разумное время (это очень важное дополнение), – только обладатель секретного ключа. На первый взгляд, это может показаться парадоксальным. Тем не менее именно так работают асимметричные системы шифрования с открытым ключом, лежащие в основе алгоритмов цифровой подписи.

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

Теперь для других участников, использующих DNSSEC, доступна информация об адресации и связанная с этой информацией цифровая подпись. Для проверки подписи используется открытый ключ из пары, принадлежащей администратору, который также опубликован. Для проверки, которая выполняется по специальному, известному всем участникам DNSSEC алгоритму, используются файл данных об адресации, файл с соответствующей цифровой подписью и открытый ключ. Заметьте, что открытый ключ дает возможность проверять достоверность подписи, но не позволяет за разумное время вычислять новые подписи для измененных данных. Важная особенность цифровой подписи в том, что при изменении подписываемых данных изменяется и сама подпись, поэтому просто скопировать подпись от одних данных и «прицепить» ее к другим не получится.

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

Все бы хорошо, но, если чуть тщательнее обдумать предложенную только что схему, можно найти неприятный момент. Предположим, злоумышленник не только изменил адресную информацию, но еще и подписал ее, используя собственный секретный ключ, а соответствующий открытый ключ (для проверки подписи) подсунул ничего не подозревающей жертве вместе с обманными данными DNS. И вообще, каким образом получатель адресной информации может убедиться, что тот, кто ему эту информацию передает, действительно уполномочен управлять данным доменом? Может, отвечающий сервер подставной? Сама по себе верность цифровой подписи не гарантирует того, что достоверно и содержание заверенных этой подписью данных. Выходит, даже внедрив «хитрые» подписи, мы остались все при тех же проблемах доверия?

Так и есть: одними подписями обойтись не удается. Требуется механизм, позволяющий удостоверять полномочия источников этих подписей. В DNSSEC для создания этого механизма должна использоваться естественная иерархия прав, уже существующая в доменной системе имен. То есть на базе системы делегирования прав администраторам доменов, о которой подробно рассказано несколькими главами выше, создается механизм подписывания ключей. Так, достоверность источника ключа для какого-либо домена удостоверяется с помощью цифровой подписи, исходящей от вышестоящего «удостоверяющего центра», подпись этого центра удостоверяет другой, стоящий еще выше в иерархии, а в итоге образующаяся «цепочка доверия» сводится с корневому домену и корневому ключу. Этот ключ должен быть распространен по всем участникам DNSSEC независимо от DNS. Например, он может быть встроен в операционные системы. Корневой ключ – главный ключ всей системы, позволяющий проверить достоверность любой подписи на всех прочих уровнях, – принадлежит той организации, которая отвечает за достоверность DNS в целом, и поэтому, строго говоря, этот ключ не может являться частью DNS.