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

Что именно проверяет WP-CLI

Во время проверки WP-CLI сравнивает локальные файлы с эталонными контрольными суммами. Для ядра WordPress эталон формируется для конкретной версии и локали. Для плагинов и тем проверка обычно доступна, если пакет распространяется через официальный каталог WordPress.org и для него существуют соответствующие checksum.

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

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

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

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

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

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

WP-CLI лучше запускать от имени системного пользователя, которому принадлежат файлы сайта. Использование root без необходимости повышает риск случайно изменить права или файлы за пределами нужного каталога.

• Создайте резервную копию базы данных и файлов.
• Убедитесь, что работаете именно с нужным сайтом.
• Запишите версию 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 может не быть. Отсутствие проверки в этом случае не означает, что плагин заражён. Сравните его с оригинальным архивом, полученным от разработчика, или с заведомо чистой резервной копией.

• Премиум-плагины могут не поддерживать проверку через 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-ключи, проверьте двухфакторную аутентификацию и удалите неизвестных администраторов. Если есть признаки активного доступа, временно ограничьте доступ к панели управления и обратитесь к специалисту по реагированию на инциденты.

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

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