Сайт восстановили из резервной копии. Каталог открывается, изображения на месте, административная панель работает. Но через несколько часов снова появляются чужие ссылки, перенаправления или подозрительные файлы. Приходится обращаться в поддержку ещё раз, и история повторяется.
Причина может быть в самой копии, в сохранившемся доступе злоумышленника или в уязвимости, через которую сайт взломали. Восстановление возвращает сохранённое состояние файлов и базы данных. Оно само по себе не определяет, было ли это состояние безопасным и закрыт ли путь для повторного проникновения.
Представьте магазин после кражи: товар вернули на полки, витрину привели в порядок, но украденный ключ всё ещё подходит к двери. Снаружи всё выглядит как прежде. Возможность войти осталась.
У повторного заражения бывает несколько разных причин:
- Вредоносный код уже находился в резервной копии. При восстановлении его вернули вместе с рабочими файлами. Нового взлома могло вообще не быть.
- Сохранилась первоначальная уязвимость. Например, восстановили старую версию плагина с известной ошибкой, и автоматическая атака снова получила доступ.
- У злоумышленника остались действующие доступы. Пароль, активный сеанс, ключ подключения или созданная им административная учётная запись позволяют вернуться после очистки.
- Источник заражения находился за пределами восстановленных файлов. Это может быть задание по расписанию, другой сайт с доступом к тем же каталогам или оставленный служебный скрипт.
Такой скрипт часто называют бэкдором — скрытым способом повторного доступа. Он может заново создавать удалённые файлы или выполнять другие действия. Если восстановили только папку сайта, а запускающее его серверное задание осталось, проблема вернётся.
Есть и более простая ловушка: распаковка чистого архива поверх существующего сайта не обязательно удаляет посторонние файлы. Злоумышленник мог добавить файл, которого в архиве никогда не было. Обычная перезапись известных файлов его не затронет.
Дата копии раньше появления симптомов ещё не доказывает, что копия чистая. Например, проникновение произошло в понедельник, а перенаправления заметили в пятницу. Архив за четверг вполне может содержать следы взлома, хотя в тот день магазин внешне работал нормально.
Поэтому при выборе копии смотрят не только на дату. Сопоставляют её содержимое с доступными журналами, проверяют файлы и базу, учётные записи и настройки. Если есть возможность, типовые файлы CMS, плагинов и тем сравнивают с официальными дистрибутивами соответствующих версий.
Для WordPress существуют проверки контрольных сумм ядра и плагинов из официального каталога. Они помогают обнаружить изменения, но имеют ограниченную область проверки. Успешная проверка ядра ничего не говорит о содержимом базы, пользовательских загрузках или серверных заданиях. А неизменённый официальный плагин всё ещё может быть устаревшим и уязвимым.
Антивирусный сканер тоже полезен, но его результат нужно понимать буквально: он не обнаружил известных ему признаков в проверенной области. Это не гарантия отсутствия всех способов повторного доступа.
У интернет-магазина к очистке добавляется ещё одна задача — сохранить актуальные заказы. Полный откат базы возвращает её к состоянию на дату копии. Заказы, регистрации и изменения остатков, появившиеся позже, могут исчезнуть из магазина, хотя реальные оплаты и отправки уже состоялись.
Особенно внимательно нужно обращаться с подписками и отложенными операциями. Восстановленная база может снова считать ожидающим задание, которое уже выполнилось. Например, документация WooCommerce Subscriptions отдельно предупреждает о риске повторного выполнения продлений после отката.
До восстановления нужно согласовать, как сохранят и проверят данные за этот промежуток. Фактические оплаты сверяют с платёжным сервисом, заказы и отгрузки — с учётной системой. Перенос актуальных данных должен учитывать устройство магазина и следы заражения в базе: бездумное возвращение всей свежей базы способно вернуть и проблему.
Рабочий порядок восстановления обычно выглядит так:
- Ограничить дальнейший ущерб и сохранить материалы для разбора. Если сайт перенаправляет посетителей, распространяет вредоносный код или есть признаки подмены страницы оплаты, публичную работу затронутого сервиса временно ограничивают. До очистки сохраняют доступные журналы и отдельный снимок файлов и базы. Заражённый снимок помечают и хранят закрыто: он нужен для расследования, а не для повторной публикации.
- Установить границы заражения. Проверяют файлы, базу, администраторов, задания по расписанию и конфигурацию. Для WordPress учитывают как серверный cron, так и задания внутри самой CMS. Если несколько сайтов работают под одной серверной учётной записью и могут изменять файлы друг друга, проверяют весь доступный им участок.
- Подготовить среду для восстановления. Копию разбирают отдельно от рабочего магазина, с ограниченным доступом и отключёнными рабочими рассылками, платежами и автоматическими заданиями. Типовые компоненты по возможности восстанавливают из доверенных источников, собственные доработки и пользовательские данные проверяют отдельно.
- Устранить обнаруженные способы проникновения. Уязвимый компонент обновляют, заменяют или отключают. Удаляют подтверждённые посторонние файлы, учётные записи и задания. Если выяснилось, что злоумышленник получил административный доступ ко всему серверу, отдельно решают вопрос о его пересоздании из доверенного образа: очистка одной папки сайта не восстанавливает доверие к системе.
- Вернуть контроль над доступами. Подозрительные доступы блокируют ещё при обнаружении инцидента. После очистки обновляют затронутые пароли и ключи, отзывают сеансы, проверяют права пользователей. Это делают с доверенного устройства, чтобы новые данные доступа не были сразу похищены снова.
- Проверить магазин и только затем возобновить обычную работу. Проверяют вход, каталог, корзину, оформление тестового заказа, изображения, уведомления и фоновые задачи. Отдельно сверяют актуальность заказов и отсутствие повторно поставленных операций.
При этом заглушка «На сайте ведутся работы», установленная внутри CMS, не обязательно останавливает серверные задания или другие способы выполнения кода. Способ ограничения доступа должен соответствовать масштабу инцидента.
Поиск причины опирается на последовательность событий: когда появились изменения, какие запросы и входы им предшествовали, что выполнялось по расписанию. Одной даты изменения файла обычно недостаточно для уверенного вывода.
Иногда установить первоначальный способ проникновения точно не удаётся: нужные журналы не сохранились или заражённое состояние уже несколько раз перезаписали. В отчёте это должно быть обозначено прямо. Подтверждённые находки, предположения и оставшиеся неизвестные требуют разного отношения.
Проверка доступов может выходить за пределы административной панели сайта. При признаках компрометации связанных аккаунтов проверяют управление доменом, DNS, CDN и другими подключёнными сервисами.
Отдельный пример — Google Search Console. Если там появился неизвестный владелец, нужно проверить связанные с ним способы подтверждения прав. Удаление пользователя из интерфейса не уничтожает оставшийся на сайте или в DNS токен подтверждения. Пока он действует, доступ можно подтвердить заново. Удалять следует именно чужие подтверждения, сохраняя необходимые подключения владельца магазина.
После восстановления важна повторная проверка в работе. Следят за новыми административными входами, изменениями файлов, подозрительными заданиями и исходящими соединениями. Проверяют, не возвращаются ли прежние признаки после выполнения расписания или обычных действий пользователей.
Период наблюдения выбирают по ситуации. Несколько часов без видимых изменений не дают универсальной гарантии: оставшееся задание может запускаться значительно реже.
Также нужно различать новое заражение и старые следы в кэше или внешних сервисах. После устранения причины проверяют и очищают затронутый кэш. Если Google отметил сайт как опасный, после исправления проблем отправляют запрос на проверку через Search Console. Предупреждение не обязано исчезнуть сразу после восстановления файлов.
Чтобы снизить риск повторения, поддерживают CMS и расширения в актуальном состоянии, убирают ненужные компоненты, ограничивают доступы и включают двухфакторную защиту там, где она доступна. Резервные копии хранят с историей версий и отдельно от места, которое способен изменять скомпрометированный сайт. Возможность восстановления периодически проверяют.
При обращении в QCKL опишите, когда появились первые признаки, что уже восстанавливали и через какое время проблема возвращалась. Укажите доступные даты копий и наличие новых заказов, которые важно сохранить.
Согласуйте задачу целиком: поиск причины, проверку масштаба заражения, очистку, выбор копии и восстановление с проверкой магазина. По результатам попросите указать, что нашли, какие доступы и уязвимости устранили, какие данные сохранили и что остаётся под наблюдением. Такой отчёт поможет понять, почему восстановленному сайту теперь можно доверять больше, чем после предыдущего отката.
