DDoS-атаки и защита сайта: большой гайд для бизнеса и VPS

07.09.202620 мин чтения

Для защиты сайта от DDoS нужно остановить вредоносный трафик до того, как он исчерпает канал, соединения или ресурсы приложения. Обычно это комбинация внешней фильтрации, защищенного DNS, закрытого сервера приложения и ограничений на дорогие операции. Настройки зависят от того, что работает у компании: сайт на WordPress, интернет-магазин, API, личный кабинет или собственная сеть.

На отдельном VPS такую архитектуру тоже можно организовать. Вариант с меньшей эксплуатационной нагрузкой: поставить сайт за облачным anti-DDoS-прокси. Вариант с большим контролем: вынести Nginx на отдельный защищенный VPS и соединить его с сервером приложения по приватной сети или туннелю. В обоих случаях объемные атаки должен очищать провайдер до заполнения внешнего канала.

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

Что происходит во время DDoS-атаки

DDoS, distributed denial of service, означает распределенный отказ в обслуживании: множество источников создают нагрузку, из-за которой легитимный пользователь не может воспользоваться сервисом. Источниками могут быть зараженные устройства, серверы, прокси и сторонние сервисы, отражающие трафик.

У перегрузки несколько возможных точек:

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

Нагрузка измеряется разными величинами. Бит/с показывает объем трафика, пакеты/с - нагрузку на обработку пакетов, RPS - запросы в секунду, а число соединений и активных запросов - занятые ресурсы. Небольшой поток тяжелых запросов иногда опаснее большого объема закэшированных страниц.

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

Типы DDoS-атак и подходящая защита

Перечислить все возможные реализации атак невозможно: способы комбинируются, а в программном обеспечении появляются новые уязвимости. Для проектирования достаточно покрыть основные классы и проверить конкретные протоколы проекта. Обозначения L3/L4/L7 в коммерческих описаниях часто используют укрупненно: например, UDP относится к L4, хотя объемный UDP-флуд обычно продают как задачу сетевой L3/L4-защиты.

Класс и примеры	Какой ресурс расходуется	Где должна работать защита
Объемный UDP/ICMP flood	Полоса, пропускная способность сети по пакетам	Сеть хостера, оператора или центр очистки
Reflection/amplification: DNS, NTP, SSDP, CLDAP, memcached	Канал жертвы заполняют ответы сторонних сервисов	Upstream-фильтрация; закрытие собственных открытых UDP-сервисов
SYN flood	Очереди установления TCP-соединений	Сетевой anti-DDoS, SYN proxy/cookies с учетом топологии
ACK/RST flood, аномальные и фрагментированные пакеты	Пакетная обработка и сетевые устройства	Фильтры провайдера, маршрутизатора и firewall
Connection/state exhaustion	Таблицы NAT/firewall, память и соединения	Сетевой фильтр, прокси, лимиты и тайм-ауты
TLS handshake flood	CPU и ресурсы установки TLS	Защищенный TLS-прокси, контроль новых соединений
HTTP GET/POST flood	Воркеры, CPU, база, исходящий трафик	L7 anti-DDoS, anti-bot, кэш, лимиты маршрутов
Cache-busting и случайные URL	Промахи кэша и запросы к origin	Политика cache key, нормализация и ограничения динамики
Slow headers/body/read	Длительно занятые соединения и буферы	Тайм-ауты, буферизация и контроль ресурсов на прокси
HTTP/2 stream/reset abuse	Ресурсы обработки потоков внутри соединения	Исправленная реализация протокола и edge-фильтрация
Дорогие API, GraphQL, поиск, экспорт	CPU, память, БД и очереди	Квоты по клиенту, сложность запросов, ограничение параллелизма
WebSocket flood	Соединения, память и обработка сообщений	Лимиты сессий, частоты сообщений и аутентификация
DNS query flood, случайные поддомены	Авторитетные DNS-серверы	Распределенный защищенный DNS
Многовекторная атака	Несколько ресурсов одновременно или последовательно	Согласованная защита сети, DNS, HTTP и приложения

Что такое отражение и усиление

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

Публичный VPS также не должен становиться участником отражения. Не оставляйте открытый рекурсивный DNS, memcached или административные UDP-службы доступными всему интернету. Состав открытых портов проверяют отдельно от настроек сайта.

