WAF для защиты веб-приложений - функции и схемы применения

В сообществе информационной безопасности мнения о защите веб-приложений с помощью WAF варьируются от "просто необходимы" до "нецелесообразная трата ресурсов, можно обойтись встроенными средствами".

Разбираем функции WAF, схемы применения и ситуации, когда можно обойтись без него.

Что такое WAF

WAF (Web Application Firewall) — межсетевой экран для веб-приложений.

Основная задача: фильтровать трафик, обнаруживать и блокировать атаки.

Архитектура:

• Запрос из интернета приходит на WAF
• Анализируется на наличие угроз
• Если всё в порядке — пересылается на приложение
• Если обнаружены признаки атаки — блокируется

Вопрос: стоит ли WAF затраченных ресурсов? Ведь это платное решение, требующее установки, настройки и эксплуатации.

Пять групп функций WAF

Функция 1: Публикация приложений

WAF выступает внешним защищённым шлюзом — это следует из архитектуры решения.

Функции публикации:

• Балансировка между бэкендами: Проверка работоспособности узлов, анализ ответов приложения (error, maintenance), переключение на работающие узлы
• Отказоустойчивость: Автоматическое переключение при сбоях, распределение нагрузки
• Управление SSL-политиками: Настройка для рейтинга A+ на SSLlabs, обеспечение совместимости с клиентами, централизованное управление сертификатами
• Управление заголовками: Strict Transport Security, Cross-Origin Resource Sharing (CORS), дополнительные заголовки безопасности

Результат: полноценная инфраструктура публикации на базе WAF.

Примечание: зарубежные решения (F5 Big-IP, Citrix) выросли из балансировщиков, поэтому публикация для них — базовая функция, а фильтрация — дополнительный модуль.

Функция 2: Верификация входных данных

Контроль данных:

• Проверка пользовательского ввода: Несоответствие типов, подозрительные конструкции, признаки атак
• Контроль доступа к URL и API: Разграничение доступа к функциям, контроль endpoint'ов, управление правами на уровне URL
• Проверка структуры данных: Контроль форм, JSON, XML, проверка соответствия схемам, защита от атак на парсер, контроль внешних сущностей в XML
• Контроль соответствия HTTP: Корректность методов, валидация ответов приложения, анализ кодов ответов, реакция на некорректные запросы

Безопасность API: OWASP опубликовал Top 10 для API Security.

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

Позитивная модель WAF:

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

• Высокая надёжность
• Требует тщательного обслуживания
• Риск ложных срабатываний при обновлении приложения

Функция 3: Обнаружение атак

Важнейшая задача WAF — обнаружение атак.

Методы анализа:

• Сигнатурный анализ: Отсечение заведомо вредоносных запросов, ориентация на заранее выделенные паттерны. Популярный, но не идеальный метод.
• Поведенческий анализ: Корреляция событий, выявление подозрительной активности, машинное обучение.
• Обнаружение ботов: CAPTCHA и reCAPTCHA, Browser Challenge, проверка User-Agent, анализ поведения.
• Защита от L7 DoS: Противодействие логическим атакам, контроль частых запросов от ботов, ограничение запросов к ресурсоёмким страницам, защита от исчерпания ресурсов.

Пример из практики: В логах обнаружен запрос "/. ./. ./somefile.txt". Очевидно path traversal! Блокируем. Через полчаса звонок: "Разрешите это, наше приложение так работает... Вот так когда-то написали...".

Виртуальные патчи:

Назначение: быстро закрыть обнаруженные уязвимости, пока разработчики готовят исправление. Как работает: WAF настраивается на блокировку запросов с признаками эксплойта. Статус: временная мера для быстрого реагирования.

Функция 4: Видимость и наблюдаемость

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

Возможности WAF:

• Логирование: Регистрация подозрительных действий, детальная информация о запросах, история событий.
• Интеграция с SIEM: Отправка сообщений о возможных атаках, SOC берёт события в работу.
• Построение схем приложений: Карта доступных страниц, параметры и передаваемые данные, автоматический swagger для API на основе статистики вызовов. Сравнение фактической структуры с планируемой.
• Сканирование и перепроверка: Создание безопасных тестовых запросов, проверка потенциальных уязвимостей. Замена подозрительного payload на безопасный индикатор.
• Анализ ответов приложения: Поиск уязвимостей в ответах, обнаружение потенциально успешных атак.

