После атаки: восстановление бизнеса и план защиты

Атака закончилась. Сайт работает. Можно выдохнуть? Не совсем. Если вы не сделаете правильные шаги после атаки — она повторится. И вторая атака обычно сильнее первой: атакующие уже знают ваши слабые места.

В этой статье — пошаговый план восстановления и укрепления защиты после DDoS-атаки. От технического анализа до коммуникации с клиентами. Следуйте этому плану — и следующая атака (если она случится) не застанет вас врасплох. Начните с настройки мониторинга и укрепления архитектуры.

Атака прекратилась — но это не значит, что всё в порядке. Вот чек-лист на первые сутки:

Проверьте работоспособность всех сервисов

Не только главную страницу. Проверьте:

— Процесс оформления заказа (от корзины до оплаты)
— Личный кабинет пользователей
— Формы обратной связи
— API для мобильного приложения (если есть)
— Административную панель
— Почту (часто страдает вместе с сайтом)
— Интеграции (платёжные системы, CRM, 1С)

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

Не отключайте защиту

Типичная ошибка: «Атака кончилась → защита больше не нужна → отключаем Cloudflare». Категорически нет. Атакующий может ждать именно этого. Повторная атака часто начинается через 12–48 часов — когда жертва расслабляется. Защита должна оставаться включённой постоянно.

Снизьте уровень агрессивности постепенно

Если во время атаки вы включили режим «Under Attack» в Cloudflare (проверка каждого посетителя) — не выключайте его сразу. Переключите сначала на «High», через 24 часа — на «Medium», через 48 — на обычный режим. Так вы плавно вернётесь к нормальной работе, не подставляясь под повторную волну.

Проверьте, не было ли взлома

DDoS иногда используется как прикрытие для реального взлома. Пока вся команда тушит пожар доступности — злоумышленник тихо проникает через уязвимость. Проверьте:

— Не появились ли новые пользователи с правами администратора
— Нет ли изменённых файлов на сервере (особенно конфигурации и код)
— Не менялись ли данные в базе (учётные записи, цены, контент)
— Нет ли подозрительных исходящих соединений с сервера
— Все ли резервные копии на месте

Если обнаружите что-то подозрительное — немедленно привлеките специалиста по информационной безопасности. О типах атакующих и их методах — в нашей статье «Кто и зачем атакует сайты».

Через 24–48 часов после атаки, когда эмоции улягутся, проведите разбор инцидента. Это не «поиск виноватых», а анализ для предотвращения повторения. Вот структура:

Хронология событий

Составьте таймлайн с точностью до минут:

— Когда началась атака (по данным мониторинга)?
— Когда мы узнали об атаке? (Разница — это время детекции. Чем больше — тем хуже)
— Какие действия предприняли и когда?
— Когда сайт стал доступен для пользователей?
— Когда атака прекратилась?
— Общее время простоя?

Что сработало

Зафиксируйте позитив. Может, хостер быстро отреагировал. Или кто-то из команды быстро подключил Cloudflare. Или мониторинг сработал вовремя. Это — ваши активы, которые нужно сохранить и усилить.

Что не сработало

Честно зафиксируйте провалы. Типичные:

— «Узнали об атаке от клиентов, а не от мониторинга» → нужен нормальный мониторинг
— «Не знали, кому звонить» → нужен план реагирования на инциденты
— «Не было защиты» → нужна защита от DDoS
— «Не могли отличить DDoS от обычного сбоя» → изучите как отличить атаку от поломки
— «Паника, хаос, все делали разное» → нужны роли и процедуры

Финансовый итог

Подсчитайте реальные потери. Используйте методику из нашей статьи «Сколько стоит DDoS-атака». Эта цифра — ваш главный аргумент для бюджета на защиту.

Атака прошла, сайт работает. Но ваши клиенты помнят. Кто-то потерял заказ. Кто-то не смог оплатить. Кто-то увидел ошибку и решил, что вас взломали. Нужно восстановить доверие.

Публичное заявление (в течение 24 часов)

Опубликуйте пост в блоге, соцсетях, рассылке. Структура:

1. Что произошло (коротко, без технических деталей)
2. Данные клиентов не пострадали (если это так — и вы проверили!)
3. Что вы сделали для восстановления
4. Что вы сделаете, чтобы это не повторилось
5. Контакт для вопросов

Пример текста: «15 февраля наш сайт подвергся внешней кибератаке (DDoS), из-за которой был недоступен в течение 6 часов. Персональные данные клиентов не были затронуты — атака была направлена на блокировку доступа, а не на взлом. Мы оперативно подключили специализированную защиту, и сервис восстановлен. Для предотвращения подобных ситуаций мы внедрили постоянную систему защиты от кибератак. Приносим извинения за неудобства. По всем вопросам: support@...»

Персональная работа с пострадавшими клиентами

Если у вас есть клиенты, чьи заказы/операции были нарушены — свяжитесь с каждым лично. Предложите:

— Приоритетное обслуживание
— Скидку или бонус на следующий заказ (5–10% достаточно)
— Помощь в повторном оформлении

Это стоит копейки, но показывает клиенту: вы цените его, вы берёте ответственность, вы реагируете.

Работа с негативными отзывами

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

После разбора инцидента — время строить защиту. Вот план, разбитый по неделям:

Неделя 1: Базовая защита

CDN и фильтрация трафика. Если вы подключили Cloudflare или аналог экстренно во время атаки — доведите настройку до ума. Не оставляйте «как получилось». Настройте WAF-правила, проверьте, что реальный IP сервера скрыт, убедитесь, что весь трафик идёт через CDN.

