Действительно ли перемещение wp-config вне веб-корня действительно выгодно?

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

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

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

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


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

122 голоса | спросил Ian Dunn 13 J000000Friday12 2012, 19:26:11

8 ответов


113

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

Ответ на этот вопрос - недвусмысленный да , и, в противном случае, полностью безответственно .


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

Позвольте мне представить очень реальный пример, с моего самого реального сервера, где перемещение 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

/** Абсолютный путь к папке WordPress. * /
если (! определено («ABSPATH»))
    define ('ABSPATH', dirname (__ FILE__). '/');

/** Местоположение вашей конфигурации WordPress. * /
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-интерпретатор |   Если это произойдет, у вас уже проблемы: у них есть прямой доступ к   ваш сервер.

FALSE . Сценарий, описанный выше, является результатом неправильной конфигурации, а не вторжения.

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

  

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

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

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

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

  

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

FALSE . Представьте, что ваши настройки по умолчанию для виртуального хоста: no PHP, no .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 для включения каталога над документом   корень.

FALSE . Предполагая, что 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 за пределы вашего веб-корня.

ответил Aaron Adams 4 TueEurope/Moscow2012-12-04T23:29:58+04:00Europe/Moscow12bEurope/MoscowTue, 04 Dec 2012 23:29:58 +0400 2012, 23:29:58
35

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

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

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

Я собираюсь продолжить и сказать , что нет смысла перемещать 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 из корня документа, защищает его от неясности - это очень соломенный человек.

ответил chrisguitarguy 18 J000000Wednesday12 2012, 04:17:03
24

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

  

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

     

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

<файлы wp-config.php>
разрешить заказ, отрицать
отказывать всем
& Lt; /файлы >

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

ответил its_me 13 J000000Friday12 2012, 20:13:49
15

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

Да, есть преимущества безопасности от изоляции вашего 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

спасибо,

ответил Sucuri 12 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 12 Sep 2012 16:41:08 +0400 2012, 16:41:08
14

Определенно ДА.

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

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

ответил Max Yudin 13 J000000Friday12 2012, 20:07:26
7

Я просто хочу пояснить, ради аргумента, что перемещение вашего файла 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 с помощью:

запретить, разрешить
отказывать всем
разрешить с 127.0.0.1
ответил Michael 3 +04002012-10-03T17:44:03+04:00312012bEurope/MoscowWed, 03 Oct 2012 17:44:03 +0400 2012, 17:44:03
4

Есть много плохих письменных тем и плагинов, которые позволяют атацерам вводить код (помните о проблеме безопасности с 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-> пароль = 'пароль';
$ db_con-> host = 'localhost';

$ db_handler = new Database_Handler ($ db_con);

$ db_con = null;

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

ответил Ralf912 20 22012vEurope/Moscow11bEurope/MoscowTue, 20 Nov 2012 00:57:05 +0400 2012, 00:57:05
-1

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

ответил Emzo 18 J000000Wednesday12 2012, 01:18:38

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132