DDoS-атаки: типы, симптомы и меры защиты

17 февраля 2026 г. • 7 min read

DDoS не является чем-то новым, но сегодня такие атаки стали намного проще, дешевле и масштабируемее. Раньше нескольких неверно настроенных серверов или небольшой бот-сети хватало, чтобы нарушить работу сервиса. Сейчас мы регулярно видим атаки, которые способны за доли секунды забить канал, перегрузить фаервол или уронить приложение запросами, которые выглядят “обычно”.

Эта статья не про запугивание. Она про контекст: что такое DDoS на самом деле, какие классы атак важны на практике, как распознать их в продакшене и какие контрмеры действительно стоят вашего времени.

Что такое (D)DoS?

В атаке Denial-of-Service (DoS) злоумышленник пытается сделать сервис недоступным не через кражу данных, а через перегрузку или исчерпание ресурсов. Цель - доступность: сайт не открывается, API уходит в таймаут, VPN-шлюз перестает принимать сессии, а DNS-резолверы не успевают обрабатывать запросы.

Буква “D” в Distributed означает, что трафик идет не из одного источника, а из многих. Это может быть ботнет из взломанных устройств, легитимная инфраструктура (reflection/amplification) или комбинация. Для оператора результат выглядит одинаково: вы имеете дело не с одним атакующим, а с распределенным потоком.

Мотивация: зачем запускают DDoS?

Причины часто скучные, но эффективные:

Вымогательство: “Плати, или снова уроним”.
Активизм/политика: видимость, месседж, срыв работы.
Отвлечение: DDoS может занять команду, пока параллельно идет другая атака.
Конкуренция/саботаж: в критические моменты (ticketing, релизы, запуски) даже короткий простой болезнен.
Давление через расходы: не каждая атака нацелена на полный даун; иногда цель - увеличить затраты на облако, нагрузку на поддержку или операционный стресс.

Важные уровни (и почему это важно)

DDoS часто описывают через уровни, потому что уровень подсказывает, какие сигналы смотреть и какие защиты вообще возможны.

Layer 3 (IP): откуда и куда идет.
Layer 4 (TCP/UDP): порты, соединения, handshakes, состояние (state).
Layer 7 (Application): HTTP(S)-запросы, API, бизнес-эндпоинты.
“Layer 8” (бизнес-логика): неофициально, но реально: дорогая логика в приложении, которую можно эксплуатировать.

Главная мысль: идеальная защита на Layer 3/4 может не спасти от Layer-7 атак, потому что запросы выглядят легитимно и становятся “дорогими” только внутри приложения.

Класс атак 1: объем и усиление (часто UDP)

Волюм-атаки пытаются задавить полосу или обработку пакетов (pps). Классический усилитель - reflection/amplification:

Атакующий отправляет небольшие запросы на публично доступные серверы (например, открытые DNS-резолверы).
Подменяет source address и ставит IP жертвы как “source”.
Эти серверы отправляют гораздо более крупные ответы жертве.

Если запрос на 100 байт вызывает ответ на 1 000 байт, это уже фактор 10. В зависимости от протокола и payload фактор может быть существенно выше. Неприятная часть: со стороны жертвы трафик приходит от “нормальных” сервисов, которые не хочется блокировать.

Важный момент: amplification обычно опирается на source IP spoofing. Поэтому ingress filtering (BCP 38) критически важен. Если провайдеры последовательно режут поддельные source-адреса на edge, этот вектор становится гораздо сложнее.

Класс атак 2: истощение протокола и состояния (TCP/Layer 4)

Не каждый DDoS про максимальную полосу. Часто эффективнее создавать state на стороне цели, пока таблицы/ресурсы не заполнятся.

Классический пример - SYN flood для TCP:

Обычно TCP устанавливает соединение через three-way handshake (SYN -> SYN/ACK -> ACK).
В SYN flood атакующий шлет огромное количество SYN, но финальный ACK не приходит.
Сервер держит множество half-open соединений (state) и делает повторы до таймаутов.

Это расходует память и CPU и может ударить по исходящему каналу. И даже если полоса большая: когда таблица сессий забита, “даун” рядом.

Похожая категория - low and slow: атакующий открывает реальные соединения и удерживает их минимальным трафиком, пока web-сервер или load balancer не упрутся в лимиты. Это часто менее заметно, чем большой всплеск по трафику.

Класс атак 3: Layer 7 и “Layer 8” (HTTP, API, дорогие эндпоинты)

Layer-7 атаки часто самые неприятные, потому что их сложнее отличить от легитимного трафика. Примеры:

HTTP flood: множество запросов к динамическим страницам, поиску или login flow.
Slowloris/slow headers: удержание соединений открытыми за счет очень медленной передачи header/body.
“Дорогая” бизнес-логика: эндпоинты, которые запускают тяжелые запросы к БД, внешние API, генерацию PDF, криптографию или даже AI/agent workflow.

Трюк не всегда в “больше трафика”, а в больше работы на один запрос. Малое, но правильно выбранное количество запросов может быть дороже, чем большая волна кешированных статических GET.

Как обнаружить DDoS в продакшене?

Если смотреть только на CPU и RAM, часть атак вы заметите слишком поздно. На практике помогают baseline и несколько надежных метрик:

