Стоит ли переносить wp-config за пределы корневого каталога?

Question

Стоит ли переносить wp-config за пределы корневого каталога?

13 июл. 2012 г., 18:26:11

Просмотры: 76.6K

Голосов: 156

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

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

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

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

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

Ian Dunn

4.86K

безопасность кастомизация wp config

Комментарии

Нет необходимости вставлять свой выбор ответов и отвергать все остальные прямо в вопросе. Как видно ниже, для этого существует система голосования на StackExchange — чтобы голосовать за ответы, которые кажутся разумными, а авторы вопросов должны использовать механизм "принятого ответа" и собственные голоса за/против.

Kzqai

20 янв. 2014 г. 18:53:59

Я не делаю так в 99% своих вопросов, но в этом конкретном случае посчитал это уместным. На вопрос есть 8 ответов, некоторые из них довольно длинные/сложные, а некоторые имеют много голосов, несмотря на неточную информацию или отсутствие полезного вклада. Думаю, предложить полуавторитетное заключение полезно для тех, кто впервые читает обсуждение. Как всегда, читатели могут составить собственное мнение; я просто высказываю свою точку зрения как автор вопроса.

Ian Dunn

21 янв. 2014 г. 02:15:01

@Kzqai: Система голосования StackExchange — это демократический процесс, и участники часто 1) не понимают, о чем на самом деле спрашивает автор или что он пытается решить, и 2) не осознают валидность того или иного ответа. После того, как ответы поступили и голоса отданы, более чем полезно, если автор уточнит, какие ответы ему помогли. В конце концов, только автор вопроса знает это, и я бы хотел, чтобы так поступали чаще. Да, люди "голосуют за ответы, которые кажутся им разумными", но дадим автору последнее слово о том, что кажется разумным ему.

Mac

14 июл. 2017 г. 16:55:12

Ваш вопрос хороший. Однако ваши комментарии к ответам показывают, что у вас есть очень конкретная настройка с реальными внешними (т.е. не контролируемыми вами) ограничениями. Было бы честнее указать их сразу. Это имеет значение, если я полностью контролирую веб-сервер, PHP, а также systemd, или если open_basedir — это мой единственный способ ощутимо повлиять на безопасность. Также: "веские аргументы против" должны показывать, чем это вредно, а не просто перечислять причины, почему эта единственная мера может быть недостаточной. И учитывайте аудиторию.

0xC0000022L

18 авг. 2021 г. 11:32:13

Все ответы на вопрос

Комментарии

Если у вас есть баг в Apache, Linux или в голове администратора, то в любом случае вы в беде. В вашем сценарии вы не объясняете, почему вероятность ошибочной конфигурации выше именно в корне веб-сайта, а не в любом другом месте на сервере. Неправильно настроенный Apache, вероятно, сможет получить доступ к /../config.php так же легко, как и к /config.php

Mark Kaplun

4 дек. 2012 г. 23:14:30

Вы не "в беде в любом случае". Это очень вероятно, и даже доказуемо, что баг приведёт к сбросу корневой директории веб-сайта к стандартной, и в этом случае вы не "в беде" — ваш wp-config.php останется в безопасности. И это крайне маловероятно — настолько, что можно считать практически невозможным — что баг приведёт к произвольному сбросу корневой директории именно в ту папку, где вы разместили свой wp-config.php.

Aaron Adams

4 дек. 2012 г. 23:23:34

Насколько вероятен такой баг? Я не эксперт по безопасности, но никогда не слышал, чтобы такой вектор атаки использовался на практике. Я против рекомендации этого метода, потому что когда вам понадобится обслуживать сайт, вы не будете знать, где находится ваш wp-config, и это, скорее всего, сделает бесполезными большинство руководств, которые касаются этого файла. Вы, я и остальные комментаторы здесь разберёмся, что произошло, но для менее опытных людей это будет долгим и мучительным моментом "WTF".

Mark Kaplun

5 дек. 2012 г. 07:46:36

