Captive portal login что это за программа и нужна ли

Содержание

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

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

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

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

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

Портал захвата pfsense

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. Где же следует располагаться компонентам решения?

😈ДОРОГА В АД — CAPTIVE PORTAL на Intercepter-NG. MiTM’и как СОТОНА | ДЕМОНстрация😈

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 портал приделывает к вызову довольно длинную переменную, которую мы должны вернуть ему в неприкосновенности среди параметров запроса на открытие портала.

При чём тут 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 пользователя (мы умеем), запоминать там, что мы ему уже посылали смс и при втором заходе спрашивать уже код. Ибо куки этот минибраузер не поддерживает.

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

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

ap7131-ABCDEF(config-captive-portal-XXXXX)#bypass ? captive-portal-detection Captive portal detection requests(e.g., Apple Captive Network Assistant ap7131-ABCDEF(config-captive-portal-XXXXX)#bypass captive-portal-detection

Источник: savepearlharbor.com

4. UserGate Getting Started. Работа с пользователями

Приветствую в четвертой публикации цикла статей, посвященному продукции компании UserGate . В данной статье мы рассмотрим, как создать локального пользователя на устройстве UserGate, добавим LDAP-коннектор для подключения к Microsoft Active Directory и настроим captive-портал.

Идентификация пользователей позволяет применять политики безопасности, правила межсетевого экрана, правила веб-безопасности только к тем пользователям или группам пользователей, которым это необходимо.

Пользователи и группы пользователей могут быть созданы на самом устройстве UserGate (локальные пользователи и группы). Кроме локальных пользователей можно добавить и сервера авторизации. При этом поддерживаются следующие типы серверов авторизации:

LDAP-коннектор;
Сервер авторизации пользователей Radius;
Сервер авторизации пользователей TACACS+;
Сервер авторизации Kerberos;
Сервер авторизации NTLM;
Сервер авторизации SAML (SSO).

UserGate оперирует следующими типами пользователей:

Пользователь Unknown — множество пользователей, не идентифицированных системой;
Пользователь Known — множество пользователей, идентифицированных системой;
Пользователь Any — любой пользователь (объединение множеств пользователей Known и Unknown);
Определенный пользователь — пользователь, определенный и идентифицированный в системе.

В рамках данной статьи будет рассмотрен явный способ идентификации пользователей через captive-портал. У UserGate есть прозрачные варианты определения пользователей, например kerberos. К сожалению, рассмотрение этого механизма выходит за рамки нашего курса.

Создание локальных пользователей

Для создания локального пользователя нужно задать его имя, но чтобы идентифицировать его, необходимо указать:

Логин и пароль — для идентификации по имени и паролю. В этом случае потребуется настроить Captive-портал, где пользователь сможет ввести данное имя и пароль для авторизации.
IP-адрес или диапазон, MAC-адрес для идентификации с помощью комбинации MAC и IP-адресов. В данном случае необходимо обеспечить, чтобы данный пользователь всегда получал доступ в сеть с указанных MAC и/или IP-адреса.
VLAN ID для идентификации пользователя по тегу VLAN. В данном случае необходимо обеспечить, чтобы данный пользователь всегда получал доступ в сеть с указанного VLAN.

Также при создании локального пользователя можно указать его электронные почтовые адреса и номера телефонов. Если данные параметры указаны, то они могут быть использованы для отсылки пользователю необходимой информации, например, как 2-й фактор при мультифакторной аутентификации.

В случае, если у пользователя указан и логин, и пароль, и IP/MAC/VLAN адреса, система использует идентификацию по адресу, то есть идентификация по адресу является более приоритетной.

Для более удобного управления политиками безопасности пользователей можно объединить в группу:

LDAP-коннектор

Рассмотрим подключение к Active Directory через LDAP-коннектор, с использованием методов авторизации Captive-портала. Для этого в разделе “Серверы авторизации” нажать на кнопку “Добавить” и выбрать “Добавить LDAP-коннектор”.

Также можно указать путь поиска, если необходимо сузить область поиска пользователей и групп, при отсутствии какого-то пути поиск происходит по всему каталогу. Вкладка “Kerberos keytab” предназначена для загрузки keytab-файл. Он понадобится при настройке авторизации Kerberos, но UserGate советует загружать данный файл даже если не планируется использование авторизации Kerberos, потому что шлюз может использовать механизма kerberos, чтобы снизить нагрузку на серверы LDAP.

Настройка Captive-портала

Captive-портал позволяет авторизовать неизвестных пользователей (Unknown users), которые не были идентифицированы с помощью агентов терминальных серверов, агентов авторизации для Windows или заданы с явным указанием IP-адреса. Кроме этого, с помощью Captive-портала можно настроить самостоятельную регистрацию пользователей с подтверждением идентификации через SMS или e-mail.

pfsense настройка Captive Portal

Настройка Captive Poratal осуществляется через панель администрирования. Для этого переходим в браузере по внутреннему IP-адресу (LAN) pfsense.

Стандартный логин/пароль для pfsense: admin/pfsense

