VPS/Cloud Botnet DDoS: как работают атаки с облачных серверов и как от них защититься

VPS/Cloud Botnet DDoS — это распределённая атака отказа в обслуживании, при которой источниками вредоносного трафика становятся виртуальные серверы, облачные инстансы, контейнеры, скомпрометированные аккаунты и другие ресурсы дата-центров.

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

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

Защита от VPS/Cloud Botnet DDoS должна работать сразу на нескольких уровнях. Магистральная или облачная фильтрация принимает объёмные атаки, сетевые механизмы ограничивают соединения, а reverse proxy, WAF и поведенческий анализ отделяют автоматизированные HTTP-запросы от действий реальных посетителей.

Что такое VPS/Cloud Botnet DDoS

VPS/Cloud Botnet DDoS — это атака, источниками которой выступают ресурсы хостинговых компаний и облачных платформ:

• виртуальные частные серверы — VPS и VDS;
• облачные виртуальные машины;
• выделенные серверы;
• контейнеры и узлы Kubernetes;
• скомпрометированные веб-серверы;
• арендованные прокси-серверы;
• взломанные панели управления хостингом;
• облачные ресурсы, созданные через похищенный аккаунт;
• инфраструктура, оплаченная с использованием украденных платёжных данных;
• неправильно защищённые среды автоматического развёртывания.

Название «ботнет» не всегда означает наличие классического вредоносного агента на каждом сервере. Управление может осуществляться через установленное вредоносное ПО, легитимные инструменты удалённого администрирования, API облачного провайдера, панель оркестрации или скомпрометированную систему CI/CD.

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

Как формируется облачный ботнет

Существует несколько принципиально разных способов формирования VPS/Cloud Botnet. Для защищающейся стороны они могут выглядеть одинаково — как интенсивный трафик из дата-центров, — но причины и продолжительность атаки различаются.

Компрометация существующих VPS

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

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

Компрометация облачного аккаунта

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

Особенно опасна ситуация, когда похищенные полномочия позволяют:

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

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

Компрометация контейнеров и Kubernetes

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

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

Злоупотребление автоматическим развёртыванием

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

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

Злоупотребление serverless-платформами

Функции serverless иногда используют для генерации HTTP-запросов или других действий прикладного уровня. Однако их не следует считать универсальной заменой обычного VPS-ботнета.

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

Почему облачные ботнеты опасны

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

Обычное IoT-устройство имеет слабый процессор и ограниченный канал связи. VPS может поддерживать тысячи параллельных соединений, выполнять TLS-рукопожатия и отправлять большое количество корректно сформированных HTTP-запросов.

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

Стабильная связь с низкой задержкой

Дата-центры подключены к крупным операторам и точкам обмена трафиком. Их соединения обычно стабильнее домашних и мобильных сетей. Узлы способны долго поддерживать TCP-, TLS-, HTTP/2- и WebSocket-сессии.

Наличие IPv4 и IPv6

Облачная инфраструктура может генерировать трафик по обоим протоколам. Если защита настроена только для IPv4, злоумышленник может направить запросы на доступный IPv6-адрес origin-сервера или балансировщика.

Распределение по регионам и провайдерам

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

Возможность имитировать обычный веб-трафик

Серверные узлы способны отправлять корректные HTTPS-запросы, использовать HTTP/2, сохранять cookie, переходить между страницами и менять заголовки. Такая атака может внешне напоминать работу поискового робота, сервиса мониторинга или интеграции.

Основные векторы VPS/Cloud Botnet DDoS

Вектор	Цель атаки	Основной ограничиваемый ресурс
UDP Flood	Сетевой интерфейс, канал, firewall	Пропускная способность и PPS
TCP Flood	Сетевой стек и балансировщик	Таблицы соединений и PPS
SYN Flood	Механизм установления TCP-соединений	Очередь полуоткрытых соединений
TLS Flood	TLS-терминатор, reverse proxy	CPU и лимиты соединений
HTTP Flood	Веб-сервер и приложение	Воркеры, CPU, память
API Flood	API и внутренние сервисы	Вычисления, квоты, база данных
HTTP/2 Flood	HTTP/2-сервер или прокси	Потоки, соединения, CPU
WebSocket Flood	Сервис постоянных соединений	Файловые дескрипторы и память
Carpet Bombing	Множество адресов одной сети	Канал и инфраструктура подсети
Multi-vector DDoS	Несколько уровней инфраструктуры	Канал, соединения и приложение

UDP- и TCP-флуды

При наличии необходимых сетевых возможностей облачные серверы могут создавать большой поток UDP- или TCP-пакетов. Целью становится внешний канал, маршрутизатор, firewall, балансировщик или сетевой стек сервера.

Однако не следует считать, что любой облачный VPS позволяет свободно подменять исходный IP-адрес. Крупные платформы применяют проверку источника трафика и другие антиспуфинговые механизмы. Например, сетевые интерфейсы EC2 по умолчанию используют проверку source/destination, а шлюзы AWS отклоняют трафик с подменёнными адресами.

Поэтому облачные узлы особенно удобны для direct-path-атак, в которых сервер устанавливает настоящие соединения и получает ответный трафик. Для отражённых UDP-атак с подменой адреса чаще используется инфраструктура, где отсутствует полноценная фильтрация исходящих пакетов.

TLS Flood

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

Если TLS завершается непосредственно на origin-сервере, атака может перегрузить процессор раньше, чем закончится пропускная способность канала.

HTTP Flood

HTTP Flood является одним из наиболее характерных векторов облачного ботнета. Серверные узлы могут:

• создавать полноценные HTTPS-соединения;
• поддерживать keep-alive;
• использовать HTTP/2;
• сохранять cookie;
• отправлять GET- и POST-запросы;
• обращаться к разным URL;
• запрашивать динамические страницы;
• воспроизводить некоторые признаки браузерной сессии.

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

Атаки на дорогие функции

Облачный ботнет может направлять запросы на операции, которые требуют больше ресурсов, чем обычная отдача страницы:

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

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

HTTP/2 и мультиплексирование

HTTP/2 позволяет передавать несколько потоков в одном соединении. Для легитимных клиентов это повышает производительность, но при атаке может усложнить контроль нагрузки: один источник создаёт ограниченное количество TCP-соединений, внутри которых одновременно выполняется множество запросов.

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

WebSocket Flood

При атаке на WebSocket злоумышленник открывает большое количество продолжительных соединений. Даже если каждое соединение передаёт мало данных, сервер расходует:

• файловые дескрипторы;
• оперативную память;
• записи таблицы соединений;
• ресурсы балансировщика;
• воркеры или event-loop;
• ресурсы брокера сообщений.

Многовекторная атака

VPS/Cloud Botnet может сочетать несколько векторов. Например:

1. UDP-поток создаёт нагрузку на внешний канал.
2. TCP-соединения заполняют таблицы состояния firewall.
3. TLS-сессии загружают процессор reverse proxy.
4. HTTP-запросы перегружают приложение и базу данных.

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

Чем VPS/Cloud Botnet отличается от других ботнетов

Характеристика	VPS/Cloud	IoT	Mobile	Browser-based
Мощность одного узла	Высокая	Низкая или средняя	Средняя	Зависит от устройства
Тип сети	Дата-центр или хостинг	Домашняя сеть	Мобильный оператор	Любая сеть пользователя
Стабильность соединения	Высокая	Средняя	Переменная	Зависит от активности браузера
Типичные атаки	TCP, TLS, HTTP, API	UDP, TCP, массовый флуд	HTTP и API	HTTP-запросы из браузера
Количество необходимых узлов	Относительно небольшое	Обычно большое	Среднее или большое	Большое
Атрибуция сети	Часто виден ASN хостинга	Residential ASN	Mobile ASN и CGNAT	Реальный адрес посетителя
Продолжительность жизни узла	До блокировки провайдером	Может быть длительной	Зависит от приложения или устройства	Ограничена браузерной сессией

Как распознать атаку с VPS и облачных серверов

Ни один признак не доказывает атаку сам по себе. Решение должно приниматься на основании комбинации сетевых, HTTP- и поведенческих сигналов.

Рост трафика из хостинговых ASN

Значительная часть запросов начинает поступать из автономных систем облачных платформ, VPS-провайдеров, дата-центров и прокси-сетей.

Но блокировать весь хостинговый трафик опасно. Из тех же сетей могут работать:

• поисковые роботы;
• сервисы мониторинга;
• корпоративные VPN;
• партнёрские интеграции;
• платёжные и логистические системы;
• вебхуки;
• средства проверки доступности;
• легитимные API-клиенты.

Признак дата-центра следует использовать как один из факторов риска, а не как безусловное основание для блокировки.

Необычно высокая активность одного адреса

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

При этом фиксированный лимит на IP не всегда достаточен. Атакующий может распределить нагрузку между большим количеством адресов.

Синхронное начало запросов

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

Повторяющиеся технические отпечатки

Даже при изменении User-Agent у запросов могут совпадать:

• TLS-параметры;
• порядок HTTP-заголовков;
• набор поддерживаемых кодировок;
• характер работы с cookie;
• частота повторного использования соединений;
• ошибки протокола;
• HTTP/2-настройки;
• переходы между страницами.

Отсутствие нормального пользовательского поведения

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

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

Дисбаланс между запросами и полезными действиями

Показателями атаки могут быть:

• рост запросов без роста авторизаций или заказов;
• увеличение ошибок 429, 499, 502, 503 и 504;
• резкий рост незавершённых сессий;
• увеличение времени ответа базы данных;
• исчерпание пула соединений;
• рост TLS-рукопожатий без последующих HTTP-запросов;
• аномальное количество обращений к одному API-методу.

Как отличить облачный DDoS от легитимного трафика

Признак	Легитимный всплеск	VPS/Cloud Botnet DDoS
Источники	Разные типы сетей	Высокая доля дата-центров и VPS
Поведение	Просмотры, переходы, конверсии	Повторение ограниченного сценария
Целевые URL	Распределены по сайту	Сосредоточены на дорогих endpoint
Cookie и сессии	Сохраняются естественным образом	Могут отсутствовать или повторяться шаблонно
Интенсивность одного IP	Обычно ограниченная	Часто очень высокая
Бизнес-результат	Растут регистрации и продажи	Растёт нагрузка без полезных действий
Момент начала	Связан с рекламой или событием	Может быть резким и синхронным

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

Защита от VPS/Cloud Botnet DDoS

Используйте многоуровневую архитектуру

Один firewall или один rate limit не покрывают все варианты атаки. Защита должна включать:

1. фильтрацию объёмного трафика до входа в инфраструктуру;
2. контроль TCP- и TLS-соединений;
3. reverse proxy перед origin-сервером;
4. WAF и поведенческий анализ;
5. лимиты для отдельных endpoint;
6. кеширование;
7. защиту базы данных и внутренних сервисов;
8. мониторинг сетевых и прикладных показателей.

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

Закройте прямой доступ к origin-серверу

Если сайт защищён reverse proxy, origin не должен оставаться доступным для произвольных подключений из интернета. Иначе атакующий сможет определить настоящий IP-адрес и обойти фильтрацию.

На сетевом уровне следует разрешить HTTP/HTTPS-доступ только с адресов защитной платформы или балансировщика. Правило должно применяться одновременно к IPv4 и IPv6.

Также необходимо проверить, не раскрывается ли origin через:

• старые DNS-записи;
• почтовые заголовки;
• поддомены;
• историю DNS;
• доступные панели управления;
• прямые ссылки на файлы;
• сертификаты и связанные имена;
• тестовые окружения.

Не блокируйте все облачные сети без анализа

Жёсткая блокировка AWS, Azure, Google Cloud и крупных хостингов может нарушить работу интеграций и легитимных клиентов.

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

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

Применяйте многоуровневый rate limiting

Лимиты следует считать не только по IP-адресу. Полезны ограничения:

• на один IP;
• на IPv4- или IPv6-подсеть;
• на ASN;
• на технический отпечаток клиента;
• на сессию или токен;
• на учётную запись;
• на конкретный endpoint;
• на HTTP-метод;
• на число одновременных соединений.

Для разных операций нужны разные пороги. Статическую страницу можно запрашивать чаще, чем восстановление пароля, экспорт отчёта или сложный поиск.

Ограничивайте стоимость запроса

Кроме количества запросов, необходимо контролировать вычислительную стоимость операций:

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

Разделяйте публичные и доверенные API

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

Подготовьте сетевую DDoS-защиту

Если атака заполняет внешний канал, локальный firewall не сможет исправить ситуацию: трафик уже достиг сети. Требуется фильтрация у провайдера, на облачной платформе или в центре очистки.

Современные облачные платформы предоставляют отдельные механизмы сетевой и прикладной DDoS-защиты. Например, Google Cloud Armor поддерживает защиту веб-приложений, а расширенная сетевая защита может применяться к внешним балансировщикам, protocol forwarding и виртуальным машинам с публичными адресами.

Как TrafficVeil помогает против облачного ботнета

TrafficVeil работает как HTTP/HTTPS reverse proxy между посетителем и origin-сервером. Для атак прикладного уровня он может использовать:

• WAF-фильтрацию;
• техническое и поведенческое обнаружение ботов;
• защиту от L7 DDoS;
• rate limiting;
• анализ HTTP-запросов;
• DNS- и SSL-инфраструктуру;
• ограничения для отдельных маршрутов и сценариев.

Для максимального эффекта origin должен принимать HTTP- и HTTPS-соединения только от TrafficVeil. Ограничение необходимо настроить для IPv4 и IPv6. В противном случае атакующий может отправить трафик напрямую на сервер в обход reverse proxy.

При этом HTTP-защита не заменяет магистральную очистку объёмного L3/L4-трафика. Если UDP-, TCP-, GRE- или другой сетевой флуд направлен на открытый IP-адрес и заполняет канал провайдера, атаку необходимо блокировать до её попадания в инфраструктуру.

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

1. Определить перегруженный ресурс

Необходимо понять, где возникает отказ:

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

2. Сравнить текущие показатели с базовой линией

Проверяются запросы в секунду, новые соединения, TLS-рукопожатия, трафик, PPS, ошибки, задержка, нагрузка CPU, память, файловые дескрипторы и соединения с базой данных.

3. Выделить атакуемые endpoint

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

4. Активировать режим усиленной фильтрации

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

5. Подключить провайдера

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

• время начала;
• целевые IP-адреса и порты;
• протокол;
• максимальный объём трафика;
• максимальный PPS;
• основные автономные системы источников;
• фрагмент сетевой телеметрии;
• изменения вектора атаки.

6. Сохранять данные для анализа

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

Как не допустить превращения своего облака в ботнет

Защитите учётные записи

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

CISA отдельно указывает на ценность фишинг-устойчивой MFA, включая аппаратные механизмы и FIDO, для защиты критичных учётных записей.

Ограничьте возможности создания ресурсов

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

Контролируйте исходящий трафик

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

Рекомендуется:

• разрешать только необходимые направления и порты;
• использовать централизованный egress gateway;
• вести журналы исходящих соединений;
• контролировать DNS-запросы;
• ограничивать скорость там, где это допустимо;
• выявлять необычное количество внешних получателей;
• обнаруживать резкий рост исходящего PPS и трафика.

Контролируйте контейнеры и образы

• используйте доверенные базовые образы;
• сканируйте зависимости и контейнеры;
• не запускайте контейнеры с избыточными привилегиями;
• ограничивайте сетевой доступ workloads;
• обновляйте Kubernetes и управляющие компоненты;
• защищайте реестры образов;
• проверяйте подписи и происхождение артефактов.

Настройте обнаружение аномалий

Признаками компрометации облака могут быть:

• создание большого количества инстансов;
• активация ранее неиспользуемого региона;
• резкий рост исходящего трафика;
• необычные изменения IAM;
• создание новых ключей и сервисных аккаунтов;
• отключение журналирования;
• изменение сетевых ACL и security groups;
• рост расходов без бизнес-причины;
• жалобы на вредоносный трафик от провайдера.

