В сети появилась методичка для выявления сетевых средств обхода

3. Общее описание методики и последовательности ее внедрения

Существуют три основных области, анализ которых даёт возможность производить детектирование использования VPN на клиентском устройстве:

• Анализ клиентских сессий на сервере (GeoIP);

• Аналитика сетевых подключений и интерфейсов на клиентском устройстве;

• Анализ системных настроек и таблиц маршрутизации на клиентском устройстве.

Анализ клиентских сессий на сервере состоит в сравнении IP-адреса подключения с репутационной БД. К преимуществам метода относятся:

• Универсальность. Функция применять аналитика нев зависимости от операционной системы (ОС) клиентского устройства;

• Прозрачность для клиента. Тест производится на стороне сервера и не требует изменения клиентского приложения.

• Скорость. Быстрое добавление в сравнении с другими методами.

• Простота. Относительная простота проверок.

Принимая во внимание перечисленные преимущества, добавление анализа клиентских сессий на сервере следует производить в качестве первого этапа по внедрению методов выявления VPN на клиентских устройствах.

Внедрение проверок на клиентских устройствах следует разбить на два подэтапа. На первом подэтапе следует внедрять прямые проверки, указывающие на использование VPN и Proxy. Второй подэтап нацелен на повышение точности выявления VPN и Proxy и снижения уровня ложных срабатываний за счет внедрения косвенных признаков использования VPN и Proxy. Детальные описания методов анализа на клиентских устройствах рассматриваются в разделах 6 и 7.

Таблица 1. Этапность внедрения методики выявления средств обхода блокировок на клиентских устройствах

5. Этап 1: GeoIP

5.1. Цели этапа

Целью проверки является определение геолокации устройства, полученного путем сравнения IP адреса точки входа трафика с данными из специализированных референсных баз данных (GeoIP).

5.2. Область применения

Анализ клиентских сессий проводится на серверной стороне.

Анализ покрывает все устройства, а равным образом подключения клиентов через web.

5.3. Источники данных GeoIP

В качестве референсной БД должна выступать платформа «Реестр адресно-номерных ресурсов сети Интернет» (РАНР).

До момента ее ввода в эксплуатацию допускается использование альтернативных БД. Наиболее широко распространённые из них MaxMind и IP2Location.

Для повышения точности анализа допускается подключение дополнительных коммерческих или внутренних источников данных.

5.4. Сценарии выявления средств обхода блокировок

Признаки, используемые при анализе GeoIP:

• определение страны и региона по IP-адресу;

• выявление аномалий: частая смена стран, резкие изменения локаций между сессиями;

• определение ASN и организации-владельца IP. Сравнение с диапазонами, выделенными дата-центрам и хостинг-провайдерам;

• проверка в репутационных списках: VPN/Proxy-адреса, TOR exit nodes, публичные Proxy;

• проверка диапазонов в «белых списках» корпоративных сетей и CDN для снижения ложных срабатываний.

Алгоритм применения методики:

1. Определить внешний IP клиентской сессии на стороне сервера.

2. Определить GeoIP по этому IP-адресу.

3. Определить ASN, тип сети и наличие признака hosting.

4. Проверить адрес по репутационным спискам VPN, proxy и TOR.

5. Сопоставить полученные данные с историей прошлых сессий, типичными странами, регионами и доверенными диапазонами.

6. При наличии результатов анализа на клиентской стороне сравнить результаты с GeoIP.

7. Принять решение об использовании средств обхода блокировок на основании результатов шагов 1–6:

   • По результатам серверной и клиентской проверки устройство находится в РФ, нет признаков hosting и репутационного риска. Решение: VPN не выявлен.

   • Серверная тест — девайс зарубежом; клиентская проверка — девайс в РФ. Решение: Выявлен VPN.

   • По результатам серверной и клиентской проверки устройство находится зарубежом. Решение: Требуется дополнительная тест.

   • По результатам серверной проверки IP имеет признак hosting или входит в списки подсетей спискам VPN, proxy и TOR. Подход: Выявлен VPN нев зависимости от совпадения страны.

6. Этап 2а: Мобильные устройства

6.1. Цели этапа

