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

Пишут, что в Сирии Интернет отключен, практически на 100%.

Для дальнейшего тестирования DNSSEC и сопутствующих инструментов я сделал пару сломанных зон. Особенно радикально сломана dotsu.su – там в зоне .su указан зарезервированный код алгоритма для DS-записи, а внутри зоны содержатся “сильно кривые” записи DNSKEY. Так, при попытке обработки dotsu.su – успешно падал онлайн-инструмент VeriSign DNSSEC debugger (http://dnssec-debugger.verisignlabs.com/), сейчас, после того, как я написал в техническую поддержку, всё исправили.

Есть вторая зона broken.nox.su, третьего уровня, там пока просто отсутствуют DS-ы в зоне уровнем выше (nox.su), что является более мягким вариантом. Update: теперь для broken.nox.su добавлена DS-запись, которая не соответствует никакому ключу в зоне (ключей там нет, собственно), так что адреса в broken.nox.su с DNSSEC резолвиться не должны.

Вообще, можно с уверенностью сказать, что основные проблемы с DNSSEC-ом будут даже не в том, что зоны станут подписывать криво, а в том, что внедрение разных сложных вспомогательных инструментов даёт новые направления для атак. И скоро мы увидим множество таких атак, в том числе, и на регистраторов.

ICANN ведёт страницу со списком мировых регистраторов доменов, поддерживающих DNSSEC. Список, мягко говоря, очень короткий. Зато там наконец-то появился первый российский регистратор – RU-CENTER (со скромным, пока что, перечнем поддерживаемых доменов: .com, .net, .su).

Пару десятков лет назад у меня был домашний “286-й компьютер” (IBM-совместимый, как это тогда называлось), оснащённый жестким диском в 40 Мб (прописью: мегабайт). Сейчас я такой же объём данных получаю с сервера в Европе, через Интернет, за пять секунд (буквально – менее пяти секунд). То есть, весь тот старый жёсткий диск, на котором много чего помещалось. Тоже на домашний компьютер, который находится, в масштабах глобальной географии, примерно на том же самом месте. Это и есть показатель развития информационных технологий, а вовсе не то, что аналогичные по назначению жёсткие диски теперь где-то в 25 тысяч раз большего объёма.

Многие спрашивали про поддержку DNSSEC российскими регистраторами. Вот, буквально только что, запустили такую поддержку RU-CENTER и R01. Причём, RU-CENTER поддерживает DNSSEC и для зон .com и .net (R01 – пока только .su).

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

Подробнее про DNSSEC на практике можно почитать на странице, размещённой под “демонстрационным доменом” nox.su, который, конечно, DNSSEC поддерживает.

Если у кого есть вопросы по данной технологии – пишите, можно почтой (адрес справа на этой странице), можно в комментарии.

На сайте Internet Society ведётся список ресурсов, поддерживающих новую технологию DANE. Сайтов там пока что не очень много. Это хорошо объясняется тем, что поддержка DANE пока отсутствует в браузерах. Есть только один плагин для Firefox, да и то – в альфа-версии. Большая проблема. Без браузерной поддержки DANE никому не нужен. Без DANE – DNSSEC теряет заметную часть технологической привлекательности, потому что только благодаря привязке к сайтам DNSSEC можно продвинуть на клиентскую сторону.

Согласно современной реальности Интернета, прорывом был бы качественный плагин для майкрософтовского браузера IE. У меня нет уверенности, что подобный плагин возможен для IE, так как я недостаточно знаком с архитектурой этого браузера. Если кто-то может рассказать подробности, то, пожалуйста, выскажитесь в комментариях. Ниже, я опишу логику работы плагина, вдруг, кто-то захочет его реализовать (что было бы замечательно).

Итак, DANE позволяет разместить в DNS отпечаток SSL-сертификата и проверить достоверность соответствия этого отпечатка домену при помощи DNSSEC. Для проведения проверки требуются: значение специальной записи из DNS и сертификат, предъявляемый веб-сервером. Сличение проводится, грубо говоря, по имени хоста. То есть, отпечаток из DNS для заданного хоста должен соответствовать отпечатку, вычисленному по полученному сертификату. Более подробное описание части, касающейся DNS, есть в записке про DANE.

Соответственно, плагин для браузера должен вмешиваться в процесс установления соединения по HTTPS с веб-сервером, получать отпечаток ключа сертификата, предъявляемого сервером и сверять этот отпечаток с данными, полученными из DNS, если их удалось получить и подтвердить DNSSEC-ом, конечно. Дальнейшее поведение плагина зависит от того, каковы результаты проверки:

• если валидный отпечаток из DNS совпадает с сертификатом, то браузер должен показать некий дополнительный флаг, означающий, что связка сертификат-сайт проверена DNSSEC. Если при этом сертификат самоподписанный или выдан неизвестным браузеру удостоверяющим центром (УЦ), то нужно подавить предупреждение браузерной системы безопасности (а можно ли это сделать в IE?);
• если отпечатки не совпали, то нужно, наоборот, выдать предупреждение системы безопасности, даже если сертификат валидный и подписан доверенным УЦ;
• если данные, полученные из DNS, не прошли проверку подлинности, а всё остальное – совпадает, то, опять же, нужно выдать предупреждение.

Плагину придётся самостоятельно проводить проверку подписей DNSSEC и извлекать их из DNS. В общем, задача не самая простая, но, вероятно, решаемая. Это я к тому, что, может, кто-то возмётся за реализацию.

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

(The Hidden Internet of Iran: Private Address Allocations on a National Network.)

На специально сайте пишут, что логи веб-сервера ieee.org длительное время находились в открытом доступе (по FTP). Причём, внутри логов, выставленных на всеобщее обозрение, находились пользовательские логины и пароли, естественно, в открытом виде. История выглядит особенно занимательно, если вспомнить, что IEEE – это организация, занимающаяся, кроме прочего, разработкой технологий обеспечения информационной безопасности (ну и всяких рекомендаций в этой области).

Кстати, на упомянутом сайте есть и небольшой анализ данных логов.

Вот есть программа New gTLD, в рамках которой хотят ввести кучу новых доменов верхнего уровня. При этом встречаются уже давно существующие домены верхнего уровня (двухбуквенные, между прочим), которые, похоже, особенно никому не нужны. Свежий пример: зона .td – национальный домен Чада. В минувший понедельник он сломался, упал полностью, так как стали недоступны серверы имён. Что-то начало восстанавливаться только в среду (сегодня), но, пока что, зона не работает. Прошло больше суток. Судя по всему, это время ушло на поиск действующих административных контактов – то есть, тех, кто мог бы вернуть домен в работу, обладая и полномочиями, и технической возможностью.

В RIPE NCC (это одна из мировых регистратур, распределяющих адресные ресурсы Интернета) поступил факс из организации UANI (США), в котором предлагается отозвать выделенные иранским провайдерам номера автономных систем, блоки IP-адресов.

Если RIPE NCC это сделает, то иранский сегмент Интернета очень быстро “потухнет”. Причём, и на территории Ирана тоже. (Да, понятно, при определённых усилиях – можно за разумное время поднять обратно некий “независимый национальный интранет”, если перенастроить маршрутизацию.)

Вот. Интересное развитие Интернета.

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

Авария Go Daddy пока что самая крупная по “пользовательскому эффекту” в этом году. Если это была атака, то она очень замечательная и показательная. Сравнить, из относительно свежих, можно только с взломом Play Station Network.

Занятно, кстати, что отключение DNS для такого количества доменов гарантированно приводит к проблемам у других массовых сервисов. Например, начинают “пухнуть” очереди у почтовых серверов: доставить почту они не могут, так как не ясно, куда её доставлять, но, согласно протоколам, должны пытаться отправить письма ещё несколько раз.

Посмотрим, что будет дальше.

Update (12.09.12): официальное сообщение.