Направление К2 · pillar-материал

Защита веб-приложений: WAF, DDoS-mitigation, bot protection и OWASP-практики

Веб-приложение публичной коммерческой компании одновременно решает две задачи: открыто принимает трафик реальных клиентов и блокирует автоматизированные атаки. От грубых SQL-инъекций и XSS до многоступенчатых DDoS L7, скрейпинга и фрода. Этот материал — подробное руководство по построению защиты веб-приложения для CISO среднего бизнеса в 2026 году: что такое WAF и как его выбрать, чем отличается DDoS-mitigation L3/L4 от L7, какие security headers обязательны, как защититься от ботов и сколько это стоит.

Карта угроз веб-приложению

Прежде чем строить защиту, важно описать модель угроз. Основные классы атак на коммерческое веб-приложение:

• Прикладные атаки (OWASP Top 10). SQL-инъекции, XSS, SSRF, IDOR, путь-обход, RCE. Цель — компрометация данных или захват инфраструктуры.
• DDoS L3/L4. Объёмные сетевые атаки на исчерпание полосы или таблицы соединений. Источник — ботнеты, отражённые атаки через DNS/NTP-амплификацию.
• DDoS L7. Прикладные атаки, имитирующие реальный пользовательский трафик. Сложнее фильтровать, особенно если злоумышленник использует резидентные прокси.
• Скрейпинг. Массовый автоматизированный сбор каталога, цен, отзывов конкурентами или агрегаторами. Не приводит к утечке, но искажает аналитику и нагружает инфраструктуру.
• Account takeover (ATO). Credential stuffing — массовый перебор украденных учёток из утечек других сервисов. Phishing с последующим использованием ваших cookies. Brute force паролей.
• Карточный фрод. Тестирование украденных банковских карт через ваш чекаут (карта проверяется мелкими покупками, потом сбывается дороже на другом сайте).
• Бизнес-логические атаки. Эксплуатация особенностей промокодов, накопительных скидок, реферальных программ. Чаще всего — ручные.
• Supply chain. Атака через CDN, npm-пакеты, сторонние SDK, JS-теги аналитики. Magecart-стиль — внедрение кода кражи карт через скомпрометированную аналитику.

WAF: что это и какие выбрать

Web Application Firewall — межсетевой экран уровня приложения, который анализирует HTTP-запросы и решает, пропустить ли их к серверу или заблокировать. Современный WAF работает в двух режимах: сигнатурный анализ (известные паттерны атак — например, всё, что напоминает SQLi-payload) и поведенческий анализ (отклонения от нормального профиля трафика).

Архитектурные варианты WAF

• Облачный WAF (proxy-mode). Весь трафик идёт через сервис провайдера, который фильтрует и пересылает на ваш origin. Подключение — изменение DNS A-записи. Преимущества: минимум администрирования, автообновление правил, защита от DDoS, скорость подключения (часы). Российские: Wallarm, BI.ZONE WAF, Servicepipe WAF.
• Reverse proxy WAF на собственном edge. Nginx + ModSecurity, либо HAProxy с lua-скриптами. Контроль полный, но управление правилами — на вас.
• Сертифицированные российские on-premise WAF. Positive Technologies Application Firewall (PT AF), ICL-Solar webProxy, InfoWatch ARMA. Обычно нужны при требованиях аттестации, в финансовом и государственном секторах. Для коммерческого бизнеса без КИИ — избыточны.
• WAF в составе CDN. Cloudflare WAF, AWS WAF. Удобны для глобальных проектов, но локализация для российских клиентов хуже, чем у локальных провайдеров, и есть санкционные риски.

Какой WAF выбрать коммерческому бизнесу

Для среднего бизнеса с трафиком от 1 до 50 ТБ в месяц мы рекомендуем облачный российский WAF, объединённый с DDoS-mitigation и bot protection. Это закрывает 80% задач за разумный бюджет:

• Wallarm (wallarm.com) — современная аналитика, защита API, обнаружение уязвимостей, активное русскоязычное сообщество, есть гибридная схема on-premise+cloud.
• Servicepipe (servicepipe.ru) — пакет «защита периметра», который объединяет WAF + DDoS + DNS, входит в реестр российского ПО.
• BI.ZONE (bi.zone) — экосистема от Сбера, удобен, если уже используется их Threat Intelligence.
• Qrator + Wallarm — связка DDoS-провайдера с WAF, исторически популярна в e-commerce.

DDoS-mitigation: L3/L4 vs L7

