Блог ДоверьсяСервису
DDoS-атака: как распознать и защитить сервис
DDoS-атака — распределенная попытка нарушить доступность сайта, приложения, сети или инфраструктурного сервиса. Множество источников одновременно создают трафик либо запросы, которые занимают пропускную способность, таблицы соединений, процессор, память или ограниченный ресурс приложения. Защита начинается не с одной кнопки, а с понимания узкого места и подготовки действий до инцидента.
DDoS-атака — распределенная попытка нарушить доступность сайта, приложения, сети или инфраструктурного сервиса. Множество источников одновременно создают трафик либо запросы, которые занимают пропускную способность, таблицы соединений, процессор, память или ограниченный ресурс приложения. Защита начинается не с одной кнопки, а с понимания узкого места и подготовки действий до инцидента.
Практический принцип: фильтр должен находиться перед ресурсом, который может быть исчерпан. Если входящий канал уже заполнен, правило на сервере не освободит канал — трафик нужно отбрасывать у оператора, в scrubbing-инфраструктуре или на распределенном edge.
Что означает DDoS
Аббревиатура расшифровывается как Distributed Denial of Service — распределенный отказ в обслуживании. Целью может быть endpoint приложения, публичный IP, сетевой канал, DNS, балансировщик, firewall, база данных или внешняя зависимость.
RFC 4732 определяет DoS как попытку помешать системе выполнять полезную работу. Распределенный вариант использует множество источников, поэтому блокировка одного адреса редко решает проблему. Атака может нарушить доступность без проникновения в систему, хотя инциденты иногда совмещают несколько техник.
Чем DoS отличается от DDoS
| Признак | DoS | DDoS |
|---|---|---|
| Источники | Один или небольшое число | Много распределенных узлов |
| Фильтрация по IP | Иногда помогает | Часто недостаточна |
| Масштаб | Ограничен ресурсом источника | Объединяет канал и ресурсы участников |
| Атрибуция | Источник заметнее | Возможны botnet, proxy и spoofing |
| Ответ | Локальные controls могут справиться | Часто нужен upstream и распределенная очистка |
Откуда берется трафик
Источниками могут быть скомпрометированные компьютеры, серверы, маршрутизаторы и устройства интернета вещей, объединенные в botnet. В reflection-сценарии злоумышленник подменяет адрес жертвы и заставляет открытые UDP-сервисы отправлять ответы не инициировавшей их стороне.
Если ответ заметно больше запроса, возникает amplification. Эксплуатация чужих открытых сервисов не означает, что они входят в один botnet. Source address validation и ingress filtering по BCP 38/84 уменьшают возможность выпускать spoofed traffic, но требуют внедрения сетевыми операторами.
Три основных класса атак
| Класс | Что исчерпывается | Полезные метрики |
|---|---|---|
| Volumetric | Пропускная способность канала | bps, входящий/исходящий трафик, drops |
| Protocol/state exhaustion | pps, connection table, load balancer или network stack | pps, new connections, SYN backlog, state usage |
| Application layer | Workers, CPU, database, cache или внешняя квота | rps, latency, errors, CPU, query time |
Границы не абсолютны: multi-vector incident сочетает несколько классов и меняет профиль во времени. Поэтому защита только по gigabits или только по HTTP-коду оставляет слепые зоны.
Volumetric-атаки
Объемный поток пытается занять доступную полосу до сервиса. Даже если сервер способен отбросить каждый пакет, законный трафик не пройдет через переполненный uplink. Критичны фактическая емкость последней мили, peering, transit и способность upstream фильтровать раньше.
Признаки: резкий рост bps, drops на интерфейсе, высокая загрузка канала при умеренных CPU и rps приложения. Локальная телеметрия может стать неполной, если packets теряются до вашей точки наблюдения.
Protocol и state exhaustion
Здесь важен не общий объем, а число packets, новых соединений или состояний. Firewall, NAT, load balancer и TCP stack имеют конечные таблицы и очереди. Небольшие пакеты способны дать высокий pps при умеренном bps.
Проверяйте connection table usage, SYN states, session allocation failures и нагрузку control plane. Увеличение лимита без анализа может лишь перенести отказ на память или приложение.
Атаки уровня приложения
HTTP-запрос может выглядеть корректно, но запускать дорогой поиск, отчет, авторизацию, генерацию файла или запрос к внешнему API. Небольшой rps тогда исчерпывает workers, database connections или квоту быстрее сетевого flood.
Нужны метрики по route, method, status, cache hit, latency, user/session и стоимости операции. Один общий лимит на весь сайт рискует заблокировать легитимных пользователей, пока дорогой endpoint останется перегруженным.
Как отличить атаку от всплеска спроса
Flash crowd и DDoS могут одинаково повышать нагрузку. RFC 4732 отмечает, что тонкую атаку трудно отделить от неожиданного спроса. Решение нельзя строить на одном признаке.
Сопоставляйте бизнес-события, conversion, последовательность действий, долю cache hits, ошибки, распределение endpoints, автономных систем и сессий. Настоящие пользователи тоже бывают за NAT, а атакующий трафик способен имитировать браузер.
Какие метрики собирать
- bps: занятие полосы;
- pps: нагрузка на packet processing;
- rps: частота запросов к приложению;
- cps: новые соединения в секунду;
- concurrency: одновременно открытые соединения;
- latency: p50, p95 и p99 по ключевым routes;
- errors: 4xx, 5xx, timeout и reset;
- saturation: CPU, memory, queues, workers, DB pool;
- quality: успешные действия и доступность из probes.
Baseline строят по времени суток и дням недели. Порог «выше среднего» без сезонности создает ложные тревоги, а абсолютный порог может пропустить медленное истощение application resource.
Калькулятор запаса канала
Проверка локального предела
Пусть uplink равен 1 Гбит/с, обычный пик — 250 Мбит/с, а операционный предел принят на уровне 70% канала, то есть 700 Мбит/с. Запас до этого предела: 700 − 250 = 450 Мбит/с.
Если наблюдается 1,4 Гбит/с входящего трафика, локальное устройство физически не примет весь поток через 1-гигабитный канал. Нужна фильтрация до bottleneck. Такой расчет не прогнозирует атаку, но сразу показывает, где autoscaling серверов и локальные ACL бессильны.
Матрица быстрой классификации
Канал, packets или приложение
| Наблюдение | Вероятное узкое место | Первая эскалация |
|---|---|---|
| bps у предела, drops до edge | Uplink или transit | Оператор и scrubbing |
| Высокий pps/cps, state table заполнена | Edge, firewall, load balancer | Network/SOC и upstream |
| bps умеренный, растут latency и DB pool | Endpoint или backend | Application/SRE и WAF |
| Только один регион не видит сервис | Route, provider или региональный edge | Network и поставщик |
Матрица — triage, а не доказательство. Один incident может одновременно заполнить канал и перегрузить login endpoint. Сохраняйте общий timeline и назначайте одного incident commander.
Почему одного firewall недостаточно
Firewall полезен для stateless/stateful filtering, но сам имеет лимиты packets, states и throughput. Если он расположен после насыщенного канала, трафик уже нанес ущерб. Слишком широкое журналирование каждого packet также способно истощить storage или control plane.
Правила должны быть узкими и проверяемыми. Механическое блокирование всех адресов с большим числом запросов может отключить NAT, корпоративный proxy или поискового робота и увеличить ущерб от инцидента.
Распределенный edge и scrubbing
Scrubbing center принимает направленный к сервису поток, отделяет нежелательные packets и передает очищенный трафик origin. Always-on режим сокращает время активации; on-demand требует надежного detection и переключения маршрута.
Anycast и распределенные точки присутствия помогают принять нагрузку ближе к источникам и убрать единственную точку входа. Но архитектура должна закрывать прямой доступ к origin, иначе атакующий обойдет защитный edge по известному IP.
CDN, cache, WAF и rate limiting
CDN и cache уменьшают число запросов к origin для кешируемого контента. WAF анализирует HTTP и применяет правила к application layer. Rate limiting ограничивает частоту по выбранному ключу, route и окну времени.
Эти controls дополняют друг друга. Cache не спасает некешируемую авторизацию, WAF не освобождает уже заполненный uplink, а limit только по IP плохо работает при NAT и распределенных источниках. Исключения, challenge и блокировки тестируют на реальном user flow.
Выбор сервиса защиты
Сначала опишите защищаемые IP и домены, обычные bps/pps/rps, максимальный приемлемый downtime, протоколы, TLS termination, origin, DNS, BGP и требования к данным. Затем сравнивайте detection time, mitigation time, capacity, сеть точек, логи, поддержку и процедуру emergency activation.
Категория сервисов защиты от DDoS-атак помогает увидеть варианты рынка. Карточки Qrator и Cloudflare служат точками знакомства с отдельными платформами; возможности, тарифы, географию и ограничения подтверждайте у поставщиков.
Что подготовить до инцидента
- актуальную схему трафика от DNS и BGP до origin;
- baseline bps, pps, cps, rps, latency и errors;
- контакты ISP, hosting, CDN, registrar и security provider;
- договоренный способ экстренной активации mitigation;
- доступ к панели через отдельный management path;
- готовые безопасные WAF и rate-limit profiles;
- список критичных endpoints и бизнес-приоритетов;
- status page и шаблоны коммуникации;
- время хранения flow logs, access logs и packet samples;
- план rollback для временных ограничений.
Runbook первых 30 минут
- Назначьте incident commander и единый канал связи.
- Подтвердите impact независимыми probes и user metrics.
- Зафиксируйте время, bps, pps, rps, routes, errors и saturation.
- Определите первое исчерпанное звено по матрице.
- Уведомите upstream или mitigation provider установленным способом.
- Защитите management, DNS, status page и origin от обхода.
- Включайте заранее проверенные controls поэтапно.
- После каждого действия сравнивайте availability и legitimate traffic.
- Сообщайте пользователям подтвержденный статус без предположений.
Не меняйте DNS, routing, firewall и приложение одновременно без timeline: станет невозможно понять, что помогло и что создало новый отказ. Каждое временное правило получает owner, время установки и условие отмены.
Работа с оператором и провайдером
Передайте защищаемый prefix/IP, время начала, обычный и наблюдаемый профиль, направления, protocols, sample flow и бизнес-impact. Уточните, видит ли оператор saturation до вашего интерфейса и какой механизм mitigation доступен.
Контакт и аутентификацию обращения проверяют заранее. Во время атаки поиск номера договора, права на изменение BGP или доступа к панели расходует критичное время.
Защита origin
Если сайт работает через proxy или CDN, origin должен принимать production traffic только от ожидаемых сетей или через аутентифицированный канал, насколько позволяет архитектура. Старые DNS-записи, сертификатные логи, почтовые headers и тестовые поддомены иногда раскрывают адрес.
Management endpoints отделяют от пользовательского пути и защищают сильной аутентификацией. При блокировке origin оставляют резервный управляемый доступ, чтобы собственное правило не лишило команду контроля.
Восстановление после атаки
Снимайте ограничения постепенно, наблюдая bps/pps/rps, ошибки и успешные действия. Не отключайте mitigation сразу после падения графика: профиль может вернуться или сменить vector.
В post-incident review собирают timeline, первое узкое место, эффективность действий, false positives, время обнаружения и восстановления. Изменения превращают в задачи с владельцами и сроками, а runbook проверяют на учениях.
Типичные ошибки защиты
- пытаться остановить переполненный uplink локальным firewall;
- смотреть только bps и пропускать pps или application exhaustion;
- принимать любой рост посещаемости за атаку;
- блокировать большие NAT и proxy по одному IP;
- оставлять origin доступным в обход edge;
- включать непроверенный global rate limit;
- полагаться только на autoscaling;
- не защищать DNS и management plane;
- логировать каждый packet на перегруженном устройстве;
- менять несколько слоев без timeline;
- не согласовать экстренный контакт с upstream;
- не удалять временные блокировки после инцидента.
Чек-лист готовности
- известны capacity и bottleneck каждого внешнего канала;
- baseline охватывает bps, pps, cps, rps и application health;
- alert проверен на тестовом событии;
- защищены network и application layers;
- origin нельзя обойти по публичному адресу;
- upstream знает защищаемые prefixes и contacts;
- mitigation activation регулярно тестируется;
- rate limits учитывают NAT и критичные user flows;
- management path не зависит от атакуемого сервиса;
- логи и flow data имеют синхронизированное время;
- есть incident commander, runbook и status template;
- временные controls имеют owner и rollback.
Частые вопросы
Защитит ли увеличение мощности сервера?
Только если узкое место находится в compute и запас превышает нагрузку. Autoscaling не расширит насыщенный uplink и может увеличить расходы при дорогих application requests.
Можно ли заблокировать DDoS по странам?
Географический фильтр иногда сокращает нежелательный поток, но источники и законные пользователи распределены. Такое правило применяют только при ясной бизнес-географии и с контролем false positives.
Поможет ли смена IP?
Иногда она временно разрывает поток, но новый адрес может раскрыться, а миграция нарушить DNS и зависимости. Без закрытия origin и изменения архитектуры это не надежная стратегия.
Чем DDoS-защита отличается от WAF?
DDoS-защита охватывает доступность сети и разных протоколов, а WAF анализирует HTTP application layer. Набор функций конкретного поставщика может объединять оба класса, но их пределы нужно проверять отдельно.
Нужно ли сообщать пользователям об атаке?
Коммуникация зависит от impact и политики организации. Полезно сообщать подтвержденную доступность, затронутые функции и время следующего обновления, не публикуя детали, которые мешают mitigation.
Итог
DDoS нельзя свести к одному размеру трафика или одному фильтру. Определите, что исчерпывается первым: канал, packet processing, state или ресурс приложения. Собирайте сопоставимые метрики, фильтруйте до bottleneck, закрывайте обход origin и заранее согласуйте действия с upstream. Подготовленный runbook и проверенные ограничения восстанавливают доступность надежнее, чем импровизация во время атаки.