[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ограничить+авториз ировать доступ в инет



On Mon, 25 Oct 2004 11:30:34 +0300, Oleg Gritsinevich <olegg@ukrpack.net> wrote:
> 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
> 
> --
> To UNSUBSCRIBE, email to debian-russian-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> 
> 

хм.... вот авторизация юзеров на базе домена я сделал.. но как сделать
редирект на страничку с запросом логина и пароля в случае закрытого
инета я еще не придума (сечас идет авторизация по доменному имени,
есть лимит трафика, но что бы зайти в интернет надо обязательно
открывать спец страничку и там авторизовываться..) при вводе логина и
пароля открыавется фаервол на текущий ип (с которого был совершон
зазход)

Reply to: