DDoS

DDoS, или Distributed Denial of Service, — распределенная атака на доступность информационной системы. Ее цель — создать такую нагрузку на сайт, сервер, сеть или приложение, чтобы легитимные пользователи не могли нормально получить доступ к сервису.

Главная особенность DDoS заключается в распределенности: запросы или сетевой трафик поступают сразу от большого количества устройств или сетевых узлов. Поэтому простая блокировка одного IP-адреса обычно не решает проблему.

DDoS может быть направлена на пропускную способность интернет-канала, сетевое оборудование, таблицы соединений Firewall, Web Server, API, Database или отдельную ресурсоемкую бизнес-функцию.

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

Что такое DDoS простыми словами

Представим интернет-магазин, который обычно получает 500 запросов в секунду.

Во время DDoS на него внезапно начинают поступать десятки или сотни тысяч запросов.

Legitimate users → Website
Attack sources → Website
Attack sources → Website
Attack sources → Website

Server, Load Balancer или интернет-канал не справляется с нагрузкой. Страницы открываются медленно, API отвечает ошибками или сервис становится полностью недоступен.

Расшифровка DDoS

DDoS расшифровывается как Distributed Denial of Service — распределенный отказ в обслуживании.

Distributed означает, что атака идет из множества источников, а Denial of Service — что результатом становится частичная или полная недоступность системы.

DDoS и DoS

DoS и DDoS решают похожую задачу, но отличаются масштабом источников.

Цель DDoS-атаки

Целью может быть не уничтожение данных, а нарушение Availability.

Для бизнеса это приводит к:

• недоступности сайта;
• сбоям API;
• потере заказов;
• остановке личного кабинета;
• ошибкам онлайн-платежей;
• росту нагрузки на техническую поддержку;
• репутационным потерям;
• нарушению SLA.

Что именно перегружает DDoS

У любой инфраструктуры есть ограниченные ресурсы.

Атакующий может пытаться исчерпать:

• Bandwidth;
• Packets per Second;
• Connections;
• CPU;
• RAM;
• Worker Threads;
• Connection Pool;
• Database Connections;
• Application Requests.

Основные виды DDoS-атак

Условно атаки можно разделить на несколько групп.

Volumetric DDoS

Volumetric Attack пытается создать объем трафика, превышающий возможности интернет-канала или инфраструктуры.

Даже если Server имеет свободный CPU, пользователи не смогут подключиться, если внешний канал полностью забит.

Почему локальный Firewall не спасает от большого DDoS

Если входящий канал уже перегружен до того, как Traffic дошел до Firewall, локальное устройство не может освободить пропускную способность провайдера.

Поэтому крупные Volumetric Attacks желательно фильтровать выше по сети — у ISP, CDN или специализированного Anti-DDoS Provider.

Protocol DDoS

Такие атаки используют особенности TCP/IP и сетевого оборудования, чтобы исчерпать State Table, Connection Tracking или другие ограниченные ресурсы.

Нагрузка может измеряться не только битами в секунду, но и количеством Packets или Connections.

SYN Flood

SYN Flood связан с этапом установления TCP Connection.

Server получает большое количество запросов на создание соединения, но часть из них не завершается нормальным Handshake.

Если инфраструктура плохо защищена, таблица ожидающих соединений может заполниться.

TCP Handshake

Обычное соединение устанавливается по схеме:

Client → SYN → Server
Client ← SYN-ACK ← Server
Client → ACK → Server

При атаке злоумышленник пытается создать огромное количество подобных состояний быстрее, чем Server успевает их освобождать.

Application Layer DDoS

Application Layer Attack направлена не на сам интернет-канал, а на конкретную функцию приложения.

Например:

GET /search?query=...
POST /reports/generate
POST /login

Если один Request запускает тяжелый SQL Query или генерацию большого отчета, сравнительно небольшой поток запросов может сильно нагрузить Backend.

HTTP Flood

HTTP Flood создает большое количество HTTP или HTTPS Requests.

