dxdt.blog: занимательный интернет-журнал

С DNSSEC связано немалое число хитрых особенностей, которые не так очевидны, как базовые принципы этой технологии. Например, часто приходится сталкиваться с неверной трактовкой назначения DS-записи. Между тем, DS-запись (Delegation Signer) – важнейший элемент DNSSEC, так как с её помощью выстраиваются цепочки доверия. Эта запись указывает на ключ, который зона, расположенная на уровень ниже (делегируемая зона), должна использовать для удостоверения (подписывания) адресной информации.

Одна из хитростей состоит в том, что если в родительской (делегирующей) доменной зоне присутствует DS-запись для дочерней (делегируемой) зоны, и родительская зона безопасна (то есть, подписана DNSSEC), то это означает, что дочерняя зона тоже должна быть безопасной. То есть, валидирующий резолвер ожидает, что дочерняя зона содержит, во-первых, подходящие к DS ключи, нужные для проверки подписей, во-вторых – сами подписи на ответах об адресации внутри зоны. Соответственно, если DS-запись присутствует, а дочерняя зона не подписана, валидирующий резолвер будет возвращать сообщение об ошибке. Это совершенно правильное поведение, потому что иначе смысла в DNSSEC нет: подделать ответы без подписей не составляет труда; если резолвер не имеет возможности отличить подписанную зону от неподписанной по наличию DS-записи в доверенной (безопасной) зоне, то подписи можно вообще не проверять.

Другой важный момент: если авторитативный сервер родительской (делегирующей) зоны, подписанной DNSSEC, отвечает на рекурсивный запрос списком NS-ов и DS-записью, то подпись ставится только на значение DS. Казалось бы, нужно подписать и список NS-ов – как иначе узнать, что они правильные? Но если у нас есть доверенная DS-запись, то нет разницы, с каких серверов мы получим дополнительную информацию: главное, чтобы совпал ключ и его отпечаток в DS, а также сошлись значения подписей. Тут работает основной принцип DNSSEC: если данные об адресации аутентифицированы, то не имеет значения, из какого источника они получены.

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

Google Public DNS для зон, имеющих DS-запись, но не подписанных, возвращает ошибку (SERVFAIL), вне зависимости от того, какова природа этих DS-записей. Другие валидирующие резолверы ведут себя иначе. Например BIND, обнаружив неизвестный алгоритм генерации DS, считает, что DS-записи в родительской зоне вовсе нет (что не совсем корректно, но с практической точки зрения оправдано, и, конечно, соответствует рекомендациям RFC). Пример такого поведения можно наблюдать для зоны dotsu.su – здесь в .su специально указаны DS-записи с неизвестным алгоритмом (9).

(Меня попросили описать в более или менее подробных деталях, какие ключи и как сейчас используются в DNSSEC. Думаю, что описание заслуживает публикации на dxdt.ru – потому что до сих пор нередко путают ключи, зоны, цепочки делегирования и прочие важные моменты.)

Посмотрим на то, как используются ключи DNSSEC, взяв для примера зону .org. Предположим, что мы справшиваем SOA-запись для .org у корневого сервера. Тогда, вместе с адресами NS-ов домена org, если последний делегирован безопасно, то есть, с DNSSEC, мы получим от корневого сервера DS-запись (или несколько – сейчас, например, их для .org две) и RRSIG-запись для DS (важно – именно для DS). То есть, главная интересующая нас подпись содержится в корне, это RRSIG over DS (RRSIG от DS). Напомню, что DS-запись содержит значение хэш-функции ключа, относящегося к делегируемой зоне (то есть, в случае нашего примера, к .org). Подпись RRSIG сгенерирована при помощи корневого ZSK (Zone Signing Key, ключа подписи зоны), который опубликован в корневой зоне, и его нужно будет оттуда получить, чтобы проверить подпись на DS. (Ключ также может уже находиться в кэше резолвера, тогда запрашивать его у корневых серверов не нужно.)

В дальнейшем, информацию, полученную с сервера имён (NS) домена org, мы проверяем ключами, которые опубликованы в этой же зоне (в .org). То есть, RRSIG-и из данной зоны проверяются ключами, которые в той же зоне и расположены. Для связывания ключей из разных зон в цепочку доверия служат DS-записи, которые также подписываются.

Посмотрим чуть ближе на реальное устройство DNSSEC для .org, как всё выглядит сейчас:

1.

