Как защитить wp-config.php и секреты WordPress

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

Защита строится из нескольких независимых границ: файл не попадает в Git и резервную копию без контроля, права Linux разрешают чтение только нужным пользователям, Nginx никогда не отдаёт его содержимое, а утёкший секрет можно быстро заменить.

Сначала узнайте реального владельца и путь

Не меняйте режим по чужому примеру. Команды ниже показывают канонический путь файла, права всех каталогов и пользователя PHP-FPM:

readlink -f /srv/www/example.com/current/wp-config.php
sudo namei -l /srv/www/example.com/current/wp-config.php
ps -C php-fpm -o user,group,pid,cmd

Ожидайте, что файлом владеет пользователь публикации, например deploy, а группа совпадает с группой пула PHP-FPM, часто www-data. Если код находится в другом каталоге или процесс работает под отдельным пользователем, используйте фактические значения.

Ограничьте права без потери чтения

Для модели deploy:www-data режим 0640 даёт владельцу чтение и запись, группе — только чтение, остальным — ничего. Перед применением сохраните копию файла вне веб-корня:

sudo install -o root -g root -m 0600 \
  /srv/www/example.com/current/wp-config.php \
  /root/wp-config.php.before-permissions
sudo chown deploy:www-data /srv/www/example.com/current/wp-config.php
sudo chmod 0640 /srv/www/example.com/current/wp-config.php

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

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

Запретите точный URL в Nginx

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

location = /wp-config.php {
    deny all;
    access_log off;
    log_not_found off;
}

Поместите правило внутри нужного server и до общего обработчика PHP. Затем выполните sudo nginx -t, примените reload и запросите /wp-config.php: ожидается 403 или 404, но никогда не содержимое PHP. Проверьте также обычную страницу, чтобы правило не затронуло сайт.

Отключите редактор PHP-кода в панели

Администратор WordPress по умолчанию может редактировать файлы темы и плагинов. Добавьте константу до строки, после которой WordPress просит прекратить редактирование файла:

define( 'DISALLOW_FILE_EDIT', true );

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

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

Не переносите секреты в небезопасное место

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

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

Проверьте, не отслеживает ли Git рабочий файл:

git -C /srv/www/example.com/current ls-files --error-unmatch wp-config.php
git -C /srv/www/example.com/current check-ignore -v wp-config.php

Первая команда должна завершиться сообщением, что путь не известен Git; вторая — показать правило .gitignore. Если файл уже был опубликован, немедленно замените пароль базы и salts. Очистку истории планируйте отдельно: она не отменяет факт утечки.

Подготовьте замену каждого секрета

Пароль пользователя MariaDB меняют административной SQL-командой, затем обновляют конфигурацию и проверяют сайт. Ключи WordPress получают заново с официального Salt API; их замена завершит активные сессии. SMTP-пароль и токены внешних плагинов отзываются в соответствующих сервисах.

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

Источники

• WordPress: hardening
• WordPress: editing wp-config.php
• WordPress: file permissions
• Nginx access module