Як перевірити цілісність файлів WordPress через WP-CLI

Що саме перевіряє WP-CLI

Під час перевірки WP-CLI порівнює локальні файли з еталонними контрольними сумами. Для ядра WordPress еталон формується для конкретної версії та локалі. Для плагінів і тем перевірка доступна переважно тоді, коли пакет поширюється через офіційний каталог WordPress.org і для нього є відповідні checksum.

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

Перевірка охоплює файлову систему, але не аналізує весь сайт. Вона не знаходить автоматично шкідливі записи в базі даних, заражені файли в uploads, небезпечний код у mu-plugins або скомпрометовані облікові записи.

• ядро WordPress;
• плагіни з офіційного каталогу, для яких доступні контрольні суми;
• окремі теми з офіційного каталогу;
• відмінності між очікуваним і фактичним станом файлів.

Підготовка до перевірки

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

Зафіксуйте час перевірки, симптоми проблеми та команди, які виконували. Не перезаписуйте підозрілі файли одразу — спочатку збережіть їх окремо, якщо це дозволяють правила реагування на інциденти.

WP-CLI краще запускати від системного користувача, якому належать файли сайту. Використання root без потреби підвищує ризик випадково змінити права або файли за межами потрібного каталогу.

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

pwd
wp core version
wp option get siteurl
wp option get home

Перевірка ядра WordPress

Основна команда перевіряє файли ядра поточної установки WordPress. Вона не повинна змінювати файли, а лише порівнює їх із контрольними сумами.

Запустіть її з каталогу сайту:

wp core verify-checksums

Як читати результат

Повідомлення про успішну перевірку означає, що файли, які входять до еталонного набору для цієї версії, збігаються. Це позитивний сигнал, але не доказ того, що весь сайт безпечний.

Якщо WP-CLI повідомляє про змінений файл, спочатку визначте, чи є зміна очікуваною. Наприклад, ручні правки ядра, залишки невдалого оновлення або помилка файлової системи можуть спричинити відмінність. Якщо файл зайвий, перевірте його походження та час зміни.

• Змінений файл не слід одразу видаляти.
• Відсутній файл може пояснювати помилки оновлення або нестабільну роботу.
• Зайвий PHP-файл у каталозі ядра потребує окремого аналізу.

Перевірка іншої версії або локалі

Якщо сайт не може коректно визначити версію або локаль, WP-CLI може не отримати відповідний еталон. У такому випадку спочатку перевірте стан установки та версію WordPress. Параметри для конкретної версії або локалі варто використовувати лише тоді, коли ви точно знаєте, яку редакцію встановлено.

Перевірка плагінів і тем

Після ядра перевірте плагіни, особливо якщо підозріла активність почалася після встановлення або оновлення розширення. Параметр --all охоплює всі встановлені плагіни, для яких команда може отримати еталонні checksum.

wp plugin verify-checksums --all

Що робити з результатами для плагінів

Якщо плагін має змінені файли, порівняйте їх із версією з надійного джерела та перевірте дату зміни. Не замінюйте розширення копією з випадкового сайту: це може додати ще один шкідливий компонент.

Для плагінів із платною ліцензією або приватного репозиторію офіційних checksum може не бути. Відсутність перевірки в цьому випадку не означає, що плагін заражений. Порівнюйте його з оригінальним архівом, отриманим від розробника, або використовуйте відомий чистий backup.

• Преміум-плагіни можуть не підтримувати перевірку через WordPress.org.
• Кастомні розширення не мають універсального еталона.
• Зміни в конфігураційних або згенерованих файлах потрібно оцінювати з урахуванням документації плагіна.

wp theme verify-checksums --all

Що контрольні суми не перевіряють

Навіть успішна перевірка ядра, плагінів і тем не виключає компрометацію. Зловмисник може не змінювати файли, які входять до офіційного набору, або зберегти шкідливий код в іншому місці.

Окремо перевірте wp-content/mu-plugins, оскільки must-use plugins автоматично завантажуються WordPress і часто залишаються поза увагою під час стандартного огляду. Також зверніть увагу на uploads: PHP-файли в каталозі завантажень можуть бути нормальною частиною окремих рішень, але часто потребують особливої перевірки.

Не ігноруйте базу даних. Шкідливі скрипти можуть бути вміщені в записи, віджети, налаштування, поля користувачів або опції. Перевірте невідомих адміністраторів, підозрілі cron-завдання, активні сесії, API-ключі та налаштування, які могли спричинити редиректи.

• база даних і таблиці з налаштуваннями;
• каталог uploads та інші нееталонні файли;
• mu-plugins і кастомний код;
• wp-config.php, файли вебсервера та завдання cron;
• облікові записи, токени, паролі й ключі доступу.

find wp-content/mu-plugins -type f -maxdepth 2 2>/dev/null
find wp-content/uploads -type f -name '*.php' 2>/dev/null
wp user list --role=administrator

Як діяти після виявлення змінених файлів

Спочатку збережіть копію підозрілих файлів, журнали вебсервера, PHP та доступу до панелі. Порівняйте час зміни файлів із часом входу адміністраторів, оновлень і появи симптомів. Це допоможе відрізнити випадкову технічну помилку від цілеспрямованої атаки.

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

Після локалізації проблеми змініть паролі WordPress, хостингу, SSH, FTP, бази даних і пошти. Відкличте API-ключі, перевірте двофакторну автентифікацію та видаліть невідомих адміністраторів. Якщо є ознаки активного доступу, тимчасово обмежте адмін-панель і зверніться до фахівця з реагування на інциденти.

Відновлення з backup може бути корисним, але лише після перевірки його дати та чистоти. Просте повернення копії без зміни викрадених паролів або усунення вразливості часто призводить до повторного зараження.

• Зберегти копію та логи до очищення.
• Перевірити причину кожної зміни.
• Відновлювати файли лише з перевіреного джерела.
• Закрити вразливість, через яку міг відбутися доступ.
• Після очищення повторити перевірку та спостерігати за логами.