Shared Hosting Security

Yurik · 22 Мар 2004

Shared Hosting Security

Всем доброго. Извиняйте что поднимаю новую тему, вопрос старый но открытый, тредов и статей много а ответа нет.
Безопасность шаред хостинга. Постоянная война хостеров и программистов. А всё из-за mod_php.
Хотелось бы в одном месте услышать что нужно требовать от своего хостера при наличии
FTP, SSH, Apache (mod_php, mod_perl)

А то многие хостеры факт что у них можно читать чужие файлы спихивают на то что а кто вам виноват что вы используете ПХП, это ж примитивная технология, потому и защиты никакой.

Особенно хочеться услышать fixxxer` о том каким должен быть uid/gid/chmod/umask

P.S. Слышал краем уха о каких то заплатках к юниксу/апачу.

confguru · 22 Мар 2004

Запостил в новости...

Представители хостеров и продвинутые программисты - приглашаем к диалогу...

Думаю получим - список рекомендаций и как не надо настраивать сервера с PHP

P.S. Убедительная просьба о уязвимостях писать представителям - соответсвующих серверов..

-~{}~ 22.03.04 15:38:

Вот к примеру решение от Boulat Khakimov

New virtual_root_level directive for PHP-4.3.4

Description
This is yet another directive to attempt to solve the shared-server security problem.
This directive is NOT affected by whether Safe Mode is turned On or Off.

virtual_root_level directive limits the files that can be opened by
PHP to the specific directory-tree. The directory-tree is determined
on the fly depending on the location of the php script executed and
the value that virtual_root_level is set to.

For example if virtual_root_level = 3 in php.ini
and we execute PHP script /home/www/domain.com/www/test.php
then test.php will NOT be able to open files outside
of /home/www/domain.com directory-tree unless there are additional
paths specified in open_basedir.

This is how virtual_root_level value should be calculated
/home/www/domain.com/www/test.php
^ ^ ^ ^
0 1 2 3

For best results virtual_root_level should be used TOGETHER with open_basedir. eg.

open_basedir = .:/tmp:/usr/local/php
virtual_root_level = 3

Below is the pseudocode to give an idea how virtual_root_level works together
with open_basedir directive.

if (virtual_root_level_check PASSED) {
return ALLOWED;
}
else if (open_basedir_check PASSED) {
return ALLOWED
}
else {
return DENIED;
}

The default is to allow all files to be opened.

Installation
http://www.boulat.net/projects/virtual_root_level/
Download the patch copy it into your php-4.3.4 source tree directory,
from there run 'patch -p0 < virtual_root_level.patch' then compile/build php the way
you always do. Recompile apache . Dont forget to add virtual_root_level directive
to your php.ini. Restart apache.

si · 22 Мар 2004

virtual_root_level

теже костыли что и open_baseidr и safe_mode (признаюсь что сам их использую) единственно надежный способ, это заставить выполняться mod_php от юзера так же как это работает с использованием suexec, но тут без опасных модификаций апача или специальных модулей для ядра необойтись ...

Yurik · 22 Мар 2004

Решение для скрытия паролей к MySQL

#chown root httpd.conf
#chmod 600 httpd.conf

<VirtualHost *>
ServerName shared1.ru
php_value mysql.default_host localhost
php_value mysql.default_user shared1
php_value mysql.default_password **********
</VirtualHost>

Всем пользователям хостинга сказать чтобы юзали mysql_connect() без параметров

Недостаток: имея доступ на запись к любой папке в виртуальном хосте можно написать скрипт получения доступа к базе пользователся. Но если есть доступ на запись то это уже в любом случае ж...

anight · 22 Мар 2004

1) safe_mode on обязательно в любом случае ДОЛЖЕН быть на shared хостинге
2) модель apache 1.3 сильно затрудняет решение subj задачи. если ее пытаться решить правильно - т.е. для каждого virtual host свой uid в системе - то придется дописывать и apache и ядро:
ядро должно по запросу главного (root) apache уметь переключать r/e uid для детей, а главный apache должен уметь следить за ними, чтобы после выявления virtual host к которому происходит запрос - вызывать эту самую функцию переключения.
тут же сразу встает много других security ньюансов.
кстати, насколько я помню - до сих пор не решен вопрос с наследованием listening socket - http://www.guninski.com/php1.html
как вариант - решение для linux - можно изменить apache следующим образом -
чтобы accept делал главный apache и все http заголовки клиента парсились им,
а затем выбраному child выставлялись права (см выше) и передавался дескриптор с соединением (как это делается в lingerd - http://www.gnu.org/directory/network/servers/lingerd.html)

какие тут есть загвоздки ?

si · 22 Мар 2004

чтобы accept делал главный apache и все http заголовки клиента парсились им,

тогда открываем соединение и ждем, получается DoS ...

Yurik · 22 Мар 2004

http://ukrainianhosting.com/

так для примера возьмем один из сайтов этого shared hosting (там юзеров почти 750)

`cat /etc/passwd
`cat /home/podshipn/public_html/config.inc.php
================

PHP:

$php_hostname="localhost";
$php_mysqluser="podshipn_user";
$php_mysqlpassword="************";
$php_dbname="podshipn_db";
$SITEDIR="http://podshipnik.kharkov.ua/";
$SITETITLE="ЧП ПОДШИПНИК";
$PREFIX="podshipnik";

ForJest · 23 Мар 2004

Лучший способ Shared hosting security IMHO это Virtual Private Server. Если тебе дороги твои данные - ты не будешь юзать Shared Hosting. Если живёшь в коммуналке - не удивляйся, что кто-то ест твои продукты из холодильника.

fixxxer · 23 Мар 2004

Простое и эффективное решение - форкать деток апача под нужными uid/gid.
Можно пропатчить функцию ap_process_request() (простой vfork() - дешево и сердито), можно использовать написанные для этой цели модули (ссылки точно не помню, но таковых есть как минимум три, все устроены примерно одинаково).
Недостаток - основной httpd работает от рута, и, если будет обнаружена дыра из разряда buffer overrun, она становится гораздо более серьезной. С другой стороны, код, выполняющийся (по крайней мере, в случае патча ap_process_request, код модулей подробно не изучал) от рута, в этом случае вполне прозрачен, и вроде бы там и негде накосячить особо... Можно еще пропатчить ядро ОС, дабы разрешить setuid/setgid апачевому юзеру - но это совсем уж жуткий хак получится.

Ну, а стандартное решение - open_basedir+safe_mode - оно конечно хорошо, хотя и является своего рода затычкой, но здесь не стоит забывать о том, что файлы в /home/login/www как из под юзерского, так и из под апачевого uid должны создаваться с одинаковыми uid/gid и атрибутами - это решается (с использованием chmod +s на /home/login/www), но поскольку к безопасности это напрямую не относится, расписывать подробно не буду.

si · 23 Мар 2004

еще пропатчить ядро ОС, дабы разрешить setuid/setgid апачевому юзеру - но это совсем уж жуткий хак получитс

ну лучше чем апаче от рута.

простой vfork() - дешево и сердито),

http://php4you.kiev.ua/docs/dk/apache_hack.html
ты про это ? очень хороший способ дать своим юзерам рута

статья очень опасная, автро кстати счтитает себя умнее Apache Team

Altex · 23 Мар 2004

Автор оригинала: fixxxer
Ну, а стандартное решение - ...

но поскольку к безопасности это напрямую не относится, расписывать подробно не буду.

сказал А - говори Б

Silex · 23 Мар 2004

Ситуация. Крупный украинский хостинг-провайдер переносил на новое железо и ПО. До переноса open_base_dir был, после переноса то ли не успели поставить, то ли забыли. Мы, зная, что ограничение open_base_dir есть, не заботились о правах на файлы, результат - в первые же сутки дефейс сайта и одного из соседей по хостингу, поскольку о переносе сервера ничего не знали. Да, лопухнулись и понадеялись на хостера, ну так и хостер мог сначала сделать, а потом открывать сервер, а не латать дыры по факту. Начали выяснять. Вот к чему пришли. Из последней переписки:

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

Это нормально?

confguru · 23 Мар 2004

Silex

Если хостинг за 5баксов - то да нормально..
Если больше >=20 то нужно задуматься..

fixxxer · 23 Мар 2004

Автор оригинала: si
ну лучше чем апаче от рута.

Лучше. Но звучит жутко

http://php4you.kiev.ua/docs/dk/apache_hack.html
ты про это ? очень хороший способ дать своим юзерам рута
статья очень опасная, автро кстати счтитает себя умнее Apache Team

Похожий способ, но я где-то в другом месте читал - видимо уже "доработки" этого решения

MiRacLe · 23 Мар 2004

Dmitry Koteroff 08/02/2004
Патч НЕ грамотный. В нем есть ошибка, из-за которой, во-первых, не работают сессии в PHP, а во-вторых, пользователь PHP может получить root-доступ к машине. В принципе, ничего не стоит это исправить достаочно просто разобраться, как работает этот патч и отловить, почему не работают сессии в PHP (методом вставики fprintf в исходники Apache). В щелях безопасности нашего хостинга я исправления не выкладываю (вдруг в них тоже ошибка?). И вообще, эта статья незаконна и была убрана с официального сайта спустя пару недель после выхода (по соображениям безопасности компании опять же). ак что дерзайте.

Net.Ru · 24 Мар 2004

Автор оригинала: si
теже костыли что и open_baseidr и safe_mode (признаюсь что сам их использую) единственно надежный способ, это заставить выполняться mod_php от юзера так же как это работает с использованием suexec, но тут без опасных модификаций апача или специальных модулей для ядра необойтись ...

Не стоит преувеличивать "опасность" модификаций. Но они (модификация ядра) самые эффектиные. Других приемлимых решений нет.

Есть еще вариант - каждому пользователю по своему апачу, но он для массового хостинга все-таки дороговат повышенными накладными расходами на висение в памяти ненужных процессов.

Лев · 24 Мар 2004

Автор оригинала: Net.Ru
Есть еще вариант - каждому пользователю по своему апачу, но он для массового хостинга все-таки дороговат повышенными накладными расходами на висение в памяти ненужных процессов.

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

Надо брать нормальный хостинг.

А делать всевозможные модификации, всеровно что зубы через задницу вырывать.IMHO

si · 24 Мар 2004

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

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

Alien · 24 Мар 2004

Ой да ладно. 500 хостинг-клиентов на одном сервере - это далеко не значит что все 500 апачей постоянно хоть чем то заняты.

GD · 24 Мар 2004

Автор оригинала: Alien
Ой да ладно. 500 хостинг-клиентов на одном сервере - это далеко не значит что все 500 апачей постоянно хоть чем то заняты.

а им и не нужно чем та заниматься, чтоб память отжирать

Shared Hosting Security

/dev/null

ExAdmin

Administrator

/dev/null

Новичок

Administrator

/dev/null

- свежая кровь

К.О.

Administrator

Новичок

unitecsys

ExAdmin

К.О.

просто Чудо

Новичок

Лев

Guest

Administrator

Новичок

GD

Guest