Привет, Хабр! Меня зовут Роман Доморацкий, я руководитель направления разработки Рег.облака. Мои команды отвечают за то, чтобы сетевые и инфраструктурные функции облака появлялись в личном кабинете.
В этой статье хочу разобрать не защиту от DDoS вообще, а более узкий сценарий — как в облаке устроены два режима защиты от DDoS (базовая On-Demand на L3–L4 и расширенная Always-On на L3–L7). Покажу, где у On-Demand появляются архитектурные ограничения, почему для L7 уже недостаточно просто фильтровать пакеты и что меняется для приложения после подключения защиты через домен и SSL/TLS-сертификат.
Навигация по тексту
В этой статье будем опираться на практическое деление атак по уровням: L3–L4 и L7. Для облачной защиты это важнее, чем длинная классификация по всем возможным типам флуда. На L3–L4 атакующий перегружает канал или сетевое оборудование: растет PPS, битрейт, количество TCP-сессий, появляются характерные паттерны флуда. Такие атаки проще заметить по сетевым метрикам и отфильтровать до попадания трафика на сервер.
На L7 проблема другая: запросы уже выглядят как прикладной трафик. Боты могут имитировать пользователей, ходить в тяжёлые ручки, создавать нагрузку на веб-сервер, базу данных или бизнес-логику. Поэтому одной сетевой фильтрации здесь недостаточно — нужно анализировать HTTP-поведение.
Как устроены DDoS-атаки на L3–L4 и L7
Сетевой уровень L3. Переполнение интернет-канала
Что делают: массово отправляют колоссальный объем технических пакетов данных.
Что происходит: пакеты бесполезные, но их так много, что они полностью забивают всю доступную ширину канала.
Последствия: сетевой интерфейс перегружен обработкой «мусора», запросы реальных клиентов не могут пробиться.
Транспортный уровень L4. Исчерпание ресурсов сетевого оборудования (SYN Flood)
Что делают. Отправляют тысячи запросов на открытие TCP-сессии.
Что происходит. На каждый такой запрос сервер резервирует часть оперативной памяти и ждёт подтверждения от клиента. Злоумышленники намеренно не отправляют это подтверждение.
Последствия. Заканчивается лимит по памяти и соединениям, оборудование перестает принимать новые запросы, в том числе от реальных клиентов.
Чтобы было понятнее, приведу аналогию. Представьте, что вы хотите зайти в метро, но перед входом собралась огромная толпа. Люди просто стоят и никуда не идут — они не проходят внутрь, а вам из-за них не попасть к дверям. Вход заблокирован не замком, а самой толпой. Так работают сетевые атаки: канал или оборудование перегружены пустыми запросами, и никто не может достучаться до сервиса.
Уровень приложения L7
Что делают. Массово отправляют HTTP-запросы к тяжёлым операциям — базе данных или бизнес-логике. Боты имитируют поведение реальных пользователей, чтобы обходить простые фильтры.
Что происходит. Критически растет нагрузка на RAM и CPU, заканчиваются лимиты соединений к веб-серверу.
Последствия. Сервис полностью недоступен или запросы выполняются очень долго.
Продолжим аналогию с метро. Вы каким-то чудом вошли, но дальше не продвинуться. Люди стоят у турникетов, прикладывают неработающие карты, несколько раз проходят через рамку металлодетектора, зовут сотрудников — делают что угодно, только не идут дальше. Имитаторов сложнее вычислить, чем равнодушную толпу у входа, и именно поэтому L7-атаки считаются самыми неприятными. DDoS-Guard, с которым мы работаем в партнерстве, закрывает ключевые сценарии на каждом из уровней. Вот сводка типовых атак, от которых защищает сервис:
Уровень OSI |
Примеры атак |
|---|---|
L3 — сетевой. |
DNS Amplification, DNS Flood, ICMP Flood, VoIP Flood, NTP Flood, Ping Flood, UDP Flood |
L4 — транспортный. |
SYN Flood, ACK / PUSH ACK Flood, SYN-ACK Flood, Fake Session Attack, Multiple ACK Fake Session Attack, Multiple SYN-ACK Fake Session Attack, Misused Application Attack |
L7 — прикладной. |
HTTP Flood, Single Request HTTP Flood, Single Session HTTP Flood, Faulty Application Attack, Fragmented HTTP Flood, SlowLoris (Session Attack), Recursive HTTP GET Flood |
Что меняется в DDoS-атаках и почему On-Demand не всегда хватает
Мы свели оценки трех ведущих вендоров — «Лаборатории Касперского», StormWall и DDoS-Guard. Общий вывод из этих отчетов такой: растет доля L7, чаще встречаются комбинированные сценарии, а зондирующие атаки сокращают время на ручную реакцию.
Для On-Demand-модели это критично. Если защита включается после обнаружения аномалии, короткий импульс или разведочный запрос может закончиться раньше, чем система успеет перестроить маршрут. А L7-атака вообще может не выглядеть как сетевой флуд: по метрикам трафик похож на легитимный, но приложение уже тратит CPU, RAM и соединения на обработку мусорных запросов.
Немного цифр:
рост атак на российские компании — 42 %;
увеличение числа инцидентов — в 1,8 раза год к году;
рост интенсивности трафика — 70 %;
рост средней мощности — 63 %, с 71 до 116 Гбит/с;
пиковые значения — до 2,5 Тбит/с.
Смена тактики: от грубой силы к сложным сценариям
Атакующие становятся хитрее. Три заметных тренда этого года:
Сдвиг к L7. Атаки на уровне приложения превышают L3-L4 в пять раз. Защиты только сетевого периметра уже недостаточно.
Многовекторность. Доля комбинированных атак достигает примерно 50 % всех инцидентов. Злоумышленники одновременно бьют по нескольким уровням — в расчёте на то, что защита есть не везде.
Разведка перед основным ударом. Доля зондирующих атак выросла с 4 до 33 %. Сначала проверяют, какая защита стоит у цели, потом бьют по-настоящему.
Почему здесь важен не размер компании, а архитектура защиты
DDoS-атака не всегда выглядит как большой и заметный инцидент, на который можно спокойно отреагировать вручную. Часть сценариев строится на коротких импульсах, зондировании и прикладной нагрузке: трафик может выглядеть почти легитимно, но при этом занимать соединения, CPU или RAM. Поэтому вопрос не только в том, падает ли сайт во время атаки. Важно, что происходит до этого момента: успевает ли защита увидеть аномалию, нужно ли переключать маршрут, рвутся ли установленные TCP-соединения, анализируется ли HTTP-поведение на L7 и какие запросы в итоге доходят до сервера.
С теорией разобрались. Теперь посмотрим, как эта логика устроена в облаке и почему режим защиты важен не меньше, чем список типов атак, которые она умеет фильтровать.
Как работает защита от DDoS
У защиты от DDoS в Рег.облаке два уровня: базовая защита L3-L4, которая работает в режиме On-Demand, и расширенная защита L3–L7, работающая в режиме Always-On. Разберем каждый отдельно.
Базовая защита L3-L4 — On-Demand
Базовая защита включена по умолчанию для всех IP-адресов и работает по модели On-Demand. В штатном режиме трафик идёт к вашему серверу напрямую. Когда системы мониторинга на стороне провайдера видят аномалию — пиковый рост PPS, флуд пакетами определённого типа, скачок битрейта, — маршрутизация меняется, и трафик уходит в центры очистки DDoS-Guard. После фильтрации на L3-L4 до сервера доходит уже только то, что похоже на легитимные запросы.
Важно понимать, что у такой модели есть принципиальные ограничения, и они следуют из самой архитектуры, а не из тарифа:
Реакция занимает минуты. Сначала мониторинг должен заметить аномалию, потом отработать переключение BGP. Короткие импульсы до нескольких десятков секунд система просто не успевает увидеть — и зондирующие тоже.
В момент переключения рвутся установленные TCP-соединения. Для HTTP это, как правило, не критично — клиент перезагрузит страницу. Для WebSocket, gRPC-стримов и длинных сессий это заметно сильнее.
Анализ ограничен L3-L4. Атаки, которые живут на уровне приложения и по сетевым метрикам выглядят как нормальный трафик, базовая защита не отличает от легитимных запросов.
Расширенная защита L3–L7 — Always-On
Расширенная защита работает в режиме Always-On: трафик идет через сеть очистки постоянно, а не только во время инцидента. Переключений нет, потому что переключать нечего — ваш сервер с самого начала «видит» только узлы DDoS-Guard. Что технически отличается от базовой:
нет окна реакции: короткие импульсные и зондирующие атаки не пропускаются просто потому, что для них не требуется принимать решение включать или нет очистку;
установленные соединения не рвутся — никаких событий в духе «перезагрузите страницу»;
появляется фильтрация на L7, где HTTP-запрос анализируется на поведение — можно отличать реальных пользователей от ботов
Что происходит с трафиком
Упрощенно цикл выглядит так: клиентский запрос уходит не напрямую на ваш IP, а на анонсированный через BGP префикс DDoS-Guard. Там срабатывает каскад фильтров — сначала L3-L4 (сигнатуры флуда, rate-limit по источникам, проверки корректности TCP-стейта), затем, если подключен L7, терминируется TLS и включается анализ HTTP-запросов. Легитимный трафик уходит в туннель до вашего сервера, вредоносный дропается на входе в сеть очистки.
С точки зрения вашего приложения это значит, что у сервера один постоянный «клиент» — узлы очистки. Реальные source IP пользователей при L7 приходят в заголовке X-Forwarded-For, и если в приложении есть rate-limit или геоблок по адресу, его настройки нужно корректировать под новый источник. Если интересно разобраться глубже, в базе знаний DDoS-Guard есть документация по форматам заголовков и режимам фильтрации.
Что нужно учесть при включении L7-защиты
Активация постоянной L3/L4-защиты
Подключить расширенную защиту можно двумя способами — при заказе нового сервера или через отдельный плавающий IP-адрес для уже существующей машины.
Вариант 1. Заказ сервера.
При создании сервера в разделе «Настройки сети» включаете публичный плавающий IP-адрес и выбираете тип защиты — «Расширенная защита от DDoS на уровнях L3–L7». Там же выбираете один из трёх тарифов. Тарифы отличаются пропускной способностью полосы легитимного трафика, количеством доменов для L7-защиты и количеством правил в чёрных и белых списках. Вредоносный трафик фильтруется без ограничений и отдельно не тарифицируется.
Важный нюанс: после заказа IP-адреса сменить тип защиты с базовой на расширенную и обратно нельзя. Решение об уровне защиты принимаете сразу.
Вариант 2. Заказ и привязка IP-адреса.
Подойдет, если сервер уже создан. Зайдите в раздел «Сетевая инфраструктура» → «Плавающие IP-адреса», создайте новый IP с расширенной защитой и привяжите его к нужной виртуальной машине.
Что вы увидите в интерфейсе.
После этого в списке плавающих IP-адресов появится жёлтая метка «L7: не настроена» — она означает, что постоянная L3-L4-защита активна, а L7 ещё предстоит настроить. Серой меткой «Базовая защита» отмечены IP-адреса с базовой прерываемой защитой.
Активация L7-защиты приложения
Чтобы защитить приложение на уровне L7, провайдер должен расшифровывать HTTPS-трафик ваших клиентов. Поэтому для L7-защиты понадобится добавить домен и SSL/TLS-сертификат. Дальше — по шагам.
Шаг 1. Настройка DNS-серверов.
Для домена, который хотите защитить, укажите DNS-серверы Рег.облака — ns5.hosting.reg.ru и ns6.hosting.reg.ru.
Шаг 2. Добавление A-записи.
Создайте A-запись, указывающую на защищённый IP-адрес, который заказали ранее. После этого подождите около 24 часов, пока изменения разойдутся по глобальной системе DNS.
Шаг 3. Добавление домена и SSL-сертификата.
Вернитесь в личный кабинет Рег.облака, откройте защищенный IP-адрес и на вкладке «Настройка защиты L3–L7» нажмите «Добавить домен». Укажите домен, для которого настраивали A-запись.
По сертификату доступны две опции:
бесплатный Let's Encrypt — выпускается автоматически и продлевается каждые 90 дней, хранится у DDoS-Guard;
пользовательский — вставляете публичную и приватную части в формате PEM.
Пользовательский сертификат применяется мгновенно, Let's Encrypt — за 1–2 часа. Если попытаетесь добавить домен раньше, чем разойдется A-запись, интерфейс покажет ошибку «не удалось найти A-запись для домена». После успешного добавления метка меняется на синюю «L3–L7: защита активна». В этот момент разблокируются операции по управлению услугой.
Все операции доступны в личном кабинете без тикетов и ожиданий.
Вместо выводов
Главное, что поменялось за последние пару лет, — DDoS перестал быть выборочной историей. Раньше можно было рассуждать в логике «нас это не касается, мы слишком маленькие». Сейчас основной поток — это автоматические сканеры и ботнеты, которые не выбирают цели по выручке. Они просто перебирают адреса из своих баз и бьют по всему, что ответило на порт 80 или 443.
Поэтому при выборе защиты важно смотреть не только на сам факт ее наличия, но и на режим работы. On-Demand помогает закрывать объемные атаки на L3–L4, но зависит от обнаружения аномалии и переключения маршрута. Always-On пропускает трафик через сеть очистки постоянно и добавляет фильтрацию на L7, но требует корректной настройки домена, сертификата и обработки реальных IP-адресов в приложении.
Если у вас есть опыт настройки DDoS-защиты на других провайдерах, на что стоит обращать внимание при выборе — приходите в комментарии, обсудим!