Перейти к содержимому
Левицкий Концепт
Инициализация систем000%
Левицкий Концепт
Все статьи
Безопасность

Что делать, если сайт взломали: пошаговый план

18 мая 2026 г.· 8 мин чтения

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

Час первый: изоляция, а не удаление

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

Час второй: смена всех учётных данных

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

День первый: поиск точки входа

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

День второй: чистка и восстановление

Ядро CMS переустанавливается из официального дистрибутива, а не патчится вручную. Файлы шаблонов и загрузок сравниваются с эталоном через diff. В базе проверяются таблицы пользователей на лишних администраторов и опции автозагрузки на инъекции. Отдельно — каталог загрузок: исполняемых файлов там быть не должно, доступ к ним закрывается на уровне веб-сервера. Если своей команды нет, разумнее подключить техническую поддержку, чем править вслепую.

Как вернуть доверие поисковиков

После взлома сайт часто оказывается в списке опасных. Порядок восстановления: убедиться, что вредонос удалён, запросить проверку в панелях вебмастеров Яндекса и Google, дождаться снятия метки. Обычно это 1–3 дня. Параллельно проверьте, не появились ли в индексе дорвейные страницы и спамные редиректы — их нужно отдать в удаление и закрыть 410-м кодом. Просевшие позиции восстанавливаются медленнее, и здесь помогает системная работа над технической оптимизацией.

Чтобы не повторилось

  • Регламент обновлений: критические патчи ставятся в течение 72 часов, остальное — раз в месяц по расписанию.
  • Резервные копии на внешнем хранилище с ретенцией минимум 30 дней и регулярной тестовой распаковкой.
  • Двухфакторная аутентификация на всех административных входах.
  • Принцип минимальных прав: у контент-менеджера не должно быть доступа к файловому менеджеру.
  • Мониторинг целостности файлов с уведомлением при любом изменении в системных каталогах.

Сколько это стоит

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

Нужна помощь с проектом?

Обсудим задачу и предложим решение — от сайта до SaaS и защиты.

Связаться