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

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

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

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

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

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

Вообще, последовательности (цепочки) некоторых событий, связанных с деятельностью персоны и возникающие в результате применения того или иного отношения порядка – часто уникальны. Отношение порядка тут может быть связано и со временем (открыл приложение “Блокнот”, а через две секунды – приложение “Калькулятор”), и с пространством (проехал базовую станцию “А”, потом базовую станцию “Д” и так далее), а может быть и ещё каким-то – главное, чтобы метки-события выстраивались друг за другом. Потому что тех, кто бывал и в магазине “Мебель”, и в магазине “Стекло”, и в магазине “Богатырь” – гораздо больше, чем тех, кто посетил эти три магазина строго в таком порядке: “Стекло” – “Мебель” – “Богатырь”. Что уж говорить про интервалы времени, взятые “между” магазинами.

Я ранее уже писал на dxdt.ru про идентификацию по цепочкам: например, про применение для деанонимизации мобильных телефонов (2010 год), про идентификацию людей по географическим координатам (2009 год) и не только.

В статье из 2019 года, посвящённой блокировкам и блокированию протоколов в Интернете, я писал вот что:

Среди перспектив развития систем контроля трафика (именно контроля) можно отметить пропуск только авторизованного трафика. Конечно, такой вариант пока кажется фантастикой. Авторизация трафика — это развитие схемы с белыми списками. В этом случае доступ по спискам IP-адресов и имен не ограничивается, но промежуточные узлы пропускают только трафик, который содержит специальные криптографические маркеры, подтверждающие его легитимность.

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

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

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

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

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

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

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

Часто попадаются в публикациях СМИ утверждения, что, якобы, это особенность “open source” в том, что в такие библиотеки и другое ПО включают “вредоносные возможности”. Но это не так. Модель распространения ПО никак не связана с возможностью добавления “вредоносного кода”: добавить такой код можно и в исходники, и в скомпилированный исполняемый код, а добавить что-то такое в скомпилированный код даже может быть проще, поскольку исходники ещё собирать кто-то будет и “зловредная нагрузка” может не собраться, собраться не так или не попасть в исполняемый код.

В подобных сообщениях СМИ, конечно, перепутаны подходы и термины. Открытый исходный код (Open Source) – это открытый исходный код. ПО, поставляемое с открытым исходным кодом, может быть проприетарным и коммерческим. Проблемы, о которых изначально шла речь, связаны с моделями и способами разработки кода, под открытостью тут подразумевается даже не свободная лицензия, а то, что, потенциально, любой желающий может предложить доработки и изменения. Но не факт, что предложенное будет принято безо всякой проверки. При этом в разных проектах устроены различные процессы проверки, той или иной степени защиты.

Естественно, трудности вызывает современное разделение по библиотекам и направлениям, которое приводит к тому, что возникает “развесистая” система зависимостей, за которой очень сложно, – даже невозможно, – уследить. Хрестоматийным примером тут является “экосистема” Node.js, где едва ли не под каждую элементарную подпрограмму делается отдельный “модуль”, а количество “вложенных зависимостей” очень велико. Но, естественно, речь не только про Node.js. Источники могут использовать самые разные правила добавления кода, а бывает так, что одиночная небольшая библиотека встроена в тысячи продуктов, которые тянут её код с собой. И вот, предположим, исходный репозиторий этот библиотеки оказался заброшен, а потом был взломан. Взломавший теперь получает возможность потенциальной инъекции произвольного кода в те самые тысячи продуктов. Но такая инъекция всё же может быть обнаружена.

Самое интересное, что сейчас во многих и многих программных продуктах, распространяемых в “бинарном исполняемом коде”, даже с закрытыми (условно) исходниками, всё равно присутствуют различные библиотеки из Open Source. Это касается и операционных систем, да даже и Windows. Про то, как можно рассматривать открытые исходники и “бинарный код” с точки зрения ИБ – я недавно публиковал отдельную записку. Но главное, не нужно смешивать “открытые исходники” (Open Source) с проблемами неконтролируемого добавления кода в некоторых способах коллективной разработки, равно как и с самой возможностью добавления “вредоносного кода” – такой код добавить можно и в виде “бинарной” вставки (то есть, фрагмента машинного кода).

