Отборочный турнир Кубка CTF России – это всегда высокая конкуренция, плотный график заданий и тысячи одновременных запросов от участников к обслуживающей соревнования информационной системе. Инфраструктура работает под нагрузкой, и любое отклонение быстро превращается в цепную реакцию. Именно в такой обстановке осенью 2025 года произошел инцидент, который стал основой для этой статьи.
Автор: Виктор Минин, председатель правления Ассоциации руководителей служб информационной безопасности
Когда говорят о DDoS, многие представляют себе всплеск трафика на входе, пару минут паники и стандартный набор мер: включить защиту, поднять лимиты, разослать оповещения. На практике же все чаще прилетает не тривиальный объемный флуд, а проводится целевая атака на логику приложения – та самая, которая не оставляет очевидных следов в метриках, но методично ломает архитектуру.
В кейсе, который произошел на отборочном турнире Кубка CTF России [1], команда организаторов столкнулась именно с такой атакой, пиковая нагрузка которой составляла до 13 млн RPS. И допущенные ошибки здесь важнее технических деталей: они показывают, где ломается процесс реагирования даже у опытных инженеров.
Ошибка 1. Ставка на защиту по умолчанию
Первая ловушка – вера в то, что включенный анти-DDoS и балансировщик с базовыми лимитами если не спасут, то хотя бы замедлят атаку. В реальности L7-атака, направленная на ресурсоемкие эндпоинты, проходит через такую защиту как через сито.
В инциденте злоумышленники били не по каналу, а по веб-страницам системы, которые заставляли базу данных работать на износ. На графиках трафик выглядел почти нормальным – зато количество соединений к СУБД выросло до предельных значений. Защита была включена, но смысла это не имело: она просто не видела аномалию.
Вывод простой: защита по умолчанию не предназначена для таких атак. Если в архитектуре есть тонкое место – его обязательно найдут.
Ошибка 2. Игнорирование архитектурных узких мест
Второй момент – архитектурный. Приложение работало на нескольких инстансах, но вся нагрузка сходилась в единую точку – MySQL. Классика: фронтенд можно расширять сколько угодно, но все ломается на уровне единственного хранилища, которое и становится узким местом.
Когда число соединений дошло до лимита, платформа начала отказывать. Это выглядело как падение приложения, хотя на самом деле рушилась база данных. В точке пикового RPS приложение не выдерживало не потому, что не справлялся веб-сервер, а потому что каждая страница направляла все новые и новые запросы в БД.
Здесь не помогло бы ни увеличение лимитов, ни количество реплик – корень проблемы оставался тем же, СУБД. Узкое место всегда вскрывается первым.
Ошибка 3. Корректировки без анализа первопричины
Инцидент развивался на фоне попыток оперативно вносить правки. Лимиты на балансировщике менялись, мелкие баги в интерфейсе правились, деплоер обновлялся. Такая стратегия кажется логичной – надо же быстро облегчить ситуацию.
Но в условиях высокой нагрузки любое изменение увеличивает неопределенность. В кейсе совпало обновление одной из частей деплоя и рост отказов – и хотя события были независимыми, визуально это выглядело как новая ошибка. Появляется шум, который закрывает настоящую причину происходящего.
Оказывается, системные инциденты не любят спешки. Важно сначала понять, что именно ломается, и только потом что-то менять.
Ошибка 4. Эскалация до непротестированных решений
Когда становится очевидно, что быстрые меры не работают, появляется соблазн вынести на прод что-то более тяжелое: WAF, прокси, новое правило маршрутизации. В теории – правильный шаг, но на практике – катастрофа.
Команда попыталась переехать с балансировщика на WAF Proxy, рассчитывая отсечь плохие запросы до того, как они выйдут на приложение. Однако именно в этот момент проявился баг на стороне облака: белые адреса, необходимые для корректной работы прокси, не были опубликованы по BGP. В итоге проверки работоспособности перестали проходить, и вместо частичной деградации сервис получил очередной простой.
Это типичный эффект: когда решение не протестировано заранее, оно почти наверняка создаст проблем больше, чем решит.
Ошибка 5. Сутки без сна и снижение качества решений
Самая недооцененная причина эскалации – человеческий фактор. Команда работала почти сутки без перерыва. В таких условиях даже у опытного инженера снижается точность суждений. Начинает казаться, что "надо только чуть-чуть поправить" или "еще немного остаться и дожать".
На фоне усталости возрастает риск пропустить важный сигнал, сделать неверный вывод, принять лишнее решение. В описываемой истории это чувствуется по каждому шагу.
Заключение
DDoS – не столько про объем трафика, сколько про эксплуатацию архитектурных слабостей. Пять описанных выше ошибок – не редкость. Наоборот, это нормальный набор для любого инцидента, в который команда входит неподготовленной.
И все же важный итог: несмотря на давление и сложный инцидент, отборочный турнир удалось провести без срывов. А команда, пройдя через испытание, стала заметно сильнее: и технически, и организационно, и по качеству взаимодействия в стрессовой ситуации. Инциденты вроде описанного выше – лучшее напоминание о том, что в устойчивости нет случайностей.
Резюмируя, стоит сказать, что архитектура, построенная с запасом, и дисциплина в реагировании важнее, чем сам по себе анти-DDoS-сервис.
