Як ротувати 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`, а потім залишити конфігурацію з невідповідним власником або правами. Це може зламати подальші деплої чи роботу сервісів. Використовуйте мінімально необхідні привілеї та після операції перевірте доступи.

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

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