Как вернуть сайт после взлома и не повторить атаку

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

Почему заражённую копию нельзя запускать вслепую

Вернуть сайт из последней копии кажется быстрым решением, но резервный архив мог быть создан уже после проникновения. Тогда вместе с файлами и данными вернутся изменения, внесённые до создания архива. Это не означает, что атакующий автоматически получит прежний доступ: повторный вход зависит от оставшихся учётных записей, уязвимых компонентов и того, закрыта ли причина инцидента. Поэтому слово «бэкап» описывает способ хранения, но не подтверждает чистоту содержимого.

До чистки я сохраняю доступные журналы, копию текущих файлов и базы, а также сведения о времени обнаружения. Это нужно для разбора инцидента и сравнения состояния сайта. Удаление подозрительных файлов до фиксации состояния стирает часть следов. Если журналы уже потеряны, так и отмечаю: точную последовательность событий может быть невозможно восстановить.

Я начинаю с сохранения доступных журналов и текущего состояния файлов и базы. Это не попытка «оставить вирус на память», а возможность позже сравнить состояние и понять, как получили доступ. WordPress рекомендует документировать инцидент, сделать снимок среды и только затем переходить к поиску и удалению вредоносного кода. Сразу удалить все подозрительное удобно лишь до момента, когда понадобятся доказательства: после этого выясняется, что журналы уже очищены, а происхождение неизвестной учётной записи не установить.

В качестве условного примера: у службы оцифровки «Архивная полка» 11 рабочих мест. Если сайт перестал принимать заявки, я сначала выясняю, когда появилась первая ошибка, какие журналы сохранились и где лежат копии. Это не кейс реального клиента и не обещание одинакового результата для любой CMS. У одной площадки сохранены подробные журналы, у другой — только дата последнего архива; план восстановления будет разным.

Выбор доверенной точки восстановления: как искать чистый бэкап

Чтобы выбрать пригодную копию, я ищу состояние, которое можно обосновать данными. Сопоставляю журналы доступа и веб-сервера, изменения файлов, первые симптомы — например, перенаправления или неизвестные записи пользователей. Если журналы неполные, точную дату проникновения подтвердить нельзя. Не существует универсального правила «отнять сутки» или «взять за неделю»: календарный запас не доказывает чистоту архива.

Файлы сайта и база данных могут изменяться независимо. Для полного восстановления типового WordPress нужны обе части, однако важно оценить, согласуются ли выбранные состояния друг с другом. База должна соответствовать версии приложения и загруженным материалам. Не следует механически восстанавливать два компонента из одной даты, если это приводит к потере нужных записей или нарушает целостность сайта.

Ориентиром служит не число дней, а согласованная картина признаков. Сопоставляю журналы веб-сервера и CMS, время появления первых редиректов, спама или неизвестных пользователей, историю изменений и уведомления хостинга. Логи могут отсутствовать или храниться ограниченное время, а обнаружение часто происходит позже самого проникновения. Поэтому нельзя честно утверждать, что копия за сутки до симптома чистая, или что архив за неделю заведомо безопасен. Практическую проверку копии я разбираю отдельно в статье о тестовом восстановлении резервной копии.

Отдельно проверяю состав резервной копии. Для типового WordPress нужны файлы установки и база данных; документация WordPress прямо говорит, что обе части требуются для полного восстановления. При этом не обязательно механически выбирать их из одного файла или одной даты, если эти состояния несовместимы. Нужно сверить, что база соответствует коду и загруженным материалам, а важные записи не потерялись при выборе более раннего состояния.

Развертывание в изолированном окружении: правило «не трогай продакшн»

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

На тестовой площадке проверьте файлы, базу и критические действия сайта. Если обнаружились неизвестные изменения, это повод вернуться к выбору копии и проверить компоненты, а не автоматически объявлять архив заражённым. Сканер помогает найти известные образцы, но результат сканирования не доказывает абсолютную чистоту. Отдельно проверьте, что тестовые формы не отправляют реальные письма и интеграции не выполняют боевые операции.

Хранение копий на отдельном носителе или в отдельной учётной записи снижает риск потерять их вместе с сайтом. Полезны несколько точек восстановления, известное расписание и периодическая проверка, что архив действительно разворачивается. В базе знаний есть рекомендация держать несколько версий бэкапа, но это не гарантия чистоты: версия помогает выбрать, а проверка и анализ помогают оценить содержимое. Я не называю антивирусный скан единственным критерием — он способен пропустить неизвестное или ошибочно отметить штатный файл.

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

Смена всех секретов: пароли, ключи и токены

