WAF или не WAF? Дайте два! Решаем вопрос защиты веб-приложений

Всем привет. Меня зовут Аскар Добряков, я ведущий эксперт направления защиты бизнес-приложений. Уже больше 15 лет занимаюсь ИБ и три из них –– защитой веб-приложений. За это время я часто сталкивался с неоднозначным отношением коллег к Web Application Firewall. В ИБ-сообществе мнения относительно защиты веб-приложений с помощью наложенных средств варьируются в диапазоне от «‎просто необходимы» до «нецелесообразная трата ресурсов, вполне можно обойтись встроенными средствами приложения».

Кто же прав? Чем полезен WAF, и какие у него недостатки? Давайте разберемся. Предупреждаю: тема непростая, но felix, qui potuti rerum cogoscere causas.

WAF (Web Application Firewall) — это межсетевой экран для веб-приложений. Его основная задача — фильтровать трафик, обнаруживать и блокировать атаки. 

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

Конечно, все понимают, что веб-приложения нужно защищать. Существует целый зоопарк угроз, тот же OWASP Top 10. Вопрос в том, как именно обеспечивать защиту — ресурсами самого приложения, или с помощью внешнего файрвола. Ведь WAF — платное решение, и его выбор, установка и эксплуатация требуют ресурсов и навыков.

Итак, стоит ли игра свеч?

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

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

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

Поскольку все запросы в такой архитектуре проходят через реверс-прокси, WAF должен выполнять функции публикации приложений:

1. Проводить балансировку между бэкендами в случае, если приложение работает на нескольких узлах. WAF проверяет работоспособность узлов, анализирует ответы приложения на наличие стоп-слов (error, maintenance) и переключает на работающие узлы при необходимости.

2. Отвечать за отказоустойчивость — это логичное следствие из функции балансировки.

3. Управлять политиками SSL — да так, чтобы SSLlabs выдал рейтинг А+, а клиенты при этом еще могли подключаться.

4. Управлять заголовками, включая Strict Transport Security и Cross-origin.

В результате мы получаем полноценную инфраструктуру публикации на базе Web Application Firewall. Такой подход характерен для зарубежных решений, например, F5 Big-ip и Citrix. Они выросли из балансировщиков, поэтому эти функции для них — базовые, а фильтрация запросов выступает как дополнительный модуль.

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

WAF выполняет ряд важных функций по верификации данных:

1. Проверка пользовательского ввода на несоответствие типов, наличие подозрительных конструкций и признаков атак.

2. Контроль доступа к URL и Endpoint для API, позволяющий разграничить доступ пользователей к функциям приложения. 

3. Проверка данных форм, JSON и XML —  контроль структуры данных, наличия внешних сущностей в XML, соответствия схемам и протоколам, а также защита от атак на парсер.

4. Контроль соответствия HTTP. WAF проверяет корректность методов, ответов приложения и их безопасность. Также с его помощью анализируется реакция приложения на некорректные запросы, например, коды ответов.

5. Обеспечение безопасности API. OWASP недавно опубликовал Top 10 для API Security, но самый наглядный пример — атаки на API. Например, вспоминается случай, когда в продукте зарубежного вендора можно было без авторизации выполнить RCE через API администрирования. Внешний контроль обращений к API помогает избежать подобных рисков.

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

Такая модель надежна, но требует тщательного обслуживания. Она может вызывать ложные срабатывания, например, при обновлении приложения без уведомления команды WAF.

3. Обнаружение атак

Обнаружение атак — важнейшая задача межсетевого экрана уровня приложений. Оно происходит благодаря сочетанию нескольких методов анализа:

1. По сигнатурам. WAF отсекает заведомо вредоносные запросы, ориентируясь на заранее выделенные паттерны. Это популярный метод, но он не идеален. Например, однажды, когда внедряли WAF одной компании, мы увидели в логах запрос «/../../somefile.txt», и какой-то файл. Очевидно, что это path traversal! Надо блокировать! Вот только через полчаса нам позвонил представитель заказчика и попросил: «Разрешите это, наше приложение так работает… Ну вот так когда-то его написали…».

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

