Облачный WAF (web application firewall) — быстрый и эффективный способ защиты веб-приложений от кибератак. Доказано на практике: за два дня можно надежно прикрыть уязвимости простого сервиса. Для более сложных приложений за это время реально настроить WAF, запустить базовую фильтрацию и начать разработку кастомных политик фильтрации запросов.

Недавно к нам в К2 Кибербезопасность обратился клиент, которому нужно было быстро защитить достаточно простое веб-приложение, и мы с инженером практики защиты приложений Даниилом Золотаревым осуществили экспресс-развертывание PT Cloud Application Firewall. На примере этого проекта разберем варианты реализации, возможные ограничения, важные условия и полезные рекомендации по внедрению WAF.

Когда что-то пошло не так

На пилотном стенде с веб-приложением заказчика отдел информационной безопасности обнаружил уязвимость удаленного выполнения кода (RCE). Идеальное решение — обновить программное обеспечение до актуальной версии, в которой эта уязвимость устранена. Однако возникла проблема: это софт иностранной компании с приостановленной технической поддержкой. Самостоятельный поиск дистрибутива, обновление ПО и связанных компонентов, а также устранение возможных проблем без технической поддержки гарантированно вывели бы нас далеко за рамки пилотного проекта. Мы обсудили ситуацию и поняли: закрывать уязвимость самостоятельно — не выход. При этом уязвимость не давала согласовать пилот с отделом информационной безопасности. Внедрение системы затягивалось и, чтобы не сорвать сроки, требовалось срочно найти альтернативу, причем не костыль, а надежное решение.

Если ПО уязвимо для удаленного выполнения кода, логичный выход — анализировать и фильтровать поступающие HTTP-запросы. Решение напрашивалось само собой — использовать WAF.

Какой WAF выбрали для защиты и почему

Мы выбрали PT Cloud Application Firewall компании Positive Technologies, отказавшись от on-premise-решений, и вот почему:

• Отсутствие свободных ресурсов. У заказчика не оказалось свободных серверов даже в тестовой среде. Защищаемый сервис не требовал высокой производительности, следовательно, заводить под него целый новый сервер было неэкономно.

• Скорость развертывания. Требовалось оперативно установить агент для обработки трафика, не теряя время на развертывание и настройку всей инфраструктуры.

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

Как ни странно, продукт Позитива работает по негативной модели. То есть пропускает только тот трафик, который однозначно попадает в категорию легитимного и строго отсекает любые подозрительные запросы.

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

PT Cloud Application Firewall прост и быстр в настройке и обладает теми же функциями, что и on-premise PT Application Firewall. Облачный WAF также снабжен внешним агентом на nginx, но с управлением через облако вендора. Фильтрующий узел (nginx + агент PT Cloud AF) размещается локально, а обмен данными с облаком вендора происходит следующим образом: логи и события безопасности отправляются в облако, а политики безопасности и сигнатуры поступают из него на узел фильтрации.

Таким образом, PT Cloud Application Firewall представляет собой двухуровневое облачное решение: 

1. Сервер управления в облаке вендора.

2. Фильтрующая нода на мощностях Облака К2.

С практической точки зрения такая архитектура не уступает решениям on-premise. Трафик защищаемого приложения не попадает в облако вендора. В облако вендора отправляются только запросы, для которых сработала сигнатура или правило фильтрации. При этом чувствительные данные (заголовки и куки авторизации, пароли, конфиденциальные данные) маскируются. Неважно, куда идут запросы, — на IP-адрес в инфраструктуре заказчика или в нашем облаке. Везде используется TLS-шифрование.

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

Как быстро развернуть PT Cloud Application Firewall

Чтобы быстро развернуть облачный WAF, требовались два ключевых элемента: личный кабинет в облаке вендора и мощности, на которых будет развернут агент фильтрации. Благодаря сотрудничеству Positive Technologies и K2 Cloud мы решили вопрос с развертыванием WAF буквально за два дня.

