Re: ограничить+авторизировать доступ в инет
On Mon, Oct 25, 2004 at 10:16:43AM +0400, Vadim Kutchin wrote:
[skip]
> Хотелось бы сделать следующее:
> Если юзер захотел поработать в инете, то для этого ему надо указать
> пароль. Дополнительно к этому вводятся дневные\недельные ограничения на
> траффик - почты можно 100 мег, http можно 50 мег, остального можно 10
> мег. И логи чтобы складывались для контроля\анализа.
>
> Что лучше почитать, как отправную точку, для создания такой системы?
> С помощью каких инструментов?
Можно посмотреть на реализации captive portal-ов (оно правда
изначально задумывалочь для Wi-Fi, но для этой задачи тоже должно
подойти). Там идея в следующем: юзера находятся в приватной сети, наружу
ходят через "интеллектуальный" гейтвей (ИГ), при попытке выхода наружу
неавторизованного пользователя (н.п. в строке браузера набирается адрес
интернетовского ресурса) ИГ делает автоматический редирект на страничку
авторизации, там юзер вводит логин/пароль. Если всё совпало, то для
айпишника данного юзера на ИГ открываются фильтры наружу и делается NAT.
Потом, в процесее работы сканятся счётчики iptables и считается трафик,
по исчерпании фильтры закрываются. Можно поискать может есть патчи для
iptables, которые умеют выставлять лимит на трафик.
За подробностями:
http://en.wikipedia.org/wiki/Captive_portal
http://wiki.personaltelco.net/index.cgi/PortalSoftware
Только нужно иметь в виду, что в этом подходе есть куча вопросов
связанных с безопасностью:
1) конфиденциальность передачи аутентификационных данных (допустим для
писюков это не вопрос - практически все умеют HTTPS, чего не скажешь о
разных наладонниках и т.п.);
2) не давать возможность юзерам "прикидываться" друг другом и
вырабатывать чужой трафик. Речь идёт о возможности подмены IP- и
MAC-адресов.
3) если адреса выдаются по DHCP, то нужно иметь ввиду вероятность того,
что шибко умный юзер может в локалке поднять свой DHCP-сервер и выдавать
юзерам в качестве default gateway адрес подконтрольного ему хоста, на
котором он может поднять свой captive portal "очень похожий" на
оригинальный и таким образом насобирать пользовательских
логинов/паролей.
4) если предполагается, что captive portal и его клиенты могут быть
воткнуты не в один свич и/или находиться в различных подсетях, то
сложность обеспечения безопасности возрастает в разы.
--
With best regards, Oleg Gritsinevich
Reply to: