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

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

На сайте Роскомнадзора опубликованы документы ведомства, касающиеся методов фильтрации Сети. Кто следит за темой фильтрации и введения границ в Интернете – почитайте, весьма полезно.

Там, кстати, упомянуты самые прогрессивные технологии, касающиеся систем адресации: DNSSEC и (даже!) DANE. Вот, например, цитата про DNS-блокирование:

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

В RIPE NCC измеряют связность Интернета. В Сирии Интернет недавно погас совсем – на сайте RIPEstat можно посмотреть, как это произошло, и, возможно, позже увидеть, как сирийский сегмент вернётся обратно в мировую сеть.

Вообще, stat.ripe.net – это очень полезный, довольно удобный, мощный инструмент для того, чтобы посмотреть, как в Интернете что работает. Для интерпретации данных, правда, нужно иметь достаточно глубокое представление о соответствующих протоколах и организации Сети. Но, тем не менее, сервис этот рекомендую, в том числе, людям, пишущим об Интернете.

Update: вечером (около 18:00 по Москве) 8 мая сирийский сегмент вновь стал виден для остального Интернета.

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

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

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

В качестве ответа очередной порции проблем с доступностью NS-ов в RU-CENTER ввели, в дополнение к уже существующим, серверы, построенные с anycast. Теперь должно стать надёжнее.

В свежем журнале “Открытые системы” моя статья про технологию 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.

На stat.nic.ru – очередное обновление: большая статья с результатами исследования веб-технологий, используемых в Рунете, и их сравнением с международным сегментом Сети (тему в RU-CENTER ведёт Артемий Ломов). Данных много, поясняющего текста тоже немало. Рекомендую всем, кому интересно, как сейчас устроен рунетовский веб. Исследование, вообще говоря, уникальное.

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

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

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

Занятный момент есть в официальном FAQ по Google Public DNS – они пишут, что если адрес, который не проходит валидацию DNSSEC, является популярным и хорошо известным, то для него может быть сделано исключение: валидацию отключат.

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

С другой стороны, именно популярные доменные зоны и могут стать привлекательной целью для атак. И, выходит, Google результаты таких атак будет транслировать пользователям. Не очень радужная перспектива.

Цитата из FAQ:

How does Google Public DNS handle lookups which fail DNSSEC validation?

If a client requests a validated lookup for a signed domain, but Google Public DNS cannot validate the lookup (due to misconfiguration, missing or incorrect RRSIG records or DNSKEY records, etc.), it will return an error response (SERVFAIL). However, if the impact is significant (e.g. a very popular domain is failing validation), we may temporarily blacklist the zone from validation until the problem is fixed.

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

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

Беда в том, что “Яндекс” пришёл далеко не один раз, не дождавшись истечения TTL (“время жизни” ответа, управляющее продолжительностью нахождения данных в кэше). Можно предположить, как всё это устроено на стороне “Яндекса”: используется группа серверов-резолверов (часть из них имеет адреса из диапазона 213.180.200.240/29), с раздельными кэшами, балансировка входящих запросов не учитывает состояние кэшей, взятое относительно источника запроса. То есть, пока каждый резолвер не загрузит данные, требуемые для ответа на запрос, вероятность попасть в кэш мала. Дело в том, что последовательные запросы отрабатывают разные резолверы: хорошо видно, как они повторно приходят на NS до истечения TTL.

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

(Да, Google Public DNS кэширует правильно, повторно раньше времени не приходит.)

Думаю, в “Яндексе” есть объяснение, почему так сделано. Но сделано некрасиво. Даже для бета-версии.