DDoS-атаки становятся сложнее и непредсказуемее – меняются их цели, сценарии и последствия для инфраструктуры. И даже при наличии автоматической защиты не всегда понятно, что именно происходит во время атаки и насколько система справляется. Редакция попросила экспертов поделиться видением, как меняются подходы к устойчивости и что действительно помогает держать сервисы в работе, когда нагрузка выходит за пределы допустимого.
Эксперты
- Казбек Мамакаев, руководитель группы разработки защиты от DDoS на уровне веб-приложений DDoS-Guard
- Эдгар Микаелян, руководитель департамента Presales CURATOR
- Дмитрий Никонов, руководитель направления защиты на уровне веб-приложений в DDoS-Guard
- Денис Сивцов, руководитель направления защиты сети на уровне L3–L4 в DDoS-Guard
- Вадим Солдатенков, руководитель направления продуктов “Гарда Anti-DDoS”, группа компаний “Гарда”
- Рамиль Хантимиров, CEO и сооснователь StormWall
- Михаил Хлебунов, директор по продуктам Servicepipe
- Глеб Хохлов, директор по продукту MITIGATOR
- Дмитрий Царев, руководитель управления облачных решений кибербезопасности BI.ZONE
Какие метрики дают объективное представление об эффективности защиты во время DDoS-атаки?
Вадим Солдатенков, группа компаний "Гарда"
Достаточность или недостаточность защиты можно объективно определить по работоспособности и/или доступности защищаемых ресурсов извне. Если каналы связи не загружены на 100%, если сетевые устройства (включая средства защиты информации, которые тоже подвержены атакам) исправно работают, если веб-сервисы или корпоративный DNS доступны извне – значит, защита от атак типа "отказ в обслуживании" справляется.
Эдгар Микаелян, CURATOR
Главная метрика – как работает само приложение под атакой. Если говорить про веб-сервисы, это время ответа, количество ошибок и фактическая доступность для легитимных пользователей. Все остальные показатели – объем трафика, количество блокировок, сложность атаки – вторичны. Эффективная защита – это когда пользователи не замечают, что в этот момент идет атака, и когда бизнес продолжает обслуживать максимальное число клиентов вне зависимости от нагрузки.
Дмитрий Царев, BI.ZONE
Если атака идет, а реальные пользователи ее не замечают и бизнес-процессы не останавливаются, значит защита работает. При этом важно учитывать, насколько эффективно каждый компонент системы защищает от угрозы. Например, если система защиты от DDoS-атак принимает весь трафик и почти полностью его отфильтровывает, то на канал к сетевому оборудованию поступает безопасный объем. Когда сетевое оборудование обрабатывает этот поток без перегрузки, нагрузка переходит на конечные системы. Если они выдерживают первые минуты атаки и затем либо повышают производительность, либо быстро восстанавливаются, такую защиту можно считать эффективной.
Денис Сивцов, DDoS-Guard
Удовлетворенность клиента – есть самая правдивая метрика. Минимальный процент атаки может достигать цели, но если отрицательного влияния на сервис не создается, то защита отработала успешно. Попытка заблокировать абсолютно каждый атакующий пакет грозит ложными срабатываниями. Здесь можно прибегнуть к медицинской этике "не навреди" (Noli nocere).
Глеб Хохлов, MITIGATOR
DDoS-атаки – это атаки на исчерпание ресурсов, которым противодействуют выстроенной эшелонами защитой, поэтому на конкретном эшелоне сложно оценить эффективность фильтрации. Задача DDoS-защиты не сбросить весь трафик атаки, а сохранить доступность защищаемого сервиса. В первую очередь нужно смотреть на бизнес-метрики защищаемого приложения и уровень доступности сервиса. Количество блокировок легитимных пользователей и увеличение времени доступа пользователя также показателем эффективности защиты.
Михаил Хлебунов, Servicepipe
Проблема в том, что цифры на графиках часто говорят одно, а реальное состояние услуги – совсем другое. Нужно смотреть на скорость реакции: за сколько секунд система обнаруживает атаку и сколько времени уходит на ее нейтрализацию. Но главное – проверить, что на самом деле осталось рабочим. Восстановилось ли время отклика? Продолжают ли функционировать критические процессы? Не упали ли легитимные запросы в попытке перестраховки? Метрика объема обработанного трафика вообще мало что значит. Куда важнее понимать: сколько легитимных клиентов потеряли доступ, насколько деградировал пользовательский опыт, вернулась ли система к норме после удара. На практике большинство компаний до сих пор слепо доверяют цифрам вместо того, чтобы проверить, что там действительно происходит.
Рамиль Хантимиров, StormWall
Эффективность защиты чаще оценивается по трем базовым метрикам: процент успешно обработанных легитимных запросов (доступность ресурсов), время отклика для реальных пользователей и количество ложных срабатываний. Если в ходе DDoS-атаки ключевые бизнес-процессы продолжают работать без сбоев, а пользовательский опыт не ухудшается – это объективный показатель хорошей защиты для бизнеса. Однако устойчивость должна обеспечиваться именно фильтрацией трафика, а не избыточными ресурсами инфраструктуры. Если сервис держится лишь за счет запаса мощности – это не показатель качества защиты, а отсрочка проблемы.
Как изменились ожидания заказчиков к автоматизации: что им нужно больше – черный ящик или прозрачность и контроль?
Эдгар Микаелян, CURATOR
Сегодня заказчики все больше доверяют провайдерам анти-DDoS и их экспертизе. Большинству уже не хочется вручную настраивать фильтры и контрмеры. Но при этом ожидание прозрачности выросло драматически: компании хотят видеть каждый входящий запрос, понимать, какое решение было принято системой и почему. То есть они готовы к черному ящику в плане автоматизации, но требуют полной наблюдаемости и объяснимости решений.
Дмитрий Царев, BI.ZONE
Компании по-разному подходят к автоматизации. Ключевым моментом становится интеграция решений в их процессы, отчетность и мониторинг для эффективного реагирования. Те, кому требуется глубокая интеграция, выстраивают работу так, чтобы получать данные и изменять настройки с использованием автоматизации/API. При этом большинству заказчиков достаточно набора инструментов в личном кабинете. Возможности для более гибкой настройки доступны, но на практике чаще всего востребованы лишь базовые операции, например блокировка адресов или добавление их в белый список.
Вадим Солдатенков, группа компаний "Гарда"
Ожидания двоякие, конечно. С позиции "хочу, чтобы все работало само" нужен черный ящик, в пределе – терминатор, так как противостояние сложным атакам требует больше вычислительных мощностей. С другой стороны, прозрачность и контроль нужны для понимания, по каким критериям система блокирует или пропускает трафик. Хорошо, когда в решении есть понятные формализованные алгоритмы. А, например, поведенческие модели с использованием ИИ лучше использовать в качестве вспомогательных инструментов защиты как раз по причине их меньшей прозрачности.
Глеб Хохлов, MITIGATOR
Конечно все хотят черный ящик, а не приобретать непрофильные компетенции и тратить ресурсы на управление DDoS-защитой. Но реальность такова, что уровень автоматизации и качество предоставляемых услуг защиты вынуждает владельцев инфраструктуры с множеством сервисов получать прозрачность и контроль защиты, и зачастую самим участвовать в своей защите. Черный ящик может быть еще эффективен для защиты небольшого сайта или приложения, но дальше спасение утопающих – дело рук самих утопающих.
Денис Сивцов, DDoS-Guard
Мой ответ – и то и другое. Непосредственно после приобретения услуги клиенту нужен черный ящик, чтобы не тратить драгоценные часы на настройку. А уже потом, со временем, клиентам требуется контроль над системой и соответствующие инструменты тонкой настройки. В целом мы видим, что запросы на многовекторное управление трафиком стремительно растут, как и потребность в кастомизации услуги под конкретный проект для получения максимального контроля.
Михаил Хлебунов, Servicepipe
Тренд четкий: заказчики массово отворачиваются от черного ящика. Автоматизация, с точки зрения заказчика, необходима. Все понимают, что ручного реагирования на атаки за секунды не бывает, но заказчики при этом хотят видеть, какие именно сигналы сработали, по каким правилам блокировалась очередь трафика, почему конкретный запрос попал в черный список. Нужен полный Audit Trail и детальная аналитика каждого инцидента. Это отражается в спросе на решения с интерактивными дашбордами, API-доступом к метрикам, возможностью переопределить решение системы за пять минут. Иначе слепая автоматизация может легко заблокировать нужных пользователей. Контроль плюс скорость – это то, что нужно.
Рамиль Хантимиров, StormWall
Сейчас заказчики требуют и то, и другое одновременно. Им нужна полностью автоматизированная защита, работающая без вмешательства человека, но с полной прозрачностью принимаемых решений.
Мы наблюдаем переход от концепции черного ящика к абсолютно прозрачной коробке – система защиты должна не только самостоятельно отражать атаки, но и предоставлять детальную аналитику о своих действиях и давать возможность вручную корректировать алгоритмы при необходимости.
Насколько часто заказчики проверяют (и должны проверять), как работает их защита при аномальных нагрузках?
Эдгар Микаелян, CURATOR
Это болезненный вопрос, особенно в России: большинство компаний до сих пор не проводят регулярных проверок, а стресс-тесты выполняются либо раз в год, либо вообще от случаю к случаю. Сейчас хорошим тоном считается комплексное стресс-тестирование всей инфраструктуры раз в квартал, а не точечная проверка только одного сервиса. Тестировать нужно не отдельно взятый ресурс, а всю цепочку зависимостей, чтобы понимать, где именно под нагрузкой инфраструктура становится хрупкой.
Вадим Солдатенков, группа компаний "Гарда"
Мониторинг в принципе должен работать 24/7. Нужно понимать, что защита – это процесс, в котором задействован не только специализированный комплекс от DDoS-атак. На качество могут влиять и человеческий фактор, и сетевое окружение, и другие системы. Все это требует контроля.
Денис Сивцов, DDoS-Guard
При ожидаемых нагрузках на канал и оборудование заказчик не должен и практически никогда не проверяет работу сервиса защиты. Исключение составляют случаи, когда заказчик желает убедиться в стабильной работе сервиса заблаговременно, перед важным событием на его защищаемой онлайн-площадке. Например, в день крупных скидок (черная пятница, 11.11, новогодние акции) перебои в работе площадок онлайн-продаж недопустимы, и к таким дням их владельцы готовятся, в том числе по технической составляющей.
Рамиль Хантимиров, StormWall
Большинство организаций проверяют защиту только во время реальных инцидентов, что является серьезным риском для их безопасности. Считаю, что с учетом стремительного роста числа и мощности DDoS-атак регулярное тестирование защиты должно стать обязательной практикой. Но судя по тому, что мы видим сейчас, это понимают лишь отдельные компании – в основном из Enterprise-сегмента.
Дмитрий Царев, BI.ZONE
Многие компании редко проверяют эффективность своей защиты. Это понятно: такие тесты требуют ресурсов и подготовки. Однако именно они помогают увидеть, как работает не только система защиты, но и сами ресурсы под нагрузкой. Это важно, так как проверка показывает поведение системы в случае, если по каким-то причинам атака все же достигает защищаемого приложения. По оценке BI.ZONE, оптимальный подход – проводить такие испытания один-два раза в год. Частоту имеет смысл повышать после крупных изменений в инфраструктуре или когда ожидается рост легитимной нагрузки.
Глеб Хохлов, MITIGATOR
В первую очередь DDoS-защиту нужно проверять не при аномальных нагрузках, а в любой момент – и желательно в прайм-тайм c целью проверки влияния защиты на легитимный трафик, выявления незащищенных ресурсов и отлаженности процессов реагирования на атаку. Мощность самой атаки не обязана достигать каких-то запредельных значений, да и значения реальных атак в Tbps легитимным способом трудно получить. Чаще всего в регламенте указана проверка раз в год, но сейчас многих атакуют значительно чаще.
Михаил Хлебунов, Servicepipe
Это не "раз в год на аудит". В 2025 г. нужно проверять постоянно. Постоянный рост DDoS-атак, гиперобъемные атаки свыше 6,5 Tbps – это не шум. Организации, которые не тестируют защиту регулярно, фактически не знают, сработает ли она при реальной атаке. Минимум – квартальные тесты под контролируемыми нагрузками. Лучше – ежемесячная проверка конкретных сценариев. Когда реальные атаки превышают расчетные параметры (а они часто превышают), неподготовленная команда обнаруживает неэффективность защиты уже во время инцидента, и это обходится максимально дорого.
Какие ошибки чаще всего допускаются при планировании реагирования на DDoS?
Дмитрий Царев, BI.ZONE
Одна из наиболее распространенных ошибок – отсутствие инструментов мониторинга систем. Без них сложно определить характер воздействия атаки на каждую отдельную систему, особенно если ее не удалось вовремя отфильтровать. Еще одна распространенная проблема – недостаточно отработанные процессы реагирования на инциденты. Без четких регламентов и инструкций даже опытные сотрудники могут не понимать, какие шаги нужно предпринять в экстренной ситуации: куда обращаться, какие отчеты анализировать, какие настройки менять, какие действия допустимы, а какие нет. Например, некоторые ресурсы могут быть менее критичны для бизнеса, и их временное отключение помогает снизить нагрузку на остальные компоненты инфраструктуры.
Вадим Солдатенков, группа компаний "Гарда"
На мой взгляд, самые большие проблемы возникают, когда ответственность при планировании на 100% делегирована внешнему подрядчику, а защита предусматривает лишь один, внешний, эшелон. Это создает единую точку отказа. Как говорил один мудрец, "если не я за себя, то кто за меня?".
Михаил Хлебунов, Servicepipe
Наиболее распространенная ошибка – компании стартуют не с того. Например, план защиты рассчитан на 100–300 Gbps, а атаки уже идут на Tbps. Или используется один универсальный сценарий вместо отдельных тактик под разные векторы – атака на сетевом уровне требует совсем других действий, чем HTTPS-flood. Часто команды изолированы друг от друга: сетевики сами по себе, аппликейшн-тимы сами по себе, бизнес не в курсе. План не проверен в боевых условиях, хотя бы в симуляции. И многие ставят ставку только на облачную защиту, забывая о локальной валидации и собственной видимости. Правильный подход – гибридный, с четкой иерархией эскалации и распределением зон ответственности между командами. И главное – тестировать.
Рамиль Хантимиров, StormWall
На практике мы чаще всего сталкиваемся с двумя ключевыми ошибками. Во-первых, компании защищают лишь часть критических ресурсов, оставляя другие уязвимыми. Эти незащищенные системы становятся слабым звеном, атака на них парализует всю инфраструктуру, включая защищенную. Во-вторых, многие ограничиваются сетевым уровнем защиты, игнорируя угрозы на уровне приложений.
Дмитрий Никонов, DDoS-Guard
Основные ошибки – недооценка угрозы и отсутствие понимания типа атаки, а также нехватка базовых знаний информационной безопасности. Распространен также миф, что CDN может полностью защитить от DDoS-атак. Однако CDN – лишь дополнительный инструмент для снижения нагрузки на сервер и ускорения загрузки ресурса для посетителей. Это хороший элемент в многослойной защите, но не основное средство защиты.
Эдгар Микаелян, CURATOR
Есть две главные ошибки. Во-первых, под защиту ставят только критические сервисы, а вспомогательные или инфраструктурные элементы игнорируют. В итоге злоумышленники находят слабое звено – DNS, API, авторизацию, вспомогательные TCP-сервисы – и бьют туда, выводя из строя бизнес-функцию. Во-вторых, отсутствие карты зависимостей. Команда не понимает, какие сервисы обеспечивают работу ключевого приложения. Даже если центральный сервис хорошо защищен, его может положить недоступность слабозащищенного вспомогательного компонента.
Глеб Хохлов, MITIGATOR
Основная ошибка при планировании – отсутствие самого планирования. Если определены зоны ответственности ИT и ИБ, то далее получается относительно стандартный план реагирования на инциденты. В практике наблюдал разные неучтенные и достаточно болезненные случаи, но подсвечу две ошибки. Первая – не налажен контакт с НСПА. Вторая – длительный процесс оценки состояния здоровья защищаемого ресурса. Например, нет доступов к дашбордам с метриками сервисов у ответственных за защиту.
Что из последнего опыта работы с DDoS вас удивило и/или заставило пересмотреть прежние представления?
Михаил Хлебунов, Servicepipe
Масштабы гиперобъемных атак (4,8 BPPS в апреле 2025 г., 6,5 Tbps) просто сломали представления о том, как должна строиться архитектура защиты. Это уже не "больше трафика на старой системе", это совсем другой класс задач. И еще поразило, как растет профессионализм атакующих. VM-ботнеты вместо IoT-устройств – это означает, что атаки становятся более целенаправленными, управляемыми, а не просто случайным шумом. Хакеры подчищают ряды, остаются только серьезные. Третий момент, который заставил пересмотреть подход: DDoS все чаще являются дымовой завесой. Пока команда безопасности занята громкой DDoS-атакой, злоумышленники спокойно проникают в сеть и воруют данные. Это не отдельная помеха, а часть скоординированной кампании. Защита требует контекста и параллельного мониторинга глубоких уровней, а не просто блокировки трафика.
Дмитрий Царев, BI.ZONE
Вероятно, наибольшее удивление вызывают масштабы современных атак. Кажется, что дальше расти уже некуда, однако злоумышленники продолжают ставить новые рекорды объемов и интенсивности атак.
Эдгар Микаелян, CURATOR
Больше всего поражает влияние ИИ на возможности атакующих. В 2025 г. мы увидели появление по-настоящему крупных ботнетов-миллионников, которые сформировались, в том числе, из-за массового использования ИИ-агентов, уязвимых IoT-платформ с элементами ИИ и автоматизированного создания вредоносной инфраструктуры. ИИ ускорил эволюцию атак: они стали более адаптивными, многовекторными и автономными.
Вадим Солдатенков, группа компаний "Гарда"
Сейчас модно говорить про атаки с использованием ИИ или что-то такое же (пока) экстраординарное. Однако я все чаще наблюдаю кейсы, когда при атаке на защищаемый ресурс проблема возникает не на нем, а на промежуточной системе контроля и фильтрации трафика перед ним, которая и становится тем самым слабым звеном. Таким образом к задаче "защитить сервисы" добавляется задача "защитить файрвол".
Рамиль Хантимиров, StormWall
В последние месяцы мы видим активный рост мощности сложных DDoS-атак. Мы уже зафиксировали ковровую бомбардировку свыше 1,3 Тбит/с. Но важнее даже не мощность атак, а меняющаяся тактика злоумышленников – теперь они еще чаще используют ботнеты и комбинируют мощные UDP-флуды с точечными прикладными атаками. Такие угрозы уже невозможно отразить методами и решениями, которые были эффективны 3–4 года назад.
Казбек Мамакаев, DDoS-Guard
Поразило, что цель атаки может не ограничиваться одним только доменом – например, в случае атаки на инфраструктуру. Атакующие теперь собирают необходимую информацию и атакуют ее со всех сторон. Если атакуют хостинг, то достаточно получить пул доменов, на которые можно посылать понемногу запросов, и они в сумме нагрузят инфраструктуру хостинга. DDoS может также быть только частью более сложной атаки с целью сместить фокус внимания.
Глеб Хохлов, MITIGATOR
Поразило, что в Рунете открытых портов TCP/7547 больше, чем суммарно TCP/80 и TCP/443. Отмечу, что TCP/7547 используется в TCP SYN-ACK Reflection, а сами CPE часто со старым софтом и слабыми паролями, позволяют их добавлять в ботнеты. Второй момент, звучавший в общении с зарубежными партнерами и клиентами, – ожидание, даже требование использования ИИ в anti-DDoS. А также вера в облачную защиту и низкий уровень квалификации и понимания проблематики DDoS в сравнении с отечественными специалистами.
Какие направления развития анти-DDoS могут реально изменить подход к защите в 2026–2027 гг.?
Эдгар Микаелян, CURATOR
- Автономная защита уровня приложений (L7) – системы, которые самостоятельно понимают поведение приложения, обучаются на нем и перекрывают сложные атаки без ручной настройки.
- Более глубокая корреляция данных: объединение телеметрии сетевого и прикладного уровня, чтобы защита работала целостно и могла видеть цепочки атаки, а не только ее отдельные сигнатуры.
- Инфраструктурные стресс-симуляторы, которые позволяют регулярно проверять устойчивость всей платформы к нагрузкам и аномалиям – в том числе в автоматизированном режиме.
Эти направления смещают акцент от просто фильтрации трафика к постоянной устойчивости инфраструктуры как цифровой системы.
Вадим Солдатенков, группа компаний "Гарда"
Будущее, в том числе, за специализацией эшелонов при отражении DDoS-атак. Работа с объемными атаками на каналы; работа с атаками на сетевые устройства, включая средства защиты информации; борьба с атаками на уровне приложений, включающая инспекцию шифрованного трафика и анализ содержимого запросов. Это три кита эшелонированной защиты.
Михаил Хлебунов, Servicepipe
- Машинное обучение уходит от сигнатур в сторону поведенческих профилей. Каждый клиент уникален, система должна учиться его нормальному трафику и реагировать на отклонения, а не ловить известные атаки.
- Гибридная архитектура становится стандартом – локальная первичная фильтрация плюс облачное скребление, но с минимальной задержкой и максимальным контролем. Никто не хочет быть полностью зависим от одного провайдера.
- Нарастает Zero Trust-подход прямо в аспекте DDoS – верифицировать нужно не просто источник запроса, но весь контекст: геолокацию, отпечаток устройства, поведенческие сигналы.
- Децентрализованное смягчение – не один провайдер, а mesh-подход с резервированием на несколько облаков и сетей. К 2026–2027 гг. победит не самый быстрый и не самый дорогой, а самый гибкий и честный в своих действиях подход. Клиенты устали от черных ящиков.
Денис Сивцов, DDoS-Guard
Простота использования продукта для конечного пользователя наряду с растущей эффективностью – это то, к чему сводится развитие во многих потребительских отраслях. Это же применимо и к защите от DDoS. Развитие сервисов защиты будет стремиться к балансу между тем, чтобы облегчить пользователю процесс настройки, и тем, чтобы дать ему достаточный набор инструментов для кастомизации. Цифровой отпечаток используемых приложений клиента будет все больше использован для автоматической адаптации сервиса защиты.
Рамиль Хантимиров, StormWall
Ключевое направление – прогнозная аналитика на основе ИИ, способная предсказывать атаки по косвенным признакам и автоматически адаптировать правила фильтрации. Второй важный тренд – интеграция anti-DDoS в концепцию Zero Trust, где каждый пакет проверяется независимо от источника. Это трансформирует парадигму от реагирования к превентивной защите, когда система предотвращает атаки до их начала.
Глеб Хохлов, MITIGATOR
В России – это, конечно же, развитие Национальной системы противодействия DDoS-атакам (НСПА) и введение новых требований к защите российскими регуляторами. Работы по уменьшению источников и рефлекторов DDoS-атак внутри страны повысят доступность сервисов для российских пользователей. В мире – попытка добавить ИИ куда только можно и нельзя (в детектирование, в подавление, в аналитику, настройку защиты) наконец-то даст результаты – в первую очередь в настройках и аналитике.