@MarkKaplun Аргумент "Люди, которые не читают Stack Exchange, могут запутаться" — довольно слабый аргумент против рекомендаций по безопасности на самом Stack Exchange. Когда больше людей осознают реальные опасности хранения конфиденциальных конфигурационных файлов в корневой веб-директории, больше людей вынесут эти файлы за её пределы, и больше руководств по WordPress будут помогать пользователям находить wp-config.php. Если вы считаете, что удобство важнее безопасности, это ваше мнение; просто тогда стоит чётко указать, что вы рекомендуете пользователям ставить удобство выше безопасности.

Aaron Adams

5 дек. 2012 г. 20:27:27

Аарон, спасибо за продуманный и детальный ответ. Ты прав, что просто сменить пароль после взлома недостаточно. Однако твой пример с Plesk меня всё ещё не убеждает. Это определённо проблема, но я не думаю, что перемещение wp-config — правильное решение в данном случае. То же касается сброса конфигурации vhost и т.д. Если твоему приложению требуется такой уровень безопасности, что ты беспокоишься о подобных уязвимостях, то тебе действительно нужно решать их более прямыми способами. Например, не использовать Plesk, потому что он всегда будет уязвим; убедиться, что конфигурация vhost безопасна по умолчанию...

Ian Dunn

6 дек. 2012 г. 01:47:29

Показать остальные 11 комментариев

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

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

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

Я утверждаю, что перемещение wp-config.php за пределы корневой директории не дает преимуществ с точки зрения безопасности — по следующим причинам:

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

На мой взгляд, перемещение wp-config.php за пределы корневой директории — это попытка обеспечить безопасность через скрытность, что является слабой защитой.

chrisguitarguy

21.5K

18 июл. 2012 г. 03:17:03

Комментарии

Да, это примерно то, о чем я думал. Рад знать, что я не один такой :) Я бы хотел оставить вопрос открытым еще на день-два на случай, если у кого-то будет убедительный контраргумент, но пока что это кажется мне правильным ответом.

Ian Dunn

18 июл. 2012 г. 04:56:05

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

Otto

12 авг. 2012 г. 18:19:02

Хорошее замечание. Исправил.

chrisguitarguy

12 авг. 2012 г. 19:36:42

Просто чтобы развеять возможный миф - разве невозможно, что что-то пойдет не так на стороне сервера, и PHP-код окажется выведенным на экран?

Stephen Harris

12 авг. 2012 г. 21:49:17

Конечно, возможно. Если mod_php не работает или PHP-файлы не передаются интерпретатору PHP, это может произойти. Если у вас настроен FCGI, то же самое возможно, если PHP-файлы не передаются процессу fcgi для интерпретации. Однако оба этих случая указывают на довольно серьезные проблемы, которые маловероятны.

chrisguitarguy

12 авг. 2012 г. 22:17:30

Показать остальные 7 комментариев

Я считаю, что ответ Макса является компетентным, и это одна сторона медали. WordPress Codex дает дополнительные рекомендации:

Также убедитесь, что только вы (и веб-сервер) можете читать этот файл (обычно это означает права доступа 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).

its_me

4.51K

13 июл. 2012 г. 19:13:49

Комментарии

Макс дал правильный ответ. +1 ему. Я просто пытаюсь дополнить его.

its_me

13 июл. 2012 г. 19:15:39

Aahan Krish, ты попал в самую точку. Спасибо за дополнение.

Max Yudin

13 июл. 2012 г. 19:26:34

Так если использовать htaccess для запрета HTTP-запросов к wp-config.php, разве это не даст тот же результат, что и перемещение файла за пределы корневой директории, но без риска раскрытия логов/бэкапов и т.д.?

Ian Dunn

13 июл. 2012 г. 20:59:10

@IanDunn Зависит от того, что является корневым каталогом документа — (1) Если WordPress размещен в подкаталоге внутри public_html, перемещение wp-config.php за пределы этого каталога означает, что он окажется внутри public_html. В этом случае вам придется использовать правила htaccess для запрета HTTP-запросов к wp-config.php. (2) Если WordPress установлен непосредственно в каталоге public_html, на один уровень выше => вы переместите его в каталог /home/user. В этом случае вы в относительной безопасности, так как файл находится за пределами корневого каталога документа. Вы также можете установить права доступа к файлу в 600 (или даже более строгие 440 или 400).

