WordPress: безопасность и обновления без потери данных

Обновление WordPress — единственный способ закрыть уязвимости, но именно в этот момент сайт чаще всего ломается. Причина обычно не в самом обновлении, а в отсутствии копии, несовместимом плагине и правках ядра. Ниже — порядок действий, при котором безопасность растёт, а данные остаются на месте.

Инвентарь и базовые проверки

Начните с фактов: какая версия ядра, какие плагины и темы установлены, что устарело. WP-CLI даёт это одной командой и не требует входа в админку.

wp core version
wp plugin list --fields=name,status,version,update
wp theme list --fields=name,status,version,update
wp core verify-checksums

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

Копия перед обновлением

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

cd /var/www/site
wp db export /backup/db-$(date +%F-%H%M).sql
tar -czf /backup/files-$(date +%F-%H%M).tar.gz wp-content
wp db check
wp db optimize

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

Обновление через WP-CLI

Обновляйте поэтапно и после каждого шага открывайте сайт. Так проще понять, что именно сломалось.

wp core update
wp core update-db
wp plugin list --update=available --field=name
wp plugin update akismet contact-form-7
wp core verify-checksums

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

Staging и проверка совместимости

Тестовая копия снимает главный риск. Разверните сайт на отдельном домене или подкаталоге, закройте его от индексации и обновите там. Базу удобно переносить с заменой адреса.

wp db export staging.sql
wp search-replace 'https://site.ru' 'https://staging.site.ru' --all-tables --precise
wp option get siteurl
wp plugin list --status=active

Флаг —precise медленнее, но корректно обрабатывает сериализованные данные. Не заменяйте адреса обычным SQL-запросом: в настройках и метаданных встречаются сериализованные массивы, и простая замена ломает длины строк. После переноса проверьте формы, оплату, вход и письма. Только потом повторяйте обновление на проде. Убедитесь, что тестовый стенд закрыт от поисковых роботов.

Жёсткая настройка wp-config.php

Часть атак закрывается конфигурацией. Отключите встроенный редактор, включите HTTPS для админки и задайте уникальные ключи. Правки вносите в дочернюю тему или плагин, а не в ядро.

wp config set DISALLOW_FILE_EDIT true --raw
wp config set FORCE_SSL_ADMIN true --raw
wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_DISPLAY false --raw
wp config set WP_DEBUG_LOG true --raw

Связка WP_DEBUG и WP_DEBUG_DISPLAY false пишет ошибки в файл, но не показывает их посетителям. Убедитесь, что debug.log недоступен из веба. Ключи авторизации можно обновить командой wp config shuffle-salts: все сессии завершатся, зато украденные cookie перестанут работать. Это нормальная мера после подозрительной активности.

Вход, XML-RPC и права

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

wp user list --role=administrator --fields=ID,user_login,user_email
wp user update 1 --user_pass="$(openssl rand -base64 24)"
wp option get default_role
wp plugin list --status=active --field=name

Учётная запись admin с предсказуемым логином — плохая идея, но переименование через базу требует аккуратности. Проще создать нового администратора с нейтральным логином, проверить вход и удалить старого. Роль по умолчанию для регистрации должна быть минимальной: подписчик, а не автор. Каждый плагин — это код с правами сайта, поэтому неиспользуемые удаляйте, а не просто деактивируйте.

Мониторинг целостности и обновления

Безопасность — процесс, а не разовая настройка. Настройте автоматические обновления минорных версий ядра и уведомления о доступных обновлениях плагинов. Следите за файлами: появление php в uploads или изменение контрольных сумм ядра говорит о проблеме.

find wp-content/uploads -type f -name '*.php' -print
wp core verify-checksums --quiet || echo "checksums failed"
wp cron event list --fields=hook,next_run_relative
wp db check

Проверка uploads полезна, потому что изображения не должны быть исполняемыми. Если PHP в этой папке нужен, ограничьте его обработку настройками сервера. Логи веб-сервера и журнал входа стоит хранить хотя бы месяц: по ним видно, когда началась подозрительная активность.

Если сайт уже скомпрометирован

Сначала изолируйте сайт: переведите в режим обслуживания или закройте доступ, но не удаляйте улики. Смените пароли базы, администраторов и FTP, обновите ключи. Затем восстановите файлы ядра и плагинов из официальных архивов, а контент — из проверенной копии. Ищите причину: устаревший плагин, слабый пароль, чужой ключ SSH. Без устранения причины повторное заражение почти гарантировано.

Не редактируйте подозрительные файлы вручную, пытаясь «вычистить» код: современные вредоносы оставляют несколько точек входа. Сравнение с чистой копией и полная замена файлов надёжнее. После восстановления проверьте задания cron, пользователей и настройки URL.

Чек-лист

• Копия базы и wp-content лежит вне сайта, восстановление проверено.
• Ядро и плагины обновлены, контрольные суммы совпадают.
• Редактор файлов отключён, админка только по HTTPS.
• Двухфакторный вход у администраторов, лишние учётки удалены.
• Неиспользуемые плагины и темы удалены, а не отключены.
• Логи и целостность файлов проверяются регулярно.

Итог

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