DDoS-атаки различают по уровням модели OSI. От уровня зависит, кто и как защищает.

L3/L4 — сетевой уровень

UDP/SYN-флуд, амплификация через DNS, NTP, memcached. Цель — забить канал к вашему дата-центру или таблицу состояний firewall-а. Размеры атак — до сотен Гбит/с и сотен миллионов пакетов в секунду. Защита возможна только на уровне магистрального провайдера или специализированного DDoS-сервиса с большими каналами. В России: Qrator, StormWall, Servicepipe, DDoS-Guard.

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

L7 — прикладной уровень

HTTP-флуд: миллионы запросов на ресурсоёмкие эндпоинты (поиск, login, чекаут). Запросы выглядят как легитимный пользовательский трафик. Часто идёт с резидентных прокси (взломанные домашние роутеры, IoT-устройства), что усложняет блокировку по IP. Защита — поведенческий анализ, CAPTCHA-челленджи, fingerprinting, rate-limiting.

Стратегия подключения

Минимум для коммерческой компании, доступной через интернет: облачный WAF + DDoS L7 в одном пакете + договор с магистральным DDoS-провайдером на случай L3/L4 (часто включён как «under attack» режим у того же сервиса). Опционально — собственный nginx+rate-limit как первая линия для рутинных атак.

OWASP Top 10 как чек-лист защиты

OWASP Top 10:2021 — основной публичный документ, который описывает 10 классов уязвимостей веб-приложений. Каждый класс — отдельная проверка как при разработке, так и при настройке защитных средств.

• A01 Broken Access Control. Решение — серверная авторизация на каждом запросе, тесты IDOR, ролевая модель.
• A02 Cryptographic Failures. Решение — TLS 1.2+, шифрование чувствительных полей, безопасное хранение паролей (bcrypt/argon2).
• A03 Injection. Решение — параметризованные запросы, ORM, валидация входа, WAF как страховка.
• A04 Insecure Design. Решение — threat modeling на этапе дизайна, security review архитектуры.
• A05 Security Misconfiguration. Решение — hardening базовых образов, отключение DEBUG в production, security headers.
• A06 Vulnerable Components. Решение — SCA в CI/CD, регулярные обновления, dependency scanning.
• A07 Authentication Failures. Решение — rate-limiting login, 2FA, отказ от слабых паролей, защита от credential stuffing.
• A08 Data Integrity Failures. Решение — подписи артефактов, валидация сериализованных объектов, SRI для JS из CDN.
• A09 Logging Failures. Решение — централизованный сбор логов (SIEM), мониторинг аномалий, ротация и защита логов от модификации.
• A10 SSRF. Решение — белый список разрешённых URL для исходящих запросов, валидация по DNS, метаданные IMDS v2 в AWS.

Полный текст с разбором каждой категории — на owasp.org/Top10.

Security headers: что и зачем

HTTP security headers — это «дешёвая» защита, которая внедряется правкой конфигурации веб-сервера за несколько часов. При этом она закрывает целый класс атак. Минимальный набор для современного веб-приложения:

Заголовок	Что делает	Рекомендованное значение
Strict-Transport-Security	Принудительный HTTPS	max-age=31536000; includeSubDomains; preload
Content-Security-Policy	Белый список источников JS/CSS/img/font/connect	default-src 'self'; script-src 'self' 'nonce-XXX'; ...
X-Content-Type-Options	Запрет MIME-sniffing	nosniff
X-Frame-Options	Защита от clickjacking	SAMEORIGIN или DENY
Referrer-Policy	Контроль передачи реферера	strict-origin-when-cross-origin
Permissions-Policy	Отключение неиспользуемых API браузера	camera=(), microphone=(), geolocation=()

Проверить текущую настройку — бесплатный инструмент securityheaders.com. Внедрение CSP — самая трудоёмкая часть: на больших приложениях с inline-скриптами и сторонними тегами обычно делают за 2–4 спринта с отдельным мониторингом нарушений в режиме Report-Only.

Bot protection: защита от автоматизации

Bot protection — отдельный класс защиты, который отличает реальных пользователей от автоматизированных скриптов. Уровни сложности ботов:

• Уровень 1. Скрипты на curl/Python requests, без браузерного окружения. Блокируются простыми правилами (отсутствие JS, ботские User-Agent, отсутствие cookies).
• Уровень 2. Headless Chrome / Playwright. Имитируют браузер, но имеют отличия в JS-окружении (отсутствие плагинов, дефолтные размеры экрана). Ловятся через fingerprinting.
• Уровень 3. Браузерные fingerprint-spoofers, резидентные прокси, ферма реальных устройств. Защита — поведенческий анализ, ML-модели, CAPTCHA только для подозрительного сегмента.

