Когда в корпоративной сети начинается инцидент, это почти никогда не похоже на учебник. Нет аккуратной схемы «обнаружили → проанализировали → локализовали», где всё красиво расчерчено по минутам, ролям и чек-листам. В реальности всё выглядит куда менее структурированно. Обычно это резкий всплеск хаоса: мониторинг начинает визжать алертами, пользователи массово жалуются на недоступность сервисов, служба поддержки теряется в потоке тикетов, а бизнес внезапно вспоминает, что у компании есть служба информационной безопасности, и начинает писать и звонить со всех сторон одновременно. Телефоны разрываются, чаты захлёбываются сообщениями, каждый хочет срочный ответ «что происходит и когда починят». Случай с DDoS-атакой — один в один.

В первые минуты всё часто кажется почти безобидным. Графики в Grafana показывают рост трафика, кто-то пишет в Slack, что сайт «подтормаживает», дежурный администратор замечает необычные пики по соединениям на фаерволе или балансировщике. Иногда это выглядит как обычная пиковая нагрузка, иногда — как сбой мониторинга. И почти сразу у всех появляется естественное желание «что-нибудь срочно починить». Закрыть порты, включить жёсткий rate limit, перезапустить балансировщик, применить все правила, которые когда-то готовились «на всякий случай». Это самая частая и самая опасная ошибка, потому что такие действия в первые минуты почти всегда только усугубляют хаос и создают новые проблемы, которые потом крайне сложно отделить от самой атаки.

Я всегда начинаю с попытки понять, что реально происходит, а не что кажется происходящим на фоне алертов и паники. Для этого нужны несколько независимых источников данных, а не один красивый дашборд. Смотрю метрики Grafana и Prometheus — не только общий трафик, но и количество соединений, ошибки приложений, задержки на балансировщиках. Параллельно поднимаю логи с балансировщиков и фаерволов через Graylog или ELK, смотрю, что именно летит: новые соединения, повторяющиеся запросы, странные user-agent’ы. Проверяю сетевые счётчики на маршрутизаторах, иногда делаю tcpdump на периферийных устройствах, чтобы увидеть характер трафика вживую: SYN-флуд, UDP-флуд, HTTP-flood, amplification или что-то более изощрённое.

Был случай, когда мониторинг показывал резкий рост пакетов, и вся команда была уверена, что это классический DDoS. Уже начали обсуждать блокировки подсетей, но по логам балансировщика стало видно, что запросы абсолютно легитимные, с нормальными заголовками и сессиями. Оказалось, что маркетинг запустил масштабную рекламную кампанию без предупреждения, и трафик вырос в разы. Любая агрессивная фильтрация в тот момент нанесла бы прямой ущерб бизнесу. Этот пример очень хорошо показывает, почему паника и резкие действия в первые минуты почти всегда вредят.

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

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

Коммуникация с бизнесом и смежными командами — отдельная и очень важная история. В первые 10–20 минут я всегда стараюсь дать короткий и спокойный статус: «есть сетевой инцидент, похоже на DDoS, работаем, следующий апдейт через 15 минут». Без паники, без технических деталей, без обещаний «починим через пять минут». Людям важно понимать, что ситуация под контролем и что информация будет обновляться регулярно.

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

Через 20–30 минут после начала инцидента обычно становится понятно, справляемся ли мы своими силами или нужна эскалация. Если атака укладывается в пропускную способность каналов и ресурсы инфраструктуры, можно работать локально: аккуратно добавлять ACL на фаерволах, включать rate limit на балансировщиках, применять WAF для фильтрации очевидного мусора. Если же атака превышает возможности каналов, любые локальные действия теряют смысл — каналы просто забиваются. В этом случае нужно как можно быстрее подключать провайдера или облачное анти-DDoS-решение для фильтрации трафика на upstream-уровне. Потерянные здесь десять минут легко превращаются в часы простоя.

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

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

На стадии стабилизации начинается более точечная работа. Например, блокируется аномальный UDP-трафик с конкретных подсетей, при этом сохраняются легитимные порты для VoIP и внутренних сервисов. Атакуемые сервисы сегментируются, чтобы они не тянули за собой остальную инфраструктуру. Был случай, когда фронтенд приложения находился за тем же балансировщиком, что и API. Мы временно вынесли фронтенд на отдельный балансировщик с жёсткой фильтрацией, а API оставили под защитой WAF. Бизнес продолжал работать, клиенты могли выполнять ключевые операции, а атака была локализована.

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

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

Пример: атака на корпоративный VPN. В первые минуты никто толком не понимал масштаб и характер нагрузки. После фиксации состояния подключили upstream-фильтрацию, аккуратно настроили rate limit на шлюзах, разделили сотрудников по приоритету доступа. Через полчаса критическая работа была восстановлена, остальная — постепенно, без резких обрывов. При этом остались полные логи и дампы атаки для дальнейшего анализа.

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

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