С уходом из гугл плея в рустор многие российские приложения, например банки, с удовольствием добавили себе в манифест пермишены, с которыми гугл им никогда бы не дал опубликоваться в официальном сторе, например "QUERY_ALL_PACKAGES", чтобы следить за тем какие приложения установлены на устройстве пользователя. Эта информация может быть реально необходима приложению примерно никогда, в 99% случаев она нужна различным SDK которые собирают информацию о пользователе, телеметрию, профили для аналитики, статистики, и т.д. и ничего полезного для самого пользователя не делают. Гугл не разрешает публиковать приложения с этим пермишеном в официальном гугл сторе, но вот, сразу же после выхода первой же версии приложения в русторе, от приложений российских банков в сеть полетели данные об установленных приложениях.
Абсолютно та же история с чтением СМС. Гугл, в принципе, даёт право публиковать подобные приложения в сторе, но проверяет их в ручном режиме и смотрит действительно ли им необходим доступ к всем СМС, если нет - разворачивает. Разумеется, никаким банкам никакой доступ к СМС не может быть нужен в принципе. "Нам нужны ОТР-коды из СМС" - не оправдание. Для этого, во-первых, есть специальное апи, которое позволяет получить код из СМС и при этом не даёт доступа к содержанию всех остальных сообщений, а во-вторых, ничего не случится если пользователю потребуется лишние 3 секунды, чтобы посмотреть пришедшее СМС самостоятельно. Стоит ли и говорить что перейдя в рустор банки сразу же себе эти пермишены добавили, и теперь они имеют полный доступ к всем вашим СМС и могут делать с ними всё что хотят - читать, анализировать, удалять, отправлять, и т.д.
Спасибо за интересную статью! Как сторонник селфхостинга ресурсов под свои нужды - горячо одобряю, особенно с учётом подорожания стоимости аренды серверов.
В комментариях уже многие высказались за использование VPNа на VPS сервере с белым адресом вместо ssh-туннеля, и я, пожалуй, тоже присоединюсь к этому. Я достаточно много пользовался ssh-туннелями, и пользуюсь ими до сих пор для доступа к каким-то приватным ресурсам, веб-мордам админок и т.д. - всего того что не должно торчать в сеть ни при каких обстоятельствах, но с ssh-туннелями также имел крайне негативный опыт с обрывами соединения и их стабильностью. Самый неприятный момент в том, что соединение может оборваться, а вот процесс ssh отвечающий за поддержание туннеля не завершится, и приходится самостоятельно руками его прибивать и стартовать новый. Да, autossh вроде как решает проблему, но сам по себе является костылём, использования которого хотелось бы избежать.
Небольшой оффтоп. У меня получилось достичь приемлемой, почти полностью беспроблемной стабильности ssh-туннелей с помощью добавления TCP-keepalive. Это генерирует небольшой постоянный трафик, но в нынешние времена это не должно быть проблемой. Для включения keepalive необходимо в конфигурацию подключения на стороне клиента, которая описывается в файле ~/.ssh/config внести соответствующие параметры. У меня типичная конфигурация подключения выглядит примерно так:
Host SSH_ALIAS
HostName 123.45.67.89
User user
Port 12345
IdentityFile ~/.ssh/id_ed25519_key_for_certain_server
IdentitiesOnly yes
TCPKeepAlive yes
ServerAliveInterval 15
ServerAliveCountMax 4
StrictHostKeyChecking yes
Также обязательно на стороне сервера в конфигурацию openssh в файле /etc/ssh/sshd_config добавить:
TCPKeepAlive yes
Не уверен что это будет работать с минималистичными реализациями вроде dropbear, но на полноценных компьютерах почти все пользуются openssh, так что думаю что проблем не возникнет.
Выскажу свои аргументы за схему с VPN на VPSке вместо туннелей:
Хорошо настроенный wireguard, с правильно выставленными значениями MTU на стороне клиента и сервера позволяет прокачивать трафик от VPS почти без потери скорости и всё буквально ограничится пропускной способностью вашего домашнего интернета. В своё время я экспериментировал с синхронизацией большого количества данных через rsync over ssh, и там у меня скорость резалась очень серьёзно. С wireguard таких проблем вообще не встретил. Допускаю что это мои руки не из плеч.
Если не обязательно использовать 80 и 443 порты, то можно полностью избежать использования nginx, и, соответственно, лишнего расхода ресурсов совсем сделав на стороне VPS порт форвардинг прямо на iptables. Трафик будет заворачиваться получателю в нужный tun-интерфейс напрямую правилами фаервола. Обрывы не страшны, т.к. даже если клиент отвалился, он переподключится, на VPS ничего специально делать не нужно, следить за восстановлением маршрутов тоже. Если у вас только один сервер за VPS и нет необходимости ничего крутить на ней самой, то можно и 80 и 443 порты полностью завернуть на ваш домашний сервер, и уже на нём, на стороне nginx, раскидывать подключения через mod_stream, ssl_preload по виртуалкам или контейнерам. Таким образом у вас будут и все ваши ресурсы, хоть их будет несколько десятков, на официальном 443 порту, и на все можно получить бесплатные сертификаты от letsencrypt или zerossl. При этом нагрузка на VPS и её ответственность будут абсолютно минимальны: прокидывать туда-сюда трафик и быть "лицом с белым адресом".
С ssh-туннелями всё это тоже сделать можно, но получается чуть больше потенциальных проблем, необходимости контроля и нагрузки на обе стороны
Ого, круто! Огромное спасибо за проделанную работу и интересную статью. Я видимо застрял где-то в прошлом, в котором собственные мобильные сети на SDR можно было развернуть только в виде 2G, а тут уже LTE полностью работает.
Кстати, а нельзя ли на операторской стороне создать для абонентов eSIM, если клиентский телефон их поддерживает?
Справедливо. Тогда был действительно период, когда для цензоров шифрование SNI, закрывающее один из самых удобных способов быстро и дёшево ограничить нужные соединения, было относительно в новинку и не носило массовый характер. Сегодня разумеется этот вопрос стоит более остро, цензоры тоже немного разобрались с тем как там оно технически устроено, помню какой-то сумрачный гений из госдумы даже предлагал полностью запретить и блокировать TLS 1.3.
Я имел ввиду то, что в те времена, когда eSNI отлично работал, а цензоры ещё за этот вопрос не взялись, Mozilla вдруг крайне неожиданно взяла и просто убрала его из браузера, хотя никакой технической необходимости в этом как будто бы не было. Я не сторонник конспирологии, но тогда это выглядело так, что их очень попросили это сделать
Помню, пользовался пару лет назад Firefox-ом c eSNI, в сочетании с dns-over-https это позволяло без VPN-ов посещать большинство заблокированных ресурсов (те что сами поддерживали TLS 1.3 и хостились за CDN). А потом в какой-то день Mozilla вдруг объявили что убирают поддержку eSNI из браузера и разом её выпилили, сказав что "это был не стандарт, а драфт, и вообще случайный эксперимент, и на замену ему сейчас придёт полноценный ECH". Но вот только несколько лет уже прошло, ECH так полноценно и не работает, а вот eSNI наоборот - реально работал, ещё несколько лет назад и реально решал проблему цензуры. Выводы, как говорится, делайте сами
Вероятно потому, что пока в Русторе не поддерживается разделение на сплиты. Приложения в Гугл Плей принимаются от разработчиков в формате app-bundle, а на устройство пользователя доставляются apk собранные конкретно под его устройство, т.е. имеющие ресурсы и код только под нужные архитектуру ЦПУ, плотность пикселей экрана, локализацию и т.д. Соответсвенно, без поддержки этих возможностей стор вынужден доставлять полный "толстый" апк, а те же нативные библиотеки под неиспользуемые архитектуры могут запросто весить несколько десятков мегабайт
Интереснейшая статья, настоящее техническое творчество. Спасибо!
Кстати, о проекте OpenIPC узнал не так давно и с огромным уважением отношусь к этой инициативе. Надеюсь однажды она разрастётся и станет чем-то вроде OpenWrt в мире WiFi-роутеров
Как человек участвовавший в проектировании и разработке карточных систем для общественного транспорта, я перевидал, перечитал документацию, прошивал и попробовал дюжину разных видов карт и никак не могу пройти мимо этой статьи.
Во-первых, как верно указали в комментариях, речь идёт об уязвимости почти 15-летней давности. Казалось бы, можно было сказать, что сейчас это уже никакого отношения к реальности не имеет, но нет. Подобные системы карт, так же как и карты в СКУДах, к сожалению, нередко завязываются на конкретное оборудование и экосистему, от которой потом крайне сложно отказаться и крайне болезненно уходить. Задачу свою она выполняет, а штучные "ломатели карт", как правило, не являются слишком большой проблемой, вот и тянутся эти проблемы из десятилетия в десятилетие, а во многих системах в ходу карты 15, 20, а то и 30 летней давности.
Корни этой проблемы тянутся из прошлого. К пониманию необходимости защиты карт, и отказа от использования принципа "security by obscurity" человечество пришло далеко не сразу, а карт и оборудования для них уже навыпускали. Компании спешили поскорее выкатить продукт на рынок, а не задумываться о том что в будущем у каждого студента будет в кармане проксмарк/флиппер/телефон с NFC который сможет взаимодействовать с их оборудованием, поэтому защиту в карты даже не закладывали.
Возьмите, например, те же СКУДы, где до сих пор массово используют emmarine карты, они вообще не предполагают никакой защиты и копируются в один тык на китайские болванки за пару десятков рублей. Плохо ли это с точки зрения безопасности? Однозначно! Такие системы используются в бизнес центрах, предприятиях, офисах компаний, и т.д. Но, как часто бывает, карта не является единственным фактором аутентификации, поэтому бизнес и государсто продолжают закрывать глаза на проблему и митигируют её сторонними способами. Например в московском транспорте отлично работает антифрод система, которая почти моментально заблокирует использование и оригинальной карты и дубликата. Ну а копировать карты с магнитной полосой - это вообще избиение младенцев. Разумеется данные на них никак не защищены.
Во-вторых, существуют современные карты, которые уже давно не болеют подобными детскими болезнями. Протокол общения с ними предполагает принудительную двухстороннюю аутентификацию, использование признаваемой надёжной во всём мире криптографии, шифрование и подпись каждого отправляемого apdu, причём расчёт криптограмм используемых в процессе, делегируется отдельным аппаратным модулям безопасности, так что никто, включая злоумышленника получившего контроль над клиентским оборудованием, или даже оборудованием оператора транспортной системы, или даже непосредственно самих турникетов не может получить доступа к ключам карты и несанкционированно записать туда что-то. Пока что с подобными картами существует проблема - несмотря на то что они уже очень много лет существуют на рынке, они мало распространены, хотя по себестоимости зачастую выходят даже дешевле карт тридцатилетней давности с нулевой защитой. Виной всему та же огромная "инертность" технологий в этой сфере, но их время обязательно придёт.
Также, поскольку я много работал с картами NXP mifare, могу сказать что проблема с crypto1 уже также давно решена. Этот алгоритм был своеобразной пробой пера среди массово используемых карт в плане аутентификации включающей в себя криптографию, выработки сессии и дальнейшее шифрование всех передаваемых данных. Да, реализован он был слабо, особенно в плане оборудования карты. Напомню, что внутри карты находится маленький компьютер размером с четверть рисового зёрнышка, и заставить его выполнять вычислительно "тяжёлые" криптографические операции - это далеко не то же самое что делать подобное на полноценном компьютере. Инженеры экономили ресурсы как могли и просчитались не столько на самой криптографии, сколько на невозможности организовать на подобных мощностях криптографически стойкий аппаратных ГПСЧ (это куда сложнее чем кажется на первый взгляд). Тем не менее, спустя некоторое время они выпустили новый тип карт, который после прошивки можно было перевести в режим работы, который полностью повторял интерфейс оригинальных mifare classic, но при этом уже имел стойкий ГПСЧ без вышеупомянутой уязвимости и дополнительные плюшки типа защиты от фаззинга команд и брутфорса ключа. Так что теперь даже эти карты возможно использовать относительно безопасно, хотя в современных реалиях они обладают уже пожалуй слишком короткой длинной ключа, и если вы прямо сейчас разрабатываете современную систему использующую карты, то лучше возьмите хотя бы mifare plus ev1 от тех же NXP, используйте их в максимально защищённом режиме и всё будет хорошо и правильно.
Ну а от гениев использующих открытый 7-байтный UID карты в качестве идентификатора любая безопасность бессильна, т.к. этот UID вообще-то нужен для чисто технических задач типа разрешения коллизии карт и т.д. и вообще может возвращаться случайный в некоторых случаях. Это НЕ прикладные данные и полагаться на них нельзя
Очень давно пользуюсь yt-dlp. Заготовил даже для себя разные шелл-алиасы чтобы быстро скачивать музыку или целые плейлисты с аудио и видео, которые, к сожалению, копирасты нередко с ютуба удаляют. Музыку вообще стараюсь всегда держать только у себя локально и никаких подписок, потому что с ними те же проблемы «недуступно у вас в регионе», «удалено по жалобе правообладателя» и т.д. В личном хранилище всё организовано так как мне нужно и по чьей-то прихоти удалено не будет.
К сожалению, тему с зарезанием скорости замечаю уже некоторое время, последнее время кажется она особенно активна. Пока что разработчики yt-dlp справляются. Низкий им поклон от меня
Интересуюсь тем, что происходит в Китае и довольно давно наблюдаю за тем как Китайские компании потихоньку захватили чуть ли не 90% мировой добычи редкоземельных металлов, которые в будущем, при сохранении текущих темпов роста производства сложных технологических товаров, могут стать дороже золота. Да и вообще Китай контролирует токую огромную долю критически важных мировых ресурсов в производстве, цепочках поставок, логистике, и не только. Всегда удивляло то, что люди по всему миру не бьют тревогу на этот счёт.
Телеметрия Майкрософта таки дошла до необходимости делать добровольно-принудительные полные бэкапы данных пользователей на анализ? Впрочем, учитывая то что они у себя на onedrive даже пытаются подбирать пароли к архивам и анализировать их содержимое - неудивительно
Спасибо огромное за статьи! Очень полезная и актуальная тема.
UPD: Кстати, было бы интересно если бы вы также смогли дать краткое описание и пример настройки функционала xray bridge для тех кому нужен функционал реверс прокси и прокидывания доступа из внешней сети к домашней
Спасибо за интересную статью. Тема крайне актуальная и важная для крупных проектов. Тоже пытался по разному подступиться к этой проблеме на рабочем проекте (550+ gradle модулей, 2М+ LOC), делал оптимизацию сборки, дружащие с местным DI стабы -impl модулей (разбиение на -api, -impl, -stub), но взрывного эффекта, это, конечно, всё равно не давало.
По моему опыту работы с Gradle, он очень плохо переносит большое количество модулей, каждый новый модуль добавляет существенный импакт на время сборки, даже если это просто -stub модуль с "пустыми" реализациями интерфейсов из -api, количество модулей, к сожалению не меняется, время конфигурации (существенное узкое место, особенно актуальное в "горячих" сборках) не уменьшается, configuration-cache не всегда адекватно работает из-за некоторых подключённых к сборке плагинов, а выигрыш на тасках сборки модуля есть, но не огромный.
Наиболее правильный подход - это конечно вот такие вот демо, к которым можно подключить только 1-2 разрабатываемых в настоящий момент модуля и не страдать с пересборкой всего проекта. Я, к сожалению, не осилил у себя декомпозировать сильно старые базовые модули, авторизацию и проход до главного экрана, которые в своё время были очень монолитными и завязанными друг на друга, а потом стало слишком больно и сложно их рефакторить.
Да, я пришёл примерно к такой же схеме. Верхнеуровнево - разные профили в firefox отправляют трафик в разные сетевые интерфейсы. Это позволяет добиться гарантированно точной выборочной маршрутизации, и по удобству меня вполне устраивает, но всё-таки немножко монструозное решение
Получается, вы заходите на нужный ресурс, тут же в админке видите весь список актуальных доменов ресурса, и потом вручную назначаете им всем правила что их нужно направлять в туннель?
По второму - я имел ввиду то, что у вас не возникает проблемы с "кэшем" dns? Т.е. когда адреса фактически сменились, но утилита занимающаяся маршрутизацией ещё отправляет в туннель старые адреса, в то время как фактически уже используются новые?
Добрый вечер. Интересный проект, спасибо за статью!
Подскажите пожалуйста, как именно происходит перенаправление выборочного трафика в туннель? Я очень хочу пользоваться чем-нибудь подобным, что решает задачу выборочного обхода блокировок, но это никогда не получается просто и удобно. Пытался запилить похожую систему себе самостоятельно, но именно в таком виде как у вас так и не смог достичь нужных результатов.
Я делал себе в своё время похожую систему основанную на policy based routing, настроил клиентское vpn-соединение, получил новый сетевой интерфейс в дополнение к основному, и теперь я вроде как могу управлять тем какой куда трафик отправлять с помощью ipset. Мне не нужны были обходы блокировок абсолютно всего что заблокировано, и всего списка antifilter, только некоторых сайтов. Основной загвоздкой было вот что - ipset управляет именно адресами, но не доменами и не сессиями в браузере, о браузерах, приложениях и других прикладных штуках он вообще ничего не знает. Постараюсь пояснить:
1) Допустим я открываю сайт, например условный инстаграм, вижу что он заблокирован. Я могу добавить домен инстаграма в список перенаправляемого в туннель, однако помимо основного домена там подгружается ещё целая куча всего, разные домены s3 хранилищ, какие-то укороченные домены, плюс всякие интеграции и т.д. Многие из них не входят в вайлдкард и не являются субдоменами основного домена. Поэтому приходится кропотливо забивать их руками, пока сайт не загрузится, после чего ещё забивать руками все вторичные домены, пока сайт не просто загрузится, но ещё и станет исправно работать. Некоторые ресурсы начинают сходить с ума когда часть контента загрузилась через WAN, а часть через TUN. Домены могут переименовываться, добавляться и удаляться. Постоянно обновлять этот список - кропотливая работа, которая со временем жутко надоедает. Я не знаю как можно удобно решить эту проблему. Вы с таким сталкивались? Как получилось решить эту проблему?
2) Далее, допустим я добавил правила для перенаправления всех доменов. Список для ipset и таблица маршрутизации составляется в момент запуска сервиса, для каждого из доменов резолвятся его IP адреса, после чего сервис запоминает их и начинает работать. Многие ресурсы крупных компаний хостятся через cloudflare (блок IPv4 адресов 104/8 и ещё несколько), там на ресурсах может часто происходить ротация IP адресов. Или другая ситуация round-robin отдал сначала один адрес, а через некоторое время другой. Получается что policy-based-routing запомнил определённые адреса, но спустя какое-то время запрос на тот же самый ресурс будет выполнен уже к фактически другому IP адресу, и не попадёт в туннель, а пойдёт в обычный WAN. Для того чтобы всё починить нужно вручную перезапустить сервис policy-based-routing, что, разумеется, неудобно и неприятно и опять требует отвлечения внимания от текущих задач. При этом наглухо зароутить в туннель весь блок 104/8 тоже нельзя, потому что на нём хостится очень много разных ресурсов, включая российские и они начнут сходить с ума и неадекватно работать, либо будет постоянно бросаться капча и т.д. В результате хотел выборочно обойти блокировки, а по итогу - только сам себе заблокировал доступ к целой горе незаблокированных ресурсов. У вас как-нибудь получилось решить такую проблему?
3) Допустим я хочу забить в ipset чисто IP адреса, без оглядки на домены. Т.е. получить все возможные адреса компании, строго забить их и забыть про все неудобства связанные с доменами. Тут опять облом, потому что получить полностью все адреса не всегда легко. Не везде эту информацию можно легко найти, не так просто их взять и собрать, плюс опять же проблема с блоками cloudflare - адреса могут постоянно плавать в них и ротироваться. Этот подход ещё менее надёжный чем с управлением доменами. Как всё-таки вы поступаете - работаете с доменами или с адресами?
В общем, я упёрся в то что именно при подобном подходе приходилось постоянно перезапускать сервис, постоянно обновлять руками списки доменов и адресов. Это было настолько неудобно, что пришлось перейти к совершено другой схеме, но я не теряю надежды что что-нибудь можно выжать и такого подхода как описан у вас, но вот обозначенные выше проблемы при его использовании пока что не смог решить. Буду признателен, если дадите пояснения на мои вопросы и дадите информации для размышления.
Мне однажды доводилось принимать участие в проведении бесплатного обучения по программированию. Компания, в которой я работал, проводила курсы по Java. Дело было в маленьком провинциальном городе, сама компания работала на московского заказчика. Количество разработчиков в городе, в те далёкие дохайповые времена, исчислялось, как мне кажется, несколькими десятками человек, очень были нужны новые люди. Компания объявила обучение, оно длилось несколько месяцев и было бесплатным, а основной целью для нас было - найти новых людей, которых можно взять в джуны. К нам поступило довольно много разных людей. Кто-то уже имел какой-то минимальный любительский опыт написания кода за плечами, кто-то был с местного градообразующего производственного предприятия и работал только поддерживая жуткий малопонятный софт написанный на делфи, кто-то вообще пришёл просто потому что бесплатно. Я в этом процессе выполнял роль "ментора" как бы это назвали на современных курсах - проверял домашние задания, помогал людям если у них были вопросы и т.д.
Так вот, по итогу обучения могу сказать следующее: из группы в несколько десятков человек большая часть в какой-то момент пропала, потому что у них были более важные дела. Какая-то часть не вывезла обучение, потому что по привычке пришла с майндсетом "я пришёл, учите меня" и проявляла ноль инициативы, им казалось что поскольку они отсидели занятия, этого достаточно чтобы их взяли на работу. Лично мне наиболее жалко было тех кто пришёл с градообразующего завода, они уже там много лет работали программистами и даже получали высокую по меркам города зарплату, но уровень их квалификации и деградация способности к обучению были таковы, что мне было сложно объяснить им самые основные концепции ООП - классы и т.д., и что писать весь код огромного проекта в одном файле - это не нормально. Взяли по итогу из всей группы одного талантливого парня самоучку, который имел хорошее техническое и аналитическое мышление, кое-что уже пробовал писать для себя сам ещё до поступления на обучение, был готов вкалывать и проявлял инициативу в обучении, самостоятельно изучал вещи, напрямую не затронутые в курсе.
После того случая, я некоторое время сидел и думал, как стоило правильно поступить? Довольно быстро я пришёл к очевидному выводу, что к люди не ценят бесплатные вещи. Однако что из этого следует дальше? Стоило ли сделать обучение платным, но за символическую цену? Это отсеет большинство "мимокрокодилов", однако не решает проблему с тем, что на обучение будут приходить люди, которые на самом деле не готовы проявлять какую-либо инициативу достаточную чтобы освоить достаточно большой объём знаний и навыков чтобы стать разработчиком. В обучение за "сотни тыщщ" я тоже не верю, всем известные продавцы курсов "войти-в-айти" занимаются отбиванием чудовищных размеров рекламных бюджетов, а людям они продают скорее идею изменить жизнь, чем обучение. Вся информация с подобных курсов легко ищется в интернете, а "структурирование информации", "подача", "менторство" и "помощь с трудоустройством" часто оказываются пустышкой или рекламной заманухой. Тоже так себе формат - безусловно он набивает кошельки владельцев этого бизнеса, но вот людям он несёт мало пользы, а если человеку нравится и хочется учить, передавать знания, да он ещё и готов это делать бесплатно, то разумеется он желает тратить время на тех, кому это по настоящему нужно и по настоящему принесёт пользу.
Ваш подход, кажется, очень неплох. Я даже не подумал о таком в своё время. Спасибо за статью!
С уходом из гугл плея в рустор многие российские приложения, например банки, с удовольствием добавили себе в манифест пермишены, с которыми гугл им никогда бы не дал опубликоваться в официальном сторе, например "QUERY_ALL_PACKAGES", чтобы следить за тем какие приложения установлены на устройстве пользователя. Эта информация может быть реально необходима приложению примерно никогда, в 99% случаев она нужна различным SDK которые собирают информацию о пользователе, телеметрию, профили для аналитики, статистики, и т.д. и ничего полезного для самого пользователя не делают. Гугл не разрешает публиковать приложения с этим пермишеном в официальном гугл сторе, но вот, сразу же после выхода первой же версии приложения в русторе, от приложений российских банков в сеть полетели данные об установленных приложениях.
Абсолютно та же история с чтением СМС. Гугл, в принципе, даёт право публиковать подобные приложения в сторе, но проверяет их в ручном режиме и смотрит действительно ли им необходим доступ к всем СМС, если нет - разворачивает. Разумеется, никаким банкам никакой доступ к СМС не может быть нужен в принципе. "Нам нужны ОТР-коды из СМС" - не оправдание. Для этого, во-первых, есть специальное апи, которое позволяет получить код из СМС и при этом не даёт доступа к содержанию всех остальных сообщений, а во-вторых, ничего не случится если пользователю потребуется лишние 3 секунды, чтобы посмотреть пришедшее СМС самостоятельно. Стоит ли и говорить что перейдя в рустор банки сразу же себе эти пермишены добавили, и теперь они имеют полный доступ к всем вашим СМС и могут делать с ними всё что хотят - читать, анализировать, удалять, отправлять, и т.д.
Спасибо за интересную статью! Как сторонник селфхостинга ресурсов под свои нужды - горячо одобряю, особенно с учётом подорожания стоимости аренды серверов.
В комментариях уже многие высказались за использование VPNа на VPS сервере с белым адресом вместо ssh-туннеля, и я, пожалуй, тоже присоединюсь к этому. Я достаточно много пользовался ssh-туннелями, и пользуюсь ими до сих пор для доступа к каким-то приватным ресурсам, веб-мордам админок и т.д. - всего того что не должно торчать в сеть ни при каких обстоятельствах, но с ssh-туннелями также имел крайне негативный опыт с обрывами соединения и их стабильностью. Самый неприятный момент в том, что соединение может оборваться, а вот процесс ssh отвечающий за поддержание туннеля не завершится, и приходится самостоятельно руками его прибивать и стартовать новый. Да, autossh вроде как решает проблему, но сам по себе является костылём, использования которого хотелось бы избежать.
Небольшой оффтоп. У меня получилось достичь приемлемой, почти полностью беспроблемной стабильности ssh-туннелей с помощью добавления TCP-keepalive. Это генерирует небольшой постоянный трафик, но в нынешние времена это не должно быть проблемой. Для включения keepalive необходимо в конфигурацию подключения на стороне клиента, которая описывается в файле ~/.ssh/config внести соответствующие параметры. У меня типичная конфигурация подключения выглядит примерно так:
Также обязательно на стороне сервера в конфигурацию openssh в файле /etc/ssh/sshd_config добавить:
Не уверен что это будет работать с минималистичными реализациями вроде dropbear, но на полноценных компьютерах почти все пользуются openssh, так что думаю что проблем не возникнет.
Выскажу свои аргументы за схему с VPN на VPSке вместо туннелей:
Хорошо настроенный wireguard, с правильно выставленными значениями MTU на стороне клиента и сервера позволяет прокачивать трафик от VPS почти без потери скорости и всё буквально ограничится пропускной способностью вашего домашнего интернета. В своё время я экспериментировал с синхронизацией большого количества данных через rsync over ssh, и там у меня скорость резалась очень серьёзно. С wireguard таких проблем вообще не встретил. Допускаю что это мои руки не из плеч.
Если не обязательно использовать 80 и 443 порты, то можно полностью избежать использования nginx, и, соответственно, лишнего расхода ресурсов совсем сделав на стороне VPS порт форвардинг прямо на iptables. Трафик будет заворачиваться получателю в нужный tun-интерфейс напрямую правилами фаервола. Обрывы не страшны, т.к. даже если клиент отвалился, он переподключится, на VPS ничего специально делать не нужно, следить за восстановлением маршрутов тоже. Если у вас только один сервер за VPS и нет необходимости ничего крутить на ней самой, то можно и 80 и 443 порты полностью завернуть на ваш домашний сервер, и уже на нём, на стороне nginx, раскидывать подключения через mod_stream, ssl_preload по виртуалкам или контейнерам. Таким образом у вас будут и все ваши ресурсы, хоть их будет несколько десятков, на официальном 443 порту, и на все можно получить бесплатные сертификаты от letsencrypt или zerossl. При этом нагрузка на VPS и её ответственность будут абсолютно минимальны: прокидывать туда-сюда трафик и быть "лицом с белым адресом".
С ssh-туннелями всё это тоже сделать можно, но получается чуть больше потенциальных проблем, необходимости контроля и нагрузки на обе стороны
Ого, круто! Огромное спасибо за проделанную работу и интересную статью. Я видимо застрял где-то в прошлом, в котором собственные мобильные сети на SDR можно было развернуть только в виде 2G, а тут уже LTE полностью работает.
Кстати, а нельзя ли на операторской стороне создать для абонентов eSIM, если клиентский телефон их поддерживает?
Справедливо. Тогда был действительно период, когда для цензоров шифрование SNI, закрывающее один из самых удобных способов быстро и дёшево ограничить нужные соединения, было относительно в новинку и не носило массовый характер. Сегодня разумеется этот вопрос стоит более остро, цензоры тоже немного разобрались с тем как там оно технически устроено, помню какой-то сумрачный гений из госдумы даже предлагал полностью запретить и блокировать TLS 1.3.
Я имел ввиду то, что в те времена, когда eSNI отлично работал, а цензоры ещё за этот вопрос не взялись, Mozilla вдруг крайне неожиданно взяла и просто убрала его из браузера, хотя никакой технической необходимости в этом как будто бы не было. Я не сторонник конспирологии, но тогда это выглядело так, что их очень попросили это сделать
Помню, пользовался пару лет назад Firefox-ом c eSNI, в сочетании с dns-over-https это позволяло без VPN-ов посещать большинство заблокированных ресурсов (те что сами поддерживали TLS 1.3 и хостились за CDN). А потом в какой-то день Mozilla вдруг объявили что убирают поддержку eSNI из браузера и разом её выпилили, сказав что "это был не стандарт, а драфт, и вообще случайный эксперимент, и на замену ему сейчас придёт полноценный ECH". Но вот только несколько лет уже прошло, ECH так полноценно и не работает, а вот eSNI наоборот - реально работал, ещё несколько лет назад и реально решал проблему цензуры. Выводы, как говорится, делайте сами
Ничего себе! Вот это чтиво! Люблю подобные низкоуровневые штуки. В них - настоящая красота программирования. Автору - огромное уважение
Вероятно потому, что пока в Русторе не поддерживается разделение на сплиты. Приложения в Гугл Плей принимаются от разработчиков в формате app-bundle, а на устройство пользователя доставляются apk собранные конкретно под его устройство, т.е. имеющие ресурсы и код только под нужные архитектуру ЦПУ, плотность пикселей экрана, локализацию и т.д. Соответсвенно, без поддержки этих возможностей стор вынужден доставлять полный "толстый" апк, а те же нативные библиотеки под неиспользуемые архитектуры могут запросто весить несколько десятков мегабайт
Интереснейшая статья, настоящее техническое творчество. Спасибо!
Кстати, о проекте OpenIPC узнал не так давно и с огромным уважением отношусь к этой инициативе. Надеюсь однажды она разрастётся и станет чем-то вроде OpenWrt в мире WiFi-роутеров
Как человек участвовавший в проектировании и разработке карточных систем для общественного транспорта, я перевидал, перечитал документацию, прошивал и попробовал дюжину разных видов карт и никак не могу пройти мимо этой статьи.
Во-первых, как верно указали в комментариях, речь идёт об уязвимости почти 15-летней давности. Казалось бы, можно было сказать, что сейчас это уже никакого отношения к реальности не имеет, но нет. Подобные системы карт, так же как и карты в СКУДах, к сожалению, нередко завязываются на конкретное оборудование и экосистему, от которой потом крайне сложно отказаться и крайне болезненно уходить. Задачу свою она выполняет, а штучные "ломатели карт", как правило, не являются слишком большой проблемой, вот и тянутся эти проблемы из десятилетия в десятилетие, а во многих системах в ходу карты 15, 20, а то и 30 летней давности.
Корни этой проблемы тянутся из прошлого. К пониманию необходимости защиты карт, и отказа от использования принципа "security by obscurity" человечество пришло далеко не сразу, а карт и оборудования для них уже навыпускали. Компании спешили поскорее выкатить продукт на рынок, а не задумываться о том что в будущем у каждого студента будет в кармане проксмарк/флиппер/телефон с NFC который сможет взаимодействовать с их оборудованием, поэтому защиту в карты даже не закладывали.
Возьмите, например, те же СКУДы, где до сих пор массово используют emmarine карты, они вообще не предполагают никакой защиты и копируются в один тык на китайские болванки за пару десятков рублей. Плохо ли это с точки зрения безопасности? Однозначно! Такие системы используются в бизнес центрах, предприятиях, офисах компаний, и т.д. Но, как часто бывает, карта не является единственным фактором аутентификации, поэтому бизнес и государсто продолжают закрывать глаза на проблему и митигируют её сторонними способами. Например в московском транспорте отлично работает антифрод система, которая почти моментально заблокирует использование и оригинальной карты и дубликата. Ну а копировать карты с магнитной полосой - это вообще избиение младенцев. Разумеется данные на них никак не защищены.
Во-вторых, существуют современные карты, которые уже давно не болеют подобными детскими болезнями. Протокол общения с ними предполагает принудительную двухстороннюю аутентификацию, использование признаваемой надёжной во всём мире криптографии, шифрование и подпись каждого отправляемого apdu, причём расчёт криптограмм используемых в процессе, делегируется отдельным аппаратным модулям безопасности, так что никто, включая злоумышленника получившего контроль над клиентским оборудованием, или даже оборудованием оператора транспортной системы, или даже непосредственно самих турникетов не может получить доступа к ключам карты и несанкционированно записать туда что-то. Пока что с подобными картами существует проблема - несмотря на то что они уже очень много лет существуют на рынке, они мало распространены, хотя по себестоимости зачастую выходят даже дешевле карт тридцатилетней давности с нулевой защитой. Виной всему та же огромная "инертность" технологий в этой сфере, но их время обязательно придёт.
Также, поскольку я много работал с картами NXP mifare, могу сказать что проблема с crypto1 уже также давно решена. Этот алгоритм был своеобразной пробой пера среди массово используемых карт в плане аутентификации включающей в себя криптографию, выработки сессии и дальнейшее шифрование всех передаваемых данных. Да, реализован он был слабо, особенно в плане оборудования карты. Напомню, что внутри карты находится маленький компьютер размером с четверть рисового зёрнышка, и заставить его выполнять вычислительно "тяжёлые" криптографические операции - это далеко не то же самое что делать подобное на полноценном компьютере. Инженеры экономили ресурсы как могли и просчитались не столько на самой криптографии, сколько на невозможности организовать на подобных мощностях криптографически стойкий аппаратных ГПСЧ (это куда сложнее чем кажется на первый взгляд). Тем не менее, спустя некоторое время они выпустили новый тип карт, который после прошивки можно было перевести в режим работы, который полностью повторял интерфейс оригинальных mifare classic, но при этом уже имел стойкий ГПСЧ без вышеупомянутой уязвимости и дополнительные плюшки типа защиты от фаззинга команд и брутфорса ключа. Так что теперь даже эти карты возможно использовать относительно безопасно, хотя в современных реалиях они обладают уже пожалуй слишком короткой длинной ключа, и если вы прямо сейчас разрабатываете современную систему использующую карты, то лучше возьмите хотя бы mifare plus ev1 от тех же NXP, используйте их в максимально защищённом режиме и всё будет хорошо и правильно.
Ну а от гениев использующих открытый 7-байтный UID карты в качестве идентификатора любая безопасность бессильна, т.к. этот UID вообще-то нужен для чисто технических задач типа разрешения коллизии карт и т.д. и вообще может возвращаться случайный в некоторых случаях. Это НЕ прикладные данные и полагаться на них нельзя
Очень давно пользуюсь yt-dlp. Заготовил даже для себя разные шелл-алиасы чтобы быстро скачивать музыку или целые плейлисты с аудио и видео, которые, к сожалению, копирасты нередко с ютуба удаляют. Музыку вообще стараюсь всегда держать только у себя локально и никаких подписок, потому что с ними те же проблемы «недуступно у вас в регионе», «удалено по жалобе правообладателя» и т.д. В личном хранилище всё организовано так как мне нужно и по чьей-то прихоти удалено не будет.
К сожалению, тему с зарезанием скорости замечаю уже некоторое время, последнее время кажется она особенно активна. Пока что разработчики yt-dlp справляются. Низкий им поклон от меня
Интересуюсь тем, что происходит в Китае и довольно давно наблюдаю за тем как Китайские компании потихоньку захватили чуть ли не 90% мировой добычи редкоземельных металлов, которые в будущем, при сохранении текущих темпов роста производства сложных технологических товаров, могут стать дороже золота. Да и вообще Китай контролирует токую огромную долю критически важных мировых ресурсов в производстве, цепочках поставок, логистике, и не только. Всегда удивляло то, что люди по всему миру не бьют тревогу на этот счёт.
Кажется, скоро до широких масс начнёт доходить
Телеметрия Майкрософта таки дошла до необходимости делать добровольно-принудительные полные бэкапы данных пользователей на анализ? Впрочем, учитывая то что они у себя на onedrive даже пытаются подбирать пароли к архивам и анализировать их содержимое - неудивительно
Спасибо огромное за статьи! Очень полезная и актуальная тема.
UPD: Кстати, было бы интересно если бы вы также смогли дать краткое описание и пример настройки функционала xray bridge для тех кому нужен функционал реверс прокси и прокидывания доступа из внешней сети к домашней
Очень круто! Спасибо за статью
Спасибо за интересную статью. Тема крайне актуальная и важная для крупных проектов. Тоже пытался по разному подступиться к этой проблеме на рабочем проекте (550+ gradle модулей, 2М+ LOC), делал оптимизацию сборки, дружащие с местным DI стабы -impl модулей (разбиение на -api, -impl, -stub), но взрывного эффекта, это, конечно, всё равно не давало.
По моему опыту работы с Gradle, он очень плохо переносит большое количество модулей, каждый новый модуль добавляет существенный импакт на время сборки, даже если это просто -stub модуль с "пустыми" реализациями интерфейсов из -api, количество модулей, к сожалению не меняется, время конфигурации (существенное узкое место, особенно актуальное в "горячих" сборках) не уменьшается, configuration-cache не всегда адекватно работает из-за некоторых подключённых к сборке плагинов, а выигрыш на тасках сборки модуля есть, но не огромный.
Наиболее правильный подход - это конечно вот такие вот демо, к которым можно подключить только 1-2 разрабатываемых в настоящий момент модуля и не страдать с пересборкой всего проекта. Я, к сожалению, не осилил у себя декомпозировать сильно старые базовые модули, авторизацию и проход до главного экрана, которые в своё время были очень монолитными и завязанными друг на друга, а потом стало слишком больно и сложно их рефакторить.
Спасибо ещё раз!
Добрый день, спасибо за ответ.
Да, я пришёл примерно к такой же схеме. Верхнеуровнево - разные профили в firefox отправляют трафик в разные сетевые интерфейсы. Это позволяет добиться гарантированно точной выборочной маршрутизации, и по удобству меня вполне устраивает, но всё-таки немножко монструозное решение
Спасибо за ответ.
Получается, вы заходите на нужный ресурс, тут же в админке видите весь список актуальных доменов ресурса, и потом вручную назначаете им всем правила что их нужно направлять в туннель?
По второму - я имел ввиду то, что у вас не возникает проблемы с "кэшем" dns? Т.е. когда адреса фактически сменились, но утилита занимающаяся маршрутизацией ещё отправляет в туннель старые адреса, в то время как фактически уже используются новые?
Добрый вечер. Интересный проект, спасибо за статью!
Подскажите пожалуйста, как именно происходит перенаправление выборочного трафика в туннель? Я очень хочу пользоваться чем-нибудь подобным, что решает задачу выборочного обхода блокировок, но это никогда не получается просто и удобно. Пытался запилить похожую систему себе самостоятельно, но именно в таком виде как у вас так и не смог достичь нужных результатов.
Я делал себе в своё время похожую систему основанную на policy based routing, настроил клиентское vpn-соединение, получил новый сетевой интерфейс в дополнение к основному, и теперь я вроде как могу управлять тем какой куда трафик отправлять с помощью ipset. Мне не нужны были обходы блокировок абсолютно всего что заблокировано, и всего списка antifilter, только некоторых сайтов. Основной загвоздкой было вот что - ipset управляет именно адресами, но не доменами и не сессиями в браузере, о браузерах, приложениях и других прикладных штуках он вообще ничего не знает. Постараюсь пояснить:
1) Допустим я открываю сайт, например условный инстаграм, вижу что он заблокирован. Я могу добавить домен инстаграма в список перенаправляемого в туннель, однако помимо основного домена там подгружается ещё целая куча всего, разные домены s3 хранилищ, какие-то укороченные домены, плюс всякие интеграции и т.д. Многие из них не входят в вайлдкард и не являются субдоменами основного домена. Поэтому приходится кропотливо забивать их руками, пока сайт не загрузится, после чего ещё забивать руками все вторичные домены, пока сайт не просто загрузится, но ещё и станет исправно работать. Некоторые ресурсы начинают сходить с ума когда часть контента загрузилась через WAN, а часть через TUN. Домены могут переименовываться, добавляться и удаляться. Постоянно обновлять этот список - кропотливая работа, которая со временем жутко надоедает. Я не знаю как можно удобно решить эту проблему. Вы с таким сталкивались? Как получилось решить эту проблему?
2) Далее, допустим я добавил правила для перенаправления всех доменов. Список для ipset и таблица маршрутизации составляется в момент запуска сервиса, для каждого из доменов резолвятся его IP адреса, после чего сервис запоминает их и начинает работать. Многие ресурсы крупных компаний хостятся через cloudflare (блок IPv4 адресов 104/8 и ещё несколько), там на ресурсах может часто происходить ротация IP адресов. Или другая ситуация round-robin отдал сначала один адрес, а через некоторое время другой. Получается что policy-based-routing запомнил определённые адреса, но спустя какое-то время запрос на тот же самый ресурс будет выполнен уже к фактически другому IP адресу, и не попадёт в туннель, а пойдёт в обычный WAN. Для того чтобы всё починить нужно вручную перезапустить сервис policy-based-routing, что, разумеется, неудобно и неприятно и опять требует отвлечения внимания от текущих задач. При этом наглухо зароутить в туннель весь блок 104/8 тоже нельзя, потому что на нём хостится очень много разных ресурсов, включая российские и они начнут сходить с ума и неадекватно работать, либо будет постоянно бросаться капча и т.д. В результате хотел выборочно обойти блокировки, а по итогу - только сам себе заблокировал доступ к целой горе незаблокированных ресурсов. У вас как-нибудь получилось решить такую проблему?
3) Допустим я хочу забить в ipset чисто IP адреса, без оглядки на домены. Т.е. получить все возможные адреса компании, строго забить их и забыть про все неудобства связанные с доменами. Тут опять облом, потому что получить полностью все адреса не всегда легко. Не везде эту информацию можно легко найти, не так просто их взять и собрать, плюс опять же проблема с блоками cloudflare - адреса могут постоянно плавать в них и ротироваться. Этот подход ещё менее надёжный чем с управлением доменами. Как всё-таки вы поступаете - работаете с доменами или с адресами?
В общем, я упёрся в то что именно при подобном подходе приходилось постоянно перезапускать сервис, постоянно обновлять руками списки доменов и адресов. Это было настолько неудобно, что пришлось перейти к совершено другой схеме, но я не теряю надежды что что-нибудь можно выжать и такого подхода как описан у вас, но вот обозначенные выше проблемы при его использовании пока что не смог решить. Буду признателен, если дадите пояснения на мои вопросы и дадите информации для размышления.
Спасибо!
О, автору моё уважение! Очень интересный подход.
Мне однажды доводилось принимать участие в проведении бесплатного обучения по программированию. Компания, в которой я работал, проводила курсы по Java. Дело было в маленьком провинциальном городе, сама компания работала на московского заказчика. Количество разработчиков в городе, в те далёкие дохайповые времена, исчислялось, как мне кажется, несколькими десятками человек, очень были нужны новые люди. Компания объявила обучение, оно длилось несколько месяцев и было бесплатным, а основной целью для нас было - найти новых людей, которых можно взять в джуны. К нам поступило довольно много разных людей. Кто-то уже имел какой-то минимальный любительский опыт написания кода за плечами, кто-то был с местного градообразующего производственного предприятия и работал только поддерживая жуткий малопонятный софт написанный на делфи, кто-то вообще пришёл просто потому что бесплатно. Я в этом процессе выполнял роль "ментора" как бы это назвали на современных курсах - проверял домашние задания, помогал людям если у них были вопросы и т.д.
Так вот, по итогу обучения могу сказать следующее: из группы в несколько десятков человек большая часть в какой-то момент пропала, потому что у них были более важные дела. Какая-то часть не вывезла обучение, потому что по привычке пришла с майндсетом "я пришёл, учите меня" и проявляла ноль инициативы, им казалось что поскольку они отсидели занятия, этого достаточно чтобы их взяли на работу. Лично мне наиболее жалко было тех кто пришёл с градообразующего завода, они уже там много лет работали программистами и даже получали высокую по меркам города зарплату, но уровень их квалификации и деградация способности к обучению были таковы, что мне было сложно объяснить им самые основные концепции ООП - классы и т.д., и что писать весь код огромного проекта в одном файле - это не нормально. Взяли по итогу из всей группы одного талантливого парня самоучку, который имел хорошее техническое и аналитическое мышление, кое-что уже пробовал писать для себя сам ещё до поступления на обучение, был готов вкалывать и проявлял инициативу в обучении, самостоятельно изучал вещи, напрямую не затронутые в курсе.
После того случая, я некоторое время сидел и думал, как стоило правильно поступить? Довольно быстро я пришёл к очевидному выводу, что к люди не ценят бесплатные вещи. Однако что из этого следует дальше? Стоило ли сделать обучение платным, но за символическую цену? Это отсеет большинство "мимокрокодилов", однако не решает проблему с тем, что на обучение будут приходить люди, которые на самом деле не готовы проявлять какую-либо инициативу достаточную чтобы освоить достаточно большой объём знаний и навыков чтобы стать разработчиком. В обучение за "сотни тыщщ" я тоже не верю, всем известные продавцы курсов "войти-в-айти" занимаются отбиванием чудовищных размеров рекламных бюджетов, а людям они продают скорее идею изменить жизнь, чем обучение. Вся информация с подобных курсов легко ищется в интернете, а "структурирование информации", "подача", "менторство" и "помощь с трудоустройством" часто оказываются пустышкой или рекламной заманухой. Тоже так себе формат - безусловно он набивает кошельки владельцев этого бизнеса, но вот людям он несёт мало пользы, а если человеку нравится и хочется учить, передавать знания, да он ещё и готов это делать бесплатно, то разумеется он желает тратить время на тех, кому это по настоящему нужно и по настоящему принесёт пользу.
Ваш подход, кажется, очень неплох. Я даже не подумал о таком в своё время. Спасибо за статью!
Террористы с удовольствием используют одобренный товарищем майором ТамТам и не парятся