Впрочем, это лишь одна часть проблемы. Другая часть, не менее важная, имеет отношение к политическим факторам, как и следует ожидать в Глобальной сети. Подробнее о нихчуть ниже, а сейчас остановимся на том решении проблем безопасности 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.
DNSSEC позволяет участникам системы самим настраивать «цепочки доверия» и решать, какому именно удостоверяющему центру они готовы верить «на слово», без дополнительных проверок. В каких-то сетевых архитектурах конечным центром доверия может являться вовсе не корневой центр всего Интернета, а, скажем, некоторый локальный сервер. Но для всего Интернета важен именно общепринятый корневой центр.
DNSSEC уже внедрена во многих доменах первого уровня. Есть немало доменов уровнем ниже, внутри которых также используется DNSSEC. Однако совершенно преждевременным было бы говорить, что DNSSEC развернута, до тех пор пока не «подписаны» корневые серверы имен, соответствующие корневому домену. (Как я рассказывал ранее, таких серверов 13, и в настоящий момент они в административном плане контролируются ICANN.)
Именно с «подписыванием» корневых серверов были связаны политические проблемы в управлении Глобальной сетью. Они сводятся к довольно простому вопросу: у кого ключ?
Из соображений безопасности секретный ключ, с помощью которого подписывается информация в вершине иерархии доверия, должен являться самой охраняемой частью системы. Однако любое изменение в файлах корневой зоны требует использования секретного ключа для генерирования новой подписи. Изменения же вносятся весьма часто, а многие из них носят чисто технический характер.
До внедрения DNSSEC контроль над верхушкой иерархии DNS был более размазан. Да, фундаментальные решения принимала ICANN после согласования с соответствующими подразделениями Минторга США. Техническую сторону обеспечивают технические службы (например, корпорация VeriSign или такая организация, как IANA). При этом сами 13 корневых серверов вовсе не являются тринадцатью физическими компьютерами, а представляют собой большое количество сложных многокомпьютерных систем, разбросанных по дата-центрам разных стран. Понятно, что в управлении этими базовыми узлами DNS так или иначе задействовано большое количество различных телекоммуникационных компаний.
После того как состоялось подписание корневых серверов, управление DNS получило еще одну строгую криптографическую процедуру, однозначно привязанную к корневому ключу. Корневую зону DNS окончательно подписали в ночь с 15 на 16 июля 2010 года. Конечно, после завершения многомесячной и довольно сложной процедуры поэтапного развертывания технологии на корневых серверах. Открытые ключи для проверки подписей DNSSEC опубликованы на сайте IANA (https:// data.iana.org/root-anchors/). Таким образом, несмотря на существенные административные сложности, Минторг США, компания VeriSign и службы ICANN в 2010 году успешно завершили развертывание DNSSEC в корневой зоне.
Споры вокруг того, кому должен достаться «главный ключ», кто будет подписывать данные, а кто станет генерировать новые ключи, шли довольно долго. В итоге утвердили следующую схему. Существует два ключасамый главный KSK (Key Signing Keyключ для удостоверения ключа) и чуть менее «главный» ZSK (Zone Signing Keyключ для подписывания зоны). KSK удостоверяет ZSK, а уже последний используется для удостоверения данных в корневой доменной зоне. Достоверность ZSK можно проверить, используя открытую часть KSK.
ZSK генерируется и находится в распоряжении корпорации VeriSign, которая и подписывает с его помощью адресную информацию в корневой зоне. KSKгенерируется ICANN, на специальной церемонии. И структуры ICANN же подписывают ZSK, делегируя таким образом технические полномочия VeriSign. Заметьте, что ключи меняются через определенное время. ZSKчаще, KSKреже, так как он несколько более защищен и используется для удостоверения меньших объемов данных.
Процедура генерации криптографических ключей по причине своей важности для Интернета, а также из-за того, что криптография сама по себе несет некий отпечаток таинственности, в первый же год работы DNSSEC в корневой зоне породила множество искаженных пересказов в СМИ. Например, летом 2010 года едва ли не каждый новостной канал распространил сенсационное сообщение о том, что «собрана шестерка программистов, которые в случае глобальной неисправности смогут перезагрузить Интернет с помощью особого ключа». В чем же реальная суть процедуры, или, если хотите, церемонии, генерации этого самого «особого ключа»?
Собственно, по состоянию на 2013 год KSK вообще ни разу не менялсядля этого просто забыли предусмотреть процедуру. Да, и такие провалы случаются в истории DNS, несмотря на участие в проектировании действующей версии системы множества признанных специалистов. Вполне возможно, что процедуры смены (ротации, как говорят специалисты) KSK все же разработают в ближайшие годы. И ключ изменится. Хотя кто знаетне исключены и более пессимистичные варианты.
Действительно, заботясь о хорошем информационном фоне и придавая процедурам «ужесточения» управления DNS нужную степень прозрачности, в ICANN изначально прибегли к помощи экспертного сообщества, сформировав несколько групп «хранителей ключа».
Команда экспертов, выступающих представителями интернет-сообщества, включает в себя 21 человека в «основном составе», плюс 13 человек«скамейка запасных». Назначение командыобеспечивать процесс генерации и сопровождения ключей, подписывающих корневую зону DNS, выступая фактически в роли доверенных контролеров;
Внутри этой команды есть две группы по семь человек, каждая закреплена за одним из двух дата-центров, в которых генерируют составляющие ключа KSK и используют его для подписания других ключей; люди из этих групп хранят ключи, необходимые для получения паролей от криптосервера. Интересно, что речь тут идет о «физических» ключах от сейфовых ячеек, в которых находятся пароли к криптосерверу.
Третья группа хранит смарт-карты с частями ключа, позволяющего расшифровать резервную копию секретного KSK в случае, если вдруг основная копия, находящаяся в криптосервере, исчезнет в результате какого-нибудь катаклизма. В резервесемь человек с ключами «от криптосервера» (условно) и шестьс частями ключей от резервной копии.
Как я только что рассказал, используют два ключа: KSK и ZSK. С помощью KSK подписывают ZSK, которым подписывается корневая зона. ZSK генерирует VeriSign, потому что эта компания технически отвечает за распространение корневой зоны DNS. По процедуре, новые ZSK «выкатываются» четырежды в год. Каждый новый ZSK должен быть подписан защищенным криптосервером, в котором содержится секретная часть KSK. В идеале никто из людей не знает секретной части KSKона просто не должна покидать пределы криптосерверов в открытом виде. То есть четыре раза в год эксперты с ключами от криптосервера приезжают в дата-центр и отпирают криптосервер, тем самым разрешая этому устройству подписать новый ZSK. Те доверенные люди, что хранят смарт-карты с частями ключа, которым зашифрована резервная копия KSK, выезжают «на восстановление» не по графику, а только если основная копия утрачена. (Видимо, только этот момент, благодаря его драматургии, и привлек журналистов.)
Понятно, что, если действовать по процедуре, без держателей ключей от криптосервера подписать зону восстановленным из резервной копии KSK не получится. Более того, по существующей процедуре не выйдет вообще что-либо сделать с корневой зоной без участия VeriSign и Минторга СШАкакими ключами ни размахивай. Очевидно, что утрата секретного ключа KSK не приведет одномоментно к отключению DNS и краху DNSSEC. До момента истечения срока действия текущего ZSK даже изменения в зону можно будет вносить. А вот подписать новый ZSK утраченным KSKне получится.
Ну а самое интересное, что в крайнем случае никто не помешает просто сгенерировать новый KSK силами ICANN, Минторга и VeriSign, равно так же, как это было сделано при развертывании DNSSEC. Впрочем, возникнет большая проблема с распространением этого нового KSK по клиентам. Ситуация поменялась из-за того, что проникновение DNSSEC за эти годы возросло: просто так опубликовать ключ на сайте не выйдет, система сломается. А добротная процедура ротации KSK включает использование старого ключа, он потребуется для удостоверения нового, так что терять ключи ICANN не стоит.
Мы уже коснулись важного момента, лежащего в основе множества атак злоумышленников, «ложного доверия» пользователей к адресу: рядовые посетители сайтов, пользователи других онлайн-ресурсов, связанных с доменами, склонны считать, что если они набирают в адресной строке то или иное доменное имя, то браузер приводит их именно на тот сайт, который они ожидают под этим именем увидеть.
Решая главную проблему «дырявости DNS», DNSSEC гарантированно создает множество новых проблем, ранее не существовавших. Это происходит прежде всего потому, что DNSSEC намного сложнее по сравнению с «классической DNS».
Уничтожая одни уязвимости, DNSSEC готовит почву для других. Разработчики системы, конечно, знают об этом. Уже понятно, что внедрение DNSSEC создаст новые возможности для атак типа «Отказ в обслуживании» (DoS), ведь криптографические процедуры защищенной DNS гораздо более ресурсоемки в вычислительном смысле. Злоумышленники при помощи отправки системам, поддерживающим DNSSEC, «дефектных» наборов данных смогут с большей относительно «классической» DNS легкостью занять все вычислительные ресурсы компьютера проверкой «бессмысленных» адресных данных.
Кроме того, существенную трудность представляет распределение ключей, необходимых для генерирования цифровых подписей. Со временем ключи устаревают, и требуется производить их замену. При этом замена должна происходить с высокой надежностью, и всем участникам системы необходима возможность узнать о том, что конкретный ключ прекратил свое действие.
Реализация сложных по сравнению с обычной DNS криптографических алгоритмов в программном обеспечении может быть выполнена с ошибками, что создаст поле для хакерских атак. Существуют и другие проблемы, о которых наверняка сейчас еще ничего не известно, и раскроются они лишь после повсеместного внедрения DNSSEC. Тем не менее при всех сложностях DNSSEC обещает значительно улучшить ситуацию с безопасностью в Интернете, создав платформу для «управления доверием».
На этом доверии сетевым реквизитам паразитируют так называемые фишеры.
Для обмана интернет-пользователей фишеры используют целый арсенал средств, на первом месте в которомхитрости с DNS и именами доменов. Очень большой удачей для фишеров будет выполненный тем или иным способом перехват управления доменом, под которым размещен сайт банка. Мошенники заблаговременно готовят сайт-обманку, внешне неотличимый от официального сайта банка, и после получения управления доменом переводят домен на этот сайт-обманку. Клиенты банка, как и ранее, заходят на сайт, набрав в адресной строке браузера привычное имя домена (или воспользовавшись закладками браузера, что в данном случае имеет тот же эффект). Однако вместо настоящего сайта клиентов ждет сайт-обманка, обычно предлагающий ввести реквизиты для управления банковским счетом (мотивируется такая просьба самыми разными причинами: «обновление базы данных», «проверка и переучет пользователей системы онлайн-банкинга» и т. п.). Клиент, искренне полагая, что находится на официальном сайте банка, с легкостью делится нужными реквизитами с фишерами. Именно для осуществления подобных атак, весьма и весьма эффективных, фишеры прибегают к услугам хакеров, помогающих «угнать» домен.