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

Пишут, что турецкие провайдеры, в целях блокирования доступа к интернет-ресурсам, перехватывают трафик, идущий в сторону сервисов Google Public DNS. То есть, трафик пользователей, предназначенный для 8.8.8.8 и 8.8.4.4, заворачивается на локальные узлы провайдера, которые отдают поддельные ответы DNS (в частности, об адресах twitter.com). Перехват касается и других хорошо известных сервисов DNS-резолвинга.

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

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

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

Есть такой небольшой проект – домен Nox.su, который я использовал для исследования и практической демонстрации технологии DNSSEC (это безопасное расширение DNS). Недавно, в конце ноября, исполнилось два года с момента внедрения DNSSEC в nox.su. (Я, как и прежде, полагаю, что это первый домен .su, подписанный DNSSEC.) Об очередной годовщине дал знать криптографический ключ KSK для зоны nox.su – он успел “протухнуть”. На смену ему уже заготовлен новый.

Нельзя сказать, что за пару лет DNSSEC “шагнула в массы”, а сейчас является штатным средством защиты в Рунете: в .ru, потенциально, подписано лишь что-то около двух сотен доменов (в статистике по ссылке ведётся учёт только DS-записей). Тем не менее, популярность DNSSEC набирает, но, конечно, слишком медленно.

(Отмечу, что я за это время подготовил ещё несколько ресурсов и публикаций, касающихся DNSSEC. Среди них, например: браузерный инструмент проверки поддержки DNSSEC; справочная страничка dnssec.pw и демонстратор DNSSEC + TLS 1d.pw.)

Занятный момент есть в официальном 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.

Сделал простой сервис, позволяющий проверить из браузера, есть ли поддержка DNSSEC у DNS-резолвера, которым вы пользуетесь. Скорее всего, это резолвер интернет-провайдера. Сервис здесь: dnssec.dxdt.ru.

Там, на странице сервиса, описано, как он работает. Механизм очень простой, но, во-первых, требует, чтобы был включен Javascript, и, во-вторых, определяет положение вещей с точностью до настроек браузера, а не операционной системы. Тем не менее, штука, на мой взгляд, полезная.

Кстати, если у вас есть секретный ключ от подписей DNSSEC, для, скажем, зоны первого уровня, то быстро подменять адреса и перехватывать трафик в доменах второго уровня этой зоны, не нарушая безопасности ключей, можно так: генерируется “теневая” зона, сразу содержащая нужные “перехватывающие” записи. Эта зона подписывается по той же схеме, что и публичный экземпляр. Узлы, осуществляющие перехват и подмену DNS, имеют доступ к “теневой” зоне, откуда в нужный момент извлекают подписанные записи. Естественно, такая схема работает только при наличии соответствующей авторизации.

По сравнению с инфраструктурой SSL – есть важное отличие: нельзя осуществлять подмену адресов в других доменах первого уровня, от которых у вас нет ключей, а только в своём. SSL-сертификат удостоверяющий центр может выпустить для любого домена.

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

Дальше немного технической части.

Убедиться в поддержке DNSSEC можно следующим образом (8.8.8.8 – один из адресов резолвера Google):

$ dig @8.8.8.8 -t A +dnssec dxdt.ru

; <<>> DiG 9.8.1-P1 <<>> @8.8.8.8 -t A +dnssec dxdt.ru
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45823 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

– наблюдаем установленный бит AD в ответе (зона dxdt.ru – подписана, это факт).

$ dig @8.8.8.8 -t A +dnssec broken.nox.su

; <<>> DiG 9.8.1-P1 <<>> @8.8.8.8 -t A +dnssec broken.nox.su
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 52027

– наблюдаем SERVFAIL, это правильно, потому что broken.nox.su – специально сломана, чтобы можно было протестировать поддержку DNSSEC; если резолвер не проводит валидацию, то в ответе будет IP-адрес (для broken.nox.su это, обычно, 0.0.0.0).

Ещё пример, используем добротно сломанный dotsu.su:

$ dig @8.8.8.8 -t A +dnssec dotsu.su

– ответом должен быть SERVFAIL, и оно так и есть, по крайней мере, на моей стороне.

(Вообще, пока официального объявления нет, нужно полагать, что эта новая функция работает не для всех узлов, то есть, результаты могут отличаться.)

Этот шаг Google может неплохо помочь в продвижении DNSSEC, а заодно повысит популярность их DNS-резолверов.

Буквально вот только что в корневой зоне DNS появилась DS-запись для ключа зоны .ru. То есть, теперь DNSSEC в .ru есть и работает.

В зоне .ru вчера появились записи DNSKEY, в которых опубликованы ключи KSK и ZSK для зоны, с соответствующей подписью. Следующий шаг – появление DS-записей (тоже с подписями) в корневой зоне DNS. Что, как обещают, должно случиться до конца года.

Координационный и технический центры российских национальных доменов готовятся к введению DNSSEC в .ru – это основной домен из трёх (su, рф, ru). Вот, пишут, что сгенерировали ключи и положили их на изолированный компьютер (air gap, да). Подписать .ru обещали до конца этого года. Так что можно, в принципе, готовить серверы и свои зоны. (Я dxdt.ru уже подписал; вот значение для DS – 12E833887648F73B80E06CC86252E025FFE5F75F.)

