Определение сеансов OpenVPN в транзитном трафике

Группа исследователей из Мичиганского университета опубликовала результаты исследования возможности идентификации (VPN Fingerprinting) соединений к серверам на базе OpenVPN при мониторинге транзитного трафика. В итоге было выявлено три способа идентификации протокола OpenVPN среди других сетевых пакетов, которые могут использоваться в системах инспектирования трафика для блокирования виртуальных сетей на базе OpenVPN.

Тестирование предложенных методов в сети интернет-провайдера Merit, насчитывающего более миллиона пользователей, показало возможность идентификации 85% OpenVPN-сеансов при незначительном уровне ложных срабатываний. Для проверки был подготовлен инструментарий, который вначале в пассивном режиме на лету определял трафик OpenVPN, а затем удостоверяется в корректности результата через активную проверку сервера. На созданный исследователями анализатор был отзеркалирован поток трафика, интерсивностью примерно 20 Gbps.


В ходе эксперимента анализатор смог успешно определить 1718 из 2000 тестовых OpenVPN-соединений, установленных подставным клиентом, на котором было использовано 40 различных типовых конфигураций OpenVPN (метод успешно сработал для 39 из 40 конфигураций). Кроме того, за восемь дней проведения эксперимента в транзитном трафике было выявлено
3638 сеансов OpenVPN, из которых было подтверждено 3245 сеанса. Отмечается, что верхняя граница ложных срабатываний в предложенном методе на три порядка ниже, чем в ранее предлагавшихся методах, основанных на применении машинного обучения.

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

Задействованные способы идентификации основываются на привязке к специфичным для OpenVPN шаблонам в незашифрованных заголовках пакетов, размеру ACK-пакетов и ответам сервера. В первом случае, в качестве объекта для идентификации на стадии согласования соединения может использоваться привязка к полю “opcode” в заголовке пакетов, которое принимает фиксированный диапазон значений и определённым образом меняется в зависимости от стадии установки соединения. Идентификация сводится в выявлению определённой последовательности изменения opcode в первых N-пакетах потока.

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


Третий метод является активной проверкой и обусловлен тем, что в ответ на запрос сброса соединения сервер OpenVPN отвечает определённым RESET-пакетом (проверка не работает при использовании режима “tls-auth” так как OpenVPN-сервер при нём игнорирует запросы от клиентов, не аутентифицированных через TLS).


Release. Ссылка here.