Чем опасны атаки на HTTP/2 и HTTP/3

В HTTP/2 одно TCP-соединение обслуживает несколько потоков запросов. Поэтому ограничение числа TCP-соединений не описывает всю прикладную нагрузку. Исторические примеры - Rapid Reset и MadeYouReset. В публикации Cloudflare о MadeYouReset речь идет об определенных непатченных реализациях HTTP/2, а не об уязвимости любого сайта с этим протоколом.

Проверяйте обновления прокси и библиотек HTTP, политику обработки потоков и наличие защиты у провайдера. Для HTTP/3 отдельно учитывайте QUIC/UDP и поддержку протокола выбранным сервисом. Отключение протокола может быть временной мерой для конкретного advisory, но общую архитектуру защиты оно не заменяет.

Атаки на бизнес-логику и стоимость

Массовые регистрации, отправка SMS, формирование PDF, обработка изображений и запросы к LLM могут исчерпать ресурсы или бюджет. Не каждый такой случай является DDoS, но защита доступности должна учитывать эти зависимости.

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

Как отличить атаку от наплыва посетителей

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

Наблюдение	Что проверить
Резко вырос трафик	Запуски рекламы, рассылки, рефералы, географию и долю успешных действий
Один маршрут стал очень популярным	Ошибку клиента, бесконечные повторы, интеграцию, кешируемость и стоимость запроса
Канал заполнен, CPU свободен	Телеметрию хостера: бит/с, пакеты/с, протоколы и потери
Растут 502/504 при небольшой полосе	Воркеры приложения, базу, блокировки и внешние зависимости
Много запросов с одного IP	Корпоративный NAT, прокси/CDN, реального клиента и корректность журналов
Запросы проходят WAF, но сайт недоступен	Дорогую легитимную бизнес-логику и прямой доступ к origin

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

Из каких слоев собрать защиту сайта

Пользователь -> защищенный DNS -> внешний anti-DDoS / CDN
             -> WAF + anti-bot + лимиты
             -> origin: Nginx / приложение
             -> кэш, БД, очереди и внешние API

Anti-DDoS L3/L4 очищает сетевой поток до вашего канала и оборудования. CDN уменьшает обращения к серверу за счет кэша и распределенной доставки. WAF проверяет HTTP-запросы на признаки эксплуатации уязвимостей. Anti-bot оценивает автоматизацию и подозрительное поведение. Rate limiter задает допустимую частоту. Эти функции могут продаваться вместе, но включаться разными настройками.

Если канал VPS условно выдерживает 1 Гбит/с, а до его входа дошло больше, локальное отбрасывание пакетов не освободит этот канал. Дополнительная память и процессор также не увеличат его емкость. Защиту нужно переносить выше по маршруту.

Есть и ограничения на других слоях: WAF не обязан блокировать дорогой, но корректный поиск; CDN не закэширует личный кабинет без специальных правил; CAPTCHA нарушит работу серверного API. Каждому сценарию нужна подходящая политика.

Как подключают anti-DDoS

Защита через DNS и reverse proxy

Домен указывает на внешнюю сеть защиты. Она принимает HTTP/HTTPS, анализирует трафик и передает запросы на origin - исходный сервер приложения. Схема подходит для большинства сайтов и HTTP API, в том числе размещенных на VPS у другого хостера.

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

Сетевая очистка через BGP и туннель

Для собственной сети трафик направляют в центр очистки, например через BGP-анонс адресного пространства, а очищенный поток возвращают по GRE/IPIP или прямому соединению. Такая схема позволяет защищать не только веб.

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

Облачная и гибридная защита

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

При режиме always-on трафик проходит через защиту постоянно. При on-demand требуется обнаружение и переключение; до завершения этих действий возможна деградация. Сравнивайте стоимость с допустимым временем недоступности.

Собственное оборудование и программные фильтры

Аппаратные комплексы, nftables, XDP/eBPF и локальные фильтры полезны в пределах пропускной способности сети и сервера. Для крупных сетей применяются ACL, BGP FlowSpec и другие механизмы оператора. RTBH, или blackhole, полностью отсекает трафик к адресу: это способ ограничить ущерб инфраструктуре, при котором сам сервис становится недоступен.

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

