Выглядит как отличное коробочное решение. Для тех кто живёт за городом и не хочет разбираться в настройке Микротиков или OpenWrt — самое то. За разъемы для антенн — отдельный респект. У меня на даче стоит сборка из роутера на OpenWrt и Huawei e3372h-153, до вышки ~11 км. Без направленной антенны нет никаких шансов поймать адекватный сигнал.
Подскажите пожалуйста, есть ли в прошивке Кинетиков возможность отключать ненужные 2G, ненужные бэнды, фиксироваться на конкретной вышке или бэнде? Есть ли интерфейс для точной настройки антенны с отображением RSRP, SINR и т.д.?
Мне кажется, у значительного количества людей подобное техническое творчество и тяга к экспериментам в детстве привели к карьере в технологической сфере. Я лично очень благодарен отцу за то что в детстве познакомился и с разными приборами, и с пайкой, и с ZX spectrum. Если бы не это, моя жизнь могла бы сложиться совсем по другому
Спасибо за статью. Интересный и кажется очень хороший подход для массового использования, даже технически неподкованными людьми. Нужный проект, и думаю что с ростом госрегулирования он станет популярным. Желаю вам успехов!
Могу предположить что сейчас большинство частных VPN серверов как раз работают через подход с контейнерами docker и настройкой через ansible, но вот чтобы это делалось прямо через мобильное приложение — такого я ещё ни разу не видел.
Хотел уточнить пару моментов:
Можно ли прописать кастомные маршруты? Дело в том, что если ресурс хостится на каком-нибудь Cloudflare, а по моим наблюдениям большинство ресурсов сейчас находятся у подобных провайдеров, то адреса на который указывают его домены могут часто меняться в пределах доступных провайдеру блоков. Я пользуюсь похожим на ваш подходом, только у меня домашний роутер на OpenWrt автоматически маршрутизирует трафик на определённые адреса (которые заблокированы в РФ или о посещении которых я не желаю докладывать российскому интернет провайдеру) в VPN-туннель. Поскольку адреса постоянно переключаются, то нужно каждый раз их подтягивать заново, а это неудобно. Лично я в какой-то момент просто решил отправлять в туннель всё что идёт в клаудфлэровские блоки 104.0.0.0/8 и 172.64.0.0/13. Есть ли подобная возможность в вашем клиенте?
Происходит ли перенастройка sshd на отключение авторизации по паролю и включения авторизации по ключам при первичном запуске ansible? В чистой системе нет средств которые из коробки ограничивают брутфорс ssh, а злоумышленники и боты из братского Китая не дремлют. Как бы не вышло так что на всех инстансах амнезии будет видимый порт ssh да ещё и с пользователем root и входом по паролю, и на них обрушится поток ненужного трафика, а то и что похуже может случиться. Было бы неплохо если бы были хотя бы какие-то контрмеры от подобного. Перекинуть sshd на какой-нибудь нестандартный порт, ограничить входные адреса, сделать авторизацию по ключам и т.д.
Скорее пожелание — как насчёт добавить ещё некоторые протоколы, например Wireguard? Да, он легко обнаруживатся DPI, но пока что, к счастью, VPN у нас не по белым спискам, и я не видел чтобы Wireguard где-то специально ограничивался. Всё таки скорость работы — штука важная, а Wireguard сильно шустрее и менее затратен по ресурсам для клиента чем тот же OpenVPN, что как раз в ежедневном использовании даст куда более приятный опыт пользователю.
Отдельное спасибо за то что описываете реальные сценарии использования туннелей, в отличие от продаванов платных VPN сервисов которые поголовно обещают людям чёрт знает что, и анонимность, и масочку Гая Фокса в придачу
Кажется, что большая часть описанного в статье вполне попадает в «общую» категорию, не касающуюся конкретно Linux. Слабые пароли и несекурный конфиг сервисов может быть и на win-серверах. Хотя с общим посылом статьи сложно не согласиться, нужно ответственно относиться к безопасности и серверов и рабочих машин, не полагаясь только на механизмы ОС поставляемые из коробки. Linux — не волшебная таблетка, я бы даже скорее сказал что допустить ошибку в конфигурации рабочей машины на нём куда проще чем в той же винде или макоси, где о простых способах «выстрелить себе в ногу» за среднего пользователя подумал производитель. С другой стороны виндовс и макось часто не могут предоставить должной гибкости и возможностей в настройке рабочей машины для себя и своих нужд, в том числе и с точки зрения безопасности, а ИМХО именно за гибкость и возможности люди и выбирают Linux.
Если бы я писал статью на эту тему, то скорее развил бы мысль в сторону того что немалое число уязвимостей ОС на базе ядра Linux растёт из монолитной структуры самого ядра. Это создаёт некоторые проблемы Linux, которые как правило вообще не будут касаться других ядер ОС.
Немного оффтоп, невозможность отключить рекламные пуши подобным образом — один из очень напрягающих моментов в iOS. Некоторые операторы злоупотребляют спамом, а появление попапа от SIM-карты вызывает вейклок устройства до момента закрытия диалога. Это приводит к ситуациям когда ты зарядил заранее телефон, потому что он тебе нужен полностью заряженным и ты очень рассчитываешь на это. А потом спустя полдня ты достаёшь его из кармана, видишь радостное сообщение от ОПСОСа «юмор и весёлые приколы ежедневно, отправь СМС… всего 4 р/день!» и заряд 15%, потому что телефон экран был включен последние 5 часов, а телефон не уходил в сон, нагрелся и разрядился.
Такая уже есть. Неплохая штука. Однако при её использовании ожидаемо теряются возможности интеграции с приложениями звонилки, СМС и т.д. Пользоваться можно, но всё таки не на 100% удобно
На самом деле, мне кажется, такой подход не решает проблему вообще никак. Мусор в списке контактов не сильно «запутывает» систему, она сможет построить социальный граф и узнать связи между людьми на основе настоящих данных (именно эту цель она и преследует), а фейковые ей мешать вообще не будут, отсеять их можно просто сделав выборку по контактам с более чем 0 связями с другими людьми. Получается что у пользователя подобного приложения будет только ложное ощущение того что он «нагнул систему», хотя на деле всё осталось как было.
Как уже упомянуло несколько человек, самым правильным решением было бы воспользоваться XPrivacyLua через который можно выбранным приложениям разрешить доступ к настоящему списку контактов, звонков, да и другим штукам типа железных идентификаторов устройства, а другим возвращать пустые списки, фейки или нуллы. К сожалению, этот подход требует установленного xposed фреймворка, что не на всех устройствах возможно, и не все захотят подобное себе устанавливать.
Я, устав от спама, завёл себе некоторое время назад не привязанную ко мне сим-карту, завёл под неё гугл-аккаунт, взял свой «рабочий» смартфон с установленным xposed фреймворком, XPrivacyLua и ещё некоторыми свистелками, делающими сбор информации с девайса близким к невозможному. На нём я регистрируюсь во всяких мутных сервисах, ставлю туда приложения которые хотят много обо мне знать, типа программ лояльности, приложений сетей магазинов и прочий шлак. Очень удобный подход, но не для всех
Надо же. Всё таки смогли договориться внести карты «Мир» в Apple/Google pay. Молодцы, это точно поспособствует популяризации платёжной системы.
Если я правильно понимаю, на android карты «Мир» сейчас работают через обычный userspace HCE-сервис из приложения платёжной системы, а на ios не работали совсем из-за отсутствия API эмуляции тэгов. Теперь всё будет работать «из системы»
О, интересно, спасибо. Не пробовал так делать сам, но очень напоминает историю с тем как на разных POS-терминалах на базе windows вытаскивают служебные системные окна, например справку о системе, и т.д., а уже через них получают доступ дальше, сворачивают рабочее приложение, запускают paint, рисуют в нём что-нибудь хулиганское
Решение — просто делать проверки через шелл (можно при желании заавтоматизировать всё через python и subprocess). Загружаемся в TWRP. Образ TWRP содержит многие утилиты для работы с файловыми системами, сбора информации о системе, и т.д. Среди них есть и утилиты для подсчёта хэшей, воспользуемся sha256sum:
Насчёт антивирусов — даже не знаю имеет ли это смысл, и что можно посоветовать. Я попробовал прогнать тесты на нескольких популярных антивирусных продуктах при установленном бэкдоре, и похоже что большинство из них не пытается прогонять сложные проверки на то что система на устройстве была скомпрометирована, или хотя бы просто попробовать прогнать проверку SafetyNet. Я не пытался глубоко анализировать механику работы антивирусов на android. Судя по всему они пытаются получать информацию о пакетах и искать подозрительные данные в манифестах или что-то вроде того. В любом случае, если устройство не предполагает использования аппаратного ТЕЕ в процессе аттестации (такое кажется есть только на пикселях), то на скомпрометированной системе с помощью рантайм-хуков злоумышленник сможет при необходимости обмануть любую проверку, поэтому наверное никто очень сильно и не пытается
Ну, кажется выглядит всё правильно. Гугл запретил huawei пользоваться ОС с гугл сервисами, но он не имеет права запретить пользоваться AOSP — это открытый проект.
Тут несколько сбивает с толку легальный статус android. Сама операционная система — под свободной лицензией, но google apps — интеллектуальная собственность гугла, пользоваться которой он даёт производителям устройств по лицензии. Эти части — совершенно отдельные сущности, просто мы привыкли что они находятся на наших устройствах одновременно. Названия с android в системе относятся как раз к операционной системе, так что всё в порядке. Просто huawei пришлось переизобрести google apps со своим бэкендом, молодцы кстати, давно пора чтобы гаппсам уже появилась какая-то совместимая с ОС альтернатива.
Куда печальнее то что пиарщики huawei наобещали больше чем то что в итоге получилось. Я вот прям помню что они говорили и про собственное ядро, и про новую организацию самой ОС, и т д
Этот механизм называется Factory Reset Protection или просто FRP. Данные FRP хранятся в отдельном разделе на флеш-памяти, поэтому переживают переустановку. По сути, это защита от угона, чтобы предотвратить ситуации с кражей и перепродажей устройства. Наверное на разлоченном устройстве это можно побороть, на закрытом — не получится.
В андроидах установка рута практически всегда идёт через разблокировку загрузчика. Производитель закладывает возможность устанавливать что-то помимо доверенной системы. Вот в iOS приходится прибегать по сути к взлому через эксплоит. Насколько я знаю, пока что это менять не планируется. Новые девайсы на 11 андроиде также возможность разблокировки предоставляют
Это точно значит что смартфон не перезагружали, а атака не может быть проведена без перезагрузок. Получается да, если не требует ввода пароля и остался включённым, значит точно не пытались атаковать
Хм, может я недопонял вопрос. Тот сценарий который я описал требует перезагрузки устройства, сначала в fastboot, потом в рековери, потом снова в систему. Без перезагрузок ничего сделать не получится, поэтому не выключая смартфон атаку не провести
Спасибо большое. Главный минус — имея рут доступ можно изменить что-нибудь в системном разделе и вызвать срабатывание dm-verity, что соответственно приведёт к невозможности загрузиться. Это легко сделать неосторожным изменение hosts файла например. Тем не менее вполне можно использовать afwall, т.к. всё для чего ему нужен root — это вызов бинарника iptables. Я бы сам лично не стал бы пользоваться root доступом в системе с заблокированным загрузчиком просто чтобы случайно не наломать дров.
П.С: не только в нём, мне нужно сесть и поправить немало орфографических ошибок
Я не наблюдал сам за работой FDE, поэтому не могу быть уверен на 100% что именно он шифрует внутри. Из того что я прочитал, полагаю что он шифрует раздел userdata целиком, но system и boot также не трогаются, поэтому нам также стоит следить за хэшами в случае временного попадания устройства в чужие руки.
Второе — не получится, потому что шифрование завязано на ТЕЕ. Мы можем склонировать userdata раздел, но тогда брутфорсить нам полное пространство ключей — 2^128. Скорее уж получится локально пробовать подбирать пины, многие люди снижают энтропию на несколько порядков используя части даты рождения или телефонных номеров своих или близких родственников, может повезти
Спасибо за вдумчивый комментарий. Всё прям в точку. Практически нечего добавить.
На мой взгляд немало проблем растёт из того, что всё касающееся безопасности очень сильно завязано на пропиетарные компоненты, и даже при желании не может быть исправлено сообществом. Либо проблемы заложены в изначальном дизайне системы и пытаться их исправить ничего не сломав во взаимодействии фреймворка и приложений близко к невозможному (пермишены, подход «всё или ничего»). В итоге, сообщество кастомщиков и радо бы усилить механизмы безопасности, но не может.
Тем не менее, там где это возможно гугл и вендоры стараются подкручивать гайки и это хорошо.
Выглядит как отличное коробочное решение. Для тех кто живёт за городом и не хочет разбираться в настройке Микротиков или OpenWrt — самое то. За разъемы для антенн — отдельный респект. У меня на даче стоит сборка из роутера на OpenWrt и Huawei e3372h-153, до вышки ~11 км. Без направленной антенны нет никаких шансов поймать адекватный сигнал.
Подскажите пожалуйста, есть ли в прошивке Кинетиков возможность отключать ненужные 2G, ненужные бэнды, фиксироваться на конкретной вышке или бэнде? Есть ли интерфейс для точной настройки антенны с отображением RSRP, SINR и т.д.?
На редкость тёплая приятная статья, спасибо.
Мне кажется, у значительного количества людей подобное техническое творчество и тяга к экспериментам в детстве привели к карьере в технологической сфере. Я лично очень благодарен отцу за то что в детстве познакомился и с разными приборами, и с пайкой, и с ZX spectrum. Если бы не это, моя жизнь могла бы сложиться совсем по другому
Могу предположить что сейчас большинство частных VPN серверов как раз работают через подход с контейнерами docker и настройкой через ansible, но вот чтобы это делалось прямо через мобильное приложение — такого я ещё ни разу не видел.
Хотел уточнить пару моментов:
Отдельное спасибо за то что описываете реальные сценарии использования туннелей, в отличие от продаванов платных VPN сервисов которые поголовно обещают людям чёрт знает что, и анонимность, и масочку Гая Фокса в придачу
Если бы я писал статью на эту тему, то скорее развил бы мысль в сторону того что немалое число уязвимостей ОС на базе ядра Linux растёт из монолитной структуры самого ядра. Это создаёт некоторые проблемы Linux, которые как правило вообще не будут касаться других ядер ОС.
Как уже упомянуло несколько человек, самым правильным решением было бы воспользоваться XPrivacyLua через который можно выбранным приложениям разрешить доступ к настоящему списку контактов, звонков, да и другим штукам типа железных идентификаторов устройства, а другим возвращать пустые списки, фейки или нуллы. К сожалению, этот подход требует установленного xposed фреймворка, что не на всех устройствах возможно, и не все захотят подобное себе устанавливать.
Я, устав от спама, завёл себе некоторое время назад не привязанную ко мне сим-карту, завёл под неё гугл-аккаунт, взял свой «рабочий» смартфон с установленным xposed фреймворком, XPrivacyLua и ещё некоторыми свистелками, делающими сбор информации с девайса близким к невозможному. На нём я регистрируюсь во всяких мутных сервисах, ставлю туда приложения которые хотят много обо мне знать, типа программ лояльности, приложений сетей магазинов и прочий шлак. Очень удобный подход, но не для всех
Если я правильно понимаю, на android карты «Мир» сейчас работают через обычный userspace HCE-сервис из приложения платёжной системы, а на ios не работали совсем из-за отсутствия API эмуляции тэгов. Теперь всё будет работать «из системы»
/s
Решение — просто делать проверки через шелл (можно при желании заавтоматизировать всё через python и subprocess). Загружаемся в TWRP. Образ TWRP содержит многие утилиты для работы с файловыми системами, сбора информации о системе, и т.д. Среди них есть и утилиты для подсчёта хэшей, воспользуемся sha256sum:
Насчёт антивирусов — даже не знаю имеет ли это смысл, и что можно посоветовать. Я попробовал прогнать тесты на нескольких популярных антивирусных продуктах при установленном бэкдоре, и похоже что большинство из них не пытается прогонять сложные проверки на то что система на устройстве была скомпрометирована, или хотя бы просто попробовать прогнать проверку SafetyNet. Я не пытался глубоко анализировать механику работы антивирусов на android. Судя по всему они пытаются получать информацию о пакетах и искать подозрительные данные в манифестах или что-то вроде того. В любом случае, если устройство не предполагает использования аппаратного ТЕЕ в процессе аттестации (такое кажется есть только на пикселях), то на скомпрометированной системе с помощью рантайм-хуков злоумышленник сможет при необходимости обмануть любую проверку, поэтому наверное никто очень сильно и не пытается
Ну, кажется выглядит всё правильно. Гугл запретил huawei пользоваться ОС с гугл сервисами, но он не имеет права запретить пользоваться AOSP — это открытый проект.
Тут несколько сбивает с толку легальный статус android. Сама операционная система — под свободной лицензией, но google apps — интеллектуальная собственность гугла, пользоваться которой он даёт производителям устройств по лицензии. Эти части — совершенно отдельные сущности, просто мы привыкли что они находятся на наших устройствах одновременно. Названия с android в системе относятся как раз к операционной системе, так что всё в порядке. Просто huawei пришлось переизобрести google apps со своим бэкендом, молодцы кстати, давно пора чтобы гаппсам уже появилась какая-то совместимая с ОС альтернатива.
Куда печальнее то что пиарщики huawei наобещали больше чем то что в итоге получилось. Я вот прям помню что они говорили и про собственное ядро, и про новую организацию самой ОС, и т д
Хм, может я недопонял вопрос. Тот сценарий который я описал требует перезагрузки устройства, сначала в fastboot, потом в рековери, потом снова в систему. Без перезагрузок ничего сделать не получится, поэтому не выключая смартфон атаку не провести
Спасибо большое. Главный минус — имея рут доступ можно изменить что-нибудь в системном разделе и вызвать срабатывание dm-verity, что соответственно приведёт к невозможности загрузиться. Это легко сделать неосторожным изменение hosts файла например. Тем не менее вполне можно использовать afwall, т.к. всё для чего ему нужен root — это вызов бинарника iptables. Я бы сам лично не стал бы пользоваться root доступом в системе с заблокированным загрузчиком просто чтобы случайно не наломать дров.
П.С: не только в нём, мне нужно сесть и поправить немало орфографических ошибок
Я не наблюдал сам за работой FDE, поэтому не могу быть уверен на 100% что именно он шифрует внутри. Из того что я прочитал, полагаю что он шифрует раздел userdata целиком, но system и boot также не трогаются, поэтому нам также стоит следить за хэшами в случае временного попадания устройства в чужие руки.
Второе — не получится, потому что шифрование завязано на ТЕЕ. Мы можем склонировать userdata раздел, но тогда брутфорсить нам полное пространство ключей — 2^128. Скорее уж получится локально пробовать подбирать пины, многие люди снижают энтропию на несколько порядков используя части даты рождения или телефонных номеров своих или близких родственников, может повезти
Спасибо за вдумчивый комментарий. Всё прям в точку. Практически нечего добавить.
На мой взгляд немало проблем растёт из того, что всё касающееся безопасности очень сильно завязано на пропиетарные компоненты, и даже при желании не может быть исправлено сообществом. Либо проблемы заложены в изначальном дизайне системы и пытаться их исправить ничего не сломав во взаимодействии фреймворка и приложений близко к невозможному (пермишены, подход «всё или ничего»). В итоге, сообщество кастомщиков и радо бы усилить механизмы безопасности, но не может.
Тем не менее, там где это возможно гугл и вендоры стараются подкручивать гайки и это хорошо.