Ваш телефон на вас настучит. Опубликована методика Минцифры по поиску VPN

Telegram-канал Профсоюз работников IT опубликовал документ, который, предположительно, представляет собой распознанную в Markdown версию методики Минцифры по выявлению VPN на устройствах пользователей. По содержанию публикация совпадает с рекомендациями, о которых накануне писал РБК со ссылкой на копию документа и источники на IT-рынке.

Методика предлагает трехэтапную проверку. Сначала компании должны анализировать IP-адрес входящего соединения: сверять геолокацию, ASN, принадлежность адреса к инфраструктуре дата-центров и хостинг-провайдеров, а также сопоставлять данные с репутационными списками VPN, прокси и узлов TOR. В документе указано, что основной GeoIP-базой должна стать система РАНР, а до ее запуска допускается использование MaxMind и IP2Location. Совпадение IP со списками VPN или TOR в методике рассматривается как признак выявленного обхода независимо от геолокации.

Второй этап касается мобильных устройств и разделен на два подэтапа. Сначала предлагается искать прямые признаки VPN и proxy на Android и iOS, затем подключать косвенные признаки, чтобы повысить точность и снизить число ложных срабатываний. Проверку рекомендуют запускать в момент входа, аутентификации или другого ключевого действия, а не постоянно, поскольку непрерывный мониторинг увеличивает расход трафика и заряд батареи.

Для Android методика описывает использование системных API ConnectivityManager и NetworkCapabilities. Среди прямых признаков перечислены системные флаги и параметры вроде IS_VPN, TRANSPORT_VPN и VpnTransportInfo. Для proxy предлагается дополнительно анализировать системные настройки, включая IP, порт и типовые диапазоны портов для SOCKS, HTTP и Tor.

На iOS возможности проверки заметно уже. Документ говорит, что доступ к системным параметрам там существенно ограничен, поэтому выявление прямых признаков VPN сильно затруднено. Для proxy отдельно упоминается системный API CFNetworkCopySystemProxySettings(). В методике также оговаривается, что iCloud Private Relay не следует автоматически относить к запрещенным VPN, хотя сервис может использоваться для обхода блокировок.

Третий этап касается устройств под управлением Windows, macOS, Linux и UNIX. Для таких систем методика описывает анализ сетевых интерфейсов, таблиц маршрутизации, DNS-настроек и MTU. Среди косвенных признаков упоминаются характерные имена интерфейсов вроде tun, tap, wg, utun и ppp, но документ отдельно оговаривает, что такие признаки нельзя использовать как самостоятельное доказательство.

Авторы методики отдельно указывают, что ни один признак сам по себе не должен считаться универсальным основанием для вывода. В документе есть матрица принятия решения: из нее следует, что одного положительного сигнала на стороне устройства недостаточно, если серверная проверка не выявила обход. Среди факторов, которые могут приводить к ошибкам, названы VPN на роутере, виртуальные машины и контейнеры, прокси с адресами обычных провайдеров, split tunneling, CDN и новые VPN-сервисы, которые появляются быстрее, чем обновляются репутационные базы.

Для корпоративных подключений методика предлагает использовать белые списки и учитывать историю использования. Если устройство включает корпоративный VPN в рабочее время и отключает в нерабочее, такой сценарий предлагается не считать подозрительным. Если однозначного вывода сделать нельзя, документ рекомендует повторную проверку или сопоставление результата с дополнительными данными, включая геолокацию устройства, сведения о сотовой сети и историю предыдущих успешных аутентификаций. В конце методика также упоминает дополнительные способы анализа, включая оценку сетевых задержек SNITCH и осторожную проверку HTTP-заголовков X-Forwarded-For, Forwarded и Via.