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

IDN – это “многоязычные доменные имена” (Internationalized Domain Names), подразумевающие преобразование кодировок на стороне клиента: Unicode кодируется при помощи Punycode, поскольку в DNS, пока что, Unicode не используется (полезная технология, вообще говоря, полезна лишь там, где действительно нужна и может быть внедрена, но это история для другой записки). Весьма неудобный дополнительный слой, который образуется из-за обработки IDN, постоянно приводит к проблемам. Самая “заковыристая”, а поэтому постоянно вылезающая тут и там, проблема – нормализация unicode-записи. Собственно, не так давно мне пришлось исправлять эту проблему в одном из сервисов, работающих с доменными именами. Но если сейчас посмотреть и потестировать те или иные профильные веб-интерфейсы, преобразующие IDN, то, думаю, данная экзотическая проблема проявится у многих (это особенно близко регистраторам доменных имён). Кстати, если этот текст читают разработчики подобных инструментов, то потестируйте имеющиеся реализации. Строки для тестирования я привожу ниже, вместе с описанием логики проблемы (впрочем, она уже упоминалась в прошлогодней записке про шумерские цифры, которую вряд ли много кто прочитал).

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

Посмотрите на две строки: “биткойн.рф” (1) и “биткойн.рф” (2) – они должны выглядеть одинаково. Эта одинаковость обманчива, потому что в первом случае “й” записано как U+0438 + U+0306 – буква “и” + “знак бреве”, два значения; а во втором случае – это просто буква “й” (U+0439, одно значение), где, так сказать, всё включено.

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

Возвращаемся к IDN. Эта технология требует преобразования кодов Unicode к DNS-записи, алфавит которой допускает (без учёта регистра) для подстрок имён хостов символы [a-z] (от “a” до “z”), [0-9] и “минус” “-” (точки тут не считаем). Для кодирования этими ASCII-символами байтовых значений Unicode используется алгоритм, называемый Punycode. Принцип тут аналогичен тому, как работает, например, Base32 (или “кодирование в рунах”), детали отличаются, но нам это здесь не так важно. Важно, что Punycode ничего не знает про особенности Unicode и просто отображает в подмножество ASCII значения unicode-байтов (и обратно), то есть, разные кодовые записи одной буквы отобразятся в разные punycode-последовательности. Что не так трудно продемонстрировать на нашем примере: “биткойн” == “qsa11dvaajue4a”, а “биткойн” == “90aoddqe0a” (выглядит занятно, да).

Однако с точки зрения DNS “qsa11dvaajue4a” и “90aoddqe0a” – разные значения, поэтому имена, их содержащие, тоже будут разными. Разный способ записи одного и того же графического представления для целей DNS не подходит – в реестрах имён, на серверах имён, первоочередное значение имеет ASCII-представление. Поэтому и используется процесс, называемый нормализацией, который описывает соглашение о том, как разные “чёрточки” так приклеить к буквам, чтобы привести всё к одной последовательности кодов, а уже её использовать, например, в DNS. Естественно, unicode-нормализация важна не только в DNS, но подробное описание принципов остаётся за рамками этой записки – его можно найти в соответствующем документе. Отмечу, что современные библиотеки для работы с IDN, обычно, позволяют прозрачно использовать нормализацию, нужно только не забыть её правильно включить при вызове функций преобразования. И, вообще говоря, алгоритмов нормализации – несколько, что делает ситуацию интереснее. А полагать, что столкнуться с подобным на практике невозможно, будет ошибкой – копирование символов иностранных письменностей в составе имён, которые не удалось ввести с клавиатуры, вполне себе встречается.

