Что происходит, когда на хостинг обрушивается поток ненастоящих запросов мощностью 800 гигабит в секунду? В августе хостинг‑провайдер Cloud4box столкнулся с подобной DDoS‑атакой уровня L7. В статье агентство рассказывает, как отразить огромный поток искусственного трафика, восстановить сервисы, что предложить клиентам и почему многие компании не хотят платить за защиту.
Количество DDoS‑атак в России увеличилось на 60%
В первом квартале 2025 года атак зафиксировано больше, чем за весь 2024 год — 20,5 млн против 21,3 млн. Средняя мощность атак также растёт: у крупных компаний фиксируются пики до 1,5 Тбит/с. Для сравнения: ещё пару лет назад атака в сотни гигабит считалась масштабной.
Длительность тоже изменилась. По данным рынка, в 2025 году атаки длились более 96 часов. Это больше четырёх суток непрерывного давления.
В последние 2 года DDoS‑атаки стали нормой. Их мощность растёт быстрее, чем возможности «среднего» бизнеса. Даже нагрузка в 100‑200 Гбит/с способна положить инфраструктуру без защиты. Атаки в 700 Гбит/с и выше фактически неподъёмны для одного провайдера, если он не подключён к scrubbing‑центрам*.
Особенно страдают финансы, ИТ и телеком, e‑com и госуслуги. Например, 19‑20 мая на серверы ФНС была совершена DDoS‑атака мощностью до 40 Гбит/с, пики доходили до 162 Гбит/с. Недоступны были «Госключ», «СБИС», «ЕМИАС» и «Честный знак» — пользователи не могли попасть в личные кабинеты и подписать документы. Спустя буквально пару недель — 6 июня 2025 года — также из‑за DDoS‑атаки легли сайт и приложение «РЖД», поездки оформлялись с перебоями.
www.rbc.ru/society/20/05/2025/682c4bc69a794747701b0771
www.forbes.ru/tekhnologii/539506-rzd-soobsila-o-ddos-atake-na-sajt-i-mobil-noe-prilozenie
Как малому бизнесу пережить внезапное падение сайта и не потерять клиентов
Как видим, даже гиганты рынка не могут полностью противостоять DDoS‑атакам. Простая универсальная защита уже не работает. Сейчас нужно комбинировать автоматические фильтры и ручные настройки под конкретные сервисы. Опыт Cloud4box подтверждает эту картину.
*внешние системы очистки трафика.
Типы DDoS‑атак
DDoS‑атаки бывают двух основных типов:
- Сетевые (L3/L4) — когда сервер заваливают огромным количеством ненастоящих запросов. В результате сеть и оборудование перегружаются, и легитимный трафик не проходит.
- Прикладные (L7) — когда атака имитирует действия пользователей: заходы на сайт, клики на формы, запросы к сервисам. Таких псевдопользователей может быть тысячи, и они могут делать это одновременно.
В 2025 году в России фиксировали L7‑атаки, где на обычный сайт поступало более 150‑200 тысяч ненастоящих запросов в секунду. Для сравнения: даже самый популярный сайт без дополнительной защиты начинает падать при 10‑20 тысячах запросов в секунду.
Что такое DDoS‑атаки и как от них защищаться бизнесу
Фильтрация таких атак — отдельная задача. Вредоносный трафик почти неотличим от легитимного. Это как «искать иголку в стоге сена». Система должна определить, какие запросы постпуают от реальных пользователей, а какие сгенерированы ботами.
С каким типом атаки столкнулся хостинг и где возникла сложность
В случае команды Cloud4box атака была смешанной от L3/4 до L7. Главная сложность пришлась именно на уровень L7. Вредоносные запросы маскировались под легитимные HTTPS‑сессии. Отличить их от настоящих обращений клиентов оказалось непросто.
За годы работы с атаками уровня L3/L4 фильтрация трафика для нас работает предсказуемо
Мы оперативно отсеиваем флуд по IP‑адресам, блокируем попытки перегрузки портов и фильтруем подозрительные потоки пакетов, которые могут перегружать сеть.
Совсем другое дело — L7 (прикладные атаки). Здесь нагрузка выглядит как абсолютно легитимный трафик: десятки и сотни тысяч запросов к сайту или приложению каждую секунду. К тому же прикладные атаки напрямую бьют по ресурсам веб‑сервера. Каждая «липовая» сессия заставляет процессор обрабатывать запрос, тратить время на генерацию ответа и держать соединение открытым. В такой ситуации отличить легитимный трафик от нелегитимного очень непросто.
В результате даже при относительно небольшой полосе пропускания у сервера может резко вырасти загрузка CPU и начаться замедление обработки реального трафика. Настоящие пользователи в таком случае ждут ответа от сервера дольше или сталкиваются с ошибками.
Именно поэтому прикладные атаки считаются более опасными. Для хостинга критично иметь опытных специалистов, которые оперативно настраивают фильтры под конкретный сервис, анализируют поведение трафика и корректируют защиту в реальном времени.
Масштаб атаки в цифрах. Cloud4box привыкли к тому, что DDoS‑атаки на сетевом уровне могут достигать сотен гигабит в секунду. Но в этот раз нагрузка оказалась серьёзной даже по меркам команды опытных специалистов.
Пиковая мощность была около 800 Гбит/с
Активная фаза длилась несколько дней, а хвосты атаки мы наблюдали еще примерно неделю. Фоновый трафик для сравнения в десятки раз ниже. То есть мы получали поток, который превышал обычные значения в несколько порядков.
Такой объём запросов не только перегружает подсети, но и «выжигает» ресурсы на уровне приложений. Веб‑сервера начинают тратить процессорное время на обработку липовых HTTPS‑сессий, вместо того чтобы обслуживать запросы реальных пользователей.
Проанализировав масштаб атаки, стало понятно — стандартная защита не справится, если реагировать шаблонно. Чтобы минимизировать последствия, пришлось действовать быстро и многоуровнево, включая внешние фильтры и донастраивая вручную защиту под отдельные сервисы.
Что делать во время DDoS‑атаки: версия хостинг‑провайдера
Когда обрушивается поток липовых запросов, система мониторинга это определяет и оповещает: что‑то идёт не так. Список стран, провайдеров и подсетей приходит в отчётах почти сразу. Первые минуты уходят на то, чтобы «поднять щиты».
С момента срабатывания мониторинга до первых ручных корректировок активных фильтров проходит 5‑10 минут
Это стандартный рабочий цикл. Сначала автоматически отсекается самый грубый мусор, затем происходит ручная точечная настройка по мере понимания характера трафика.
Следующий этап — включение в работу инженеров. Их задачи идут в таком порядке.
Сохранить работу всей сети. Сначала — защита сетевой инфраструктуры. Если «упадёт» магистраль, потеряются контроль и возможность обслуживать всех клиентов.
Потом — защита сервисов для клиентов: биллинг, панели управления, почта и сайты. Лучше держать приоритет в таком порядке и объяснять это клиентам простыми словами.
Подключить партнеров по очистке трафика (скраббинг*). Параллельно с инженерами, Cloud4box подключил партнёра по очистке трафика. В момент инцидента это был StormWall (детали очистки остаются за скобками по соображениям безопасности). Там трафик проходил «промывку». Плохие запросы отбрасывались, хорошие попадали к нам.
Основная очистка сетевой атаки (L3/L4) происходила на его оборудовании, Cloud4box со своей стороны вели постоянную коммуникацию с операторами партнёра.
*Скраббинг — очистка трафика от вредоносных запросов, которые поступают во время DDoS‑атаки.
Вручную донастраивать фильтры (L7 — per‑service). Здесь начинается самая сложная часть. Параллельно с «центральной» фильтрацией инженеры начали ручную донастройку фильтров под конкретные сервисы — порт‑по‑порту и сайт‑по‑сайту. Это критично для L7. Автоматические фильтры либо режут много легитимного трафика, либо пропускают часть «липового». Поэтому Cloud4box шли итеративно: наблюдали, корректировали, отслеживали эффект.
Существуют сложности в настройке индивидуальных фильтров под каждого клиента
Поскольку базовая защита рассчитана на то, чтобы сохранить доступность сервисов для большого количества пользователей. Индивидуальная настройка возможна только при L7‑защите — иначе возникает риск, что в пользу одного клиента будут ухудшены условия для остальных.
Менять маршруты и проверять результат. В процессе важно постоянно смотреть метрики: пиковую мощность, список источников, географию. По мере того как понимаете, откуда идёт основной поток, можете временно закрывать доступ из отдельных регионов или провайдеров. Это снижает нагрузку, но иногда приводит к тому, что часть реальных пользователей в этих регионах временно теряет доступ.
Вся активная фаза заняла несколько дней. Потом атака постепенно затухала, но хотим повторить, её хвосты Cloud4box ловили еще неделю. Важно понимать: полностью остановить атаку может только тот, кто её начал. Ваша задача удержать сервисы в рабочем состоянии и минимизировать ущерб для клиентов.
Ключевой вывод о ходе реагирования
Быстрое обнаружение + немедленное подключение партнёра по скраббингу + итеративная ручная настройка под L7 — рабочая комбинация.
Именно ручная работа и очередь клиентов по приоритетам определяли скорость восстановления каждого конкретного сервиса.
Восстановление после DDoS‑атаки
В теории «почистил и всё вернулось». На практике именно следующий набор пунктов сделал восстановление сложным и долгим.
Нестандартные порты, кастомные сервисы клиентов = индивидуальная настройка. Многие клиенты используют нестандартные порты (например, для 1С или внутренних сервисов). Атаки нередко идут не только по стандартным HTTP/HTTPS‑портам (80 и 443), но и по нестандартным. Например, по API, игровым серверам или административным панелям.
Автофильтры по умолчанию предполагают стандартные порты и сразу режут все подозрительные соединения на нестандартных. Поэтому такие клиенты страдают первыми. Перенастроить их сервисы — задача не быстрая. Это требует согласования с администраторами, проведения тестов и иногда физического участия клиента. Для каждого отдельного сервера клиента нужно определить, какие параметры/потоки подходят.
В момент атаки делать это массово тяжело. Клиентов более десятка тысяч. У каждого свои порты и сервисы. В результате очередь на ручную проработку влияет на скорость восстановления, иногда это занимает по времени до нескольких дней для конкретного клиента.
Если клиент изначально планирует подключение L7‑защиты при покупке услуги, Cloud4box заранее согласовывает настройки фильтров для конкретных случаев.
Региональные и провайдерские «обрезки». Применяемые правила защиты могут блокировать трафик по провайдерам или городам, чтобы отрезать основную «бомбардировку». Для одних клиентов это незаметно, для других — критично. Некоторые регионы России временно «не видели» их сервисы.
Координация с партнерами и ограниченная видимость. Основная очистка шла на оборудовании партнера. Это рабочая схема, но «подсмотреть» все внутренние процессы очистки — не получится. К тому же нельзя настроить индивидуальные правила сразу для всех. Каждое правило серьёзно нагружает центры очистки. Поэтому подобные настройки всегда планируются заранее в рамках платной защиты, чтобы они работали эффективно и без рисков для других клиентов.
Коммуникация и ожидания клиентов — человеческий фактор. У саппорта ограниченные ресурсы. Клиенты часто требовали немедленного индивидуального решения, но это невозможно при одновременной атаке на десятки сервисов. При этом Cloud4box работали круглосуточно и публиковали обновления по ситуации. К сожалению, часть клиентов всё равно расторгла контракты. Это нормальная, но неприятная часть риска.
Переход к другому провайдеру не гарантирует, что ситуация не повторится
Атака может настигнуть любого, вспомните кейсы корпораций. Вопрос в её мощности и готовности команды реагировать. Поэтому важно не только заранее продумывать защиту на L3‑L4, но и на L7 в том числе. Такой комбинированный подход снижает риски куда надёжнее, чем реагирование по факту.
Вмешательство третьих сторон. Провайдеры или регуляторы (в отдельных случаях Роскомнадзор) могут принять собственные меры по ограничению трафика. Это эффективно, но не всегда синхронизировано со стратегией хостинга. Как следствие, кардинально меняет картину для клиентов. Мы учитываем возможность такой координации в планах реагирования.
DDoS‑атака на Cloud4box затронула не всех клиентов одинаково. Выделить можно три основных сценария.
Первый — минимальные сбои (от минут до пары часов). Так прошли атаку те клиенты, чьи сервисы работали на стандартных портах и не требовали ручной донастройки. Базовые фильтры и скраббинг от партнера справились быстро.
В отдельных случаях атака могла затронуть и стандартные порты
Это в том случае, если они находились по соседству с нестандартными портами или попадали под общие правила фильтрации. То есть даже при стандартных портах простои в 3‑4 дня не столько связаны с их типичностью, сколько с индивидуальной инфраструктурой и ручной настройкой.
Второй — заметные перебои (несколько часов). Это клиенты, чья инфраструктура сложнее. Например, связка веб‑сайта, почты и внутренних сервисов. Для них атака — это кратковременные отключения и задержки в доступе из отдельных регионов.
Третий — длительные простои (до нескольких дней). Основной удар пришёлся по тем, у кого были нестандартные настройки: собственные протоколы, кастомные порты или редкие сценарии работы. Автоматическая фильтрация блокирует такие сервисы в первую очередь, а ручная настройка требует времени и координации.
Что это значило для SLA. В среднем по платформе SLA сохранялся в допустимых границах. Критичные сервисы — биллинг, панели управления, почта — вернули в строй максимально быстро. Для части клиентов SLA всё же оказался нарушен. Простой измеряется часами, в отдельных случаях днями.
Базовая защита на уровне L3/L4 была выполнена в полном объёме
Мы закрыли всех клиентов от сетевых атак. L7‑защита в базовый пакет не входит. Здесь всегда нужен индивидуальный, нестандартный подход и заранее согласованные правила. Как говорится, «спасение утопающих — дело рук самих утопающих». Мы сделали максимум возможного, даже в части L7‑фильтрации, но гарантировать ее эффективность без отдельной услуги невозможно
Что показала атака:
- Классические сайты и сервисы, которые работают по стандартным протоколам, восстанавливаются быстрее всего.
- Чем сложнее конфигурация и чем больше «кастомного», тем дольше идёт ручная настройка.
- SLA при DDoS‑атаке — это не только скорость реакции провайдера, но и то, как сам клиент выстроил свою инфраструктуру.
Как общаться с клиентами во время DDoS‑атаки
Во время атаки важно не только технически отражать трафик, но и держать постоянную связь с клиентами. Когда у клиента перестает открываться сайт или не работает почта, первое, что он делает — идет в поддержку.
В таком случае, должны быть открыты все каналы связи:
- чат в личном кабинете;
- Telegram;
- телефонные линии;
- тикеты в почте.
Объяснение, что случилось, в Телеграм‑канале Cloud4boxОбъяснение, что случилось, в Телеграм‑канале Cloud4box
Саппорт в этот момент оказывается под огромной нагрузкой. Писать и звонить могут одновременно десятки клиентов, и каждому хочется получить быстрое решение. Шаблонные отписки в стиле «мы работаем над проблемой» лучше не использовать. Вместо этого объясните честно и просто, что происходит, что сделано и что будет дальше.
Сколько стоит минута молчания: почему клиентская поддержка может приносить убытки
Были и трудные моменты:
- часть клиентов требовала немедленного восстановления сервиса «прямо сейчас», хотя это невозможно физически одновременно для всех;
- кому‑то казалось, что проблема только у него, и приходилось объяснять, что атака идёт глобально и приоритеты расставлены по критичности.
Тем не менее открытая и честная коммуникация помогла. Многие клиенты отмечали, что им важнее получать регулярные обновления и понимать ситуацию, чем сидеть в неизвестности. При этом важно не отправлять клиентов покупать платную защиту и отстаивать интересы каждого заказчика без исключения.
Выводы после DDoS‑атаки
Для Cloud4box это была не первая DDoS‑атака. Во многом хостингу помог опыт прошлых инцидентов. Они уже знали, какие шаги работают лучше всего: быстрое подключение скраббинг‑центров, приоритизация критичных сервисов и честная коммуникация с клиентами.
После атаки команда сделала несколько выводов:
- Отработала схему реагирования так, чтобы сотрудники понимали, кто и за что отвечает в первые минуты атаки.
- Закрепила правило: «В первую очередь поднимаем критичные сервисы, а потом уже начинаем работу над кастомными решениями по обращениям клиентов».
- Объясняла клиентам, что нестандартные порты и нестандартные сервисы уязвимее в момент атаки, несмотря на то, что в обычное время они дают чуть большую безопасность. Если они важны, их нужно заранее выносить в отдельный SLA или согласовывать белые списки.
Фильтрация прикладного уровня — дорогая история. Она может увеличить стоимость услуги в 3‑4 раза. Поэтому мы не включаем ее в базовую защиту, а предлагаем как отдельную услугу тем, для кого простой недопустим.
Что делать, если сайт под DDoS‑атакой
Опыт рынка показывает: готовность к атакам зависит не только от провайдера, но и от клиента. Есть несколько шагов, которые клиент может предпринять заранее.
Понять, нужен ли вам отдельный SLA на защиту. Интернет‑магазин, онлайн‑банкинг, SaaS‑платформа, корпоративная почта? Простой даже на пару часов обернётся прямыми потерями. В таких случаях стоит закладывать расходы на расширенную защиту (включая L7‑фильтрацию). Да, она дороже. Иногда в 3‑4 раза, но это всё равно меньше, чем стоимость простоя.
Вспомнить про список мер, которые можно внедрить самостоятельно. А именно:
- настроить rate limiting (ограничение числа запросов от одного пользователя);
- включить гео‑блокировку, если ваш бизнес не работает с конкретными регионами;
- использовать резервные DNS‑серверы;
- распределить сервисы по нескольким дата‑центрам, чтобы падение одного не остановило всё.
Не обманывать себя. «Мы маленькие, нас никто не будет атаковать» или «У нас нет ценной информации». Атаки происходят не только ради выкупа или конкурентной борьбы. Иногда это просто массовые кампании по странам и регионам, где под удар попадает бизнес любого уровня.
И последнее — цена простоя. По оценкам рынка, простой сайта без защиты обходится в среднем от нескольких сотен тысяч рублей за час малому бизнесу до миллионов рублей в час крупной компании. Для e‑commerce во время атаки критичны минуты: покупатель не ждёт, он уходит к конкуренту.
Чем раньше вы настроите хотя бы базовые меры и обсудите с провайдером SLA на защиту, тем выше вероятность, что в следующий раз атака пройдёт для вашего бизнеса почти незаметно.
Вывод
С 2022 года DDoS‑атаки стали сильнее и изощреннее. В 2025 году на российские госсервисы и корпорации совершались атаки пиками до 1‑2 млн поддельных запросов в секунду. Отразить их только силами провайдера или клиента — невозможно. Рабочая защита строится на совместной подготовке. Провайдер использует инфраструктуру и опыт специалистов, а клиент заранее тестирует нагрузку, настраивает сервисы и знает, какие действия предпринять в случае атаки.
cloud4box.com