3. Обнаружение ботов тоже часто выносится на WAF. Оно включает CAPTCHA, reCAPTCHA, Browser Challenge и даже проверки по User-Agent.

4. Защита от L7 DoS помогает противостоять логическим атакам на приложение, частым запросам от ботов, запросам к ресурсоемким страницам и функциям. WAF может контролировать и ограничивать такую активность. Эти функции сейчас также часто возлагают на WAF.

5. Виртуальные патчи позволяют быстро закрыть обнаруженные уязвимости, пока разработчики не выпустят исправление. WAF настраивается на блокировку запросов с характерными признаками эксплойта. Виртуальные патчи — временная мера, но они полезны для быстрого реагирования на угрозы.

   4. Видимость и наблюдаемость

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

   WAF помогает: 

   1. Логировать подозрительные действия.

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

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

   4. Сканировать и перепроверять атаки. Большинство WAF может создавать безопасные тестовые запросы для проверки потенциальных уязвимостей, заменяя подозрительный payload на безопасный индикатор.

   5. Анализировать ответы приложений для поиска уязвимостей и потенциально успешных атак. 

   Пример из практики: идет совершенно обычный запрос, никаких признаков атак, сигнатуры не срабатывают. В нем, прямо в query, содержится четыре параметра. WAF бьет тревогу: «‎В ответе приложения содержится пароль базы данных!‎». Это обнаруживает SOC, мы начинаем разбираться и пытаемся восстановить атаку.

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

5. Доверие 

Насколько мы уверены в безопасности приложения? Его разработала наша команда, сторонний подрядчик, или это известное рыночное решение? А может, оно досталось нам в наследство и уже 10 лет не поддерживается? Нужен ли нам дополнительный контроль трафика между приложением и внешними пользователями? Как быстро мы сможем устранить обнаруженную уязвимость? И как мы вообще узнаем о ее существовании?

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

Также в этот пункт же можно отнести формальное соответствие требованиям регуляторов и стандартам безопасности –  использование решения, которому доверяет регулятор.

Конкретные схемы применения WAF

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

1. Классическая схема: интернет-WAF-приложение

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

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

• идентификация пользователей;

• управление доступом;

• регистрация действий пользователей (именно внутри той логики приложения, которую мы, к сожалению, не можем повторить на WAF);

• патчи для закрытия уязвимостей;

• отказоустойчивость — без отказоустойчивого приложения никакой WAF не поможет.

На практике, в двухзвенной схеме WAF все, включая публикацию и верификацию, обычно находится в зоне ответственности подразделения информационной безопасности. 

Специалисты по ИБ также отвечают за дополнительные аспекты, такие как сжатие данных и настройка дополнительных заголовков, необходимых для работы приложения. Зона ответственности ИТ-отдела (эксплуатантов системы) в таком случае ограничивается поддержанием работоспособности самого приложения.

2. Лучше WAF может быть только два WAF

Мой любимый вариант 🙂 В такой схеме WAF располагаются друг за другом по цепочке, образуя многоуровневую защиту. Сначала, условно, фильтр грубой очистки, а затем фильтр тонкой очистки.

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

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

3. После прохождения обоих уровней WAF трафик поступает на защищаемые приложения, которые имеют свои встроенные механизмы безопасности.

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

В такой схеме часто наблюдается следующее разделение обязанностей: за публикацию приложения отвечает департамент телекоммуникаций (подразделение, занимающееся сетями и взаимодействием с интернетом). Отдел ИБ сосредотачивается на специфической защите на втором узле WAF, а ИТ продолжает поддерживать и эксплуатировать приложение.

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

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

В некоторых случаях организации уже имеют настроенную систему публикации приложений. Это могут быть различные решения: Nginx, Envoy, Kubernetes с ингресс-контроллером и так далее. Получается достаточно сложная схема, которая может быть основана на принципах Infrastructure-as-Code, и что-то менять в ней, добавлять еще один хоп или реверс-прокси — очень проблематично.

В таких ситуациях оптимальным решением может стать WAF, встроенный непосредственно в систему публикации приложений.

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

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

4. Совсем без WAF

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

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

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

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

Выводы

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

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

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