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

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

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

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

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



Комментировать »

Немного технологических параллелей. Предположим, что на сервер баз данных, через сеть, отправляются запросы добавления записей. При этом каждый запрос требует завершения транзакции – то есть, обратно клиенту должен прийти пакет, подтверждающий выполнение, после этого клиент может отправить следующий запрос. В условных терминах привычного SQL – это будут команды INSERT. Известно, что в такой схеме производительность, по числу добавлений в секунду, определяется сетевой задержкой. То есть, если пакет находится в пути 10 ms, то сервер должен дожидаться следующего INSERT 20 ms (потому что в обе стороны), а это гарантирует верхний предел в 50 записей в секунду, даже если сервер выполняет одну запись за 1 микросекунду (на несколько десятичных порядков быстрее).

Проблема, конечно, решается поточной записью “списками”, когда новые запросы поступают без ожидания завершения транзакции или какого-либо подтверждения по предыдущим запросам (например, COPY). Сетевая задержка тут уже успевает помешать только один раз, в начале соединения, а дальше – очередной запрос поступает на сервер тут же, следом за предыдущим, что позволяет работать с большей производительностью.

Естественно, эта особенность действует не только для баз данных: ограничивающее влияние сетевых задержек на транзакционные схемы с подтверждением есть в TCP (где с этим явлением борются: см. TCP Fast Open), в TLS (здесь тоже борются: см. TLS Early Data/0-RTT и др.), и в других протоколах. Схема обобщается и на многие решения, которые не имеют отношения к интернет-протоколам.

Рассмотрим такой сценарий: РЛС, предназначенная для определения координат и скорости “быстрых объектов” на “существенном расстоянии”. Тривиальная импульсная РЛС, полагающаяся на отражения отдельных зондирующих импульсов в строгом порядке, оказывается в такой же ситуации, как и сервер баз данных выше (при том, конечно, что РЛС появились раньше таких серверов). Излучили короткий импульс – приняли отражённый сигнал, обработали, отправили очередной импульс – если время до цели 1 ms (300 км, примерно), то получается разрешающая способность наблюдения в 500 Гц, максимум. А если цель дальше, то будет меньше. Хуже всего, что отражённый сигнал вообще может не прийти обратно к точке излучения на нужном уровне. Но если импульсы отправлять чаще, не ждать отражения, или даже использовать непрерывный зондирующий сигнал, то ситуация, в теории, резко улучшается, как и в случае с сервером баз данных: можно обрабатывать отражённый сигнал с разрешением хоть в гигагерц. На практике, впрочем, возникнут проблемы, потому что РЛС – это не сервер баз данных. Принимать сигнал одновременно с излучением – весьма трудно, если не использовать разнесённые в пространстве антенны (бистатическая радиолокация). А увеличение частоты следования зондирующих импульсов требует использования более сложных алгоритмов кодирования и обработки, которые позволяют различать отражённые сигналы, соответствующие различным зондирующим импульсам. Это, впрочем, обычная задача для современных РЛС.



Комментировать »

В браузере Chrome версии 122, вышедшей на днях, включена по умолчанию поддержка постквантовой гибридной криптосистемы TLS X25519Kyber768 (раньше данная возможность включалась вручную, через флаг). Данная криптосистема уже некоторое время поддерживается моим экспериментальным сервером TLS – посмотрим, увеличится ли количество подключений с X25519Kyber768: у этой криптосистемы на сервере повышен приоритет, но подключений пока что очень мало (естественно, там далеко не только браузеры в качестве клиентов).

(Кстати, так как популярный “Яндекс.Браузер” является клоном Chromium/Chrome, а TLS-стек там соответствует версии Chromium, то и в браузер от “Яндекса”, как я понимаю, поддержка постквантовой криптосистемы в TLS тоже приехала автоматически.)



Комментировать »

Кстати, насчёт того, было ли известно о различных векторах DoS-атак, которые с собой приносит DNSSEC (это касательно свежих CVE с коллизиями ключей и подписей). Я, ради интереса, посмотрел, что я писал в книге “Доменные войны II”, вышедшей ещё в 2011 году, и там на странице 269 сказано следующее:

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

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

Естественно, это никоим образом не отменяет актуальности конкретных современных атак на конкретные современные системы.



Комментировать »

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

Evaluating KeySigTrap, we set up a zonefile with 582 colliding DNSSEC keys and 340 signatures.

Это CVE-2023-50387.

(via)



Комментировать »

