Финансовый риск
От 50 000 до 300 000 рублей в час из-за недоступности сайта для клиентов при атаке на прикладном уровне (L7), перерасхода ресурсов CPU/RAM хостинга.
Влияние на KPI
Снижение конверсии заказов. Медленный отклик сайта (TTFB) ухудшает поведенческие факторы и пессимизирует поисковый трафик из Google и Яндекса.
Уровень критичности
Высокий
Кому поручить
DevOps-инженер / Бэкенд-разработчик
Почему хороших пользователей нельзя банить
даже во время атаки
Защита от DDoS должна отличать вредный трафик от реальных клиентов. Если пользователь уже прошёл проверку, система не должна резко превращать его в нарушителя из-за 503, 504 или ошибки backend.
Плохая DDoS-защита часто выглядит просто: много ошибок или запросов — значит IP вредный, режем. Для владельца сайта это может казаться безопасным, но для бизнеса такая логика опасна: под блокировку попадают люди, которые уже прошли проверку, оформляют заказ, работают в личном кабинете или пытаются повторить действие после временной ошибки.
Современная защита веб-приложений должна быть богаче. Она должна учитывать контекст: прошёл ли пользователь challenge, есть ли у него доверенная сессия, какие ошибки вернул backend, похож ли трафик на атаку, можно ли дать мягкий cooldown вместо жёсткого запрета.
В этой статье разбираем модель, которая нужна DDoS + WAF провайдеру: trust states, verified-user grace, cooldown page и recovery challenge.
Проблема: бинарная защита ломает доверие
В реальном приложении пользователь может открыть несколько вкладок, повторить запрос, дождаться ответа API, обновить страницу, попасть на endpoint, который временно отдаёт ошибку. Это не всегда атака. Иногда это обычная работа сайта под нагрузкой.
Если защита считает любую серию 4xx/5xx ошибок поведением злоумышленника, она начинает наказывать не только ботов, но и настоящих клиентов. Особенно опасны ситуации, где пользователь уже был в доверенном состоянии: прошёл challenge, получил cookie, работал с личным кабинетом или оформлял оплату.
Поэтому DDoS-защита и WAF должны оценивать не только запрос, но и историю доверия.
Trust ladder: вместо GREEN → BLACK
stateDiagram-v2
[*] --> Unknown: новый посетитель
Unknown --> Probation: базовая проверка
Probation --> Trusted: challenge пройден
Trusted --> VerifiedCooldown: backend errors / спорный всплеск
VerifiedCooldown --> RecoveryChallenge: нужно подтвердить браузер
RecoveryChallenge --> Trusted: проверка пройдена
VerifiedCooldown --> SoftBlock: поведение ухудшается
SoftBlock --> HardBan: явный malicious pattern
HardBan --> [*]: TTL истёк / ручной разбор
Trust ladder — это лестница доверия. Она не обещает, что проверенный пользователь никогда не будет ограничен. Но она запрещает бедную реакцию “был зелёным — стал чёрным” без промежуточных состояний.
Для бизнеса это критично: во время атаки важна не только фильтрация мусора, но и сохранение доступа для тех, кто приносит деньги — покупателей, партнёров, операторов, сотрудников и API-клиентов.
Где здесь WAF
WAF-фильтр нужен, чтобы блокировать SQL injection, XSS, path traversal, сканеры, подозрительные payload и автоматизированные попытки взлома. Но WAF не должен быть “чёрным ящиком”, который блокирует всё необычное без объяснения.
Правильная модель WAF включает audit mode, исключения для административных зон, разные профили строгости и понятный журнал событий. Особенно важно отделять customer-facing защиту от внутренних операторских интерфейсов и служебных API.
Если вы хотите глубже разобраться в WAF-слое, посмотрите материалы WAF и OWASP: практическое руководство и WAF-правила: от базовых до продвинутых.
Как должна работать verified-user grace
После challenge система должна помнить, что браузер уже подтвердил себя: cookie, short-lived trust receipt или другое состояние доверия.
503, 504 и деградация origin чаще говорят о здоровье приложения. Такие события нельзя автоматически считать атакой конкретного IP.
Если поведение спорное, пользователь должен увидеть понятную 429-страницу: защита временно ограничила запросы, попробуйте повторить через короткое время.
Для доверенных пользователей лучше предложить повторную мягкую проверку, чем молча рвать соединение или показывать общий Forbidden.
Команда защиты должна видеть: почему сработало ограничение, какие сигналы повлияли, когда состояние истечёт и можно ли безопасно снять блок.
Что должен видеть владелец сайта
Если сервис защиты показывает только “заблокировано 12 000 запросов”, это мало. Владельцу сайта важно понимать, кто был заблокирован, почему, сколько пользователей прошли challenge, сколько попали в cooldown, были ли WAF false positives и какие endpoint давали ошибки.
Минимальный набор для клиентской области:
- состояние домена: normal, elevated, under attack;
- разделение blocked, challenged, passed и cooldown;
- WAF-события с режимом audit/block;
- подозрительные path, страны, ASN и user-agent;
- origin health: 5xx, timeout, DNS/SSL;
- рекомендации: что исправить в приложении и какие правила включить.
Это превращает анти-DDoS из “чёрной коробки” в управляемую платформу application protection.
flowchart LR
U[Пользователь] --> E[Edge / POP]
E --> T{Trust state}
T -->|unknown| C[Challenge]
T -->|trusted| W[WAF + Rate limits]
T -->|cooldown| P[429 cooldown page]
C -->|passed| W
W -->|clean| O[Origin]
W -->|suspicious| A[Audit / soft block]
O -->|5xx/timeout| H[Origin health signal]
H --> T
A --> L[Security events]
P --> R[Recovery challenge]
R --> T
- HTTP Flood: как отличить ботов от реальных пользователей — про L7-атаки и поведенческие признаки.
- Как отличить DDoS от “сломалось” — про разницу между атакой и backend-деградацией.
- Что делать при 502/504 прямо сейчас — план действий при ошибках origin.
- Как выбрать защиту от DDoS — критерии для владельца бизнеса.
- Почему CAPTCHA не спасает — почему challenge должен быть частью системы, а не единственной защитой.
Чаще всего из-за слишком грубых правил: высокий error rate, много повторных запросов, подозрительный user-agent или совпадение с WAF-сигнатурой. Без контекста система может принять реального пользователя за бота.
Это льготный режим для пользователя, который уже прошёл проверку. Вместо мгновенного hard ban система учитывает его историю доверия и сначала применяет мягкие состояния: cooldown, повторную проверку или временное ограничение.
Silent drop выглядит как сломанный сайт. Cooldown page объясняет, что защита временно ограничила запросы, и даёт пользователю понятный следующий шаг: подождать, пройти recovery challenge или обратиться в поддержку.
Нет. DDoS-защита работает с объёмом, частотой и поведением трафика. WAF анализирует HTTP-запросы и payload: SQL injection, XSS, path traversal, сканеры. В зрелой платформе оба слоя работают вместе.
Смотрите не только blocked requests, но и жалобы на Forbidden, рост 5xx, падение конверсии, повторные challenge, всплески cooldown и WAF-срабатывания на легитимных страницах: login, checkout, личный кабинет, API.
Скопируйте эти вопросы и отправьте вашему техническому директору (CTO) или руководителю разработки:
- Настроена ли WAF-фильтрация для отсечения ботов с помощью JS-челленджей без показа капчи реальным пользователям?
- Защищен ли веб-сервер от атак типа Slowloris путем оптимизации HTTP Keep-Alive таймаутов?
- Проверено ли наше приложение на защиту от атак типа HTTP Request Smuggling и отравления кэша?
Словарь по теме
Origin Server
Основной сервер, где хранится и обрабатывается контент. CDN кэширует контент с origin и раздаёт его пользователям.
SQL-инъекция
Атака через внедрение вредоносного SQL-кода в запросы к базе данных. Позволяет получить несанкционированный доступ к данным или изменить их.
User-Agent
HTTP-заголовок, идентифицирующий браузер или программу. Боты часто имеют пустой или подозрительный User-Agent.
L7 атака
Атака на прикладном уровне (HTTP). Атакующий отправляет валидные HTTP-запросы, которые выглядят как обычные пользователи, но нагружают тяжёлые endpoint'ы.
Endpoint
URL-адрес, по которому доступен определённый ресурс или функция API. Например: /api/users, /login.
CAPTCHA
Тест для отличия человека от бота. Просит распознать изображения, решить задачу или просто кликнуть галочку. Используется для защиты форм.
OWASP
Open Web Application Security Project — некоммерческая организация, публикующая стандарты веб-безопасности и списки уязвимостей.
DDoS
Распределённая атака на отказ в обслуживании. Множество устройств одновременно отправляют запросы на сервер, перегружая его и делая недоступным для легитимных пользователей.