Настройка Captive Portal для авторизации пользователей

Captive Portal – сетевой сервис авторизации и идентификации пользователей. Наиболее часто используемый при построении общественных Wi-Fi сетей, где необходимо ограничивать права доступа в сеть Интернет или взымать дополнительную плату за её использование. По сути своей представляет веб-портал где пользователю предлагается указать учетные данные для дальнейшей идентификации в сети.

С точки зрения информационной безопасности, Captive Portal необходимая мера при использовании корпоративной Wi-Fi сети. И с реализацией его прекрасно справляются межсетевые экраны нового поколения (NGFW) Palo Alto Networks.

Далее мы рассмотрим подробную инструкцию по установке и настройке Captive Portal для использования в корпоративной Wi-Fi сети. А так же наиболее часто возникающие проблемы, с которыми приходится сталкиваться системному администратору.

Настройка шаг за шагом.

Шаг 1.   Необходимо определить по какому из интерфейсов будут инициироваться запросы от пользователей на авторизацию и дать ему права на данную процедуру.
В нашем случае это ethernet1/5. Для того чтобы разрешить данному интерфейсу авторизацию Captive Portal, необходимо в Network – Network Profiles – Interface Mgmt создать или использовать уже имеющийся профиль, в котором разрешить сервисы Response Pages и User-ID.

Далее на вкладке Network – Interfaces выбрать нужный нам интерфейс и в Advanced – Other Info указать ранее созданный профиль:

Шаг 2. Необходимо сгенерировать или использовать сертификат, подписанный третьей стороной, для идентификации самого Captive Portal и дальнейшего безопасного с ним соединения. В этой статье мы будем рассматривать первый вариант. На вкладке Device – Certificate Management – Certificates нажимаем кнопку Generate. В появившемся окне нам необходимо внести данные для генерации корневого сертификата.

Certificate Name – произвольное имя сертификата
Common Name – IP или FQDN адрес интерфейса, который будет использоваться для Captive Portal
Certificate Authority – установить галку, для того чтобы сертификат был корневым

Теперь нам нужно сгенерировать сертификат непосредственно самого портала, подписанного корневым. Для этого еще раз нажимаем кнопку Generate и вводим следующие данные:

Certificate Name – произвольное имя сертификата
Common Name – IP или FQDN адрес Captive Portal
Signed By – указываем ранее созданный корневой сертификат
IP – добавляем IP атрибут Captive Portal
Host Name – в случае если у Captive Portal имеется FQDN адрес, то указываем и его

После нажатия на кнопку Generate в списке сертификатов у нас должен появится наш новый, подписанный корневым.

Шаг 3. Создаем SSL/TLS профиль, который будет использоваться для авторизации пользователей.
Переходим на вкладку Device – Certificate Management – SSL/TLS Service Profile и нажимаем Add.

Name – произвольное имя профиля
Certificate – выбираем ранее созданный сертификат (подписанный корневым)
Min Version – рекомендуется использовать наиболее защищенный TLSv1.2

Шаг 4. Переходим к настройкам непосредственно самого CaptivePortal.

Enable Captive Portal – включаем портал
Idle Timer (min) – таймер бездействия пользователя, по окончанию которого портал потребует повторного введения учетных данных
Timer (min) – общий таймер, по окончанию которого пользователю будет предложено заново ввести учетные данные
Mode – во избежание ошибки сертификата в браузере пользователей, рекомендуется использовать режим Redirect, таким образом будет происходить перенаправление на страницу Captive Portal. В случае же с Transparent, шлюз будет подменять запрашиваемый сайт пользователем на страницу Captive Portal, что может быть расценено браузером как попытка кражи конфиденциальных информации
SSL/TLS Service Profile – выбираем ранее созданный нами профиль шифрования
Authentication Profile – выбираем профиль, который указывает на список пользователей, для которых разрешена авторизация с помощью Captive Portal
Session Cookie (опционально)использовать куки вместо повторного ввода учетных данных
Redirect Host – IP или FQDN интерфейса шлюза Palo Alto, на который будет производиться перенаправление пользователей

Шаг 5. Далее настроим правило авторизации, которое бы перенаправляло все HTTP запросы от неизвестных пользователей на портал авторизации.
Для этого переходим на вкладку Policies – Authentication и нажимаем Add для добавления нового правила. Выбираем зону нашей Wi-Fi сети в качестве источника и зону INTERNET (Untrust) в качестве назначения. Т.к. пользователь нам еще неизвестен, то в качестве User выбираем Any. И наконец на вкладке Actions нужно указать действие default-web-form, в нашем случае это отправлять пользователей на Captive Portal.
В итоге должно получиться так:

Шаг 6. Завершающим шагом нам необходимо создать правило, которое бы разрешало всем авторизированным пользователям доступ в интернет. Следуя рекомендациям по безопасности мы выбираем web-browsing и ssl в качестве приложений для доступа в интернет, а также назначаем используемые по умолчанию порты (80 и 443).
Разрешающее правило создаем в Policies – Security и в итоге оно должно выглядеть следующим образом:

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

На этом настройку Captive Portal можно считать оконченной!

Как быть с HTTPS?

После настройки Captive Portal вы возможно столкнетесь с проблемой, что в отличи от HTTP запросов, HTTPS не обрабатываются для перенаправления на страницу авторизации. И даже если явно указать в правиле авторизации на обработку таких запросов, то это все равно не решит проблему.

Дело в том в отличии от HTTP, HTTPS пакеты являются зашифрованными и шлюз просто не в состоянии определить какому сайту предназначен тот или иной пакет, и уж тем более изменить его для перенаправления на свою страницу авторизации.

Но межсетевые экраны (NGFW) Palo Alto Networks способны решить и эту проблему. Благодаря аппаратной функции дешифровки, шлюз способен проникать в зашифрованные пакеты и читать их содержимое. Данная возможность будет также полезна для мониторинга и отслеживания передачи конфиденциальной информации третьей стороне.

Для включения дешифрации нам необходимо на вкладке Policies – Decryption создать два правила. Первое включает эту функцию для всех неизвестных пользователей, которые еще не авторизовались на портале. Второе отключает дешифрацию, если авторизация пройдена.
В качестве Decryption Profile используем профиль встроенные по умолчанию:

В итоге должно получиться так:

Незабываем указать HTTPS трафик для авторизации в ранее созданном нами правиле на вкладке Policies – Authentication:

После всех описанных выше действий попытка зайти на любой сайт будет переадресована шлюзом на страницу авторизации Captive Portal.

Опубликовано в рубрике Palo Alto