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

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

Понятно, что такой инструмент “ломает” DANE. (Напомню, что DANE привязывает, при помощи DNSSEC, SSL-сертификаты к домену.) Один из сценариев: интернет-провайдер подменяет в ответе DNS-резолвера цепочку подписей для домена, включая туда нужные записи DANE, показывающие на “подменный” SSL-сертификат. DANE рекомендует проводить проверку подписей DNS на клиенте, тем самым обеспечивается защита от подмены данных резолвером интернет-провайдера, однако в случае с “теневой зоной” никакой защиты нет: все подписи валидны, а сертификат получаем “подменный”. Более того, DANE, при условии подходящей браузерной реализации, тут позволяет использовать “недоверенный” (даже самоподписанный) сертификат, удостоверив его DNSSEC, что даже облегчает перехват HTTPS (потому что не нужно привлекать удостоверяющий центр).

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

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

Конечно, у подобных систем есть свои проблемы. Например, они могут конфликтовать с геораспределёнными системами, которые по своим внутренним причинам отдают пользователям из разных регионов разные данные. Впрочем, эта особенность в большей степени касается SSL-сертификатов, чем DNSSEC.

В контексте проекта мониторинга CMS в Рунете часто спрашивают, как сопровождать робота, собирающего статистику по сайтам. Отмечу, что при большом числе запросов (а робот, опрашивающий CMS-ки, генерирует этих запросов десятки миллионов), важна каждая мелочь. Кратко поделюсь некоторым нашим опытом.

CMS определяются по сигнатурам. Конкретная сигнатура для веб-сервера строится на основании анализа его ответов на специальный набор запросов. Естественно, сама методика опроса серверов должна быть оптимизирована в плане нагрузки. Например, там где только возможно, используются не GET-запросы, а HEAD. Также ограничен разумной величиной поток запросов на конкретный веб-сервер.

Робот корректно представляется в User-Agent. В нашем случае вот так: “Web-Monitoring/1.0; +http://monoid.nic.ru/”. Здесь присутствует адрес в корпоративном домене, под которым находится веб-страница с максимально подробным описанием того, что это за “зверь” забежал на ваш сайт. Почитайте: monoid.nic.ru. Практика подтверждает, что такая страница – необходимый элемент: она снижает обеспокоенность веб-мастеров.

Для IP-адреса, с которого ходит робот, обязательно нужна заполненная обратная зона, с говорящим именем, расположенная в том же узнаваемом корпоративном домене. В нашем случае это monoid-srv.nic.ru. Корректная обратная зона приветствуется не веб-мастерами, но админами и инженерами NOC-ов. (Да, возможно, с точки зрения внешнего наблюдателя, идеально было бы держать веб-сервер с информационной страницей на том же IP, с которого ходит робот, но технологически добротная реализация этого варианта слишком уж затратна.)

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

(А подробное описание методики с оценкой точности, подготовленное Артемием Ломовым, тоже опубликовано на stat.nic.ru.)

Исследовали состояние дел с поддержкой DNSSEC в домене .RU. Пока что корректно подписано только 54 зоны. Всего “пытались подписать” 82 зоны. Самая распространённая причина неработоспособности – просроченные подписи.

Очередное “открытие” из разряда особенностей Skype. На этот раз, похоже, нашли бекдор, сдающий на серверы Microsoft ссылки из переписки пользователей. Подтверждается некоторыми другими источниками, сам я не проверял. Ранее писали про китайскую версию Skype, которая делает примерно то же самое.

Естественно, клиент может передавать всё содержание переписки, причём таким образом, что простым анализом трафика с клиентского компьютера выявить ничего не удастся. Что тут можно сказать? Хорошая программа – Skype. Полезная. Во многих отношениях.

И не одна она, такая программа.

На сайте Freelance.com забавное предложение:

I need a preimage for a specific MD5 hash (will be revealed in private message). Length or content of the image doesnt matter (however I would pay more if I could choose a prefix)

[Мне требуется прообраз для заданного MD5-хеша (раскрою в личном сообщении). Длина или значение прообраза не играют роли (хотя, я готов заплатить больше, если смогу выбрать префикс)].

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

Вот, старая тема вновь всплыла: говорят, что в Штатах записывают все телефонные разговоры внутри страны, чтобы потом, если вдруг, то запись поднять и прослушать.

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

Если есть система распознавания речи, то объём данных можно резко сократить, сжимая текстовое представление, полученное после расшифровки аудиосигнала. В таком варианте нет никаких проблем с хранилищем: люди за год не наговорят даже на сотню жёстких дисков. Распознавание не требуется вести в реальном времени, можно устроить буферную зону из которой данные перетекают в текст по мере обработки. Очевидно, что фрагменты, которые не удалось уверенно распознать, можно сохранять в звуковом виде, в качестве дополнения к текстовой расшифровке.

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