Российские компании и сервисы защиты

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

Сервис	Какой сценарий рассмотреть	Что уточнить
Yandex Cloud Smart Web Security	Веб и API, облачная инфраструктура или внешний origin через защиту домена	Статус Preview для внешнего домена, стоимость запросов, прокси и журналов
CURATOR	Защита веба и сети; отдельные продукты anti-DDoS, WAF, CDN, anti-bot и DNS	Какая комбинация включена; DNS/BGP-подключение и аварийная поддержка
StormWall	Веб-защита либо сетевая очистка для собственной инфраструктуры	Сетевой продукт и WAF приобретаются под нужный сценарий; способ доставки трафика
Kaspersky DDoS Protection	Сети, дата-центры и корпоративные сервисы	Мониторинг, включение очистки, протоколы, роли собственной команды
Selectel	Проект уже работает у этого провайдера	Базовая L3/L4-защита не включает полноценную L7-фильтрацию; условия расширения и RTBH

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

Зарубежные компании и сервисы защиты

Сервис	Какой сценарий рассмотреть	Что уточнить
Cloudflare	Защита проксируемых сайтов и API; для сети существуют отдельные продукты	Возможности плана, доступ к настройкам, поддержку и защиту origin
AWS Shield	Инфраструктура AWS и поддерживаемые ресурсы	Различия Standard/Advanced; для прикладных правил используется AWS WAF
Google Cloud Armor	Приложения за поддерживаемыми балансировщиками Google Cloud	Тип ресурса, HTTP-политику и доступность расширенных функций
Azure DDoS Protection	Публичные IP и сеть Azure	Покрываемые ресурсы; для L7 отдельно нужен WAF
Akamai Prolexic	Сетевая защита собственной или гибридной инфраструктуры	Подключение и отдельные продукты для веб-приложений/API
Fastly DDoS Protection	Приложения и API, обслуживаемые через Fastly	Условия подключения, режим работы и тарификацию

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

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

В запрос поставщику включите домены, IP, протоколы, географию, обычные и пиковые RPS/бит/с, долю динамики, размеры файлов и критичные интеграции. Если измерений нет, начните со статистики хостера и access-логов.

Сравните предложения по одинаковым условиям:

Постоянная защита или переключение после обнаружения.
Покрытие L3/L4/L7, DNS, API и WebSocket.
Лимиты очищенного трафика, запросов и ресурсов прокси.
Оплата атакующего трафика, WAF-запросов, логов и исходящей полосы.
Управление TLS, передача реального IP и аутентификация прокси перед origin.
Время реакции инженера и процедура изменения правил.
Доступ к событиям, API и журналу ложных срабатываний.
SLA, исключения, blackhole и порядок аварийного подключения.

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

Как защитить один VPS за облачным прокси

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

1. Зафиксировать текущие настройки

Сохраните DNS-зону, конфигурацию Nginx/firewall, параметры TLS и список интеграций. Подготовьте консоль хостера и резервный административный доступ. Узнайте, что хостер делает при атаке на IP: очищает поток, ограничивает полосу или включает blackhole.

2. Подключить домен к сервису защиты

Добавьте origin и сертификат, настройте HTTPS до исходного сервера с проверкой сертификата. Проверьте домен и www-вариант, если он используется. Снизить TTL имеет смысл заранее: это не отменяет уже существующий DNS-кэш.

До переключения проверьте через предусмотренный провайдером тестовый режим вход, формы, оплату, webhook, файлы и API. После проверки измените DNS и убедитесь, что запросы действительно проходят через защиту.

3. Закрыть прямой доступ к origin

На firewall разрешите нужный веб-порт только с официальных сетей прокси. Для IPv6 нужна такая же политика: открытая AAAA-запись способна оставить обход защиты. Учтите отдельные адреса health-check, если они предусмотрены документацией.

Уберите технические поддомены, раскрывающие IP. Если адрес уже известен, обсудите его замену или отключение публичного адреса. Закрытый порт не спасает известный IP от насыщения внешнего канала, поэтому сетевая защита origin тоже имеет значение.