its_me

13 июл. 2012 г. 21:10:23

@IanDunn Как я уже сказал, это мое базовое понимание, и я не эксперт по безопасности. :)

its_me

13 июл. 2012 г. 21:10:58

Показать остальные 2 комментариев

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

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

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

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

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

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

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

1- Всегда поддерживайте его в актуальном состоянии

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

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

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

Спасибо,

Sucuri

289

12 сент. 2012 г. 15:41:08

Комментарии

Ребята, спасибо за ваши мысли. Думаю, мы уже затронули большинство этих моментов в других ответах и комментариях. 1) Да, это возможно, но редко; 2) Да, в этом есть преимущества, но они минимальны; 3) Да, это возможно, но такая уязвимость вряд ли повторится, и защита от неё — это что-то вроде игры "бей крота" или требования снимать обувь в аэропортах из-за того, что какой-то идиот однажды спрятал бомбу в ботинке. Это реакционные меры, которые вряд ли принесут пользу в будущем.

Ian Dunn

12 сент. 2012 г. 18:01:18

В ходе обсуждения вопрос эволюционировал от "Есть ли какие-то преимущества?" до "Ладно, преимущества есть, но перевешивают ли они риски?" Главный риск, о котором я говорю, — это необходимость расширять область openbase_dir, чтобы PHP получил доступ к скриптам за пределами корневой веб-директории. Многие хостинг-настройки — включая те, что используют Plesk (а их много), — хранят логи, бэкапы, приватные FTP-зоны, которые должны быть изолированы от веб-корня, и т.д. в директории выше веб-корня. Поэтому предоставление PHP доступа к этой директории может быть серьёзной уязвимостью.

Ian Dunn

12 сент. 2012 г. 18:04:58

@IanDunn с каких пор редкость события стала веским аргументом против принятия упреждающих мер безопасности? Кстати, ваш пункт о том, где PHP может открывать файлы, сегодня можно решить через hardening в systemd. Вся суть ИБ в том, что у злоумышленников бесконечно много путей для проникновения, а защитники могут противостоять только известным векторам атак. Поэтому принято комбинировать как можно больше профилактических мер для создания защитной сети, а не полагаться на единственный узел.

0xC0000022L

18 авг. 2021 г. 11:21:23

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

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

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

Max Yudin

6.38K

13 июл. 2012 г. 19:07:26

Комментарии

Если злоумышленник получил достаточно прав для изменения PHP-обработчика, вы уже в беде. По моему опыту, случайные изменения происходят очень редко, и в таком случае пароль можно легко изменить. Учитывая это, вы всё ещё считаете, что стоит рисковать раскрытием логов/бэкапов и т.д. из-за расширенной области видимости open_basedir?

Ian Dunn

13 июл. 2012 г. 21:01:21

У меня никогда не было доступа -rwx к директориям выше public_html, поэтому я не был знаком с open_basedir. Мои логи хранятся в отдельной директории, как и бэкапы. Думаю, так устроены все shared-хостинги.

Max Yudin

13 июл. 2012 г. 21:35:40

Хостинги сильно различаются; нет стандартной структуры директорий. Plesk (одна из самых популярных панелей управления для shared-хостингов) размещает логи в /var/www/vhosts/example.com/statistics/logs, а корневая директория сайта — /var/www/vhosts/example.com/httpdocs. Перенос wp-config.php в /var/www/vhosts/example.com/wp-config.php потребует предоставления скриптам доступа ко всей директории example.com.

Ian Dunn

14 июл. 2012 г. 03:03:12

Просто из любопытства, где хранятся ваши логи и резервные копии, если не в директории домена? Доступ к ним осуществляется через панель управления или как-то иначе?

Ian Dunn

14 июл. 2012 г. 03:04:10

Да, через панель управления.

Max Yudin

14 июл. 2012 г. 10:37:56

Показать остальные 2 комментариев

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

Поскольку WordPress нельзя настроить для поиска 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

