DNSSEC

DNSSEC
Современный интернет немыслим без DNS. Придуманная в начале 80-х годов прошлого
века система доменных имён сейчас прочно легла в фундамент практически всех
действий, осуществляемых рядовыми пользователями глобальной Сети. Поиск сайтов в
поисковой машине использует DNS для переходов по ссылкам в выдаче поисковика.
Навигация по знакомым сайтам с помощью набора имени домена в адресной строке тоже
базируется на DNS. Отправляете электронную почту - опять же никуда без DNS.
Система доменных имён сейчас настолько привычна, что типичный пользователь
интернета вообще не задумывается о её существовании. Ну, в лучшем случае о DNS
вспоминают особенно продвинутые пользователи интернета, да и то лишь тогда, когда с
этой системой возникают проблемы. В таких случаях опытные интернетчики с
готовностью подсказывают начинающим веб-сёрферам: «Записывайте IP-адреса! Скоро
только по ним можно будет отыскать сайты!». Действительно, внутри Сети незаметно для
пользователя компьютеры, подключенные к интернету, находят друг друга с помощью
числовых IP-адресов. Символьная же запись, связать которую с IP-адресами позволяет
DNS, нужна лишь для людей.
Другими словами, DNS входит в число ключевых элементов интернета. Однако при этом
DNS - одна из самых незащищённых систем адресации в истории компьютерных сетей.
Парадоксально? Может быть, но такова реальность. В 80-х годах прошлого века
безопасности DNS не уделили должного внимания, хотя о недостатках специалисты
знали.
Характеристики информационной безопасности классической DNS можно описать одной
фразой: эта система работает на доверии. То есть хорошо функционировать DNS может
лишь тогда, когда все стороны, участвующие в системе, полностью доверяют друг другу и
друг друга не обманывают.
Важнейший аспект информационной безопасности - достоверность данных. Особенно
этот аспект актуален для систем адресации. При этом в DNS, можно сказать, нет никаких
строгих механизмов обеспечения достоверности данных. Попробуем разобраться на паре
примеров.
Итак, предположим, что рядовой пользователь интернета со своего домашнего
компьютера планирует зайти в интерфейс электронной платёжной системы. Пользователь
набирает в адресной строке браузера «Платёжка.ru» (для удобства мы используем
кириллические адреса) и нажимает «Enter». Что происходит дальше? А дальше в
подавляющем большинстве случаев компьютер пользователя спрашивает один из
известных ему серверов DNS об IP-адресе узла, соответствующего домену «Платёжка.ru»,
и в ответ сервер DNS присылает некий IP-адрес. Далее запросы браузера передаются узлу
с данным IP-адресом. При этом сервер, обслуживающий запросы компьютера
пользователя к DNS, скорее всего, принадлежит интернет-провайдеру, предоставляющему
этому пользователю доступ к глобальной Сети.
Ни браузер, ни пользователь не имеют в рамках DNS возможности проверить, что
полученные в ответ на запрос данные об IP-адресе некоторого узла Сети действительно
указывают на настоящий сервер платёжной системы, который должен быть размещён под
доменом «Платёжка.ru». Вполне возможно, что ответ DNS подделан на том или ином
этапе обработки запроса. Самый банальный вариант: ответ подделан на DNS-сервере
интернет-провайдера. Нет, вовсе не обязательно, что на подлог осознанно пошёл
провайдер, просто его компьютерные системы могли быть взломаны хакерами.
Но шут с ним, с провайдером. Прежде нужно понять, чем грозит использование
фиктивного ответа DNS в качестве руководства к действию. А грозит оно вот чем:
полученный IP-адрес может указывать на сервер злоумышленников, где расположен
поддельный сайт платёжной системы. С виду этот сайт такой же, как и настоящий - это
несложно устроить. А то, что и адрес в браузере соответствует привычному, только ещё
больше убедит пользователя, что он зашёл именно на правильный сайт и всё в порядке. А
тем временем сайт-наживка выманит у пользователя все его пароли к электронным
кошелькам. Нужно ли сомневаться, что эти пароли тут же будут использованы
мошенниками?
Только что описанный пример с фишерской атакой, использующей подделку DNS, –
наиболее простой и очевидный, что, впрочем, нисколько не отменяет его
востребованности у сетевых мошенников. Но возможны и многие другие, куда более
изощрённые способы применения фундаментальных уязвимостей в DNS.
Ещё история из реальности. Один из небольших интернет-провайдеров, содержащий так
называемую домовую сеть, с помощью подделки ответов DNS перенаправлял браузеры
своих пользователей таким образом, что они не могли соединиться с сайтом крупного
конкурента. Конкурент предлагал гораздо более выгодные тарифы на доступ к интернету,
и администраторы домовой сети опасались, что все клиенты уйдут, а сеть разорится.
Поэтому администраторы и настроили серверы DNS «мошенническим» способом.
Впрочем, подлог всё равно вскрылся. Клиенты, многие из которых даже не подозревали,
что интернет-провайдер может контролировать все их действия в Сети, разбежались по
конкурентам минимум вдвое быстрее. Домовая сеть разорилась.
Проблемы достоверности в DNS существуют не только на уровне взаимодействия между
конечными пользователями и провайдерами. Обману и успешным хакерским атакам
подвержены и сами провайдеры разных уровней, владеющие DNS-серверами. Протоколы
DNS подразумевают обмен информацией об адресации между серверами DNS, а эта
информация тоже может стать объектом атаки злоумышленников. В результате адресные
данные будут изменены, а владельцы DNS-серверов об этом могут и не узнать.
Более того, атаки, использующие собственно DNS, могут служить базой для проведения
сложных многоступенчатых атак по вторжению в различные защищённые компьютерные
сети. Оказывается, для того, чтобы использовать уязвимости протоколов DNS, хакерам
вовсе не обязательно контролировать точку подключения в той сети, в которой работает
атакуемая система. Напротив, глобальная DNS позволяет и атаки проводить в глобальном
масштабе.
Иными словами, DNS крайне важна и совсем не защищена.
Нельзя сказать, что специалисты только недавно узнали о фундаментальных уязвимостях
в DNS. Это не так. Наоборот, то, что доменная система имён не имеет механизмов защиты
от атак, специалистам известно очень давно, многие годы. Поэтому не стоит слишком
всерьёз воспринимать шумиху в околокомпьютерной прессе, разгорающуюся каждый раз,
как тот или иной аналитик публикует сообщение о новой глобальной уязвимости. Да,
свеженайденные уязвимости действительно существуют и весьма важны. Нужно только
понимать, что все они представляют собой лишь конкретные практические реализации
атак, подтверждающие верность старых теоретических выкладок, описывающих наличие
соответствующих дыр в протоколах. Собственно, сами специалисты по компьютерной
безопасности, сообщившие об обнаружении нашумевших в прессе уязвимостей, сразу
оговаривали, что речь идет о воплощении давно известных фундаментальных дефектов.
Время пришло ?
Попытки сделать DNS защищённой системой предпринимались чуть ли не сразу после
широкого распространения этой системы в глобальной Сети. Однако для того, чтобы
приблизиться к практической реализации защиты, потребовалось совпадение сразу
нескольких факторов, потому что одного лишь желания «теоретиков» DNS не хватало.
С одной стороны, атаки на основе уязвимостей DNS, так сказать, нагуляли серьёзный вес,
приобрели масштаб и стали создавать заметные имиджевые проблемы интернетпровайдерам, крупным телекоммуникационным компаниям и структурам, управляющим
интернетом. Надо заметить, что наивно было бы полагать, будто забота о безопасности
конечных пользователей, увлекаемых мошенниками в сети фишинга, - это всегда
первоочередная проблема интернет-провайдеров или телекоммуникационных компаний
вообще. К сожалению, для коммерческих компаний (а интернет-провайдеры - компании
коммерческие) безопасность пользователей становится сколько-нибудь приоритетной
лишь с того момента, как провайдер начинает терять на этой безопасности деньги.
Общественные организации и объединения, связанные с управлением интернетом,
конечно, готовы больше внимания уделять защите рядового веб-путешественника. Но что
они могут без поддержки провайдеров?
С другой стороны, появились надежды, что будет закупаться новое оборудование,
позволяющее реализовать защиту в DNS. Дело в том, что функции защиты (тут
потребуется криптография, о которой мы поговорим чуть ниже) не только подразумевают
осуществление множества достаточно сложных по сравнению с классической DNS
вычислительных операций, но и потребуют увеличения объёмов сетевого трафика,
приходящегося на DNS-сообщения. Возросшая нагрузка требует увеличения
вычислительной мощности узлов DNS и некоторых других компьютеров, входящих в
состав интернета. То есть придётся закупать новые серверы, новые маршрутизаторы и так
далее. Впрочем, в последние годы стоимость подобного оборудования в пересчёте на
производительность заметно снижается, так что надежда на финансирование закупок есть.
Итак, сейчас образовался довольно благодатный фон для того, чтобы осуществить
превращение DNS, о необходимости которого так долго твердили.
В основе DNSSEC лежат алгоритмы криптографии с открытым ключом. Подробный
разбор механизмов DNSSEC потребует как минимум большой отдельной статьи. Однако
общие принципы можно описать в нескольких абзацах.
Итак, суть DNSSEC в том, что адресная информация в DNS может быть подтверждена с
помощью цифровой подписи. В дальнейшем любой желающий может убедиться в
достоверности адресных данных, проверив соответствующую цифровую подпись. Если
утрировать ситуацию, то можно сказать, что цифровая подпись - это последовательность
байтов со строго определёнными значениями, зависящая от тех данных, которые
подтверждаются этой подписью.
То есть к адресной информации в ответе, например, DNS-сервера добавляется строка
байтов, представляющая собой цифровую подпись. Конкретная подпись, если говорить в
общих чертах, валидна только для тех данных, которые ей подписаны.
Поэтому отрезать подпись от одних данных и приставить к другим на практике не
получится. Тут, впрочем, нужно обязательно отметить в скобках, что, в теории, для всех
современных практических алгоритмов электронной подписи одна и та же подпись может
соответствовать разным данным. Фокус в том, что на практике вероятность подобного
совпадения пытаются свести к незначительной величине.
Понятно, что генерировать подпись для заданного набора данных должен администратор,
ответственный за эти данные и, что важно, обладающий признаваемой другими
участниками авторизацией. Но об этом ниже.
Итак, для того, чтобы оборот цифровых подписей оказался возможен, используется пара
криптографических ключей: закрытый, секретный ключ и соответствующий ему
открытый ключ. Закрытый ключ позволяет с помощью криптографических алгоритмов
сгенерировать цифровую подпись для исходных данных. Открытый ключ позволяет
только проверить достоверность предъявленной подписи относительно этого ключа и
сопоставленных с подписью данных. Закрытый ключ, позволяющий подписывать данные,
сохраняется в тайне. Открытый ключ доступен всем желающим проверять подписи.
У многих людей, впервые сталкивающихся с современной криптографией, возникает
некоторое недоумение: как же так получается, что открытый ключ позволяет проверять
подписи, но не позволяет самостоятельно подписывать другие данные? Дело в том, что,
конечно, нет никакого строгого теоретического запрета на вычисление закрытого ключа
на основе открытого или запрета на генерирование валидной цифровой подписи для
произвольного текста или данных из таблицы адресации с помощью лишь открытого
ключа.
Криптографическая смекалка проявляется тут в том, что такая задача очень трудна для
сколько-нибудь сложных ключей. Другими словами, раскрыть секретный ключ можно, но
при современном состоянии математики для этого потребуется невообразимое количество
вычислительных ресурсов, недоступное на практике. Так что криптография с открытым
ключом не обладает строгой теоретической стойкостью, но пока не подводила на
практике. Все эти моменты следует иметь в виду, размышляя о нагрузке на DNS,
создаваемой DNSSEC, о механизмах обновления ключей и о надёжности новой
технологии в перспективе, ведь DNS предстоит существовать ещё долгие годы.
Итак, процесс придания достоверности данным DNS c помощью цифровых подписей
может выглядеть приблизительно так. Администратор какой-либо доменной зоны,
поддерживающей нужную технологию, с помощью известного ему секретного ключа
подписывает адресную информацию цифровой подписью. После этого цифровая подпись
передаётся потребителям адресной информации вместе с ответом DNS-сервера.
Соответствующий открытый ключ администратор зоны публикует общедоступным
образом. Теперь потребитель адресной информации получает возможность проверить
достоверность данных, полученных в ответе DNS: с помощью открытого ключа
проверяется валидность сопровождающей ответ цифровой подписи. Принимать в качестве
руководства к действию будут только корректно подписанные данные.
В новой среде жизнь хакера усложняется. Предположим, что хакер подделывает ответ
DNS. Однако теперь подобный подлог вскрывается после проверки, так как хакер не
имеет доступа к секретному ключу и не может корректно подписать изменённые данные.
И всё? Проблема решена? К сожалению, если чуть подробнее взглянуть на только что
описанный механизм безопасности, то станет понятно: пробелы в безопасности остались
ровно те же, что и раньше.
Действительно, если хитрый хакер умеет подделывать ответы DNS, то логичным будет
допущение, что он сможет подделать и пару ключей, необходимых для работы с
цифровыми подписями. Да, вычислить секретный ключ по открытому чрезвычайно
трудно. Но хакер может легко сгенерировать собственную пару ключей и подписать
подложные данные DNS с помощью секретного ключа из этой пары, а соответствующий
открытый ключ также подсунуть жертве атаки, выдав его за ключ правомерного
администратора зоны. При проверке хакерской подписи относительно хакерского
открытого ключа жертва не сможет обнаружить подлог. Более того, думая, что работает с
данными, достоверность которых подтверждена цифровой подписью, наивный
пользователь интернета вообще может утратить бдительность: ложное чувство
безопасности - страшная вещь.
Выходит, что введение цифровой подписи лишь сместило фокус проблемы. Раньше
вопрос сводился к тому, можно ли доверять открытым данным из таблиц DNS. Теперь
вопрос сводится к тому, можно ли доверять конкретному открытому ключу из той же
самой DNS. Парадоксальная катастрофа надежд. Или нет?
Да, само по себе внедрение цифровых подписей на том или ином сервере совершенно не
решает проблемы доверия. Именно поэтому DNSSEC содержит в себе море
дополнительных механизмов управления доверием. Именно поэтому, к сожалению, о
развёртывании DNSSEC в глобальном масштабе интернета ещё нельзя говорить, несмотря
на то, что некоторое число доменов первого уровня технологию уже поддерживает. Но
обо всём по порядку.
Цифровые подписи дают механизм для создания управляемой иерархии доверия, которую
нельзя было бы выстроить средствами классической DNS. Оказывается, открытый ключ, с
помощью которого предполагается проверять подписанные адресные данные, также
может быть удостоверен кем-то, каким-то другим «нотариусом». Теперь потенциальная
жертва хакерской атаки получает возможность проверить не только подпись у данных, но
и сам открытый ключ, задействовав третью сторону. Так как, предположим, хакер не
может подписать свой поддельный ключ у этой третьей стороны, то и описанная выше
атака с подменой пары ключей и подписи не удастся.
Понятно, что ключ удостоверяющего «нотариуса», которого правильнее будет называть
удостоверяющим центром, тоже нуждается в проверке. Этот ключ может подписать
доверенный центр уровнем выше. И так далее. Здесь естественным для
криптографических систем цифровой подписи образом создается цепочка
удостоверяющих центров, или иерархия доверия, очень актуальная и для DNSSEC.
Потребитель адресной информации сам выбирает, каким центрам он готов доверять, и,
используя открытые ключи этих центров, получает возможность проверять достоверность
данных, полученных от тех узлов, за благонадёжность которых поручились
удостоверяющие центры.
На практике оказывается, что иерархия удостоверяющих центров завязана на так
называемый корневой центр, обладающий корневой парой ключей. С их помощью
подписаны ключи центров уровнем ниже, что позволяет заинтересованному лицу все эти
ключи проверить. Корневой ключ крайне важен, и не только технологически, но и
политически. Особенно это важно, если речь идёт о DNSSEC.
DNSSEC позволяет довольно гибко подойти к вопросам построения цепочек доверия.
Именно эта особенность технологии позволяет вводить DNSSEC в отдельных сегментах
адресного пространства интернета или даже в отдельных локальных компьютерных сетях.
А вот с глобальным масштабом возникает проблема. Дело тут вот в чём. Важнейшая
задача, решаемая с помощью DNSSEC, вовсе не является чисто технологической,
напротив, это скорее административная задача. Состоит эта задача в том, чтобы
гарантировать, что каждый участник DNS в ответ на свой запрос получает из системы
именно те данные, которые туда поместил администратор, юридически ответственный за
тему запроса. Спросили про site.test.ru - получите ответ, подготовленный на основе
данных администратора, уполномоченного отвечать за .test.ru. Возможно, для доменов
ниже третьего уровня такая строгость не всегда важна. Но для второго и первого
однозначно требуется строгий административный подход к распределению полномочий
по управлению адресацией.
А раз так, то к ситуации хорошо подходит единственный способ построения иерархии
доверия, иерархии удостоверяющих центров: такая иерархия должна строиться на основе
уже существующей формально-юридической системы делегирования прав
администрирования доменов в интернете с привязкой к официальному дереву доменов.
Домены в интернете образуют древовидную иерархию, растущую из корневого домена.
Так, в корневой доменной зоне находятся все привычные домены верхнего уровня: COM,
NET, ORG, RU, SU и более двух сотен других доменов. Обслуживают домены верхнего
уровня корневые серверы DNS (это 13 сложных распределённых компьютерных систем в
дата-центрах по всему миру). Сейчас административное управление корневыми серверами
осуществляет корпорация ICANN, а техническое обслуживание - IANA (подразделение
ICANN), VeriSign и ряд других телекоммуникационных компаний.
При делегировании полномочий администраторам доменов также работает связанная с
доменным деревом иерархия прав. Например, права администрирования домена RU
делегированы корпорацией ICANN Координационному центру домена RU. Такое
делегирование сопровождалось формальной юридической процедурой, имеющей
значение в офлайне. Координационный центр домена RU заключает договоры с
регистраторами доменов, делегируя им полномочия по изменению адресации в зоне .ru.
Регистраторы определяют права по администрированию доменов второго уровня и
делегируют эти права администраторам конкретных доменов, заключая какие-то
договоры с этими администраторами. Такая схема, по крайней мере в теории, позволяет
установить, какое лицо (юридическое или физическое) и за какую доменную зону
отвечает. Соответственно, эти лица и должны подписывать адресную информацию о
вверенной им зоне, а вышестоящие организации будут эти подписи удостоверять,
основываясь на офлайновых договорах. Такая система выглядит устойчивой, так как
отражает правовую практику в офлайне - а ведь все споры решаются именно тут.
Из логики построения систем безопасности ясно, что корневой ключ, запирающий всю
систему DNS, не должен принадлежать самой системе. То есть такой ключ необходимо
распространять среди участников адресной системы внешним относительно DNS
способом, иначе наличие корневого ключа не придаст доверия системе в целом.
Например, корневой ключ может распространяться по компьютерам вместе с
операционными системами.
При этом корневой ключ соответствует корневой доменной зоне. И вот тут-то начинается
политика. Дело в том, что как только корневая зона оказывается подписанной, возникает
вопрос: у кого ключ? Понятно, что закрытый ключ, позволяющий подписывать изменения
в корневой зоне, должен быть у какой-то одной организации, и она должна хранить его в
тайне. При этом любое изменение адресации потребует использования секретного ключа
для генерации новой подписи.
Другими словами, участники процесса администрирования корневой зоны не смогут
самостоятельно вносить какие-то изменения, а должны будут идти на поклон к ключнику.
Ключник же будет волен как угодно ограничивать возможности по изменению корневой
зоны. Тут особенно интересно вспомнить мало известные широкой аудитории
исторические хитрости распределения компанией VeriSign квот по доступу к реестру
домена COM между аккредитованными регистраторами. Однако это тема для отдельной
статьи.
Особенно сильное влияние должность ключника приобретёт после того, как корневой
ключ раздадут по всем узлам Сети и компьютерам конечных пользователей. Если сейчас
методы управления корневыми серверами выглядят довольно мутно для непосвящённого
в тонкости этой хитрой индустрии человека, то наличие одного ключа сразу потребует
чётко обозначить, кто же главный.
Политический момент здесь даже круче, чем может показаться на первый взгляд. Дело в
том, что среди наиболее вероятных кандидатов на обладание корневым ключом - Минторг
США. Тут нет ничего удивительного, ведь именно эта правительственная структура
утверждает решения ICANN по развитию корневой доменной зоны. И именно эта
структура осенью 2008 года выдвинула вопрос о внедрении DNSSEC для корневой зоны
на обсуждение заинтересованных представителей телекоммуникационной и интернетиндустрии. Другие вероятные кандидаты - сама ICANN (в лице IANA) и VeriSign (на
правах компании, сейчас фактически раздающей файл корневой зоны по корневым
серверам). Возможен, хотя маловероятен и такой вариант: в качестве хранителя ключа
Минторг США выбирает некую особую компанию, находящуюся вне «общей банки».
Столь масштабные политические решения не принимаются быстро. Вокруг должности
ключника идёт скрытая борьба. И именно поэтому корневая зона до сих пор не подписана.
А пока она не подписана, нельзя говорить о внедрении DNSSEC, потому что те немногие
островки безопасности (например, шведский домен SE), уже включившие эту технологию
на своих серверах, сталкиваются с описанной выше проблемой подтверждения своих
полномочий и делегирования доверия.
Вообще же даже вне политических проблем технология DNSSEC не сделает небосвод
адресации в интернете кристально ясным, не наполнит его радужными картинами. Решив
проблему достоверности данных, DNSSEC обязательно принесёт с собой множество
новых проблем. О некоторых из них известно уже сейчас. Какие-то ещё предстоит
обнаружить. Главное, что объединяет эти проблемы: в классической DNS ничего
подобного не было.
Традиционно в пример приводят проблему глобального времени, актуальную для
DNSSEC и не существующую в старых протоколах. Дело в том, что криптографические
ключи, соответствующие той или иной доменной зоне, должны периодически изменяться
(происходит так называемая ротация ключей). То есть у конкретного открытого ключа
есть срок действия, после истечения которого ключ уже нельзя использовать. Очевидно,
что конкретная компьютерная система для того, чтобы определить, не истёк ли срок
действия предъявленного другой системой ключа, должна иметь общее с этой системой
время. Если часы на разных компьютерах не синхронны (до определённой степени), то
возникают возможности для хакерской атаки.
Алгоритмы, используемые в DNSSEC, может быть, не столь сложны с точки зрения
криптографов, но достаточно сложны с точки зрения DNS. Программисты, реализующие
эти сложные алгоритмы, обязательно наделают ошибок. Ошибки приведут к появлению
уязвимостей, которыми воспользуются хакеры.
Криптография DNSSEC требует дополнительных вычислительных ресурсов. Уже сами
создатели DNSSEC указывают на то, что этот факт - первый шаг на пути к новым D D oSатакам на компьютерные системы. При этом атаковать можно не только DNS-серверы, но
и машины конечных пользователей. Суть атак довольно проста: атакуемой компьютерной
системе подсовывают заведомо дефектные цифровые подписи, вынуждая тратить
процессорное время на проверку этих подписей.
DNSSEC - это следующий шаг в развитии систем адресации интернета. А развиваются эти
системы по спирали. Так что лет через десять можно будет прочитать статью о том, как же
устарела DNSSEC с её многочисленными фундаментальными уязвимостями, о которых замечательное дело! - специалисты писали ещё десяток лет тому назад.