Методичка Минцифры по выявлению VPN

Вот это, конечно, новость!

Получается айфоны совсем дырявые?

В моём понимании любая возможность приложения уйти от сетевого интерфейса, который ему назначен это огромная уязвимость.

Потому что threat model здесь не ограничивается тем, что РКН выяснит айпи твоего прокси сервера.

Это еще и: 1) сам факт использования ВПН. Мы плавно подходим к идее повсеместных штрафов. И нужно понимать, насколько палевно продолжать пользоваться всем на одном устройстве.

  1. раскрытие твоего реального айпи для иностранных приложений, которым может не понравится твоя текущая страна. И твой аккаунт блокнут! То есть на айфоне, если я правильно понял твоё сообщение, с этим все совсем плохо….

Меня впечатлило сообщение ValdikSS в другой ветке. И я проверил некоторые утверждения.

  1. На Windows, при включенном tun прокси, я смог отправить запрос из командной строки с другого сетевого интерфейса, указав source ip wi-fi адаптера. Но нет проблемы в общем-то настроить firewall.

  2. Касательно андроид. SO_BINDTODEVICE на свежих андроидах действительно проблема, аналогичная ios. На андроиде, как я прочитал, она еще не решена. Но ее закрыли в grapheneos Releases | GrapheneOS

А вот касательно более старых андроидов с ядром ниже 5.7, Network.bindSocket не дает подрубиться к другому сетевому интерфейсу ни в какую сторону. Даже в сплит режиме. То есть, если указано приложению в директ. Оно может только в директ. Если vpn, то только vpn. Я полагаю, что также оно себя поведет и в shelter/knox, и в отдельном юзере. Я проверил это с помощью java code в Tasker. При попытке приложению, посланному в директ, подрубиться к tun0 - operation not permitted. К wlan0 - ок.

Также касательно того, что shelter/knox видят TRANSPORT_VPN, как некоторые писали. Если верить приложению RKN hardening, то не видят. Они видят только существование интерфейса tun0. И на основании его делают вывод. Решается через модули lsposed.