Как защитить wp-config.php в WordPress: практические шаги

Почему wp-config.php нужно защищать в первую очередь

В wp-config.php обычно содержатся название базы данных, имя пользователя, пароль и адрес сервера базы данных. Там же хранятся AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY и соответствующие соли. WordPress использует эти значения для создания и проверки файлов cookie авторизации.

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

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

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

Запретите редактирование PHP-файлов из админки

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

Добавьте константу в wp-config.php до строки, которая сообщает о завершении редактирования. Ее следует объявить только один раз.

• После сохранения проверьте, что файл не содержит синтаксических ошибок.
• Для изменений кода используйте контролируемое развертывание, SFTP или SSH с персональными учетными записями.
• Эта константа не блокирует загрузку файлов, установку плагинов или выполнение уже присутствующего вредоносного кода.

define('DISALLOW_FILE_EDIT', true);

Где именно разместить константу

В типичной конфигурации строку добавляют в wp-config.php перед комментарием вроде "That's all, stop editing". Не вставляйте ее внутрь массива, условия или комментария. Если сайт работает в контейнере или использует автоматическое развертывание, убедитесь, что изменение не будет перезаписано во время следующего деплоя.

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

Включите HTTPS для административной части

Пароли, файлы cookie и данные сессий должны передаваться через защищенное соединение. Для принудительного использования HTTPS при входе и в административной части WordPress применяют константу FORCE_SSL_ADMIN.

Добавляйте ее только после того, как SSL-сертификат корректно работает на домене. Если HTTPS настроен частично, неправильная конфигурация может вызвать циклические перенаправления или сделать админку недоступной.

• Проверьте, что сайт открывается через https:// без предупреждений о сертификате.
• Убедитесь, что адреса WordPress и сайта используют HTTPS согласованно.
• После изменения проверьте вход, выход, загрузку медиафайлов и сохранение страниц Elementor.
• Если перед сайтом работает CDN или reverse proxy, убедитесь, что сервер правильно определяет исходный HTTPS-запрос.

define('FORCE_SSL_ADMIN', true);

Что проверить после включения

Откройте страницу входа в приватном окне браузера, авторизуйтесь и перейдите в несколько разделов админки. Проверьте, не появились ли ошибки mixed content, при которых часть ресурсов загружается через HTTP. Отдельно протестируйте редактор Elementor: сохранение изменений, предварительный просмотр и загрузку стилей.

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

Замените ключи и соли WordPress

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

Замена этих значений делает недействительными активные файлы cookie авторизации. После сохранения изменений все пользователи, включая администраторов, должны войти на сайт повторно. Это нормальное и ожидаемое поведение, а не признак неисправности WordPress.

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

Когда нужно повторить замену

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

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

Настройте права доступа и расположение файла

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

Права 600 означают, что владелец может читать и изменять файл, а другие пользователи не имеют доступа. Права 640 дополнительно разрешают чтение группе. Не устанавливайте права наугад: слишком строгое ограничение может нарушить работу сайта, а слишком широкое — открыть конфиденциальные данные другим процессам на сервере.

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

chmod 600 wp-config.php

Можно ли вынести wp-config.php за пределы публичного каталога

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

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

Защитите файл на уровне веб-сервера

Правила WordPress не могут исправить ошибочную конфигурацию Apache, Nginx или PHP. Если сервер начнет отдавать PHP-файлы как обычный текст, wp-config.php может раскрыть все секреты. В нормальной конфигурации PHP-файлы обрабатываются интерпретатором, но это все равно нужно проверить.

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

• Проверьте правила доступа к конфигурационным файлам и резервным копиям.
• Не оставляйте в публичном каталоге файлы с расширениями .bak, .old, .zip или копии конфигурации.
• Убедитесь, что ошибки PHP не выводят секреты на страницы, доступные посетителям.
• Ограничьте доступ по SSH, SFTP и к панели хостинга персональными учетными записями и включите двухфакторную аутентификацию, если она доступна.

Резервные копии и финальная проверка

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

После внесения изменений пройдите короткий чек-лист. Это поможет обнаружить проблему сразу, а не после жалобы пользователя или сбоя во время обновления.

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