На сайте популярной онлайн-игры World of Tanks в разделе “Личный кабинет” есть инструкция по выбору паролей. Помимо прочего, инструкция гласит:

Qwerty – короткий и очевидный пароль;
Vjq1gfhjkm2 – сложный и достойный пароль.

Забавно здесь вот что: второй пароль, названный сложным и достойным, – чисто словарный. Это всего лишь строка “Мой пароль” (два словарных слова, типичных для данной области), набранная в латинской раскладке, с добавлением, последовательно, цифр 1 и 2 между словами. То есть, с точки зрения перебора специалистом, владеющим инструментарием, оба пароля из примера имеют эквивалентную сложность (и очевидность).

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

Да, понятно, что это, наверное, такая шутка авторов инструкции.

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

Допустим, в игре проводится только односторонняя аутентификация: клиент аутентифицируется сервером, но не наоборот. И есть, скажем, простой механизм смены IP-адреса сервера в ходе работы игры, реализованный отправкой пары управляющих команд клиенту. Тогда некий активный злоумышленник может наугад заливать потенциальных играющих клиентов левыми UDP-пакетами, пытаясь вынудить клиента выполнить смену сервера. Если клиентов в игре много, а протокол, ввиду экономии, не защищён, то есть большие шансы на успех. В качестве нового сервера, понятно, выступает узел, контролируемый злоумышленниками, который перехватывает соединение и, запросив авторизацию, крадёт/меняет пароль от игрового аккаунта (если позволяет протокол).

И это не единственный сценарий атаки, который позволяет построить протокол UDP.

В свежем журнале “Открытые системы” моя статья про технологию DANE (доступ по подписке). Напомню, что DANE – это весьма полезное улучшение для систем безопасности, действующих в Интернете: cуть DANE состоит в публикации дополнительной информации об использовании SSL-сертификатов при помощи DNS, защищённой DNSSEC.

(Я часто писал про DANE на dxdt.ru.)

DNSSEC удостоверяет информацию, размещаемую в DNS. Вообще, современное понимание DNS сильно шире простого преобразования “символьное имя <-> числовой адрес”. Эту систему рассматривают как распределённую базу данных, хранящую некие пары значений и снабжённую не менее распределённым механизмом для поиска. То, что при помощи DNS можно сопоставлять символьные имена хостов и IP-адреса – это лишь одно из применений полезного сервиса.

Например, существует такая ресурсная запись (то есть, пара значений из базы данных DNS) – SSHFP, SSH FingerPrint. Эта запись позволяет разместить в DNS отпечаток серверного криптографического ключа, используемого для доступа при помощи SSH. Зачем? Для того, чтобы SSH-клиент мог сверить данные, полученные при установлении соединения от сервера, с данными, размещёнными в DNS, и лишний раз убедиться, что всё в порядке, канал никто не перехватывает – или наоборот: перехватывает.

Для того, чтобы схема имела смысл, доменная зона должна быть безопасной, подписанной DNSSEC. Понятно, что подписанная зона удостоверяет IP-адрес, с которым будет устанавливаться соединение по SSH. Но DNS никак не гарантирует, что это соединение не перехвачено на уровне IP, и атакующий не подменяет сервер.

Включить проверку можно при помощи настройки SSH-клиента. Например:

$ ssh -o VerifyHostKeyDNS=yes test@example.com

(Понятно, что опцию VerifyHostKeyDNS можно просто указать в конфигах.)

Отпечаток, размещаемый в DNS, генерируется (в Linux-ах) при помощи следующей команды:

$ ssh-keygen -r dxdt.ru

Например, я держу такую запись в зоне dxdt.ru, которая, естественно, подписана DNSSEC. Выглядит запись так:

dxdt.ru. IN SSHFP 1 1 0A1D19C05D239CCE90EE616DEB2EF80B35F3759B

– посмотреть может каждый, опросив серверы, поддерживающие зону.

На мой взгляд, полезное применение DNSSEC.

ICANN принимает комментарии общественности по вопросу ротации корневого KSK, используемого в глобальной DNSSEC. Корневую зону DNS администрирует организация IANA (при участии VeriSign). Напомню, что для генерации подписей корневой зоне используют ключ ZSK (Zone Signing Key), который, в свою очередь, удостоверен подписью, полученной при помощи корневого KSK (root Key Signing Key). Этот последний KSK является неким самым главным ключом от DNS, встроенным в валидирующие резолверы, позволяющим строить “цепочку доверия”.

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

Комментарии по проблеме принимают до 31 мая. Эту дату могут и сдвинуть. Когда проведут ротацию ключей и каким методом – пока вообще не ясно. Скорее всего, будет отдельный проект и несколько рабочих групп. Это в традиции ICANN.