Внешне они могут быть похожи на обычный пользовательский трафик, поэтому фильтрация сложнее, чем при очевидном сетевом Flood.

GET Flood

Злоумышленник может массово запрашивать страницы или API Endpoints.

Особенно опасны URL, которые плохо кэшируются и каждый раз вызывают Backend или Database.

POST Flood

POST Request часто запускает более сложную бизнес-логику: Authentication, поиск, оформление заказа, создание отчета или загрузку данных.

Большое количество таких Requests способно быстро исчерпать ресурсы приложения.

DDoS и Database

Иногда непосредственной целью становится не Web Server, а Database за ним.

Например, атакующий вызывает API Endpoint, который выполняет тяжелую выборку без хорошего индекса.

Internet
↓
API
↓
Expensive SQL Query
↓
Database CPU 100%

В этом случае сетевой Traffic может быть относительно небольшим, но сервис все равно перестает работать.

DDoS и Login

Login Endpoint часто выполняет проверку Password, обращается к Database, LDAP или Identity Provider.

Массовые запросы могут создавать высокую нагрузку.

Для защиты используются Rate Limiting, CAPTCHA-подобные механизмы, WAF и оптимизация Authentication Infrastructure.

DDoS и API

API особенно уязвимы к Application Layer DDoS, если один Request запускает дорогую операцию.

Полезно ограничивать:

• Requests per Client;
• Query Complexity;
• размер Request Body;
• число параллельных операций;
• время выполнения.

DDoS и GraphQL

В GraphQL один Query может запросить большое количество связанных данных.

Поэтому кроме обычного Rate Limiting полезны Query Depth и Complexity Limits.

Иначе небольшой поток сложных запросов способен создать значительную нагрузку.

DDoS и WebSocket

WebSocket создает долгоживущие Connections.

Если Server способен обслуживать ограниченное число соединений, массовое открытие Sessions может исчерпать File Descriptors, RAM или Connection Limits.

DDoS и DNS

DNS также может быть целью атаки.

Если авторитетные DNS Servers недоступны, пользователи могут не получить IP Address сайта, даже если сам Web Server работает.

Поэтому отказоустойчивость DNS является важной частью Anti-DDoS Architecture.

Reflection Attack

Reflection Attack использует промежуточные интернет-сервисы для отправки ответов в сторону жертвы.

Атакующий формирует запрос так, чтобы ответ был отправлен не ему, а целевому IP.

Amplification Attack

Amplification означает, что небольшой входящий запрос вызывает значительно больший ответ.

Если злоумышленник способен подменить Source IP в подходящей сетевой среде, множество промежуточных серверов может направить большие ответы жертве.

Почему Reflection опасна

Жертва видит Traffic не напрямую от атакующего, а от большого количества легитимных сетевых сервисов.

Это усложняет простую фильтрацию по списку Source IP.

IP Spoofing

IP Spoofing — подмена Source IP в сетевом пакете.

Она может использоваться в некоторых Reflection и Amplification сценариях.

Фильтрация поддельного Source Traffic на стороне сетевых операторов уменьшает такие возможности.

Botnet

Botnet — сеть зараженных или контролируемых устройств, которыми злоумышленник управляет удаленно.

Для DDoS могут использоваться:

• компьютеры;
• серверы;
• роутеры;
• камеры;
• IoT Devices;
• другие подключенные к интернету устройства.

Каждый отдельный узел может генерировать небольшой Traffic, но суммарный поток становится огромным.

Почему IoT используют в DDoS

Некоторые IoT Devices имеют слабую Security, редко обновляются и постоянно подключены к интернету.

После компрометации их можно использовать как часть Botnet.

DDoS и CDN

CDN принимает пользовательский Traffic на распределенной Edge Infrastructure.

Это помогает распределить нагрузку и остановить часть атаки до Origin Server.

Users + Attack
↓
CDN Edge
↓ filtered traffic
Origin

Для публичных сайтов CDN часто является одним из основных уровней DDoS Protection.

DDoS и Anycast

Anycast позволяет объявлять один IP Address из нескольких географических точек сети.

