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

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

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

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

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

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

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

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

Понятно, что системы DPI годятся на роль инструмента, формирующего гибкие, в технологическом смысле, правила блокирования доступа к ресурсам. Есть, конечно, ряд проблем с реализацией масштабного анализа трафика: например, пакеты по Интернету могут ходить разными путями и, перехватив запросы от веб-браузера, можно не получить соответствующих ответов сервера. Но тут главное правильно расставлять точки перехвата. Так, интернет-провайдер заведомо может видеть весь трафик работающих через его сеть конечных пользователей.

Часто ссылаются на HTTPS, как на недоступный для подобного анализа протокол. Да, формально, HTTPS предоставляет зашифрованный канал связи. Но в реальности есть ряд методов, позволяющих, на практике, всю эту защиту перевести в разряд мнимых. Устройства для анализа сетевого трафика, находящиеся между пользователем и тем ресурсом, с которым он соединяется, давно умеют перехватывать сессию HTTPS в момент её установления, на лету генерировать SSL-сертификат для соответствующего ресурса и – пожалуйста, трафик можно прослушивать. Естественно, тут есть проблема с тем, что сертификат, выпущенный перехватывающим устройством, должен успешно помещаться в цепочку доверия браузера – иначе браузер выдаст предупреждение.

Но, во-первых, массовый пользователь игнорирует подобные предупреждения браузера, “заставляя” тот продолжить использование веб-сайта. Во-вторых, нет особых гарантий того, что удостоверяющие центры, входящие в список доверенных браузера, не участвуют в работе систем DPI. Собственно, вокруг второго момента, который, вообще-то, давно известен, сейчас разгорелся нешуточный сыр-бор. В случае, если автоматический инспектор трафика использует для генерации своих “перехватывающих” сертификатов сертификаты доверенного УЦ (не обязательно корневой, годятся промежуточные), то обычный пользователь браузера даже не увидит предупреждения, не заметит подмены. (Кстати, есть неплохой плагин для Firefox, позволяющий следить за тем, как браузер оперирует сертификатами – Certificate Patrol.)

Заметьте, что если у провайдера работает добротная система анализа трафика, то можно блокировать этот трафик не только по контенту или по адресам, но и по типу трафика, используя белый список. Соответственно, если поток не удаётся разбирать и классифицировать, то его можно заблокировать. Естественно, этот принцип работает и для HTTPS – если клиент не стал соединяться с перехватывающим трафик узлом, то соединение вовсе блокируется. Через настроенную подобным образом сеть не пройдёт канал VPN, даже если, скажем, он использует нестандартные порты (например, я использую собственный VPN, работающий по TCP, через 80-й порт).

Проблему передачи шифрованных данных через такую “фильтрующую сеть” можно решить, используя стеганографию – данные закрытого канала помещаются внутрь маскирующего, имитирующего “обычную” работу с рядовым веб-сайтом. Такие решения известны. Из новинок – вот есть Telex. Понятно, подобный канал будет медленным.

Кстати, фокусам с подменой SSL-ей отчасти может помешать внедрение технологий вроде DANE. Но нужно учитывать, что, в теории, тот же DANE, если говорить о типичном пользователе Интернета, перехватывается аналогичными SSL методами, здесь лишь сильно сужается круг тех, кто может осуществить такой перехват. Что, логичным образом, возвращает нас к мысли о реальных причинах шума, высказанной в самом начале заметки.