Мониторинг. Подключите хотя бы базовый мониторинг: UptimeRobot (бесплатно) или Better Uptime (от $20/мес). Настройте уведомления на телефон — не на email, который проверяют раз в час. Подробности — в нашем гайде по мониторингу.

Неделя 2: Укрепление инфраструктуры

Скройте реальный IP-адрес сервера. Частая проблема: Cloudflare подключён, но старый IP-адрес «светится» в DNS-истории, в email-заголовках, в открытых базах. Атакующий может бить напрямую, минуя защиту. Попросите хостера сменить IP, если возможно.

Настройте файрвол сервера. Разрешите входящие HTTP/HTTPS подключения только с IP-адресов вашего CDN-провайдера. Всё остальное — блокировать. Тогда даже при знании вашего IP напрямую подключиться не получится.

Резервные копии. Убедитесь, что бэкапы делаются автоматически, хранятся в отдельном месте (не на том же сервере) и проверены (попробуйте восстановить из бэкапа тестово).

Неделя 3: Процессы и люди

Создайте план реагирования на инциденты. Документ на 1–2 страницы: кто что делает при атаке, контакты провайдеров, пошаговые инструкции. Распечатайте (сайт с инструкциями может тоже лежать) и раздайте ключевым людям. Шаблон — в нашей статье об инцидент-менеджменте.

Определите ответственных. Кто принимает решение о включении режима «Under Attack»? Кто общается с провайдером? Кто информирует клиентов? Не «все» и не «кто-то» — конкретные люди с именами и телефонами.

Проведите обучение. Покажите команде, как выглядит DDoS-атака, что делать в первые 30 минут. 15-минутный брифинг может сэкономить часы во время реального инцидента.

Неделя 4: Продвинутая защита

Оцените необходимость платного решения. Если бесплатного Cloudflare достаточно — отлично. Если ваш бизнес приносит более 3–5 млн рублей в месяц через сайт — рассмотрите платные тарифы или специализированные решения.

Настройте rate limiting. Ограничение количества запросов с одного IP — простая, но эффективная мера против L7-атак.

Постройте отказоустойчивую архитектуру. Если бюджет позволяет — разнесите инфраструктуру: несколько серверов, балансировка нагрузки, автоскейлинг. Это защищает не только от DDoS, но и от обычных аварий.

DDoS-атака — уголовное преступление в России (ст. 272, 273 УК РФ). Даже если шансы найти исполнителя невелики, подать заявление стоит по нескольким причинам:

1. Фиксация факта. Заявление в полицию — официальный документ. Он может понадобиться для страховой выплаты, для обоснования убытков перед партнёрами, для налоговых вычетов.

2. Статистика. Чем больше заявлений — тем больше внимания правоохранительные органы уделяют теме. Это долгосрочная инвестиция в безопасность всего интернета.

3. Иногда находят. Особенно если атакующий — не профессионал (бывший сотрудник, школьник, начинающий вымогатель). IP-адреса, цифровые следы, оплата на форумах — всё это может привести к исполнителю.

Что нужно для заявления:

— Логи сервера за период атаки
— Данные от хостинг-провайдера (подтверждение атаки, объём трафика)
— Скриншоты мониторинга
— Если было вымогательство — письмо с требованиями (со всеми техническими заголовками)
— Оценка ущерба (финансовые потери, расходы на восстановление)

Заявление можно подать в ближайшем отделении полиции или через сайт МВД. Дело обычно передаётся в отдел «К» (по борьбе с киберпреступностью).

Главная ошибка после атаки — вернуться к обычной жизни и забыть. Защита от DDoS — это не проект с датой завершения. Это непрерывный процесс:

Ежемесячно:

— Проверяйте, что мониторинг работает (отключите сайт на минуту тестово — пришло ли уведомление?)
— Проверяйте актуальность контактов в плане реагирования
— Просматривайте отчёты CDN-провайдера — нет ли аномалий?

Ежеквартально:

— Проводите «учебную тревогу» — объявите команде «атака» и проверьте, как они реагируют
— Пересматривайте бюджет на защиту — адекватен ли он выросшему бизнесу?
— Обновляйте WAF-правила — новые типы атак появляются постоянно. О фильтрации ботов стоит думать регулярно.

Ежегодно:

— Полный аудит инфраструктуры безопасности
— Пересмотр провайдера защиты (рынок меняется, появляются новые решения)
— Обучение новых сотрудников процедурам реагирования
— Проверка и тестирование бэкапов

Думайте о защите от DDoS как о пожарной сигнализации. Вы не отключаете её после того, как потушили пожар. Вы проверяете батарейки, обновляете план эвакуации и проводите учения.

Звучит парадоксально, но DDoS-атака может стать поворотным моментом к лучшему. Вот как:

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

Укрепление инфраструктуры. Меры, которые вы предпримете после атаки (CDN, мониторинг, резервирование), улучшат не только безопасность, но и скорость, надёжность, масштабируемость сайта. CDN ускоряет загрузку. Мониторинг ловит ошибки до того, как их увидят клиенты. Резервирование защищает от любых сбоев, не только от DDoS.

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

Конкурентное преимущество. Вы можете (и должны) сообщать клиентам, что ваш сервис защищён от кибератак. Для B2B-клиентов это важный фактор при выборе подрядчика. «Мы используем enterprise-уровень защиты от DDoS» — это аргумент в продажах.

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