Свежий занятный пример про утечку данных о пользовательской VPN-сессии через DNS, а также и про то, как именно один и тот же пользователь (клиент) может к DNS и к веб-серверу одного и того же сервиса приходить из совсем разных точек Сети: пишут, что клиентская программа VPN-провайдера ExpressVPN длительное время допускала DNS-запросы к локальному, провайдерскому DNS-резолверу, а не к резолверу внутри VPN. О подобных утечках, связанных с DNS, я писал достаточно много, например, в недавней записке про ECS.



Комментировать »

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

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

С сугубо прикладной точки зрения, DNS с DNSSEC – это глубокая, непонятная технология: пользователь даже не имеет возможности кликнуть по кнопке “Всё равно продолжить”, поскольку, в случае сбоя, до контекста такой кнопки дело не доходит – сломался не сам привычный механизм, а пропало действие древнего, 16-битного, заклинания, вводившего в окружающую действительность законы работы механизма.

Будущее DNSSEC остаётся туманным.



Комментарии (2) »

Добавил в DNS-зону dnssec.pw, которая из недавней записки про совпадающие теги (KeyTag), несколько дополнительных ключей и подписей, чтобы создать минимальное разнообразие криптосистем: была только RSA, добавил ECDSA на P-256, плюс ECDSA KSK (ключ для подписывания ключей) с тегом 12345, как у прочих (кроме SEP-ключа). В общем, ключей теперь много, так что зона разрослась. Зато несколько удобнее тестировать приложения. (Кстати, в зоне сейчас нет A-записей; кроме DNSSEC-записей там только SOA и NS, возможно, другие записи появятся позже.)



Комментировать »

Цитата из моей недавней статьи, опубликованной в журнале “Интернет изнутри”:

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

(Я писал об этом на dxdt.ru тоже, конечно.)



Комментировать »

Интересно, что Google Public DNS (8.8.8.8) при взаимодействии с зоной dnssec.pw, которую я на днях снабдил ключами с одинаковыми тегами, продолжает возвращать неконсистентные результаты, если спрашивать об отсутствующих в зоне записях. Например, при запросе TXT-записей в dnssec.pw теперь нередко приходят ответы со статусом SERVFAIL, “RRSIG with malformed signature…” – написано в пояснении. Однако есть и ответы со статусом NOERROR (примерно, половина, как ни странно), где, впрочем, пояснение тоже указывает на “RRSIG with malformed signature…”.

Возможно, конечно, что в данном сервисе на разных экземплярах узлов разное программное обеспечение, но есть и другое, несколько более занятное, объяснение: может так быть, что сервис ограничивает количество попыток проверки подписи для каждой итерации. В зоне четыре ключа ZSK, подпись RRSIG на NSEC – одна, на SOA – две. Соответственно, если у резолвера установлено некоторое предельное количество ошибок проверки подписи, то, когда предел достигнут, резолвер прекращает попытки перебора ключей и возвращает SERVFAIL. Если же ключ удалось угадать за меньшее количество попыток, то возвращается NOERROR. Подсчёт строк с сообщениями “RRSIG with malformed signature” в ответах – укладывается в эту гипотезу, но чтобы судить точнее – нужно собрать дополнительную статистику.



Комментировать »

Немного занимательной математики и глобальной DNS.

Насколько велика вероятность, что в доменах первого уровня глобальной DNS совпадут теги разных ключей DNSSEC? Нередко приходится слышать, что так как тег 16-битный, то и вероятность, примерно, 1/65535 (за вычетом особенностей алгоритма вычисления значения тега и пр.). Это не верно. Если рассматривать совпадения внутри набора ключей DNS, то получаем хрестоматийный пример парадокса дней рождения: нам не важно, чтобы повторилось конкретное, заданное значение тега, напротив – требуется совпадение любого значения внутри любой пары, а это совсем другая история, поскольку количество всевозможных пар велико даже в небольших наборах ключей. Поэтому вероятность совпадения тегов DNSSEC-ключей, на практике, очень велика. Иногда ключи просто обязательно совпадут по тегам. Например, в списке доменов первого уровня (корневой зоны DNS) сейчас 1452 имени, то есть, можно составить 1053426 пар (больше миллиона). А это количество (практически) гарантирует, что будут совпадения тегов ключей.

И действительно, если собрать DNSKEY-записи из доменов первого уровня, то окажется, что значений повторяющихся тегов, – то есть, значений, которые встречаются для разных ключей в разных зонах, – сильно больше сотни: у меня получилось 129 таких тегов. Обратите, кстати, внимание, что некоторые ключи разных зон TLD имеют одинаковые теги потому, что это просто одинаковые ключи. Такие повторы отбрасывались. Потому что корректно – сравнивать именно сами значения ключей (как и в прочих случаях использования тегов). Например, различные DNSSEC-ключи с одинаковыми тегами опубликованы в зонах cab и today, в зонах agency, weber и temasek, и во многих других.

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



Комментировать »