Michael

143

3 окт. 2012 г. 16:44:03

Комментарии

Привет, Майкл, спасибо, что поделился. Ты пробовал это в реальной среде, чтобы проверить, работает ли? Я думаю, что директива open_basedir принимает целое дерево, так что для доступа к /root/secure из /root/html тебе нужно установить open_basedir в /root.

Ian Dunn

3 окт. 2012 г. 17:52:20

Чтобы твоя идея сработала, думаю, тебе нужно настроить структуру каталогов как /root/httpdocs/config/accessible, где httpdocs содержит логи, бэкапы и т.д.; config содержит wp-config.php, а accessible содержит WordPress и весь контент. Тебе придется изменить конфигурацию vhost и прочее, чтобы переназначить корневой каталог на accessible. Однако я не вижу преимуществ перед простым запретом HTTP-запросов к wp-config в стандартной настройке.

Ian Dunn

3 окт. 2012 г. 17:53:41

Согласно http://www.php.net/manual/en/ini.core.php#ini.open-basedir: "В Windows разделяй каталоги точкой с запятой. На всех остальных системах разделяй их двоеточием. Как модуль Apache, пути open_basedir из родительских каталогов теперь автоматически наследуются." Так что можно задать несколько каталогов, и не обязательно, чтобы они были в одном дереве.

Michael

3 окт. 2012 г. 22:34:38

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

Ian Dunn

4 окт. 2012 г. 01:05:53

@IanDunn хорошо разобрал это в ответе Аарона Адамса

AndrewC

5 дек. 2012 г. 03:02:10

Показать остальные 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 не сохраняет их копию).

Ralf912

5.31K

19 нояб. 2012 г. 22:57:05

Комментарии

Этот ответ не затрагивает суть вопроса напрямую. Любой разработчик плагинов может устроить настоящий праздник в вашем WordPress, если убедит вас установить его код и будет иметь злой умысел. Это ничем не отличается от добровольной установки вируса на вашу систему. Этот аргумент против перемещения wp-config.php бессмыслен. Это как сказать, что установка автомобильной бомбы по своей воле делает автомобильную сигнализацию бесполезной. Технически верно, но WTF?!?

Lance Cleveland

6 дек. 2012 г. 07:51:56

Нет, это не бессмысленно. Вопрос звучит так: Могу ли я защитить учетную запись базы данных, скрыв wp-config.php. И ответ однозначно: Нет. Это то же самое, если бы вы спросили: "Могу ли я защитить свою машину от бомб с помощью автосигнализации?" Нет никакой дополнительной пользы от скрытия вашего wp-config с точки зрения защиты доступа к базе данных или FTP-доступа. Оба находятся в глобальной области видимости. Я уверен, есть множество других способов для злоумышленников получить доступ к глобальным переменным без инъекции кода.

Ralf912

6 дек. 2012 г. 09:51:28

Я не вижу вопроса "можно ли защитить учетную запись базы данных, скрыв wp-config.php" в оригинальном вопросе. Оригинальный вопрос был "имеет ли смысл перемещать wp-config.php". Ответ, по моему мнению, однозначно да. Это как спросить, стоит ли запирать входную дверь, когда выходишь из дома. Утверждение "кто-то может легко разбить окно и проникнуть внутрь, так зачем беспокоиться" не отвечает на фундаментальный смысл вопроса. По моему мнению, вопрос звучал так: "Стоит ли прилагать дополнительные усилия для перемещения wp-config.php? Есть ли от этого КАКАЯ-ЛИБО польза?". Да. Как минимум, это отсеивает ленивых хакеров.

Lance Cleveland

10 дек. 2012 г. 17:28:25

Одна из самых распространенных практик безопасности... Вы упустили очень (очень, очень) важный момент: Что интересует злоумышленника? И это не то, как вы оформили свой wp-config.php. Злоумышленника интересуют значения, которые вы определили в wp-config. Возьмем ваш пример с входной дверью: Скрытие wp-config - это все равно что запереть входную дверь, но хранить все свое золото незащищенным в саду. Все значения, определенные в wp-config, объявляются глобально. Поэтому они все доступны вне wp-config. Даже если вы скроете wp-config, значения все равно останутся доступными.