На лицензионном портале вендора можно самостоятельно за пару минут завести «пилот» через личный кабинет без участия службы поддержки. У Positive Technologies множество отдельных личных кабинетов (тенантов) для каждого заказчика, изолированных друг от друга. Доступ к конкретному тенанту имеют только сам заказчик и партнер, который обеспечивает настройку. По сути, это основной интерфейс управления WAF.

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

Сам процесс настройки довольно прост. Во-первых, это стандартная настройка реверс-прокси на nginx. Во-вторых, это установка агента и добавление нескольких директив в конфигурацию nginx.

Для подключения агента нужна строка подключения. Ее можно найти и скопировать в консоли PT Cloud Application Firewall по пути: Система → Изолированное пространство → Ваш тенант.

Следующим шагом стало обеспечение мощностей для развертывания фильтрующей ноды. Коллеги из K2 Cloud выделили для нас новый VPC и личный кабинет за полдня, включая все необходимые согласования. После этого наша команда за 10 минут самостоятельно развернула сервер с требуемыми параметрами и опубликовала его на внешнем IP-адресе.

Установка агента и настройка nginx

Существует несколько способов установки агента PT Cloud Application Firewall.

Можно использовать ISO-образ или Debian-пакет на предварительно подготовленной ОС Astra Linux или Debian 10/11. ISO-образ представляет собой готовую операционную систему с уже установленным модулем. Достаточно развернуть виртуальную машину из этого образа, и система готова к работе. Метод с Debian-пакетом предполагает наличие машины с установленной ОС, на которую сначала устанавливается nginx, а затем модуль PT Cloud Application Firewall.

PT Cloud Application Firewall также поддерживает контейнерную версию. Если инфраструктура и сервер заказчика находятся в одной подсети, агент можно установить с помощью Ingress Controller для Kubernetes.

В нашем случае не было ни контейнера, ни инфраструктуры, ни кубера, так что мы выбрали развертывание машины на Debian 11 (последней стабильной версии, поддерживаемой агентом) с последующей установкой nginx и модуля PT Cloud Application Firewall. Этот подход оказался проще, чем получение ISO-образа от вендора, его загрузка в наше облако и последующее развертывание машины.

К2 Cloud как раз предлагает готовый образ Debian со стандартными для облака улучшенными политиками безопасности. Поэтому мы установили агент на Debian 11 из deb-пакета, который можно скачать из репозитория Positive Technologies.

Первым шагом необходимо установить nginx определенной версии. Для агента на Debian 11 актуальна версия nginx — 1.22.0. При установке можно следовать официальной инструкции nginx, но с одним важным изменением. Вместо команды sudo apt install nginx в конце процесса нужно выполнить следующие действия:

• вывести все доступные версии подключенного apt- репозитория:
  apt-cache policy nginx

• скопировать строку с нужной нам версией. В нашем случае:
  1.22.0-1~bullseye

• установить nginx:
  sudo apt-get install nginx=1.22.0-1~bullseye

Далее перейти к настройке nginx. У нас было тестовое приложение даже без HTTPS, поэтому конфигурация nginx самая простая и выглядит так:

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

Тестирование и ложные срабатывания

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

Сформировали запрос в Burp. В параметр bcKey вставили нагрузку '};prompt('1');{' в формате URL encode и отправили запрос.

Видим в браузере следующее:

Ловим атаку на WAF. Видим, что обнаружена XSS в параметре bcKey.

Переводим WAF в режим блокировки.

Проводим атаку снова и видим, как она блокируется.

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

1. Отключали срабатывание по конкретному правилу.

2. Настраивали систему для исключения срабатываний по определенному пути.

3. При необходимости отключали ограничения по объему передаваемых данных, если это соответствовало логике работы приложения.

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