Traffic распределяется по инфраструктуре, что помогает большим провайдерам масштабировать обработку входящих атак.

Пользователю необязательно самостоятельно строить такую сеть — она может быть частью CDN или Anti-DDoS Service.

DDoS и WAF

WAF полезен против Application Layer Attacks.

Он анализирует HTTP Requests и может применять:

• Rate Limiting;
• IP Reputation;
• Bot Filtering;
• Managed Rules;
• Custom Rules;
• Challenge Mechanisms.

Но WAF сам по себе не остановит огромный Volumetric Flood, если канал к нему уже перегружен.

DDoS и Firewall

Firewall способен блокировать ненужные Ports, Protocols и Sources и ограничивать часть Connections.

Но возможности ограничены пропускной способностью самого Firewall и внешнего канала.

Для крупных атак фильтрация должна выполняться ближе к источникам Traffic или на сети провайдера.

DDoS и Load Balancer

Load Balancer распределяет легитимную нагрузку между несколькими Backend Servers.

Это повышает устойчивость, но не является полноценной DDoS Protection.

Если атака превышает возможности самого Balancer или интернет-канала, добавление Backend Servers не решит проблему.

Horizontal Scaling

Автоматическое добавление Instances может помочь при всплеске обычного Traffic и части Application Layer нагрузки.

Но бесконечно масштабироваться невозможно.

Кроме того, Attack может резко увеличить Cloud Costs.

DDoS и Auto Scaling

Auto Scaling полезен как дополнительный уровень устойчивости, но должен сочетаться с Rate Limits и фильтрацией.

Иначе атакующий фактически заставляет компанию оплачивать все больше вычислительных ресурсов.

Экономическая DDoS-атака

В Cloud даже если сервис остается доступным, огромный объем Requests может увеличить расходы на Traffic, Serverless Invocations, Database Operations и Compute.

Поэтому защита должна контролировать не только Availability, но и Cost Exposure.

DDoS и Rate Limiting

Rate Limiting ограничивает количество действий от клиента за заданный период.

Например:

/login → 10 requests/minute
/search → 100 requests/minute

Для распределенной атаки одного лимита по Source IP может быть недостаточно, потому что запросы приходят от множества Addresses.

Rate Limiting по IP

Простой IP Limit хорошо работает против одного агрессивного Client, но при Botnet каждый IP может отправлять небольшое число запросов.

Тогда нужны дополнительные признаки: Account, Token, Session, ASN, Geography, Behavioral Pattern.

Challenge Mechanism

Перед передачей подозрительного клиента Backend защитная система может попросить выполнить дополнительную проверку.

Так часть автоматического Bot Traffic отсекается до приложения.

CAPTCHA и DDoS

CAPTCHA может помочь для отдельных пользовательских Endpoints, но не является универсальной DDoS Protection.

Она не подходит для Machine-to-Machine API и не решает проблему Volumetric Attack.

Bot Management

Bot Management анализирует поведение клиентов и пытается различать обычных пользователей, поисковых Crawlers и автоматизированный вредоносный Traffic.

Это особенно полезно против Layer 7 DDoS.

DDoS и кэширование

Cache уменьшает количество Requests, доходящих до Backend.

Если популярная страница обслуживается на CDN Edge, миллионы запросов не обязательно создадут такую же нагрузку на Origin.

Cacheable и Uncacheable Requests

Атакующий может специально выбирать динамические URLs, которые нельзя обслужить из Cache.

Поэтому защита не должна строиться только на кэшировании.

Origin Protection

Если сайт находится за CDN или Anti-DDoS Proxy, Origin Server не должен оставаться доступным напрямую из интернета.

Иначе злоумышленник может узнать его IP и отправить Traffic в обход защитного слоя.

Как скрыть Origin

Firewall можно настроить так, чтобы Origin принимал Connections только от Networks защитного провайдера.

CDN → Origin: allow
Internet → Origin: deny

Также важно не публиковать реальный IP в старых DNS Records или других сервисах без необходимости.

DDoS и Reverse Proxy