Добавили обработку записей с информацией о DMARC и SPF на сервис проверки настроек интернет-узлов audit.statdom.ru (сервис, кстати, называется САБИУ): проверяется наличие соответствующих TXT-записей, для DMARC определяется заявленная политика.

Сам сервис позволяет получить отчёт о настройках интернет-узла, как эти настройки видны снаружи: вводите DNS-имя – получаете сведения о настройках DNS, TLS, HTTP, HTTPS, MX и показатель рейтинга в баллах (максимально – 100). Полезно при оценке того, как настроен ваш веб-узел и параметры почты. Из суперсовременных технологий – audit.statdom.ru умеет определять DNS-over-TLS на авторитативных серверах.

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

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

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

Логика работы DKIM такая: отправляющий сервер, используя секретный ключ, вычисляет подпись для некоторых технических элементов, составляющих сообщение электронной почты, встраивает значение подписи и вспомогательные сведения в состав сообщения (в так называемый “технический конверт”, который не виден для обычных пользователей), отправляет получившееся сообщение. Принимающий (или промежуточный) почтовый сервер, получив письмо, может использовать данные, переданные в DKIM-параметрах, для извлечения из DNS открытого ключа и, собственно, проверки подписи на сообщении. Если сообщение было отправлено сервером, который не имел доступа к нужному ключу, то этот сервер не может вычислить корректную подпись DKIM. В общем-то – всё. Именная принадлежность ключей и других параметров определяется на основании домена-источника. В самом простом случае – это домен почтового адреса, указанного в качестве отправителя письма. Тут, впрочем, есть технические тонкости, опять же, невидимые для типичного пользователя, но их сейчас можно пропустить: будем считать, что если в письме нужным способом указан адрес отправителя user@test.ru, то домен-источник – test.ru, для него и публикуются ключи в DNS (они публикуются в TXT-записях для специального имени-селектора).

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

Для того, чтобы администратор почтового домена мог типовым машиночитаемым способом опубликовать рекомендации по обработке поступающих сообщений другими серверами – придумана спецификация DMARC (Domain-based Message Authentication, Reporting, and Conformance). Опять же, это спецификация, описывающая способы публикации политик обработки почты, формат записи и принципы интерпретации. DMARC – это текстовая строка определённого формата, опубликованная в TXT-записи. DMARC предназначается для использования вместе с DKIM и SPF (Sender Policy Framework – здесь не рассматривается). Но, каким бы странным это ни показалось: публикация DMARC никак не зависит от DKIM, и наоборот. Внедрение DKIM на сервере-отправителе, отправка сообщений с DKIM – возможны без публикации DMARC, а публикация DMARC и эффективное использование – возможны без соответствующего по именам внедрения DKIM (пример – см. ниже). Естественно, DMARC и DKIM рекомендуется применять вместе: если вы настроили DKIM, то очень неплохо будет опубликовать и сведения политики в DMARC, поскольку эти сведения могут подсказать принимающему серверу, что ему делать с полученными из вашего домена письмами. Тем не менее, проверка DKIM не требует извлечения сведений DMARC. А DMARC может применяться без фактической поддержки DKIM.

Пример, хорошо иллюстрирующий ситуацию: администратор домена не планирует использовать этот домен в качестве почтового, поэтому требуется устроить так, чтобы принимающие серверы, поддерживающие DMARC (важная оговорка!), отбрасывали все сообщения с адресами из данного домена. В таком случае, администратор просто публикует строгую политику обработки DMARC (“reject”), но вовсе не размещает в DNS ключи DKIM и даже не настраивает почтовый сервер. То есть, администратор домена не предполагает отправки сообщений с адресами в этом домене, а такая конфигурация DMARC означает, что если какой-то другой сервер отправит такое сообщение, то оно может быть отброшено на принимающей стороне.

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

