Captive apple com андроид

CaptivePortalLogin что это такое то?

Всем привет Поговорим мы о такой штуке как CaptivePortalLogin, я расскажу что это такое и почему оно у вас появляется. Как я думаю, то CaptivePortalLogin предназначен для безопасного пользования открытыми вай фай частными сетями, то есть публичными. Когда вы захотите подключится к такой сети, то у вас выскочит предупредительное сообщение CaptivePortalLogin, где нужно нажать кнопку и в принципе все… Это касается вроде бы только телефонов Samsung, но у других тоже может быть такой прикол

Если отключить CaptivePortalLogin, то есть риск что вы не сможете подключиться к вай фай сети, так что учтите это

Я пошел в гугловский переводчик и написал туда Captive Portal Login:

И вот что мне выдал переводчик:

То есть все верно, это вход в систему, можно сказать еще что CaptivePortalLogin это некая дополнительная авторизация перед использование публичной беспроводной сети.

Вот смотрите, нашел картину, это Application manager, вкладка All и тут есть приложение CaptivePortalLogin:

Весит приложение 96 Кб, а это оч и оч мало…

В окне Сведения о приложении (App info) вы можете попробовать отключить приложение, если нажмете на FORCE STOP (но как я уже писал тогда у вас может быть ошибка при подключении к беспроводной сети):

Значит можно ли отключить CaptivePortalLogin, то я уже написал, что в принципе может и можно, но будут ли в таком случае нормально подключаться вай фай сети, то это неизвестно. В сети я также нашел способ как отключить CaptivePortalLogin, так чтобы и можно было подключаться к вай фай сетям, для этого нужно установить приложение WifiAutoLogin. Собственно из названия WifiAutoLogin понятно уже, что главная функция проги это автологин для вай фай сети, чтобы вы вручную не подтверждали. Ссылку где можно скачать WifiAutoLogin я давать не буду, скажу только то, что при желании все легко находится в поисковике

Так, еще раз, какой делаем вывод? CaptivePortalLogin это приложение для вывода запроса-подтверждения при подключении к вай фай сети. Если отключить, то есть риск что вообще не будет подключаться сеть. Решение это использовать WifiAutoLogin, пойдите на форум 4PDA, там есть тема с обсуждениями.

Надеюсь что все тут было понятно. Удачи вам

Источник

Как я избавлялся от Google на Android

Недавно на работе получил задачу от руководителя: сделай так чтобы телефон android не сливал данные гуглу. Можете представить мой восторг (и предвкушение) ибо спустя 2 недели тестов я вполне уже чувствовал себя человеком который прошивает телефоны на радиорынке (ничего личного, просто не мой профиль). Прочел отличную статью и понабравшись опыта решил немного дополнить. Статья кстати отличная, рекомендую к прочтению.

Давайте рассмотрим несколько альтернативных операционных систем якобы без сервисов гугла, и выясним действительно ли они не общаются с гуглом. Подготовился я к слову основательно, для тестов даже приобрел девайс «pixel 3», так как GrapheneOS работает только с устройствами от google.

Хотел протестировать еще:

• /e/ Но к сожалению моего девайса не было в списке
• PostmarketOS Та же проблема
• PinePhone Было желание приобрести тестовый девайс. Но после обзора на youtube, желание пропало, так как он очень тормозит, и сложно его представить в роли смартфона для повседневного пользования.

GrapheneOS

На первый взгляд система позиционирует себя как максимально безопасная и анонимная. Есть пару нюансов которые мне не понравились:

Ничего необычного, этот сервис называется Captive portal используется для андроид с 4 версии. При наличии root можно выбрать другие независимые сервера или на крайняк поднять свой. Но такой возможности нет и приходится довольствоваться услугами google. Также разработчик утверждает что использование других серверов в качестве альтернативы нежелательно, по причине того что телефон будет более узнаваем в толпе, но говорит, что такая функция находится в разработке (правда имеет маленький приоритет)

LineageOS

LineageOS является более популярной операционной системой. Но к ней тоже очень много вопросов. Абсолютно чистая система умудряется стучать гуглу в особо крупных количествах. Вот данные которые я снял со своего маршрутизатора, и сделал небольшую табличку. Маршрутизатор снифил трафик с телефона 3 дня, повторюсь, что телефон я откатил до заводских настоек и ничего не устанавливал и никуда не логинился.

Существует несколько способов ограничить доступ телефона к google:

• Использование firewall. В моем случае я использовал afwall+, его можно скачать в магазине f-droid или же в aurora store, который можно скачать там же
• Второй способ, менее радикальный и более трудоемкий. Он заключается в подмене сервисов. Настройка на службах альтернатив google.

Каждый способ требует root права. Описывать как их получить не буду, так как есть огромное количество статей на эту тему, и в зависимости от модели телефона инструкция может меняться. Я использовал magisk

Использование firewall

Ну с этим, думаю, понятно. Блокируем все, и разблокируем по мере необходимости (для AFwall+ понадобятся root права). В android 10 добавили модуль Network Stack Permission Config module. Если заблочить данный модуль то система будет говорить что у данной сети нет доступа к интернету.
Тем не менее интернет будет работать в обычном режиме. Так как у меня гугловый девайс Pixel 3, то были подозрения что устройство общается с google на hardware уровне. Но они развеялись после того как заблокировал все и снял дамп с роутера. Результаты показали что за двое суток устройство дальше внутренней сети не ушло.

Подмена сервисов

Необходимо настроить следующие сервисы:

По дефолту LineageOS использует гугловые dns 8.8.8.8, было бы не плохо заменить их на cloudflare 1.1.1.1. Идеальным решением будет использовать vpn и завернуть туда весь трафик, в противном случае для каждой wifi сети надо будет вбивать руками кастомные dns. Альтернативой является установка приблуды через magisk «CloudflareDNS4Magisk», или какой-либо другой с магазина, но там на свой страх и риск. Как по мне лучше с гугловыми dns, чем непонятным магазинным софтом.

Captive Portals

Captive portal — сетевой сервис, требующий от подключившегося к сети пользователя выполнить некоторые действия для получения доступа в Интернет. Обычно используется для взимания платы, аутентификации абонента либо показа рекламы. Настроим его что-бы он стучался не на google.

Дальнейшая инструкция подразумевает то, что вы уже получили root через magisk

Присоединяем телефон по USB, запускаем терминал (linux;macos) и заходим в shell, ./adb shell , и переходим в режим админа su . Может отбить: permission denied, в этом случае заходим в magisk и даем shell рута.

Далее вводим следующие команды. Я выбрал заменить google на магазин f-droid

Вы также можете выбрать другой сервер. Ниже будет предоставлено несколько альтернатив, либо же вы можете поднять свой собственный

WebView

Советую заменить браузер на «duck go browser» который можно найти на aurora store

Hosts

Желательно заблокировать следующие сайты в файле hosts. Так как мы блокируем google нужно выбрать другой поисковик, предлагаю этот.

Выводы:

Огромное количество информации сливается даже при кастомных прошивках которые, позиционируют себя как свободные от google. А по факту когда снимаешь дамп трафика то мягко говоря удивляешься.

Если вы выберете второй способ, то все-равно не пренебрегайте использованием firewall, я неделю проверял данные с роутера, пробовал разные варианты (что будет если заблокировать эту службу, а что если эту). Оказалось что это самый надежный способ. Как и любая настройка firewall, блокируем все, разблокируем по надобности.

Изучал вопрос приватности и решил поделится с Хабром, так как Хабр часто делится со мной. Может кому-то это будет полезно. Спасибо если дочитали до конца.

Источник

Как отключить Captive Portal Login на смартфонах Samsung

У южнокорейского производителя электроники всегда были свои личные взгляды на многие вещи, которые зачастую расходятся с предпочтениями жителей Европы и США. Эта ситуация касается Wi-Fi сетей, в которых есть так называемый механизм Captive Portal Login. По сути, программисты Samsung решили дополнительно обезопасить владельцев всех смартфонов и планшетов на Android, вынуждая их каждый раз нажимать на злосчастную кнопку при подключении к открытой Wi-Fi сети.

В России механизм Captive Portal широко используется в Wi-Fi сети московского метрополитена, а также наземного транспорта. Если смартфоны Sony, HTC, Apple, Xiaomi и других производителей без каких-либо проблем автоматически подключаются к Wi-Fi сети MosMetro, то продукция компании Samsung требует обязательно нажатия кнопку «Войти в сеть». Только после ее нажатия произойдет подключение к сети.

Разумеется, что единичные нажатия на эту кнопку не приносят никаких трудностей, но когда на нее приходится нажимать каждый день по несколько раз – тут-то и возникает желание избавиться от Captive Portal Login, так как из-за этой особенности не корректно работает даже приложение «Автовход Wi-Fi в Метро», вынуждая каждый раз просматривать рекламу,

На форуме XDA Developers этой проблеме посвящена огромная ветка и некоторым разработчикам удалось найти решение этой проблемы, принудительно отключая Captive Portal Login на смартфонах и планшетах Samsung. Все, что требуется сделать от владельца устройства – установить на свой девайс специальное приложение под названием WifiAutoLogin. Произвести его загрузку можно непосредственно с форума для разработчиков, либо с нашего сайта.

После установки приложения на смартфон под управлением операционной системы Android 4.0.3 и выше потребуется запустить его и убедиться в том, что тумблер напротив Background authentication is переведен в приложение On. Если это действительно так, то программа должна полноценно работать и отключать Captive Portal Login в Wi-Fi сетях.

Справедливости ради стоит отметить, что приложение WifiAutoLogin может не работать на некоторых смартфонах и планшетах Samsung из-за программных особенностей, а также на кастомных прошивках и ядрах.

Источник

Распределённый Captive Portal в публичных местах и сложности с Apple

Почитав про метро, хотел было комментировать, но решил написать отдельно.

Мы участвовали в создании публичных сетей с распределёнными captive portal и наступали практически на все грабли, поэтому хочу поделиться опытом.

Для начала — немного теории о том, как это работает и чем распределённые порталы отличаются от централизованных. Идеологически то, что мы привыкли называть Captive Portal, на самом деле состоит из трёх компонентов:

web frontend — предназначен для взаимодействия с пользователем, сбора информации методом заполнения форм и показа ему рекламы. Если мы собираемся просить пользователя вводить личную информацию и пароли, то следует использовать https, соответственно, на сервер нужен нормальный сертификат. Если собираемся просить поставить галочку под соглашением пользователя, то достаточно http.

собственно captive portal — это некий агент, призванный получать информацию, собранную с помощью web frontend, анализировать её, возможно делать от своего имени уточняющие запросы (например, в RADIUS) и по результатам сообщать о своём решении либо непосредственно пользователю, либо ему же посредством web frontend. В случае положительного решения captvie portal приоткрывает для данного пользователя необходимые отверстия в firewall. По истечении заданного промежутка времени отверстия закрываются и мы имеем пользователя обратно в web frontend. Досрочно портал закрывается по неактивности пользователя. Зачастую единственной причиной ограничения времени сессии является желание снова показать пользователю рекламу (если мы не хотим выступать как в метро, уродуя дизайн других сайтов)

firewall — ведает доступом отдельных пользователей в сеть. В случае отсутствия доступа по идейным соображениям — выполняет перенаправление пользователя в web frontend. В случае отсутствия доступа по техническим причинам (не пингуется gateway) можно поручить firewall выполнять перенаправление пользователя на специальную страничку «сервиса нет, но мы чиним изо всех сил».

В случае централизованного captive portal все три компонента очевидным образом располагаются на одной машине (устройстве), что сильно упрощает задачу. Firewall в данном случае часто исполняет ещё и NAT, а captive portal можно реализовать в виде кучки скриптов, которые подкручивают локальный iptables. Возникает труднопреодолимое желание натолкать в сеть дешёвых точек доступа, которые свалят нам всех пользователей в ethernet или в самом лучшем случае — в отдельный vlan. Какие здесь проблемы:

• Проблемы с безопасностью. Мы ограничиваем доступ к внешнему каналу, однако в локальной сети всё плохо. Поскольку сеть открытая, любой пользователь может отвечать на arp от имени нашего default gateway, получать трафик пользователей и заниматься фишингом. Не возбраняется поставить свой сервер DHCP и в некой дельта-окрестности стремать пользователей заявлениями типа «ваш браузер безнадёжно устарел». Если ваш captive portal и пользователя разделяет роутер, то у вас нет возможности контролировать на captive portal соответствие mac и ip со всеми вытекающими. Коммуникация между беспроводными клиентами становится возможной. Вы можете на дешёвой точке запретить коммуницировать беспроводным клиентам, но клиенты других точек видны уже по ethernet.
• Проблемы с трафиком. Имеем в локальной сети много лишнего трафика. Желательно до открытия captive portal клиентов дальше точки доступа не пускать.
• Проблемы с масштабируемостью. При большом числе клиентов проблемным может стать любой из трёх компонентов портала.

Как вы уже догадываетесь, распределённый captive portal призван решать все эти проблемы. Говоря «распределённый», мы предполагаем, что компоненты могут размещаться на разных устройствах. Это позволит нам создать надёжную систему, которая обеспечит нужный уровень безопасности и сервиса, при этом обладая большими возможностями по масштабированию. Проблему, которую нам предстоит решить — обеспечить взаимодействие между компонентами captive portal. Где же следует располагаться компонентам решения?

Firewall должен находиться максимально близко к клиенту, т.е. однозначно в точке доступа. Поскольку точек доступа несколько и в каждой из них — свой firewall, то их работа должна быть синхронизирована в рамках некоторого пространства или местности, в пределах которой предполагается роуминг клиентов. В противном случае клиенты при роуминге будут испытывать проблемы с коммуникацией. В современных сетях задача синхронизации работы чего-либо внутри некой области (RF-домена) выполняется с помощью назначаемых арбитров (менеджеров RF-домена) и была решена в стародавние времена безотносительно к задаче реализации распределённого captive portal. Для этой системы синхронизация работы firewall — просто ещё один из процессов, который должен выполняться в домене согласованно, наряду (например) с коммутацией трафика, синхронизацией конфигураций точек или сбором статистики.

Место расположения web frontend сильно зависит от сложности задач, которые ему предстоит решать. Если надо показывать странички, не предполагающие server side processing или каких-то сложностей типа рассылки СМС, то вполне можно обойтись сервером на точке доступа. Он, опять же, располагается максимально близко к клиенту и обеспечивает наиболее эффективное с ним взаимодействие. Синхронизацией контента веб серверов на разных точках доступа займётся (сюрприз) менеджер RF-домена.

Место расположения captive portal зависит от положения web frontend и доступности точек. Поскольку задачей captive portal является подкручивание firewall, то он должен иметь своё представительство (агента) на каждой точке. Тем не менее, web frontend может коммуницировать с любой из копий этих агентов, ибо их состояние (вы уже догадались) также синхронизируется в рамках домена.

Таким образом, мы добиваемся ситуации, при которой для клиента, успешно прошедшего авторизацию, captive portal открывается сразу во всём домене и после этого в любой момент на всех точках доступа домена firewall для этого клиента настроен одинаково.

Тонкости

Метод взаимодействия с captive portal. Нам нужен механизм, с помощью которого мы можем сообщить порталу результаты взаимодействия с пользователем. В нашем случае в качестве такого механизма был выбран HTTP GET. При необходимости приоткрыть портал мы посылаем HTTP GET в любое из его представительств. Состав передаваемых в GET параметров зависит от режима, в котором работает портал. Здесь несколько вариантов:

• Портал открывается всегда. Возможно занести запись об этом в log.
• Портал открывается при наличии в GET переменной, отражающей согласие с условиями (agreement).
• В GET передаются username и password, портал сам лезет в RADIUS с этими атрибутами и открывается, получив оттуда ACCEPT.
• В GET передаётся один (универсальный) атрибут, портал указывает его и как username и как password при обращении в RADIUS и открывается, получив ACCEPT. Понятно, что такой пользователь должен быть в RADIUS

Всё, что за пределами этой логики, требует реализации в web frontend. Например, можно спросить у пользователя телефон, послать ему смс, проверить код. По результатам — зарядить в радиус пользователя (например) с username=номер_телефона и password=его_IP и дальше послать GET в портал с этими значениями.

Как портал, получив GET, разбирается о каком пользователе идёт речь? При переадресации пользователя в web frontend портал приделывает к вызову довольно длинную переменную, которую мы должны вернуть ему в неприкосновенности среди параметров запроса на открытие портала.

В идеале, точка выполняет бриджинг (форвардинг 2-го уровня) между SSID и неким vlan в проводах. То есть firewall работает на втором (MAC) уровне. Поскольку firewall видит прилетевший из недр вашей сети DHCP offer клиенту, он точно знает его IP, сам отвечает вместо клиента на ARP и жёстко фильтрует весь ARP и DHCP на беспроводном сегменте.

Отсутствие у точки IP-адреса в пользовательском vlan исключает возможность коммуникации пользователя непосредственно с точкой. Однако, иногда нам такая возможность необходима — при расположении web и портала прям на точке. В этом случае используется фиктивный адрес 1.1.1.1

При чём тут Apple

И почему мы везде, как и в метро, убеждаем айфончеги, что портала нет.

По тому, как айфончики ведут себя в беспроводных сетях, у меня сложилось стойкое убеждение, что создатели этого мегапродукта предполагали только один сценарий, а именно — одна точка доступа. То есть либо дома, либо в кафе для хипстеров. Во втором случае есть неиллюзорный шанс встретиться с captive portal.

