Waf что это расшифровка аббревиатуры

WAF и / или NGFW? Договоримся о терминах

Многие специалисты по инфобезопасноcти путают понятия «NGFW» и «WAF». Более того, этим грешат даже некоторые представители компаний — производителей продуктов, которые позиционируются как NGFW. Часто приходится слышать вопрос «у меня есть NGFW, нужен ли мне WAF?» или «зачем мне WAF?» В связи с этим созрело решение разобраться в причинах этой путаницы, раз и навсегда договориться о терминах и определить области применения каждого из понятий.

Введение

Начнём с самих аббревиатур, определяющих категории продуктов для обеспечения информационной безопасности: 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.

Особо стоит выделить:

Эффективно противодействовать таким атакам при помощи механизмов представленных в NGFW невозможно. Механизмы инспекции трафика имеют ограниченную функциональность, а применение IPS-сигнатур для анализа HTTP-трафика ведёт к большому количеству ложных срабатываний, и поэтому HTTP-сигнатуры по умолчанию отключены в IPS / NGFW большинства производителей.

Искушённый читатель может возразить, что сигнатурный анализ также применяется в большинстве 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:

Данный перечень является выборочным и приведён для демонстрации отличий задач, стоящих перед NGFW и WAF, и методов их решения.

Выводы

Несмотря на то что некоторые уважаемые производители NGFW утверждают, что «only those corporations that feel they have coding issues in their web applications need a WAF» («в WAF нуждаются только те организации, которые считают, что у них есть проблемы с кодом их веб-приложений»), можно однозначно сказать, что WAF вам нужен, если ваш бизнес зависит от устойчивой работы и безопасности ваших публичных веб-приложений / сервисов, которые используют ваши клиенты и партнёры, особенно если вы занимаетесь электронной коммерцией, если вы — банк и у вас, разумеется, есть онлайн-банкинг, а также во всех прочих случаях, когда нарушение информационной безопасности / работоспособности ваших веб-приложений может повлечь за собой значительные финансовые или репутационные потери.

Не следует исключать возможность того, что вам необходим WAF для ваших внутренних веб-приложений и сервисов: для крупных географически распределённых компаний ответом на вопрос «нужен ли мне WAF внутри сети?» в подавляющем большинстве случаев будет «да». Утвердительный ответ порождает в свою очередь множество других вопросов, на которые предстоит ответить прежде чем сделать выбор в пользу того или иного продукта и той или иной модели развёртывания WAF. Но это — уже другая история.

Источник

Чем защищают сайты, или Зачем нужен WAF?

В этом году компанию Positive Technologies назвали «визионером» в рейтинге Gartner Magic Quadrant for Web Application Firewalls. Это вызвало ряд вопросов о том, за какие достижения мы туда попали и что такое WAF вообще. Вопросы вполне правомерные, ведь Gartner выпускает своё исследование WAF лишь с прошлого года (для примера: «квадранты» по SIEM стали выходить на пять лет раньше, в 2009 году). Кроме того, некоторые до сих пор путаются с терминологией, не отличая «экран для защиты веб-приложений» (WAF) от обычного «межсетевого экрана» (network firewall) или «системы предотвращения вторжений» (IPS).

В этой статье мы попробуем отделить мух от котлет — и рассказать, как идёт эволюция периметровой защиты по мере роста изощрённости атак.

1. В начале времён: пакетные фильтры

Изначально термин firewall (брандмауэр, экран) обозначал сетевой фильтр, который ставится между доверенной внутренней сетью и внешним Интернетом (отсюда прилагательное «межсетевой»). Этот фильтр был призван блокировать подозрительные сетевые пакеты на основе критериев низких уровней модели OSI: на сетевом и канальном уровнях. Иными словами, фильтр учитывал только IP адреса источника и назначения, флаг фрагментации, номера портов.

В дальнейшем возможности расширились до шлюзов сеансового уровня, или фильтров контроля состояния канала (stateful firewall). Эти межсетевые экраны второго поколения повысили качество и производительность фильтрации за счет контроля принадлежности пакетов к активным TCP-сессиям.

К сожалению, подобная система защиты практически бесполезна против современных кибер-угроз, где более 80% атак используют уязвимости приложений, а не уязвимости сетевой архитектуры и сервисов. Хуже того: блокирование определенных портов, адресов или протоколов (основной способ работы межсетевых экранов) может вырубить вполне легитимные приложения. Это значит, что защитная система должна проводить более глубокий анализ содержания пакетов — то есть лучше «понимать» работу приложений.

2. Системы обнаружения/предотвращения вторжений (IDS/IPS)

Следующим поколением защитных экранов стали системы обнаружения и предотвращения вторжений (IDS/IPS). Они способны изучать в TCP-пакетах поле данных и осуществлять инспекцию на уровне приложения по определённым сигнатурам. Системы IDS приспособлены к тому, чтобы выявлять атаки не только снаружи, но и внутри сети за счет прослушивания SPAN-порта коммутатора.

Для совершенствования защитных механизмов в IDS/IPS стали применяться декодеры (разбор полей TCP-пакета) и препроцессоры (разбор частей протокола уровня приложения, например, HTTP). Применение препроцессоров в IPS Snort позволило существенно улучшить функциональность периметровой защиты в сравнении с пакетным фильтром, даже если последний проверяет пакеты на уровне приложений (iptables с модулем layer7).

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

Параллельно для борьбы с распространением вирусов появляются прокси-серверы, а для решения задач балансировки нагрузки — обратные прокси-серверы. Они отличаются технически, но главное, что и те, и другие полноценно работают на уровне приложения: открывается два TCP соединения от прокси к клиенту и от прокси к серверу, анализ трафика ведётся исключительно на уровне приложения.

