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