Captive Portal для самых маленьких
Здравствуйте мои маленькие любители авиационного спирта =) !
Последние пару дней занимался настройкой Wi-Fi, да не простого, а стильного-модного-молодёжного, со своим Captive Portal. Для тех, кто в танке: это когда ты подключаешься к Wi-Fi сети, но прежде чем допускать тебя к интернетам и ЛОРу в частности, нужно пройти какую-никакую дополнительную авторизацию на веб-страничке, third-party так сказать.
Такой подход я считаю более секурным, потому как, доступ каждого клиента по Wi-Fi регулируется лично через iptables, а не тупо форвардится всё подряд. Какой простор для творчества! Во-вторых, авторизация происходит через веб-страничку, а не WPA и прочие нативные механизмы wireless-сетей, которые как и всё в нашем мире, не вечны и надёжность их хромает.
После вступления, приступим.
Рассказывать о настройке NAT лишний раз не буду, думаю, у вас уже должна быть настроена раздача Wi-Fi, и всё, что вам ненужно, это только Captive Portal.
wlan0 — имя интерфейса Wi-Fi
eth0 — имя интерфейса с интернетами
192.168.0.0/24 — локалка
Вот и всё. Здесь включена проверка через -i wlan0, таким образом это не вызовет никаких конфликтов с другими сетями, т.к. у меня в продакшене под кроватью очень много правил iptables и я знаю, о чём говорю.
Подводные камни, на которые я наткнулся и спешу поделиться с вами. В соседнем треде мне научно-популярно объяснили, что тщетно пытаться настроить редирект по HTTPS на свой Captive Portal, это просто не сработает, это уже MitM атака. Не очень-то и хотелось! ;p
Если у вас используются личные DNS, то наверняка у вас есть правило, разрешающее локальные запросы к серверу (tcp/53 udp/53). Не забудьте разрешить запросы и к локальному веб-серверу (tcp/80). Но а если вы сообщаете Wi-Fi клиентам какие-то публичные NS, то не забудьте разрешить доступ клиентам к ним: iptables -t filter -I FORWARD -i wlan0 -s 192.168.0.0/24 -d 8.8.8.8/32 -j ACCEPT . А суть такова. Когда клиент подключается к Wi-Fi, он проверяет доступность интернета в целом, для этого смартфоны качают со своих серверов файлы и проверяют корректность полученных данных. Если оно не сможет резолвить хост запрашиваемого сайта, то на этом и споткнётся и проверка на наличие Captive Portal в сети не пройдёт.
Собственно, теперь к механизму Captive Portal.
Как уже замечено, это личная прерогатива каждого клиента, проверять доступность интернета, и если в результате проверки что-то пошло не так, — значит либо интернета нет, либо Captive Portal.
Мы перенаправили все запросы на 80 порт к себе, на свой локальный сервер. Теперь nginx должен в ответ на все HTTP запросы отвечать кодом 302. Не 200, не 301, не 511, а именно 302, а затем перенаправлять вас на страничку с third-party авторизацией, и только таким макаром например мой Андрюша-9 смог обнаружить, что у меня таки Captive Portal, а не какой-то сломанный интернет. В результате сразу после подключения к Wi-Fi сети должно появиться Push-уведомление: Скриншот #1, при нажатии которого откроется страничка, куда редиректит nginx Скриншот #2.
Сам скрипт странички я оставляю вам на откуп: думаю, вам не составит никакого труда наслюнявить однострочник на php добавляющий $_SERVER[‘REMOTE_ADDR’] в iptables через shell_exec(); или типа того. Да? Да. Ваш Captive Portal полностью в ваших руках.
Вот и весь механизм работы Captive Portal. Спрашивайте ответы.
Источник
Captive portal собственными руками
Каждый из нас подключался к беспроводной сети (аэропорты, кафе и тд) где необходимо согласится с некоторыми условиями или пройти авторизации прежде чем начинать пользоваться интернетом. Такая технология называется captive portal.
В мою задачу входило создать captive portal где каждому пользователю раз в 30 минут будет показываться определенный сайт (реклама), и пока он не нажмет «кнопочку» «далее» интернета не будет.
Для создания нам понадобится:
- Wifi-точка доступа любая (на практике можно использовать и проводной интернет)
- Маршрутизатор на любой *nix системе (в моем случае это debian wheezy)
Краткое описание принципа работы
- Любой пакет пришедший на маршрутизатор маркируем
- Любой запрос на 80 порт (пакеты уж маркированны) перенаправляем на нужную нам страницу
- При «авторизации»(нажатии кнопки далее) пользователя добавляем его мак в исключения и разрешаем доступ в интернет
- Скрипт вычисляет у кого прошел лимит времени и удаляет данного клиента.
У нас имеется маршрутизатор на базе debian, где eth0 — локальная сеть в моем случае (192.168.11.0/24), eth0:1 — интерфейс который смотрит в интернет.
Настройку интерфейсов мы пропустим, это каждый выполнит сам. Сразу перейдем к настройке iptables, я обычно прописываю iptables в rc.local:
/etc/rc.local
На этом конфигурация iptables заканчивается и переходим к странице которую получает пользователь: /var/lib/index.php
Данная страница может быть любой, смысл лишь в том, чтобы получить мак пользователя и добавить его в iptables.
В текущий момент получилась следующая схема:
- Iptables автоматически редиректит любой запрос на 80 порт на нашу страницу
- пользователь вводит свое имя и почту, скрипт php получает мак пользователя и добавляет в iptables правило исключения для этого мака
- Php скрипт складывает все данные пользователей (имя, почта, время добавления) в файл /var/lib/users
Осталось только сделать скрипт который будет:
- удалять правило из iptables для мака у которого вышло время
- удалять из файла данные по этому пользователю
Так как мои знания в программировании довольно плачевны был написан простенький скрипт на перле:
Источник
Проект выходного дня: настраиваем в Linux безопасное гостевое подключение по Wi-Fi
Приближаются праздники (обратите внимание на дату создания оригинала этой статьи) и вы знаете, что это значит: ваши родственники захотят использовать ваш WiFi. Если вы хотите найти решение, лежащее где-то посередине между «запустить открытую незащищенную точку доступа» и «раздать ваш пароль WPA2 тем, кто записывает подобные вещи на клочках бумаги», вариант с настройкой Captive Portal-а может оказаться удобным решением.
Прим. редактора: Captive Portal (кэптив портал, каптив портал) позволяет создать публичную сеть на одном из интерфейсов брандмауэра, что позволяет реализовать общественную точку беспроводного доступа — хотспот или зону общественного доступа, например, в библиотеках. При первой попытке выхода в Интернет из публичной зоны Captive Portal отображает специальную web-страницу, на которой обычно находятся правила пользования, с которыми нужно ознакомиться перед тем, как будет разрешён доступ в сеть. Captive Portal также позволяет использовать внешний сервер RADIUS для аутентификации клиентов перед тем, как предоставить доступ в Интернет. См. также здесь.
Есть несколько Captive Portal-ов с открытым исходным кодом, которые вы можете выбрать для своей машины с Linux. Среди них — NoCat , HotSpotPA , PacketFence и ChilliSpot . Однако, если у вас нет времени для изучения всех возможностей и вариантов, лучшим выбором будет, вероятно, WiFiDog поскольку это простое и активно разрабатываемое решение. WiFiDog будет работать на любом дистрибутиве Linux и он также присутствует в качестве дополнительного пакета в большинстве встроенных Linux-маршрутизаторов (например, в OpenWRT и DD-WRT ).
Очевидно, что задачи, которые выполняются пакетом Captive Portal-а, зависят от того, есть ли на машине два (или больше) сетевых интерфейса. Портал перехватывает подключения, поступающие на интерфейс, для которого заданы ограничения, выполняет некоторую проверку подлинности, а затем осуществляется перенаправление трафика на интерфейс, на котором ограничения отсутствуют, причем независимо от того, используется доступ к локальной или глобальной сети. Каноническая схема настройки точно такая, как для обычного маршрутизатора. Ограничения устанавливаются для интерфейса с Wi-Fi, а маршрутизация и подключение к интернету без всяких ограничений осуществляется через интерфейс к WAN. Прочие проводные интерфейсы, имеющиеся на маршрутизаторе, как правило, в схеме не используются, поскольку программы портала не слушают их и не ограничивают к ним доступ.
Но необходимости в специализированном маршрутизаторе нет; с той же самой настройкой все будет работать так же хорошо, если вы установите карту Wi-Fi в обычный сервер с Linux. Вам также необязательно блокировать сеть Wi-Fi со всеми вашими посетителями: если ваш маршрутизатор допускает с помощью «виртуальных интерфейсов» одновременную работу с несколькими SSID, то вы просто указываете, какой интерфейс будет использоваться для Captive Portal-а, а какие интерфейсы для него использоваться не будут.
Базовый вариант WiFiDog содержит в себе два компонента: шлюз, который прослушивает запросы на подключение клиентов, и сервер аутентификации, который одобряет подключение клиентов и поддерживает активные соединения. На полноценной машине, на которой работает Linux, вы можете запустить обе программы, но у встроенного маршрутизатора, как правило, достаточно ресурсов для запуска на нем лишь шлюза; сервер аутентификации вам придется запускать на другой машине.
Когда WiFiDog будет действительно использоваться, пользователям нужно будет создавать «учетные записи» с использованием их уникальных адресов электронной почты. Когда пользователи посещают шлюз Wi-Fi, они могут на странице входа в шлюз либо войти с использованием уже существующей учетной записи, либо создать новую учетную запись и временно получить доступ к сети, чтобы они могли проверить свою электронную почту в ранее зарегистрированном почтовом ящике. Когда делается попытка войти в систему через шлюз, шлюз перенаправляет запрос к серверу аутентификации, если полномочия подтверждены, то шлюз и сервер обмениваются зашифрованными данными и новому клиенту предоставляется трафик. Может показаться странным, но поскольку обмен зашифрованными данными между клиентом и шлюзом никогда не происходит, WiFiDog может использоваться для доступа с самого широкого спектра устройств в отличие от случаев, когда используется система, в которой от клиента требуется загружать сертификат SSL или в течение всей сессии постоянно использовать JavaScript.
Инсталляция и настройка: Шлюз
Пакет со шлюзом доступен как часть проекта WiFiDog в виде архива с исходными кодами, хотя если вы устанавливаете шлюз на сервере или на настольном компьютере, вы можете поискать его с помощью системы управления пакетами, имеющейся в вашем дистрибутиве. Если вы намереваетесь запустить шлюз на маршрутизаторе с Linux, вам лучше всего ознакомиться с инструкциями, прилагаемыми к используемой прошивке, но вы, скорее всего, обнаружите предварительно скомпилированные двоичные модули или пакеты, входящие в состав стандартной поставки.
Впрочем, для всех остальных случаев легко откомпилировать исходный код, поскольку в нем используются стандартные в Linux функции netfilter и iptables. Просто распакуйте исходный код, с помощью команды cd перейдите в директорий, а затем выполните трехшаговую операцию ./autogen.sh; make; sudo make install .
В результате будет создан двоичный пакет wifidog, а в директории /etc/wifidog.conf будет создан шаблон конфигурационного файла. Откройте конфигурационный файл и отредактируйте его так, как считаете нужным; в созданном файле в блоках комментариев приведена документация по каждому из параметров, так что этот файл сравнительно легко читать и можно правильно задать настройки. Наиболее важными параметрами являются GatewayID, ExternalInterface, GatewayInterface и AuthServer.
Параметр GatewayID является именем, которое вы назначаете этому конкретному узлу, например, MyHomeWifi. WiFiDog поддерживает централизованное администрирование нескольких шлюзов, которым нужно задавать различные имена, но если у вас только один шлюз, просто выберите имя и запомните его. Параметры ExternalInterface и GatewayInterface указывают на интерфейс, смотрящий в интернет, и интерфейс шлюза, соответственно. В обычных случаях вы должны в качестве ExternalInterface использовать eth0 (проводной Ethernet-интерфейс), и wlan0 (беспроводная сетевая карта) — в качестве GatewayInterface.
Параметр AuthServer представляет собой блок, описывающий сервер аутентификации, с которым должен связываться данный шлюз при авторизации новых клиентов. Можно использовать несколько блоков AuthServer; опять же это то, что позволяет пользоваться настройками, находящимися в сети в разных местах, — шлюз будет обращаться к ним последовательно до тех пор, пока не получит ответ. Пример блока выглядит следующим образом:
Здесь указывается, что шлюз взаимодействует с сервером аутентификации по ссылке https://mylocalserver.lan/wifidog/. Вы можете различными способами указывать адреса URI, используемые для доступа к серверу аутентификации, в том числе указать путь к скрипту регистрации пользователя и станицу, сообщающую об успешном подключении. Настроек, заданных по умолчанию, как правило, достаточно, если, конечно, у вас на сервере уже не используется сложная система конфигурирования Apache.
В конфигурационном файле вы также можете задавать тайм-ауты и интервалы отсылки пингов вида «keepalive» («я живой»), определять базовые правила брандмауэра и указывать списки клиентов, которые будут сразу без каких-либо проблем автоматически подключаться к интернету (параметр TrustedMACList), а также определить свою собственную главную страницу портала. Когда файл будет настроен, сохраните его, а затем с помощью команды sudo wifidog -f -d7 запустите сервис шлюза. Параметр -f указывает, что сервис будет исполняться не в фоновом режиме, а параметр -d7 устанавливает режим с максимальной выдачей сообщений — таким образом вы сможете отловить все проблемы. В реальных условиях эксплуатации вам не следует указывать эти параметры и wifidog будет работать в режиме демона.
Инсталляция и настройка: Сервер аутентификации
На сервере аутентификации вам потребуется выполнить больше настроек и установить дополнительные пакеты: вам потребуется Apache, PHP, PostgreSQL и около десятка дополнительных пакетов для PHP. Большинство из них обычные, такие как xmlrpc и mhash, но некоторые из них специализированные, например, Auth_RADIUS. Текущий список требований можно получить из официальной документации. Согласно официальной документации рекомендуется также увеличить объем памяти, указываемый в файле php.ini, по крайней мере, до 32 Мб.
После того, как дополнительные пакеты будут установлены, вся остальная настройка выполняется сравнительно просто. Скачайте и распакуйте исходный код, разместите его в любом удобном месте, например, в вашем директории DocumentRoot. Это директорий должен быть доступен для других машин по URL, который вы укажите на шлюзе в конфигурационном файле /etc/wifidog.conf; в нашем примере — http://mylocalserver.lan/wifidog/. Когда вы перейдете страницу http://mylocalserver.lan/wifidog/install.php, вас поприветствует мастер установки сервера аутентификации.
Используемый в настоящее время инсталлятор может проверять зависимости пакетов с тем, чтобы вы были уверены, что пользуетесь правильными версиями PHP и PostgreSQL, но он не создает для вас базу данных PostgreSQL. Приводятся только объяснение того, как это сделать, в том числе и примеры пошаговых команд, создающих пользователя базы данных «wifidog», а затем — самой базы данных и таблиц. На этапе проверки правильности пакетов по отдельности проверяется правильность версии библиотек PHP и правильность прав доступа к файлам. Наконец, вам будет предложено загрузить схему базы данных и создать учетную запись администратора. После этого, удалите файл install.php.
Настройка сервера аутентификации выполняется с помощью редактирования файла config.php, расположенного в директории wifidog. Как и в случае со шлюзом, для каждого параметра есть примеры и документы с комментариями. В самом начале указываются обычные настройки базы данных (имя хоста, пользователь базы данных), которые вы, возможно, захотите изменить. Ниже, в разделе «WiFiDog Basic Configuration» («Базовая конфигурация WiFiDog»), есть несколько параметров, связанных с Google Maps и другими украшательствами; в большинстве случаев вы можете оставить их без изменений.
Управление шлюзом
Когда сервер будет запущен и заработает, подключитесь к основному URL (но не через ваш шлюз Wi-Fi). Вы должны увидеть страницу входа в WiFiDog. Здесь вам следует ввести учетную запись администратора, которую создали ранее. Вы получите доступ к инструментальным средствам управления через веб интерфейс. Когда вы подключаетесь первый раз, никаких настроек не будет, поэтому вам нужно будет начать с создания «сети» в меню сетевого администрирования Network administration.
В простом случае (один сервер аутентификации и один шлюз), вы можете назначить сети любое легко запоминающееся имя, например, MyBasicNetwork (моя основная сеть). По умолчанию, WiFiDog для аутентификации пользователей использует учетную запись электронной почты. Если вы не хотите его использовать, вы можете выбрать в разделе «Network authentication» («Сетевая аутентификация») другой метод аутентификации. Параметр «Validation grace period» («Время отсрочки проверки») предоставляет вновь вошедшему в систему пользователю время, в течение которого он может проверить наличие новых сообщений в его электронной почте (по умолчанию это — 20 минут).
После того, как ваша новая сеть будет определена, добавьте к сети ваш шлюз, выбрав для этого в меню «Node administration» («Администрирование узлов сети») вариант «Add Node» («Добавить узел»). Идентификатор узла Node ID, который вы вводите, должен быть именем узла, который вы создали на шлюзе в файле wifidog.conf: в файле на шлюзе он называется GatewayID (проблема несоответствия является проблемой WiFiDog, а не вашей проблемой); в нашем примере используется идентификатор MyHomeWifi. Сохраните ваши настройки, и клиенты смогут подключаться через шлюз, используя для этого правила, которые вы указали для сети MyBasicNetwork. Здесь снова возможность WiFiDog, позволяющая удаленно управлять несколькими узлами в нескольких сетях, обеспечит большую гибкость при использовании распределенной системы, даже если это кажется излишним в случае наличия только одной точки доступа.
Теперь, находясь в административном интерфейсе, вы можете видеть, с какими учетными записями осуществляется вход в сеть, проверять возникающую при этом нагрузку на сеть, пользоваться сетевыми графиками и проверять регистрационные журналы. Вы также можете управлять учетными записями пользователей в случаях, если обнаружили какие-либо необычные действия, которые не ожидали видеть, либо подозрительную активность при создании учетных записей.
Дополнительные возможности: Дополнительная бдительность
Процедура, описанная выше, сама по себе не защитит вас от проникновения злоумышленников; мы просто создали обычный шлюз, на котором нет каких-либо ограничений по сервисам. Чтобы защитить вашу локальную сеть от проникновения в нее посетителей, зашедших через точку доступа, вам потребуется принять дополнительные меры, начиная с записи правил брандмауэра в файле wifidog.conf на шлюзе. Вы можете пользоваться обычными схемами фильтрации пакетов iptables, которые поддерживаются в Linux, так что вы можете настраивать правила, блокирующие трафик Bittorrent, ограничивать доступ к определенным адресам IP и делать многое другое. В файле wifidog.conf есть примеры с подробными комментариями, либо вы можете получить подсказку из любых инструкций HOWTO, относящихся к iptables.
И, все же, кроме всего этого, на вас все равно лежит ответственность следить за тем, кто подключается к сети. Выявление и блокирование недобросовестных посетителей отнюдь не простая задача и, в целом, одна из проблем Wi-Fi состоит в том, что злоумышленники могут перехватывать сигнал, считывать аутентификационный IP и адреса MAC и, подменив пакеты, имитировать вошедшего в систему клиента. Так что, как это обычно рекомендуется, когда речь идет о безопасности вашего Captive Portal-а WiFiDog, вы не можете сделать его более безопасным, чем это уже есть по умолчанию. Просто следите за тем, чтобы посетитель не заходил слишком далеко, и открывайте дополнительные порты только тогда, когда это потребуется вашим родственникам.
Источник