В корне (в корневой зоне) мы видим два ключа (я буду их обозначать реальными идентификаторами, которые я взял из DNS) – 22603 (ZSK) и 19036 (KSK – кстати, не менялся с 2010 года, потому что забыли придумать, как его поменять). Для ключа 22603 в корневой зоне есть RRSIG, сгенерированная от ключа 19036. 19036 – это и есть тот самый главный, корневой, рутовый KSK, открытая часть которого изначально находится у нас в резолвере (пусть ключ и опубликован в DNS, но в резолвер он должен попасть каким-нибудь другим доверенным путём, не черезе DNS). После того, как мы проверили RRSIG от ключа 22603 этой открытой частью ключа KSK (19036) и всё сошлось, мы добавляем ключ 22603 в доверенные ключи. И можем пойти дальше.

2.

В корне же мы видим DS-записи для ORG, а также RRSIG для них. Подпись (RRSIG over DS) сделана от ключа 22603 (то есть, от ZSK, см. выше). Ключ 22603 мы только что добавили в доверенные. Проверяем подпись на DS-записи, если всё сошлось, то можем пойти дальше, записав себе значение DS.

3.

На серверах, поддерживающих .org, мы видим четыре ключа – 9795, 21366 (эти два – KSK) и 60764, 11112 (а эти два – ZSK; KSK от ZSK отличаются значением одного бита в поле типа ключа). Хэш от ключа 21366 соответствует значению DS-записи, опубликованной в корне (см. выше). Эту запись мы только что (ну или некоторое время назад, см. TTL) получили от корневого сервера, вместе с подписью, которую проверили – значит, DS-у доверяем.

4.

На серверах .org мы также видим записи (их сейчас три) RRSIG для набора DNSKEY. Эти три записи RRSIG сгенерированы от трёх ключей: 9795, 21366 и 11112 – обратите внимание, каждая из этих RRSIG подписывает все ключи, опубликованные в зоне (ключи публикуются в записях DNSKEY). То есть, у нас четыре ключа подписаны при помощи трёх других. Один из этих подписывающих ключей – 21366 – соответствует DS-записи, полученной из корня, поэтому мы можем добавить его в список доверенных ключей. Теперь записям, подписанным этим ключом, мы тоже будем доверять. После того, как мы убедились, что подпись от ключа 21366, сделанная для RRSIG DNSKEY в зоне .org, – валидная, мы добавляем и три других ключа (9795, 11112, 60764) в список доверенных. Почему? Потому что RRSIG over DNSKEY удостоверяет и их тоже – она для всех ключей зоны общая.

5.

Итак, мы решили получить SOA-запись (это главная запись в любой DNS-зоне) от .org и проверить её. Нет ничего проще: получаем SOA, вместе с ней приходит RRSIG, сгенерированная от ключа 11112, этот ключ есть у нас в списке доверенных, поэтому проверяем подпись – если сходится, то верим данным из SOA-записи. (Аналогично – для А-записей и для прочих.)

Обратите внимание, что мы не проверяли подписи на адресах NS-ов (серверов имён .org) – этого и не нужно делать, если только мы не хотим проверить именно значения NS-ов. Хитрость в том, что в DNSSEC не имеет значения, откуда были получены подписанные данные – с легитимных серверов или ещё откуда-нибудь: главное, чтобы подписи сходились.

Резюме: информацию, получаемую с серверов .org, мы проверяем ключами, полученными с тех же серверов, а вот убедиться, что это правильные ключи, нам позволяет подпись (RRSIG over DS) из корневой зоны.

Схема организации подписей и зон DNSSEC для dxdt.ru:

Картинка сгенерирована при помощи полезного сервиса DNSViz.

Кстати, довольно давно я завёл специально испорченную, в смысле DNSSEC, зону – dotsu.su. С её помощью удобно тестировать различные анализаторы DNSSEC. Текущая версия DNSViz выдаёт вполне корректную картинку для dotsu.su (раньше были сбои).

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

Конечно, есть персональные аккаунты на разных сайтах, но их всё равно заводит компьютер, хоть и, вероятно, на основе команд пользователей. Вопрос с идентификацией реальных людей, а не компьютеров, принципиален для массовой интернет-слежки: источник активности в Сети должен быть точно известен. Процитирую свою статью в “Доменных именах”:

