Основы Интернет - технологий.

СМИ обратили внимание, что в 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, информацией о сотовых вышках и историей аутентификаций.