Российские и международные решения: Wallarm, DataDome, PerimeterX (теперь HUMAN), Cloudflare Bot Management. Yandex SmartCaptcha — встраиваемая капча от Яндекса, полезна как fallback. Для большинства e-commerce среднего размера достаточно WAF с включённым bot management в облаке.

Rate-limiting на уровне приложения

Помимо облачной защиты обязательно настройте rate-limiting на уровне приложения. Минимальные правила:

• Login: 5–10 попыток в минуту с одного IP, после превышения — задержка или CAPTCHA.
• Password reset: 3 запроса в час на email.
• Регистрация: 5 в час с IP, с проверкой на временные email и фрод-сигналы.
• Поиск: 60–120 запросов в минуту на пользователя.
• Чекаут / создание заказа: 10–20 в минуту, с дополнительной проверкой подозрительных паттернов.
• API-эндпоинты: отдельные quotas по API-ключу, плюс burst-limit.

В nginx это делается через limit_req_zone, в приложении — через Redis или специализированные библиотеки (express-rate-limit, slowapi, django-ratelimit).

Логирование и SIEM-интеграция

Защита без видимости — это бессмысленно. Минимальные требования к логированию:

• Логи nginx/CDN с указанием IP, метода, URL, User-Agent, статуса ответа, времени обработки.
• Логи приложения с действиями пользователей: вход, выход, изменение данных, скачивание файлов, экспорт.
• Логи WAF с заблокированными запросами и категорией атаки.
• Логи аутентификации: успешные и неудачные попытки, смена пароля, активация 2FA, использование recovery.
• Логи административных действий: создание учётных записей, изменение прав, изменение конфигурации.

Хранение — централизованно (ELK/OpenSearch, Splunk, Vector + ClickHouse), с защитой от модификации и retention не менее 6 месяцев. Для compliance 152-ФЗ — год и более. Если есть SIEM (KUMA от Касперского, Positive MaxPatrol SIEM, Splunk) — настройте корреляционные правила: «5 неудачных входов + 1 успешный с того же IP» = подозрение на ATO, «массовая выгрузка БД» = алёрт.

Incident response при атаке

План реагирования на инциденты — обязательный документ. Минимальная схема для веб-приложения:

1. Обнаружение. Триггер: алёрт SIEM, жалоба клиента, рост ошибок 5xx, упоминание в Telegram-каналах об «утечке».
2. Триаж. Дежурный инженер за 15–30 минут оценивает: реальный инцидент или ложное срабатывание, класс (DDoS / ATO / утечка / RCE), масштаб.
3. Эскалация. Уведомление CISO и руководства. Активация incident-команды (разработчик, devops, security, юрист).
4. Сдерживание. Изоляция скомпрометированных систем, блокировка атакующих IP/учётных записей, переключение в «under attack» режим у CDN.
5. Расследование. Сбор логов, восстановление цепочки событий, определение точки входа.
6. Устранение. Закрытие уязвимости, ротация скомпрометированных секретов, восстановление целостности.
7. Уведомления. При утечке ПДн — РКН в течение 24 часов. Внутренние стейкхолдеры. При необходимости — клиенты.
8. Post-mortem. Разбор без поиска виноватых. Что предотвратило бы повторение. План работ.

Бюджет на защиту веб-приложения

Реалистичные ориентиры для коммерческого бизнеса (без КИИ):

Уровень	Месячные расходы	Что включено
Стартер (до 1 ТБ трафика)	50 000 – 100 000 ₽	Облачный WAF + DDoS L3/L4 + базовый bot management
Средний (1–20 ТБ)	150 000 – 400 000 ₽	WAF + DDoS L3/L4/L7 + bot protection + кастомные правила
Корпоративный (20+ ТБ)	500 000 ₽ – 1.5 млн ₽	Многоуровневая защита, выделенный SOC, ML-аналитика, threat intelligence

Дополнительно — единовременные CAPEX-затраты: pentest (от 500 000 ₽ раз в год), внедрение security headers (20–80 часов разработки), интеграция SIEM (от 1 млн ₽), внедрение secure-SDLC процессов.

Сравнение российских WAF-решений

Для коммерческого среднего бизнеса в 2026 выбор WAF почти всегда — между несколькими российскими вендорами. Зарубежные решения (Cloudflare, Akamai, F5, Imperva) формально работают, но создают риски по 152-ФЗ и санкционные риски по доступности.