Трафик: bps и pps на edge (router, firewall, load balancer).
Метрики соединений: новые соединения/с, открытые сессии, SYN backlog, TLS handshakes/с.
HTTP-метрики: RPS, latency (p95/p99), доли 4xx/5xx, таймауты.
Upstream симптомы: packet loss, рост RTT, насыщение линков, события BGP.
Сигналы логов/WAF: необычные пути, невалидные заголовки, много незавершенных запросов, подозрительные user-agent/паттерны.

Самое важное простое: нужен baseline. Без него все выглядит как “просто много”. С baseline сразу заметно, что “маленькие пакеты” или “незавершенные запросы” сильно отклоняются от нормы.

Mitigation: что реально работает

Есть два подхода: make (строить самому) или buy (использовать сервис). Для большинства команд “buy” реалистичнее, потому что DDoS mitigation быстро вырастает в задачу, которую нельзя вести как side project.

1) Поставить слой перед приложением: CDN/WAF/DDoS-провайдер

Для сайтов и API это часто наиболее эффективно:

Anycast распределяет трафик по множеству локаций.
WAF-фильтры режут очевидные Layer-7 паттерны.
Bot management, rate limits и challenge/response снижают “дешевые” атаки.

Важно: не все атаки - HTTP. Если вы публикуете VPN, VoIP, игровые серверы или другие UDP-протоколы, нужны другие уровни защиты в зависимости от архитектуры.

2) Правильно настроить rate limiting и timeouts

Просто, но эффективно при грамотной реализации:

ICMP/“ping”: ограничить, но не запрещать полностью (нужно для диагностики).
HTTP: лимитировать по IP/token/route, особенно на дорогих эндпоинтах.
Slow requests: жесткие таймауты для незавершенных header/body.

Пример (Nginx, сильно упрощенный) для лимитов на route:

limit_req_zone $binary_remote_addr zone=api_per_ip:10m rate=10r/s;

location /api/ {
  limit_req zone=api_per_ip burst=40 nodelay;
}

Это не серебряная пуля, но меняет экономику: “дешевые” атаки становятся сложнее.

3) Архитектура: отделить дорогую работу

Layer-7 DDoS часто бьет не по полосе, а по местам, где один запрос непропорционально дорогой. В обычных компаниях таких мест много: логин, поиск, PDF-экспорт, отчеты, загрузки, сложные DB-запросы, внешние API-вызовы.

Типичный пример: в клиентском портале есть экспорт (“invoice в PDF”, “сгенерировать отчет”, “скачать все ZIP”). В норме это нажимают раз в несколько минут. В атаке тот же эндпоинт дергают сотни или тысячи раз в минуту. Проблема не в полосе; проблема в CPU (рендеринг), БД (queries) и worker pool (threads/соединения). Снаружи это выглядит как “все медленно”. Внутри - таймауты, очереди и БД, которая не успевает.

Хорошая новость: не нужно перестраивать все. Часто достаточно нескольких решений, чтобы отделить дорогую часть от пути запроса и добавить “тормоз”:

Кеширование (включая страницы ошибок), разумные TTL, edge caching.
Асинхронная обработка (очереди) для дорогих задач: вместо “PDF сейчас” - запуск job и выдача позже.
Строгая валидация и ранний abort: ограничение сложности, жесткие лимиты на запрос.
Отдельная защита для логина/поиска/загрузок/экспорта: отдельные rate limits и timeouts, при необходимости отдельные worker pools.
“Degraded mode” (feature flags): временно отключать функции без стресса деплоя.

4) Upstream-опции: фильтрация, scrubbing, аварийные планы

Если масштаб очень большой, трафик нужно фильтровать до того, как он попадет на ваш канал:

Фильтрация у провайдера / scrubbing center
Временные блок-правила (например: “зачем UDP на веб-сервер?”).
Аварийная маршрутизация (например: переключение на “protected” IP).

Это работает только если вы договорились с провайдером заранее. Начинать “ad hoc” в середине инцидента дорого и медленно.

Практичный чеклист (для команд без DDoS-специалистов)

Инвентаризация: какие сервисы публичные? HTTP, DNS, VPN, mail, gaming, VoIP?
Единые точки отказа: DNS-провайдер, reverse proxy, load balancer, один регион?
Наблюдаемость: bps/pps, RPS, latency, ошибки, количество соединений, алерты с baseline.
Укрепить дефолты: timeouts, limits, максимальные размеры header, лимиты соединений, backpressure.
План с провайдером: кто scrubs, кто фильтрует, какие escalation paths.
Runbook: “если X, то Y” + контакты, пороги и переключатели (feature flags).
Тренировки: контролируемые load tests и инцидент-дриллы (легально и согласованно).

Наконец: тестировать, но легально и полезно

Тестирование DDoS - чувствительная тема. Все, что касается публичного интернета, чужих систем или инфраструктуры без явного разрешения, запрещено. Что можно и нужно делать:

Нагрузочные тесты в своем staging (например, для дорогих эндпоинтов).
Chaos tests для зависимостей (cache down, DB slow, более строгие лимиты).
Тренировать процесс реагирования: алерты, коммуникации, эскалация провайдера, аварийные меры.

Источники и ссылки

До следующего раза, Joe