Ralf912

11 дек. 2012 г. 13:21:45

Я думаю, что те, кто выступает за его перемещение, пытаются защититься от сценариев, когда wp-config.php может отображаться в виде обычного текста через HTTP-запрос, а не от сценариев, когда он может быть доступен другому PHP-коду, работающему на хосте.

Ian Dunn

12 дек. 2012 г. 00:40:19

Показать остальные 2 комментариев

Извините, что поднимаю старую тему, но разве нет очевидного решения для всего этого? Мы знаем, что есть некоторая польза для безопасности при перемещении файла wp-config.php за пределы корневой директории WordPress. Некоторые утверждают, что преимущества минимальны, другие с этим не согласятся.

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

Наиболее очевидным решением для меня является создание файла secret-info.php вне корневой директории WordPress, который будет содержать переменные для всех имен пользователей и паролей, например:

$userName = "user";

$databasePassword = "12345";

Оставить файл wp-config.php в стандартной корневой директории WordPress, удалить значения имени пользователя и пароля из wp-config.php, но оставить все остальное. Затем просто сослаться на переменные $userName и $databasePassword, подключив secret-info.php в wp-config.php, например:

require('ПУТЬ-К-ФАЙЛУ/secret-info.php');

Кажется, это очевидное решение. Я что-то упускаю?

User

100

21 июл. 2020 г. 20:49:08

Комментарии

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

Ian Dunn

22 июл. 2020 г. 07:36:24

Прошли вечность, а WordPress по-прежнему размещает файл wp-config.php по умолчанию в корневой директории, доступный из веба, даже без добавления правил .htaccess для ограничения доступа к нему. Большинство shared-хостингов с установкой WordPress в один клик делают то же самое. В результате большинство сайтов на WordPress сконфигурированы именно так, и я ни разу не слышал, чтобы кто-то говорил: "Мой сайт взломали, потому что wp-config.php находился в корневой директории".

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

В результате WordPress 5.2+ в разделе "Здоровье сайта" не предлагает перемещать этот файл, и я не слышал о плагинах безопасности, которые бы это делали.

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

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

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

Mark Kaplun

23.7K

10 авг. 2021 г. 09:26:11

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

Emyr Thomas

361

18 июл. 2012 г. 00:18:38

Комментарии

Он настроил его в корневом каталоге документа, а не за его пределами, поэтому это не относится к данному вопросу. Метод, о котором спрашивается в вопросе, предполагает перемещение файла wp-config.php на один каталог выше корневого каталога виртуального хоста, а не просто на один уровень выше папки с установкой WordPress. Весь смысл в том, чтобы вынести его за пределы папки, доступной для HTTP-запросов.

Ian Dunn

18 июл. 2012 г. 01:59:08

Aaron Adams 1.72K · Accepted Answer · 2012-12-04T21:29:58Z

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

Ответ на этот вопрос — да, и утверждать обратное — возможно, безответственно.

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

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

Ошибка:

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

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

Звучит безобидно, не так ли?

Вот что я сделал, чтобы спровоцировать эту ошибку:

Настроил поддомен для перенаправления на другой URL (например, site.staging.server.com на site-staging.ssl.server.com).
Изменил тарифный план подписки (например, ее конфигурацию 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 автоматически ищет файл wp-config.php в директории на уровень выше установки WordPress, так что если вы переместили его туда, больше ничего делать не нужно!

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

<?php

/** Абсолютный путь к директории WordPress. */
if ( !defined('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 вашего сервера… Если это произойдет, у вас уже проблемы: у них есть прямой доступ к вашему серверу.

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

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

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

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

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

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

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

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

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

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

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

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

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

Даже если бы данные для подключения к базе данных были единственным, что хранится в 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 за пределы корневого каталога?

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

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

Ошибка:

Результат:

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

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

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

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

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

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

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

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

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

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

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

Аргумент 5: Перемещение `wp-config.php` за пределы корневой директории делает сервер менее защищенным