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

Пару часов назад сломались сервисы Go Daddy, в том числе, недоступны их серверы DNS. Там куча доменов (рунетовских, правда, не так много – например, вот эти на dns.dxdt.ru). Соответственно, они упали тоже. Да уж. Беда прям.

Пару лет назад я писал об основной особенности “Википедии”, транслирующей преломлённое СМИ отображение реальности в массы. Да, “Википедия” выступает неким лавинным усилителем постмодернизма. На днях появился очередной пример, подтверждающий, что всё так и работает: писатель Филип Рот (Philip Roth) попытался внести правки в википедическую статью, рассказывающую о его собственном произведении (The Human Stain), однако получил отказ – не авторитетный источник, требуется ссылка на СМИ или что-нибудь подобное. Пришлось Роту публиковать в СМИ открытое письмо, дабы получить “авторитетный источник”. После этого статью таки поправили.

(На историю навёл Дмитрий Леонов.)

Пробую амазоновский инструмент для балансировки трафика, работающий через DNS. Называется Route 53, балансировка сводится к тому, что DNS-серверы отвечают разными адресами для запрашиваемого имени, в зависимости от (топологического) местоположения спрашивающего: какой дата-центр “ближе” (меньше задержка при доставке пакетов), тот IP-адрес и отдаётся. Метод, в общем, довольно старый. В случае с “Амазоном” – главная особенность в том, что они сами измеряют задержки. Вот. Так что я завёл специальную зону и домен – dns.poligon.tankodrom.net, поднял два веб-сервера, и добавил (временно) специальную картинку в код dxdt.ru, чтобы посмотреть на эффект. Если вы ближе к Штатам, то dns.poligon.tankodrom.net будет отвечать по http одним адресом, а если вы ближе к Европе, то другим.

Популярное нынче обсуждение использования спецслужбами ботов в социальных сетях продолжает шествие по газетам. Теперь “Коммерсантъ” сообщает про целых три автоматизированных системы, которые, якобы, заказала СВР. Тема богатая, конечно. Не ясно, правда, почему газеты приплетают сюда ботов.

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

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

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

Обновляется БД, содержащая слепок системы адресации Рунета. Традиционно, немного статистики (это без учёта погрешности; так сказать, нижние пределы), по состоянию на 19/08/2012 (в скобках, тот же показатель по состоянию на 03/07/2012 и прирост): уникальных IP – 216936 (212898; +4038); уникальных имён NS-ов – 188009 (189782; −1773); уникальных имён MX-ов: 1179147 (1153618; +25529).

Надо подчеркнуть, что использование сервисов вроде Google Public DNS – не слишком хорошо защищает от подмены и перехвата (блокировки) доступа. Как я уже писал, никто не мешает узлу, переправляющему ваш трафик в строну сервиса Google, ответить на DNS-запрос вместо сервиса Google (да ещё и быстрее). То есть, пока нет криптографических механизмов проверки подлинности ответа, подменить гугловский DNS не так трудно, адреса его известны.

Занятно, что подобная подмена распространяется и на все другие этапы разрешения имён DNS. Если вы контролируете подходящий маршрутизатор, то отвечать можно и за корневой сервер доменной системы имён (так блокируют доступ к сайтам на практике, например, в Китае). А из-за особенностей протоколов DNS, ответ, пришедший якобы от корневого сервера, может сразу содержать адрес узла, соответствующего запрошенному имени. Спросили www.yandex.ru? Ну вот и получите в ответ – 127.0.0.1.

Вот, буквально сегодня делегировали новый домен верхнего уровня: .POST. Такая всемирная “олдскульная” почта. “Олдскульная” потому, что не e-mail же. Администратор домена – Всемирный почтовый союз.

Теперь для DANE есть соответствующий RFC-6698. Ждём поддержки браузерами. Есть шансы, что реализуют оперативно, а Chrome сохранит статус первопроходца.

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

Меня попросили поделиться инструкцией о том, как настраивается VPN с использованием виртуального сервера из амазоновского EC2 (часть AWS – Amazon Web Services). Инструкцию размещаю на dxdt.ru, ведь в современном Интернете VPN – полезный инструмент. Подобные инструкции есть в Сети, но я попробовал ещё раз пройти всё детально по шагам, собрать все этапы вместе, включая настройку DNS. Более того, в рамках данной инструкции мы ещё разберёмся с созданием собственного “удостоверяющего центра” для выпуска SSL-сертификатов и создания инфраструктуры для аутентификации узлов. И DNS, и особенности управления сертификатами (отзыв сертификатов; проверка имён, например, при помощи директивы VPN tls-remote) – среди тех ключевых моментов, о которых постоянно забывают, настраивая “личный” VPN.

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

Описание длинное, с картинками, поэтому прячу под “Читать полностью”.

Читать полностью

Тут спрашивают, достаточно ли устроить 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, особого смысла вводить дополнительную проверку транзакций нет. Хотя, можно и ввести, конечно. Всё зависит от типа паранойи.

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

Между тем, повысить надёжность поддержки DNS не так уж и сложно. Есть такой понятие, как вторичный сервер DNS (slave, secondary) – этот сервер получает данные об адресации внутри домена (файл зоны) с первичного или другого вторичного сервера, то есть, просто копирует данные, в автоматическом режиме. Понятно, что клиенты могут использовать для получения адресной информации и первичный, и любой из вторичных серверов. Разумно использовать в качестве вторичных серверы, расположенные в другом регионе, у другого провайдера, и так далее. То есть, построить систему, распределённую в техническом и административном смыслах. В таком случае авария серверов имён у одного провайдера не будет приводить к отказу домена в целом, то есть, сайт будет доступен.

Услуги поддержки вторичных серверов предоставляют все более или менее продвинутые DNS-хостеры. Скажем, RU-CENTER, GoDaddy и EasyDNS.