У общих сетей CDN могут быть другие клиенты. Где возможно, дополните IP-список аутентификацией именно вашего прокси перед origin: mTLS или предусмотренным провайдером механизмом. Секретный служебный заголовок имеет смысл только если прокси перезаписывает входное значение, а origin проверяет его.

4. Отделить управление и служебные порты

SSH разрешите из административной сети/VPN. Базу данных, Redis и метрики разместите на loopback или приватном интерфейсе. После изменения firewall откройте вторую проверочную административную сессию до закрытия первой.

Не забывайте об обновлении сертификатов. После закрытия порта 80 HTTP-проверка ACME может перестать работать; заранее выберите поддерживаемый маршрут проверки или DNS challenge.

Можно ли сделать защиту на отдельном VPS-прокси

Да. Такая схема подходит, когда нужен свой Nginx, собственные правила, несколько origin или независимый от приложения входной сервер.

Интернет -> L3/L4-очистка провайдера
         -> VPS A: HTTPS-прокси, фильтрация, лимиты
         -> приватная сеть / WireGuard
         -> VPS B: приложение и данные

DNS сайта -> публичный адрес VPS A
Приложение VPS B -> только приватный интерфейс

Провайдер VPS A должен поддерживать ожидаемую сетевую защиту. Обычный дешевый VPS с Nginx становится новой точкой перегрузки. Для сложного HTTP-флуда потребуется также управляемый L7-сервис либо собственная прикладная фильтрация с постоянным сопровождением.

Приватный канал между серверами

Если серверы находятся в разных сетях, можно использовать WireGuard. Пример адресного плана: VPS A получает 10.77.0.1, VPS B - 10.77.0.2. Приложение на B слушает 10.77.0.2:8080, а firewall разрешает этот порт только от 10.77.0.1 на интерфейсе туннеля.

Последовательность внедрения:

Выбрать приватную подсеть, которая не пересекается с существующими маршрутами.
Создать отдельные ключи на каждом сервере и обменяться только публичными ключами.
Указать узкие AllowedIPs: адрес второго узла, без перенаправления всего интернета в туннель.
Поднять канал и проверить приложение по приватному адресу.
Настроить проксирование на VPS A и затем закрыть публичный порт приложения на B.
Проверить перезапуск узлов, MTU, соединение после простоя и мониторинг доступности origin.

Расположение публичного endpoint туннеля согласуют с firewall. Если требуется скрыть B и он находится за NAT, B может устанавливать связь с A; необходимость keepalive зависит от сети. Сам факт использования VPN не скрывает уже известный публичный IP и не защищает его канал от флуда.

Что предусмотреть для надежности

Один VPS A остается единственной точкой отказа. Для более строгой доступности нужны второй прокси и проверенный механизм переключения; две A-записи сами по себе не гарантируют корректный failover. Контролируйте здоровье приложения, свободный диск логов, обновления и запас ресурсов самого прокси.

Свой стек может включать Nginx/HAProxy, ModSecurity с OWASP Core Rule Set, Coraza с подходящим коннектором или CrowdSec. Каждый инструмент требует проверки совместимости и правил. Их установка не создает автоматически распределенную сеть очистки. Для проекта с небольшой командой управляемая L7-защита часто уменьшает эксплуатационную нагрузку.

Пример ограничений Nginx для приложения

Ниже фрагмент для Nginx, который проксирует запросы на приложение. Он добавляется в существующую конфигурацию с рабочим TLS. Пути, лимиты и origin адаптируют к проекту; сначала работает наблюдение без блокировки.

Зоны лимитов и адрес приложения

Этот блок размещается внутри существующего http { ... }, вне server:

limit_req_zone $binary_remote_addr zone=web_ip:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=login_ip:10m rate=1r/s;
limit_conn_zone $binary_remote_addr zone=active_ip:10m;

upstream protected_app {
    server 10.77.0.2:8080;
}

log_format protection '$remote_addr $request_method $uri $status '
                      'rt=$request_time urt=$upstream_response_time '
                      'req=$limit_req_status conn=$limit_conn_status';

Адрес 10.77.0.2:8080 соответствует схеме с двумя VPS и шифрованным туннелем. Для приложения на той же машине используется его локальный адрес, например 127.0.0.1:3000.

