Журнал "Information Security/ Информационная безопасность" #5, 2025

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