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

Вот, буквально сегодня делегировали новый домен верхнего уровня: .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, практически недоступен для анализа и перехвата.

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

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

Ну что, прибыл новый ровер на Марс – успешно. Уже присылает картинки. Интересно, сколько времени проработает?

Вокруг предстоящей 6 августа посадки марсохода Mars Science Laboratory (MSL, Curiosity) очень большой шум и ажиотаж в СМИ. Транслировать информацию о ходе завершающей стадии полёта собираются самыми разнообразными способами. Шумиха точно находится на границе разумного. Если уже не за ней. Как бы чего не вышло. Хотя, аппарат-то тщательно оттестирован и, наверняка, построен грамотно, с использованием отлаженной технологической цепочки, что называется, “полного цикла”. Не то что в некоторых других случаях.

Посмотрим, в общем. Утром. 6 августа. Самое занимательное, конечно, что до сих пор на Марсе работает один из предыдущей пары роверов – Opportunity. Уже восемь лет. То есть, если так пойдёт и дальше, то у более совершенного MSL появляются шансы дождаться прилёта экспедиции людей.

Три фото прототипа ударного беспилотника X47B. Вид в полёте снизу:

Два вида на сопло, устроенное не самым обычным образом:

Понятно, что основная идея здесь – отвод теплового потока вверх. Но, видимо, решение не только этой задачи двигало конструкторов к такому варианту сопла.

(Фото: Northrop Grumman.)

А свежее видео полёта доступно по ссылке.

Познавательное видео: канадская подводная лодка потопила штатовское судно (корабль?) поддержки. Понятно, что это учения, а судно списанное. Но, тем не менее, более 9 тыс. тонн. Ссылка под картинкой ведёт на YouTube.

DARPA проводило открытое мероприятие UAVForge. Примерно в течение года. Основная идея: построить практический демонстратор микробеспилотника, пригодного для транспортирования одним человеком и способного более или менее автономно выполнять простые задачи. Ключевая особенность: использование модного “краудсорсинга”, когда в оценке идей и формировании направлений разработки при помощи Интернета напрямую задействована большая группа людей, изъявивших желание принять участие в проекте. (Да, в принципе, Интернет тут не обязателен, но другой, сравнимой по эффективности, базовой коммуникационной технологии пока нет.)

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

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

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

2009 – 11

2010 – 11

2011 – 10

2012 (до 1 июля) – 6

В общем, встречи единичные.

(Данные встретил в DEW Line, первоисточник – на официальном сайте.)

Ремарка к новостям блокирования: занятно, что на IP 216.239.32.21 – указывает около 7 тыс. доменов .RU, .SU, .РФ, и это IP из пула Google.

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