Web application firewall что это
Web Application Firewall: проблемы выбора и перспективы развития
Являются ли системы класса WAF обязательным стандартом для обеспечения безопасности веб-ресурсов или же остаются важной, но дополнительной опцией? Как выбрать и внедрить Web Application Firewall и что ждёт рынок в будущем? Об этом рассуждают представители вендоров, сервис-провайдеров и крупных заказчиков в рамках онлайн-конференции AM Live.
Введение
Очередной выпуск онлайн-конференции AM Live был посвящён системам стоящим на страже веб-ресурсов — решениям класса Web Application Firewall. Для того чтобы разобраться, что такое WAF, какие функции этих систем наиболее востребованны и как избежать проблем при внедрении, мы пригласили в студию ведущих экспертов рынка информационной безопасности. Предлагаем вашему вниманию ключевые тезисы прямого эфира, длившегося более двух часов.
В дискуссии приняли участие:
Ведущий и модератор дискуссии — Андрей Дугин, начальник отдела обеспечения информационной безопасности компании МТС.
Для чего нужен Web Application Firewall
В первую очередь мы спросили у наших экспертов, кому и зачем нужен WAF. Модератор дискуссии предложил поговорить о том, чем этот класс средств защиты отличается от обычных файрволов, в том числе — нового поколения (Next Generation Firewall, NGFW). Не проще ли вместо использования WAF банально поддерживать безопасность сайта — устанавливать актуальные патчи, устраивать пентесты и т. д.?
Виктор Рыжков:
— Сейчас легче перечислить тех, кому WAF не нужен: Web Application Firewall не нужен только тогда, когда у компании просто нет веб-ресурсов или эти ресурсы не жалко потерять. WAF помогает защитить веб-ресурсы, если они являются основой бизнеса, если они используются как хранилище персональных данных или другой критической информации или если они связаны с инфраструктурой компании и могут послужить точкой входа для злоумышленников.
Вячеслав Алешин:
— WAF поможет защитить заказные решения, используемые компаниями. Такие системы нередко содержат уязвимый код и могут представлять угрозу безопасности компании.
Иван Новиков:
— WAF занимается защитой на седьмом уровне по модели OSI. Такой межсетевой экран анализирует запросы, которые не контролирует ни обычный файрвол, ни NGFW. Помимо сайта WAF защищает веб-серверы приложений, контролирует интеграции со сторонними сервисами, а также отрабатывает угрозы не связанные с уязвимостями — такие как DDoS-атаки.
Вячеслав Гордеев:
— Существуют два принципиальных отличия WAF от других межсетевых экранов: функциональное и архитектурное. К функциональным особенностям можно отнести возможность разбора специализированных форматов внутри HTTP (например, JSON), чего не делают NGFW и другие системы. Архитектурные особенности — это способ внедрения и установки в сеть. Web Application Firewall работает в первую очередь как реверс-прокси, публикуя только те приложения, которые находятся внутри компании.
Михаил Кондрашин:
— Если говорить образно, WAF — это продукт, который позволяет эксплуатировать уязвимый веб-сайт так, чтобы его не взломали. Что касается размещения, то NGFW устанавливается на шлюзе, а WAF — там, где находится веб-сайт.
Александр Баринов:
— Каждая компания приходит к пониманию, нужен ли ей WAF или нет, следующим образом: если это большая и зрелая компания, ты понимаешь, как это делать — как обеспечить безопасную разработку, прикручиваешь свою частную облачную историю. Если же ты — какой-то не вполне зрелый стартап, со временем понимаешь, что вот здесь у меня могут украсть интеллектуальную собственность, тут — уронить сайт или сделать не доступным какой-то функционал. В какой-то момент просто осознаёшь, что отвлекаешься от бизнеса, и здесь на смену приходит готовое WAF-решение.
Гости студии отметили, что NGFW, обычный файрвол или IPS — это многопротокольные устройства, в то время как WAF «заточен» на протоколы веб-приложений, которые используют HTTP как транспорт. За счёт более глубокого анализа специализированных протоколов такое решение показывает большую эффективность в определённой нише. Важно, что WAF «знает», какие конкретно приложения он защищает. В зависимости от того, на какой объект направлен трафик, такой файрвол может применять различные политики безопасности.
Возможно ли использовать опенсорс-решения в этой сфере? По мнению экспертов, такой подход имеет право на жизнь, но сопряжён с большими трудностями. Как отметили наши спикеры, в этом случае компания по сути становится разработчиком собственного решения и должна решать вопросы не только его развития, но и техподдержки.
Ещё одна тема, которую затронули гости студии, — варианты размещения Web Application Firewall. Имеет ли смысл использовать локальный (on-premise) вариант или лучше подписаться на облачный сервис? Как отметили эксперты AM Live, в данном случае это — вопрос доверия к облачному провайдеру, поставщику услуги. Сейчас рынок безопасности веб-приложений активно мигрирует в облако, а значит, всё больше и больше заказчиков считают риски таких сервисов приемлемыми для себя.
В ходе прямого эфира мы спросили зрителей онлайн-конференции о том, используют ли они WAF в своей компании. Положительно ответил на этот вопрос 51 % респондентов. Не используют системы безопасности этого класса 49 %.
Рисунок 1. Используете ли вы WAF в своей организации?
Наши эксперты обсудили преимущества и недостатки готовых программно-аппаратных комплексов WAF и сугубо «софтверных» решений. Как отметили собравшиеся в студии специалисты, разработки под определённое «железо» могут работать эффективнее универсальных систем, эксплуатируемых на любом оборудовании. Другой стороной медали является желание заказчика работать на определённых, уже имеющихся у него аппаратных платформах. При этом не стоит забывать об «организационно-бюрократическом» аспекте этой проблемы — иногда департаменту информационной безопасности проще купить комплексное программно-аппаратное решение, чем проводить приобретение по двум разным статьям бюджета.
Технические особенности WAF
Базовую структуру «типового» решения класса Web Application Firewall обрисовал Вячеслав Гордеев. Как сказал эксперт, у каждого WAF есть набор модулей защиты, по которым проходит весь трафик. Обычно всё начинается с базовых уровней — модулей защиты от DDoS-атак и блоков сигнатурного анализа. Уровнем выше стоит возможность разработки своих собственных политик безопасности, а также подсистема математического обучения. На одном из последних этапов обычно появляется блок интеграции со сторонними системами.
Ещё одной важной частью WAF является пассивный или активный сканер, который на основании ответов сервера и опроса конечных точек может выявлять уязвимости. Некоторые файрволы способны детектировать мошенническую активность на стороне браузера.
Переходя к вопросу о технологиях детектирования атак, эксперты отметили, что есть две принципиально разные задачи: валидация (проверка данных в конкретных запросах) и поведенческий анализ. Для каждой из этих моделей применяется свой собственный набор алгоритмов. Если же взглянуть на работу WAF в разрезе стадий обработки запроса, то можно отметить блок парсеров, модули декодирования (не путать с дешифрованием) и набор правил блокировки, отвечающих за итоговый вердикт. Помимо этого, есть ещё один слой — политики безопасности, которые разрабатываются людьми или на основании алгоритмов машинного обучения.
Обсуждая работу Web Application Firewall с контейнерами, спикеры заметили, что отличия могут быть только в способе развёртывания, а принципы работы остаются прежними. В среде контейнеризации WAF может быть развёрнут разными способами — например, выступать в роли IP-шлюза, фильтруя все запросы на вход в среду виртуализации. Кроме того, WAF может работать как контейнер и быть интегрирован с шиной передачи данных.
Отвечая на вопрос «Что, на ваш взгляд, наиболее важно при выборе WAF?», большинство зрителей прямого эфира AM Live отметили в качестве ключевого фактора технологии обнаружения атак. За этот вариант проголосовали 63 % респондентов. Интеграцию с другими средствами защиты считают наиболее важной функцией WAF 12 % опрошенных, а стоимость — 9 %. За варианты «Модель поставки» и «Сертификация» высказались 2 % и 3 % соответственно. Другие факторы считают наиболее важными 11 % участников опроса.
Рисунок 2. Что, на ваш взгляд, наиболее важно при выборе WAF?
В завершение второго блока прямого эфира эксперты обсудили возможность предоставления сервиса WAF по модели SaaS, а также способы оценки эффективности работы файрвола. Как отметили наши спикеры, SaaS — это предоставление полного доступа к приложению и его администрированию в облаке. Каких-то значительных преимуществ этот подход не несёт, но он является первым шагом к переносу инфраструктуры в облако. Если компания делегирует провайдеру и эксплуатацию системы, то речь идёт скорее о модели MSSP, которая может дать некоторую выгоду. Оценить эффективность WAF поможет пентест, который заказчик может провести во время пилотирования проекта. Помимо этого, вендоры и системные интеграторы могут предоставлять клиенту регулярные отчёты по работе файрвола, демонстрирующие результаты анализа трафика.
Как внедрять Web Application Firewall
Следующая часть онлайн-конференции была посвящена вопросам внедрения WAF. Для начала Андрей Дугин как представитель крупной компании-заказчика рассказал о том, на что тратится время при внедрении WAF локально.
По мнению модератора дискуссии, основные этапы внедрения файрвола — следующие:
Михаил Кондрашин отметил, что внедрение сервиса WAF в одно приложение занимает полторы минуты. Эксперт пояснил, что речь идёт только о мониторинге: настройка правил блокировок займёт дополнительное время. При этом другие спикеры онлайн-конференции указали, что подразумевается «чистое» время, которое не включает многие аспекты внедрения — согласования, обучение персонала и другие этапы. Иван Новиков подчеркнул, что время внедрения зависит от способа развёртывания, а также от конкретного приложения и от трафика, который необходимо контролировать.
Гости студии рассказали также о том, как правильно построенный процесс внедрения поможет уменьшить процент ложных срабатываний WAF. Виктор Рыжков отметил, что решить эту задачу поможет тестирование на подготовительном этапе (pre-production), а также после ввода системы в эксплуатацию. Эксперт отметил важность возможности «обучения» файрвола, когда на этапе теста часть вердиктов корректируется специалистом. Александр Баринов порекомендовал изучить статистику работы WAF за первый месяц работы, чтобы понять, не блокирует ли система легитимный трафик. Вячеслав Алешин подчеркнул, что не бывает WAF полностью исключающих ложные срабатывания.
Спикеры перечислили также основные направления интеграции Web Application Firewall с другими средствами безопасности. По мнению экспертов, это:
Зрители AM Live высказали свои мнения о том, что больше всего тормозит внедрение WAF. Почти треть опрошенных (32 %) отметила, что главным препятствием для успешного внедрения являются ложные срабатывания. Ещё 21 % указал на сложность администрирования, а 18 % — на высокую цену. Снижение производительности веб-сайта отметили 5 % респондентов, а 4 % пожаловались на недостаточную масштабируемость. Не видят препятствий для внедрения и используют WAF 20 % опрошенных.
Рисунок 3. Что, на ваш взгляд, тормозит внедрение WAF больше всего?
Тренды и прогнозы развития рынка WAF
В заключение беседы эксперты в студии поделились своим видением перспектив развития рынка Web Application Firewall. Спикеры отметили рост популярности различных открытых WebAPI и предсказали смещение фокуса защиты в их сторону; у Gartner даже есть определения для таких продуктов — Web Application & API Protection (WAAP). Из-за пандемии зависимость от онлайна выросла драматическим образом, поэтому важность WAF возрастёт, его наличие может стать обязательным условием безопасности веб-ресурса. Участники онлайн-конференции отметили, что WAF станет «ближе» к приложениям и будет встроен в процесс их разработки.
Говоря о технологических тенденциях развития систем класса WAF, эксперты предсказали внедрение в WAF систем искусственного интеллекта и многоуровневого машинного обучения. Будут усилены возможности обнаружения неизвестных угроз, а также активизируется использование предварительно сгенерированных моделей, созданных внутри компании. Помимо этого, спикеры AM Live отметили вероятное развитие механизмов фильтрации, основанных на поведенческих факторах.
С точки зрения развёртывания продолжатся миграция WAF в облака и интеграция систем этого класса с другими облачными сервисами. Эксперты отметили тенденцию к открытости систем безопасности, которая затронет и WAF; это — ответ на запросы рынка, выгодный как покупателям, так и вендорам.
Финальный опрос зрителей онлайн-конференции был посвящён мнению нашей аудитории относительно WAF по итогам эфира. Почти треть опрошенных (29 %) после просмотра очередного выпуска AM Live убедились в правильности своего выбора WAF. Ещё 16 % респондентов заинтересовались и готовы тестировать эти средства безопасности. Считают WAF избыточным для себя 13 % участников опроса, а 3 % зрителей в результате решили сменить поставщика WAF.
Не поняли, о чём шла речь во время прямого эфира, 32 % наблюдавших за ним, а 7 % опрошенных считают, что участники не смогли доказать необходимость использования WAF.
Рисунок 4. Каково ваше мнение относительно WAF по итогам эфира?
Выводы
Дискуссия показала, что Web Application Firewall является ключевым элементом безопасности современных веб-ресурсов. Рост числа критически важных задач, выполняемых посредством веб-интерфейсов и открытых API, является драйвером рынка систем безопасности этого класса. Сегодня заказчик может выбирать: самостоятельно развёртывать WAF на собственной инфраструктуре, встраивать в неё готовые программно-аппаратные комплексы или же использовать облачные сервисы.
Важным трендом является интеграция WAF — как с другими системами информационной безопасности, так и с процессом разработки сайтов. Необходимость встраивания такого файрвола в процесс DevSecOps не раз отмечали приглашённые нами эксперты.
Web Application Firewall: работа на опережение
В одном из предыдущих постов мы рассказывали об отражении DDoS-атак при помощи анализа трафика по протоколу Netflow. Само собой, DDoS — далеко не единственная проблема, с которой может столкнуться ресурс. Воображение злоумышленников весьма и весьма велико, да и технических средств у них хватает. Плюс не стоит забывать о том, что какой-то из ваших ресурсов вполне может работать на ПО с zero-day-уязвимостями.
Вот и получается, что веб-приложение может подвергнуться атаке сразу с нескольких фронтов — тут вам и межсайтовый скриптинг, и SQL-инъекции, и обход авторизации, и удаленное выполнение кода, в общем, вы знаете. В извечной борьбе щита и меча против подобного и был придуман защитный экран для веб-приложений, отлавливающий подобные активности и блокирующий их ещё до выполнения на вашем сайте.
В этом посте мы расскажем, как работает WAF от Билайн Бизнес, какие у него есть преимущества и как его оперативно подключить для своей компании.
Зачем вообще нужен WAF
В прошлом году компания Positive Technologies выпустила своё исследование «Уязвимости веб-приложений 2019», согласно которому доля веб-приложений, содержащих уязвимости высокого уровня риска, составила уже 67%. Самые частые проблемы — недостаточно защищенная зона авторизации, SQL-инъекции и чтение произвольных данных. Плюс растёт процент систем, в которых возможна утечка данных.
О важности защиты веб-приложений говорит и один из отчётов аналитиков Gartner:
Основные различия WAF, IPS и NGFW (Gartner)
Последствия подобных утечек и взломов довольно очевидны и не очень приятны для компаний (и их клиентов особенно): здесь тебе и личные данные, включая платежную информацию, и коммерческие тайны с конфиденциальными документами, и доступы ко внутренним системам. В общем, джекпот, в случае срыва которого компания страдает и репутационно, и материально. Ожидаемо, сильнее всего от подобного страдают финансовые организации, но не только:
По данным Positive Technologies
Для защиты от подобного в компаниях и существуют специалисты по информационной безопасности, определяющие допустимость использования того или иного софта, а также общие политики безопасности. При этом общие тенденции — рост числа самих приложений, активное использование различных API, работа в условиях смешанной среды (in-house-приложения, частные и облачные) активно намекают, что многие процессы стоит автоматизировать.
Особенно в области информационной безопасности.
Основные проблемы для компаний при попытках развернуть подобные решения самостоятельно заключались в том, что время реакции на активную угрозу было довольно большим, как и стоимость владения самим решением. Хотелось, как обычно — чтобы и побыстрее, и подоступнее. А в идеале ещё и с облачной версией решения, которую можно быстро подключить и комфортно администрировать.
Поэтому мы решили предлагать именно автоматизированные механизмы защиты, блокировки и отражения атак с помощью нашего защитного экрана.
Прежде всего, мы взяли список 10 самых главных угроз для веб-приложений 2020 от OWASP и осуществили защиту от них по обеим моделям (позитивная и негативная).
Конечно, здесь же есть отражение атак нулевого дня, включая и HTTPS, а также блокировка трафика по географическому признаку.
Кроме того, наш WAF поддерживает уникальный алгоритм автоматического создания политик на базе машинного обучения, который как нельзя лучше подходит для автоматического создания политик безопасности для веб- приложения.
Настроенный WAF будет хорошо знать структуру именно вашего ресурса, поэтому сможет автоматически блокировать любые нетипичные для его работы действия.
Кстати, есть парочка мифов насчёт избыточности самой сути WAF и его необходимости. Обычно приводят в пример вот что:
Шлюз безопасности и мониторинг сессий меня защитит
Веб-приложения должны быть доступны всем, поэтому остается только разрешить весь входящий трафик на порты 80 (HTTP) и 443 (HTTPS) и надеяться, что все будут играть по правилам. Мониторинг сессий на наличие, идентификацию и блокирование исполняемого кода не заменяет анализ трафика веб-приложений, поэтому эксплуатация уязвимости посредством легитимного веб-запроса не составляет труда при наличии шлюза безопасности «всё в одном».
Тогда точно защитит сетевой сканер защищенности веб-приложений
Не совсем. Сетевые сканеры безопасности предназначены для выявления небезопасных конфигураций, отсутствия необходимых обновлений и наличия уязвимостей серверов и сетевых устройств, а не уязвимостей веб-приложений. Архитектура решений, огромное количество правил и признаков, подлежащих проверке при сканировании сети, все же иногда позволяют производителям сетевых сканеров предлагать дополнительную функциональность по поиску уязвимостей веб-приложений в рамках отдельной лицензии или даже бесплатно.
Но удобство использования и качество их работы далеки даже от среднего уровня профессиональных сканеров веб-приложений, и доверие к таким продуктам не может быть восстановлено после нахождения критических уязвимостей там, где универсальный сканер отработал на 100%.
Как всё работает
Мы построили решение на оборудовании израильской компании Radware, которая долгое время остается лидером в области услуг информационной безопасности. Один из важных плюсов решения — именно автоматическая работа: анализ угроз и оптимизация стандартизированных правил для веб-приложений осуществляются без участия администратора.
Есть три способа подключения, которые определяются тем, где решено проводить анализ трафика:
Кроме трёх вариантов подключения, есть и два варианта развертывания:
Преимущества решения
В рамках нашего защитного экрана для веб-приложений мы предлагаем лучшее в своем роде решение, которое:
Обычно единичной услугой считается подключение WAF на определённый сайт клиента. В нашем случае, если у клиента, допустим, два сайта на одном сервере, которые доступны с двух разных IP, мы всё равно считаем это как одну услугу предоставления 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. Но это — уже другая история.