Многие специалисты по инфобезопасноcти путают понятия «NGFW» и «WAF». Более того, этим грешат даже некоторые представители компаний — производителей продуктов, которые позиционируются как NGFW. Часто приходится слышать вопрос «у меня есть NGFW, нужен ли мне WAF?» или «зачем мне WAF?» В связи с этим созрело решение разобраться в причинах этой путаницы, раз и навсегда договориться о терминах и определить области применения каждого из понятий.
- Введение
- Причины путаницы
- Функциональные возможности и назначение WAF
- Что с атаками?
- Модель безопасности
- HTTPS и что с ним делать
- Что ещё не делает NGFW?
- Выводы
Введение
Начнём с самих аббревиатур, определяющих категории продуктов для обеспечения информационной безопасности: WAF является сокращением от Web Application Firewall, «межсетевой экран для веб-приложений», NGFW — от Next Generation Firewall, «межсетевой экран следующего поколения». Путаницу изначально вносит слово «Firewall», которое встречается в обоих терминах и изначально провоцирует на сравнение и противопоставление двух категорий продуктов. Однако WAF и NGFW не являются взаимозаменяемыми сущностями, служат для решения разных задач, размещаются в различных точках сети и в большинстве случаев администрируются разными командами.
Причины путаницы
NGFW является эволюцией традиционных межсетевых экранов и служит для разграничения доступа между сегментами сети. Реалии таковы, что термины «межсетевой экран» и «NGFW» сегодня взаимозаменяемы: когда говорят «firewall» — подразумевают NGFW.
Традиционные межсетевые экраны выполняют фильтрацию сетевого трафика с использованием таких параметров, как IP-адреса, идентификаторы сетевых протоколов, их атрибуты, такие как номера портов для TCP и UDP, типы сообщений ICMP и другие параметры трафика, относящиеся к уровням 3–4 модели ISO / OSI.
Чёткого определения NGFW в природе не существует, функциональность представленных на рынке реализаций имеет серьёзные отличия, но тем не менее мы можем сформулировать набор основных признаков, свойственных продуктам данной категории. NGFW дополняют возможности традиционных межсетевых экранов путём интеграции в себе функций VPN-шлюза, обнаружения и предотвращения вторжений (IPS) на основе сигнатур (шаблонов, по сути — регулярных выражений), инспекции трафика и проксирования протоколов уровня приложений с базовой проверкой их корректности и соответствия стандартам.
Именно функции IPS и инспекции трафика, реализованные в NGFW, являются одной из основных причин путаницы и источником вопроса «зачем мне WAF, если у меня уже есть NGFW?». Но «дьявол кроется в деталях», поэтому далее в этой статье рассмотрены отличия этих функций от того, что может и делает WAF.
Нельзя не упомянуть, что функции инспекции трафика NGFW в первую очередь предназначены для контроля действий внутренних пользователей при информационном обмене между сегментами защищаемой сети или выходе за пределы защищаемого периметра, в то время как WAF предназначен для защиты от злонамеренных внешних воздействий на защищаемые сервисы, и его механизмы, работающие в направлении «наружу», предназначены только для предотвращения утечек конфиденциальных данных как в результате внешних воздействий, так и вследствие ошибок в коде защищаемых приложений и сервисов. Иными словами, функции инспекции трафика NGFW в первую очередь применяются к трафику пользователей защищаемого периметра, а функции WAF — к трафику направленному к защищаемым веб-приложениям / сервисам.
Рисунок 1. Отличия WAF от NGFW
Функциональные возможности и назначение WAF
Особенности HTTP-трафика
Вкратце, WAF служит для защиты конкретных экземпляров веб-приложений / сервисов, использующих в качестве транспорта семейство протоколов HTTP. В реализациях некоторых производителей также присутствует поддержка других протоколов, таких как SMTP и FTP, но данная возможность не является определяющей для WAF и в данной статье не рассматривается. Основным «полем битвы» для WAF является трафик протоколов семейства HTTP.
Рассказ об области применения WAF будет неполным без понимания особенностей трафика, с которым приходится иметь дело, и того, каким угрозам необходимо противодействовать.
За тридцатилетнюю историю своего существования HTTP превратился из протокола для передачи содержимого статичных HTML-документов и изображений в транспортный протокол, не только поддерживающий инкапсуляцию различных структур данных, но и способный быть «подложкой» для других протоколов.
Рисунок 2. Пример структуры простого HTTP-запроса
Распространение HTML5 и фреймворков для браузеров, фактически превратившее последние в «толстые клиенты», проникновение мобильных устройств и приложений для них в повседневную жизнь современного человека привело к росту доли HTTP-трафика, относящегося к API-сервисам. Согласно отчёту 2019 года «Akamai 2019 State of the Internet / Security: Retail Attacks and API Traffic report», уже тогда 83 % HTTP-трафика в интернете составляли API-вызовы.
Адресация защищаемых сущностей
WAF защищает веб-приложения / сервисы, которые, как минимум, определяются IP-адресом (L3) и портом (L4), на котором они публикуются. В большинстве случаев область защищаемого веб-приложения / сервиса также характеризуется именем ресурса, которое передаётся клиентом в HTTP-запросе в стандартном заголовке «Host».
Итак, WAF работает с HTTP-трафиком, осуществляя анализ HTTP-запросов, адресованных конкретному экземпляру веб-приложения / API-сервиса, и ответов на них. При обнаружении нелегитимной активности WAF в зависимости от конфигурации либо блокирует запрос, либо протоколирует такую активность / передаёт информацию о ней в смежные системы, например SIEM.
Что с атаками?
Широкие возможности протокола HTTP породили не менее разнообразный набор атак на веб-приложения и сервисы. Наиболее значимые типы атак описываются в перечнях «OWASP Top Ten Web Application Security Risk» (для веб-приложений) и «OWASP API Security Top Ten» (для API-сервисов) от OWASP Foundation.
Противодействие таким атакам прежде всего требует декомпозиции HTTP-запроса до отдельных примитивов (заголовки, URI, параметры и их значения, составляющие многокомпонентных запросов) и анализа содержимого структур данных, вложенность которых не имеет теоретических ограничений, а также последующего анализа их элементов, что требует ресурсоёмких вычислений. Наглядным примером является передача данных в форматах JSON или XML.
Особо стоит выделить:
- атаки на бизнес-логику приложения, для противодействия которым требуется понимать нормальные поведенческие паттерны легитимного пользователя при работе с приложением;
- нелегитимные автоматизированные действия при помощи ботов по сбору информации, подбору паролей, обходу CAPTCHA и т. п.;
- распределённые атаки типа «отказ в обслуживании» на уровне приложения (L7 DDOS), в результате которых происходит исчерпание ресурсов инфраструктурных компонентов приложения.
Эффективно противодействовать таким атакам при помощи механизмов представленных в NGFW невозможно. Механизмы инспекции трафика имеют ограниченную функциональность, а применение IPS-сигнатур для анализа HTTP-трафика ведёт к большому количеству ложных срабатываний, и поэтому HTTP-сигнатуры по умолчанию отключены в IPS / NGFW большинства производителей.
Искушённый читатель может возразить, что сигнатурный анализ также применяется в большинстве WAF. В связи с этим нужно отметить следующее:
- сигнатуры в лидирующих WAF можно применять «точечно»: после декомпозиции содержимого запроса до элементарных составляющих сигнатура применяется к конкретному примитиву HTTP-протокола или передаваемых данных;
- несмотря на это, WAF-сигнатуры при применении «из коробки» дают существенный процент ложных срабатываний, поэтому требуют тщательного тестирования перед включением в режим блокировки вредоносных запросов.
Таким образом, сигнатуры в WAF являются лишь одним из многих механизмов противодействия атакам.
В завершение разговора о сигнатурах рассмотрим реальный пример уязвимости, против которой сигнатурный анализ неэффективен. Посредством отправки HTTP-запроса, содержащего JSON-данные, ключ или ключи, в которых содержатся метасимволы, злоумышленник может вызвать атаку типа «отказ в обслуживании».
Рисунок 3. Пример корректного JSON-кода
Вложенность в JSON теоретических ограничений не имеет. Предлагаем читателям описать регулярным выражением JSON-код, который содержит метасимволы в именах каких-либо ключей. Будет интересно.
Модель безопасности
Современные WAF сочетают в себе как негативную («чёрные списки»), так и позитивную («белые списки») модели безопасности. В качестве первой разновидности используются сигнатурный анализ и его более «продвинутые» варианты, где в дополнение к шаблонам и контекстам, в которых они применяются («как» — «где»), учитывают также источник атаки («кто» — «чем» — «откуда»), маскирование конфиденциальных данных, передаваемых от веб-приложения / сервиса в сторону клиента, а также запрет определённых примитивов протокола HTTP (например, URI). Позитивная модель безопасности с необходимой и достаточной детализацией для каждого экземпляра веб-приложения / сервиса описывает характеристики запросов и их содержимого, которые можно считать легитимными.
HTTPS и что с ним делать
Одним из стимулов широкого распространения протокола HTTP является его криптографически защищённая при помощи семейства протоколов TLS версия — HTTPS. Согласно данным отчёта Google Transparency Report, на конец февраля 2021 года от 77 до 98 % (в зависимости от клиентской платформы) страниц, загруженных браузером Chrome, были переданы по протоколу HTTPS.
Для того чтобы WAF мог выполнять анализ содержимого HTTPS-сессии, требуется её расшифровать. В недавнем прошлом, когда защита HTTPS-трафика основывалась на RSA-криптографии, для того чтобы получить доступ к содержимому HTTPS, достаточно было иметь соответствующий ключ, который использовался веб-приложением / сервисом, что позволяло обойтись без терминирования HTTPS-сессий на WAF, или использовать WAF в режиме «дорогой L7 IPS», работая с копией трафика.
Распространение TLS 1.3 и вариаций криптографических протоколов Диффи-Хеллмана сделало необходимым выполнение ресурсоёмкой операции терминирования HTTPS непосредственно на WAF. Таким образом, возможные ранее варианты установки WAF в режиме «моста» или для работы с копией трафика более неприменимы. WAF должен терминировать соединения и работать в режиме «полного прокси». Тем не менее для облачных WAF существуют компромиссные варианты, в которых терминирование трафика на WAF не производится, а с самого веб-приложения / сервиса на WAF направляется лог HTTP-запросов для анализа. Функциональность такого WAF сильно ограничена, а допустимость такого подхода либо определяется требованиями к безопасности приложения, либо остаётся на совести команды обеспечивающей защиту приложения / сервиса.
Что ещё не делает NGFW?
Реализации WAF, занимающие лидирующие позиции, кроме описанных ранее обладают следующими возможностями, которых нет в продуктах класса NGFW:
- защита сложных API-сервисов, таких как GraphQL;
- обнаружение автоматизированных HTTP-клиентов («ботов») и реагирование на те или иные категории автоматизированной активности согласно определениям политики безопасности;
- защита от распределённых атак типа «отказ в обслуживании» на уровне приложения (L7 DDOS);
- обнаружение попыток обхода CAPTCHA;
- обнаружение подстановки учётных данных («credential stuffing»);
- переадресация злоумышленника на honeypot-страницу (ловушку);
- создание политики защиты API путём загрузки файла — описания API.
Данный перечень является выборочным и приведён для демонстрации отличий задач, стоящих перед NGFW и WAF, и методов их решения.
Выводы
Несмотря на то что некоторые уважаемые производители NGFW утверждают, что «only those corporations that feel they have coding issues in their web applications need a WAF» («в WAF нуждаются только те организации, которые считают, что у них есть проблемы с кодом их веб-приложений»), можно однозначно сказать, что WAF вам нужен, если ваш бизнес зависит от устойчивой работы и безопасности ваших публичных веб-приложений / сервисов, которые используют ваши клиенты и партнёры, особенно если вы занимаетесь электронной коммерцией, если вы — банк и у вас, разумеется, есть онлайн-банкинг, а также во всех прочих случаях, когда нарушение информационной безопасности / работоспособности ваших веб-приложений может повлечь за собой значительные финансовые или репутационные потери.
Не следует исключать возможность того, что вам необходим WAF для ваших внутренних веб-приложений и сервисов: для крупных географически распределённых компаний ответом на вопрос «нужен ли мне WAF внутри сети?» в подавляющем большинстве случаев будет «да». Утвердительный ответ порождает в свою очередь множество других вопросов, на которые предстоит ответить прежде чем сделать выбор в пользу того или иного продукта и той или иной модели развёртывания WAF. Но это — уже другая история.