Действия при компрометации облачного аккаунта

1. Ограничьте доступ злоумышленника. Отзовите активные токены, ключи и подозрительные сессии.
2. Сохраните доказательства. Экспортируйте аудит API, события IAM, сетевые журналы и список созданных ресурсов.
3. Изолируйте подозрительные workload. Прекратите вредоносный исходящий трафик, сохранив данные для расследования.
4. Проверьте механизмы закрепления. Найдите новые роли, пользователей, ключи, функции автоматизации и изменённые политики.
5. Смените секреты. Меняются не только пароли, но и API-ключи, сертификаты, токены и секреты приложений.
6. Проверьте все регионы. Ресурсы могли быть созданы вне основного региона.
7. Свяжитесь с облачным провайдером. Это поможет остановить злоупотребление, сохранить данные и разобраться с расходами.
8. Устраните первоначальную причину. Иначе после восстановления злоумышленник сможет вернуться.

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

Блокировка только отдельных IP-адресов

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

Блокировка всех дата-центров

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

Один общий лимит для всего сайта

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

Открытый origin

Даже качественная защита reverse proxy теряет смысл, если IP origin-сервера известен и доступен напрямую.

Защита только IPv4

IPv6-адрес может остаться открытым для обхода фильтрации. Политики доступа и мониторинг должны быть эквивалентными для обоих протоколов.

Масштабирование без фильтрации

Автомасштабирование временно повышает устойчивость, но также может увеличивать расходы. Если вредоносные запросы продолжают поступать, инфраструктура начинает автоматически масштабировать стоимость атаки.

Чек-лист защиты сайта

• Скрыт ли реальный IP origin-сервера?
• Разрешены ли подключения к origin только от reverse proxy?
• Применяется ли то же ограничение для IPv6?
• Есть ли внешняя защита от L3/L4 DDoS?
• Настроены ли лимиты TCP- и TLS-соединений?
• Есть ли отдельные лимиты для дорогих endpoint?
• Анализируются ли ASN и тип сети источника?
• Используются ли поведенческие признаки?
• Кешируются ли популярные ответы?
• Ограничена ли сложность API- и GraphQL-запросов?
• Контролируются ли WebSocket-соединения?
• Настроен ли мониторинг 429, 499, 502, 503 и 504?
• Подготовлены ли контакты провайдера и план реагирования?
• Сохраняются ли HTTP- и сетевые журналы?

Чек-лист защиты облачного аккаунта

• Включена ли фишинг-устойчивая MFA?
• Отсутствуют ли общие административные аккаунты?
• Используются ли временные роли вместо постоянных ключей?
• Настроен ли принцип минимальных полномочий?
• Отключены ли неиспользуемые регионы?
• Установлены ли квоты на создание ресурсов?
• Настроены ли бюджеты и уведомления о расходах?
• Контролируются ли изменения IAM?
• Отслеживается ли создание публичных IP-адресов?
• Включено ли централизованное журналирование?
• Защищено ли журналирование от отключения?
• Ограничен ли исходящий трафик?
• Контролируются ли контейнеры и образы?
• Есть ли процедура отзыва ключей и токенов?
• Проводятся ли регулярные проверки неиспользуемых ресурсов?

Вывод

VPS/Cloud Botnet DDoS отличается высокой мощностью каждого узла, стабильными каналами и возможностью создавать полноценные TCP-, TLS- и HTTP-сессии. Такой ботнет особенно опасен для динамических сайтов, API и функций, где один запрос запускает дорогую обработку.

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

Надёжная защита строится слоями: объёмные сетевые атаки блокируются до входа в инфраструктуру, origin закрывается от прямого доступа, а HTTP/HTTPS-трафик проходит через reverse proxy, WAF, поведенческий анализ и многоуровневые лимиты. Одновременно организация должна защищать собственные облачные аккаунты, контролировать исходящий трафик и отслеживать аномальное создание ресурсов.