Вынос configuration.php за пределы корня сайта - Безопасность сайтов на Joomla

Для повышения безопасности сайта и защиты конфигурационного файла от изменений извне со стороны взломщиков, рекомендуется выносить configuration.php за пределы корневого каталога сайта.

Сделать это довольно легко.

1. Выставите все необходимые настройки в configuration.php (позже у вас не будет возможности отредактировать глобальную конфигурацию через админ.панель Joomla)

2. Зайдите по FTP в корень сайта и сделайте копию configuration.php.

3. Переместите configuration.php за пределы корня сайта, например, на уровень ниже и создайте специальную папку:
Если путь к сайту такой: /home/xxxxx/docs/, то файл переносите в /home/xxxxx/security/ - где security - имя созданной папки.
переименуйте configuration.php на своё усмотрение (например, config.php).

4. Возвращайтесь в корень сайта и на место исходного configuration.php запишите новый файл с таким содержимым:



Где xxxxxx - путь к серверу из переменной $mosConfig_absolute_path, кот. можно посмотреть в оригинальном файле  configuration.php

5. Сохраняйте изменения и закачивайте на сервер.

6. Выставите права файлам configuration.php и config.php в 444.

Готово.

И от чего это спасет? Если у злоумышленника есть доступ к корневой директории, то никто ему не помешает точно так же подключить этот файл, и считать из переменных их значения. Ровным счетом никакого выигрыша от данного действия я не вижу. Если вор уже в квартире, то не важно, храните ли вы деньги в коридоре под зеркалом, или на лоджии в шкафчике.

У меня есть огромные сомнения по поводу того, что это хоть как-то усилит безопасность. Если у взломщика будет какая-то возможность изменять файлы извне, то куда конфиг не закопай - это не поможет. Ну отредактирую я другой файл извне, имя которого я знаю (допустим, что Вы назвали файл конфига не "config.php", а "FgfgDFFDfgffDFRR.php" для ещё большей безопасности).

В файл, который я смогу что-то записать я вставлю функцию чтения из файла configuration.php и вывожу на экран функцию инклуда. Теперь я знаю имя реального конфига. Дальше я читаю его содержимое и вывожу его на экран. Мне это сделать ничего не запретит.

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

тогда и
robots и .htaccess
выносить надо

Ну там доступы к БД не хранятся хотя бы
А вообще, конечно, не особо способ

Есть вот такое решение, опубликованное на сайте разработчиков RSFireWall.
http://www.rsjoomla.com/support/documentation/view-article/218-file-and-folder-access-check-checking-if-configurationphp-is-outside-of-public-html.html

Текст ниже переведён через Яндекс.

Есть несколько способов, чтобы защитить таких деликатных файлов из открытого доступа, но большинство из них не являются, насколько это возможно. Хороший способ защитить ваш configuration.php файл-это просто переместить его в не-public folder. Однако, обратите внимание, что это не просто скопировать и вставить операции, определенные изменения должны быть сделаны. Ниже мы предоставим шаг за шагом инструкции о том, как этого добиться.
Шаг 1 : Переместить configuration.php для безопасной директории вне public_html.
Шаг 2: Вам придется изменить /includes/defines.php и /administrator/includes/defines.php файлы, точнее, эта константа:
define ('JPATH_CONFIGURATION', JPATH_ROOT);
Если, например, вы хотите, чтобы переместить файл на один уровень вверх и в папку с именем "test" константа будет выглядеть так:
define ('JPATH_CONFIGURATION', JPATH_ROOT.DS.'..'DS.'test');
Шаг 3: Убедитесь, что configuration.php не для записи на всех, так что она не может быть переопределена com_config.
Шаг 4: Если вам необходимо изменить настройки конфигурации, сделать это вручную в переселены configuration.php.

Примечание:
Используя этот метод, даже если Веб-сервер каким-то образом обеспечивает содержимое PHP-файлов, например, в результате неправильной, никто не может увидеть содержимое реальный конфигурационный файл. Имея учетом недостатком, если не находиться в состоянии настроить глобальные параметры, это еще хороший метод защиты против mallacious атак.
----------------------------------------------------------------------------------------------------------------
Точно не помню но вроде бы у меня так не получилось поэтому сделал вот как:

define('JPATH_CONFIGURATION',   JPATH_ROOT.DS.'/../test');

 /public_html/administrator/includes/defines.php
define('JPATH_CONFIGURATION',   JPATH_ROOT.DS.'/../avtoconf');

Долго не мог врубиться как правильно написать эту строчу. И методом научного тыка сделал...
define('JPATH_CONFIGURATION', JPATH_ROOT . '/../вашкаталог');
Без всяких DS
Удачи!

Дополнение на версии Joomla 3.7.х. Кое что поменялось теперь надо так делать.
В моей версии хостинга: "Сюда перемещаем"/www/Мой сайт/
Изменяемем файл "defines.php" по пути. administrator/includes/defines.php открываем редактируем стоку 18 (Стока не критерий поиска) с текстом и дописываем до такого вида .
Меняем другой по пути "includes/defines.php" меняем тоже самое. В моём варианте как видите получилось на 2 шага вверх.

Дополнение на версии Joomla 3.7.х. Кое что поменялось теперь надо так делать.
В моей версии хостинга: "Сюда перемещаем"/www/Мой сайт/
Изменяемем файл "defines.php" по пути. administrator/includes/defines.php открываем редактируем стоку 18 (Стока не критерий поиска) с текстом

Код

define('JPATH_CONFIGURATION', JPATH_ROOT);

и дописываем до такого вида

Код

define('JPATH_CONFIGURATION', JPATH_ROOT . DIRECTORY_SEPARATOR . '/../../бла-бла');

.
Меняем другой по пути "includes/defines.php" меняем тоже самое. В моём варианте как видите получилось на 2 шага вверх.

Вот только толку от этого 0

Дополнение на версии Joomla 3.7.х. Кое что поменялось теперь надо так делать.
В моей версии хостинга: "Сюда перемещаем"/www/Мой сайт/
Изменяемем файл "defines.php" по пути. administrator/includes/defines.php открываем редактируем стоку 18 (Стока не критерий поиска) с текстом

Код

define('JPATH_CONFIGURATION', JPATH_ROOT);

и дописываем до такого вида

Код

define('JPATH_CONFIGURATION', JPATH_ROOT . DIRECTORY_SEPARATOR . '/../../бла-бла');

.
Меняем другой по пути "includes/defines.php" меняем тоже самое. В моём варианте как видите получилось на 2 шага вверх.

Если что то делать в плане защиты так это закрывать доступ к папке админа, или глобально, как в yii выносить админ часть на другой домен и хостинг. А манипуляции с конфигом полная ерунда.

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