Как ротировать SALT-ключи WordPress после компрометации

Что такое SALT-ключи WordPress и зачем их менять

В `wp-config.php` хранится набор криптографических ключей и salts, которые WordPress использует для подписи и защиты cookies авторизации. К ним относятся `AUTH_KEY`, `SECURE_AUTH_KEY`, `LOGGED_IN_KEY`, а также соответствующие значения `AUTH_SALT`, `SECURE_AUTH_SALT`, `LOGGED_IN_SALT` и другие salts.

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

Ротация особенно важна после кражи cookies, подозрения на выполнение произвольного кода, взлома учетной записи администратора или утечки резервной копии, содержавшей `wp-config.php`.

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

Что сделать перед ротацией

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

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

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

• Проверьте правильный путь к WordPress.
• Убедитесь, что WP-CLI запускается от нужного системного пользователя.
• Проверьте, что `wp-config.php` доступен этому пользователю для записи.
• Выясните, не создается ли файл во время деплоя из шаблона или Secret Manager.
• Подготовьте отдельный канал для повторной авторизации администраторов после операции.

cp -a /var/www/site/wp-config.php /var/www/site/wp-config.php.before-salt-rotation

Как изменить SALT-ключи через WP-CLI

Подключитесь к серверу и выполните команду с параметром `--path`, указывающим на каталог установки WordPress. Команду нужно запускать от пользователя, у которого есть доступ к файлам сайта и корректному PHP-окружению.

wp config shuffle-salts --path=/var/www/site

Как проверить результат

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

Откройте сайт в приватном окне браузера и проверьте вход. Пользователь, авторизованный до ротации, должен пройти авторизацию повторно. Также проверьте вход в `/wp-admin/`, работу ролей, создание новой сессии и основные функции сайта.

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

Проверка сайта после аннулирования сессий

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

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

Проверьте плагины, темы, загруженные файлы и недавно измененные PHP-файлы. Отдельное внимание уделите `mu-plugins`, каталогам загрузок, заданиям cron, конфигурации веб-сервера и дополнительным SSH-ключам. Если нет уверенности в чистоте системы, восстановите сайт из проверенной резервной копии или привлеките специалиста по реагированию на инциденты.

• Измените пароли пользователей WordPress, хостинга, SSH, базы данных и панели управления.
• Отзовите или перевыпустите API-токены, ключи интеграций и пароли приложений, если злоумышленник мог получить к ним доступ.
• Проверьте настройки электронной почты, платежных сервисов, CDN, резервного копирования и внешних интеграций.
• Обновите WordPress, плагины, темы и серверные компоненты после проверки совместимости.
• Сохраните журналы доступа до очистки или ротации логов, чтобы не потерять данные об инциденте.

Когда смена ключей не сработает или будет отменена

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

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

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

• Не редактируйте ключи вручную, задавая случайные короткие значения.
• Не копируйте новые salts между разными средами без необходимости.
• Не возвращайте старую резервную копию `wp-config.php` после ротации.
• Не считайте отсутствие ошибки WP-CLI доказательством полной очистки сайта.

Распространенные ошибки при ротации SALT-ключей

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

Еще одна ошибка — выполнить команду от имени `root`, а затем оставить конфигурацию с неподходящими владельцем или правами доступа. Это может нарушить последующие деплои или работу сервисов. Используйте минимально необходимые привилегии и после операции проверьте доступы.

Также не следует сразу удалять все журналы или перезапускать систему без плана. Сначала сохраните необходимые для анализа данные, а затем проводите очистку и усиление защиты.

• Не запускайте команду в каталоге другого сайта.
• Не публикуйте резервную копию конфигурации.
• Не пропускайте проверку сторонних токенов и паролей приложений.
• Не откладывайте поиск вредоносного кода после успешной ротации.