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

Современный смартфон – технически продвинутое устройство, которое не только обладает большой вычислительной мощностью, но и может обмениваться с внешним миром информацией по нескольким каналам. Да, каналы, завязанные на сети операторов связи (GSM и др.), являются централизованными, а поэтому могут быть в нужный момент отключены. Однако смартфон может быть узлом так называемой mesh-сети, которая является децентрализованной. В такой mesh-сети каждый узел-участник выполняет функции ретранслятора, передавая данные тем узлам, которые, в данный момент, оказались в пределах досягаемости. А пределы досягаемости задаются возможностями модуля WiFi и (как специальный вариант) Bluetooth.

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

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

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

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

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

Кстати, цитата: “The big story here is that these keys were generated by government-issued smart cards that were certified secure. The certificates had all the usual buzzwords: FIPS certification from NIST (U.S. government) and CSE (Canadian government), and Common Criteria certification from BSI (German government)“.

В продолжение темы аппаратных закладок: интересная работа Georg T. Becker, Francesco Regazzoni, Christof Paar и Wayne Burleson (по ссылке – PDF). Предложен метод внедрения аппаратных закладок (“троянов”) путём изменения легирующего состава (dopant), добавляемого в вещество, составляющее транзистор. В результате меняется тип проводимости, что влияет на электрические характеристики схемы.

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

В роли одного из практических примеров обсуждают модификацию аппаратного генератора случайных чисел Intel. Корректировка поведения транзисторов, изменяющая свойства регистров, сводит вполне корректную интеловскую схему генерации (псевдо)случайных чисел к фиксированному исходному ключу и небольшому количеству псевдослучайной энтропии. То есть, всё можно раскрыть простым перебором. Степень желаемой сложности перебора задаётся атакующим. Так, штатно работающий генератор выдаёт сложность 2^128, модификация позволяет сократить её до, например, 2^32 (доступно для перебора). Для непосвящённого в атаку аналитика, контролирующего качество элементной базы, результаты выглядят вполне себе добротно. Изменения не обнаруживаются и встроенной в схемотехнику системой самопроверки. Примерно такой подход снижения сложности перебора ключей, кстати, обсуждается в записке о гипотетической системе прослушивания TLS. Думаю, не нужно напоминать, что оборудование Intel весьма распространено.

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

Известно, что по каналам Интернета ходит большой объём пользовательского трафика, который, при непрерывной записи, сложно полностью хранить (в течение длительного времени). Предположим, что гигабитный канал, имеющий усреднённую загрузку 80%, генерирует около 290 гигабайт “полезного” трафика в час. Это примерно 7 терабайт в сутки, то есть, если мы используем хранилище данных в 1000 терабайт (несколько тысяч жёстких дисков, несколько стоек в дата-центре), его не хватит и на полгода.

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

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

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

Вот, старая тема вновь всплыла: говорят, что в Штатах записывают все телефонные разговоры внутри страны, чтобы потом, если вдруг, то запись поднять и прослушать.

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

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

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

Интересное наблюдение. Издание “Лента.ру” – lenta.ru – обновило дизайн, не так давно. Вместе с дизайном, конечно, обновилась вёрстка страниц. Некоторое время назад я отметил, что верстальщики новой “Ленты” используют элемент HTML5 time без понимания, что это такое за элемент, демонстрируя, тем самым, карго-культ HTML5. В тот раз time использовали для “обрамления” строки, содержащей время публикации новости или статьи, при этом формат использовали вот такой (значение я, для примера, взял произвольное): “12:31, 31 января 2013“. Соответствующий код (неверный!):

<time>12:31, 31 января 2013</time>

Поясню: спецификация требует указывать время для time в машиночитаемом формате, либо внутри самого элемента, либо в атрибуте datetime. (Обратите внимание на этот атрибут – он чуть позже сыграет ключевую роль в карго-культе.) Собственно, элемент time для автоматической обработки и придумали, поэтому машиночитаемый формат необходим. “12:31, 31 января 2013” – формат, понятно, неверный. Смысла в подобном использовании time нет.

Теперь в “Ленте” подкорректировали вёрстку. В time добавлен атрибут datetime. Замечательно. Казалось бы, так и надо. Дело в том, что использование атрибута datetime, содержащего машиночитаемое представление времени, позволяет указать внутри самого элемента что угодно, в том числе, и “кириллическую” строку с названием месяца. Казалось бы, исправили ситуацию. Но, внимание: разработчики “Ленты” предпочли в качестве значения этого атрибута установить ту же самую строку недопустимого формата, которая раньше стояла только внутри time. Например: datetime=”10:41, 12 февраля 2013″. Просто скопировали, видимо.

