Возникла следующая проблема, на 1 выделенном сервере находятся несколько виртуальных хостов, причём 1 из них является дырявым, как решето, то есть там уже находили и sql иньекции, заливали и шелы туда и т. д. Объяснение владельцу данного домена азов безопасности не принесло успеха, в то время, как просто выгнать, или перекинуть его на другой сервер также не представляется возможным. В ввиду этого возникла идея построения более безопасной архитектуры. В принципе, что будут делать с данным дырявым сайтом мегакульхацкеры меня мало интересует, основная проблема заключается в том, что через него утыскивали пассы от бд других виртуальных доменов.Почитав немного о том, какими способами можно каждому виртуальному домену присвоить своего юзера, сделал вывод, что самым стабильным и оптимальным является запуск нескольких копий апача, по 1 для каждого юзера. Минусом этого вариант насколько я понимаю является значительное увеличение потребляемых ресурсов. Поэтому пришла мысль сделать следующий вариант.
Запустить ngnix в качестве фронтенд, в то время как несколько апачей будут работать на бэкенде. Так как апачи будут обрабатывать запрос ngnix и отдавать ответ мгновенно, то это не должно создать проблем с потреблением большого количества ресурсов апачами, но в этом могу ошибаться, так как не опытен в этом вопросе, именно поэтому пишу сюда, чтобы узнать мнение профессионалов. Также хочу заметить, что никогда не работал с ngnix поэтому хотелось бы получить ответы на следующие вопросы.
1)Можно ли ngnix использовать в качестве фронтенда под несколько апачей?
2) Плюсы и минусы изложенной архитектуры с учётом наличия на сервере 30,50 и 100 сайтов.
3) Возможно кто-то знает более граммотную реализацию того, что я изложил выше и может поделиться своим опытом?Ссылки на актуальные для темы гайды будут также весьма ценны.
Заранее спасибо всем за ответы.
>Почитав немного о том, какими способами можно каждому виртуальному домену присвоить своего
>юзера, сделал вывод, что самым стабильным и оптимальным является запуск нескольких
>копий апача, по 1 для каждого юзера. Минусом этого вариант насколько
>я понимаю является значительное увеличение потребляемых ресурсов.Если раньше все работало на одном апаче под одним юзером, то, вероятно, все уже давно украли :))
Чтобы этого избежать можно сделать теперь два апача. Один под проблемного клиента, другой для остальных. В целом это не правильно, но я не спрашиваю насколько ты стеснен в аппаратном обеспечении, насколько ценные данные хранятся на сервере и насколько быстро нужно все уладить. Просто как вариант...
В идеале, конечно, правильно было бы рассадить каждого клиента в свою песочницу или виртуальную машину. Это ресурсозатратно, но, если ты хостер и тарифными планами ограничиваешь память и процессорное время, то другого пути нет.>Поэтому пришла мысль сделать следующий вариант.
>
>Запустить ngnix в качестве фронтенд, в то время как несколько апачей будут
>работать на бэкенде. Так как апачи будут обрабатывать запрос ngnix и
>отдавать ответ мгновенно, то это не должно создать проблем с потреблением
>большого количества ресурсов апачами, но в этом могу ошибаться, так как
>не опытен в этом вопросе,Вообще апач имеет встроенные средства разделения виртуалхостов на каждого юзера. Смысл тот же, что и раздача персонального апача каждому юзеру. Но, например, в общем апаче не получится отдельному пользователю установить свою персональную версию пхп. Соответственно, если юзеры не захотят ходить строем, то придется поднимать отдельные апачи.
Апач, как бэкенд, работает как и работал. Фронтенд только снимает с него часть простой работы и оставляет сложную. Разгрузка происходит из-за того, что фронтенд умеет отдавать статику, легко и быстро, а апачу для этого нужно больше ресурсов.>Можно ли ngnix использовать в качестве фронтенда под несколько апачей?
можно, но не забудь с какими правами ты будешь хранить файлы каждого юзера и какими правами наделен nginx. Nginx, в отличие от апача, не умеет с каждым виртуалхостом работать от имени отдельного юзера. Если твоя модель безопасности это позволяет, то почему нет.
Ну и советую сперва новую модель своего хостинга потестировать долго и вдумчиво. Все-таки с такими познаниями безопаснее учиться, а не сражаться...
>Если раньше все работало на одном апаче под одним юзером, то, вероятно,
>все уже давно украли :))Именно это и сделали, но ту проблему мы уже уладили, важно, чтобы это не повторилось :)
>В идеале, конечно, правильно было бы рассадить каждого клиента в свою песочницу
>или виртуальную машину. Это ресурсозатратно, но, если ты хостер и тарифными
>планами ограничиваешь память и процессорное время, то другого пути нет.А можно для инетереса узнать примерную разницу в ресурсопотреблении, если 10 виртуальных хостов будут висеть на хосте в обычном варианте, или же, если каждого из них рассадить в песочницу?
>Вообще апач имеет встроенные средства разделения виртуалхостов на каждого юзера. Смысл тот
>же, что и раздача персонального апача каждому юзеру.А можно узнать об этих средства? Всё, что мне удалось найти в этом направлении, это какое-то кастом поделии каких-то сторонних разработчиков, которые открыто написали, что за стабильность поделия не ручаются.
>>Можно ли ngnix использовать в качестве фронтенда под несколько апачей?
>
>можно, но не забудь с какими правами ты будешь хранить файлы каждого
>юзера и какими правами наделен nginx. Nginx, в отличие от апача,
>не умеет с каждым виртуалхостом работать от имени отдельного юзера. Если
>твоя модель безопасности это позволяет, то почему нет.Как я понял из этого поста, если использовать ngnix для фронтенда, а апач для бэкенда, то часть работы ляжет на ngnix и ему нужен будет доступ к файлам юзеров? Думал он с кэшем будет работать.
И как вариант хочу спросить заранее, если ngnix должен иметь доступ к файлам юзеров, то есть ли смысл при разделении доменов под разных юзеров - подымать под каждого юзера свой ngnix?
>Ну и советую сперва новую модель своего хостинга потестировать долго и вдумчиво.
>Все-таки с такими познаниями безопаснее учиться, а не сражаться...Сейчас как раз выдалась возможность потестить всё на свободной машине,именно поэтому я решил этим заняться :)
Заранее спасибо за помощь.
>>Вообще апач имеет встроенные средства разделения виртуалхостов на каждого юзера. Смысл тот
>>же, что и раздача персонального апача каждому юзеру.
>
>А можно узнать об этих средства? Всё, что мне удалось найти в
>этом направлении, это какое-то кастом поделии каких-то сторонних разработчиков, которые открыто
>написали, что за стабильность поделия не ручаются.http://www.opennet.me/opennews/art.shtml?num=19842
Вот что поближе, а по ключевым словам еще и в гугле полно>Как я понял из этого поста, если использовать ngnix для фронтенда, а
>апач для бэкенда, то часть работы ляжет на ngnix и ему
>нужен будет доступ к файлам юзеров? Думал он с кэшем будет
>работать.Откуда же кэшу взяться без доступа к файлам. Не чужой же обрабатывать :)
>И как вариант хочу спросить заранее, если ngnix должен иметь доступ к
>файлам юзеров, то есть ли смысл при разделении доменов под разных
>юзеров - подымать под каждого юзера свой ngnix?С точки зрения повышения безопасности смысл есть, а в плане экономии ресурсов - смысла меньше... Это уж тебе решать.
Если хотите действительно высокой надежности, то используйте vserver/openvz. Дополнительная нагрузка в основном будет на память. На железной ноде nginx, на пользовательских апач. Сервер БД можно как в отдельный контейнер общий для всех, так и по копии в каждый.
>Если хотите действительно высокой надежности, то используйте vserver/openvz. Дополнительная нагрузка в основном
>будет на память. На железной ноде nginx, на пользовательских апач. Сервер
>БД можно как в отдельный контейнер общий для всех, так и
>по копии в каждый.Распишите пожалуйста подробнее, что вы имели ввиду, или можно даже ссылку на какой-нибудь гайд.
На общий вопрос можно дать лишь общий ответ. Гайды они обычно с конкретикой, которая может не совпадать с вашей, например в гайде lighttpd+postgresql на основной машине и factcgi+django/ror/catalyst в контейнерах, а вам лучше nginx на основной и apache+mod_php+mysql в контейнерах.
Так что просто прочитайте на вики и офсайте про OpenVZ и придумайте подходящую вам схему. Установка, настройка и использование OpenVZ очень хорошо описаны в его родной доке и не представляют собой никаких сложностей, nginx или apache и то сложнее настроить.
>На общий вопрос можно дать лишь общий ответ. Гайды они обычно с
>конкретикой, которая может не совпадать с вашей, например в гайде lighttpd+postgresql
>на основной машине и factcgi+django/ror/catalyst в контейнерах, а вам лучше nginx
>на основной и apache+mod_php+mysql в контейнерах.
>Так что просто прочитайте на вики и офсайте про OpenVZ и придумайте
>подходящую вам схему. Установка, настройка и использование OpenVZ очень хорошо описаны
>в его родной доке и не представляют собой никаких сложностей, nginx
>или apache и то сложнее настроить.спасибо, попробую.