Что предпринимает айфончик, встретив несколько точек с одним SSID и captive portal? Он пробует все доступные. На каждой он подключается, просит адрес, проверяет рандомный url из своего длинного списка (раньше он был один), понимает, что тут captive, отдаёт адрес (dhcp release) и отключается. Поскольку в нашем случае один SSID светит с каждой точки и в 2.4 и в 5GHz, всё умножается на два. Придя к логичному заключению «да тут везде засада!», айфончик снова подключается к одной из точек и рисует свой минибраузер. В терминологии наших заказчиков и клиентов этот процесс называется «Мой последний айфон очень долго подключается к вашей сети» и «у меня дома всё летает на точке за 1000 р.» В случае скоординированной сети (не отдельных точек) при каждом подключении точка посылает сообщение менеджеру домена «у нас новый пассажир», а в случае MESH — параллельно ещё и туда. Весь процесс занимает до 20 секунд.

Что предпринимает айфончик, встретив одинаковый SSID сразу в 2.4 и в 5GHz? Вы думали, что сможете балансировать клиентов между каналами, точками и диапазонами, максимально используя возможности клиентов и пропускание сети? Только не с продуктами Apple! Со стороны сети, слыша от клиента запросы в обоих диапазонах, мы вправе предполагать, что сможем вынудить клиента подключиться куда нам надо, пропуская запросы к тем точкам, куда мы не хотим, чтобы он подключался. Обычно клиенты понимают намёк и подключаются, например, в 5Ghz. Айфон будет ломиться в 2.4 до последнего. Для упорных есть отдельный счётчик (20 запросов подряд по умолчанию). Тоже занимает время.

Два описанных процесса происходят не только при подключении к сети, но и при роуминге, если отойти достаточно далеко. О, да здесь новые точки. Ну-ка, проверим…

Что предпринимает айфончик, если он запустил минибраузер и нам (вдруг) надо прислать клиенту СМС? Он показывает смс в маленьком окошке сверху с временем экспозиции порядка 3 секунд. Блондинка не в состоянии за это время запомнить 6 (шесть!) цифр. Окошко уезжает, пользователь тычет пальчиком в смс, минибраузер закрывается, dhcp release, disconnect, welcome to 3G. Пользователь с горем пополам запоминает код, лезет в settings, подключается к сети, введите номер телефона, получите новый смс. И далее, и далее… В терминологии заказчиков и пользователей это называется «на моём последнем айфоне не работает ваш каптив портал» и «даже в метро уже починили».
Ситуацию можно поправить, пересылая в web frontend MAC пользователя (мы умеем), запоминать там, что мы ему уже посылали смс и при втором заходе спрашивать уже код. Ибо куки этот минибраузер не поддерживает.

В чём причина такого малоадекватного поведения? Всё просто: создатели прибора ставили целью не оставить вас без связи.

Предположим, вы пришли в гости. Там — закрытая сеть, но добрые хозяева сообщили вам пароль и voilà — вот он интернет. Ваш смартфон сеть запомнил и во время вашего следующего визита подключился к ней уже автоматически. Но хозяева забыли заплатить провайдеру и на этот раз дальше роутера вас не пустили. То есть вы ничего не делали, даже не брали в руки телефон, но, сами того не подозревая, оказались без связи с внешним миром. Это очень плохо. Чтобы этого избежать, современные мобильные устройства выполняют при подключении некий многоступенчатый процесс, цель которого — не оставить вас без связи:

1. Не можем получить IP — отключаемся
2. Не видим ARP с default gateway — отключаемся
3. Не отвечает ни один DNS из списка — отключаемся
4. Запрашиваем некий url с одного из своих доменов — надеемся увидеть

В случае успеха последнего шага предполагаем, что интернет есть и слезаем с 3G. И так делаем при каждом подключении к wifi. Даже дома.
Если вместо «Success» наблюдаем что-то не то — вот он captive portal. Пора запускать минибраузер. Не смог пользователь за один раз договориться с порталом в окошке — отключаемся. Проблема с айфоном состоит в том, что он до последнего надеется на лучшее. Если вы просите подключиться к сети, и её видно на более, чем одной точке — будут перепробованы все варианты. Убьётся время. Большинство устройств, увидев портал, предполагают, что он тут везде, наверное.

Единственная возможность прекратить метания — выполнить обход обнаружения портала. Возможно осуществить двумя способами — фильтрацией «User-Agent: CaptiveNetworkSupport» или пропускать трафик по некоторому списку доменов. В метро, например, работает iMessage при закрытом портале.

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

На нашем оборудовании обнаружение выключается одной командой:

Источник