Группа исследователей из Мичиганского университета опубликовала результаты исследования возможности идентификации (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 отправляет определённый RST-пакет (проверка не работает при использовании режима "tls-auth" так как OpenVPN-сервер при нём игнорирует запросы от клиентов, не аутентифицированных через TLS).
Тестирование предложенных методов в сети интернет-провайдера 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 отправляет определённый RST-пакет (проверка не работает при использовании режима "tls-auth" так как OpenVPN-сервер при нём игнорирует запросы от клиентов, не аутентифицированных через TLS).
OpenVPN Is Open to VPN Fingerprinting | Hacker News
news.ycombinator.com