Ограничения в виртуальном хосте

Следующий фрагмент размещается внутри server { ... } выбранного сайта, где уже заданы домен, listen и сертификаты. Существующие location нужно объединить с правилами, а не дублировать:

access_log logs/protection.log protection;

limit_req_status 429;
limit_conn_status 429;
limit_req_dry_run on;
limit_conn_dry_run on;
limit_conn active_ip 30;

client_header_timeout 10s;
client_body_timeout 15s;
keepalive_timeout 30s;
client_max_body_size 10m;

proxy_connect_timeout 3s;
proxy_read_timeout 30s;
proxy_request_buffering on;

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;

location / {
    limit_req zone=web_ip burst=30 nodelay;
    proxy_pass http://protected_app;
}

location = /api/login {
    limit_req zone=login_ip burst=5 nodelay;
    proxy_pass http://protected_app;
}

Здесь прокси намеренно перезаписывает передаваемый приложению IP после его проверки. Приложение должно доверять только этому прокси. Заголовок протокола подходит для случая, когда HTTPS завершается на данном Nginx; при другой цепочке TLS нужно корректно передавать исходную схему.

Частота и burst в примере иллюстрируют механику limit_req. Их выбирают по обычной нагрузке и допустимому пику. Для статических файлов за кэшем, входа и тяжелого API нужны разные бюджеты. Большой офис и мобильный оператор могут выпускать множество людей с одного IP; для авторизованных клиентов полезнее дополнительные квоты по аккаунту или токену.

limit_conn учитывает запросы после чтения заголовка, а в HTTP/2 и HTTP/3 активные потоки считаются отдельно. Это ограничение не заменяет защиту от незавершенных заголовков и сетевых атак. Тайм-аут чтения тела задает интервал ожидания данных, а не общий дедлайн загрузки. Длительные загрузки, streaming и WebSocket требуют отдельных настроек.

Реальный IP за облачным CDN

Если перед этим Nginx стоит еще и CDN, без настройки real IP лимит применится к адресам CDN. Сначала закройте origin на firewall и настройте модуль realip по документации провайдера: доверенные CIDR, его заголовок и порядок прокси.

Не указывайте доверие к 0.0.0.0/0 или ::/0. При прямом входе из интернета произвольный клиент может подделать X-Forwarded-For. В собственном VPS A, который принимает пользователей напрямую, переписывание IP из такого заголовка вообще не требуется.

Проверка и включение блокировки

Перед применением сохраните предыдущую конфигурацию, затем выполните:

sudo nginx -t
sudo systemctl reload nginx

Перезагрузка допустима только после успешного nginx -t. На этапе dry run ищите в логе решения REJECTED_DRY_RUN и DELAYED_DRY_RUN, сравнивайте их с легитимными сессиями. После калибровки переключайте нужное limit_req_dry_run или limit_conn_dry_run в off и снова проверяйте конфигурацию.

Убедитесь, что обычный запрос проходит, ограниченный получает 429, а вход и API остаются работоспособными. При ложных срабатываниях верните соответствующее правило в dry run и примените проверенную конфигурацию. Не отключайте всю защиту ради одного маршрута.

Yandex Cloud Smart Web Security для внешнего сайта

Yandex SWS можно подключить к поддерживаемым облачным ресурсам или к внешнему приложению через защиту домена. На дату проверки 7 сентября 2026 года защита внешних доменов помечена как Preview. Для критичного production согласуйте этот статус, ограничения и условия поддержки.

По официальному руководству порядок такой:

Создать прокси и домен, указать origin и сертификат.
Направить DNS на прокси и проверить доступность origin.
Подключить профиль безопасности по шаблону.
Начать с логирования; базовое разрешающее правило должно пропускать наблюдаемый трафик.
Для API выделить правило «Защита API», не отправляющее клиентов в CAPTCHA.
Настроить Advanced Rate Limiter и при необходимости WAF.
Закрыть прямой доступ к origin и проверить интеграции.
Включать блокировку после проверки событий.

В этой реализации правило WAF уже содержит L7 DDoS-защиту: дублирующий Smart Protection для того же трафика не обязателен. Это особенность продукта. Перед подключением рассчитайте стоимость запросов, прокси, журналов и используемого балансировщика; режим наблюдения также может тарифицироваться.

