Добрый день. Как известно, при предоставлении возможности пользователям исполнять какие-либо скрипты, качество написания которых зачастую оставляет желать лучшего, уровень безопасности системы резко падает. Появилась идейка - используя jail, предоставить пользователям свою среду исполнения, так что если их поломают, то это будет исключительно их проблема :) + минимизация рисков для других хостеров. Но ситуация осложняется тем, что необходимо использовать 1 ip-адрес, т.е. - есть домен domen.ru/user-page ip=123.133.12.150.
Свои соображения по поводу воплощения подобного проекта есть, но очень хотелось бы узнать - есть ли у кого опыт воплощения подобных проектов? Либо просто выслушать Ваши советы и предложения :)
Тут есть 2 пути:
1) завести карантинный сервер, на который пользователи выгружали бы свои скрипты, а там проверялись. Затем они бы отправлялись на основной сервер (можно автоматизировать при помоши CVS).
2) Тут недавно на форуме крутилась тема как запереть пользователей с своеобразный chroot.
Тоже вариант.
>Тут есть 2 пути:
>1) завести карантинный сервер, на который пользователи выгружали бы >свои скрипты, а там проверялись. Затем они бы отправлялись на основной >сервер (можно автоматизировать при помоши CVS).
Это конечно вариант, но я не вижу возможности автоматизировать процесс проверки, таким образом мы опять приходим к человеческому фактору (да и какой нормальный программист сядет копаться в чужих исходниках в режиме 24/7 :))
>2) Тут недавно на форуме крутилась тема как запереть пользователей с >своеобразный chroot.
Честно говоря, просматривая форум, ничего подобного не нашел... :(Да, активность по данному вопросу не поражает :)
Попробую выложить свой вариант решения проблемы:
Для начала - примерная структурная схема системы:
User(ports 21,80) -> CentSrv(real ip) -> jail(1,n)(192.168...)
CentSrv:a)ipfw divert to SwTC
b)SwTC to jail
SwTC - софтина, которая проверяя имя пользователя (либо запрашиваемый урл) пробрасывает пакеты на необходимый jail, внутри которого и крутится вся система доступная пользователю.Проблема как раз и состоит в этом среднем звене, но, как мне кажется, это вполне решабельно. :)
>необходимо использовать 1 ip-адрес, т.е. - есть домен domen.ru/user-page ip=123.133.12.150.Раздавай jail'ам интранет адреса, на которые потом можешь прокидывать через прозрачный прокси (apache+mod_accel) висящем на реальном IP.
>>необходимо использовать 1 ip-адрес, т.е. - есть домен domen.ru/user-page ip=123.133.12.150.
>
>Раздавай jail'ам интранет адреса, на которые потом можешь прокидывать через прозрачный прокси
>(apache+mod_accel) висящем на реальном IP.
А подробнее про этот вариант можно?
Уважаемый alts, а можно у вас поинтересоваться как вы будуте раздавать квоты в jail'е, просто сам хочу нечто подобное организовать, но вот с квотами не пойму, что делать?
>Уважаемый alts, а можно у вас поинтересоваться как вы будуте раздавать квоты
>в jail'е, просто сам хочу нечто подобное организовать, но вот с
>квотами не пойму, что делать?
А это смотря какие квоты имеются ввиду :) если дисковые, то средствами фряхи ставим квоту на chroot для каждого jail'a, а вот квотирование доступной памяти и процессорного времени... тут уже никак.
На самом деле пришла еще одна мысль - для меньшего геморроя создать всего один jail, в котором и бедт крутиться все окружение для всех, либо какого то определенного количества хостеров (тут и real-ip не жалко выделить :), а в случае возникновения проблемы просто прибить этот jail и запустить его заново. Но пока данная мысля находится в процессе оценивания :)
С превеликим удовольствие принимаются пожелания и мысли (good/bad) по данному поводу.
Один общий jail с общим окружением означает что один хостер сможет порыться в файлах другого хостера. Тот же PHP ведь будет с одними правами для всех?
>Один общий jail с общим окружением означает что один хостер сможет порыться
>в файлах другого хостера.
>Тот же PHP ведь будет с одними правами для всех?
Естественно, но такой подход ни чем не хуже обычного хостинга без применения jail'ов, с другой же стороны дает несколько плюсов:
1.Разбиение хостеров на группы - если что то произойдет в пределах группы, то хостеров из других групп оно не коснется.
2.Группы имеют real-ip, что исключает поддельные адреса и напряги связанные с этим.
3.Экономия ресурсов сервера - не будет кучи запущенных процессов в каждом отдельном jail'е, тот же апач будет крутиться в окружении группы один на всех.Это текущие мысли, может еще чего додумаю :)
>Один общий jail с общим окружением означает что один хостер сможет порыться
>в файлах другого хостера. Тот же PHP ведь будет с одними
>правами для всех?либо запускать PHP через suPHP и правильно раздать права на папки, либо PHP как модуль и на каждый виртуал хост выставить свой open_basedir
>Один общий jail с общим окружением означает что один хостер сможет порыться
>в файлах другого хостера. Тот же PHP ведь будет с одними
>правами для всех?Ничего подобного, для CGI - все решается через suexec и права доступа на директорию, а для php - через safe_mode.
>А это смотря какие квоты имеются ввиду :) если дисковые, то средствами
>фряхи ставим квоту на chroot для каждого jail'a, а вот квотированиеА можно по подробней, как это квота на chroot для каждого jail'а???
>доступной памяти и процессорного времени... тут уже никак.
>На самом деле пришла еще одна мысль - для меньшего геморроя создать
>всего один jail, в котором и бедт крутиться все окружение для
>всех, либо какого то определенного количества хостеров (тут и real-ip не
>жалко выделить :), а в случае возникновения проблемы просто прибить этот
>jail и запустить его заново. Но пока данная мысля находится в
>процессе оценивания :)Вот и я к такому же решению пришел, что можно всех хостеров в один jail или создать несколько jail'ов на разные тарифные планы, т.е. например самый простой хостинг (без динамики) можно сунуть в jail где будет только apache и с отключенными модулями... т.е. экономим ресурсы машины... но вот опять тот же вопрос как внутри jail'а раздать хостерам квоты???
PS а вообще, похоже что мы оба идем к одной цели то для ускорения обменом опыта ;) моя тетя Ася 60738030
>А можно по подробней, как это квота на chroot для каждого jail'а???
Ну просто выставляем системную квоту на папку jail'a либо, используем то же самое внутри рассматриваемого jail'a из под рута для каждого пользователя
>>доступной памяти и процессорного времени... тут уже никак.
Кстати, порыл тут на эту тему hint - /etc/login.conf но как разделить на всех - пока хз :)
>Вот и я к такому же решению пришел, что можно всех хостеров
>в один jail или создать несколько jail'ов на разные тарифные планы,
>т.е. например самый простой хостинг (без динамики) можно сунуть в jail
>где будет только apache и с отключенными модулями... т.е. экономим ресурсы
>машины... но вот опять тот же вопрос как внутри jail'а раздать
>хостерам квоты???
man quota
http://www.freebsd.org/doc/ru_RU.KOI8-R/books/handbook/quota...>PS а вообще, похоже что мы оба идем к одной цели то
>для ускорения обменом опыта ;) моя тетя Ася 60738030
Счаз стукну :)
>>Раздавай jail'ам интранет адреса, на которые потом можешь прокидывать через прозрачный прокси
>>(apache+mod_accel) висящем на реальном IP.
>А подробнее про этот вариант можно?Один apache с mod_accel на реальном порту, в конфигурации которого для каждого jail'а прописан свой блок конфигурации с пробросом. Для прозрачности, в апачах внутри jail нужно использовать mod_pealip.
RealIP (apache+mod_accel)
| | \
| | \
(FakeIP .... .......
apache+
mod_realip)
Hello all :-)
ещё слышал, что вместо apache с mod_accel можно использовать squid в качестве аксселератора. К примеру, есть какой-то корпоративный сайт, находящийся в интрасети, а на шлюзе поднят сквид, слушающий запросы снаружи на 80-м порту. И относительно безопасно, и сайт внутри доступен всем работникам + экономия траффика за счёт кеширования. А уж выделить внутри интрасети необходимое количество адресов для jail-машин на каждого хостера - не проблема.Кстати, нарыл тут же попутно https://www.opennet.ru/base/sec/freebsd_jail_setup.txt.html
С уважением, alex256.
ICQ 174637738