Если сайт WordPress предположительно взломан, не удаляйте файлы наугад. Сначала ограничьте риск для посетителей, сохраните текущее состояние и зафиксируйте признаки инцидента. Если сайт принимает платежи или персональные данные, подключите администратора инфраструктуры и ответственного за инциденты.
Что считать признаком компрометации
- Появились неизвестные администраторы, файлы или задачи по расписанию.
- Сайт перенаправляет посетителей на посторонние адреса либо отдаёт чужой контент.
- Хостинг сообщает о вредоносном коде, рассылке спама или аномальных запросах.
- На сайте появились предупреждения браузера или поисковых систем.
Одна необычная ошибка ещё не доказывает взлом. Соберите логи веб-сервера, PHP, WordPress и хостинга.
Первые действия
- Зафиксируйте время и симптомы. Сохраните логи и снимки экрана. Не публикуйте их вместе с паролями, токенами и личными данными.
- Ограничьте доступ злоумышленника. Вместе с хостингом примените защиту на уровне сервера, при необходимости временно закройте опасные операции. Не стирайте исходное состояние до снятия копии.
- Создайте отдельную копию текущего состояния. Она может содержать заражённые файлы: храните её изолированно, не разворачивайте на рабочем сайте.
- Проверьте администраторов и доступы. Ищите неизвестные учётные записи, API-ключи, SFTP/SSH-пользователей, панели хостинга, почтовые ящики.
- Смените с доверенного устройства пароли и ключи. Начните с хостинга, WordPress, БД, почты. Переиздание WordPress security keys завершает действующие сеансы, но требует контроля дальнейшего входа.
Очистка и восстановление
- Работайте на изолированной копии или staging, а не экспериментируйте на боевом сайте.
- Сравните ядро WordPress с официальным дистрибутивом. При доступном WP-CLI уместна проверка
wp core verify-checksums— она не проверяет содержимое БД, загрузки и все плагины. - Замените скомпрометированные плагины и темы чистыми версиями из доверенного источника. Пользовательские файлы и базу данных исследуйте отдельно.
- Проверьте
wp-config.php, конфигурацию сервера,.htaccess, задания cron, директорию uploads и подозрительные изменения в БД. - Восстановите сайт из проверенной чистой копии при наличии такой копии. Если источник заражения неизвестен, одна только переустановка WordPress не гарантирует безопасности.
Когда можно вернуть сайт в работу
До открытия доступа убедитесь, что устранена причина инцидента, пользователи и ключи проверены, резервная копия восстанавливается, обновления установлены, а логи и мониторинг включены. Если затронуты клиентские данные, оцените обязанности по уведомлению и сохранению доказательств.
Связанные материалы
Источник: https://wordpress.org/documentation/article/faq-my-site-was-hacked/
Материал был полезен?
Помогите нам сделать материалы точнее и понятнее.