sign-box позволяет заблокировать маршрутизацию от программ, которые применили SO_BINDTODEVICE на интерфейс прокси. Если программа исключена из использования прокси, она не сможет выполнить запрос через прокси, а сможет только через Wi-Fi/мобильную сеть. А если не исключена, то сможет и через прокси, и через Wi-Fi/мобильную сеть.
Определить само наличие прокси программа сможет в любом случае.
Ядро должно быть 5.7 и новее. Curl не выдаст ошибку, если SO_BINDTODEVICE не сработает, а попробует просто забиндить source ip сокета (и это успешно сработает, но не даст пакету смаршрутизироваться).
У вас, судя по гуглу, ядро 5.4, где такой ошибки ещё нет.
Запустите ваше ПО на денёк и посмотрите, есть ли трафик от UID = -1. Я предполагаю, что сам Android такие пакеты регулярно отправляет (будто бы system), и не знаю, сломается ли что-либо, если их блокировать.
И действительно похоже на баг, даже два (еще позволяет отправлять запросы в обход установленных VPN-приложением маршрутов). Я был уверен, что это by design, но нет — Network.bindSocket даёт отлуп, а SO_BINDTODEVICE обходит даже allowBypass и allowFamily.
@m0xf, @nidalee, поможете корректно описать проблему в Google? Я сделал PoC, обходящий несколькими методами несколько разных конфигураций.
Include/excluderoutes управляет маршрутами для главной таблицы маршрутизации. Если приложение забиндилось на интерфейс, оно их игнорирует (в обе стороны) — только что проверил на примере OpenVPN for Android, который настроил в режим «только локальная сеть» (маршрут только на диапазон выданного адреса). Curl’ом удалось достучаться до ifconfig.co через tun0.
Подумайте о другой стороне проблемы: многие программы, предназначенные для работы в локальной сети, отправляют ответы на запросы из локалки через направильный интерфейс (через VPN), потому что не биндятся на тот интерфейс, с которого получили запрос. Это типичный баг. Я даже просил разработчиков VPN-программ по умолчанию вводить подобные исключения хотя бы для broadcast-трафика (потому что он вообще в L3 VPN маршрутизироваться не должен, а L2 Android не поддерживает): https://github.com/schwabe/ics-openvpn/issues/1847
А Happ пользуются исключительно потому, что во всех этих прокси-протоколах нет понятия сессии, и заблокировать конфиги для конкретного устройства нельзя, пользователи могут делиться ими бесконечно.
В Happ сделали HWID, прямо как в старфорсе :D
На сервер отсылается HWID и сервер не выдаёт ключи больше, если хоть раз они скачивались с одного HWID. Экспортировать их тоже нельзя.
Открою вам страшную тайну (о которой не знает даже Минцифры): и на Android, и на iOS, и на Windows, и на Linux, и на macOS любая программа может выполнить запрос через любой сетевой интерфейс в системе.
Только что проверил на Android:
Устанавливаем VPN-соединение, отправляем запрос напрямую — IP VPN, через wlan0 — IP Wi-Fi
В VPN-клиенте настраиваем исключение для отправляющей программы, делаем запрос — IP Wi-Fi, отправляем через tun0 — IP VPN, т.е. исключение для программы обходится.
Достаточно в Termux запустить curl ifconfig.co --interface tun0, если на телефоне ядро 5.7 или новее (SO_BINDTODEVICE для непривилегированных пользователей появился с этой версии), а если старше — управлять через Network.bindSocket
Binds the specified DatagramSocket to this Network. All data traffic on the socket will be sent on this Network, irrespective of any process-wide network binding set by ConnectivityManager.bindProcessToNetwork. The socket must not be connected.
Per-app VPN это просто намёк программе на то, какой интерфейс (таблицу маршрутизации) использовать по умолчанию. Заблокировать это можно только галочкой “Block connections without VPN”, в этом случае сломается доступ к устройствам в локальной сети (принтеры, телевизоры, умные устройства, и т.п.).
Временно починить можно либо отключением Wi-Fi-устройства через диспетчер устройств, либо с помощью IGMP Join в любую мультикаст-группу, например, с помощью VLC:
А ещё вините Windows 10 21H2 (последняя версия с расширенной поддержкой LTSC). На форумах Microsoft есть следующая информация:
This is most likely a known windows bug regarding multicast routing. Chased this issue for a year until finally Intel and Microsoft teamed up and gave this reply:
The engineering team has investigated this multicast issue with Microsoft. Microsoft is aware there’s an issue with the multicast address managed by the OS. The issue has been introduced together with Windows 10 (WDI arch for WiFi Drivers.) Any scenarios of WLAN reconnected (i.e. Airplane mode, roaming out and back into RF range, or disconnect and reconnect to the same SSID) and then the multicast packets might be affected by this issue. Currently this issue is expected to be fixed for Windows 10 Version 21H1.
Basically will multicast stop to work if your wifi has any issues. Can only be resolved by disabling/enabling the interface, reboot machine (or toggle the ipv6 setting).
Однако у меня проявляется то же самое и на полностью обновлённой 21H2 (но не на 22H2, обычные сборки которой уже не поддерживаются).
Telega, вроде бы, единственный сторонний клиент, от которого доходят СМС при входе. В других сторонних клиентах сервер telegram делает вид, что выслал СМС, но они не доходят.
Но я telegram не пользуюсь и в нём не разбираюсь, не кастуйте меня.
Чем это отличается от существующего запрета 2019 года? Он не действует? https://habr.com/ru/news/459720/
Или под то, что в этой новости, попадают также SDR и прочее оборудование, напрямую не нацеленное на работу со спутниками?
Его, вроде бы, и так не могли ввозить не-операторы указом ГРЧЦ от 30 ноября 2018.
sign-box позволяет заблокировать маршрутизацию от программ, которые применили SO_BINDTODEVICE на интерфейс прокси. Если программа исключена из использования прокси, она не сможет выполнить запрос через прокси, а сможет только через Wi-Fi/мобильную сеть. А если не исключена, то сможет и через прокси, и через Wi-Fi/мобильную сеть.
Определить само наличие прокси программа сможет в любом случае.
Ядро должно быть 5.7 и новее. Curl не выдаст ошибку, если SO_BINDTODEVICE не сработает, а попробует просто забиндить source ip сокета (и это успешно сработает, но не даст пакету смаршрутизироваться).
У вас, судя по гуглу, ядро 5.4, где такой ошибки ещё нет.
https://sing-box.sagernet.org/configuration/inbound/tun/#strict_route
Это блокируется selinux’ом для обычных программ на современных android. Через adb можно.
Запустите ваше ПО на денёк и посмотрите, есть ли трафик от UID = -1. Я предполагаю, что сам Android такие пакеты регулярно отправляет (будто бы system), и не знаю, сломается ли что-либо, если их блокировать.
P.S. в гугл репорт отправил.
Судя по репорту, раньше SO_BINDTODEVICE обходил даже системную опцию “Block connections without VPN”, и закрыли именно это.
У меня и так последний Graphene. Я только что поставил Pixel OS, чтобы перепроверить на стоке (тоже работает).
Я не могу вам отвечать в ЛС, у вас закрыто.
Hidden text
я сообщу через vulnerability program, не сообщайте гуглу публично, пожалуйста
И действительно похоже на баг, даже два (еще позволяет отправлять запросы в обход установленных VPN-приложением маршрутов). Я был уверен, что это by design, но нет — Network.bindSocket даёт отлуп, а SO_BINDTODEVICE обходит даже allowBypass и allowFamily.
@m0xf, @nidalee, поможете корректно описать проблему в Google? Я сделал PoC, обходящий несколькими методами несколько разных конфигураций.
Include/excluderoutes управляет маршрутами для главной таблицы маршрутизации. Если приложение забиндилось на интерфейс, оно их игнорирует (в обе стороны) — только что проверил на примере OpenVPN for Android, который настроил в режим «только локальная сеть» (маршрут только на диапазон выданного адреса). Curl’ом удалось достучаться до ifconfig.co через tun0.
Подумайте о другой стороне проблемы: многие программы, предназначенные для работы в локальной сети, отправляют ответы на запросы из локалки через направильный интерфейс (через VPN), потому что не биндятся на тот интерфейс, с которого получили запрос. Это типичный баг. Я даже просил разработчиков VPN-программ по умолчанию вводить подобные исключения хотя бы для broadcast-трафика (потому что он вообще в L3 VPN маршрутизироваться не должен, а L2 Android не поддерживает): https://github.com/schwabe/ics-openvpn/issues/1847
А Happ пользуются исключительно потому, что во всех этих прокси-протоколах нет понятия сессии, и заблокировать конфиги для конкретного устройства нельзя, пользователи могут делиться ими бесконечно.
В Happ сделали HWID, прямо как в старфорсе :D
На сервер отсылается HWID и сервер не выдаёт ключи больше, если хоть раз они скачивались с одного HWID. Экспортировать их тоже нельзя.
Пользователям он не нужен, он нужен сервисам.
Открою вам страшную тайну (о которой не знает даже Минцифры): и на Android, и на iOS, и на Windows, и на Linux, и на macOS любая программа может выполнить запрос через любой сетевой интерфейс в системе.
Только что проверил на Android:
Устанавливаем VPN-соединение, отправляем запрос напрямую — IP VPN, через wlan0 — IP Wi-Fi
В VPN-клиенте настраиваем исключение для отправляющей программы, делаем запрос — IP Wi-Fi, отправляем через tun0 — IP VPN, т.е. исключение для программы обходится.
Достаточно в Termux запустить
curl ifconfig.co --interface tun0, если на телефоне ядро 5.7 или новее (SO_BINDTODEVICE для непривилегированных пользователей появился с этой версии), а если старше — управлять через Network.bindSocketPer-app VPN это просто намёк программе на то, какой интерфейс (таблицу маршрутизации) использовать по умолчанию. Заблокировать это можно только галочкой “Block connections without VPN”, в этом случае сломается доступ к устройствам в локальной сети (принтеры, телевизоры, умные устройства, и т.п.).
Ну это я так её обозвал, это просто адрес в памяти.
Про Digma A172 клоны Nokia с маркетплейсов https://notes.valdikss.org.ru/trojan-digma/
Временно починить можно либо отключением Wi-Fi-устройства через диспетчер устройств, либо с помощью IGMP Join в любую мультикаст-группу, например, с помощью VLC:
А ещё вините Windows 10 21H2 (последняя версия с расширенной поддержкой LTSC). На форумах Microsoft есть следующая информация:
Однако у меня проявляется то же самое и на полностью обновлённой 21H2 (но не на 22H2, обычные сборки которой уже не поддерживаются).
Telega, вроде бы, единственный сторонний клиент, от которого доходят СМС при входе. В других сторонних клиентах сервер telegram делает вид, что выслал СМС, но они не доходят.
Но я telegram не пользуюсь и в нём не разбираюсь, не кастуйте меня.