Shared Hosting Security

[Falc]

si
>>если у вас 500 клиентов то вы предлагаете повесить 500 апачей по скажем минимум 5 чилдов, это 2500 процесов. больно вашему серверу не будет от этого ? а если там еще mod_perl+mod_php денег на памать хватить ?

Есть мнение что при наличии 500-та клиентов можно позволить себе не один сервер

 

[Alien]

Вот интересно, на одном хорошем jail-based хостинге сейчас

Mem: 1757M Active, 726M Inact, 388M Wired, 100M Cache, 199M Buf, 39M Free

а всего на этом сервере 333 клиента. И у каждого свой апач.
И как же оно живет?

 

[si]

а всего на этом сервере 333 клиента. И у каждого свой апач.
И как же оно живет?

и 333 jail ?
если апаче пустой (без mod_perl и php), то их 1000 в 1Gb с трудом влезет.

 

[andreyb]

Автор оригинала: si
если у вас 500 клиентов то вы предлагаете повесить 500 апачей по скажем минимум 5 чилдов, это 2500 процесов. больно вашему серверу не будет от этого ? а если там еще mod_perl+mod_php денег на памать хватить ?

Вопрос первый: Как это вы сможете запустить 500 разных апачей на 1 IP и 1 порту. На сколько я знаю все сетевые приложения требуют одну никем не используемую пару IPort. Или у вас есть 500 IP?

Второй вопрос: Почему open_basedir для вас не является защитой?? Если для каждого пользователя он будет настрое только на его домашний каталог, то никто из него и не выйдет, если конечно дырку в самом php не найдут. Ну а если найдут, то судьба везде находят, могут и в самом апаче найти.

Спасибо!!!

 

[fixxxer]

Или у вас есть 500 IP?

У меня есть около 15 миллионов IP - 10.x.x.x
...ну и Squid тоже не помешает

 

[Yurik]

Вопрос к съевшим зубы: насколько опасны модификации ядра системы/апача. Могу и в праве ли я требовать от провайдера такие меры? Какие аргументы ему привести в пользу этого.

 

[fixxxer]

Чем кривее руки - тем опаснее

 

[Tonn]

Автор оригинала: Yurik
Вопрос к съевшим зубы: насколько опасны модификации ядра системы/апача. Могу и в праве ли я требовать от провайдера такие меры? Какие аргументы ему привести в пользу этого.

Я потребовал и модифицировали. Аргументы привел, что разорил казино на соседнем сайте.

 

[ForJest]

А сколько жрёт один апач на одного юзера? С пресловутыми пятью чайлдами?
Почему хостеры не предлагают две услуги тогда уже один сервер без собственного апача и с safe_mode и base_open_dir, рядом второй подороже - со своим апачем. Вот и не было бы никаких проблем. И статеечку положить рядом почему на одно и другое стоит обращать внимание... И в договор включить, что за безопасность данных на сервере не со своей апачей мы ручаемся только относительно... Вот глядишь люди начнут хостеров спрашивать о безопасности данных, думать о своих данных ну и так далее...

А так получается что на коленке пишут ламе... т.е. начинающие программисты для заказчиков, которые вообще ни сном не духом о возможных проблемах.
Неведние выгодно хостерам в первую очередь. Типа - а вдруг пронесёт и к нам не пожалует тот самый военный программер. А мы таки да продадим электричество, которое жрёт сервер за $2500 в месяц и будем счастливы...

 

[si]

за безопасность данных на сервере

никто в с своем уме на хостенге (и не только) вам не будет отвечать за сохранность и безопасность данных

 

[ar2r]

У меня такая мысль родилась. Покритикуйте.

Повесить каждому свой апач на 127.0.0.1:xxxx запущеный с правами пользователя. И пробрасывать к нему коннекты извне через squid или apache+mod_proxy слушающие внешний IP на 80 порту.

Я особо не задумывался над +/- Так что-то в голову пришло....

 

[fixxxer]

я эту мысль высказал несколькими постингами выше

более того - я это пробовал делать
и это работает

 

[Net.Ru]

Да, это вполне хорошее решение. Единственный минус в том, что на среднестатистическом хостинг-сервере (около 500 сайтов) оно примерно на 60% повышает расход ресурсов машины по сравнению с аналогичным решением с "одним" апачем.

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

При цене хостинга от 20-30$$ в месяц вполне есть все основания выбирать хостинг с отдельным апачем - есть достаточное число предложений за такую цену и с такими возможностями.

Хотя, повторюсь, это не единственное решение для безопасности.

