В одном из проектов после взлома выяснилось, что резервная копия скачивается не целиком: объем архивов превысил доступное хранилище, а уведомления о сбое не было. Для восстановления использовали локальные копии. Владельцу в такой ситуации нужен понятный порядок действий: что сохранить, кому передать доступ и что проверить до возвращения посетителей.
Если сайт взломали, первая цель — ограничить ущерб и собрать исходные данные. Открывшаяся после восстановления главная страница еще не подтверждает безопасность сайта и прием заявок.
Первые шаги: зафиксировать взлом и закрыть доступ к опасной версии
Сохраните адрес проблемной страницы, время обнаружения с часовым поясом и описание того, что увидели. Полезны уже полученные снимки предупреждения или чужой рекламы, сообщения посетителей и уведомления хостинга. Отдельно запишите последние известные изменения сайта и действия после обнаружения проблемы: даже неудачная попытка восстановления важна для специалиста.
Не нужно обходить предупреждение браузера или повторно открывать зараженные страницы ради подробного осмотра. Чужая переадресация может срабатывать только при определенном переходе или на части устройств, поэтому отсутствие симптома у владельца еще не опровергает проблему. Google описывает такие случаи и рекомендует технические способы исследования вместо обычного просмотра зараженных страниц в справке о проблемах безопасности.
Передайте хостингу и ответственному специалисту задачу ограничить публичный доступ к опасной версии, сохранив данные для разбора. Способ ограничения зависит от размещения сайта и других сервисов на сервере; выбирать его должен тот, кто понимает эту схему.
Приостановите рекламу, ведущую на поврежденные страницы, и дайте сотрудникам альтернативный способ приема обращений. Подрядчику передайте адрес, симптомы, время обнаружения и уже выполненные действия.
До очистки: журналы, файлы и состояние базы
Попросите специалиста сохранить отдельный комплект материалов об инциденте: текущие файлы, состояние базы, доступные журналы запросов и ошибок, сведения о входах и изменениях учетных записей. Состав зависит от платформы и того, что успел записать сервер. Если журналы хранятся недолго, ожидание ответа подрядчика может лишить расследование нужного периода.
Такой комплект помечают как потенциально зараженный и хранят с ограниченным доступом. Его нельзя путать с чистой резервной копией для запуска. Рекомендация сохранить снимок среды до очистки есть в документации WordPress по действиям после взлома; для конкретного сайта специалист определяет, какие данные и каким способом зафиксировать.
Запросите опись: что сохранено, за какой период и кто отвечает за хранение. Пароли и архивы передают по согласованному защищенному каналу только участникам, которым они нужны для работы.
Разделяйте время обнаружения и начало атаки: копия до появления чужой страницы могла уже содержать заражение. Если журналы не сохранились и момент проникновения неизвестен, это ограничение указывают в отчете.
Кто отвечает за хостинг, домен и восстановление
Соберите список сервисов, владельцев учетных записей и действующих контактов. Домен, сервер и резервные копии могут быть у разных подрядчиков; важно понять, кто доступен сейчас.
Распределите ответственность по результатам:
- Хостинг или администратор сервера уточняет состояние площадки, помогает с ограничением доступа, сохранением журналов и доступными копиями.
- Специалист по восстановлению исследует заражение, готовит рабочую версию, проверяет входы и фиксирует выполненные изменения.
- Ответственный за домен подтверждает контроль над ним и согласует изменения адресации, если они действительно нужны.
- Владелец бизнеса определяет приоритетные функции, допустимую потерю данных и принимает проверенные сценарии работы.
Назначьте одного координатора решений о запуске и смене площадки. В общей задаче фиксируют текущую версию, ответственного за следующий шаг и условие его выполнения.
В проекте с неполными архивами на выделенном сервере находились несколько сайтов, а их изоляция была недостаточной. В состав работ вошли анализ логов, восстановление из локальных копий, перенос и обновления. Поэтому при похожей схеме важно согласовать проверку соседних сайтов и общих доступов, а не ограничивать задачу доменом, на котором первой появилась чужая страница.
Восстановление, устранение причины и последующие улучшения согласуют отдельно, с проверяемым результатом каждого этапа. Вопрос о переделке решают после диагностики: см. когда редизайн не нужен.
Неполная копия: что проверить в отдельном окружении
Сначала выясните, что именно сохранилось: полный архив, несколько его частей, экспорт базы или только папка с файлами. Например, для типичного сайта на WordPress нужны и файлы, и база данных: скачанная папка сайта сама по себе не заменяет выгрузку базы. Это различие прямо описано в руководстве WordPress по резервным копиям.
Если архив не скачивается целиком, не стоит сразу считать все копии утраченными. Специалист проверяет, был ли неполным сам архив или прервалась его передача, доступны ли остальные части и есть ли независимые копии у хостинга или прежнего исполнителя. Для каждого варианта записывают дату, состав и результат проверки, сохраняя исходные файлы без перезаписи.
Следующий шаг — пробное восстановление в отдельной среде, доступной только участникам работ. До запуска в ней настраивают безопасное поведение почты, платежей и обменов, чтобы копия не отправляла настоящие уведомления и не меняла рабочие данные. Проверять пригодность архива сразу поверх действующей версии — значит совмещать эксперимент и восстановление в одной операции.
Попросите показать восстановленную базу, страницы с изображениями и ключевые функции. В протоколе проверки должны остаться ошибки, отсутствующие данные и принятые решения; формулировки «сайт поднят» недостаточно.
До выбора копии согласуйте, какие новые заявки, заказы или публикации придется вернуть отдельно, сверяя с независимыми системами учета. Переносить зараженную базу целиком нельзя: вместе с нужными записями можно вернуть нежелательные изменения.
Что закрыть до возвращения сайта посетителям
Возврат файлов сам по себе не объясняет, почему сайт взломали. Попросите назвать подтвержденную причину или рабочую версию с указанием доказательств: что видно по журналам, учетным записям и изменениям. Если причину установить не удалось, согласуйте, какие возможные пути проникновения проверены и какие меры приняты с учетом этой неопределенности.
Очистку и восстановление доступа проверяют отдельно. Специалист ищет нежелательные изменения в файлах и базе, лишние учетные записи, измененные правила переадресации и задания, которые могут вернуть заражение. Удаление видимого баннера не доказывает, что остальные изменения найдены. Владельцу нужен перечень проверенных областей и обнаруженных проблем, без необходимости самостоятельно читать код.
Смена одного пароля администратора не охватывает доступ к хостингу, передаче файлов и базе. В плане работ должны быть пересмотр прав, отзыв ненужных доступов и активных сессий, замена скомпрометированных учетных данных. В документации WordPress отдельно отмечены разные точки доступа и повторная смена паролей после очистки, если их меняли еще на зараженном сайте: рекомендации после взлома.
Обновления и ограничения доступа проверяют на подготовленной версии до возвращения посетителей. Если есть признаки компрометации самого сервера, вопрос о чистой площадке решают вместе с администратором, а не сводят к замене файлов сайта. При согласованном переносе отдельно сохраняют адреса страниц и проверяют переключение; эти задачи описаны в материале о переезде без потери SEO.
Наконец, исправьте сам процесс резервного копирования: проверьте свободное место, получение уведомлений об ошибках и восстановление из новой копии. CISA рекомендует регулярно проверять доступность и целостность резервных данных и держать защищенные копии отдельно от доступной атакующему среды. Эти принципы приведены в руководстве по восстановлению после атак.
Как принять восстановление и проверить заявки
Приемка начинается с заранее согласованных сценариев. Проверьте основные страницы и мобильную версию, поиск или каталог, отправку формы и получение обращения сотрудником. Для магазина добавьте согласованный тест заказа и подтверждения оплаты, если платежи входят в работу сайта; факт открытия корзины не подтверждает всю цепочку.
Используйте согласованные тестовые данные и узнаваемую пометку. Сверьте обращение на сайте, в почте и CRM, если она подключена; проверьте отсутствие дублей. Результат подтверждает получатель: сообщения об успехе в форме недостаточно.
Если поисковая система обнаружила заражение, технический запуск и снятие предупреждения — разные события. Google рекомендует запрашивать повторную проверку после устранения всех указанных проблем; примеры адресов в отчете могут быть неполными. Порядок и требования к запросу опубликованы в справке Search Console, поэтому обещать исчезновение предупреждения в момент запуска нельзя.
В итоговой передаче работ нужны дата восстановленных данных, список устраненных проблем, результаты тестов и нерешенные вопросы. Также зафиксируйте, кто получает сигналы о новых сбоях, проверяет резервные копии и отвечает на повторные симптомы. Восстановление можно принять осознанно, когда понятно не только что снова работает, но и какие данные возвращены, что проверено и за чем продолжают наблюдать.