Reverse Proxy может применять Limits, Cache и Connection Control до Backend.

Но локальный Proxy ограничен ресурсами той инфраструктуры, в которой он запущен.

DDoS и API Gateway

API Gateway может выполнять Authentication, Quotas и Rate Limiting.

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

DDoS и Microservices

Одна внешняя атака может перегрузить конкретный Microservice, а затем вызвать Cascading Failure.

Например, перегруженный Order Service начинает создавать тысячи Requests к Database и Payment Service.

Cascading Failure

Каскадный отказ возникает, когда проблема одного компонента распространяется на другие.

Для уменьшения риска используются:

• Timeout;
• Circuit Breaker;
• Bulkhead;
• Queue Limits;
• Backpressure;
• Rate Limiting.

Backpressure

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

Это полезно как при ошибках, так и во время злонамеренной нагрузки.

Timeout

Если Backend зависает на 60 секунд для каждого атакующего Request, Worker быстро исчерпываются.

Разумные Timeouts освобождают ресурсы быстрее.

Connection Pool

Application может иметь ограниченный Pool соединений с Database.

Если DDoS создает слишком много параллельных Requests, Pool полностью занят, и даже обычные пользователи перестают получать обслуживание.

Bulkhead

Bulkhead разделяет ресурсы между функциями.

Например, генерация отчетов не должна использовать все Worker Threads, необходимые Login и оформлению заказа.

Так атака на один Endpoint меньше влияет на остальные функции.

Priority Queue

Некоторые системы могут отдавать приоритет критичным операциям.

Например, платежные callbacks обслуживаются отдельно от тяжелых пользовательских отчетов.

DDoS и Serverless

Serverless Platform способна быстро масштабироваться под Requests, что улучшает Availability.

Но злоумышленник может вызвать огромное количество Invocations и увеличить расходы.

Поэтому нужны Quotas, WAF и Limits.

DDoS в Kubernetes

Kubernetes может масштабировать Pods, но внешний Flood сначала проходит через Load Balancer, Ingress и Network Infrastructure.

Protection должна существовать до Cluster Edge.

Внутри кластера также полезны Resource Limits и Autoscaling.

Resource Limits

Если один Pod под атакой способен занять всю память Node, проблема распространяется на соседние Workloads.

CPU и Memory Limits помогают уменьшить Blast Radius.

DDoS и Container

Контейнеризация сама по себе не защищает от DDoS.

Приложение внутри Container все равно может исчерпать CPU, Memory, Network или Database Connections.

DDoS и облако

Cloud Infrastructure предоставляет возможность быстро масштабироваться и использовать Managed DDoS Protection.

Но ответственность за архитектуру приложения, Rate Limits и защиту Origin остается важной.

Always-on Anti-DDoS

При Always-on модели Traffic постоянно проходит через инфраструктуру защиты.

Атака фильтруется без необходимости вручную переключать маршрутизацию после начала инцидента.

On-demand Anti-DDoS

При другой модели Traffic перенаправляется в Scrubbing Center только после обнаружения атаки.

Такой подход может быть дешевле, но требует надежного Detection и быстрого переключения.

Scrubbing Center

Scrubbing Center принимает атакуемый Traffic, отделяет подозрительную часть и отправляет очищенный поток в инфраструктуру клиента.

Internet Traffic
↓
Scrubbing Center
↓ clean traffic
Data Center

Blackholing

Blackhole Routing направляет Traffic к определенному IP в никуда.

Это может защитить остальную сеть от перегрузки, но атакуемый сервис при этом становится недоступен.

Такой механизм является крайней мерой, а не полноценной защитой доступности.

Traffic Scrubbing

В отличие от Blackhole, Scrubbing пытается сохранить легитимный Traffic и удалить вредоносный.

Для бизнеса это значительно полезнее, поскольку сервис продолжает работать.

Как понять, что идет DDoS

Типичные признаки:

• резкий рост Traffic;
• увеличение Requests per Second;
• рост Latency;
• большое количество новых Connections;
• HTTP 429, 502, 503 или 504;
• CPU 100%;
• Database Connection Exhaustion;
• Network Packet Loss;
• недоступность сервиса из разных регионов.

