простой способ веб-аутентификации пользователей сетей Wi-Fi
Это краткое руководство будет полезно начинающим сисадминам, перед которыми стоит задача быстро и с минимальными затратами развернуть систему Wi- Fi доступа с аутентификацией и авторизацией. Это может быть, например, небольшая беспроводная сеть, предоставляющая платную услугу использования интернета для мобильных абонентов. В интернет-кафе ставка обычно делается не на организацию безопасных каналов связи, а на простоту пользования услугой. Ничего удивительного нет – практика показывает, что значительная часть современных пользователей интернета вообще не предполагают, что в основе лежит некая среда передачи, протоколы и т.п. Они просто «заходят в интернет», то бишь открывают веб-браузер. Были случай, когда человек для доступа в интернет купил модем и уже, было, собрался окунуться в пучину всемирной паутины, как вдруг совершенно неожиданно для себя выяснил, что для этого еще и телефонная линия нужна! «Странно», - подумал мужик, - «а говорили, что нужен только модем»...
Поэтому широкую популярность приобрела так называемая веб-аутентификация, которая является альтернативой более сложным VPN-туннелям и полностью отвечает юзерским представлениям – «браузер=интернет». Суть технологии в следующем: пользователь, подключившись к Wi-Fi сети, первоначально не имеет выхода в интернет. Открыв браузер и набрав произвольный URL в адресной строке, он попадает на страницу аутентификации, где ему предлагается ввести логин и пароль (или номер карты и пин-код). Доступ к интернет-ресурсам будет открыт только после успешной авторизации. В данном механизме на стороне клиента не требуется специального программного обеспечения или какой-либо предварительной настройки.
На сегодняшний день веб-аутентификацию поддерживают большинство точек доступа, однако использовать ее совместно с автоматизированной системой расчетов часто не представляется возможным из-за отсутствия полноценной поддержки RADIUS. Точки доступа, лишенные этого недостатка, как правило, стоят довольно дорого. Ниже описано решение, позволяющее реализовать веб-аутентификацию на UNIX-маршрутизаторе (том же сервере, где, например, установлена биллинговая система), что позволит сэкономить на выборе точек доступа.
Кроме стоимости, к недостаткам существующих решений, в полной мере поддерживающих RADIUS-аутентификацию (802.1х или встроенную поддержку RADIUS Web based auth) и позволяющих тарифицировать Wi-Fi соединения, стоит отнести функционирование этих решений на втором (канальном) уровне модели OSI. Из этого имеются исключения, например, решение Cisco Systems (LWAPP), которому, однако, в полной мере присущ первый недостаток - цена. Однако у большинства из изученных устройств имеется ограничение на расположение контроллера и выноса (у разных производителей под выносом понимаются одни и те же устройства, но по-разному именуемые: радио-порты (HP ProCurve Secure Access 700wl Series совместно с ProCurve Switch xl Access Controller Module), облегченные точки (SonicWall) и т.д. Такие решения чрезвычайно сложно развертывать в IP-сетях, где нет возможности поместить точку и контроллер в один Ethernet-сегмент.
решение
Между сетью общего пользования и точкой доступа, работающей в режиме моста или маршрутизатора без NAT, вклинивается обычный PC-маршрутизатор. В нашем примере он будет работать под управлением Linux.
Все функции аутентификации Wi-Fi клиентов переносятся на сервер, что позволяет до минимума снизить требования к используемым точкам доступа. Если нужен сервис DHCP, то он может быть запущен как на AP (Access Point, точка доступа), так и на сервере. Второй вариант оправдан только в случае, когда необходимо централизованно раздавать IP-адреса в Wi-Fi сети, построенной на нескольких AP.
Функции пограничного UNIX-маршрутизатора:
- биллинговая система (например, LANBilling в комплектации LBcore, LBcd (Ethernet-агент);
- перенаправление HTTP/HTTPS-запросов на собственный веб-сервер и блокировка прочего трафика для неавторизованных пользователей;
- исполнение дополнительного скрипта аутентификации, работающего с базой данных биллинга;
- открытие доступа пользователям, прошедшим аутентификацию;
- блокировка пользователя при исчерпании баланса, по запросу или завершению сессии.
правила файрволла
Перенаправлять HTTP-трафик можно при помощи механизма iptables REDIRECT. При старте системы должны быть выполнены следующие условия: разрешены только DNS-запросы, весь веб-трафик перенаправляется на сервер, остальное, фигурально выражаясь, идет в /dev/null, то бишь заблокировано. Конфигурационный файл iptables для стартового состояния будет выглядеть примерно следующим образом (это файл, сохраненный iptables-save, так что пусть вас не смущают описания цепочек со счетчиками пакетов/байтов в квадратных скобках):
*nat
:PREROUTING ACCEPT [97569:16395666]
:POSTROUTING ACCEPT [26991:1834572]
:OUTPUT ACCEPT [27006:1835736]
-A PREROUTING -p udp -m udp --dport 53 -j ACCEPT
-A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 80
-A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 443
-A PREROUTING -j DROP
COMMIT
Как видим, все правила было решено задать в таблице nat, цепочке PREROUTING. Хоть это не единственный вариант записи (часть этих правил можно содержать и в FORWARD), так определенно удобнее с точки зрения администрирования.
Если кто не в курсе, используются такие «конфиги» совместно с программой iptables-restore. Впрочем, никто не мешает вам задавать правила файрволла способом, к которому вы привыкли.
Список заданных правил будет иметь следующий вид:
# iptables -t nat -nL PREROUTING
Chain PREROUTING (policy ACCEPT)
Target prot opt source destination
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53
REDIRECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 redir ports 80
REDIRECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 redir ports 443
DROP all -- 0.0.0.0/0 0.0.0.0/0
После успешной аутентификации пользователя, например, с IP-адресом 192.168.10.10, к правилам фильтра, относящимся к той же таблице nat и цепочке PREROUTING, в начало дописываем разрешающее правило (естественно, не руками дописываем, а поручаем это управляющему скрипту, пример которого см. ниже). В результате должно получиться приблизительно следующее:
# iptables -t nat -nL PREROUTING
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 192.168.10.10/32 0.0.0.0/0
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53
REDIRECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 redir ports 80
REDIRECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 redir ports 443
DROP all -- 0.0.0.0/0 0.0.0.0/0
Добавление в начало цепочки разрешающего правила (ACCEPT) фактически останавливает просмотр остальных правил для адреса 192.168.10.10, и в результате перенаправление и блокировка трафика для него не работают.
управляющие скрипты
Для динамического управления правилами iptables необходимы 2 скрипта: script_start, добавляющий разрешающее правило для данного IP-адреса в начало цепочки, и script_stop, удаляющий правило.
script_start:
#!/bin/bash
# param $1 - ip
# param $2 - netmask
/sbin/iptables -t nat -I PREROUTING 1 -s $1/$2 -j ACCEPT
script_stop:
#!/bin/bash
# param $1 - ip
# param $2 - netmask
/sbin/iptables -t nat -D PREROUTING -s $1/$2 -j ACCEPT
Как видите, значения IP-адреса и маски подсети поступают в скрипт как параметры коммандной строки - $1 и $2 соответственно.
Вобщем-то это может быть и один скрипт, принимающий аргументы start и stop на манер System V init.
Помимо динамического управления правилами файрволла для корректного начала и завершения пользовательской сессии в базе данных необходимо поддерживать актуальное соответствие между пользователем и его текущим IP-адресом. Поэтому вышеописанные скрипты нужно немного усложнить, либо создать промежуточные, выполняющие запросы к биллингу. Или переложить большую часть работы на биллинг, одна из подсистем которого будет вызывать описанные выше скрипты как внешние модули. Вариантов, в общем, бездна.
Собственно веб-аутентификацию будет выполнять некий CGI- или PHP-скрипт на стороне сервера. Его задача проста - проверить логин и пароль. Если такой логин не найден, он попытается активировать карту, рассматривая введенный логин как номер карты. Для удобства все служебные запросы, необходимые для проверки подлинности, можно вынести в хранимую SQL-процедуру.
Если авторизация успешно пройдена, скрипт должен инициировать запуск скрипта script_start. Как он это будет делать – вам решать. Не забудьте только, что изменение правил файрволла (чем, собственно, и занимается script_start) требует root-привилегий. Веб-скрипт может также открывать в браузере пользователя дополнительное окно с формой, позволяющей отправить запрос на завершение сессии.
настройка apache
Потребуется небольшое дополнение к основной конфигурации. В httpd.conf нужно добавить строку:
ErrorDocument 404 /authorize.php
«Почему ErrorDocument?» – спросите вы. А потому, что если юзер вводит любой URL – например http://www.vasya-
pupkin.info/bestbb/index.php?xxx=yyy, вряд ли на вашем сервере, куда был перенаправлен этот запрос, найдется данная страница (вот будет прикол,если найдется! ;)
Кроме того, не мешает поправить DirectoryIndex в директории, описанной как DocumentRoot (если вы решили положить свой скрипт именно в корневую директорию):
Options Indexes FollowSymLinks
DirectoryIndex authorize.php
AllowOverride None
Order allow,deny
Allow from all
Все это необходимо для того, чтобы любой HTTP-запрос, перенаправленный на этот сервер, приводил к запуску скрипта аутентификации.
Можно, конечно, было привлечь к решению проблемы «тяжелую артиллерию» вроде mod_rewrite, но это имеет смысл только тогда, когда на данном веб- сервере есть какой-то другой, не относящийся к авторизации контент.
Необходимость прерывания пользовательской сессии возникает в следующих случаях:
- пользователь исчерпал свой баланс;
- административный запрос на блокировку.
- пользователь хочет закрыть сессию по окончании работы, дабы пресечь возможный несанкционированный доступ с использованием его IP-адреса; - разрыв сессии по таймауту при отсутствии активности с данного IP-адреса в течение заданного времени.
Во всех случаях для разрыва сессии необходимо запустить script_stop с нужными параметрами. Запуск скрипта в первых двух случаях должен инициироваться вашим биллингом. Пользовательский запрос (3-й случай) обычно выполняется через браузер (в предыдущем разделе упоминалось, что скрипт аутентификации должен открывать в браузере соотвествующее окно). Содержимое формы отправляется в тот же скрипт, он же может запускать и script_stop. Полагаю, что получение в PHP- или CGI-скрипте IP-адреса запрашивающего не является для вас проблемой.
Для обработки 4-го случая необходима переодическая проверка активных сессий. Для этих целей можно написать шелл-скрипт, который будет запускаться с заданным интервалом (через cron).
Alice D. Saemon, по материалам компании «Сетевые решения», производителя биллинговой системы LANBilling
Поэтому широкую популярность приобрела так называемая веб-аутентификация, которая является альтернативой более сложным VPN-туннелям и полностью отвечает юзерским представлениям – «браузер=интернет». Суть технологии в следующем: пользователь, подключившись к Wi-Fi сети, первоначально не имеет выхода в интернет. Открыв браузер и набрав произвольный URL в адресной строке, он попадает на страницу аутентификации, где ему предлагается ввести логин и пароль (или номер карты и пин-код). Доступ к интернет-ресурсам будет открыт только после успешной авторизации. В данном механизме на стороне клиента не требуется специального программного обеспечения или какой-либо предварительной настройки.
На сегодняшний день веб-аутентификацию поддерживают большинство точек доступа, однако использовать ее совместно с автоматизированной системой расчетов часто не представляется возможным из-за отсутствия полноценной поддержки RADIUS. Точки доступа, лишенные этого недостатка, как правило, стоят довольно дорого. Ниже описано решение, позволяющее реализовать веб-аутентификацию на UNIX-маршрутизаторе (том же сервере, где, например, установлена биллинговая система), что позволит сэкономить на выборе точек доступа.
Кроме стоимости, к недостаткам существующих решений, в полной мере поддерживающих RADIUS-аутентификацию (802.1х или встроенную поддержку RADIUS Web based auth) и позволяющих тарифицировать Wi-Fi соединения, стоит отнести функционирование этих решений на втором (канальном) уровне модели OSI. Из этого имеются исключения, например, решение Cisco Systems (LWAPP), которому, однако, в полной мере присущ первый недостаток - цена. Однако у большинства из изученных устройств имеется ограничение на расположение контроллера и выноса (у разных производителей под выносом понимаются одни и те же устройства, но по-разному именуемые: радио-порты (HP ProCurve Secure Access 700wl Series совместно с ProCurve Switch xl Access Controller Module), облегченные точки (SonicWall) и т.д. Такие решения чрезвычайно сложно развертывать в IP-сетях, где нет возможности поместить точку и контроллер в один Ethernet-сегмент.
решение
Между сетью общего пользования и точкой доступа, работающей в режиме моста или маршрутизатора без NAT, вклинивается обычный PC-маршрутизатор. В нашем примере он будет работать под управлением Linux.
Все функции аутентификации Wi-Fi клиентов переносятся на сервер, что позволяет до минимума снизить требования к используемым точкам доступа. Если нужен сервис DHCP, то он может быть запущен как на AP (Access Point, точка доступа), так и на сервере. Второй вариант оправдан только в случае, когда необходимо централизованно раздавать IP-адреса в Wi-Fi сети, построенной на нескольких AP.
Функции пограничного UNIX-маршрутизатора:
- биллинговая система (например, LANBilling в комплектации LBcore, LBcd (Ethernet-агент);
- перенаправление HTTP/HTTPS-запросов на собственный веб-сервер и блокировка прочего трафика для неавторизованных пользователей;
- исполнение дополнительного скрипта аутентификации, работающего с базой данных биллинга;
- открытие доступа пользователям, прошедшим аутентификацию;
- блокировка пользователя при исчерпании баланса, по запросу или завершению сессии.
правила файрволла
Перенаправлять HTTP-трафик можно при помощи механизма iptables REDIRECT. При старте системы должны быть выполнены следующие условия: разрешены только DNS-запросы, весь веб-трафик перенаправляется на сервер, остальное, фигурально выражаясь, идет в /dev/null, то бишь заблокировано. Конфигурационный файл iptables для стартового состояния будет выглядеть примерно следующим образом (это файл, сохраненный iptables-save, так что пусть вас не смущают описания цепочек со счетчиками пакетов/байтов в квадратных скобках):
*nat
:PREROUTING ACCEPT [97569:16395666]
:POSTROUTING ACCEPT [26991:1834572]
:OUTPUT ACCEPT [27006:1835736]
-A PREROUTING -p udp -m udp --dport 53 -j ACCEPT
-A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 80
-A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 443
-A PREROUTING -j DROP
COMMIT
Как видим, все правила было решено задать в таблице nat, цепочке PREROUTING. Хоть это не единственный вариант записи (часть этих правил можно содержать и в FORWARD), так определенно удобнее с точки зрения администрирования.
Если кто не в курсе, используются такие «конфиги» совместно с программой iptables-restore. Впрочем, никто не мешает вам задавать правила файрволла способом, к которому вы привыкли.
Список заданных правил будет иметь следующий вид:
# iptables -t nat -nL PREROUTING
Chain PREROUTING (policy ACCEPT)
Target prot opt source destination
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53
REDIRECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 redir ports 80
REDIRECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 redir ports 443
DROP all -- 0.0.0.0/0 0.0.0.0/0
После успешной аутентификации пользователя, например, с IP-адресом 192.168.10.10, к правилам фильтра, относящимся к той же таблице nat и цепочке PREROUTING, в начало дописываем разрешающее правило (естественно, не руками дописываем, а поручаем это управляющему скрипту, пример которого см. ниже). В результате должно получиться приблизительно следующее:
# iptables -t nat -nL PREROUTING
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 192.168.10.10/32 0.0.0.0/0
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53
REDIRECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 redir ports 80
REDIRECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 redir ports 443
DROP all -- 0.0.0.0/0 0.0.0.0/0
Добавление в начало цепочки разрешающего правила (ACCEPT) фактически останавливает просмотр остальных правил для адреса 192.168.10.10, и в результате перенаправление и блокировка трафика для него не работают.
управляющие скрипты
Для динамического управления правилами iptables необходимы 2 скрипта: script_start, добавляющий разрешающее правило для данного IP-адреса в начало цепочки, и script_stop, удаляющий правило.
script_start:
#!/bin/bash
# param $1 - ip
# param $2 - netmask
/sbin/iptables -t nat -I PREROUTING 1 -s $1/$2 -j ACCEPT
script_stop:
#!/bin/bash
# param $1 - ip
# param $2 - netmask
/sbin/iptables -t nat -D PREROUTING -s $1/$2 -j ACCEPT
Как видите, значения IP-адреса и маски подсети поступают в скрипт как параметры коммандной строки - $1 и $2 соответственно.
Вобщем-то это может быть и один скрипт, принимающий аргументы start и stop на манер System V init.
Помимо динамического управления правилами файрволла для корректного начала и завершения пользовательской сессии в базе данных необходимо поддерживать актуальное соответствие между пользователем и его текущим IP-адресом. Поэтому вышеописанные скрипты нужно немного усложнить, либо создать промежуточные, выполняющие запросы к биллингу. Или переложить большую часть работы на биллинг, одна из подсистем которого будет вызывать описанные выше скрипты как внешние модули. Вариантов, в общем, бездна.
Собственно веб-аутентификацию будет выполнять некий CGI- или PHP-скрипт на стороне сервера. Его задача проста - проверить логин и пароль. Если такой логин не найден, он попытается активировать карту, рассматривая введенный логин как номер карты. Для удобства все служебные запросы, необходимые для проверки подлинности, можно вынести в хранимую SQL-процедуру.
Если авторизация успешно пройдена, скрипт должен инициировать запуск скрипта script_start. Как он это будет делать – вам решать. Не забудьте только, что изменение правил файрволла (чем, собственно, и занимается script_start) требует root-привилегий. Веб-скрипт может также открывать в браузере пользователя дополнительное окно с формой, позволяющей отправить запрос на завершение сессии.
настройка apache
Потребуется небольшое дополнение к основной конфигурации. В httpd.conf нужно добавить строку:
ErrorDocument 404 /authorize.php
«Почему ErrorDocument?» – спросите вы. А потому, что если юзер вводит любой URL – например http://www.vasya-
pupkin.info/bestbb/index.php?xxx=yyy, вряд ли на вашем сервере, куда был перенаправлен этот запрос, найдется данная страница (вот будет прикол,если найдется! ;)
Кроме того, не мешает поправить DirectoryIndex в директории, описанной как DocumentRoot (если вы решили положить свой скрипт именно в корневую директорию):
Options Indexes FollowSymLinks
DirectoryIndex authorize.php
AllowOverride None
Order allow,deny
Allow from all
Все это необходимо для того, чтобы любой HTTP-запрос, перенаправленный на этот сервер, приводил к запуску скрипта аутентификации.
Можно, конечно, было привлечь к решению проблемы «тяжелую артиллерию» вроде mod_rewrite, но это имеет смысл только тогда, когда на данном веб- сервере есть какой-то другой, не относящийся к авторизации контент.
Необходимость прерывания пользовательской сессии возникает в следующих случаях:
- пользователь исчерпал свой баланс;
- административный запрос на блокировку.
- пользователь хочет закрыть сессию по окончании работы, дабы пресечь возможный несанкционированный доступ с использованием его IP-адреса; - разрыв сессии по таймауту при отсутствии активности с данного IP-адреса в течение заданного времени.
Во всех случаях для разрыва сессии необходимо запустить script_stop с нужными параметрами. Запуск скрипта в первых двух случаях должен инициироваться вашим биллингом. Пользовательский запрос (3-й случай) обычно выполняется через браузер (в предыдущем разделе упоминалось, что скрипт аутентификации должен открывать в браузере соотвествующее окно). Содержимое формы отправляется в тот же скрипт, он же может запускать и script_stop. Полагаю, что получение в PHP- или CGI-скрипте IP-адреса запрашивающего не является для вас проблемой.
Для обработки 4-го случая необходима переодическая проверка активных сессий. Для этих целей можно написать шелл-скрипт, который будет запускаться с заданным интервалом (через cron).
Alice D. Saemon, по материалам компании «Сетевые решения», производителя биллинговой системы LANBilling
Сетевые решения. Статья была опубликована в номере 09 за 2006 год в рубрике sysadmin