3. Всё в кучу: NGFW/UTM

Следующим шагом эволюции систем обнаружения вторжений стало появление устройств класса UTM (unified threat management, система единого управления угрозами) и NGFW (next generation firewall, экраны нового поколения).

Системы UTM отличаются от NGFW лишь маркетингом, при этом их функционал практически совпадает. Оба класса программных продуктов явились попыткой объединить функции различных продуктов (антивирус, IDS/IPS, пакетный фильтр, VPN-шлюз, маршрутизатор, балансировщик и др.) в одном устройстве. В тоже время, обнаружение атак в устройствах UTM/NGFW нередко осуществляется на старой технологической базе, при помощи упомянутых выше препроцессоров.

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

Но разница в технологической платформе — не единственное, что отличает защиту веб-приложений.

4. Защита Веба: что должен уметь WAF

Если говорить совсем просто, то веб-приложения отличаются от обычных приложений двумя вещами: огромным разнообразием и значительной интерактивностью. Это создаёт целый ряд новых угроз, с которыми традиционные межсетевые экраны не справляются: по нашим оценкам, в 2014 году 60% атак на корпоративные сети осуществлялись через веб-приложения, невзирая на наличие традиционных защитных средств.

Именно здесь вступает в дело Web Application Firewall (WAF), защитный экран для приложений, осуществляющих передачу данных через HTTP и HTTPS. Вот какие функции отличают WAF от защитных систем предыдущих поколений:

Теперь подробнее о том, что означают все эти пункты:

Multiprotocol Security

Будучи узкоспециализированным средством, WAF не защищает от проблем протоколов, отличных от HTTP/HTTPS. Но у любой медали две стороны. Многообразие способов обмена данными поверх протокола HTTP настолько велико, что ориентироваться в нём может только специализированное средство. Лишь для примера: где-то переменные и значения передаются в формате example.com/animals?dogs=32&cats=23, где-то в формате example.com/animals/dogs/32/cats/23, где-то передача параметров приложения осуществляется в Cookie, а где-то — в параметрах заголовка HTTP.

Кроме того, продвинутые модели WAF могут анализировать XML, JSON и другие протоколы современных порталов и мобильных приложений. В частности, это позволяет противодействовать большинству методов обхода защитного экрана (HPC, HPP, Verb Tampering и др).

IP Reputation

Технология IP-Reputation опирается на внешние чёрные и белые списки ресурсов, и одинаково доступна любым периметровым средствам защиты. Но ценность этого метода несколько преувеличена. Так, в практике наших специалистов случались ситуации, когда крупные новостные агентства в силу своих уязвимостей месяцами раздавали malware пользователям, и при этом не попадали в чёрные списки. К сожалению, вектора проникновения вредоносного ПО очень разнообразны, и в наши дни источником заражения для пользователей могут быть даже сайты органов государственной власти. А возможна и обратная проблема, когда по IP блокируются «невиновные» ресурсы.

Сигнатуры атак

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

Автоматическое обучение и поведенческий анализ

Для атак на веб-приложения злоумышленники активно используют уязвимости нулевого дня (0-day), что делает бесполезными сигнатурные методы анализа. Вместо этого нужно анализировать сетевой трафик и системные журналы для создания модели нормального функционирования приложения, и на основе этой модели выявлять аномальное поведение системы. WAF в силу своей архитектуры может разобрать весь сеанс связи пользователя, и потому способен на более углубленный поведенческий анализ, чем NGFW. В частности, это позволяет выявлять атаки с использованием автоматических средств (сканирование, подбор паролей, DDoS, фрод, вовлечение в ботнеты).

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

Защита пользователей

Периметровое оборудование, обсуждаемое в настоящей статье, предназначено для защиты серверов с веб-приложениями. Однако существует класс атак (например, CSRF) направленных на клиента веб-приложения. Поскольку трафик атаки не проходит через защитный периметр, на первый взгляд защитить пользователя оказывается невозможно.

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

К сожалению, разработчики ПО практически никогда так не делают. Однако некоторые WAF могут самостоятельно внедрять подобную защиту в веб-формы и защищать, таким образом, клиента – а вернее, его запросы, данные, URL и cookie-файлы.

Взаимодействие со сканерами уязвимостей

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

Лучшие образцы WAF имеют в своем распоряжении интегрированные сканеры уязвимостей, работающие в режиме чёрного ящика, или динамического анализа (DAST). Такой сканер может использоваться в режиме реального времени для быстрой проверки тех уязвимостей, которые «прощупывают» злоумышленники.

Виртуальный патчинг

Даже известные уязвимости невозможно устранить сразу: исправление кода требует средств и времени, а зачастую и остановки важных бизнес-процессов; иногда в случае использования стороннего ПО исправление невозможно вообще. Для парирования таких «частных» угроз в системах IDS/IPS, а по наследству в UTM/NGFW, применяются пользовательские сигнатуры. Но проблема в том, что написание такой сигнатуры требует от пользователя глубокого понимания механизма атаки. В противном случае пользовательская сигнатура может не только «пропустить» угрозу, но и породить большое количество ложных срабатываний.

В наиболее современных WAF используется автоматизированный подход к виртуальному патчингу. Для этого используется анализатор исходных кодов приложения (SAST, IAST), который не просто показывает в отчёте строки уязвимого кода, но тут же генерирует эксплойт, то есть вызов с конкретными значениями для эксплуатации обнаруженной уязвимости. Эти эксплойты передаются в WAF для автоматического создания виртуальных патчей, которые обеспечивают немедленное «закрытие бреши» ещё до исправления кода.

Корреляции и цепочки атак

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

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

Что дальше?

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

Источник