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

Тендер на техническое управление всей адресацией в Интернете – фактически, отменили (но будут проводить ещё один похожий). Официальная причина проста: не собрали достойных предложений. Напомню, что речь о так называемой IANA-функции, то есть, о важнейших технических рычагах, вроде распределения номеров автономных систем, IP-адресов, управления корневой зоной DNS. Ответственную организацию назначает минторг США, по результатам изучения предложений, мнения рынка и мнения сообщества.

Если в двух словах, то это означает, что ситуация с контролем над Интернетом становится всё интереснее. Сейчас IANA-функцию выполняет ICANN. Естественно, ICANN выдвигалась и в новом тендере, собирала поддержку от международного интернет-сообщества. Но, если бы всё было гладко, то минторг, в итоге, именно ICANN мог бы и выбрать, по накатанной, так сказать. А тут вот как вышло: “не получили ни одного подходящего предложения”.

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

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

Да, текстовый канал можно отслеживать, анализируя записи и убивая всё подозрительное, что не является текстом на естественном языке. Это не исключает связь, прикрытую стеганографией, но гарантированно делает скорость обмена совершенно мизерной – сгодится разве что текстовые петиции распространять. Но остаются файлы изображений, а здесь можно надёжно спрятать довольно большой трафик. Проблема, верно?

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

Какой самый лучший способ добиться использования только “правильных” программ? Верно – нужно вынести их “в облако”, предоставив пользователю только интерфейс. Тоже не новость, к сожалению. А в качестве интерфейса должен быть особый тонкий клиент, скорее всего, просто браузер, намертво привязанный к аппаратуре доступа.

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

Спрашивают в комментариях к записке об использовании открытых и “чужих” сетей – зачем нужен собственный резолвер 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, но это всё ж не то решение, которое сравнится с собственным резолвером. При этом гугловский сервис быстрее. В моём случае – заметно быстрее.)

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

У ICANN опять новый сайт: icann.org. Судя по всему, традиционно сделан на Drupal (версия 7). И это правильно. А кроме того, показательно, в свете рунетовского рынка веб-разработок, где до сих пор не перестали изучать распространение “закрытых” коммерческих CMS-ок (а их мизерное количество) и сравнивать, рейтинговать их популярность.

Делюсь ссылкой на пример страницы, использующей Media Queries (это такая современная браузерная технология, позволяющая активно управлять отображением в веб) – для понимания того, как штука работает, нужно поманипулировать размерами окна браузера: изменяется и взаимное положение текстовых колонок, и размер шрифта. Кстати, те же эффекты происходят при просмотре страницы теста с мобильных устройств, при выводе на печать.

Автор теста – Артемий Ломов.

Вот даже Алекс Экслер в Испании подключается к “соседскому” открытому Wi-Fi, и исследует сетевые сервисы (я надеюсь, при помощи специально сконфигурированного ноутбука). А вы говорите! Что же ожидать от простых пользователей? Они тоже подключаются куда попало. В том числе, и всякими смартфонами, в которых куча персональной информации.

Кстати, есть специальные программные пакеты, имитирующие некую живую “открытую” сеть, с точкой входа через Wi-Fi. Для чего? Чтобы приманивать любопытных. Ну не только для этого, ещё и для своевременного обнаружения вторжений и исследования угроз. Вообще, понятно, что можно поднять такое приманивающее окружение самостоятельно, используя свободное ПО. Да.

А потом удивляются, что почту взламывают.

(Ага, это юмор по выходным.)

Кстати, обсуждение заметки про VPN в чужих сетях, навело на другую интересную мысль. Учитывая, что устройств, использующих доступ к Интернету, при себе всё больше, логичным решением для, например, отеля, является своя точка доступа Wi-Fi с тем же самым VPN-ом, засунутым внутрь. Должно быть удобно, потому что позволит использовать даже те устройства, которые с OpenVPN не дружат.

Чтобы проверить решение на практике, я взял валявшийся без дела роутер Wi-Fi ASUS RT-N12, залил в него прошивку DD-WRT, с поддержкой OpenVPN, загрузил сертификаты (там есть панелька в веб-интерфейсе даже, можно не браться за консоль) и – всё работает, благо, внутри у него Linux. Сложностей настройки не выявил. То есть, теперь сценарий такой: подключаем к чужой проводной сети (Ethernet, понятно) роутер, он поднимает внутри VPN, и получаем собственный зашифрованный и безопасный Wi-Fi, через который могут работать и смартфоны, и планшеты, и старый КПК. Удобно.

В продолжение истории Trustwave – компании, которая призналась, что выпускала SSL-сертификаты, предназначенные для скрытного прослушивания трафика HTTPS: Mozilla распространила весьма строгое по форме требование к удостоверяющим центрам, чьи корневые сертификаты встроены в этот популярный браузер. Цитата:

We have requested that any such certificates be revoked, and their HSMs destroyed. We have requested the serial numbers of those certificates and fingerprints of their signing roots so that we, and other relying parties, can detect and distrust these subCA certificates if encountered. We have requested that any CAs who have issued subCA certificates fulfill these requests no later than April 27, 2012.

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

