Похоже, что одним из наиболее распространенных методов обеспечения безопасности в наши дни является перемещение на wp-config.phpодин каталог выше, чем корень документа vhost . Я никогда не нашел хорошего объяснения этому, но я предполагаю, что это сводит к минимуму риск того, что вредоносный или зараженный скрипт внутри рута прочитает пароль базы данных.

Но вы все равно должны разрешить WordPress доступ к нему, поэтому вам нужно расширить его, open_basedirчтобы включить каталог над корнем документа. Разве это не разрушает всю цель, а также потенциально подвергает злоумышленникам журналы сервера, резервные копии и т. Д.?

Или этот метод только пытается предотвратить ситуацию, при которой wp-config.phpлюбой http://example.com/wp-config.php, кто запрашивает , будет показан в виде простого текста , а не анализируется механизмом PHP? Это кажется очень редким явлением, и это не перевесит недостатки предоставления журналов / резервных копий / и т. Д. HTTP-запросам.

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

Заключение. После долгих обсуждений по этому вопросу появились два ответа, которые, на мой взгляд, следует считать авторитетными. Аарон Адамс делает хороший аргумент в пользу переноса wp-config, и chrisguitarguy делает хороший аргумент против этого . Это два ответа, которые вы должны прочитать, если вы новичок в ветке и не хотите читать все целиком. Другие ответы либо излишни, либо неточны.

Краткий ответ: да

Ответ на этот вопрос однозначно да , и сказать иначе совершенно безответственно .

Длинный ответ: пример из реальной жизни

Позвольте мне привести очень реальный пример с моего очень реального сервера, где перемещение wp-config.phpза пределы корневого веб-узла специально предотвращало захват его содержимого .

Баг:

Взгляните на это описание ошибки в Plesk (исправлено в 11.0.9 MU # 27):

Plesk сбрасывает переадресацию поддоменов после синхронизации подписки с планом хостинга (117199)

Звучит безобидно, верно?

Ну, вот что я сделал, чтобы вызвать эту ошибку:

1. Настройте поддомен для перенаправления на другой URL (например, site.staging.server.comна site-staging.ssl.server.com).
2. Изменен тарифный план подписки (например, конфигурация PHP).

Когда я сделал это, Plesk установил для субдомена значения по умолчанию: обслуживание содержимого ~/httpdocs/без активных интерпретаторов (например, PHP).

И я не заметил. Неделями.

Результат:

• В wp-config.phpвеб-корне запрос на /wp-config.phpзагрузку файла конфигурации WordPress.
• За wp-config.phpпределами веб-рута появляется запрос на /wp-config.phpскачивание совершенно безвредного файла. Настоящий wp-config.phpфайл не может быть загружен.

Таким образом, очевидно, что перемещение wp-config.phpза пределы корневого веб-узла имеет реальные преимущества в плане безопасности в реальном мире .

Как перейти wp-config.phpв любое место на вашем сервере

WordPress автоматически найдет один файл над вашей установкой WordPress для вашего wp-config.phpфайла, так что если вы его переместили, все готово!

Но что, если вы переместили его куда-нибудь еще? Легко. Создайте новый wp-config.phpв каталоге WordPress с помощью следующего кода:

<?php

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');

/** Location of your WordPress configuration. */
require_once(ABSPATH . '../phpdocs/wp-config.php');

(Обязательно измените указанный выше путь к фактическому пути вашего перемещенного wp-config.phpфайла.)

Если вы столкнулись с проблемой open_basedir, просто добавьте новый путь к open_basedirдирективе в вашей конфигурации PHP:

open_basedir = "/var/www/vhosts/example.com/httpdocs/;/var/www/vhosts/example.com/phpdocs/;/tmp/"

Это оно!

Разбирая аргументы в обратном

Каждый аргумент против wp-config.phpвыхода за пределы корня сети основывается на ложных предположениях.

Аргумент 1: если PHP отключен, он уже

Единственный способ, которым кто-то увидит, что содержимое [ wp-config.php] - это если они обойдут ваш сервер PHP-интерпретатором ... Если это произойдет, у вас уже есть проблемы: у них есть прямой доступ к вашему серверу.

ЛОЖЬ : сценарий, который я описал выше, является результатом неправильной конфигурации, а не вторжения.

Аргумент 2: Случайное отключение PHP является редким и, следовательно, незначительным

Если у злоумышленника достаточно прав для изменения обработчика PHP, вы уже облажались. Случайные изменения очень редки в моем опыте, и в этом случае было бы легко изменить пароль.

ЛОЖЬ : сценарий, который я описал выше, является результатом ошибки в общей части серверного программного обеспечения, влияющей на общую конфигурацию сервера. Это вряд ли «редко» (и, кроме того, безопасность означает беспокойство по поводу редкого сценария).

WTF : смена пароля после вторжения вряд ли поможет, если во время вторжения была обнаружена конфиденциальная информация. Действительно, мы все еще думаем, что WordPress используется только для случайных блогов, а злоумышленники заинтересованы только в порчи? Давайте позаботимся о том, чтобы защитить наш сервер, а не просто восстановить его после того, как кто-нибудь войдет.

Аргумент 3: Отказ в доступе wp-config.phpдостаточно хорош

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

FALSE : Представьте , что ваш сервер по умолчанию для виртуального хоста являются: нет PHP, нет .htaccess, allow from all(вряд ли необычное в производственной среде). Если ваша конфигурация каким-то образом сбрасывается во время обычной операции - например, при обновлении панели - все вернется в состояние по умолчанию, и вы будете выставлены.

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

WTF : Почему кто-то специально рекомендует меньшее количество уровней безопасности? Дорогие машины не просто имеют замки; у них также есть сигнализация, иммобилайзеры и GPS-трекеры. Если что-то стоит защищать, делай это правильно.

Аргумент 4: Несанкционированный доступ wp-config.phpне имеет большого значения

Информация о базе данных действительно единственная конфиденциальная информация в [ wp-config.php].

ЛОЖЬ : ключи аутентификации и соли могут быть использованы при любом количестве возможных атак.

WTF : Даже если учетные данные базы данных были единственными wp-config.php, вы должны быть напуганы злоумышленником, который заполучит их.

Аргумент 5: перемещение wp-config.phpвне веб-корня фактически делает сервер менее безопасным

Вам все еще нужно разрешить WordPress доступ [ wp-config.php], поэтому вам нужно развернуть, open_basedirчтобы включить каталог над корнем документа.

ЛОЖЬ : Предположим, wp-config.phpчто в httpdocs/, просто переместите его ../phpdocs/, и установите, open_basedirчтобы включить только httpdocs/и phpdocs/. Например:

open_basedir = "/var/www/vhosts/example.com/httpdocs/;/var/www/vhosts/example.com/phpdocs/;/tmp/"

(Не забудьте всегда указывать /tmp/или свой tmp/каталог пользователя , если он у вас есть.)

Вывод: файлы конфигурации всегда должны всегда находиться вне корневого веб-каталога.

Если вы заботитесь о безопасности, вы выйдете wp-config.phpза пределы своего веб-корня.

Самое главное, что он wp-config.phpсодержит некоторую конфиденциальную информацию: имя пользователя / пароль вашей базы данных и т. Д.

Итак, идея: переместить его за пределы корня документа, и вам не о чем беспокоиться. Злоумышленник никогда не сможет получить доступ к этому файлу из внешнего источника.

Но вот в чем проблема: на wp-config.phpсамом деле ничего не выводится на экран. Он определяет только различные константы, которые используются в вашей установке WP. Таким образом, единственный способ увидеть содержимое этого файла - это обойти интерпретатор PHP вашего сервера - он может .phpотобразить файл как простой текст. Если это произойдет, у вас уже есть проблемы: у них есть прямой доступ к вашему серверу (и, возможно, права суперпользователя) и они могут делать все, что захотят.

Я собираюсь пойти дальше и сказать, что нет смысла выходить wp-configза пределы корня документа с точки зрения безопасности - по причинам, указанным выше, а именно:

1. Вы можете ограничить доступ к файлу через конфигурацию вашего виртуального хоста или .htaccess - эффективно ограничивая внешний доступ к файлу так же, как если бы перемещение вне корня документа
2. Вы можете обеспечить строгое разрешение доступа к файлу, wp-configчтобы предотвратить чтение файла любым пользователем без достаточных привилегий, даже если он получает (ограниченный) доступ к вашему серверу через SSH.
3. Ваша конфиденциальная информация, настройки базы данных, используются только на одном сайте. Таким образом, даже если злоумышленник получит доступ к этой информации, единственным сайтом, на который он повлияет, будет установка WordPress, к которой wp-config.phpпринадлежит файл. Что еще более важно, у этого пользователя базы данных есть только права на чтение и запись в базу данных этой установки WP, и ничто иное - нет доступа для предоставления разрешений другим пользователям. То есть, другими словами, если злоумышленник получит доступ к вашей базе данных, это просто вопрос восстановления из резервной копии (см. Пункт 4) и изменения пользователя базы данных.
4. Вы резервное копирование часто. Часто это относительный термин: если вы публикуете 20 статей каждый день, лучше делать резервные копии каждый день или каждые несколько дней. Если вы публикуете сообщения раз в неделю, то резервного копирования один раз в неделю вполне достаточно.
5. Ваш сайт находится под контролем версий ( как этот ), что означает, что даже если злоумышленник получил доступ, вы можете легко обнаружить изменения кода и откатить их. Если у злоумышленника есть доступ wp-config, он, вероятно, перепутал что-то еще.
6. Информация о базе данных - действительно единственная важная вещь wp-config, и, поскольку вы осторожны с ней (см. Пункты 3 и 4), это не так уж сложно. Соли и тому подобное можно менять в любое время. Единственное, что происходит, это то, что он делает недействительными зарегистрированные файлы cookie пользователей.

Мне кажется, что wp-configвыход из документа пахнет безопасностью из-за неясности - а это очень соломенный человек.

Я думаю, что Макс это хорошо осведомленный ответ, и это одна из сторон истории. WordPress Кодекс имеет больше советуют :

Кроме того, убедитесь, что только вы (и веб-сервер) можете прочитать этот файл (это обычно означает разрешение 400 или 440).

Если вы используете сервер с .htaccess, вы можете поместить его в этот файл (в самом верху), чтобы запретить доступ любому, кто его просматривает:

<files wp-config.php>
order allow,deny
deny from all
</files>

Обратите внимание, что установка разрешения 400 или 440 для wp-config.php может помешать плагинам записывать или изменять его. В качестве примера можно привести плагины для кэширования (W3 Total Cache, WP Super Cache и т. Д.). В этом случае я бы выбрал 600 (разрешение по умолчанию для файлов в /home/userкаталоге).

Кто-то попросил нас войти, и я отвечу здесь.

Да, есть преимущества безопасности от изоляции вашего wp-config.php от корневого каталога вашего сайта.

1- Если ваш обработчик PHP будет сломан или изменен каким-либо образом, информация о вашей БД не будет раскрыта. И да, я видел это несколько раз на общих хостах во время обновления сервера. Да, сайт будет взломан в течение этого периода, но ваши пароли не будут повреждены.

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

3. Помните об уязвимости PHP-CGI, когда любой может передать? -S в файл и просмотреть исходный код. http://www.kb.cert.org/vuls/id/520827

В конце концов, это мелкие детали, но они помогают минимизировать риск. Особенно, если вы находитесь в общей среде, где любой может получить доступ к вашей базе данных (все, что им нужно - это пользователь / пароль).

Но не позволяйте небольшим отвлекающим факторам (преждевременной оптимизации) оказаться перед тем, что действительно необходимо для обеспечения безопасности сайта:

1- держать его всегда в курсе

2- Используйте надежные пароли

3- Ограничить доступ (через разрешения). У нас есть пост об этом здесь:

http://blog.sucuri.net/2012/08/wordpress-security-cutting-through-the-bs.html

Спасибо,

Определенно да.

Когда вы перемещаете wp-config.php за пределы общедоступного каталога, вы защищаете его от чтения с помощью браузера, когда злонамеренный (или случайно!) Обработчик php изменяется.

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

Я просто хочу пояснить, ради аргумента, что перемещение вашего файла wp_config.php не обязательно означает, что вы должны переместить его только в родительский каталог. Допустим, у вас есть структура, подобная / root / html, где html содержит установку WP и весь ваш HTML-контент. Вместо того, чтобы перемещать wp_config.php в / root, вы можете переместить его в нечто вроде / root / secure ..., которое находится как вне каталога html, так и вне корневого каталога сервера. Конечно, вам нужно убедиться, что php может работать и в этой защищенной папке.

Поскольку WP не может быть настроен для поиска wp_config.php в папке одного уровня, например / root / secure, вы должны сделать дополнительный шаг. Я оставил файл wp_config.php в / root / html и вырезал важные части (логин базы данных, соль, префикс таблицы) и переместил их в отдельный файл с именем config.php. Затем вы добавляете команду PHP includeв ваш wp_config.php, например так:include('/home/content/path/to/root/secure/config.php');

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

Кроме того, вы можете ограничить доступ к защищенной папке, создав там файл .htaccess с помощью:

order deny,allow
deny from all
allow from 127.0.0.1

Существует множество плохо написанных тем и плагинов, которые позволяют атакерам вводить код (вспомните проблему безопасности с Timthumb). Если я буду злоумышленником, зачем мне искать wp-config.php? Просто введите этот код:

var_dump( DB_NAME, DB_USER, DB_PASSWORD );

Вы можете попытаться скрыть свой wp-config.php. Пока WordPress делает всю важную информацию доступной для всех, скрывать wp-config.php бесполезно.

Плохая часть в wp-config.php не в том, что он содержит конфиденциальные данные. Плохая часть заключается в определении конфиденциальных данных как глобальной доступной константы.

Обновить

Я хочу прояснить проблемы define()и почему плохая идея - определять конфиденциальные данные как глобальную константу.

Есть много способов атаковать сайт. Внедрение скрипта - это только один из способов атаковать сайт.

Предполагая, что на сервере есть уязвимость, позволяющая злоумышленнику получить доступ к дампу памяти. Атакующий найдет в дампе памяти все значения всех переменных. Если вы определяете глобальную доступную константу, она должна оставаться в памяти до тех пор, пока скрипт не завершится. Создавая переменную вместо константы, есть большая вероятность, что сборщик мусора перезапишет (или освободит) память после того, как переменная больше не нужна.

Лучший способ защитить конфиденциальные данные - удалить их сразу после их использования:

$db_con = new stdClass();
$db_con->db_user = 'username';
$db_con->password = 'password';
$db_con->host = 'localhost';

$db_handler = new Database_Handler( $db_con );

$db_con = null;

После использования конфиденциальных данных присвоение nullперезапишет данные в памяти. Злоумышленник должен получить дамп памяти как раз в тот момент, когда $db_conсодержит конфиденциальные данные. И это очень короткое время в приведенном выше примере (если класс Database_Handler не сохраняет его копию).

Помимо преимуществ безопасности, он также позволяет вам держать ваш экземпляр WordPress под контролем версий, сохраняя при этом основные файлы WordPress как субмодуль / внешний. Вот как Марк Джакит настроил свой проект WordPress-Skeleton. См. Https://github.com/markjaquith/WordPress-Skeleton#assumptions для получения подробной информации.