DDoS-атаки остаются одной из самых доступных и разрушительных угроз для онлайн-бизнеса. При минимальных затратах злоумышленник способен парализовать работу сайта, API или целой инфраструктуры. При этом атаки на разных уровнях сетевой модели требуют принципиально разных подходов к защите. Ошибка в выборе инструмента приводит либо к блокировке легитимных пользователей, либо к пропуску вредоносного трафика. Ниже разбираются ключевые различия между атаками на сетевом/транспортном (L3/L4) и прикладном (L7) уровнях, а также принципы построения автоматизированной эшелонированной защиты.
Атаки на L3/L4: перегрузка канала и сетевого оборудования
Атаки на сетевом (L3) и транспортном (L4) уровнях нацелены на исчерпание пропускной способности канала или ресурсов сетевого оборудования. Это объёмные атаки: злоумышленник генерирует огромный поток пакетов, который забивает канал или перегружает межсетевой экран.
Типичные сценарии:
SYN flood. На сервер отправляется лавина TCP-пакетов с флагом SYN. Сервер выделяет ресурсы под каждое соединение, но злоумышленник не завершает рукопожатие. Таблица соединений переполняется, и легитимные пользователи не могут подключиться.
UDP flood. На случайные порты сервера отправляется поток UDP-пакетов. Сервер проверяет, есть ли приложение на каждом порту, и отвечает ICMP-пакетом о недоступности. Ресурсы расходуются на обработку и отправку ответов.
DNS amplification. Злоумышленник отправляет DNS-запросы на открытые резолверы, подменяя обратный адрес на адрес жертвы. Резолверы отправляют жертве усиленный ответ — коэффициент усиления может достигать 50–70 раз.
Главный признак атак на L3/L4 — огромный объём трафика, измеряемый в гигабитах или миллионах пакетов в секунду. Для отражения таких атак требуется фильтрация на уровне сети, до того как трафик достигнет сервера-жертвы.
Атаки на L7: имитация легитимного поведения
Атаки на прикладном уровне (L7) имитируют поведение реальных пользователей. Они не создают аномально высокого объёма трафика, но нагружают конкретные функции приложения: поиск, авторизацию, генерацию отчётов, оформление заказа.
Типичные сценарии:
HTTP flood. Множество запросов к тяжёлой странице или API-методу, которые заставляют сервер выполнять ресурсоёмкие операции: обращаться к базе данных, генерировать PDF, обсчитывать рекомендации.
Slowloris и slow POST. Злоумышленник открывает множество соединений и удерживает их, медленно отправляя заголовки или тело запроса. Сервер держит соединения открытыми, и пул worker-потоков исчерпывается.
Атаки на API. Массовые запросы к конкретному эндпоинту с поддельными или украденными токенами авторизации. Внешне это выглядит как всплеск активности легитимных пользователей.
Главный признак атак на L7 — аномальные паттерны на фоне нормального трафика: резкий рост запросов к конкретной странице, необычное соотношение запросов и сессий, высокая доля ошибок 4xx или 5xx по одному эндпоинту.
Как различается защита для разных уровней
Для отражения атак на L3/L4 требуется фильтрация трафика до того, как он достигнет дата-центра. Эту задачу решают scrubbing-центры провайдеров защиты. Весь входящий трафик направляется на распределённую сеть узлов очистки, где вредоносные пакеты отбрасываются на основе сигнатур, анализа частоты и объёма. Очищенный трафик направляется на сервер. Для больших объёмов также применяется BGP-анонсирование, которое позволяет отводить трафик через scrubbing-центры на уровне маршрутизации.
Для отражения атак на L7 scrubbing-центр недостаточен: запросы выглядят как легитимные и не превышают порогов по объёму. Здесь требуется Web Application Firewall (WAF), который анализирует содержание запросов, сессионную активность, частоту обращений с одного IP к конкретному URL. Современные WAF используют поведенческий анализ и машинное обучение для отличения ботов от людей.
На практике большинство серьёзных атак сочетают оба уровня: сначала идёт SYN flood для истощения сетевых ресурсов, а затем HTTP flood для добивания приложения. Поэтому зрелая защита выстраивается эшелонированно: scrubbing-центр на периметре плюс WAF перед веб-сервером.
Автоматизация защиты: от ручного реагирования к самообороне
Ручное вмешательство при современных скоростях атак означает десятки минут простоя, пока инженер анализирует трафик и меняет правила. Автоматизация строится вокруг связки «мониторинг — WAF — scrubbing-центр» и включает три ключевых элемента:
- Мониторинг и детектирование. Система фиксирует аномалию: резкий рост запросов к одному URL, падение доли успешных ответов, рост времени отклика.
- Автоматическая активация защитных правил. WAF включает капчу, добавляет rate limiting, блокирует IP с аномальным поведением. При необходимости сигнал передаётся в scrubbing-центр.
- Эскалация. Если атака выходит за пределы возможностей WAF, scrubbing-центр переводит трафик в режим очистки.
Критическое условие автоматизации — качество детектирования. Слишком агрессивные правила блокируют реальных пользователей и снижают бизнес-показатели. Слишком мягкие — пропускают атаку. Оптимальный баланс достигается настройкой порогов на основе исторических данных и регулярным тестированием в рамках контролируемых симуляций атак.
Чек-лист для построения эшелонированной защиты от DDoS
- Провести инвентаризацию критичных внешних сервисов (сайт, API, почтовые серверы).
- Настроить мониторинг трафика с оповещениями об аномалиях.
- Подключить scrubbing-центр для защиты от объёмных атак на L3/L4.
- Развернуть WAF перед веб-сервером для защиты от атак на L7.
- Настроить автоматические сценарии реагирования: при обнаружении аномалии WAF должен автоматически включать защитные правила.
- Ограничить rate limiting для критичных эндпоинтов API.
- Настроить резервные каналы связи и план восстановления на случай длительной атаки.
- Регулярно тестировать устойчивость защиты через контролируемые симуляции (chaos engineering).
Типовой сценарий: автоматизация защиты в финтех-сервисе
Финтех-компания, предоставляющая API для онлайн-платежей, столкнулась с серией DDoS-атак на публичный эндпоинт. Атаки начинались поздно вечером, когда инженеры не были на дежурстве — простой API длился по 40–60 минут, пока кто-то вручную не активировал защитные правила.
После внедрения автоматической связки поведенческого мониторинга и WAF время реакции сократилось до нескольких секунд. При обнаружении аномального роста ошибок 429 на конкретном эндпоинте WAF автоматически включает дополнительные проверки, не дожидаясь вмешательства человека. За первые полгода работы система отразила 14 атак, из которых только две потребовали ручного анализа — остальные были купированы автоматически.
Сценарий подтверждает, что автоматизация защиты от DDoS — не вопрос продвинутого DevOps, а необходимость для любого сервиса, чей простой напрямую конвертируется в финансовые потери.
Материалы канала ориентированы на специалистов по информационной безопасности и IT-руководителей. Подписывайтесь, чтобы получать актуальные методологии и разборы инцидентов.
Вопрос для обсуждения: Какие инструменты и подходы к автоматизации защиты от DDoS показали наибольшую эффективность в практике и с какими сложностями пришлось столкнуться при их внедрении?