Сайт взломали: что подготовить и сделать в первую очередь

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

Что подготовить до начала

Работайте с устройства, которому доверяете: обновите систему, не используйте компьютер с подозрительными расширениями браузера. Не отправляйте пароли и резервные копии в открытый чат. Для действий понадобятся:

• доступ к панели хостинга и контакт службы поддержки;
• доступ к DNS-регистратору, если придётся менять записи или временно отключать сайт;
• резервные копии сайта и базы данных, если они есть, с датой создания;
• логи веб-сервера, панели хостинга и CMS за период до обнаружения проблемы;
• список администраторов и подключённых сервисов: почты, платёжной системы, аналитики.

Если у вас нет прав на сервер или сайт обслуживает подрядчик, сообщите ему об инциденте сразу. Не сбрасывайте всё подряд и не удаляйте логи до сохранения копии. Версия CMS и порядок восстановления зависят от конкретной системы; универсальная инструкция по кнопкам здесь была бы ненадёжной.

Первые действия: изолировать, сохранить, уведомить

1. Зафиксируйте, что именно происходит. Сделайте скриншоты, запишите время и адреса страниц, на которых видите подмену или перенаправление. Проверьте сайт с другого устройства и сети, чтобы отличить взлом от локального вредоносного расширения или кэшированной страницы. Проверка: у вас есть время обнаружения и несколько конкретных URL с симптомом.
2. Свяжитесь с хостингом и попросите сохранить данные. Опишите симптомы и время начала, попросите сохранить журналы и подсказать, можно ли временно ограничить публичный доступ. Если сайт собирает заявки или принимает оплату, сообщите об этом отдельно. Проверка: у вас есть номер обращения или письменный ответ и понятно, кто выполняет изоляцию.
3. Сохраните копию текущего состояния. Попросите хостинг сделать копию файлов и базы данных до очистки. Отдельно сохраните логи. Подозрительная копия не годится для восстановления, но может помочь установить способ проникновения. Храните её отдельно от рабочего сайта и ограничьте доступ. Проверка: вы знаете, где лежат копии, когда их сделали и кто может их получить.
4. Ограничьте ущерб. Если сайт продолжает заражать посетителей или принимать данные, временно закройте публичный доступ либо включите безопасную страницу обслуживания средствами хостинга. Если не знаете, как это сделать без потери данных, поручите действие поддержке. Проверка: посетители больше не получают вредоносный контент, а вы сохраняете доступ к панели и резервным данным.
5. Смените доступы с чистого устройства. Начните с почты администратора и панели хостинга, затем смените пароли CMS, FTP/SFTP, базы данных и связанных сервисов. Удалите неизвестные учётные записи и завершите активные сессии, если платформа это позволяет. Не используйте один пароль повторно. Проверка: старые пароли не работают, а список пользователей содержит только известных вам людей.

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

Как восстановить сайт, а не вернуть заражение

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

1. Выберите чистую резервную копию. Сверьте дату копии с первыми признаками взлома. Если атака могла начаться раньше обнаружения, самая свежая копия может уже содержать вредоносные изменения. Проверка: дата и происхождение копии известны, восстановление проходит на отдельной среде или после согласования с хостингом.
2. Обновите CMS, темы и расширения. Удалите компоненты, которыми больше не пользуетесь, и проверьте, что оставшиеся получают обновления от надёжного разработчика. Не устанавливайте «исправленные» архивы с неофициальных сайтов. Проверка: панель не показывает доступных обновлений, а неизвестных расширений и тем нет.
3. Проверьте учётные записи и интеграции. Удалите неизвестных пользователей, пересмотрите доступы подрядчиков и обновите ключи подключённых сервисов, если они могли быть раскрыты. Проверка: у каждой учётной записи есть понятный владелец и нужный уровень доступа.
4. Верните сайт в работу и наблюдайте. После восстановления проверьте главную страницу, формы, вход в админку, оплату и отправку почты. Попросите хостинг или администратора следить за журналами и повторными изменениями файлов. Проверка: основные сценарии работают, редиректов нет, а новые подозрительные события не появляются.

Бэкап¹ — резервная копия файлов и данных, из которой можно восстановить сайт. Для надёжного восстановления важно знать не только дату копии, но и то, что в ней нет следов атаки.

Что часто мешает восстановлению

• «Всё исправил, но редирект вернулся». Вероятно, сохранился другой заражённый файл, неизвестная учётная запись или уязвимое расширение. Снова изолируйте сайт и передайте хостингу время повторного появления симптома.
• «Пароль не подходит». Уточните, не заблокировала ли панель вход после попыток авторизации и не изменил ли администратор учётные данные. Сброс выполняйте через официальный канал хостинга, а не по ссылке из неожиданного письма.
• «Сайт показывает старую версию». Причиной может быть кэш браузера, CDN или прокси, а не повторный взлом. Проверьте сайт с другого устройства и попросите хостинг очистить кэш после восстановления.
• «В логах нет подозрительных записей». Логи могли быть выключены, перезаписаны или недоступны в тарифе. Запросите у хостинга сведения о доступных журналах и сроке их хранения; отсутствие записи не доказывает, что атаки не было.

Что делать дальше

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

Сноска

¹ Резервная копия, или бэкап, — сохранённое состояние сайта для восстановления после сбоя или повреждения данных.