Целью проверки является аналитика прямых признаков использования средств обхода блокировок на мобильных устройствах под управление Android и iOS.

6.2. Область применения

Аналитика клиентских сессий проводится на клиентском устройстве.

Анализ производится на мобильных устройствах Android и iOS.

6.3. Общие принципы анализа прямых признаков на клиентских устройствах

Прямыми признаками использования средств использования блокировок являются системные признаки VPN и Proxy в Android и iOS. Сбор признаков осуществляется приложением на клиентском устройстве через системные api в рамках стандартных пользовательских привилегий.

Проверка должна выполняться в момент запуска приложения или аутентификации или при выполнении ключевого действия в приложении (подтверждение покупки/перевода, указание конечной точки маршрута и т.п.). Что является ключевым действием в приложении определяет его разработчик.

Проведение непрерывного контроля или отправка пустых результатов анализа запрещена, поскольку это негативно будет влиять на расход трафика и потребление заряда батареи клиентского устройства.

Проведение анализа на клиентских устройствах не зависит от анализа на серверной стороне и является самостоятельной проверкой, тем не менее основная проблема анализа состоит в подтверждении и/или уточнении данных, полученных в процессе GeoIP анализа.

6.4. Android

Для Android используются системные программный интерфейс ConnectivityManager и NetworkCapabilities. Предлагаемые подходы не требуют root-доступа и должны работать со стандартными привилегиями приложения.

Прямыми признаками использования VPN являются:

• флаг IS_VPN в Score(Policies);

• наличие транспорта VPN в Transports;

• наличие VpnTransportInfo;

• наличие свойства TRANSPORT_VPN у activeNetwork при проверке hasTransport.

Примеры диагностических значений:

Score(Policies: ):
EVER_EVALUATED&IS_UNMETERED&IS_VPN&EVER_VALIDATED&IS_VALIDATED
Transports: WIFI|VPN
VpnTransportInfo{type=1, sessionId=PCAPdroid VPN, bypassable=false
longLiveTcpConnectionsExpensive=false}

Для выявления Proxy следует проводить анализ System.getProperty и иных доступных системных настроек. При выявлении в системных настройках данных об IP и порте Proxy вероятно весь посещаемость направляется через него.

Список характерных Proxy-портов для разных технологий:

• SOCKS: 1080, 9000, 5555, 16000-16100;

• http: 80, 443, 3128, 3127, 8000, 8080, 8081, 8888;

• прозрачные Proxy: 80, 443, 4080, 7000/7044, 8082, 12345;

• Tor: 9050, 9051, 9150.

6.5. iOS

На iOS доступ к системным данным существенно ограничен. Следовательно использование прямых признаков на iOS сильно затруднено. Анализ прямых признаков возможен только в том случае, если само программа создает конфигурации, которые могут быть расценены, как средства обхода блокировок.

Для выявления использования системного Proxy следует применять системный api CFNetworkCopySystemProxySettings() для получения настроек текущего подключения.

Наличие IP и порта указывает на наличие Proxy и направление всего трафика устройства через него.

6.6. Ограничения Мобильных устройств

• Резидентные прокси и сценарии, где внешний IP выглядит как обычный адрес провайдера.

• Системы приватности и фильтрации, если они не маркируются как VPN средствами ОС.

7.6. Маршрутизация

Ниже приведены аномалии в таблицах маршрутизации устройств, косвенно указывающие на использование VPN:

• Маршрут по умолчанию, указывающий на интерфейс, отличный от основного физического или беспроводного.

• Наличие выделенных маршрутов, направляющих посещаемость на нестандартные шлюзы.

• Отсутствие прямого маршрута до шлюза интернет-провайдера при активном соединении.

• Использование нестандартных значений MTU.

• Наличие маршрутов, указывающих на использование split tunneling, когда часть трафика идет через туннель, а часть напрямую.

Приведенные признаки могут дополнить проверки на серверной стороне или при анализе прямых признаков на клиентском устройстве. Выявление только этих признаков не является основанием для вынесения решения выявлен VPN.

Причины, ограничивающие применение анализа маршрутизации при выявлении VPN:

• Частные диапазоны 10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16 встречаются повсеместно в офисных, домашних и контейнерных средах.