Функция 5: Доверие

Вопросы, на которые нужно ответить:

• Уверенность в безопасности: Кто разработал приложение? (наша команда, подрядчик, рыночное решение) Поддерживается ли оно? (или досталось в наследство 10 лет назад) Как быстро можем устранить уязвимость? Как узнаем о её существовании?
• Необходимость контроля: Нужен ли дополнительный контроль трафика? Каков уровень доверия к приложению?
• Соответствие требованиям: Формальное соответствие регуляторам, стандарты безопасности, использование решений, которым доверяет регулятор.

Часто ответы на эти вопросы приводят к выводу о необходимости дополнительного контроля.

Схемы применения WAF

Все функции могут выполняться WAF или другими средствами — зависит от архитектуры, инфраструктуры и разделения ответственности.

Схема 1: Классическая (Интернет → WAF → Приложение)

Архитектура: Интернет → WAF → Приложение

Функции WAF: • Публикация приложения (максимум) • Верификация входных данных • Обнаружение атак • Видимость и доверие • Всё возможное

Что остаётся приложению:

• Идентификация пользователей
• Управление доступом
• Регистрация действий пользователей (внутри логики приложения)
• Патчи для уязвимостей
• Отказоустойчивость

Разделение ответственности:

На практике: в двухзвенной схеме всё находится в зоне ответственности подразделения информационной безопасности.

Схема 2: Два WAF (многоуровневая защита)

Архитектура: Интернет → WAF 1 → WAF 2 → Приложение

Первый уровень (фильтр грубой очистки):

• Защита от DDoS
• Обнаружение и блокирование ботов
• Базовый сигнатурный анализ
• Взаимодействие с внешним миром

Второй уровень (фильтр тонкой очистки):

• Настройка под конкретное приложение
• Позитивная модель
• Специфический сигнатурный анализ
• Виртуальные патчи для конкретного приложения

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

Разделение ответственности:

Альтернатива: первый WAF может быть заменён на систему защиты от DDoS (облачную или локальную). Такая конфигурация считается классической схемой защиты.

Схема 3: WAF, встроенный в систему публикации

Архитектура: Интернет → Система публикации + WAF (агент) → Приложение

Ситуация применения:

• Уже есть настроенная система публикации (Nginx, Envoy, Kubernetes с ingress)
• Сложная схема на базе Infrastructure-as-Code
• Добавлять ещё один реверс-прокси проблематично

Реализация:

• Агенты, устанавливаемые на nginx или другой реверс-прокси
• Проверка запросов без изменения архитектуры
• Функции безопасности встроены в существующую инфраструктуру

Разделение ответственности:

Зоны ответственности ИБ и ИТ пересекаются.

Пример: На nginx добавлены модули-агенты WAF. ИТ-подразделение администрирует nginx, специалисты ИБ видят и принимают решения только по событиям безопасности.

Схема 4: Без WAF

Архитектура: Интернет → Система публикации → Приложение (со встроенной защитой)

Условия применения:

• Надёжная система публикации уже есть
• Приложение проводит тщательную верификацию входных данных
• Быстрое устранение уязвимостей
• Регулярные пентесты и анализ уязвимостей
• Полное доверие к приложению
• Нет требований комплаенса или есть сертификат

Как реализуются функции безопасности:

• Публикация: Nginx или другой реверс-прокси, частотные ограничители (защита от DDoS). Альтернатива: облачные системы защиты.
• Верификация данных: Встроенная в приложение (жёсткий контроль ввода).
• Обнаружение атак: Риск принимается, компенсируется плотной работой с уязвимостями.

Разделение ответственности:

Этот подход требует:

• Значительных ресурсов на разработку
• Поддержки приложения на высоком уровне
• Высокого уровня зрелости процессов
• Встроенной безопасности приложения (security by design)

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

• Публикация приложений
• Верификация входных данных
• Обнаружение атак
• Видимость и наблюдаемость
• Обеспечение доверия

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