Вообще, сведения о том, что вполне официальные удостоверяющие центры (УЦ), чьи корни встроены в браузеры, выпускают “особые” сертификаты для того, чтобы определённые “суперпользователи” Интернета могли качественно прослушивать трафик – это давно уже секрет Полишинеля. С технической точки зрения речь практически всегда идёт о программно-аппаратном комплексе, содержащем внутри секретный ключ, подписанный корневым сертификатом доверенного УЦ, и, понятно, соответствующий этому ключу сертификат дополнительного УЦ. Комплекс устанавливается в точке перехвата пользовательского трафика. Когда обнаруживается соединение по HTTPS, система на лету генерирует собственный сертификат для домена, с которым устанавливается соединение, перехватывает начало сессии и организует классическую атаку типа “человек посередине”. Так как представленный пользователю фиктивный сертификат (только что сгенерированный) подписан по всей цепочке, как полагается, и ведёт к одному из корней, встроенных в браузер, то никаких предупреждений пользователь не увидит. (Собственно, именно этот аспект нашей техномагической реальности позволяет специалистам скептически усмехаться, когда они слышат или читают про невероятную “защищённость пользователей” систем веб-почты, интерфейсы которых работают по HTTPS – типа, невозможно перехватить пароль и т.д.; да и не только о веб-почте речь.)

Другое дело, что только в прошлом году вся эта история с практикой SSL/TLS стала активно обсуждаться в популярных СМИ, а не только в забитых всякой математикой специализированных списках рассылки, которые мало кто читает. Теперь вот довольно-таки паникёрское заявление сделала Mozilla. Интересно, какую реакцию можно ожидать? Что, известные УЦ повинятся? Сдадут свои сертификаты? Перестанут сотрудничать с крупными и очень влиятельными клиентами? Что-то с трудом верится. Тем более, что отловить “кривые” сертификаты довольно трудно, они не светятся на весь Интернет, а пользователь, даже высококвалифицированный, столкнувшись с таким сертификатом, не сможет его распознать. Сейчас нельзя просто взять и выкинуть из браузеров корни всех тех УЦ, которые не смогли убедить разработчиков в том, что они белые и пушистые, подорвав тем самым бизнес этих УЦ – есть риск, что тут будет усмотрено нарушение законов о защите конкуренции. Просматривается, так сказать, полезный выход – это разработка новой технологии управления доверием в Интернете, и такая технология, вероятно, должна быть распределённой, ориентированной на пользователей. Собственно, об этом тоже сказано в исходном сообщении Mozilla. Но возможен и вариант, когда пользователи просто начинают доверять другому корню, скажем, корню DNS.

А если вернуться в сугубо практическое русло, то нужно сказать, что криптография пока что не сломана. Если использовать собственную инфраструктуру ключей и сертификатов, то перехватывать трафик “специальные” сертификаты других УЦ не позволят.

Ну и развитие истории подтверждает то, что производители браузеров всерьёз занялись игрой на рынке безопасности.

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

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

Технически решение выглядит вполне ожидаемо: виртуальный сервер из Amazon EC2, пакет OpenVPN и BIND, в качестве рекурсивного резолвера на том же сервере. В ноутбуке (на клиентах вообще) – Ubuntu (или другой дистрибутив) и тот же OpenVPN.

Не стану описывать детали настройки, на сайте OpenVPN есть подробное описание и примеры конфигурационных файлов, никаких проблем с тем, чтобы поднять сервер и настроить клиент не возникает. Более того, схема работает даже для клиентских машин под Windows, есть специальная оболочка.

Самый простой вариант настройки VPN это решение типа “точка-точка” с общим секретом (файл с ключом и для сервера, и для клиента). Решение простое, но малоинтересное. Например, потому, что нельзя реализовать одновременное подключение нескольких клиентов к серверу. Поэтому следует использовать вариант с сертификатами SSL. Естественно, покупать какие-то сертификаты для этого не нужно: берём OpenSSL и либо руками, либо при помощи скриптов от OpenVPN, генерируем всё, что нужно. А нужно: сертификат общего удостоверяющего центра, сертификат сервера, сертификаты для всех клиентов.

Другие особенности. Для VPN-сервера нужно взять фиксированный IP-адрес, это позволяет устанавливать соединение, не используя DNS. Я, впрочем, держу А-запись, указывающую на сервер. Так, на всякий случай. В конфигурационных файлах на клиентах, конечно, указан IP-адрес. Кроме того, на клиенте нужно указать и адрес собственного резловера (resolv.conf). Я использую тот же IP – VPN-сервера, потому что всё крутится на нём. На сервере в настройках BIND требуется дополнительно разрешить обработку рекурсивных запросов, приходящих от клиентов OpenVPN. А для того, чтобы трафик ходил наружу, нужно настроить NAT, в моём случае это делается при помощи правил в iptables.

Что мы получаем? Вот что: в результате весь трафик ходит через защищённый канал, который автоматически создаётся при подключении ноутбука к любой внешней сети. Есть потенциальная проблема с фильтрацией пакетов в чужой сети. Поэтому в качестве транспорта для VPN я использую TCP, ходящий на 80-й порт. Такое направление редко где закрыто, потому что, как известно, это HTTP от Веба, а Веб нужен всем. Есть и другие варианты: TCP и 443 (HTTPS) или даже “стандарт” – UDP и 1194, обычно работает.

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

(И, кстати, весь популярный “геотаргетинг” по IP-адресу – ломается. Например, “Яндекс” предлагает мне посмотреть карту Дублина и почитать дублинские новости.)

Занятно, что новые веб-технологии стороны клиента содержат всё больше и больше разнообразных “алгоритмических” добавок, работающих без всякого Javascript. Например, в технологии Media Queries есть логические выражения, преобразование которых проводит браузер, оперируя разными свойствами доступного окружения операционной системы (типа размера окна и так далее). Поделюсь парой полезных ссылок по этой теме, это статьи проекта WebHiTech:

• С удобством от устройства к устройству. Часть 1;
• С удобством от устройства к устройству. Часть 2.

А вообще, такое развитие – прямой путь к появлению всевозможных новых уязвимостей. Интересно, возникнут ли вредоносные программы, распространяющиеся исключительно внутри файлов CSS?