Даже если вы восстановили чистый бэкап, старые пароли и ключи доступа считаются скомпрометированными. Злоумышленник мог перехватить их или сохранить в своем арсенале. После развертывания в изоляции необходимо сменить все учетные данные: пароль администратора CMS, пароль от базы данных, ключи FTP/SSH, токены API и пароли администраторов хостинга. Не просто сменить на похожие, а создать совершенно новые, сложные и уникальные комбинации. Используйте менеджер паролей, чтобы не забыть их, но храните их вне сервера. Если вы используете одно и то же слово для разных сервисов, смените его везде, даже на личных аккаунтах.

Особое внимание уделите файлам конфигурации, где хранятся ключи шифрования и соединения. В WordPress это wp-config.php, в Bitrix — config.php. Проверьте, не добавлены ли туда новые неизвестные переменные или функции. Часто хакеры оставляют в конфиге скрытые команды для удаленного управления. После смены паролей и проверки конфигов обязательно обновите саму CMS и все плагины до последних версий. Обновление закрывает известные уязвимости, через которые произошло проникновение. Если вы восстановили старую версию CMS, она снова будет уязвима для той же атаки.

На стенде проверяю те действия, ради которых сайт существует: основные страницы, формы, вход сотрудников, загрузку материалов и ошибки приложения. Для «Архивной полки» важно проверить, что посетитель может отправить заявку, а сотрудник — открыть нужный материал. Я не проверяю корзину у сайта без магазина и не обещаю, что один час тестирования покрывает все сценарии. Объём зависит от функций и доступности тестовых данных.

После оценки инцидента меняю именно те секреты, которые могли быть раскрыты: доступ CMS, хостинга, базы данных, SSH/FTP и интеграций, если они присутствуют. Пароли должны быть уникальными; старые сессии следует завершить там, где это поддерживает система. Смена значений требует аккуратного обновления конфигурации: если приложение продолжит использовать старый пароль базы, сайт перестанет подключаться. После изменения проверяю авторизацию и работу зависимых интеграций.

Проверка функционала и безопасность перед переключением

Прежде чем переключить DNS и пустить трафик на восстановленный сайт, проведите полную проверку функционала. Протестируйте форму обратной связи, корзину, регистрацию пользователей, админ-панель. Убедитесь, что все страницы загружаются корректно, нет битых ссылок и ошибок JavaScript. Проверьте, что сайт не показывает никаких признаков компрометации: всплывающих окон, редиректов на посторонние ресурсы, скрытых ссылок. Если вы заметили хоть малейшее отклонение — остановитесь и возвращайтесь к предыдущему шагу. Переключение на грязный сайт — это катастрофа для репутации и бизнеса.

Также проверьте исходящие соединения, если это применимо к вашей схеме. Не всякий незнакомый адрес означает заражение: сайт может обращаться к штатной аналитике, обновлению или интеграции. Сопоставьте запрос с конфигурацией и журналами. Если назначение не удалось объяснить, оставьте сайт в ограниченном режиме до выяснения, а не делайте вывод по одному адресу.

В WordPress wp-config.php содержит параметры конфигурации, а официальная инструкция для взломанного сайта отдельно советует заменить секретные ключи, чтобы завершить активные сеансы. Путь config.php нельзя универсально приписать всем установкам Bitrix: расположение файлов зависит от платформы и версии. Я сравниваю изменённые конфиги с чистой версией и документацией конкретной CMS, а не вставляю команды из случайной инструкции.

После восстановления доверенного состояния проверяю поддерживаемость CMS, темы и расширений, затем обновляю их с проверкой совместимости. Обновление закрывает известные проблемы обновлённого компонента, но не удаляет уже созданные учётные записи, чужие файлы и изменения базы автоматически. Поэтому «обновили — значит вылечили» не является планом. Сначала выясняю вероятный путь доступа, затем исправляю его и только после этого проверяю повторно.

Закрытие входа: защита от повторного взлома

Восстановление — это не только возврат файлов. Проверьте, какие компоненты были уязвимы, какие учётные записи лишние, где приложению нужна запись и какие механизмы загрузки включены. Доступ к административной части ограничивайте способом, который поддерживает инфраструктура и не блокирует легитимную работу сотрудников. Многофакторная аутентификация полезна, если доступна для используемой CMS и провайдера входа.

Не забывайте про регулярные обновления и мониторинг. Установите автоматические уведомления о новых версиях CMS и плагинов, но тестируйте их перед установкой на прод. Настройте мониторинг целостности файлов: если файл изменился без вашего участия, система должна отправить вам тревогу. Мы в АйТи-Фреш используем специализированные инструменты для отслеживания изменений в коде и конфигурациях. Если вы не хотите заниматься этим сами, лучше доверить это профессионалам. Постоянная бдительность — лучшая защита от повторного взлома.

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

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

Частые вопросы