Решение	Тип	Когда выбирать
Wallarm	Cloud + On-prem	API-heavy SaaS, активные релизы, нужна интеграция с DevOps и SOAR; ML-детект 0-day
PT Application Firewall (PT AF)	On-prem, сертификат ФСТЭК	Системы с требованиями ФСТЭК (КИИ, госорганы), классическая корпоративная среда
Servicepipe	Cloud	Базовая защита от L7 + WAF, оптимально для среднего e-commerce; хорошее соотношение цены и качества
Qrator Labs	Cloud, фокус на DDoS	Когда главная угроза — объёмные DDoS; WAF подключается как опция
StormWall	Cloud, DDoS+WAF	Mid-market, хорошее покрытие L7 DDoS, единое окно с WAF
BI.ZONE WAF	Cloud	Связка с другими сервисами BI.ZONE (CTI, BUG BOUNTY, pentest)
ModSecurity + Coraza	On-prem, open-source	Для команд с in-house DevOps, ограниченным бюджетом и собственным SRE
EdgeЦентр Web Protect	Cloud (CDN + WAF)	Когда нужен российский CDN + WAF в одном пакете

Полная карта решений с актуальными ценами и нюансами интеграции — в pdf-обзоре по запросу.

Расширенный кейс: маркетплейс косметики под комбинированной атакой

Маркетплейс косметики «Заказчик В», ~280 000 активных пользователей. В пятницу вечером после успешной рекламной кампании сайт неожиданно лёг: TTFB вырос до 14 секунд, потом 502. Параллельно поддержка получила 47 жалоб от клиентов «не могу войти в аккаунт».

Анализ показал три параллельные активности:

• DDoS L7 через массовые HTTP-запросы к /search с уникальными query-параметрами (cache-bypass), 240 000 RPS с 14 000 IP-адресов из 32 стран.
• Credential stuffing через эндпоинт /api/auth/login: ~12 000 попыток за 2 часа со словарём 2.1 млн утёкших паролей с других сервисов. ~600 учёток успели взять.
• Scraping каталога от двух Headless Chromium-кластеров через резидентные прокси, ~3 000 RPS с rotation user-agent и cookies.

Что сделали в первые 4 часа:

1. Подключили экстренную DDoS-mitigation через Servicepipe (под-ключение за 90 минут через DNS-redirect).
2. Активировали «under attack» режим: challenge-страница для всех новых сессий с проверкой JS-fingerprint.
3. Запросили у Servicepipe blacklist по AS-номерам известных bullet-proof-хостингов.
4. Поставили rate-limit 5 попыток/минуту на /api/auth/login + 2FA по SMS для всех новых сессий.
5. Принудительно сбросили сессии всех скомпрометированных учёток + предложили смену пароля.
6. Расследовали утечку: 600 учёток подтвердились валидными по данным наших клиентов из чужих утечек (HaveIBeenPwned), это не была компрометация маркетплейса.

Через 14 дней сделали постоянное решение: bot protection (DataDome), HCaptcha на регистрации и логине, rate-limit на критичных эндпоинтах, мониторинг логов через SIEM (Wazuh), правила корреляции для раннего детекта credential stuffing. Расходы: 380 тыс. ₽/мес на bot management + 220 тыс. ₽/мес на расширенный WAF/DDoS-пакет. Эффект: 0 успешных атак за 12 месяцев, drop конверсии scrapers на 94%.

Регуляторы и стандарты

• OWASP Top 10 — топ-10 рисков веб-приложений.
• OWASP ASVS — стандарт верификации безопасности.
• OWASP Secure Headers Project — справочник по security headers.
• fstec.ru — ФСТЭК, реестр сертифицированных WAF, требования для КИИ.
• publication.pravo.gov.ru — 152-ФЗ и связанные акты по требованиям к защите.
• cve.org — реестр известных уязвимостей.
• nvd.nist.gov — NIST NVD с метриками CVSS.

Связанные материалы

• Тестирование на проникновение: регулярная проверка эффективности WAF и кода.
• Безопасность API: отдельные практики для REST/GraphQL-эндпоинтов.
• Secure SDLC: чтобы новые релизы не приносили новые уязвимости быстрее, чем WAF успевает их закрыть.
• Защита персональных данных: правовые требования к защите веб-приложений с ПДн.

FAQ о защите веб-приложений

Обсудить защиту веб-приложения Бесплатная 30-минутная встреча: текущая защита, узкие места, рекомендации по бюджету.