DDoS или обычный рост аудитории

Резкий Traffic Spike не всегда является атакой.

Причиной может быть рекламная кампания, новость, распродажа или вирусная публикация.

Поэтому Detection должен учитывать не только объем, но и поведение Requests.

Признаки вредоносного трафика

Подозрительными могут быть:

• одинаковые URL с огромной частотой;
• аномальное распределение User-Agent;
• невозможная скорость действий;
• массовые запросы к тяжелому Endpoint;
• аномальный рост Connections;
• Traffic из неожиданных сетей.

Baseline

Чтобы заметить аномалию, полезно знать нормальный профиль системы.

Например, сайт обычно получает 2 000 Requests в секунду днем и 300 ночью.

Внезапный рост до 80 000 ночью требует анализа.

DDoS Monitoring

Полезные метрики:

DDoS и Observability

Нужно смотреть одновременно Network Metrics, WAF Logs, Load Balancer, Application Metrics и Database.

Тогда можно понять, где именно находится Bottleneck.

Почему только CPU недостаточно

При Volumetric Attack CPU сервера может быть 10%, но сайт уже недоступен из-за переполненного канала.

При Layer 7 Attack наоборот, Network Traffic может быть небольшим, но Database CPU — 100%.

DDoS и SIEM

SIEM может собирать события от Firewall, WAF, CDN и Servers.

Но для очень большого потока NetFlow или HTTP Events могут потребоваться специализированные Monitoring Systems.

Что делать во время DDoS

1. Подтвердить тип инцидента.
2. Определить, какой ресурс перегружен.
3. Связаться с ISP или Anti-DDoS Provider.
4. Включить или усилить WAF Rules.
5. Ограничить тяжелые Endpoints.
6. Включить Rate Limiting.
7. Защитить Origin.
8. Проверить Database и Connection Pools.
9. Следить за бизнес-метриками.

Почему нельзя начинать защиту только после атаки

Если интернет-канал уже полностью перегружен, быстро развернуть локальный Firewall или изменить Web Server может быть поздно.

Anti-DDoS Architecture желательно проектировать заранее.

DDoS Runbook

Runbook описывает действия команды при атаке.

В нем полезно указать:

• контакты ISP;
• контакты Anti-DDoS Provider;
• кто принимает решение о блокировках;
• как переключить DNS или Routing;
• какие Endpoints можно временно отключить;
• где смотреть Monitoring.

DDoS и Incident Response

Во время инцидента Network, Security, DevOps и Application Teams должны действовать совместно.

Network Team видит объем Traffic, а разработчики могут быстро определить, какой Endpoint перегружает Database.

Защита критичных функций

При атаке можно временно отключить второстепенные функции, чтобы сохранить основной бизнес-процесс.

Например, отключить тяжелую генерацию отчетов, но оставить Login и оформление заказа.

Degraded Mode

Приложение может иметь упрощенный режим работы.

Например, показывать Cached Product Catalog, временно отключив персонализированные рекомендации.

Это повышает Availability во время экстремальной нагрузки.

DDoS и SLA

DDoS напрямую влияет на Availability и выполнение SLA.

Поэтому при критичных онлайн-сервисах защита от атак должна учитываться еще на этапе архитектуры.

DDoS и RTO

Компания должна понимать, сколько времени сервис может оставаться недоступным.

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

Деловые последствия DDoS

Для интернет-магазина один час недоступности может означать потерянные продажи.

Для SaaS — нарушение SLA и отток клиентов.

Для финансового сервиса — невозможность выполнить критичные операции.

Поэтому DDoS является не только техническим, но и бизнес-риском.

Типичные ошибки защиты от DDoS

1. Надеяться только на локальный Firewall.
2. Не защищать Origin IP.
3. Считать Auto Scaling полноценной защитой.
4. Не ограничивать тяжелые API Endpoints.
5. Не иметь Rate Limiting.
6. Не мониторить Network Traffic.
7. Не иметь контакта с ISP.
8. Не тестировать Incident Runbook.
9. Публиковать Database или Admin Endpoints напрямую.
10. Не учитывать стоимость Cloud Traffic во время атаки.

