Сайт уже взломали: что делать после инцидента и как не повторить

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

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

Вторая ошибка — искать исполнителя только по скорости ответа в мессенджере. Скорость важна, но важнее методика: изоляция, сохранение улик, чистая переустановка или контролируемая очистка, ротация секретов, усиление периметра, мониторинг повторного заражения.

Типичные сценарии, которые путают с «просто вирусом»

Спам редиректы и SEO-прокладки. Сайт «вроде работает», но поисковики и антифишинг уже наказывают. Бизнес теряет трафик, пока спорит, «кто виноват — хостинг или CMS».

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

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

Грабли аварийного реагирования

• Стереть всё «для чистоты» до того, как сохранили логи и образ — потом не понять входную точку.
• Сменить только пароль админки, забыв FTP, SSH, БД, токены интеграций, ключи облака.
• Оставить старые расширения и «временные» скрипты в корне сайта.
• Вернуть сайт из бэкапа, который уже был заражён — и получить тот же бэкдор.
• Не проверить соседние сайты на том же аккаунте хостинга.

Рабочий порядок после взлома

Опытный подход предполагает сначала остановить кровотечение, затем понять вход, затем вернуть сервис уже в усиленном состоянии-—-с контролем, что заражение не вернулось.

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

Сохранение картины. Логи веб сервера, список недавно изменённых файлов, дамп БД, перечень пользователей админки. Без этого-«лечение» превращается в гадание.

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

Ротация секретов. Пароли, ключи-API, токены-CRM-и платежей,-SSH-ключи, секреты в-CI. Если злоумышленник сидел долго, считайте секреты скомпрометированными до доказательства обратного.

Усиление. Обновления, минимальные права, базовая фильтрация на периметре, второй фактор для админов, закрытие лишних точек входа, мониторинг целостности файлов и аномалий.

Рамка работ по таким инцидентам близка к практике-безопасности инфраструктуры: не разовая-«чистка», а цикл-«инцидент-→-причина-→-укрепление-→-наблюдение».

Что проверить, прежде чем объявлять победу

1. Нет ли повторных изменений файлов после санации.
2. Не торчат ли старые админ учётки и тестовые стенды в интернете.
3. Не заражён ли бэкап, из которого собираетесь восстанавливаться в будущем.
4. Понимаете ли вы входную точку достаточно, чтобы её закрыть.
5. Есть ли план реакции на повтор-—-кто дежурит и что делает в первый час.

Цена инцидента и цена профилактики

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

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

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

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

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

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

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

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