Если точной дифференциации источников нет, а ваша система не умеет отличать одного гражданина от другого, то следы начинают путаться, потому что деятельность двух различных граждан в Интернете оказывается приписана одному собирательному образу. Эта оплошность тут же рушит общую картину, ведь носителя этого собирательного образа в мире не существует. Это означает, что построенный поведенческий профиль будет содержать большую ошибку, что потянет за собой проблемы с предсказанием действий и, на следующем шаге, с сопоставлением новых следов, найденных в трафике. Аналитика, работающая на пользовательском трафике, сложна, а ее алгоритмы содержат много внутренних связей. Так что, если на одном участке базы данных ваша система не смогла отличить Петра Владимировича от Владимира Петровича, будьте уверены: из-за этого на другом участке базы данных перепутаются Ольга Семеновна и Марина Ивановна.

Ещё немного про TLS/SSL: Let’s Encrypt – это инициатива по созданию общедоступного бесплатного удостоверяющего центра (УЦ), а также программных инструментов и сервиса автоматической выдачи сайтам SSL-сертификатов, признаваемых браузерами. Более того, обещают, что сопутствующее ПО будет автоматически настраивать веб-сервер для работы по HTTPS.

Чуть подробнее: предполагается, что утилита Let’s Encrypt, будучи запущенной на сервере, сама сгенерирует ключи, свяжется с удостоверяющим центром, подтвердит управление сайтом (владение доменом), закажет и получит SSL-сертификат и настроит веб-сервер для работы с ним. Всё это с использованием специального протокола, который был разработан ранее. И бесплатно.

Выглядит, конечно, привлекательно. Но вызывает сомнение высокая степень автоматизации: всё ж SSL/TLS иногда требует обдумывания действий, иначе безопасность не повышается, а скорее наоборот. Всякое тиражное решение несёт с собой риск тиражирования не только хороших, правильных практик, но и ошибок, которые сделали разработчики решения. Можно спорить, насколько сильно нужно ошибиться в сервисе, автоматически внедряющем HTTPS на сервере, чтобы в результате ошибки уровень безопасности для этого сервера снизился – предполагается, что до момента запуска Let’s Encrypt сервер вообще использовал открытый протокол HTTP. Всяческие сценарии с захватом управления веб-сервером и автоматическим выпуском сертификата для его домена не очень пугают, так как если кто-то получил управление сервером, то он и так может сделать с ним всё что угодно, в том числе заказать сертификат (тут, впрочем, может потребоваться ещё и контроль электронной почты под доменом). Но, естественно, бесплатность процедуры несколько упрощает атаку.

Нет сомнений, что подобный сервис, к сожалению, окажется удобен для различных фишерских доменов, среди которых есть и простые тайпсквотерские (yanclex.ru), и более хитрые, комбинированные: например, что-нибудь вроде ssl-yandex.ru. Возможность быстро выпустить бесплатный сертификат и поднять HTTPS, вызывающий дополнительное доверие пользователей – она не может быть лишней. Впрочем, сейчас для этих же целей успешно выпускаются платные сертификаты DV (с валидацией по домену), с подставными реквизитами: возможности определить степень легитимности домена УЦ не имеет. Так что радикально Let’s Encrypt тут ситуацию не изменит.

Запуск сервиса обещают летом 2015 года. В числе участников инициативы значатся Mozilla и IdenTrust (это действующий УЦ), то есть можно ожидать появления нового УЦ как минимум в одном распространённом браузере. Как я понимаю, на первых порах Let’s Encrypt планирует вообще использовать для работы корень IdenTrust, с отдельным промежуточным сертификатом (по крайней мере, сейчас у них на сервере HTTPS устроен именно так). В общем, посмотрим, что получится.

Спрашивают, зачем нужно использовать протокол HTTPS для веб-сайта, если последний не работает с конфиденциальной информацией (например, это не панель управления хостингом). Казалось бы – если на страницах нет ничего секретного, то зачем их шифровать? Такая типичная ошибка в восприятии HTTPS как протокола, нужного исключительно для шифрования (к сожалению, такая искажённая картина весьма распространена). Действительно, шифровать не обязательно, но HTTPS это не только и не столько шифрование, сколько контроль целостности. То есть, безопасный протокол защищает страницы от подмены.

Если у вас сайт банка, но “общие” страницы отдаются по HTTP, а не по HTTPS, это означает, что кто-то может легко подменить часть кода веб-страницы на пути к пользовательскому компьютеру (или заменить всю страницу). Такая подмена позволяет внести изменения в тексты на странице (скажем, сообщить об “отзыве” лицензии), при этом у пользователя нет никаких инструментов, позволяющих проверить, получает ли он информацию в неизменном виде.

