Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Информационная безопасность доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 395
Так вот оно что! То-то я с утра сижу и бьюсь уже целый час — через Hiddify и все тайм-аут. Короче, понятно. И ведь надо же! Скажем так: не зря им там зарплату платят...
Happ работает нормально сейчас. Отвалился на днях hiddify на винде и самсунге у семьи, пришлось перевозить. У happ конечно открытого исходного кода нет, но в целом на нем сижу уже с год, проблем не знаю. Плюс есть раздельное проксирование даже на пк, правда замороченнее, чем на телефоне. И если немного пошаманить по их мануалу, то автобут с автоподкобчением есть. Хз на сколько контора надежная, но вроде пока норм
А пробовали обновлять данные профиля ("Update subscriptions")?
У меня тоже было такое пару раз, и это помогло.
На андройде AFWall+ может блокировать обращения приложений к localhost.
Указывайте, пожалуйста, что это только для rooted устройств, т.е 0.01%
Повод для очередного повышения цифровой грамотности населения)
root имеет свою цену, которую мало кто готов заплатить. Это банки, потеря Knox и так далее…
Knox, конечно, потеря, но это касается только Самсунга. В остальных случаях можно рут скрыть
А вы на практике пробовали рут скрывать? Это вечная война щита и меча. Сегодня удается крыть - завтра обнаружат.
У меня рут права и скрыто всё. Работает всё 3 года.
Для работы Mir Pay стоит модуль Pay Security Bypass. Если какое-то приложение жалуется на Root, в Magisk скрываю через Deny List
Собираюсь рутануться и поставить Magisk. Средствами magisk можно ли решить описанную в теме проблему? Например, посадить условный Max в песочницу, чтобы он думал, что он на телефоне Inoi подключён по wifi за лютым фаерволом, и открыт только https прокси на 10.0.0.1?
Если я правильно понял. То проблему уязвимости рутованных устройств это не решает. Понятно, что ещё нужно троян умудриться установить себе. Но вполне может и с обновлением какого-то приложения прилететь. И если я всё правильно понял, то лучше два устройство использовать, чем одно с root правами.
Я могу ошибаться в формулировке, но на lineageos через magisk скрыл рут права и пользуюсь банкингом и госуслугами уже около года без нареканий.
Мне такой подход нравится: по сути, отключу-ка я фичу безопасности, чтобы с этого устройства в банк ходить.
У меня знакомый есть, техдир в крупной компании, у него в заведовании случился зловред, который со счета юрлица несколько лямов украл, напрямую влезая в работу банк-клиента на ПК. Чувак офигел, никогда не верил, что кто-то такое сотворит, мишень для атаки оказалась совсем мелкой. А уж на своём телефоне, где стоит совсем одинаковый клиенты сбера и той же альфы с тиньком... Ну, в общем, рут штука такая, может и иной раз оказаться не совсем лишним.
Вот на PC рутом можно по страницам банков ходить, а на телефоне всё сразу становится плохо. Неужели линукс (на нем же андроид?) настолько хуже винды?
Magisk уведомляет, что приложение запрашивает root-права. Нужно больше деталей о ситуации, иначе при детальном разборе может оказаться, что root тут вообще ни при чём.
В остальных случаях можно рут скрыть
Я зарёкся так делать. Лишился на своей трубке возможности бесконтактной оплаты. А доступ к банковскому приложению так и не появился. One+
позвольте надушнить, swoo(балалайка для NFC оплаты альфа банком) нивкакую не видит KSU, даже без всяких модулей
Happ - уязвим и особо опасен, не рекомендуется использовать ни при каких обстоятельствах... Только что прилетело обновление на Happ и он перестал детектиться per-app-split-bypass-poc
Чушь.
Грамотность тут не причем.
Не составляет особо труда по гайду с 4пда рутировать устройство. Только попробуйте найти ещё устройства, в которых можно разблокировать загрузчик. С каждым годом их все меньше.
Так что зависимость не от "грамотности населения", как вы пренебрежительно сказали, а от самих устройств. Которых, опять же, с каждым годом все меньше.
Только попробуйте найти ещё устройства, в которых можно разблокировать загрузчик
Sony к вашим услугам. Там не то что разблокировать, кастомизация прошивок во все поля.
Разблокировать можно, кроме (пока) 1 VII и японских аппаратов.
https://developer.sony.com/open-source/aosp-on-xperia-open-devices/get-started/unlock-bootloader
https://wiki.lineageos.org/devices/#sony
Но комьюнити едва живое: lineage, еще полтора кастома да и всё. Это не десятые годы, когда там прошивок было на любой вкус и цвет.
Тенденция по заблокированным загрузчикам безусловно есть, но пока вариантов достаточно. Xiaomi (включая Redmi, POCO), Pixel, Samsung, OnePlus, Motorola, Sony. Там конечно подводных камней полно. Однако, на 4PDA они весьма подробно изучены.
Я вообще не знаю, дают ли Vivo и Honor возможность разблокировки загрузчика. Так что, возможно, рут на многих смартфона и вовсе невозможен. Можете посмотреть темы на 4пда или где еще, там все сдохло в этом плане с года 2020-21
Дык AFWall+ с iptables работает, а его долбаный гугель-мугель давно отрезал от простого трудяги))) Только с рутом. А рут сейчас далеко не на всех производителях поставишь, у BBK смартов, у Хуавея рута, увы, нету, в редких случаях на смартфонах, где умудрились взломать загрузчик)
Ойфон по той же причине отваливается.
Видимо, остается ждать пока поправят и выпустят обновы. Либо другие протоколы гонять.
Спасибо за наводку. В любом случае после новостей о принудительном обнаружении VPN траффика на андроид НЕОБХОДИМО накатывать рут. Без него вы от ВК и Сбера не скроете наличие VPN-клиента на телефоне, даже если он отключен (Модуль HMAL). Как ниже писали "Повод для очередного повышения цифровой грамотности населения"
Так простое решение ближе чем кажется .. Во первых не использовать клиенты отечественных сервисов во вторых можно использовать второй смартфон.. Это что бы пользователю не объяснять что ему можно и что нельзя очень долго) кроме того есть же разные варианты проксирования ..это не обязательно сокс и вообще не обязательно именно прокси и сплит тоннель..но за статью спасибо..информация полезна)
кроме того есть же разные варианты проксирования …это не обязательно сокс и вообще не обязательно именно прокси и сплит тоннель
Только у 95% населения это сокс и именно прокси
А вы не в курсе, на всяких Xiaomi, Realme и вроде даже Samsung есть второе пространство. Как оно устроено? Это отдельный пользователь в ОС по сути? Я к тому, если использовать в нём все приложения, которые потенциально занимаются слежкой (или наоборот ВПН + телега, Ютуб и т.д.), получится ли избежать такого способа слежки через описанную вами уязвимость?
Да, но уже существующие клиенты, получив обновление от "гос" приложения с использованием этого эксплойта - засветят свои VPN сервера.
Вопрос кто быстрее - клиенты обновятся или "гос" приложения.
А как быть "наружным" россиянам за границей? Им VPN в любом случае нужен. Иначе при выключенном VPN есть вероятность, что либо РФ-сервис не откроется, либо постучит кому положено, что пользователь находится за рубежом (пора проверять на налоговое резиденство, например).
Ну это решается резидентным выходным узлом и использованием веб версий приложения..
Арендовать Didicated Server где-то в РФ или размещать его у друзей / знакомых причем у маленьких провайдеров, где чуть меньше шансов что прибегут парсить логи коннектов.
Использовать белый VPN который одобрил РКН, но от идеи проверки на налоговое резиденство не спасёт (но оно пока и не реализовано).
Использовать ВПН от непонятно кого в РФ, но под веб версиями сайтов. Есть шансы что и за такие впны возьмутся, но "не сегодня" и опять же надо будет не только поднять логи коннектов но и содержимое трафика, чтобы узнать кто залогиниться в сайт в этого ВПНа.
---
Мой взгляд дилетантский и обывательский, не стоит брать его за идеальный вариант
а на законодательное регулирование доступа граждан РФ к сервисам внутри РФ похоже, вообще забить решили. Почему нельзя гражданину РФ пользоваться госуслугами (и прочими сервисами в РФ) из-за рубежа? - Покачену!
Живя в России, невозможно практически не использовать клиенты отечественных сервисов
Банк, маркетплейс, банально погода точная, карты - как минимум
Дождаться пока клиенты заменят tun2socks на https://github.com/XTLS/Xray-core/tree/main/proxy/tun
Он скорее не работает, чем работает
Очень смелое заявление... В нем нет огромного чемодана управления сетью (менеджмент роутинга и ip адресов) который тянут за собой приложения типа tun2socks, но как интерфейс->xray core он вполне работает неплохо.
Это дизайн такой, не превращать приложение занимающееся трафиком в сетевой комбайн. Сетевым менеджментом должно заниматься приложение используещее библиотеку, но не сама библиотека которая занимается трафиком.
Очень смелое заявление…
Заявление человека, который пытался его использовать. Кроме того, что он не полнофункиональный, так еще и имеет примерно миллиард багов. То зависнет, то пакеты в /dev/null улетят, то еще что-то.
А для VpnService нужен полнофункциональный сетевой интерфейс.
И да, на андроиде скорее всего багов еще больше, я не видел ни один клиент, который его использовал бы. А вот к примеру в sing-box с этим проблем нет.
Он прекрасно работает, но я не вполне понимаю как он решает проблему сплит-тунелинга. Без изоляции сетевых пространств имён этот интерфейс точно так же доступен всем желающим, да ещё и аутентификации как в том же SOCKS нету by design.
А с изоляцией и localhost не проблема изолировать.
А в sing-box уже есть поддержка tun из коробки, кстати. Только, видимо, клиенты всё равно используют socks5 inbound, чтобы был общий интерфейс.
Мы уже догнали и перегнали китайцев в плане жесткости блокировок и борьбы с КВН. А значит халява закончилась и теперь придется писать софт их обхода самим. Беря за основу их опенсорсные наработки и приспосабливая их к нашим новым условиям.
...
iOS точно так же уязвим, на iOS точно так же уязвим Happ (проверено).
Не забывайте что на iOS вообще нет раздельного туннелирования, так что в целом обходить даже ничего не надо. Если у андроида будет шанс, то у iOS - нет.
Это не сплит туннелинг, это роутинг
А в чем разница, можете пожалуйста объяснить?
а что тогда такое сплит туннелинг? Это когда разделяешь туннелирование по определённым приложениям?
понимаю, вопрос названий, но по сути одно, другому не мешает. Говорить, что на иоси совсем этого нет – ну странно немного:
Смотрите, на пальцах есть два похода:
1) Смотрим, какое ПРИЛОЖЕНИЕ хочет попасть в интернет, если ПРИЛОЖЕНИЮ разрешено - оно использует VPN. Такое есть на android и нет на iOS. Это split tunneling.
2) Смотрим, на какой домен или IP хочет попасть приложение. Если IP или домен в списке - пускаем, если нет - нет. Это routing, такое есть везде, но это решето, потому что условный Макс может в любой момент просто взять и постучаться на сервер Telegram. Если он ожидает, что Telegram с вашего устройства доступен быть не должен, то увидев ответ "привет я телеграм", он может просто слить ваш IP куда надо.
Это все до первого домена Макса где-нибудь в Польше, на той же впске за 5 баксов, которая живет только чтобы сливать ваши IP. Роутинг по доменам и геозонам - это решето, оно не работает против тех, кто за вас серьезно взялся.
факт, "АЗС ГПН" на iOS уже год, как легко детектит vpn по списку интерфейсов и route table. Так что для iOS'еров 2 пути: сносить ру приложения или ходить с карманным роутером
Мне казалось, что в целом про Happ и его команду давно уже известно интересующимся, но видимо нет. И да, судя по информации в СМИ - в методичках отмечено, что на iOS есть проблема с детектированием из-за особенностей архитектуры, об этом тут, на хабре, так же есть статья.
в целом про Happ и его команду давно уже известно интересующимся
Можете подробнее рассказать про это тем, кто не сильно следит за этим всем? Спасибо
в методичках отмечено, что на iOS есть проблема с детектированием из-за особенностей архитектуры
Нагло врут, а то как эта новость разошлась по официальным СМИ, это только подтверждает.
очевидно, миру нужно приложение приложение псевдо-впн на мобилку, которое "сливает" ип произвольных серверов и тех, что в "белых списках".
Правильно ли я понимаю, что эта уязвимость актуальна только при включенном vpn клиенте (в том числе в режимах perapp/split-tunnel) ? При выключенном spyware к xray socks5 proxy никак не подключится? Если так, то "простое" решение отключить per-app и split-tunnel и включать vpn вручную(или чз автоматизацию) перед запуском условного telegramm с предварительной выгрузкой из памяти spyware-приложений.
Ну, только если вы готовы этим заниматься каждый раз и уверены, что не забудете когда-то в запаре.
на ios штатными средствами настраивается включение и выключение vpn при запуске/закрытии приложения, на android делается вроде через Tasker
Подскажите, как это делать на iOS?
Можно использовать Shortcuts. Но там задержка есть при автоматическом включении и отключении VPN.
На русском это приложение называется "Команды". Делаете автоматизацию, мол, открытие\закрытие приложения А будет триггером включения\отключения средств обхода блокировок
где гарантия, что прока вы чатитесь в условном телеграмме spyware-приложение не проснется (по таймеру, сайлент-пушу, жобШедулеру, етц) и не сделает свое черное дело?
Есть один клиент с поддержкой аутентификации Xray (репозиторий). Минусы только в удобстве: конфиг и правила маршрутизации придётся писать в json.
у меня сегодня отвалились 2 платных сервиса и 1 бесплатный, и причем часть сайтов в зоне ru тоже не открывается
Я теряю деньги из-за всех этих блокировок, что делать
GeoIP ни на сервере, ни на клиенте, ИМХО, не поможет ничем, у них хватит мозгов стучаться на арендованный для этой цели зарубежный хост.
Получается, на стороне сервера два IP будут необходимы.
А на стороне клиента - старый добрый фаерволл не подойдёт? Чтобы ни одно приложение без явного разрешения не могло стучаться на локалхост.
А на стороне клиента - старый добрый фаерволл не подойдёт?
Подойдёт. Просто запретить приложениям-стукачам прозванивать локальные адреса и усё.
Имхо тут оптимален только вариант белых списков со своей стороны - youtube/instagram/github и тп все заворичивается в туннель на какой то входной ноде, который ретранслирует уже трафик как есть на VPS с развернутым wg/vless.
А все что не входит в "белый список" - шлется напрямую дальше в интернет.
Да, это проблематично, да надо будет постоянно обновлять список на основе личного опыта, но так эти упыри гарантировано не увидят ip вашей впски, максимум айпи русской впски, являющейся входной нодой для всех.
На выходном VPS можно арендовать еще один ip и использовать его для выхода в интернет, или использовать еще один VPS, можете настроить Proxy, и никто её ip кроме вас и вашего российского хостинг провайдера не узнает. Всё таки необходимо заботится об удобстве при пользовании интернетом.
Кстати может быть кто-нибудь знает предоставляют какие либо из VPS провайдеров второй серый IP. Ведь для выхода не нужен белый ip
Можно почитать в комментах, этого недостаточно.
скаМ (и в будущем всем российским приложениям, которые обяжут поставить библиотеку с этой логикой под угрозой исключения из белых списков и лишения аккредитации) достаточно иметь один зарубежный сервер. Затем делается два запроса: один к серверу скаМ, второй - на подконтрольный зарубежный сервер. Если айпишники различаются - отправляем в блок иностранный айпишник.
Так в том и смысл, что на ваш зарубежный сервер идет трафик только для специфичных доменов, совершенно не важно какой впс разрабы скама купят, он не попадет в ваш "белый список".
В таком варианте тоже есть свои уязвимости и проблемы - начиная с того, что отказ входной ноды повлечет отсутствия интернета для вас, но зато как минимум вы свой ip не спалите вообще никак.
Для этого подставной зарубежный сервер Макса должен каким-то образом попасть в «белый список» на клиенте, о котором написал sloww. Не так ли?
Для андроид файрвол доступен только с рутом. Не на всех устройствах это можно сделать безболезненно.
" На сервере вам нужно заблокировать доступ обратно в geoip:ru:Есть ли инструкция, как это сделать? Не поломав доступ к самому серверу из РФ.
Диапазон loopback адресов от 127.0.0.0 до 127.255.255.255. Это 16777214 хостов. Диапазон портов от 0 до 65535. Умножаем 16777214 на 65535 и получаем более триллиона комбинаций. То есть решение простое со стороны разработчиков — дать юзверю возможность вручную устанавливать нестандартный адрес и порт (ещё лучше через рандомайзер адреса и порта), и пусть приложения-стукачи хоть обснифаются в попытках прозвонить искомый локальный адрес и порт.
А если и этого мало, как loopback можно поставить адреса из диапазонов 172.16 и 192.168 с соответствующим набором портов. Главное чтобы не было совпадений по пулам адресов при подключении к мобильной связи или Wi-Fi.
В v2RayNG порт можно поменять. В теории можно поставить любой до 65535, во всяком случае это на время задержит снифер (если он есть). Но проблема реальная и её надо исправлять. Правда относится она не к самому протоколу VLESS, а к его реализации.
Современные реализации masscan, zmap позволяют просканировать весь ipv4 интернет меньше чем за час. А тут вообще локалхост, как ниже написали.
Не проще просто клиенту генерировать случайный логин/пароль при запуске и передавать его уже tun2proxy? Тогда кроме как через tun2proxy никто не подключится.
К socks, но не к tun
https://habr.com/ru/articles/1020080/comments/#comment_29790062
Все мобильные клиенты на основе xray/sing-box запускают локальный socks5 прокси без авторизации.
Очень смелое утверждение. У меня в конфиге inbound только tun интерфейс.
Да такое ощущение, что автор просто хайпится на теме, как когда писали про то, что Макс просит разрешение к камере и прочему, как и любые другие мессенджеры. Недавно про прослушку ВПН затирал, будто другие приложения, в том числе иностранные, про включенный обход не через тест узнают.
Сейчас половина постов на этом хайпится, так что да, решили просто хайпануть
я специально искал вменяемый коммент вроде этого чтобы понять что я не один вижу
тезисы из его двух статей: они могут = они делают
безальтернативно
показано что MAX проверяет доступность хостов и статус VPN - значит цель Ловить пользователей с приватными VPN для РКН
а как же гораздо более необходимое для любого приложения, сразу навскидку:
-диагностика проблем подключения для улучшения UX ?
-AB-тестирование доступности сервисов в разных регионах ?
манипуляция и эмоции точно есть
Так точно, пока вы писали “ну может и не для блокировок Max это собирает” минцифры уже бизнесу рассылает требования помочь и заблокировать ВПНы.
Проснитесь.
а как же гораздо более необходимое для любого приложения, сразу навскидку:
Все эти аргументы уже обсосаны под соответствующими статьями. Для диагностики проблем подключения у VK есть сотни собственных серверов. И TURN-сервера у них тоже есть, которые сейчас с улюлюканьем абузят некоторые умельцы. Им не нужны сервера в Польше для этих целей, и определялок IP в ру-сегменте более чем достаточно, если по какой-то нелепой причине VK брезгует своими.
AB-тестирование доступности сервисов в разных регионах ?
Каких-таких сервисов VK в Европе? А к серверам Whatsapp они зачем стучались, тоже свою доступность проверять? Не надо их выгораживать, на таких поблажках и строится вся система защиты ура-патриотов "все не так однозначно, вот НА ХАБРЕ сказали, что ВК просто очень хочет пользоваться TURN-ами Whatsapp! Ничего такого в этом нет".
ни у кого тут нет достоверной информации чтобы заявлять однозначно, в том числе и у ТС, даже указанных выше методичек никто не видел
я сразу навскидку встречно альтернативы по твоим тезисам:
Приложение может проверять доступность конкурентов, чтобы выявить проблемы у пользователя с доступностью тг и прочих сервисов и предложением своего мессенджера.
Может использовать публичные сервисы (ifconfig.me, ipify) как нейтральные индикаторы выхода в интернет, что уменьшить количество точек отказа архитектурно, регулярно вижу такое в проектах ( пинги восьмерок при доступности своих DNS серверов и прочее)
никаких никому оправданий
очевидный же разрыв в логике
Вам повезло. У вас, вероятно, sing-box и правильный конфиг. К сожалению, большинство пользователей используют xray-based клиенты, которые построены на tun2socks.
А как tun помешает атаке? У него ж с авторизацией ещё хуже чем в socks5…
Официальный клиент sing-box для Android (SFA) использует VpnService напрямую, без SOCKS, так что он таким образом не детектится (если конечно ручками не добавлять SOCKS-inbound в конфиг)
Да, если у вас он не добавлен, то вы в безопасности. Просто обычно все его пихают. В статье так и указано:
в распространенных конфигурациях так же уязвимы.
а я правильно понимаю, что это тот самый переключатель "VPN\Proxy mode"
или как в Nekoray галочка - TUN mode.
И основное различие в том, что в режиме прокси - нужно явно сами апсы туда заворачивать (например выбирать "системный прокси"), а в режиме VPN (как он в v2rayNG называется) или TUN (в Nekoray) все идет через клиент и подвергается роутингу freedom\direct\block?
Или я совсем уже все напутал?)
Возможно ли выполнить данную атаку посредством web-app приложений? Если снести все ру приложухи со смартфона и перейти на web app, насколько высока вероятность успешности такой атаки?
Именно такую - нет. Браузер не даст подключиться просто так сделать запрос через порт на локалхосте.
Очень возможна. Например, так кое-какие две конторы систему отслеживания на Android сделали. На десктопе вспоминаю сразу апдейтер драйверов Intel - в трее висит сервер, а страничка на сайте работает как UI. В uBlock Origin есть фильтр "Block Outsider Intrusion into LAN" для хоть какой-то защиты от подобного.
Ну собственно по этой причине недавно наблюдались повальные запросы от веб сайтов к локальной сети? В целом в браузере же их и запретить можно
Браузеры постепенно и сами с этим борются: Chrome уже полгода назад запретил сайтам обращаться к локалхосту через загрузку ресурсов и fetch(), а в будущем это поведение будет распространено и на вебсокеты.
Все-таки это не критическая уязвимость. И это не относится к VLESS. Но тема открытого socks поднята верно, хоть и немного истерично.
У меня этот сканер из защищенного пространства Lineage (без рута, с гуглосервисами) ничего не нашел.
По сути это проблема конфигурации ядра. Ограниченность клиентов, которые не дают всё правильно настроить вручную. С тем же чистым sing-box такой проблемы нет (а с Nekobox, который его использует внутри себя, проблема есть). Активно пропагандирую использование оригинального клиента sing-box в статье на хабре: https://habr.com/ru/articles/1018964/
Правильные с моей точки зрения шаги:
Убираем mixed inbound в конфиге для Andoid. А если не убираем, то добавляем логин и пароль: https://sing-box.sagernet.org/configuration/inbound/mixed/
Добавляем плохие пакеты в
exclude_packageнастроек tun inbound (в статье по ссылке я туда добавил клиент Max). Эти пакеты (программы) не будут попадать в tun. Данную настройку можно переопределять в интерфейсе sing-box для Android (галочками выбирать приложения).На всякий случай добавляем плохие пакеты в правила маршрутизации по
package_nameв direct (в статье я так поступил с Max). Если приложение вдруг попадет в tun или в не удаленный mixed inbound, то оно всё равно пойдет в обход прокси, потому что правила маршрутизации работают и при поступлении трафика в ядро через локальный socks.
не то чтобы уязвимость, скорее недочет архитектуры клиентов xRay, но додуматся до такого - гениально, респект, исправил эту проблему в своем клиенте olcNG, спасибо вам еще раз!
А спасет ли ситуацию использование "второго пространства"? То есть все "ру" трояны в отдельном пространстве, а все остальное в отдельном, включая квн
Очередная победа mihomo клиентов + для угарелых голый sing-box
Так же самые распространенные Clash и Sing-box клиенты в распространенных конфигурациях так же уязвимы.
А всякие Clash используют ядро Mihomo.
где там xhttp и finalmask в mihomo? А мне надо, уж извините.. Если вдруг уже стали поддерживать это, особенно xhttp с его обфускационными фиксами, буду очень рад
В happ ещё и при попытке настроить раздельное туннелирование все правила сбрасываются на дефолтные походу при каждом запуске
В идеале такие приложения должны использовать :0, т.е. генерировать автоматически свободный порт. Да, его все равно можно сканировать, но в сочетании с авторизацией должно быть норм. Есть вероятность, что в каких-то клиентах это уже будет работать.
а что по поводу клиента амнезии?
Я его не проверял, если честно.
Тоже интересно. Они же тут на Хабре есть. Может отпишутся
AmneziaVPN 4.8.14.5 (latest в playmarket) уязвима через socks без авторизации.
Только что проверил через termux, запихнув его в список-исключения.
Уже ишью написал ктото https://github.com/amnezia-vpn/amnezia-client/issues/2452
Прикольно обвинять команду Happ во лжи, основываясь на своих домыслах.
Теперь по делу:
Мы уберем HandlerService, который болтается у нас со времен царя гороха. Прошу заметить: если вы трупровайдер VPN, то наверняка кидаете свою JSONподписку, а значит, там его нет. Пароль на socks, который будет генерироваться случайно на каждое подключение, да, сделаем. Самая главная дичь: в iOS вы никогда не сможете защититься от проверки на VPN, потому что условный Max всегда сможет отправить пакет на условный ipaddress.my и узнать IP. Поэтому спекулировать и орать «смотрите, они плохие» может каждый. Вы предложите решения, если они правда существуют, а мы не поленимся и сделаем их для вас. От себя могу порекомендовать делать мосты в соединении, чтобы, даже если кто-то узнал ваш выходной IP, он не смог узнать входной.
Вас обвиняют не в отсутствии пароля на socks5, этим страдают буквально все xray клиенты и часть sing-box.
Вас обвиняют в том, что вы создали огромную дыру запустив xray api и отказались исправить ее после сообщения о ней 10 марта 2026 года.
А если не затруднит. Мне для личного расследования, скиньте пожалуйста на почту admin@happ.su где и кто отказался, что-то исправлять.
Ну на самом деле отказ был по началу даже канале “Флудилка” вашего телеграмм чата уже после выхода статьи даже под общественным давлением.
У вас с 10 марта был доступ к репозиторию.
Если вас интересует именно переписка, то она была в почте. Как раз с admin@happ.su
Если ваша позиция изменилась, вы можете заявить об этом однозначно и я добавлю UPD
del
А генерировать пароль динамически - никак?
Хорошо, мы поставим пароль на socks
Поставьте
Через день-два разрабы Max глянут пароль и научат Max подключаться к socks по паролю
Поставьте динамический
В чем проблема?
Если я правильно понимаю, приложения не используют этот локальный прокси-сервер напрямую, вы можете генерировать случайный порт и случайный пароль при запуске. Дальше max пусть брутит сколько хочет.
Я думаю, в любом случае блокировать приложения-стукачи надо на стороне КВН-серверов. Потому что невозможно заставить миллионы нешарящих пользователей обновить клиенты (а некоторых - ещё и отказаться от любимой Windows-7, под которой запускаются только достаточно древние версии).
Кстати да, единственный рабочий вариант на данный момент. Запретить выход во первых на geoip:ru сервера, во-вторых, на сервера приложений-стукачей (типа того же Скама).
А вот такой роутинг - хороший выход?
https://github.com/frayZV/simple-ru-routing
А что помешает этим приложениям так же как и вам, лезть на арендованные из хозяевами VDS сервера в Европе и стучать через них таким же образом как вы обходите блокировки? Вот мы и поменялись ролями)) Сперва Роскомнадзор пытался блочить нам сервера, а мы говорили - мы все равно прорвемся, все сервера не заблокируете! А теперь наоборот, мы пытаемся заблочить его, а он будет кричать мы все равно прорвемся, все сервера не заблокируете!
Это невозможно. Как вы отличите запрос от условного озона к условному check-my-foreign-ip.com от вполне легитимного запроса туда же?
Вот например:
Условный озон при каждом запуске подгружает список зарубежных и отечественных чекеров, кэшируя их.
При каждом запуске он чекает ip через эти сервисы.
Когда-нибудь пользователь забудет выключить vpn и попадётся.
Вносить чекеры в блэклисты на сервере бесполезно, их очень много + ничто не мешает РКН тихонько свои поднять.
Маршрутизировать только заблокированные ресурсы просто нереально, если невозможно делать это по домену 2 уровня, потому что доменов 3 уровня у того же ютуба - воз и маленькая тележка. А у инсты они вовсе динамические. По подсетям - еще хуже, админить нереально, как и проверять, не затесался ли в подсеть какой-нибудь чекер.
Только сплит туннелирование по приложениям и фикс описанной в статье дыры спасут, имхо.
Ну и разделение входного и выходного ip, лучше вообще у разных хостеров.
Забанят выходной и черт с ним.
Простите за тупой вопрос, а как это делается? Здесь речь идет о https://docs.rw/docs/learn/server-routing об этом? Если рассматривать настройку на примере данной панели? Т е по такой же схеме коннектимся к условному серверу в Германии а выход будет из Финляндии ? благодарю!
Как вы отличите запрос от условного озона к условному check-my-foreign-ip.com
Если условный озон не будет открываться у пользователя без выключения vpn, это простимулирует пользователя таки настроить раздельное туннелирование, обновив сначала клиент.
@runetfreedomПодскажите, а нет ли у вас планов добавить ваш пресет настроек из v2rayN в v2rayNG? Было бы очень полезно, а то думаю почти все пользователи v2rayNG сидят на стандартном китайском Domestic DNS...
Если для этого нужен Android девайс, то думаю народ может помочь с этим)
Да я сам сижу на v2rayNG…
Я постараюсь найти время и сделать
ужеж всё есть, assets там уже есть runetfredom/geoip а json с роутингом можно взять отсюдова
Вы путаете настройки маршрутизации и настройки самого клиента. Я говорю про пресет настроек для раздела Settings, а не assets. В v2rayN прессет Russia включает в себя не только настройки маршрутизации, но и DNS серверов.
Очень ждем того же и для v2rayNG, ну или хотя бы на первое время текстовую инструкцию для обывателей о том, что куда прописать
На Android есть замечательный VPN клиент - Husi, основанный на sing-box. Public Archive так как автор мигрировал в другой репозиторий. Кроме того, данный VPN - клиент поддерживает маршуритизацию трафика по типу протокола(TCP, UDP и др.), по типу подключения (WI-FI, мобильные данные и др.).
AmneziaVPN Xray тоже уязвим из-за прокси. Это сложно пофиксить? Даже если сокс не закрыть, можно генерить на него пароль при каждом запуске.
Amnezia VPN можете прокомментировать, пожалуйста?
Оригинальный xray клиент умеет закрывать свой сокс5 паролем.
На iOS довольно попсовый клиент Shadowrocket. Как с ним дела обстоят?
интересно шо как с shadowrocket на ios
у меня нет возможности проверить, скачайте tcp port scanner и просканируйте 1-65535 на 127.0.0.1
Можно выбрать тип прокси HTTP или TUN Mode, но при втором варианте какие-то явные проблемы с загрузкой контента, начинает торчать порт который можно указать вручную, а также в адрес прокси тоже есть два варианта 127.0.0.1 и еще один.
но есть еще какая-то настройка "цепь прокси" где можно выбрать айпи, порт, логин и пароль. Возможно что это решение и как потестить?
Проверил, там без авторизации socks на 1082 порту, ip сервера возвращается. Неприятно.
По умолчанию торчит открытый 1080, но можно поменять на произвольный: настройки => прокси => порт
Получается что ваша DLL для проксирования голосового чата в Discord становится все более актуальной, раз TUN mode лучше выключить из-за UDP
Через час после публикации статьи разработчик Happ в своей телеграм группе отказался считать это уязвимостью и отказался исправлять даже под давлением своей собственной аудитории
а я не понял, что он должен исправить?
заменить порт 1080 на что-то иное? Но кто мешает злобным сканерам перебирать все открытые проты?
включить там авторизацию? но как быть с приложениями которые не умеют в прокси а просто ходят в интернет?
включить чистый роутинг/tun? но как заставить ходить spyware мимо этого tun?
Статья алармит: "на меня не реагируют", но как должны среагировать разработчики я не понял.
включить там авторизацию? но как быть с приложениями которые не умеют в прокси а просто ходят в интернет?
А как они сейчас ходят? Через tun2socks.
включить чистый роутинг/tun? но как заставить ходить spyware мимо этого tun?
Как и сейчас - через VpnService
ну так и что должны сделать разработчики v2rayTun, например? я так и не понял.
На проксю повесить ротацию портов + паролей, из-за чего сторонние сервисы не смогут через нее ходить и пойдут только как требуется через VpnService
если порты будут ротироваться, то приложениям тоже нужно будет постоянно менять настройки портов. но это не будет мешать spy сделать nmap и посмотреть "какие порты открыты?"
если авторизация будет у прокси, то далеко не все приложения смогут в это сходить. смысл прокси теряется
если же настроить tun, то как изолировать от него spy? непонятно
я пока не понимаю, какой комплекс мер предлагается для устранения "критической уязвимости vless"?
Включить авторизацию для socks5. Так же, как и все остальные.
Есть ли у вас свой тг канал где вы обсуждаете данную тему и какие клиенты безопасны для использования сейчас?
Что там с karing, тоже самое?
Открою вам страшную тайну (о которой не знает даже Минцифры): и на 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”, в этом случае сломается доступ к устройствам в локальной сети (принтеры, телевизоры, умные устройства, и т.п.).
А Happ пользуются исключительно потому, что во всех этих прокси-протоколах нет понятия сессии, и заблокировать конфиги для конкретного устройства нельзя, пользователи могут делиться ими бесконечно.
В Happ сделали HWID, прямо как в старфорсе :D
На сервер отсылается HWID и сервер не выдаёт ключи больше, если хоть раз они скачивались с одного HWID. Экспортировать их тоже нельзя.
Пользователям он не нужен, он нужен сервисам.
Так и есть ) А можно вместо tun0 создать интерфейс tun0398fgx0?
Получить список интерфейсов тривиально. Наберите в termux ifconfig
Действительно, сначала попробовал ip a, и получил access denied. Радость была преждевременной. Что ж, скрыть выходную точку от РКН не получится, ставь или нет на socks пароль. Нужно и от tun избавляться, получается.
В knox termux не запускается. Интересно, значит ли это, что и список интерфейсов нельзя будет получить?
Отличная находка, уже начал допрашивать искусственного идиота по поводу собственной реализации, вот что он накидал, кому интересно:
Скрытый текст
Android’s “Block connections without VPN” (lockdown) is the only real defense against the bypass technique in that comment. But users hate enabling it because it kills their LAN: Chromecast stops working, printers disappear, smart bulbs can’t be reached, web UIs on 192.168.1.1 time out. So most users leave lockdown off, and the bypass remains exploitable.
If we can make lockdown not break LAN, suddenly there’s no reason to leave it off. That’s what excludeRoute() does.
What excludeRoute() does (API 33+, Android 13+)
Normally, addRoute(“0.0.0.0”, 0) tells Android: “send all traffic to my TUN interface.” excludeRoute() punches holes in that: “…except for these subnets, send those out the physical interface as normal.”
So at VPN setup time on API 33+ we’d do:
builder.addRoute(“0.0.0.0”, 0) // existing — catch-all to TUN builder.excludeRoute(IpPrefix(“10.0.0.0/8”)) // private LAN builder.excludeRoute(IpPrefix(“172.16.0.0/12”)) // private LAN builder.excludeRoute(IpPrefix(“192.168.0.0/16”)) // private LAN builder.excludeRoute(IpPrefix(“169.254.0.0/16”)) // link-local (mDNS, AirPlay) builder.excludeRoute(IpPrefix(“224.0.0.0/4”)) // multicast (Chromecast/SSDP)
Now: Internet traffic → VPN. LAN traffic → physical Wi-Fi. Lockdown can be on without anything breaking.
The flow for one user end-to-end (API 33+)
App detects isLockdownEnabled() == false → dashboard shows a yellow warning card: “App-level VPN exclusions can be bypassed. Tap to enable system lockdown.”
User taps → opens Settings.ACTION_VPN_SETTINGS → flips “Always-on VPN” + “Block connections without VPN” → returns.
App detects lockdown is now on → warning card disappears, replaced by a green “Lockdown active” indicator.
Because we excluded RFC1918 routes, their printer / Chromecast / router admin page still work. They have no reason to turn it back off.
The flow for SDK < 33 (Android 10, 11, 12)
This is the awkward part. excludeRoute() literally doesn’t exist on those API levels — there’s no compat shim. Two realistic sub-options:
Sub-option A — degraded experience, honest warning (what I’d recommend):
On API < 33, we can’t carve out LAN. We still detect lockdown and show the same warning card.
But the “Fix it” CTA gets an extra line: “Note: enabling lockdown on your Android version will also block local network devices (printers, Chromecast). Upgrade to Android 13+ for full LAN compatibility.”
User makes an informed trade-off. If LAN matters more, they leave lockdown off and accept the bypass risk; if security matters more, they enable lockdown and lose LAN. Same status quo as today, but now they know.
Sub-option B — IP-route trickery (not recommended):
We could try to approximate excludeRoute() by not adding 0.0.0.0/0 and instead adding many narrow addRoute() calls covering “everything except RFC1918.” That’s the standard pre-13 workaround.
It works in principle (e.g. add 0.0.0.0/1 + 128.0.0.0/2 + 192.0.0.0/9 + 192.169.0.0/16 + … carefully splitting around the LAN ranges).
But it’s fragile, ugly, easy to get wrong, and hard to reason about. Mistakes leak.
Verdict: not worth it. minSdk is already 29, and Android 13+ adoption is high enough that the cleaner path (option A — honest warning on old versions, real fix on new versions) is fine.
TL;DR: нужен sdk 33+, не проверял лично пока, сейчас займусь.
UP: стена под спойлером решает проблему доступа к LAN, проблему доступа приложений без разрешения оно не решает.
Include/excluderoutes управляет маршрутами для главной таблицы маршрутизации. Если приложение забиндилось на интерфейс, оно их игнорирует (в обе стороны) — только что проверил на примере OpenVPN for Android, который настроил в режим «только локальная сеть» (маршрут только на диапазон выданного адреса). Curl’ом удалось достучаться до ifconfig.co через tun0.
Подумайте о другой стороне проблемы: многие программы, предназначенные для работы в локальной сети, отправляют ответы на запросы из локалки через направильный интерфейс (через VPN), потому что не биндятся на тот интерфейс, с которого получили запрос. Это типичный баг. Я даже просил разработчиков VPN-программ по умолчанию вводить подобные исключения хотя бы для broadcast-трафика (потому что он вообще в L3 VPN маршрутизироваться не должен, а L2 Android не поддерживает): https://github.com/schwabe/ics-openvpn/issues/1847
Выглядит как баг в Android. В документации к VpnService.Builder.addAllowedApplication сказано:
Adds an application that's allowed to access the VPN connection. If this method is called at least once, only applications added through this method (and no others) are allowed access. Else (if this method is never called), all applications are allowed by default. If some applications are added, other, un-added applications will use networking as if the VPN wasn't running.
Network.bindSocket(vpnNetwork) работает и делает ACL через ConnectivityService, но он не закрывает setsockopt(SO_BINDTODEVICE, “tun0”) - это ядро Linux, на ядре 5.7+ оно доступно непривилегированным пользователям и обходит ACL.
И действительно похоже на баг, даже два (еще позволяет отправлять запросы в обход установленных VPN-приложением маршрутов). Я был уверен, что это by design, но нет — Network.bindSocket даёт отлуп, а SO_BINDTODEVICE обходит даже allowBypass и allowFamily.
@m0xf, @nidalee, поможете корректно описать проблему в Google? Я сделал PoC, обходящий несколькими методами несколько разных конфигураций.
Запряг Claude уже писать, благо уже накидан достаточно жирный док на эту тему. Параллельно ищет решение в коде\архитектуре впн приложения, может что-то найдется.
Драфт багрепорта закинул на альтернативный пастбин, там есть TBD плейсхолдеры, я еще не запускал реальные тесты.
В GrapheneOS это фиксили похоже: https://grapheneos.org/releases#2025072700
This release resolves 2 upstream Android VPN leaks discovered by GrapheneOS and our community testers.
prevent using SO_BINDTODEVICE to bypass VPN lockdown mode (leak protection) to resolve an upstream Android VPN leak discovered by GrapheneOS testers where code specifies a specific interface via a special system call to bypass the VPN
prevent using NsdService#connect for components restricted by VPN lockdown mode to prevent a very limited upstream Android local network VPN leak discovered by GrapheneOS
https://github.com/GrapheneOS/os-issue-tracker/issues/2381
Фикс: https://github.com/GrapheneOS/platform_packages_modules_Connectivity/pull/33/changes (запретили SO_BINDTODEVICE пакетам из списка)
У меня и так последний Graphene. Я только что поставил Pixel OS, чтобы перепроверить на стоке (тоже работает).
Судя по репорту, раньше SO_BINDTODEVICE обходил даже системную опцию “Block connections without VPN”, и закрыли именно это.
Смотрите что нашел Claude Opus:
Скрытый текст
### 2. Surface
uid=-1fromgetConnectionOwnerUidas a user-facing alert (RECOMMENDED — Path A confirmed viable)This is now the recommended ship target. Path A revision (2026-04-07, confirmed empirically that calling
ConnectivityManager.getConnectionOwnerUidfrom Skyfall's own service UID, on every new flow read off Skyfall's tun fd, returns:- The real owning UID for any kernel-routed flow, including from other UIDs (verified for Chrome
uid=10154, Skyfall's own bridgeuid=10235).-
-1(Process.INVALID_UID) specifically and only for SO_BINDTODEVICE'd flows, regardless of caller UID.The discriminator is the bind mechanism, which is the exact property that makes the attack distinguishable from legitimate traffic. There were zero false positives observed in the production verification run — every Chrome browsing flow, every Skyfall bridge flow, every legit whitelisted app flow resolved to its real UID.
#### Implementation
Already partially in place — Path A added a JNI callback
notify_new_flow_checkinapp/src/main/cpp/tcp.cthat fires at the new-session SYN point and callsTun2HttpVpnService.onNewFlowCheck(proto, localIp, localPort, remoteIp, remotePort). The handler queriesgetConnectionOwnerUidand currently logs to thePathAtag. Productionising it requires:1. Whitelist comparison. When
uidis a real value, check it against the user'spref_vpn_allowed_application(orpref_vpn_disallowed_applicationin blacklist mode). Real UIDs that match the policy are fine. Real UIDs that violate the policy are also anomalies worth surfacing (this would only happen if Android's per-UID routing rule had a bug — never observed but a useful invariant check).2.
uid == -1is the attack signal. Increment a counter; record (proto, dst, port, timestamp).3. Sliding window + thresholding. First-flow vs sustained-pattern policies. A first-flow notification is the strongest possible signal because the attack only needs one round-trip to leak the exit IP — alerting after N events misses the exfiltration. Recommendation: alert on the very first
uid=-1event of any session, with optional rate-limiting to avoid notification spam if a misbehaving system service somehow generates many.4. Settings toggle: detection vs hard-stop.
- Detection mode (default for first release) — show a persistent notification "Untracked traffic detected on VPN — your exit IP may be exposed", with a tap-target to a details screen showing the destination IP/port and timestamp.
- Paranoid mode (opt-in) — immediately call
stopVpnWithError()on the firstuid=-1flow. Accepts the (small) risk of a stray system-service flow killing the VPN in exchange for a hard fail-stop before the leak completes. Recommend offering this only to users who explicitly opt in via a Settings toggle.5. Localised strings — both English and Russian, following the existing
values/strings.xmlandvalues-ru/strings.xmlpattern.#### Pros
- No special permission required (
getConnectionOwnerUidis part of the public framework API and the VPN owner has access by virtue of holding the tun fd).- No polling. Triggered by the actual event (the SYN arriving at the native tun reader).
- Cheap (~100 lines of Kotlin + the JNI callback already in place from Path A).
- Catches the attack at the moment it happens — not minutes later via stats buckets.
- Empirically validated discriminator. The smoking gun: in the Path A verification run, Skyfall's own bridge →
uid=10235, attacker SO_BINDTODEVICE →uid=-1, run side-by-side on the same tun in the same second. No ambiguity.- Independent confirmation in another VPN client: [sing-box's process detection](https://github.com/SagerNet/sing-box) logs
router: failed to search process: android: connection owner not foundfor exactly this case — same observation, different codebase.#### Cons
- Detection, not prevention. The TCP handshake completes before
onNewFlowCheckfires, and a fast attacker can complete an HTTPS round-trip in 50–100ms (verified in the smoking-gun ifconfig.co run). Paranoid mode mitigates this by tearing down the VPN on the first event but cannot retroactively prevent the leaked first request.- False-positive risk on edge cases is unmeasured at scale. Path A saw zero false positives in the verification run on a single emulator over a few minutes of mixed Chrome + Skyfall traffic. Long-term real-device behaviour may surface rare edge cases (e.g. very-short-lived kernel sockets evicted before the lookup happens, certain system services). Recommend a 1–2 week telemetry window with the detection-only mode before shipping paranoid mode by default.
- A sophisticated attacker could skip SO_BINDTODEVICE entirely if they discovered another path into the tun. None known today (Path A ruled out
Network.bindSocket— it returnsEPERMagainst the VPN network), but the workaround only catches the specific attack class we know about.**Verdict:** ship it. This is the only confirmed-viable defensive signal we have. Detection-only by default, paranoid mode behind a Settings toggle. Estimated effort: half a day to productionise (the JNI callback and
getConnectionOwnerUidplumbing already exist from Path A; what's left is the policy comparison, sliding window, notification UI, Settings toggle, and i18n strings).
Чем можно проверить в shelter? Termux туда не хочет заезжать
Спасибо огромное за находку. По-моему она важнее, чем то, что написано в статье. Проверил сейчас с чистым sing-box. И правда приложение может выбирать интерфейс, правила исключения из tun тогда не работают. Если включить в системе "Block connections without VPN", то выбрать wan0 уже не получится. Но если выбрать принудительно tun0 (а не просто по умолчанию в tun0), то процесс идет в прокси, даже если есть правило по имени пакета не пускать его в прокси (в секции route). Почему-то при ручном выборе интерфейса sing-box не может определить имя пакета. В debug-логах появляется ошибка: router: failed to search process: android: connection owner not found. Пытаюсь разобраться в причине, может быть баг, а может системное ограничение.
Изучил. Если приложение привязывается к конкретному интерфейсу, то per-app правила не работают, так как в этом случае невозможно определить пакет по соединению. Функция getConnectionOwnerUid не находит UID, если интерфейс указан принудительно. Поиск в функции выполняется по связке интерфейс (idiag_if), протокол, local, remote, а в качестве интерфейса всегда указывается 0 (и заменить значение нельзя). То есть это не баг в sing-box, а системное ограничение.
Проверил, рабочий профиль видимо от этого также не защищает: склонировал NekoBox в профиль, настроил туннель в нём, с личного профиля в Termux с curl --interface tun1 соединение идёт через туннель в рабочем профиле. В обратную сторону проверить не могу, Termux в рабочем профиле не работает, с другими терминалами тоже без удачи, в прошивке curl/wget нет, chmod +x эффекта не имеет.
Открою вам страшную тайну (о которой не знает даже Минцифры): и на Android, и на iOS, и на Windows, и на Linux, и на macOS любая программа может выполнить запрос через любой сетевой интерфейс в системе.
На Linux всё-таки не через любой интерфейс, а через любой в своём сетевом namespace, который не поменять без CAP_SYS_ADMIN.
По поводу Happ
Меня сильно смущало всегда две вещи, как неискушенного пользователя, который не умеет делать такие вещи,как автор статьи:
их основной сайт находится в зоне su и зарегистрирован в российском регистраторе. Таким образом, владелец находится полностью под колпаком чекистов, если они того захотят
отсутствие открытого исходного кода. Насколько я помню они это объясняли,что это сделано с целью безопасности функциональности зашифрованных ссылок подписок .Может я путаю.
>На сервере вам нужно заблокировать доступ обратно в geoip:ru. Если вы этого не сделаете, то шпионы в яндексах/wb/ozon’ах и т.д. с
Речь только про приложения? или сайты тоже опасны? можно на телефонах тогда раздельным туннелированием по приложениям открывать в браузере Х только русское, а в другом браузере уже остальное (попимо настроенной маршрутизации в самом впн клиенте)
>для Windows нужная стратегия уже реализована в клиенте в v2rayN (пресет “Все, кроме РФ”)
А если использовать маршрутизацию все напрямую, кроме заблокированного? Я обычно это использую
И раз уж вы упомянули свой набор правил, то позвольте к вам @runetfreedom обратиться как простой пользователь по поводу вашего geoip.dat
С учетом того, что в например хорошем клиенте v2rayn невозможно выбрать другой источник геоип и геосайт данных кроме заданных (да, я знаю,что можно скачать просто с гита и положить в папку вручную и в настройках отменить автообновление геоданных,но это кривой костыль и не подходит для родственников и тд) и с учетом массовых блокировок\замедлений крупнейших хостеров и cdn , можно ли вас попросить добавить в ваш геоип файл категории, которые,например, есть у создателя проекта b4
https://github.com/DanielLavrushin/b4geoip
Спасибо!
отсутствие открытого исходного кода. Насколько я помню они это объясняли,что это сделано с целью безопасности функциональности зашифрованных ссылок подписок .Может я путаю.
Мега тупое оправдание по поводу безопасности, ведь они могли и могут опубликовать весь код просто без закрытого ключа и никаких проблем не было бы. Я уже не говорю о том, что этот ключ для расшифровки уже давно вытащили и есть даже сайты и боты для расшифровки.
их основной сайт находится в зоне su и зарегистрирован в российском регистраторе. Таким образом, владелец находится полностью под колпаком чекистов, если они того захотят
Если вы почему-то риск лишиться домена называете "под колпаком", то да.
Хотя, я не понимаю, почему наличие у меня домена, например, в зоне .com автоматически ставит меня под какой-то колпак западных спецслужб.
Насколько я помню они это объясняли,что это сделано с целью безопасности функциональности зашифрованных ссылок подписок
При этом настоящая ссылка из зашифрованной получается максимально тривиальным способом. Достаточно заснифить трафик с телефона при помощи mitmproxy и все. Я так спокойно тыбзил нужные ссылки (и они прекрасно работали в том же v2rayNG), что узнать какие конфиги используется для обхода БС.
Что насчёт клиента Throne?
Вопрос автору - это при запуске в режиме tun или socks5? Просто в режиме socks5 и имеется ввиду что запускается порт на локалхосте. Что тут исправлять если это так и должно работать? Человек который это включает должен понимать как оно работает.
А вот если это в режиме tun, тогда это реально опасно.
TUN режим в таких клиентах - это ничто иное как socks5 на локальном порту и интерфейс, созданный tun2socks, который и ходит в этот прокси.
Если сделать авторизацию в socks5, то использовать его смогут только приложения, в которых вы это специально настроили. Без авторизации - любое приложение (ему только надо порт найти, но это не сложно). Авторы клиентов авторизацию не сделали.
В теме в основном обсуждаются мобильные клиенты. А что для десктопа? Я например пользуюсь обходом блокировок только с десктопа, программой Throne в режиме прокси и отдельным браузером для заблокированных сайтов, настроенным на это прокси. В правилах на клиенте прописал на всякий случай запрет для geoip:ru, чисто интуитивно.
Наверное ещё имеет смысл удалить все российские приложения (хотя у меня почти их нет - приходит в голову только 2gis), и вообще тщательнее подходить к выбору приложений. Что ещё?
Автор просто нагнал воздуха.
В общем-то, не очень понятно, а в чем заключается уязвимость?
То что регулятор может узнать, о ужас, IP ваших проксей?
Хорошо, предлагаю ГРЧЦ/Минцифры следующий вариант: приложение Парковки, да любое российское приложение, будет смотреть - существует ли прокси интерфейс на iOS при использовании приложения; само приложение, в свою очередь, будет иметь эндпоинт который не метчится по ru правилам (TLD домена и айпи - зарубежные). Как ни крути, любое приложение будет по нему стучаться именно с вашего прокси. В прочем, даже смотреть, активен ли прокси интерфейс не обязательно.
Отказываться от огромного пула клиентов с яблоками - бред.
Существует еще несколько способов определить ip вашего прокси, которые в разы проще чем то, что описал автор.
Или то что можно узнать настройки аутбаунда?
И что потом? Регулятор будет пользоваться прокси? Будет ресселить ваши подписки?
Имея на руках publickey никакими митм'ами заниматься не получится без privatekey. Пользы от этой информации никакой.
Так что, вопрос к автору - и что с того?
Отказываться от огромного пула клиентов с яблоками - бред.
Когда автоматизируют и поставят на поток, выбора не останется - серверы будут жить часы или даже минуты.
В таком случае - откажитесь от использования браузеров вовсе. Ведь по методу описанному во 2 абзаце, на gosuslugi.ru тоже можно подставить эндпоинт, который не метчится никакими правилами.
Блокировка по отпечатку наиболее эффективная, собирать адреса долго и неточно, а ещё нужно системе доверять о том, какие данные отправило подконтрольное приложение, а это значит, что можно условый Макс заблокировать этим методом. Хотя возможно они так сделают, я не удивлюсь)
Не подумайте не правильно, но вот это вот "когда", "если" и т.д. уже слышали тысячу раз и каждые раз они обсираются что-то мало-мальски эффективное ставить на поток. Всем уже понятно, что это гонка вооружений, но Ваш посыл понятен: как говорится "Хорошим людям нужно выигрывать всегда, чтобы всё было хорошо, но стоит плохим людям выиграть всего 1 раз, и всё пойдет прахом".
Не подумайте не правильно, но вот это вот "когда", "если" и т.д. уже слышали тысячу раз и каждые раз они обсираются что-то мало-мальски эффективное ставить на поток.
Отлетающие по сибирским блокировкам вообще любые протоколы, отлетающие VLESS-ы с некорректным отпечатком браузера или что там было, отлетающий mtproto из-за кривой маскировки - это все "обсираются поставить на поток"? Я завидую вашему оптимизму. Сейчас начнут собирать IP проксей, потом введут за них административку (задним числом как обычно по длящемуся правонарушению) и поедут пативены, после этого любой ВПН станет просто золотым.
Отлетающие по сибирским блокировкам вообще любые протоколы, отлетающие VLESS-ы с некорректным отпечатком браузера или что там было, отлетающий mtproto из-за кривой маскировки
Частные случаи+буквально говорите про кривую маскировку. Вот и ответ. Сибирские блокировки очень редки на данный момент, особенно в западной части (их попросту нет у 99% хостеров. Плюс впн - это уже давно не про "решение из коробки", тут надо подтягивать и идти в ногу со временем (по себе знаю, приходится).
Про административку тоже байка, так как пользователей ну такое множество, что у них документооборота такого не существует (знаю из первых уст). Помню, так же и про мобилизацию пугали, а в итоге ни одного кейса даже админки не было задокументировано. Видите как, раз вы так говорите, значит их psyops по запугиванию и самоцензуре работает, а значит лишний раз потенциально убедит потенциального гражданина не заниматься обходами и идти на парковку
Нет, вы меня тоже не поймите неправильно: я даже свой VPN клиент навайбкодил для HTTPS, с WB и VK транспортами. Но градус шизы нарастает удивительными темпами, вам бы 5 лет назад просто не поверили бы, если бы вы сказали, что РКН сегодня успешно обнаруживает и блокирует. Если дальше такими темпами пойдем (мое хобби экстраполировать), то до конца года гайки докрутят уже. Списочки ВПН-то не просто так сейчас будут собирать.
Солидарен. Вместо того, чтобы самосовершенствоваться в хобби и работе и как-то духовно и физически я тоже вынужден практически ежедневно мониторить, что нового поднасрали мрази с верхов, чтобы оставаться свободным в своем легитимном конституционном, кстати, праве на свободу доступа к информации. Уж больно люблю быть свободным и не люблю думать так, как хотят наверху.
Но к сожалению, самый действенный способ - это голосовать собой и менять страну проживания, голосуя вкладом в экономику и рождаемостью (которые и так уже на дне, к сожалению или к счастью). Пока люди будут затерпливать и именно искать обходы, а не активно что-то делать с этой ситуацией, так и будем обитать в этом цифровом (а может скоро уже и не только) гулаге.
Как бы да :) Для того, чтобы вас спалить, достаточно посетить сайт палящего (ozon/wb/sber/max) а там, например, дёрнуть по js что-то, что должно быть заблокировано, например https://ipinfo.io/ip и всёго делов. Ну узнают IP адрес выходной ноды, дальше чего? Заблокируют его на границе? Ок, я в админке сменю адрес у этой виртуалки. Пфф, делов.
А такой вопрос - может ли подобным образом стучать чтото типа яндекс метрики и рекламы? В смысле у них есть отпечаток клиента и сопряжение с тем кто именно этот клиент и есть тысячи запросов и с относительно стабильных русских ip, и с десятка мест по всему земному шару. Они знают куда слать ответ с картинкой рекламного утюга. Что мешает сопрячь те же выходные ноды с вполне отечествеными ip тех же юзеров и посмотреть куда течет трафик с единственным рукопожатием в сутки зная что искать? Ресурсоемко, но грубо говоря вся информация у них уже есть и проанализировать ее (не полностью, а до первых результатов) вопрос суток.
Можно как угодно. А еще проще проверить, когда вы уже залогинены где-то (например на госуслугах). Тогда и матчить ничего особо не нужно. Смотря какая задача решается. Спалить факт юзания сплит впн? Легко. Вы даже и не заметите подвоха. Чтобы у вас не заблокировали выходную ноду на границе? Так сделайте каскад из трех нод: ру - зарубеж - зарубеж. И желательно в разных ДЦ/конторах. Тогда на блокировку выходной ноды вам будет наплевать.
А вариант с внесением подсети в бан? Или бан всех адресов этого ASN? Тоже пфф?
Я обычный юзер, и я так понял,с помощью этих впн могут получить доступ к устройству. Я пользовался happ и на пк, и на телефоне. Каким тогда впном пользоваться?
Я правильно понимаю по статье, что использование каскадной схемы здесь не спасает и сливается именно egress/exit hop ?
а что по поводу Amnesia?
Я ничего не понял особо, но возник вопрос: а если допустим будет какой-то портативный роутер между телефоном и интернетом, можно ли будет на нём как-то отсекать ненужный трафик, может быть там будет клиент наружу и сервер локальный, и так же на телефоне раздельный трафик, чтобы некоторые приложения напрямую пролетали мимо в большинстве своём
Так вроде IP прокси не так уж и трудно вытащить и без уязвимости... А ещё, если этим будет пользоваться государство, то так можно отправлять левые IP адреса и тогда можно будет заблокировать всё, если правильно всё это организовать.
После чтения новостей за последнюю неделю я решил не вводить ещё один контур тревоги в свою жизнь ("что они там ещё придумают?"), а сделал довольно простую вещь - снёс вообще все приложения отечественного бигтеха с основного телефона. Те, без которых совсем нельзя - поставил на вторую, девственно чистую от клуба весёлых и находчивых трубку. Ну и геоблок, конечно же, куда же без него.
Честно говоря, думаю, что затея с навешиванием обязанностей по блокировке на крупный бизнес в итоге не взлетит - у бизнеса цель зарабатывать деньги, а хотелки Минцифры только эти деньги отнимают (расходы на внедрение и поддержание системы, уход части клиентов итд итп). И плюс эти самые хотелки будут имплементировать на местах ровно те же самые программисты, которые тоже состоят в клубе весёлых и находчивых, потому что без нахождения в этом самом клубе свои рабочие обязанности невозможно исполнять с ноября 2025-го года (блокировка скачивания расширений вскода, хранилищ пакетов линукса, документации к различным пакетам и инструментам et cetera). Результат, думаю, предсказать несложно.
Честно говоря, думаю, что затея с навешиванием обязанностей по блокировке на крупный бизнес в итоге не взлетит
Как знать... зависит от бизнеса и его бенефициаров. Тот же VK Видео уже давно рекомендует отключить квн, если он на телефоне включен. Яндекс.Музыка тоже так делает. Что интересно, банковские приложения работают нормально. Во всяком случае я пробовал приложения Сбера и Совкомбанка: ни у одного претензий не было.
Но я тоже надеюсь на тихий заботаж этого дебилизма...
См. "Закон Яровой" и его реализацию. Бизнес его исполняет за свои деньги, перекладывая расходы на конечных потребителей. Не первый раз, не последний.
Если не путаю, Минцифры угрожает отзывом аккредитации тем компаниям, которые не будут сотрудничать. А это не только налоговые льготы, но и отсрочки от призыва. Т.е. если коротко и прямо: "или вы стучите на пользователей, или мы убьём ваших ключевых сотрудников".
Думаю, при такой постановке вопроса желающих отказываться найдётся немного. Как и желающих имитировать бурную деятельность по розыску пользователей VPN с риском для здоровья и жизни в случае разоблачения. И я, если честно, не могу их в этом винить.
свои рабочие обязанности невозможно исполнять с ноября 2025-го года
А власти по большому счёту уже не нужны программисты. Власти нужны дроноводы и немного хакеры. Т.е., читай - пули, которые можно выстрелить куда захочется, и тут же забыть.
Результат, думаю, предсказать несложно.
по-моему эту мантру пишут уже несколько лет
Правильно понимаю что если v2rayng работает mode: vpn, то данная уязвимость не релевантна?
Так физически смартфоны разделят. На официальный для этих приложух и личный. В целом то ничего криминального: ну не рассчитан средний телефон на безопасное содержание внутри себя шпионского ПО. И не будет рассчитан, потому что не существует в мире глобального спроса на эти функции. Нет тут таких продвинутых и удобных средств виртуализации, неймспейсов, полноценного фаервола, выдачи фальшивых данных вместо реальных на всякие системные вызовы. Все это где-то можно, но кусочками, не всегда, по чуть-чуть и в целом для гиков.
One UI 8.0, amneziavpn 4.8.14.5, без split-tunneling и с ним
Скрытый текст
Ну вообще на v2rayNG тоже существует возможность использовать пресет "Всë, кроме РФ", и очень давно.
Те кто умеют искать возможность включать подобное, всегда найдут)
А к sstp это применимо (и приложению sstp max)?
Многие пишут про способы решения этой проблемы с помощью рута или каких-то кастомных клиентов или настроек. Мой сервер используется не только мной, но еще и людьми, которые ради впн не станут так глубоко лезть ради устранения этой прорехи. Так что спасибо больше за статью. Мне удалось оперативно принять меры
Подозреваю, что happ (и все квн-сервисы, подключающие исключительно через него) - засланные казачки
Когда автор врёт с самого начала, то проверять есть правда дальше по тексту уже не интересно. Точнее можно быть уверенным, что он будет продолжать врать и дальше. Речь про это заявление "Минцифры открыто потребовало от аккредитованных российских IT компаний внедрения в свои продукты шпионских модулей, которые будут помогать блокировать персональные впн серверы "
Если автору эта тема интересна, то он прекрасно знает, что речь идёт о запрете работы указанных приложений через впн, а не "внедрении шпионских модулей"
Раз он врёт в мелочах, то соответственно ложь, нагнетание и передёргивание фактов это для автора естественный подход, и тем более очевидно что он будет врать и в остальном...
Прочитайте саму методичку (открывается только по ipv6), конкретно разделы 6 и 7,
Забей на него, там либо бот, либо клиника
Для вас русский язык не родной? Я вам повторю еще раз, рекомендации минцифры относятся к недопущению доступа к указанным ресурсам с использованием впн. Определение впн производится через штатный функционал андроид и айос. Там нет ничего про передачу каких либо данных в минцифры или тем более встраивание шипионских модулей.
Хотя я думаю вы это и сами прекрасно знаете и это была очередная попытка надурить читателей...
Волну разгоняют
Там нет ничего про передачу каких либо данных в минцифры или тем более встраивание шипионских модулей.
Верим? Верим. Это поэтому в коде Макса были пинги и connect 443 до main.telegram.org и mmg.whatsapp.net, пока за руку не поймали? ;)
Они УЖЕ встраивали модули. Еще даже до официальных документов, которые это рекомендуют.
Ну вот почитай и поверь в другое) https://dzen.ru/a/aXT4fnkHWAInpkzP
Буквально нет интереса читать отмазки воришек, которых поймали за руку. У них никогда не было причин стучаться на заблокированные сервисы и никогда не будет. Стучаться они туда могли только с одной целью, да еще и "в крысу", с удаленным управлением.
То есть тому что он там что-то передаёт ты веришь, а то что это просто проверка, то это тебе лапшу вешают?)
А я почитал, там «Основная причина: проверка качества интернета». Причины почему для этого нужно проверять «именно эти ресурсы» я оставлю читателю возможность решить самостоятельно
Так ты дальше прочитай, а не только заголовок)
Я прочитал её полностью и все ещё жду логического обоснования: «Зачем для проверки наличия интернета использовать во-первых сторонний сервис, а во-вторых - ещё и заведомо заблокированный?»
Если что-то крякает как утка, выглядит как утка…
P.S. Выводы там тоже интересные, с которыми у меня никак не получается согласиться
МАХ не отслеживает пользование VPN-сервисами [и] не отправляет запросы на серверы WhatsApp и Telegram. Используемые технические решения направлены на обеспечение высокого качества работы сервисов — в первую очередь звонков и уведомлений. К персональным данным или пользованию другими сервисами, включая VPN, они не имеют никакого отношения
Ответ пресс-службы? Прекрасно
не отправляет запросы на серверы WhatsApp и Telegram
Вот эта часть прямо противоречит твоей предыдущей ссылке. И обсуждаемой истории. Отправляет (вернее отправлял раньше) проверяя доступность в том числе заблокированных ресурсов. Проверить наличие интернета можно и иначе. И я не вижу никаких логичных причин, почему «это» направлено на
Используемые технические решения направлены на обеспечение высокого качества работы сервисов — в первую очередь звонков и уведомлений.
Зато это хорошо вписывает в анализ этого
пользованию другими сервисами, включая VPN
"Если google.com недоступен, а telegram.org доступен - значит интернет есть, но что-то блокируется. Если недоступно всё - у пользователя просто нет связи."
"Если у пользователя нет доступа к max.ru - значит нет связи. Или что-то её блокирует. Все равно нам это никак не поможет и мы об этом даже не узнаем, пока пользователь не окажется в сегменте работающего интернета. Ну и конечно же, он тоже никому не напишет."
Ну а если доступ есть - то что мешает общаться?
Вот MAX делает проверку и если нет интернета так и говорит тебе об этом. Да и что с того что там whatsapp и telegram, миллионы сервисов и приложений могут к ним обращаться, как к google и к яндексу и почему-то никто не думает что в интернете миллион приложений и что все остальные приложения, те же мессенджеры ничего никому не передают и не собирают и не делают запросы на другие сайты
Мы ходим по кругу
Вот MAX делает проверку и если нет интернета так и говорит тебе об этом.
Для этого не нужно проверять доступность мессенджеров-конкурентов.
Более того, о какой проверке интернете идёт речь, если сервис-конкурент уже сейчас «щемят» на грани полной блокировки? Какую полезную информацию о «наличии интернета» даст такая проверка и для чего её можно применить?
Да и что с того что там whatsapp и telegram
Не укладывается в логику => презумпция вины в отношении сервиса который навязывают силой. А зачем строить нелогичный дизайн - я не понимаю.
и что все остальные приложения
мы сейчас обсуждаем не их
Для этого не нужно проверять доступность мессенджеров-конкурентов.
Telegram (порт 7)
Порт TCP 7 используется для протокола Echo - простейшей проверки связи. Сервер просто отправляет обратно то, что получил. MAX не "отправляет данные в Telegram", а делает технический пинг: проверяет доступность сервера.
WhatsApp (порт 443) Соединение с mmg.whatsapp.net (сервер мультимедиа WhatsApp) через стандартный шифрованный порт. Приложение пытается установить рукопожатие, чтобы проверить прохождение трафика.
мы сейчас обсуждаем не их
То есть остальные могут делать запросы и собирать и сохранять информацию, ну понятно)
Я понимаю почему в РФ так легко разводить людей. Им что не скажешь, они счастливо всему верят.
Вы думаете, что статья, где это описана - вранье? Думаете, что если дернуть исследованную версию, то там в коде этого не будет?
Мы ведь на техническом ресурсе, вы ведь понимаете, что это сразу же вскрылось здесь же в комментах? Это "все не так однозначно" сойдет для комментов на каком-нибудь Пикабу, но здесь ведь люди и сами могут проверить.
Я понимаю то, что это никому не интересно. Те кто считают Макс инструментом антихриста будут верять во всё, что будет подтверждать эту теорию. В прослушку, геопозиционирование, видеофиксации и т.п. Те же, кто считает, что Макс это просто второсортный мессенджер с господдержкой, не будут убивать час свободного времени что бы увидеть в сниффере искомые адреса. Потому что их наличие вообще ничего не значит, как и их отсутствие.
Просто почему-то в одну сторону только верят, кто что первое сказал или тому что они хотят услышать)
Вторые сказали "ихтамнет", это не ответ:
МАХ не отправляет запросы на серверы WhatsApp и Telegram.
https://habr.com/ru/news/1006950/
Это буквально псиоп уровня The Party told you to reject the evidence of your eyes and ears. It was their final, most essential command.
В коде есть - они говорят нет. Не верьте своим глазам, они врут. Не знаю, на кого это расчет, кроме ура-патриотов.
Полностью читай, а не кусками "Используемые технические решения направлены на обеспечение высокого качества работы сервисов — в первую очередь звонков и уведомлений. К персональным данным или пользованию другими сервисами, включая VPN, они не имеют никакого отношения. Там также объяснили, что данные об IP-адресах нужны МАХ только для корректной работы звонков в нем, а запросы на серверы — это касается Google и Apple — для проверки доставки push-уведомлений, что необходимо в «сложных сетевых условиях и ограничениях мобильной связи в отдельных регионах». «Технология WebRTC требует внешний IP, чтобы построить прямой маршрут "телефон-телефон". Это стандарт для всех подобных сервисов», — заключили в пресс-службе МАХ."
Там также объяснили, что данные об IP-адресах нужны МАХ только для корректной работы звонков в нем, а запросы на серверы — это касается Google и Apple — для проверки доставки push-уведомлений, что необходимо в «сложных сетевых условиях и ограничениях мобильной связи в отдельных регионах».
Это не объяснили, это отписка уровня «вы все врёте».
Технология WebRTC требует внешний IP, чтобы построить прямой маршрут "телефон-телефон". Это стандарт для всех подобных сервисов
Для этого не нужно определять IP через внешние непонятные сервисы (которые сегодня есть, а завтра - умерли), есть STUN. И такие сервера вполне есть у ВК, да и в целом, поднять не проблема
Ну ты же не разработчик, чтобы знать как что они там реализуют, да и что дают проверка доступен ли whatsapp и telegram, миллион сайтов и приложений могут делать эти запросы, точно также как и к другим сервисам google, яндексу
Ну, тут мы как бы как раз на ресурсе разработчиков, которые прекрасно понимают как, что и зачем делают. И нет, не для проверки доступности сети)
Я, честно говоря, не очень понимаю, зачем Вы так ръяно бросаетесь защищать Макс и планируемые меры обнаружения ВПН, когда сами в этом не особо разбираетесь, судя по остальным комментариям. Разве что...
Ну то что это ресурс разработчиков это не говорит о том насколько и сколько здесь высокий их уровень.
Ну это ваше мнение и возможно других что это не для проверки сети.
Что в MAX такого чего нет в других мессенджерах, с чего решили что они не собирают, не сохраняют информация, что-то не проверяют, просто этого нет в коде или просто никто не смог найти?
Если не смогли найти, а найдут потом, ну значит так себе здесь разработчики.Смотрю здесь каждый второй мамкин хакер, но у всех начинается какая-то паника, что же делать.
Для получения внешних адресов используются TUN сервера. У MAX есть собственные TUN сервера.. И уж совсем нет смысла подключатся к разным локациям. В случае без VPN адреса будут одинаковые в разных локациях, в случае с VPN адреса будут разными. Это ни в чем не поможет WebRTC.
вот вот, будут блокировать сайт, приложение при обнаружении VPN и возможно передавать сведения для блокировки IP, а не внедрять шпионское ПО для слежки за пользователем, но все думают, что они занимают какую-то высокую должность что за ними будут следить, да и другой вопрос, зачем включать vpn и заходить на сайт который отлично работает без него)
Правильно ли я понимаю, что если наши приложки начнут встраивать в себя таких троянов, то они могу получить репорты в апп сторах/гугл плеях и просто вылететь от туда?
Думаете, это остановит РКН ?
Наши приложки уже примерно четыре года как принято устанавливать из рустора, ведь там есть все банки, госуслуги, госключи и так далее и тому подобное (и фотошопы, перезалитые хз кем) с доступом даже в режиме белых списков. Прокатит только с ios-устройствами, но там есть успешная практика а) носить трубки прямо в банк для установки приложений через кабель б) быстра-быстра накатывать очередное приложение-календарь с доступом к банковским счетам пока не зарепортили и не удалили, поторопитесь! Так что дырки будут и в этой экосистеме (меньше конечно, но и того хватит)
Нет информации по поводу GUI proxy client Furious от автора Loren Eteval? Пользуюсь этим клиентом достаточно давно.
У Throne тоже есть пресет "Bypass Russia", который позволяет напрямую подключаться к рф айпишникам
Интересно, Streisand это тоже касается?
Есть более общая архитектурная уэявимость VPN/прокси по своей концепции, это не средство обхода блокировок. По части детекта факта применения VPN/прокси имеет концептуальный патерн - специфичный маршрут трафика.
Цензуре нет необходимости проверять насколько реалистично Ваш, к примеру, "VLESS + Realiti" в дефолте проксирует Майкросовтовский сайт(в попытке найти едва уловимые различия) - цензуре достаточно сопоставить SNI в Вашем трафике, и пул адресов вашего хостинга в Нидерландах.
Тоже самое про другие VPN/прокси применяемые как средство обхода блокировок - прячем "мух"(специфику пакетов), а "слон"(крайне специфичный маршрут трафика) виден всем желающим. Его то в 2026 году в РФ и начали "рубить" и технически(падеж стелс-VPN/прокси по мере апгрейда ТСПУ), так и экономически - решением о заградительных тарифах на трансграничных трафик конечного пользователя.
Гораздо больший потенциал как показывают и теория и практика имеют “неоднокликовые” решения вроде Zapret(которым серверная часть не нужна и как следствие отсуствует слив трафика в специфичный маршрут). Причем трансграничный пиринг инфраструктурных гигантов тарифицируеться не как у пользователя, и если вы обратились фактически например к российским GGC, то ваш трафик для вашего провайдера внутрироссийский.
а если так - купить мини-компьютер домой, прикрутить к нему белый статический IP адрес, ставить ubuntu, на ней настроить себе openvpn сервер и кучу правил, к нему подключаться клиентом с своего смартфона, и уже со своего сервера коннект к нескольким зарубежным VLESS серверам и переключать их
А с амнезией что?
я сейчас сам проверил и у меня он не видит Xray API, но SOCKS5 нашел. У меня vless через 3x-ui панель и раздельное туннелирования приложений. Так что думаю у Amnezia все норм.
Версия приложения: 4.8.14.5
@runetfreedom
но SOCKS5 нашел
Так получается не норм, в этом и есть уязвимость всех, кроме happ
Socks5, а дальше вот: https://github.com/amnezia-vpn/amnezia-client/issues/2452
а как в v2rayNG V2rayN отреагировали на запрос? у них самая удобная кастомизация и настройка маршрутизации включая порты
А как на Андроиде с автоматизацией? По идее если сделать жёсткий пул доверенных приложений, а все остальные принудительно гасить когда включается тот же vray?
Сделал MR для v2rayNG с обязательной авторизацией, можете подождать пока его вольют либо я могу выложить скомпилированные apk файлы
Ну а в целом, переход на айось с андроида в текущих реалиях оправдан?
Почему-то все стараются изолировать маха в песочнице, откуда он успешно выползает.
А что если поступить наоборот - сделать в телефоне отдельное пространство с квн и инстаргаммом? То есть в открытую на телефоне нет никаких подозрительных приложений. Но если запустить на нём некую программу (виртуальную машину?), то в ней уже запустится квн и нужные приложения. При этом квн будет виден только избранным программам.
Ну а если, скажем нельзя сделать авторизацию, которую бы цепляли избранные для сплит туннеля приложения, то может лимит авторизаций на внутреннем socks прокси частично решил бы эту проблему ?
Ну вот условно в vless клиенте разрешается доступ для 3 каких-то приложений. И далее, на сокс выставляется лимит в 3 анонимных подключения. Избранные приложения тут же занимают этот лимит, потому что подключаются по понятной методике. А условный шпионский модуль, даже если и вычислит порт внутреннего socks сервера и подключится к нему - доступ в интернет не получит.
По-моему, проще сделать два раздельных физических устройства. Взять старый мобильник (думаю, у большинства дома хоть один да найдётся) и на него поставить броузер, YouTube и VLESS-клиент (для надёжности можно ещё перепрошить на Lineage OS), на втором — держать всё остальное в обычном режиме.
Выходные IP VPN-серверов легко палятся разными способами, от задержек до категории IP и паттернов трафика. Мне кто-то кинул ссылку на сайт proxydetect.live, там сразу десяток способов используется, и все на стороне сервера. С проверками на стороне клиента ещё проще.
Если РКН узнает выходной IP, то это не так страшно - у нормальных VPN он как правило отличается от входного, заблокировали выходной, входной останется доступным.
Проблема в другом, что возможность передачи и по VPN-каналу, и в открытую создаёт возможность определить входной адрес VPN. Шпионский модуль в каком-то приложении в открытую передаёт пакет - триггер для ТСПУ, который начинает сохранять сессии пользователя, а потом передаёт информацию, что в такое-то время с VPN этим пользователем было скачано определённое количество трафика. А потом сессии анализируются и смотрится, с какого адреса в это время трафик приходил.
А возможностей передать триггер и спалить таким образом входной адрес предостаточно, от сплита по адресам и приложениям (какой-нибудь ВК может открыть ссылку в браузере, а там VPN), до локальных прокси, локального DNS (Андроид открывает DNS на 127.0.0.1 при включении раздачи трафика), и бинда к конкретному сетевому интерфейсу.
Поможет только второе устройство (но большинство людей не готово на это пойти) и добавление поддержки прокси в приложения (причём это должен быть не простой прокси, как HTTP или SOCKS, а с маскировкой под HTTPS, наподобие MTProto в телеграме, или хотя бы с защитой всего канала по TLS). Разработчики большинства приложений забьют на это скорее всего.
Интересно, сколько минцифры занесли бабок, чтобы распространить эту информацию?
Но если на устройстве пользователя находится spyware (к примеру как часть какого-то государственного приложения), то ничего не мешает ему напрямую подключиться к этому xray socks5 proxy минуя VpnService и узнать внешний ip адрес и заблокировать его.
Ну и пусть блокируют - выходная нода в РФ не светится, а адрес входной они так не узнают!
Сейчас только совсем уж начинающие энтузиасты используют одит и тот же IP для входа и выхода.
Просто теперь это станет настоящий бизнес - порог входа повысится, а потенциальная аудитория - десятки миллионов человек.
Запрос к сервису определения IP, который зароутился в выходную ноду, отдаст ответ с IP выходной ноды. Все сервисы определения IP вы не поймаете правилами роутинга. Они просто поднимут свой на том же сервере в Польше за 5 евро в месяц, на голом IP, и пойдет он в вашу выходную ноду. :)
Сейчас только совсем уж начинающие энтузиасты используют одит и тот же IP для входа и выхода.
как представитель именно этого меньшинства, подскажите, вот, допустим, есть vps с 3x-ui, как мне понять что это мой кейс ? если в админке vps провайдера указан только один ipv4 по которому я и захожу через ssh ? если это так, то нужно понять, можно ли арендовать у провайдера ещё один ipv4 и как то его сделать "на выход" ? по каким ключевым словам поискать как это делается в 3x-ui ?
а адрес входной они так не узнают!
Spyware на устройстве не узнает, но с высокой вероятностью это можно сделать, анализируя трафик пользователя на стороне ТСПУ. Для этого ТСПУ должен знать паттерн поведения spyware и накопить достаточно трафика
Что меня удручает, этот текст поймут 0.001% населения.
Мне как физику, и вообще, человеку не связанному с интернет-технологиями непонятно как в обозримое время разобраться со всеми этими "заворачиваниями UDP", "входными-выходными IP", VLESS туда, xray сюда... Для полноценного цифрового сопротивления нужны простые инструменты и инструкции не содержащие жаргона, терминов, и т. п... типа "скачать вот это", "нажать вот это", "если не заработало - поменять вот это и повторить".
С кем общаться в ТГ если 99% народа выдавят в Макс? Народ ругается, но ставит, потому что нужен инструмент общения. Если не с кем поделиться ссылкой на YT? Когда мне надо отправить какое-то видео (обычно музыкальное) я стараюсь найти его на rutube, потому что на той стороне скорее всего YT не работает.
В перспективе, в противостоянии государства и граждан, я бы поставил на государство. Потому что проблемы негров, как известно, шерифа не волнуют, а у шерифа есть кольт и наверняка домашний интернет в обход опломбированных ящиков. (Кстати хорошо бы выяснить этот момент).
С другой стороны, вроде бы возможен некий гомеостаз, когда у 99% населения заблокировано всё, а на 1% плевать, но... учитывая легкую воспроизводимость цифровых решений и если будут реализованы удобные однокнопочные решения, то этот 1% может быстро превратиться в 99% и опять...
Суть в том, что государство имеет возможность сделать так, чтобы VPN сервисы не смогли стать массовыми. Для пользования VPN нужны будут меры предосторожности, чтобы не спалить IP, и хотя бы один неподготовленный пользователь может заблокировать доступ сразу для всех, поэтому удобных однокнопочных решений уже не получится. Технари смогут сделать обход блокировок для себя даже в таких условиях, но не смогут предлагать его простым пользователям.
В обсуждении issue в репе NekoBox упомянули (тов. sou1jacker) такой вариант (чтобы хотя бы сокс5 "завернуть").
Routes -> Create new -> Custom configuration
{
"inbound": ["mixed-in", "socks-in"],
"outbound": "block"
}POC при тесте реально упёрся в блок.
Хабр кстати буквально час назад отвалился вне России без прокси. Что-то опять шаманят, через Российский прокси работает
Может быть ребята из Happ вели себя так, потому что были очень недовольны тем фактом, что я вообще это нашел.
разработчик Happ в своей телеграм группе отказался считать это уязвимостью и отказался исправлять даже под давлением своей собственной аудитории
Happ все же согласились исправить обе уязвимости.
Знакомая ситуация. В моей практике разработчики сначала проигнорировали сообщение об уязвимости, отказавшись проверять пошаговую инструкцию. Мол, они по своему коду видят, что этого просто не может быть. Потом всё же проверили и тоже не подтвердилось. Позже выяснилось, что проверка была на другой версии (не той, о которой я писал). В прежней версии кода уязвимости не было т.к. была необходимая проверка. Но, потом её зачем-то убрали. Т.е. разработчики сами запутались: когда, что и зачем они проверяют. Фикс выкатили (только для мажорных веток). Но, при этом отказывались признавать это уязвимостью, пытались обжаловать CVE (неудачно). После чего сказали, что MITRE и я - ангажированные. Подробнее я писал в статье Как я зарегистрировал CVE и разозлил вендора.
Можно носить с собой коробочку с впн на портативном 4g-роутере с аккумулятором и раздачей вай-фай. Будет физическое отделение устройств.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Из-за критической уязвимости VLESS клиентов скоро все ваши VPN будут заблокированы