После первого входа запустится мастер первичной настройки, который можно пропустить щелкая кнопочку Next.

Добавление пользователей

Для корректной работы Captive Portal необходимы пользователи. Можно по аналогии с OPNsense подключить pfsense к Active Directory А можно использовать локальную базу пользователей pfsense. System -> User Manager -> Users -> Add

Для разрешения доступа к Captive Portal пользователю (группе пользователя) необходимо добавить следующие права: User — Service: Captive Portal login

Создание Captive Portal

Далее, добавляем Captive Portal (Service -> Captive Portal -> Add). Активируем.

Производим следующие настройки: интерфейсах выбираем LAN; в методах аутентификации — Use an Authenticathion backend; серверах аутентификации — Local Database. Также рекомендуется задать таймауты для автоматического разлогинивания пользователей (если это необходимо).

Крайне желательно настроить Enable HTTPS login.

На этом настройка Captive Portal завершена. Теперь для выхода в интернет пользователям необходимо ввести логин и пароль. Страница для ввода данных будет появляться при попытке доступа в интернет автоматически.

Если страница ввода данных для Captive Portal не появляется, то просто наберите в адресной строке URL Яндекса и вас перекинет на страницу ввода данных. К сожалению, редирект с поисковой системы Google не работает корректно.

Отключение авторизации для некоторых IP-адресов

Остался один шаг для настройки корректной работы. А именно разрешить внутреннему DNS-серверу ходить в интернет без авторизации, либо разрешить всем обращаться к определенным DNS-без авторизации. По такому же принципу можно разрешить доступ в интернет некоторым пользователям без авторизации, или разрешить доступ к некоторым ресурсам в сети интернет без ввода логина и пароля.

В настройках Captive Portal переходим на вкладку Allowed IP Addresses и добавляем IP-адреса которым (или к которым) разрешен доступ без авторизации.

Источник: itarticle.ru

6.5. Настройка Captive-портала

Captive-портал позволяет авторизовать неизвестных пользователей (Unknown users) с помощью методов авторизации с использованием каталогов Active Directory, Radius, TACACS+, SAML IDP, Kerberos, NTLM или локальной базы пользователей. Кроме этого, с помощью Captive-портала можно настроить самостоятельную регистрацию пользователей с подтверждением идентификации через SMS или e-mail.

Следует помнить, что:

Настройка Captive-портала сводится к следующим шагам:

Шаг 1. Создать метод авторизации, например, авторизация с помощью домена Active Directory

В консоли UserGate в разделе Пользователи и устройства —> Серверы авторизации нажать на кнопку Добавить и создать сервер авторизации

Шаг 2. Создать профиль авторизации, в котором указать необходимые методы авторизации

В консоли UserGate в разделе Пользователи и устройства —> Профили авторизации нажать на кнопку Добавить и создать профиль авторизации, используя созданный ранее метод авторизации

Шаг 3. Создать Captive-профиль, в котором указать необходимые профили авторизации

В консоли UserGate в разделе Пользователи и устройства —> Captive-профили нажать на кнопку Добавить и создать Captive-профиль, используя созданный ранее профиль авторизации

Шаг 4. Создать правило Captive-портала

Правило Captive-портала определяет трафик, к которому должны быть применены методы идентификации пользователей, указанные в Captive-профиле. В консоли UserGate в разделе Пользователи и устройства —> Captive-портал нажать на кнопку Добавить и создать правило Captive-портала

Шаг 5. Настроить DNS для доменов auth.captive и logout.captive

Служебные доменные имена auth.captive и logout.captive используются UserGate для авторизации пользователей. Если клиенты используют в качестве DNS-сервера сервер UserGate, то ничего делать не надо. В противном случае необходимо прописать в качестве IP-адреса для этих доменов IP-адрес интерфейса сервера UserGate, который подключен в клиентскую сеть. Альтернативное решение — настроить параметры Домен auth captive-портала и Домен logout captive-портала. Более детально эти параметры описаны в разделе Общие настройки.

Создание методов авторизации подробно рассматривалось в предыдущих главах. Рассмотрим более подробно создание Captive-профиля и правил Captive-портала.

Чтобы создать Captive-профиль, необходимо в разделе Captive-профили нажать на кнопку Добавить и указать необходимые параметры:

Название

Описание

Шаблон страницы авторизации

Выбрать шаблон страницы авторизации. Создавать страницы авторизации можно в разделе Библиотеки —> Шаблоны страниц. Если необходимо настроить самостоятельную регистрацию пользователей с подтверждением по SMS или e-mail, то следует выбрать соответствующий тип шаблона (Captive portal: SMS auth/ Captive portal: Email auth)

Метод идентификации

Метод, с помощью которого UserGate запомнит пользователя. Возможны 2 варианта:

Запоминать IP-адрес. После успешной авторизации пользователя через Captive-портал UserGate запоминает IP-адрес пользователя, и все последующие соединения с этого IP-адреса будут относятся к данному пользователю. Данный метод позволяет идентифицировать данные, передаваемые по любому из протоколов семейства TCP/IP, но не будет корректно работать при наличии NAT-подключения между пользователями и сервером UserGate. Это рекомендуемое значение, устанавливаемое по умолчанию.
Запоминать cookie. После успешной авторизации пользователя через Captive-портал UserGate добавляет в браузер пользователя cookie, с помощью которого идентифицирует последующие соединения данного пользователя. Данный метод позволяет авторизовать пользователей, находящихся за NAT-устройством, но авторизуется только протокол HTTP(S) и только в том браузере, в котором происходила авторизация через Captive-портал. Кроме этого, для авторизации HTTPS-сессий пользователя UserGate будет принудительно дешифровать все HTTPS-соединения. Для правил межсетевого экрана пользователь, идентифицированный по cookie, будет всегда определен как Unknown user

Профиль авторизации

Созданный ранее профиль авторизации, определяющий методы аутентификации

PROИТ

Office 365, AD, Active Directory, Sharepoint, C#, Powershell. Технические статьи и заметки.

Дано: на сервере установлен pfSense 2.3 с модулем Captive Portal (кэптив портал для контроля входа пользователей в Интернет через WiFi — wifi-hotspot).

Задача: настроить собственную страницу ввода логина-пароля (или номера ваучера) взамен встроенной ( login page form ), а также отображать собственную страницу выхода ( logout page , отсоединения сесии ) , а также обойти проблему всплывающего окна формы выхода ( popup window, которая зачастую блокируется в браузере).

Т.к. мы хотим позволить пользователю не только вводить логин-пароль, но и иметь возможность войти в сеть по выданному ваучеру, нам необходимо было совместить обе формы входа, т.к. по умолчанию pfSense отображает только форму ввода логина.

Как загрузить свои шаблоны форм?

Делается это на странице настроек Captive портала в блоке » HTML Page Contents » ( Services — Captive Portal — Имя зоны — Configuration ):

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

Как видно уже предлагается базовый шаблон:

Здесь важны имена полей для ввода, а также скрытые поля и заменяемые значения ( $ ). На базе этого шаблона, не меняя имен, можно сделать любой свой шаблон.

Если необходимо использовать внешние файлы — ресурсы (рисунки, стили, скрипты), то их можно загрузить в File Manager портала (Services — Captive Portal — Имя зоны — File Manager ). Нужно учесть, что у ресурсов в имени необходимо добавить префикс «captiveportal-«

captiveportal-logo.png
captiveportal- mystyle.css

Если этого не сделать, то им этот префикс будет присвоен при загрузке и в шаблоне ссылки на них перестанут работать.

Я приведу примеры двух шаблонов:
1) форма входа login.html
2) форма выхода logout.html
Форма входа login.html

В нашем случае она должна была содержать как поля ввода логина пароля, так и поле для ввода номера ваучера. Также нужно было добавить предварительную валидацию полей ввода от пустых значений и некорректного ввода (через javascript ). Стили и скрипты можно описывать сразу в коде страницы.

Примечание: шаблон формы также допускает наличие php- скриптов (чем мы воспользуемся при создании формы выхода).

Итак, шаблон должен содержать следующие скрытые поля:
Оставляем их без изменений.

Поле для ввода логина должно называться auth_user , а поле пароля auth_pass . Поле для ввода номера ваучера — auth_voucher .

Форма должна содержать кнопку submit с имене м accept (попытка отправить форму с другим именем такой кнопки не удалась, хотя не понятно почему, т.к. имя именно кнопки отправки не должно ни на что влиять) .

Также, т.к. мы объединяем эту страницу со страницей вывода ошибок, то в том месте страницы, где хотелось бы показать текст ошибки, нужно вставить шаблон переменной: $PORTAL_MESSAGE$ .

Т.к. заранее известно, что если логин-пароль не верны и ошибка возвращает текст «Invalid credentials specified.» , то можно это «отловить» в скрипте и показать текст по-русски (см. мой шаблон ниже).

Тексты ошибок для ваучеров можно настроить непосредственно на странице параметров генерации ваучеров ( Services — Captive Portal — Имя зоны — Vouchers ):

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

Также при вводе ваучера пользователь должен согласиться с условиями использования нашей сети (поставить «галочку» «Согласен»).

Код страницы входа получился следующим (для публикации убрала лишние стили, которые можно добавить самостоятельно, обязательные поля выделила желтым):

Источник: www.e-du.ru

Тонкости

При чём тут Apple

4. UserGate Getting Started. Работа с пользователями

Создание локальных пользователей

LDAP-коннектор

Настройка Captive-портала

pfsense настройка Captive Portal

Добавление пользователей

Создание Captive Portal

Отключение авторизации для некоторых IP-адресов

6.5. Настройка Captive-портала

PROИТ

pfSense 2.3 форма входа (login) и выхода (logout) (Captive Portal)

Для чего нужна программа компилятор

Программа смешанное белье для чего

Токси риск программа для чего

Программа аршин метрология для чего

Программа чек пфр для чего

Для чего предназначена программа стили

Для чего нужна программа тренажер

Для чего нужна программа apkpure