SPF (Sender Policy Framework) в Интернете позволяет администратору домена через DNS определить перечень адресов узлов, которые могут доставлять email-сообщения с адресами в данном домене. SPF публикуется в TXT-записях. Распространено мнение, что SPF – чрезвычайно простой инструмент, “всего лишь список IP-адресов”, который легко проверить, не получив фактического письма от почтового сервера. Конечно, если рассматривать практику массового применения SPF, то, действительно, так как большинство администраторов используют SPF в самом простом варианте записи, может показаться, что никаких дополнительных уровней логики там и нет. Это, однако, не так: спецификация достаточно сложная, определяет “макросы”, а поэтому позволяет реализовать весьма экзотические настройки. Один из примеров такой экзотики – использование механизма аутентификации exists.

Тип exists позволяет встроить в SPF произвольные имена DNS, которые генерируются на стороне проверяющего узла на основе данных конкретного подключения. То есть, эффект от работы таких фильтров нельзя предсказать простым опросом DNS – нужна ещё и SMTP-сессия.

Например, запись exists:%{ir}._relays.example.net обозначает, что нужно IP-адрес (i) отправляющего узла (как он виден на стороне принимающего) использовать в запросе A-записи в зоне _relays.example.net, и при этом запись IP-адреса нужно перевернуть по октетам (r). То есть, если почтовое сообщение пытается доставить узел с адресом 10.11.12.13, то сконструированное имя для запроса в DNS будет таким: 13.12.11.10._relays.example.net. Если IP-адрес не известен, то и обработать такой фильтр нельзя. Помимо i в спецификации определены и другие макроподстановки, например, домен отправителя, имя из EHLO/HELO и т.д. Впрочем, exists встречается даже реже, чем другой экзотический вариант – exp.

Если вы управляете авторитативным сервером глобальной DNS, то в логах можете увидеть “странные” запросы с именами, составленными из букв в разном регистре (см. скриншот).

DNS-серверы должны игнорировать регистр символов имени из состава запроса. Записи dXdT.RU. и dxdt.ru. – должны считаться совпадающими. Есть, впрочем, свои особенности: DNS-ответ включает в себя и имя из запроса, а одно из толкований требования об “игнорировании регистра” состоит в том, что если регистр игнорируется, то его можно игнорировать и в ответе. То есть, с одной стороны, ответ должен содержать имя в точно таком же формате, в каком оно поступило в запросе (обычно, так и происходит), с другой стороны, если считается, что при сравнении регистр не имеет значения, то имена dXdT.RU. и dxdt.ru. – равны, а поэтому можно в ответ смело писать dxdt.ru. (или DxDt.ru., например).

Тем не менее, регистр символов довольно давно предложено использовать в качестве носителя дополнительной информации – для рандомизации состава запроса. Это создаёт ещё один инструмент для защиты от атак на DNS, которые используют поддельные ответы, опережающие соответствующий запрос по времени. Подобная атака состоит, например, в том, что в адрес рекурсивного резолвера отправляется большое количество пакетов, имитирующих ответ на DNS-запрос от авторитативного сервера, но содержащих подменные данные, например, IP-адрес сервера злоумышленника в A-записи. (DNS использует UDP, поэтому такая подмена возможна на уровне транспорта.) Если рекурсивный резолвер не сможет отличить подменный пакет от настоящего, – который, хотя бы, соответствует запросу, – то в локальный DNS-кэш попадёт подставное значение, оно и будет передаваться узлам, использующим данный резолвер (это называется “отравление кеша”). Естественно, для того, чтобы атака сработала, резолвер должен ожидать ответ об атакуемой зоне, но это не так трудно организовать: есть очень популярные зоны, запросы об именах в которых регулярно возникают; кроме того, нужный запрос может быть отправлен в резолвер самим злоумышленником. Последний вариант хорошо подходит для популярных открытых сервисов DNS, таких, как Google Public DNS, где, как раз, рандомизация регистра букв широко используется (собственно, запросы со скриншота – пришли из этого сервиса).