Вообще, эта история с встраиваемой в посторонние сайты браузером Firefox рекламы Mozilla VPN тоже имеет отношение к стремительно наступающему Новому Средневековью. Скорее всего, в этом конкретном случае, у пользователя всё ещё имеются возможности не подключать “промо” или “отписаться” (как минимум, сообщают, что можно выключить флаг в настройках браузера – что, конечно, само по себе показательно: флаг для отключения встроенной в браузер рекламы). Важно совсем другое. Ещё некоторое время назад разработчикам браузера могло бы показаться, что задача браузера состоит в отрисовывании веб-страницы максимально близко к некоторым спецификациям (“веб-стандартам” и пр.). Идея воспользоваться статусом браузера и модифицировать визуальное оформление страницы так, чтобы закрыть его собственной рекламой, должна была бы быть отброшена. Это не отменяет богатой истории подобных подмен, начиная с массового перенаправления “несуществующих доменных имён” с использованием положения провайдера авторитативных серверов DNS и вплоть до вмешательства в HTTP-трафик на стороне провайдера доступа или даже на транзите. Наоборот, такой исторический опыт и должен бы приводить к тому, что в приличном браузере подобные практики не могут рассматриваться. Но, конечно, не в условиях Нового Средневековья.

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

Пока что с Firefox это не сработало: пользователи всё поняли правильно и даже возмутились. Не факт, что это будет иметь долгий эффект: интернеты становятся “корпоративными”, в том числе, на стороне клиента. Нужно ли ожидать рекламных пауз в ядре Linux? Риторический вопрос.

Не самым хорошим образом развивается браузер Firefox, хоть и предсказуемо, к сожалению: теперь этот браузер принялся показывать блокирующую всплывающую рекламу Mozilla VPN на произвольных веб-страницах. Надо сказать, что если сравнивать с подобным внедрением рекламы, то остаётся не так уж и много вариантов поведения браузера, которые хуже. В VPN-сервис, можно предположить, там ещё больше встроено всякой подобной нагрузки. (Дополнение. Предположим ещё, что блокирующая реклама Mozilla VPN не показывалась тем пользователям, которые уже купили Mozilla VPN. Тогда получается простая и известная схема: чтобы убрать рекламу – нужно заплатить, а иначе – будете просматривать рекламный видеоролик перед тем, как страница сайта отобразится. Забавно.)

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

Оказывается, некоторое время назад в Google добавили занятную функцию в приложение для (так называемой) “двухфакторной аутентификации” (2FA), а именно – возможность восстановления “из облака” в случае потери устройства. Заметьте, что весь смысл “двухфакторной аутентификации” состоит в том, что подключающийся пользователь может доказать, что у него есть доступ к дополнительному секрету, кроме пароля, который могли и украсть. Естественно, этот дополнительный секрет может проявляться как “одноразовые пароли” или какие-нибудь PIN-коды, которые, например, генерируются в зависимости от текущего времени (и от значения секрета, конечно).

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

С этим обновлением мы вводим решение проблемы – делая одноразовые коды более надёжными путём безопасного хранения их в Google-аккаунте пользователя.
(With this update we’re rolling out a solution to this problem, making one time codes more durable by storing them safely in users’ Google Account.)

То есть, наличие потенциальной привязки к аппаратному устройству делало 2FA полезным инструментом, однако Google предлагает передать дополнительный пароль на внешние серверы, в результате чего вторым фактором оказывается Google-аккаунт. Теперь, если пользователям некоторой корпоративной системы предложено использовать Google Authenticator в качестве хранилища второго секрета (распространённый случай), то это означает, что доступ к системе завязан уже даже не на неконтролируемое приложение от третьей стороны, а прямо на аккаунт Google.