• Метрики маршрутов меняются автоматически в зависимости от среды и не являются уникальным признаком VPN.

• Множественные интерфейсы и виртуальные маршруты создаются WSL2, Hyper-V, VirtualBox, антивирусами, средствами родительского контроля и иными легитимными компонентами.

Ниже приведены аномалии в таблицах маршрутизации устройств, косвенно указывающие на использование Proxy:

• Маршрут по умолчанию настроен на передачу трафика в виртуальный сетевой интерфейс;

• Наличие в таблице маршрутизации выделенных маршрутов.

• Большое количество установленных соединений на локальный порт;

• Использование клиентами случайных портов;

• Отсутствие прямых внешних соединений.

Аналитика таблиц маршрутизации не применим для iOS, поскольку доступ приложений к информации о других приложениях и системных настройках ограничен.

7.7. DNS

Анализ настроек DNS также относится к косвенным признакам. Явное модификация DNS-сервера на публичный адрес либо DNS внутри VPN-сети может быть уточняющим признаком, но сам по себе недостаточен.

Причины, ограничивающие применение анализа настройки DNS при выявлении VPN:

• DNS может быть изменен и без VPN, в частности приложениями фильтрации или блокировки рекламы.

• Потребитель может вручную задать DNS, например публичный или корпоративный.

• Некоторые VPN не меняют DNS и оставляют DNS родительской сети.

• Локальные DNS-адреса и направление DNS в цифровой интерфейс полезны только в комбинации с иными признаками.

Ниже приведены аномалии в настройках DNS, косвенно указывающие на использование Proxy:

• DNS-серверам назначаются локальные адреса;

• Все DNS-запросы направляются в виртуальный веб интерфейс.

7.8. Дополнительные технические методы выявления Proxy

• Тест специализированных утилит, например proxychains или tsocks.

• Выявление системных процессов proxy-серверов по именам процессов и характерным портам.

• Анализ правил межсетевого экрана, iptables или pf, на наличие перенаправлений на локальный proxy.

• Мониторинг активных соединений к нестандартным или удаленным портам.

• Проверка локальных сертификатов и признаков Man in the Middle proxy.

• В режиме split tunneling часть приложений может функционировать напрямую, поэтому проверка по одной активной сети недостаточна.

• Proxy-in-app, кастомные туннели и пользовательские реализации обхода, не отражающиеся в системных api.

8.5. UNIX и Linux

Особенности выявления использования средств обхода в UNIX/Linux:

• Характерные имена интерфейсов: tun, tap, wg, utun, ppp.

• Используются только активные интерфейсы со статусом UP и назначенным IP-адресом.

• Для туннельных интерфейсов VPN MTU часто меньше стандартных значений, например 1350 или 1400.

• Наличие нескольких маршрутов по умолчанию, маршрутов через виртуальные интерфейсы, нетипичных подсетей и измененных DNS может использоваться как дополнительная анализ.

• Аналитика /etc/resolv.conf и иных конфигураций DNS полезен только как поддерживающий фактор.

• Сравнение локальных и публичных IP-адресов, а равным образом принадлежность адреса ЦОД, равным образом относятся к дополнительным признакам.

8.6. Windows

Особенности выявления использования средств обхода в Windows:

• Для выявления активных удаленных подключений может использоваться RasEnumConnection.

• Для анализа сетевых адаптеров допускается применять GetAdaptersAddresses или GetAdaptersInfo.

• Признаками могут выступать цифровой тип адаптера, IfType = IF_TYPE_PROP_VIRTUAL, характерные названия VPN, TAP, Wintun, WireGuard, OpenVPN и состояние UP.

• В качестве расширенного метода можно анализировать реестр на предмет выявления VPN и proxy-настроек.

• Проверка шлюза по умолчанию, DNS, расхождения публичного и локального IP, а равным образом метрик интерфейсов относится к дополнительным факторам точности.

Для всех desktop и UNIX-платформ сохраняется общее правило: интерфейсы, маршруты, MTU, частные подсети и DNS сами по себе не являются достаточным основанием для жесткого решения без серверного риска или иных сильных подтверждений.