Тут спрашивают, достаточно ли устроить DNS-резолвер на собственном сервере или использовать сервис наподобие Google Public DNS, чтобы меньше беспокоиться о подмене ответов DNS (которые могут увести куда угодно)? Нет, не достаточно. Ключевой момент тут в IP-адресах. Предположим, что у вас настроен в качестве резолвера собственный сервер (пусть это будет BIND), доступный по IP-адресу 1.2.3.4. Откуда ваша локальная операционная система знает, что, отправляя запросы и получая ответы от 1.2.3.4, – она “разговаривает” именно с нужным резолвером?

Если в качестве точки перехвата трафика используются ближайший к вашему узлу шлюз, то очень легко сделать так, что по адресу 1.2.3.4 будет отвечать какой угодно подставной сервер. Посудите сами: сейчас даже новомодные точки доступа WiFi используют такую технологию, чтобы вместо нужного сайта показывать в браузере собственную страницу с сообщением об “ошибке соединения”, если там, например, кабель выпал (делать так, конечно, форменное безобразие). То же нередко реализуют интернет-провайдеры. Технология простая: маршрутизатор, вместо того, чтобы отправить пакеты в Интернет, перенаправляет их внутреннему узлу. Так что на запрос к 8.8.8.8 (гугловский DNS) может поступить самый неожиданный ответ: mail.google.com = 192.168.1.1. Более того, благодаря возможностям по спуфингу, существующим в типичной локальной сети, перехватить трафик может не только маршрутизатор. Ну и существует ещё несколько способов, позволяющих подставить другой сервер вместо вашего резолвера. Что, кстати, напоминает ситуацию со спуфингом GPS. (Как страшно жить.)

Возвращаемся к DNS. Что делать? А просто не нужно забывать об аутентификации. Так, если вы используете свой резловер без VPN, то потребуется настроить TSIG – то есть, подписывание запросов и ответов клиентом и сервером, стандартный механизм при обмене файлами зон.

Я делаю так: на локальной машине в качестве резолвера поднят BIND с поддержкой TSIG, для него в качестве “форвардера” настроен сервер резолвера – в файле конфигурации named.conf директива forwarders:

forwarders {
1.2.3.4;
};

(1.2.3.4 – IP-адрес резолвера).

Для удостоверения сообщений требуется общий секретный ключ. Его можно сгенерировать утилитой dnssec-keygen, входящей в пакет BIND9:

$ dnssec-keygen -a HMAC-MD5 -b 128 -n HOST megakey

(пояснения к параметрам: тип алгоритма HMAC-MD5, 128-бит, ключ для хоста).

Результатом работы является пара файлов, примерно с такими именами: Kmegakey.+157+14629.key и Kmegakey.+157+14629.private. Значение ключа, в виде строки Base64, можно взять из .private. Ключ, понятно, секретный.

Теперь в конфигурацию обоих BIND-ов, на клиенте, и на сервере, нужно добавить записи о ключе и директивы, предписывающие этот ключ использовать. Самый правильный способ: ключи вынести в отдельный файл, защитить его правами доступа, а в конфигурацию добавить с помощью include. Что, кстати, на отдельном виртуальном сервере может оказаться избыточным.

Описание ключа, для speckey.conf.key или прямо для named.conf:

key “resolver-key” {

};

Понятно, что SuperMEGAKey допустимо заменить на ваш собственный секретный ключ.

Назначение ключа узлу (серверу), в named.conf, ничего секретного в строке нет:

server 1.2.3.4 {

};
};

Здесь 1.2.3.4 – адреса узлов: на клиенте – серверный адрес, на сервере – клиентский.

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

Осталось напомнить, при чём здесь VPN. При установлении соединения VPN уже проводится аутентификация и сервера VPN, и клиента. По крайней мере, если VPN настроен правильно. Поэтому, если DNS-резолвер работает в той же виртуальной сети, что и шлюз VPN, особого смысла вводить дополнительную проверку транзакций нет. Хотя, можно и ввести, конечно. Всё зависит от типа паранойи.

Спрашивают в комментариях к записке об использовании открытых и “чужих” сетей – зачем нужен собственный резолвер DNS, налаженный внутри VPN?

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

Понятно, что в случае с собственным VPN-соединением, запущенным через “чужую” сеть, определять адреса серверов может всё тот же провайдерский резолвер. В конце концов, через VPN ходит TCP/IP, а не символьные имена доменов. После того, как резолвер определил IP-адрес сервера, соединение будет устанавливаться уже через VPN.

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

Другое решение – держать рекурсивный резолвер локально, на своём ноутбуке. Я не уверен, может ли это делать Windows (наверное, может), но с юниксоподобными системами проблем нет, достаточно поднять локальный BIND. Трафик резолвера нужно завернуть в VPN, это обеспечит секретность. (Тут есть подводный камень: использование NAT, – а трафик из VPN во внешний мир может выходить именно через NAT, – грозит тем, что испортится один из защитных механизмов DNS, который называется “рандомизация портов UPD на источнике запроса”; но это другая история.) А главный недостаток один: нужно на каждом клиенте VPN держать свой рекурсивный резолвер. Неудобно. Поэтому куда более логично разместить собственный резловер на сервере, обеспечивающем VPN. Всё равно этот сервер работает постоянно.

А кроме того, редкий провайдерский резолвер поддерживает DNSSEC. Я таких вообще не видел.

(И, хорошо, можно использовать открытые сервисы, наподобие Google public DNS, но это всё ж не то решение, которое сравнится с собственным резолвером. При этом гугловский сервис быстрее. В моём случае – заметно быстрее.)