Вопрос 1: как спрятать логин и пароль к базе, что б злодей не узнал его?

зависит от настроек того на чём крутится и где лежит

На сервере есть несколько сайтов, злоумышленник взломав один сайт может без проблем прочитать/изменить файлы соседнего сайта.

Вопрос 2: как защитить соседние сайты?

утилиты основанные на inotify

1. если шелл уже залили - никак

2. suphp/php-cgi+suexec/mpm_itk на выбор

утилита - tripwire хотя бы

На сервере есть несколько сайтов, злоумышленник взломав один сайт может без проблем прочитать/изменить файлы соседнего сайта.

Вопрос 2: как защитить соседние сайты?

утилиты основанные на inotify

inotify не защитит от изменения.

Жумлу обновлять вовремя надо.

Как и любой другой софт вообще.

не ту строку процитировал

Есть ли утилита, которая может следить за файлами сайта и в случае изменения/удаления/добавления будет вести учёт и отправлять его админу?

> если шелл уже залили - никак

есть методы защититься от залития шелла? или тут уже зависит от метода взлома?

suphp/php-cgi+suexec/mpm_itk на выбор

я так понимаю можно создать для каждого сайта по пользователю и использовать suexec/mpm_itk?

Главным вопросом остаётся вопрос N1, конфигурационный файл лежит к примеру site.com/configs/config.xml
Логин и пароль не шифрованные, злоумышленнику не составит труда слить или испортить БД!

Вопрос 1: как спрятать логин и пароль к базе, что б злодей не узнал его?

Да. Создаете структуру каталогов вида /home/userX/site, развешиваете пермишены, и радуетесь. В случае mpm_itk проще всего, но он есть не во всех дистрах.

Вопрос 1: как спрятать логин и пароль к базе, что б злодей не узнал его?

а) положить конфиг в config.php, который при внешнем запросе обрабатывается интерпретатором и показывает красивую пустую страницу

б) в .htaccess вписать

<Files config.xml>
Order allow,deny
Deny from all
</Files>

есть методы защититься от залития шелла? или тут уже зависит от метода взлома?

для начала отключить в php.ini, если возможно, allow_url_fopen() и все функции для работы с сокетами;

можно поставить mod_security, но тут уже нужны знания, чтобы его грамотно настроить и оттюнить

Меня интересует как спрятать логин и пароль от человека, который уже взломал сайт. Извне конфигурационный файл недоступен!

Уже никак. Гипотетически, можно применить симметричное шифрование, а ключ захардкодить в за-zend'енном скрипте, но это все равно лишь немногим усложнит жизнь взломщику.

Понятно. Спасибо!

> Вопрос 1: как спрятать логин и пароль к базе, что б злодей не узнал его?

http://www.ioncube.com/

Вопрос 2: как защитить соседние сайты?

http://www.php.net/manual/en/ini.core.php#ini.open-basedir

И я бы еще в сторону расширенных атрибутов доступа к файлам посмотрел, если на сервере ext* файловая система, чтобы код не напортили, да по хтакцесам своих редиректов не понаставили.

Жумлу обновлять вовремя надо.

Админы жумлы любят делать chmod -R 777 )

> http://www.ioncube.com/

Если у взломщика есть доступ к серверу, то не поможет: делаешь require('configuration.php'), потом print_r(new JConfig()). Как-то так.

http://www.php.net/manual/en/ini.core.php#ini.open-basedir

curl с использованием протокола file:// позволяет это обойти. Кроме него есть еще много способов.

> Вопрос 2: как защитить соседние сайты?

Если сайты живут в /hone/<username>/<sitename>:

chmod 0711 /home/
chmod 0700 /home/*

и использовать mpm_itk.

Для каждого сайта отдельный пользователь.

curl vs. open_basedir

http://www.php.net/manual/en/ini.core.php#ini.open-basedir

curl с использованием протокола file:// позволяет это обойти.

Тут написано, что это проблема закрыта ещё в 2005 году.

Кроме него есть еще много способов.

Было бы очень интересно про них послушать.

Какая версия джумлы?

> Тут написано, что это проблема закрыта ещё в 2005 году.

Ыыы… Не верьте всему, что пишут. В 2009 еще был баг с «file:file:////etc/passwd». Погуглите, найдёте эксплойт для 5.2.9.

Было бы очень интересно про них послушать.

http://www.google.ru/search?q=open_basedir+bypass

Найдёте и для 5.3.x.

> http://www.google.ru/search?q=open_basedir+bypass

Стыд мне, позор, признаю. Вот ведь чёрт, за дырами в PHP просто не угнаться...

На работу mpm_itk нареканий нет? Достаточно стабильно под нагрузками?

> На работу mpm_itk нареканий нет?

Не было. Правда, мы с него свалили на nginx + php-cgi + самописный Zend Extension, который ставил нужный UID/GID для каждого пользователя (в зависимости от UID/GID document root).