Как рандомизация регистра символов помогает защитить DNS-ответы? Довольно очевидным способом: резолвер отправляет запрос, в котором символы имени указаны в разном регистре, тем самым кодируя некоторое битовое значение (понятно, что строчная буква может кодировать единицу, а заглавная – ноль); закодированное значение резолвер запоминает и проверяет совпадение регистра в полученном ответе. Тогда, если ответ сгенерировал кто-то, кто реально видел запрос, то этот кто-то сможет подставить правильный код в регистр символов. Схема не защищает от отправки ответа раньше настоящего авторитативного сервера (или вместо этого сервера), но от отправки ответа раньше запроса – защищает. Рандомизация параметров DNS-запроса, снижающая предсказуемость параметров ответа, реализуется в DNS и другими способами. Прежде всего, это номер порта источника (номер порта – 16-битное значение), кроме того, в запросе есть поле Transaction ID (ещё 16 бит). Регистр букв имени может добавить заметное количество значимых битов. Если, конечно, технология поддерживается на стороне авторитативных серверов. И если кто-то не решил “посигналить” строчными/заглавными в обратную сторону. В общем, много “если”. (Напомню, что полноценную защиту от подмены ответов предоставляет DNSSEC.)

Предположим, мы хотим идентифицировать устройство и, возможно, даже пользователя Интернета по некоторым сигнатурам, связанным с использованием различных приложений. Самая простая “сигнатура” подключения – это IP-адрес. Но тут даже слово “сигнатура” используется в кавычках, так как IP-адрес, сам по себе, это всего лишь самый очевидный и банальный “номер узла”: в современном Интернете далеко не всегда IP-адрес даже примерно соответствует реальному подключению. Трансляция адресов (NAT) используется и провайдерами доступа, и за “клиентским подключением”, и в составе VPN, и так далее. IP-адрес принадлежит к наиболее важным идентификаторам в IP-сетях, но точность конкретного адреса для нашей задачи, – то есть, как “сигнатуры”, рассматриваемой в направлении пользовательского, клиентского подключения, – не велика. Более того, задачу даже принято формулировать в других терминах: как определить, что с новым IP-адресом подключается то же самое устройство? (Вынесем тут за скобки пользователя.)

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

На уровне IP есть источники сигнатур, сходные по происхождению с только что описанными. Это те же сдвиги времени доставки (в том числе, можно подсчитывать скорость изменения задержек – брать производную), а кроме того, можно предположить, что и в заголовках пакетов присутствуют сочетания значений (ID, опции и пр.), которые связаны с конкретным источником пакета, но, опять же, всё, что есть в заголовке, размывается в ходе передачи пакетов промежуточными узлами (и это даже без учёта NAT-ов).

TCP предоставляет некоторое количество новых сигналов: что-то можно специально добавить, да ещё и на разных этапах установления соединения (см. SYN-куки и т.д.), при этом сам процесс установления сессии позволяет выделить дополнительные особенности – сдвиги по меткам времени, характеристики из заголовков, взятые по разным сигналам. Отдельный новый базис TCP – это номера портов, а точнее, их изменение: тут экзотические методы использования, – вроде port knocking, – вообще могут позволить узнать конкретный источник сессии без всякой привязки к IP-адресу или к параметрам протоколов более высоких уровней.

И всё же, перечисленные варианты не так уж информативны, особенно, если речь только о пассивном анализе трафика. Дополнительную информацию приносят данные из более высоких уровней. Клиентские TLS-сертификаты, сертификаты электронной подписи, криптографические ключи, передаваемые в рамках разных протоколов уровня приложений – могут достаточно точно указывать на пользователя (и могут идентифицировать устройство). DNS не так трудно снабдить индивидуальными метками: а неконтролируемые и прямые запросы в DNS делают даже те приложения, которые позиционируются как “защищённые”. Эти источники сигнатур вообще не зависят от транспортных протоколов, то есть переходят от канала к каналу без изменений. Главное – их увидеть. А про куки-файлы, HTTP-запросы, конечно, можно и не напоминать.

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

Дополнение: речь в примере, естественно, идёт об исследовании узлов не по адресам, а относительно некоторого набора признаков, определяющих поддержку протокола, например, относительно набора ключей, известных серверу.

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