Защита WordPress, магазина и публичного API

WordPress и другие CMS

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

Ограничивайте вход и восстановление пароля, следите за обновлениями CMS и плагинов. XML-RPC отключают только после проверки, что он не нужен существующим интеграциям. admin-ajax.php может обслуживать функции фронтенда: правила подбирают по действиям, а не блокируют путь целиком.

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

API и мобильные приложения

Используйте аутентификацию, квоты по клиенту и методу, ограничения размера входа и параллельных операций. Проверяйте подпись webhook до обращения к дорогим зависимостям. Не подтверждайте прием задачи, пока она не записана надежно: иначе попытка разгрузить endpoint приведет к потере данных.

Задайте пределы пагинации, глубины/сложности GraphQL и формирования отчетов. Ограничьте очереди и число повторов; применяйте backoff и идемпотентность. CAPTCHA для машинных клиентов обычно непригодна, поэтому браузерные страницы и API разделяют политиками.

Функции, которые можно временно отключить

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

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

Как наблюдать за защитой и не потерять клиентов

Смотрите на сеть, задержки, коды ответа и ресурсные ограничения одновременно. Минимум для дашборда: бит/с и пакеты/с у хостера, RPS по маршрутам, новые соединения, cache hit ratio, время origin, очередь приложения, база и решения фильтрации.

Отдельно отслеживайте заявки, авторизации и оплаты. Падение бизнес-метрик после включения WAF может означать ложную блокировку даже при зеленом графике доступности. Проверяйте легитимных роботов предусмотренным провайдером способом; одного User-Agent для доверия недостаточно.

Ограничьте срок и объем хранения журналов, исключите пароли, токены и лишние персональные данные. Во время атаки неконтролируемый access-лог способен заполнить диск. Сохраняйте репрезентативные события и счетчики, необходимые для расследования.

Что делать, если атака уже идет

Зафиксировать начало, симптомы и критичные сервисы. Проверить релизы и обычные причины сбоя.
Открыть инцидент у хостера/anti-DDoS-провайдера: адреса, протоколы, графики и допустимый режим работы.
Включить заранее подготовленный профиль усиленной фильтрации.
Уменьшить нагрузку на origin: кэш, ограничение дорогих маршрутов, отключение второстепенных функций.
Проверять легитимные сессии и интеграции после каждого изменения.
Сохранять события, время и владельца каждого изменения; держать статус для клиентов вне атакуемого контура.
После стабилизации поэтапно вернуть режимы и разобрать первую точку отказа.

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

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

Как проверить готовность до атаки

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

План приемки:

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

Сценарии и метрики удобно подготовить по чек-листу нагрузочного тестирования. Запас производительности и защита от атак проверяются отдельно, хотя используют часть общих измерений.

FAQ

Можно ли остановить DDoS бесплатно?

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

Поможет ли Fail2ban или CrowdSec?

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

Можно ли поставить второй VPS перед основным сервером?

Да: защищенный VPS принимает HTTPS, фильтрует запросы и передает их приложению по приватной сети или туннелю. На основном сервере закрывают публичный веб-доступ. Внешний VPS должен иметь сетевую защиту и достаточные ресурсы; для сложных L7-атак нужны дополнительные меры.

Защитит ли WireGuard от DDoS?

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

Если порт origin закрыт, зачем защищать его IP?

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

Почему после включения лимитов перестал работать сайт?

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

Достаточно ли WAF для интернет-магазина?

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

Можно ли защитить внешний VPS через Yandex Cloud?

В SWS предусмотрена защита внешнего приложения через домен и прокси. На 7 сентября 2026 года документация помечает этот вариант как Preview. Перед внедрением проверьте статус, ограничения и поддержку, затем подключите DNS, сертификат, профиль и ограничения origin.

Нужно ли скрывать сайт от поисковых роботов во время атаки?

Полная блокировка роботов не должна быть стандартной мерой. Настройте проверку известных роботов и контролируйте доступ к публичным страницам, robots.txt и sitemap. Подделанный User-Agent не дает оснований обходить фильтрацию.

Поможет ли увеличение мощности сервера?

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