И вот мы получили очередной карго-культ HTML5, включающий сложный обряд из двух ходов. Почему подобное происходит именно в “Ленте”? Вопрос риторический.

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

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

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

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

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

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

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

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

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

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

В свете падения известных хостингов, которое сейчас обсуждают, поделюсь описанием того, как работает и где размещается dxdt.ru. Сайт я разместил на амазоновском EC2, на виртуальном сервере (сервер типа Small Instance). Операционная система Amazon Linux (это, по сути, Red Hat). Веб-сервер – Apache 2.2. Непродолжительное время использовал nginx в качестве обратного прокси к Apache, но, пока что , особого смысла в nginx, конкретно для dxdt.ru, не вижу: монструозный Apache справляется с небольшим трафиком.

БД – MySQL, на том же сервере; иногда с аппетитом кушает память. PHP + APC (это “ускоритель” PHP, как известно) + WordPress + кэшируюший плагин W3 Total Cache (очень полезный плагин оказался).

Есть поддержка HTTPS, но я использую собственный корневой сертификат (и это правильно, для данной модели), так что попытка обратиться по HTTPS стандартным браузером приведёт к ошибке/предупреждению. Понятно, что HTTPS предназначен для админки WordPress-а (WP). Тут надо заметить, что разработчики WP никак не допилят поддержку HTTPS, поэтому в некоторых случаях страницы (не принадлежащие к админке) генерируются с элементами, адресуемыми по HTTP (обычно, это картинки). Возможно, есть какой-то плагин, решающий эту проблему.

В целом, WP – неплохая CMS. Есть планы (о которых мне периодически напоминают) переписать dxdt.ru руками на специальный “движок”, отказавшись, наконец, от PHP. Интерес тут чисто спортивный. В качестве снарядов для данного спорта я сейчас рассматриваю связку Python + Django + MongoDB + какой-то не-Apache (nginx?). Но это планы, да.

Опыт использования амазоновского хостинга для dxdt.ru положительный. Доступность хорошая. Ресурсов хватает. Гибкости тоже. Нет трудностей с IP-шниками (кстати, важный фактор!). Например, удалось оперативно и без всяких проблем настроить обратную зону для IP-адреса dxdt.ru (это нужно для отправки почты с сервера) и всё такое прочее. Преимущество амазоновского сервиса в том, что тут предоставляется инфраструктура, то есть можно самостоятельно быстро поднять нужные серверы, что-то настроить, переключить адреса, ну и так далее. Это уровнем выше аренды обычного виртуального сервера, и удобнее, чем один физический выделенный сервер. Вообще, я амазоновским EC2 пользуюсь несколько лет, но для совсем других задач – сайты раньше там не хостил, а оказалось, что и для этого весьма хороший вариант. Кстати, домен dxdt.ru я поддерживаю тоже на паре NS-ов, находящихся в EC2 (это не амазоновский DNS, а виртуальные серверы с BIND-ом – всё жду, когда же КЦ и ТЦИ доделают DNSSEC в .ru, чтобы быстро внедрить поддержку, да, видно, нескоро это будет).

Вот.

Update (18/04/2014): эта записка некоторое время не обновлялась, а между тем, ещё в декабре 2012 года, в домене RU внедрили поддержку DNSSEC; конечно, домен dxdt.ru был подписан одним из первых.

Update (24/11/2014): c 21 ноября 2014 года dxdt.ru возвращает страницы только по HTTPS – этот безопасный протокол стал единственным для работы с сайтом.

То, что спуфинг для сигналов GPS возможен и доступен – известно давно. Сейчас вот обсуждают вполне практическую демонстрацию с беспилотником, который, при помощи интеллектуальной помехи, заставили совершить небезопасный манёвр (“перехватили управление”, так сказать). Это не первая демонстрация спуфинга, но довольно эффектная. Наиболее неприятная картинка вырисовывается, если соединить уязвимость GPS с гипотетическими самоуправляемыми автомобилями. В принципе, даже живые водители склонны излишне верить GPS, а что ожидать от автомобильной программы?

Не, понятно, что в автомобильные программы должны, конечно, встроить защиту и всё такое. И при обнаружении нарушения в сигнале GPS, авто, скажем, будет безопасно останавливаться. Хотя, толпа неожиданно замерших неподалёку от генератора помех автомобилей-роботов тоже вполне себе неприятность. Вообще, в свете управления беспилотниками “по GPS”, неясно, что автомобилю роботу лучше предпринять при сбое навигации. А ведь ещё можно вспомнить, что нынче по GPS ходят круизные лайнеры.