DDoS-атаки: как они устроены и почему выводят сервисы из строя

Когда сайт или онлайн-сервис становится недоступен, бизнес теряет не только посетителей. Останавливаются заявки и продажи, снижается конверсия, нарушается работа личных кабинетов и API, растёт нагрузка на технические команды. Для сервисов, которые напрямую зависят от доступности в интернете, несколько часов простоя могут обернуться существенными операционными и финансовыми потерями.

Одна из причин таких простоев — DDoS-атаки. Их задача — создать такой объём трафика или запросов, при котором сетевой канал, инфраструктура или отдельные ресурсы приложения перестают справляться с нагрузкой.

При этом DDoS — не один конкретный сценарий. Атака может быть направлена на сетевой или транспортный уровень, на само приложение или сразу на несколько компонентов инфраструктуры. Поэтому и защита должна быть многоуровневой.

В этой статье разберем механизм работы таких атак, о способах защиты вы можете узнать во второй части.

Аббревиатура DDoS расшифровывается как Distributed Denial of Service — распределённая атака типа «отказ в обслуживании». Суть её не обязательно в том, чтобы вывести сервер из строя физически. Задача атакующего — создать условия, при которых легитимные пользователи не смогут нормально получить доступ к сервису.

Для этого можно перегрузить разные ресурсы:

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

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

Условно DDoS-атаки можно разделить по уровню воздействия.

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

Один из известных примеров — SYN flood. Атакующий отправляет большое количество запросов на установку TCP-соединения, создавая нагрузку на сетевые ресурсы.

Другой вариант — UDP flood, при котором генерируется большой объём UDP-трафика. В зависимости от сценария он может перегружать канал, сетевое оборудование или другие ресурсы инфраструктуры.

Отдельный класс составляют reflection/amplification-атаки, где атакующий использует сторонние серверы или сервисы для формирования большого объёма трафика в сторону жертвы. Агентство по кибербезопасности и защите инфраструктуры (Cybersecurity and Infrastructure Security Agency, CISA) отдельно рассматривает такие сценарии и рекомендует, в частности, координировать действия с upstream-провайдерами и заранее иметь процедуры реагирования.

Главная особенность L3/L4-атак заключается в том, что вредоносный трафик может создать проблему раньше, чем вообще достигнет веб-приложения.

Если интернет-канал организации рассчитан на 10 Гбит/с, а в его сторону направляется существенно больший объём трафика, WAF на сервере не сможет решить проблему: канал будет перегружен до того, как запросы попадут на уровень приложения.

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

Например, атакующий может отправлять большое количество HTTP-запросов к ресурсу, который требует значительных вычислений или обращений к базе данных. Даже относительно небольшой объём такого трафика способен создать серьёзную нагрузку на приложение. Так работает HTTP flood.

Другой пример — Slowloris. В этом случае атакующий пытается удерживать большое количество HTTP-соединений открытыми, отправляя данные медленно и постепенно. В результате исчерпываются доступные соединения или связанные с ними ресурсы веб-сервера.

Для L7-атак особенно важен контекст запроса: IP-адрес сам по себе далеко не всегда позволяет отличить атаку от обычного трафика. Поэтому здесь применяются WAF, rate limiting, механизмы обнаружения автоматизированного поведения и другие средства анализа HTTP-трафика.

Отдельного внимания заслуживают многовекторные (multi-vector) DDoS-атаки. В этом случае злоумышленники используют сразу несколько способов создания нагрузки — одновременно или последовательно. Например, атака может сочетать объёмный UDP flood на L3/L4 с HTTP flood на L7. Такой сценарий усложняет обнаружение и требует от защитного контура одновременно противостоять разным типам трафика.

Представим атаку на веб-сервис. Сначала на его сетевую инфраструктуру направляется большой объём UDP-трафика. Канал и сетевые устройства получают повышенную нагрузку, а специалисты начинают разбираться с источником и характером атаки.

Одновременно или вслед за этим атакующий запускает HTTP flood. Запросы уже выглядят как обращения к самому приложению: например, большое количество запросов к поиску, авторизации или другому ресурсоёмкому API. Даже после фильтрации основной части сетевого трафика приложение и база данных могут продолжать испытывать нагрузку.

Получается, что устранение одного вектора не обязательно прекращает атаку. Защитный контур должен уметь обнаруживать и фильтровать разные типы трафика на соответствующих уровнях. Например, крупный сетевой трафик фильтруется на внешнем или распределённом защитном контуре, HTTP/HTTPS-запросы анализируются WAF и механизмами L7-защиты, а rate limiting ограничивает интенсивность обращений к наиболее критичным ресурсам. Здесь защищать нужно не отдельный сервер или приложение, а весь путь трафика до него.

Предположим, система мониторинга сообщила о резком росте трафика. Команда начинает разбираться:

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

Пока специалисты отвечают на эти вопросы, атака продолжается.

При этом фильтрация на самой атакуемой инфраструктуре может оказаться бесполезной, если узкое место находится раньше — например, на интернет-канале. Поэтому задача Anti-DDoS не только в том, чтобы обнаружить вредоносные запросы, но и в том, чтобы сделать это на подходящем уровне и достаточно близко к источнику трафика.

CISA рекомендует заранее определить процедуры реагирования, ответственных сотрудников и каналы коммуникации с провайдерами. В руководстве также отдельно отмечаются мониторинг, анализ трафика и использование специализированных сервисов защиты от DDoS (DDoS mitigation services) для крупных атак.

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

В следующей части разберём, как выстроить такую защиту: где должен работать Anti-DDoS, какую роль играют WAF и другие механизмы L7-защиты и почему защитный контур важно настраивать и тестировать ещё до начала атаки.