P.S. Но каталог для хранения сессий и все прочие "опасные" параметры нужно тщательно проверять самому. Как-то давно я уже писал о полезности носить со своими проектами максимально детально составленные php.ini и php_values в .htaccess. Т.к. большое число достаточно хороших провайдеров, которые продают дорогой хостинг с собственными апачами, оставляют session.save_path по дефолту - /tmp. Из тех, у кого лично видел - superb.net и alabanza.com.

 

[fixxxer]

Net.Ru
Многие хостеры предлагают выбор - свой апач или VirtualHost. Цена, само собой разумеется, отличается.

оставляют session.save_path по дефолту - /tmp

Это по недосмотру или по незнанию тонкостей конфигурирования php. Обычно достаточно написать один раз, и это исправляют. Если, конечно, это не тупой реселлер (был тут такой )...

Кстати, при своем апаче это не критично - главное не создавать файлы с атрибутом o+r

 

[Net.Ru]

Автор оригинала: fixxxer
Это по недосмотру или по незнанию тонкостей конфигурирования php. Обычно достаточно написать один раз, и это исправляют. Если, конечно, это не тупой реселлер (был тут такой )...

Наверное можно назвать это и недосмотром, но это обязанность разработчика подготовить проект так, чтобы он был максимально переносим. Чтобы если заказчик сайта поменяет хостера, ему не нужно было в очередной раз выяснять у хостера куда у него прописаны сессии и каждого нового просить переписать. А вто время разработчик может добавить в .htaccess/php.ini одну лишь строчку и обезопасить клиента от части проблем. А то что у многих хостеров по дефолу /tmp - это данность и ее не исправить точно так же как не сделать всех людей сытыми и богатыми.

В конце-концов, если у хостера прописано register_globals on, а у вас рассчитано на register_globals off, то не нужно требовать от хостера отключать globals в конфиге сервера, вместо того чтобы указывать его самому.

У superb.net кстати до сих по дефолту сессии идут в /tml.

Можно зайти на гугль и поискать по "phpinfo session.save_path /tmp", будет много интересного. Можно еще к поиску добавить домен какого-нибудь конкретного провайдера, посмотреть как дела обстоят у него.

Кстати, при своем апаче это не критично - главное не создавать файлы с атрибутом o+r

Это не панацея, можно либо подделывать новые сессии, либо узнавать идентификаторы существующих. Против этого рекомендуется хотя бы закрывать от чтения /tmp, чтобы нельзя было прочитать список файлов в каталоге,

 

[rudik]

1. Интересно было бы услышать о том, как можно похакать Apache, который запущен от root и пропатчен на запуск каждого ответа под uid/gid пользователя?

2. Кто-то писал что сессии не запускаются после патча - у меня таких проблем небыло.

3. Как иным способом заставить Apache сохранять закачанные на сервер файлы под именем пользователя, которому пренадлежит данный виртуальный хост?

 

[fixxxer]

Как иным способом заставить Apache сохранять закачанные на сервер файлы под именем пользователя, которому пренадлежит данный виртуальный хост?

Если апач работает не от логина пользователя, это не подходит.
Нужно сохранять с uid пользователя и gid апача или наоборот.
Это легко делается с помощью
chown user /home/user/www
chgrp www /home/user/www
chmod 660 /home/user/www
chmod +s /home/user/www
+ umask 005 на апача и юзера

-~{}~ 02.04.04 11:14:

не работают сессии в PHP, а во-вторых, пользователь PHP может получить root-доступ к машине.

Свой патч проверил. Сессии работают. Доступ к руту пытался получить из virtual, session_save_handler, shutdown_function(garbage collector) и auto_append_file - не получалось, всё от корректного юзера...

 

[andreyb]

А скажите чем так страшен session.save_path /tmp, и как лучше делать... Для общего развития...

 

[rudik]

Автор оригинала: andreyb
А скажите чем так страшен session.save_path /tmp, и как лучше делать... Для общего развития...

Вероятность чтения пользователями чужих сессий. /tmp директория должна находиться в директории пользователя (виртуального хоста).

 

[ClayRabbit]

А какой вообще смысл в open_basedir и virtual_root_level ?
При включенном safe_mode и safe_mode_exec_dir и без них все хорошо вроде.
А без safe_mode они ничего не гарантируют, разве что если все exec()-подобные функции начисто запретить. Но тогда еще симлинки останутся.

Т.ч. safe_mode + safe_mode_exec_dir + в апаче запрещаем FollowSymLinks и оставляем только SymLinksIfOwnerMatch (При етом, к сожалению, приходится исключать Options из AllowOverride, что, в частности, ведет и к невозможности использовать в .htaccess php-директивы). А шо делать... Без этого можно чужие пхп-скрипты через симлинку апачем брать...