Captive portal

Captive portal обычно используются в открытых беспроводных сетях, где пользователям показывается приветственное сообщение с условиями доступа (разрешённые порты, ответственность, и т. п.). Администраторы внедряют такие страницы для того, чтобы пользователи брали на себя ответственность за свои действия и для снятия собственной юридической ответственности^[3]. Насколько такое перенесение ответственности легитимно с правовой точки зрения — предмет дискуссий^[4][5]. На некоторых сетях может требоваться ввод номера мобильного телефона или других идентификационных данных пользователя, чтобы администраторы могли предоставить информацию властям в случае выявления противоправной деятельности.

Часто captive portal используется для маркетинговых или коммерческих коммуникаций. Пользователь получает доступ к интернету через открытую Wi-Fi после обмена персональными данными посредством заполнения веб-формы. Такая форма может автоматически открываться при подсоединении или появляться после попытки открыть любой сайт в браузере. То есть пользователь в прямом смысле становится «заложником» портала и не может свободно использовать интернет, пока не выполнит указанные действия или не завершит процедуру входа. Это позволяет поставщику услуги отображать или рассылать рекламу людям, подключающимся к точке доступа. Такой сервис также называют «социальным Wi-Fi», так как для входа может потребоваться учётная запись социальной сети (например, Facebook). За последние годы социальные captive portal стали широко распространённым решением для сбора маркетинговых данных^[6].

Содержание captive portal может быть разнообразным; зачастую доступ к сети предоставляется в обмен на просмотр содержимого или выполнение определённых действий (чаще всего — предоставление контактных данных). Таким образом, маркетинговое применение captive portal является инструментом генерации лидов (получения бизнес-контактов или потенциальных клиентов)^[7].

Один из наиболее часто используемых методов — перенаправление всего веб-трафика пользователей на специальный веб-сервер с возвратом HTTP-редиректа на страницу captive portal^[8]. Когда современное устройство впервые подключается к сети, оно отправляет HTTP-запрос на специальный URL, определённый производителем, и ожидает получить код состояния HTTP 200 OK или 204 No Content. Если устройство получает статус 2xx, оно считает, что имеет полный доступ к интернету. Если вместо этого получен ответ с HTTP 302 redirect на captive portal, отображается соответствующее уведомление^[9][10]. Стандарт определяет код состояния 511 Network Authentication Required (Требуется сетевое подтверждение личности).

Перенаправление клиентского трафика может осуществляться также с использованием ICMP-редиректа на третьем уровне модели OSI.

Когда клиент запрашивает ресурс по доменному имени, происходит обращение к системе доменных имён. В случае captive portal файервол гарантирует, что неаутентифицированные клиенты могут использовать только DNS-сервер, предоставленный через DHCP, или (альтернативно) он перенаправляет все запросы к своему серверу. Этот DNS-сервер в ответ на все запросы возвращает IP-адрес страницы captive portal.

Для осуществления такого перенаправления captive portal использует технику подмены DNS (DNS hijacking), представляющую собой аналог атаки типа «человек посередине». Для снижения эффекта от отравления DNS обычно используется TTL, равный нулю.

вводит стандартизированный способ информирования клиентов о наличии конечных точек Captive Portal API () с помощью параметров DHCP (IPv4 и DHCPv6) и объявлений маршрутизатора в IPv6 (NDP). Реализация RFC 8910 появилась в systemd-networkd v254 в июле 2023 года[11].[12] В сообществе NetworkManager также обсуждается поддержка взаимодействия с такими API[13].

URL-адреса для обнаружения captive portal, как правило, возвращают минимальный стандартный ответ, если сеть не использует captive portal. Когда устройство получает ожидаемый ответ, оно заключает, что имеет прямой доступ к интернету. Если сигнал отличается, устройство предполагает наличие captive portal и инициирует процесс авторизации.

Известны случаи, когда в captive portal имелись неполные наборы правил файервола, например, оставлялись открытыми некоторые исходящие порты, что позволяло клиентам обходить портал^[17].

В некоторых случаях правила позволяют клиентам отправлять DNS-запросы в интернет или избранный DNS-сервер обрабатывает произвольные запросы. Это позволяет обходить captive portal, передавая любой сетевой трафик внутри DNS-пакетов (туннелирование).

Некоторые captive portal допускают автоматическое обнаружение и вход специальных пользовательских агентов. Такие агенты или вспомогательные приложения (например, Captive Portal Assistant от Apple) позволяют пройти авторизацию и получить доступ без взаимодействия с веб-интерфейсом при наличии корректных учётных данных. В то же время попытки входа с некорректными или устаревшими данными могут привести к непредвиденным последствиям, например, к случайной блокировке учётной записи.

Если captive portal отслеживает подключённые устройства по MAC-адресу, возможен обход системы путём использования MAC-адреса ранее авторизованного устройства. После авторизации шлюз вносит MAC-адрес в белый список; однако подменить MAC не составляет труда, поэтому любой другой клиент может выдать себя за уже зарегистрированное устройство и обойти портал. Для снижения таких рисков используют расширенные механизмы аутентификации.

Часто captive portal требуют наличия веб-браузера; если пользователь пытается использовать почтовый клиент или другое приложение, использующее Интернет, доступ может не работать без объяснения причин, и только после открытия браузера появляется форма авторизации. Это может быть проблемой для пользователей, у которых отсутствует веб-браузер с поддержкой HTTPS. Иногда допускается подключение сервисов, не использующих DNS, если приложение работает по IP-адресу, а не доменному имени. Также усложняет ситуацию использование AJAX или уже загруженных страниц: при попытке отправить HTTP-запрос может возникнуть непредсказуемое поведение.

Поскольку HTTPS-соединения не могут быть перенаправлены без предупреждений о безопасности, если браузер сразу запрашивает защищённые сайты, такие попытки заканчиваются неудачно (сайт кажется «недоступным»).

Платформы с поддержкой Wi-Fi и TCP/IP, но без современного браузера (например, Nintendo DS) часто не совместимы с большинством captive portal. Для них возможна не только веб-, но и XML-аутентификация (WISPr), авторизация по MAC-адресу или прочим протоколам.

Могут применяться соглашения между вендорами платформ и операторами точек доступа, позволяющие бесплатный или льготный доступ к серверам производителя через механизмы «огороженного сада» (walled garden). Например, в 2005 году компании Nintendo и Wayport обеспечили бесплатный Wi-Fi для Nintendo DS в ряде ресторанов McDonald's^[18]. Аналогично, для телефонии (VoIP, SIP) можно разрешить обход шлюза для соответствующих портов.