СМИ обратили внимание, что в Telegram-канале «Профсоюз работников IT» был опубликован документ под названием «Методика выявления признаков использования средств обхода блокировок на клиентских устройствах». Судя по содержанию, это та самая «методичка», о рассылке которой недавно сообщал РБК.
Напомним, что Минцифры якобы разослало «методичку» крупнейшим российским интернет-компаниям после серии совещаний, на которых присутствовали представители более 20 крупных российских компаний («Сбер», «Яндекс», VK, Wildberries, Ozon, «Авито», X5 и другие). На этих встречах глава ведомства Максут Шадаев поручил компаниям к 15 апреля ограничить доступ к сервисам для пользователей с включенным VPN.
Подчеркнем, что подлинность этого документа официально не подтверждена, но содержимое совпадает с тем, что ранее описывали источники РБК.
Описанная в документе методика предлагает трехэтапную схему обнаружения VPN и прокси. Первый этап — серверный, самый простой и универсальный: компания смотрит на внешний IP-адрес клиентской сессии, сверяется с GeoIP-базой, определяет ASN и признак hosting, а затем сверяет с репутационными списками VPN-сервисов, открытых прокси и выходных узлов Tor.
В качестве основной базы авторы документа указывают систему РАНР (Реестр адресно-номерных ресурсов), а до ее запуска разрешают использовать MaxMind и IP2Location. Если адрес ранее фигурировал в списках VPN-сервисов или был связан с Tor, это считается признаком обхода независимо от географии устройства.
В качестве вспомогательных источников геолокации предлагается использовать идентификаторы базовых станций (PLMN), BSSID точек Wi-Fi и GPS (при согласии пользователя).
Второй этап — проверки, которые проводятся непосредственно на мобильных устройствах под управлением Android и iOS. По оценке авторов документа, именно на эти платформы приходится около 80% приложений, через которые можно проводить такое детектирование.
Для Android методика описывает работу через системные API ConnectivityManager и NetworkCapabilities без всякого root: приложение извлекает флаги IS_VPN, TRANSPORT_VPN, VpnTransportInfo и изучает транспорт активной сети. На Android 12+ предлагается еще и применять dumpsys vpn_management, который выдает список активных VPN с именами пакетов. В примере в самом документе фигурирует io.github.romanvht.byedpi, то есть ByeDPI.
Для выявления прокси рекомендуется анализировать системные настройки и сопоставлять порты с типовыми диапазонами: SOCKS (1080, 9000, 5555, 16000–16100), HTTP (80, 443, 3128, 8080, 8888 и другие), прозрачные прокси и Tor (9050, 9051, 9150).
В случае iOS все гораздо скромнее. Из-за изоляции приложений и политики конфиденциальности Apple сторонние приложения не могут читать параметры других, поэтому прямые признаки обхода блокировок доступны фактически только в том случае, если приложение само создает VPN-конфигурацию.
Для анализа прокси методика предлагает использовать CFNetworkCopySystemProxySettings(), проверять ключ __SCOPED__ на наличие интерфейсов utun, tap, ppp, ipsec, подключать NWPathMonitor для отслеживания изменений сети, а в отдельных случаях — NEVPNManager (но только при наличии соответствующих entitlements).
Отдельно авторы оговариваются насчет использования iCloud Private Relay: его нельзя автоматически считать запрещенным VPN, хотя он и позволяет обходить блокировки. Для него требуется отдельная логика.
Запускать все эти проверки методика советует в ключевые моменты (при входе, аутентификации или целевом действии), но не использовать постоянно, чтобы не разряжать батарею устройства и не расходовать трафик.
Третий этап — десктопы под управлением Windows, macOS, Linux и UNIX. Здесь предлагается анализировать сетевые интерфейсы, таблицы маршрутизации, настройки DNS и значения MTU (на туннельных интерфейсах оно часто нестандартное, вроде 1350 или 1400).
Кроме того, в качестве косвенных признаков обхода блокировок упоминаются характерные имена интерфейсов — tun, tap, wg, utun, ppp. Для Windows также отдельно описаны вызовы RasEnumConnection, GetAdaptersAddresses, проверка IfType = IF_TYPE_PROP_VIRTUAL и анализ реестра. Для macOS — getifaddrs(), Transparent Proxy API и Network Extensions. Однако и здесь авторы методики подчеркивают: сами по себе эти признаки недостаточны.
В финальных разделах упоминаются и более экзотические подходы. Например, метод SNITCH (Server-side Non-intrusive Identification of Tunnelled Characteristics), который измеряет RTT между сервером и клиентом и ищет аномально высокие задержки для заявленной геолокации IP: прохождение трафика через VPN неизбежно создаст лишние миллисекунды.
Также упоминается анализ HTTP-заголовков X-Forwarded-For, Forwarded и Via, которые могут выдать прохождение трафика через прокси (правда, с оговоркой, что такие заголовки легитимно формируют и сами CDN).
Отдельная глава в документе посвящена ложным срабатываниям. В частности, системы может легко ввести в заблуждение корпоративный VPN, антивирус с собственным сетевым фильтром, Docker, WSL2, Hyper-V, VirtualBox и другие среды виртуализации, NAT, а также CDN, искажающие геолокацию без всякого обхода блокировок.
Также отмечается, что обнаружение использования VPN и других средств обхода затруднено, если:
- VPN поднят на роутере (следов на самом устройстве нет);
- используются резидентные прокси с IP-адресами обычных домашних провайдеров;
- используется режим split tunneling, или речь идет о новых VPN-сервисах, которые появляются быстрее, чем успевают обновляться репутационные базы.
В итоге в документе предложена матрица принятия решений: одного положительного сигнала мало, и вердикт «обход выявлен» выносится только при совпадении результатов ряда проверок.
Для корпоративных решений будет предусмотрен «белый список», а в спорных случаях предлагается комбинировать результаты с данными GPS, информацией о сотовых вышках и историей аутентификаций.