HTTPS решает эти проблемы: изменить страницы на промежуточном узле простым способом не получится (что, естественно, не отменяет возможного перехвата HTTPS, но переводит задачу на принципиально иной уровень сложности). Конечно, всегда остаётся доступен старый способ: принудительная замена протокола на стороне пользователя, которая хорошо работает для ссылок (простая замена https:// на http://). Однако если пользователь привык заходить на сайт банка по браузерной закладке (типичный сценарий, кстати), попытка подмены протокола, – например, через редирект, – вызовет предупреждение в браузере (потому что для выполнения HTTP-редиректа тоже потребуется серверный SSL-сертификат, а его, скорее всего, у перехватывающего соединение узла нет).

И не стоит забывать о том, что уже есть поддерживаемые браузерами инструменты, позволяющие жёстко назначить HTTPS единственным протоколом для веб-сайта. Пример: HTTP Strict Transport Security.

В Wired публикуют статью о том, что спецслужбы США (АНБ, в основном) не собирают больших справочных баз данных по уязвимостям в ПО, неизвестным широкой общественности. Речь идёт о практике публикации (или, наоборот, сокрытия) информации об уязвимостях, которые находят аналитики АНБ (и других профильных агентств). Если уязвимость сохраняется в секрете, то её можно длительное время использовать для атак на информационные системы. Однако от этой же уязвимости, как пишут, могут пострадать информационные системы США – то есть, лучше бы её опубликовать, чтобы разработчики заткнули дыру. Такая дилемма.

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

Для того, чтобы сведения о найденной уязвимости донести до разработчиков, пришлось бы готовить небольшую операцию прикрытия. А какой в ней смысл? Безопасность государственных программных систем, в которых тоже есть известные АНБ незакрытые уязвимости, можно обеспечить другими способами. А главное – вовсе не факт, что обоюдная угроза от незакрытых уязвимостей вообще как-то беспокоит те подразделения АНБ, которые занимаются проникновением в информационные системы: перед ними стоят другие задачи и самостоятельно лишать себя инструментов они вряд ли станут. Собственно, об этом и говорится в статье по ссылке, но только под соусом из всяких уточнений и оговорок.

До сих пор нередко встречаются “продвинутые пользователи” персональных компьютеров, старой закалки, которые свой рабочий компьютер не подключают ни к каким вычислительным сетям, а данные переносят на флешках. То есть, к сети компьютер не подключен, “чтобы никто не влез или вирус не пробрался”, но так как некие “конфиденциальные данные” нужно, например, распечатать, они копируются на флешку, с которой пользователь отправляется на другое рабочее место, с целью передачи документа на сетевой принтер.

Вообще, концепция подобного “неподключения” известна давно, называется она air gap (“воздушный зазор”, в вольном переводе) и применяется в целях обеспечения информационной безопасности, иногда – весьма эффективно применяется. Однако описанная выше наивная трактовка концепции, подразумевающая использование флешки, лишь создаёт дополнительные риски: флешка обязательно теряется (или, хоть это и маловероятно, её крадут) – получаем потенциальный канал утечки. Конечно, нельзя забывать и о том, что современное вредоносное ПО успешно распространяется как раз при помощи флешек. Соответственно, “продвинутый пользователь”, постоянно путешествующий со своей флешкой по разным устройствам, не только подвергает свой собственный компьютер угрозе заражения каким-нибудь зловредом, но ещё и служит транспортом для этих зловредов внутри предприятия. Риск внедрения вредоноса на компьютер через вычислительную сеть – едва ли выше, чем в случае с флешкой. Кстати, как писали аудиторы, нашумевший Stuxnet был занесён на режимный иранский завод именно по такой схеме: флешка с данными и документами.

(На правах технократического юмора.) Если кто не знает, то “циска” – это собирательное название маршрутизаторов, произошедшее от Cisco и почти ставшее нарицательным. Известно, что если отключить достаточное число маршрутизаторов, то национальный сегмент Интернета потеряет внутреннюю связность (а не только связность с глобальной Сетью). То есть внешняя атака, отключающая “циски”, приводит к пропаданию Интернета в выбранной стране. Естественно, маршрутизаторы содержат уязвимости-закладки, некоторые из них позволяют маршрутизатор не просто отключить, а убить совсем. Идеальным решением задачи активации закладки является передача в составе трафика специального ключа.

Маршрутизаторы копируют все пакеты и обязательно анализируют часть их заголовков, а факультативно – содержимое самих пакетов. Так что обнаружив ключ активации в составе полученного пакета данных, маршрутизатор отключается. Ключ может представлять собой строку из 256 бит, соответственно подобрать его не представляется возможным. Понятно, что программная реализация проверки валидности полученного кода должна быть устроена так, что сам код на основании анализа алгоритма вычислить не удастся. Это очень важный аспект: иначе кто-то сможет получить ключ уничтожения в своё распоряжение, прикупив одну уязвимую “циску”.

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

Предположим, что пакет, содержащий “смертельный код”, отправляется внешним узлом в направлении ближайшего пограничного маршрутизатора атакуемого сегмента сети. Если маршрутизатор, получив пакет, умирает немедленно, то гарантировать можно лишь уничтожение этого самого маршрутизатора – остальные узлы-маршрутизаторы останутся работоспособными, а вот связь их с внешним сетевым миром прервётся, поэтому вырубить их извне уже не получится. Проблема.

Допустим, маршрутизатор сперва отправляет пакет далее по маршруту, и лишь потом – умирает. При такой схеме возможно вывести из строя один из маршрутов, в который входит начальный маршрутизатор, да и то – гарантировать ничего нельзя: пакет может потеряться в пути, а переслать его повторно будет уже некому. Так как маршрутов доставки пакетов обычно несколько, получаем проблему с покрытием: после того, как откажет несколько “цисок”, эпидемия затихнет, а связность сохранится.

Естественно, можно продолжать бомбардировать все доступные узлы пакетом, содержащим смертельный код, но есть и другое решение. Для качественного уничтожения связности пакеты должны пройти через каждый маршрутизатор, обеспечивающий работу национального сегмента Сети. При этом желательно, чтобы вредоносные пакеты вообще не покидали пределов сегмента. Это означает, что источником пакетов должны быть пользовательские компьютеры – тогда они заведомо охватят большое число маршрутизаторов, а распространяться эпидемия отключений начнёт с самого подходящего уровня: ведь без конечных пользователей Интернет не имеет особого смысла.

Как получить нужный эффект? Например, использовать механизм, встроенный в распространённую операционную систему. Пусть в определённый момент центральные серверы, куда эта операционная система обращается за обновлениями, отправят некий “праймер” – сигнал к атаке. После этого операционная система в любой пакет исходящего трафика встраивает убивающий маршрутизаторы код и – вуаля, сегмент посыпался, причём падают маршрутизаторы во всех возможных путях доставки пакетов к пользователям, покрытие идеальное. Естественно, операционная система пользовательских компьютеров не содержит секретного кода: он передаётся центральными серверами, в зашифрованном виде, чтобы не вызвать преждевременного срабатывания. От конечного компьютера требуется только расшифровать код и вернуть его обратно в Сеть – самая обычная операция, кстати, не вызывает подозрений, встречается во многих протоколах, так как может являться чем-то вроде проверки электронной подписи или служить частью системы аутентификации.

А после того как в национальном сегменте умерли хотя бы две трети “цисок”, на восстановление связности потребуются многие месяцы (не исключено, что и годы).

Продолжается новомодный поток анонсов с громкими атаками на SSL/TLS: в этот раз – POODLE, позволяющая свести на нет секретность HTTPS (например) при использовании SSLv3. Занятно, что в сообщении по ссылке читаем: “Today, Firefox uses SSLv3 for only about 0.3% of HTTPS connections” (“Сейчас Firefox использует SSLv3 лишь для 0,3% HTTPS-соединений”).

(Подробное описание, PDF.)

Большой проблемой современного состояния SSL/TLS в Интернете является возможная “прозрачная” подмена сертификатов, проводимая при участии удостоверяющих центров. Одним из решений этой проблемы является построение независимой от иерархии удостоверяющих центров публичной системы аудита выданных сертификатов. Соответствующая инициатива называется Certificate Transparency (CT), я писал о ней примерно год назад. Результаты аудита, которые публикуются в специальных логах, могут, в том числе, автоматически проверяться браузерами. Технология активно развивается и уже частично поддерживается браузерами Chrome и Chromium. Конечно, есть проблема с полнотой логов, но важно, что поддержку включили.

Кстати, поговаривают, что в Chrome/Chromium будут требовать поддержки CT для EV-сертификатов (сертификатов с “дополнительной валидацией”) с февраля 2015 года. То есть, уже совсем скоро.

Посмотреть, как работает эта новая технология, можно, например, здесь: https://embed.ct.digicert.com/.