Из-за специфики веб-приложений невозможно создать универсальные правила защиты, как в случае с антивирусными базами. Поэтому ложные срабатывания — обычное явление, завязанное на особенности логики работы конкретного приложения. Как правило, они отрабатываются на этапе «обучения»‎ WAF.

Альтернативные решения

Таким образом, за два дня мы успешно защитили небольшое веб-приложение заказчика. Само развертывание и настройка WAF заняли минимум времени. В дальнейшем мы проведем тонкую настройку политик безопасности.

Мы использовали модель с личным кабинетом, расположенным в облаке вендора, и фильтрующей нодой в K2 Cloud. Однако этот пример — лишь один из многих способов решения подобных задач. Существуют различные варианты разделения зон ответственности между нами и заказчиком.

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

Задача состояла в интеграции WAF в эту существующую архитектуру. Мы выбрали решение Positive Technologies, но вместо облачного PT Cloud Application Firewall использовали on-premise- вариант — PT Application Firewall.

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

Этот подход позволил сохранить существующее распределение зон ответственности. Команда информационной безопасности не вмешивается в прямое взаимодействие между приложением и пользователями, а концентрируется на анализе событий и группировке, разделением между разными приложениями, подавлением срабатываний, написанием частных правил и так далее. Такой вариант обычно называют light on-prem, когда личный кабинет в облаке, а нода на месте, в ЦОДе заказчика.

«Самый облачный» вариант предполагает использование WAF, уже развернутого в нашей облачной инфраструктуре и обслуживающего множество клиентов. Он включает два ключевых компонента:

1. Личный кабинет в облаке вендора (например, в PT Cloud AF).

2. Партнерская нода — сервер в Облаке К2 с установленным агентом, через который проходит трафик клиентов.

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

1. Мультитенантная инсталляция, обслуживающая различных клиентов.

2. Распределение фильтрующих нод между клиентами.

3. Агенты отправляют данные не в облако вендора, а в выделенный сегмент K2 Cloud.

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

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

1. Профиль трафика.

2. Объем трафика.

3. Набор включенных проверок.

4. Специфика защищаемых веб-приложений.

Например, если веб-приложения часто работают с объемными файлами (документы Word, сложные XML-структуры), нода WAF затрачивает больше вычислительных ресурсов на их анализ. Поэтому точно предсказать нагрузку и трафик практически невозможно. Существуют синтетические тесты, но они не всегда отражают реальные условия эксплуатации и не могут служить надежной основой для оценки.

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

При наличии предварительных данных о высоких нагрузках или значительном объеме трафика мы применяем следующее решение:

1. Устанавливаем балансировщик нагрузки перед WAF.

2. Балансировщик распределяет трафик между несколькими фильтрующими узлами без проведения глубокого анализа.

3. При необходимости разворачиваем целую группу фильтрующих узлов.

4. Обеспечиваем привязку сессий к конкретным узлам для сохранения целостности обработки.

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

Финальный вариант в нашем арсенале — классическое on-premise-решение. В этом случае мы устанавливаем управляющую консоль WAF в облако или центр обработки данных заказчика.

Ключевые выводы об экспресс-развертывании WAF

WAF часто рекомендуется как универсальное решение для защиты веб-приложений. Однако важно подчеркнуть, что каждый проект уникален и требует индивидуального подхода. Наш сценарий быстрого развертывания PT Cloud Application Firewall, хотя и эффективен во многих случаях, — не панацея.

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

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

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

Если подытожить, схема экспресс-развертывания облачного WAF лучше всего подходит для защиты легковесных веб-приложений. Случаи с большим объемом трафика, архитектурными и комплаенс-ограничениями, необходимостью детальной проработки политики, кастомными реакциями или отправкой файлов на проверку в антивирус — другое дело. Их проще реализовать on-premise. Однако разбираться в деталях необязательно. Как правило, достаточно просто поставить задачу, а мы ответим готовым коммерческим предложением с подробным планом действий :)