Как строить защиту от DDoS

Шаг 1. Определить критичные сервисы

Нужно понимать, какие сайты и API должны оставаться доступными в первую очередь.

Шаг 2. Измерить нормальную нагрузку

Без Baseline сложно отличить атаку от обычного роста пользователей.

Шаг 3. Использовать распределенную фильтрацию

Для публичных сервисов полезны CDN и Anti-DDoS Provider.

Шаг 4. Защитить Application Layer

Настройте WAF, Rate Limits и ограничения дорогих запросов.

Шаг 5. Закрыть Origin

Backend должен принимать внешний Traffic только через защитный Edge.

Шаг 6. Настроить Resource Limits

Один Endpoint не должен исчерпывать все ресурсы системы.

Шаг 7. Подготовить Monitoring

Следите за Network, HTTP, Application и Database одновременно.

Шаг 8. Создать Runbook

Команда должна заранее знать порядок действий при атаке.

Практический пример

Интернет-магазин обычно получает около 3 000 HTTP Requests в секунду.

В один момент Traffic вырастает до 90 000 Requests в секунду. Большинство запросов направлено на Endpoint поиска, который обращается к Database и не кэшируется.

CDN продолжает обслуживать изображения и статические страницы, но Search API начинает создавать высокую нагрузку на Backend.

WAF включает более строгий Rate Limiting для подозрительных клиентов и блокирует часть Bot Traffic. Для Search Endpoint вводится временное ограничение частоты запросов.

Приложение переводится в Degraded Mode: персональные рекомендации отключаются, а каталог частично обслуживается из Cache.

Origin Server принимает Connections только от CDN, поэтому злоумышленник не может легко обойти Edge Protection.

Monitoring показывает, что Database CPU возвращается с 100% до 60%, а Error Rate снижается.

После инцидента команда увеличивает Cache Coverage, добавляет Query Complexity Limits и обновляет Runbook.

Этот пример показывает, что защита от DDoS — это комбинация Network Protection, WAF, архитектуры приложения и Operational Readiness.

DDoS для бизнеса

Для бизнеса DDoS представляет риск прежде всего для доступности цифровых каналов: сайта, личного кабинета, API и облачных сервисов.

Чем больше компания зависит от онлайн-продаж и удаленного доступа, тем выше потенциальный ущерб от даже короткого простоя.

Эффективная защита строится многоуровнево: ISP или Anti-DDoS фильтрует крупный сетевой Traffic, CDN распределяет нагрузку, WAF защищает HTTP, а приложение ограничивает ресурсоемкие операции.

Преимущества многоуровневой защиты

• фильтрация атаки до дата-центра;
• защита интернет-канала;
• Layer 7 Filtering;
• снижение нагрузки на Database;
• сохранение Availability;
• контроль Cloud Costs;
• быстрое реагирование на инцидент.

Можно ли полностью исключить DDoS

Нельзя гарантировать, что система никогда не столкнется с атакой или деградацией.

Цель архитектуры — сделать атаку экономически и технически сложнее, уменьшить ее влияние и быстрее восстановить нормальную работу.

Связанные термины

Краткий итог

DDoS — распределенная атака на доступность сайта, сервера или сетевой инфраструктуры. Ее задача — создать настолько большой поток Traffic, Connections или Application Requests, чтобы легитимные пользователи не могли нормально пользоваться сервисом.

Атака может перегружать Bandwidth, сетевой стек, Firewall, Web Server, API или Database. Поэтому одной универсальной защиты не существует.

Эффективная Anti-DDoS Architecture сочетает фильтрацию на стороне провайдера, CDN, WAF, Rate Limiting, защиту Origin, кэширование, Resource Limits и Monitoring. Для критичных систем также необходим заранее подготовленный Incident Runbook и понимание того, какие бизнес-функции нужно сохранить в первую очередь.