web application firewall что это
Эволюция Web Application Firewall: от сетевых экранов до облачных систем защиты с машинным обучением
В нашем прошлом материале по облачной тематике мы рассказывали, как защитить ИТ-ресурсы в публичном облаке и почему традиционные антивирусы не совсем подходят для этих целей. В этом посте мы продолжим тему облачной безопасности и поговорим об эволюции WAF и о том, что лучше выбрать: железо, ПО или облако.
Что такое WAF
Более 75% атак хакеров направлены на уязвимости веб-приложений и сайтов: такие атаки, как правило, незаметны для ИБ-инфраструктуры и ИБ-служб. Уязвимости веб-приложений несут в себе, в свою очередь, риски компрометации и фрода учетных записей и персональных данных пользователей, паролей, номеров кредитных карт. Кроме того, уязвимости в веб-сайте служат точкой входа злоумышленников в корпоративную сеть.
Web Application Firewall (WAF) представляет собой защитный экран, который блокирует атаки на веб-приложения: SQL-инъекции, межсайтовый скриптинг, удаленное выполнение кода, брутфорс и обход авторизации (auth bypass). В том числе атаки, использующие zero-day уязвимости. Файрволы приложений обеспечивают защиту, выполняя мониторинг содержимого веб-страниц, включая HTML, DHTML и CSS, и фильтруя потенциально вредоносные запросы по HTTP/HTTPS.
Какими были первые решения?
Первые попытки создать Web Application Firewall предпринимались еще в начале 90-х годов. Известно как минимум о трех инженерах, работавших в этой области. Первый — профессор компьютерных наук Джин Спаффорд из Университета Пердью. Он описал архитектуру файрвола приложений с прокси и в 1991 году опубликовал её в книге «Безопасность UNIX на практике».
Вторым и третьим — были ИБ-специалисты Уильям Чесвик и Маркус Ранум из Bell Labs. Они разработали один из первых прототипов файрволов приложений. Его распространением занималась компания DEC — продукт выпустили под названием SEAL (Secure External Access Link).
Но SEAL не являлся полноценным WAF-решением. Он представлял собой классический сетевой файрвол с расширенной функциональностью — возможностью блокировать атаки на FTP и RSH. По этой причине первым WAF-решением сегодня считается продукт компании Perfecto Technologies (позже Sanctum). В 1999 году она представила систему AppShield. В то время Perfecto Technologies занимались разработкой ИБ-решений для e-commerce, и целевой аудиторией их нового продукта стали онлайн-магазины. AppShield умел анализировать HTTP-запросы и блокировал атаки на основе динамических ИБ-политик.
Примерно в одно время с AppShield (в 2002 году) появился первый WAF с открытым исходным кодом. Им стал ModSecurity. Он создавался с целью популяризации WAF-технологий и поддерживается IT-сообществом до сих пор (вот его репозиторий на GitHub). ModSecurity блокирует атаки на приложения, основываясь на стандартном наборе регулярных выражений (сигнатур) — инструментов для проверки запросов по шаблону — OWASP Core Rule Set.
В итоге разработчикам удалось добиться своей цели — на рынке начали появляться новые WAF-решения, в том числе построенные на базе ModSecurity.
Три поколения — уже история
Принято выделять три поколения WAF-систем, эволюционировавших по мере развития технологий.
Первое поколение. Работает с регулярными выражениями (или грамматиками). К нему относится ModSecurity. Поставщик системы изучает типы атак на приложения и формирует паттерны, которые описывают легитимные и потенциально вредоносные запросы. WAF сверяется с этими списками и решает, что делать в конкретной ситуации, — блокировать трафик или нет.
Примером обнаружения на основе регулярных выражений является уже упомянутый проект Core Rule Set с открытым исходным кодом. Еще пример — Naxsi, который также является опенсорсным. Системы с регулярными выражениями имеют ряд недостатков, в частности, при обнаружении новой уязвимости администратору приходится создавать дополнительные правила вручную. В случае с масштабной IT-инфраструктурой правил может быть несколько тысяч. Управлять таким количеством регулярных выражений довольно сложно, не говоря о том, что их проверка может снижать производительность сети.
Также регулярные выражения имеют довольно высокий уровень ложных срабатываний. Знаменитый лингвист Ноам Хомский предложил классификацию грамматик, в которой разделил их на четыре условных уровня сложности. Согласно этой классификации, регулярными выражениями можно описать только правила файрвола, которые не предполагают отклонений от шаблона. Это означает, что злоумышленники могут легко «обмануть» WAF первого поколения. Один из методов борьбы с этим — добавить в запросы к приложениям специальные символы, которые не влияют на логику вредоносных данных, но нарушают сигнатурное правило.
Второе поколение. Чтобы обойти проблемы, связанные с производительностью и точностью WAF, были разработаны файрволы приложений второго поколения. В них появились парсеры, которые отвечают за выявление строго определенных типов атак (на HTML, JS и т. д.). Эти парсеры работают со специальными токенами, описывающими запросы (например, variable, string, unknown, number). Потенциально вредоносные последовательности токенов выносятся в отдельный список, с которым регулярно сверяется WAF-система. Впервые этот подход показали на конференции Black Hat 2012 в виде C/C++ библиотеки libinjection, которая позволяет выявлять SQL-инъекции.
По сравнению с WAF первого поколения, специализированные парсеры могут работать быстрее. Однако они не решили трудности, связанные с ручной настройкой системы при появлении новых вредоносных атак.
Третье поколение. Эволюция в логике обнаружения третьего поколения заключается в применении методов машинного обучения, позволяющих максимально приблизить грамматику обнаружения к реальной грамматике SQL/HTML/JS защищаемых систем. Данная логика обнаружения в состоянии адаптировать машину Тьюринга для охвата рекурсивно перечисляемых грамматик. Причем ранее задача создания адаптируемой машины Тьюринга была неразрешимой, пока не были опубликованы первые исследования нейронных машин Тьюринга.
Машинное обучение предоставляет уникальную возможность адаптировать любую грамматику для охвата любого типа атак без создания списков сигнатур вручную, как это требовалось при обнаружении первого поколения, и без разработки новых токенизаторов/парсеров для новых типов атак, таких как внедрения Memcached, Redis, Cassandra, SSRF, как того требовала методология второго поколения.
Объединяя все три поколения логики обнаружения, мы можем нарисовать новую диаграмму, на которой красным контуром представлено третье поколение обнаружения (рис. 3). К этому поколению относится одно из решений, которое мы реализуем в облаке совместно с «Онсек», разработчиком платформы адаптивной защиты веб-приложений и API Валарм.
Теперь в логике обнаружения используется обратная связь от приложения для самонастройки. В рамках машинного обучения этот цикл обратной связи называется «подкрепление». Как правило, существует один или несколько типов такого подкрепления:
Далее рассмотрим технологические возможности различных вариантов реализации WAF.
Железо, ПО или облако — что выбрать?
Один из вариантов реализации файрволов приложений — «железное» решение. Такие системы представляют собой специализированные вычислительные устройства, которые компания устанавливает локально в своем дата-центре. Но в этом случае приходится закупать собственное оборудование и платить деньги интеграторам за его настройку и отладку (если у компании нет собственного ИТ-отдела). При этом любое оборудование устаревает и приходит в негодность, поэтому заказчики вынуждены закладывать бюджет для обновления аппаратного обеспечения.
Другой вариант развертывания WAF — программная реализация. Решение устанавливается в качестве дополнения для какого-либо ПО (например, ModSecurity настраивается поверх Apache) и работает на одном сервере с ним. Как правило, подобные решения можно развернуть как на физическом сервере, так и в облаке. Их минус — это ограниченные возможности масштабируемости и поддержки со стороны вендора.
Третий вариант — настройка WAF из облака. Такие решения предоставляются облачными провайдерами в качестве сервиса по подписке. Компании не нужно приобретать и настраивать специализированное железо, эти задачи ложатся на плечи поставщика услуги. Важный момент — современный облачный WAF не подразумевает миграцию ресурсов на платформу провайдера. Сайт может быть развернут в любом месте, даже on-premise.
Почему сейчас все чаще смотрят в сторону облачного WAF, расскажем далее.
Что может WAF в облаке
С точки зрения технологических возможностей:
Теперь немного об особенностях облачных WAF с точки зрения организационных моментов и управления:
Текст подготовил Александр Карпузиков, менеджер по развитию продуктов ИБ облачного провайдера #CloudMTS.
Web Application Firewall — специализированная защита веб-приложений
В недавнем отчете, посвященном глобальным угрозам интернет-безопасности, компания Symantec указала, что злоумышленники при атаках на веб-сайты используют уязвимости серверных веб-приложений, либо уязвимости самой операционной системы, на которой работают такие приложения.
Основной целью киберпреступников обычно являются различные финансовые организации: банки, страховые компании, онлайн-площадки e-commerce. При этом главной точкой «входа» для хакера нередко становится именно веб-приложение, притом сам веб-ресурс может быть любой направленности. Попытаться взломать систему защиты сегодня может даже пользователь, не особо осведомленный в этой области — ведь описание технологии хакинга и все нужные для этого средства доступны в интернете, а значит их можно найти с помощью обычных поисковиков.
Почему именно WAF?
В подавляющем большинстве атак на веб-сайты злоумышленники эксплуатируют уязвимости не сетевой инфраструктуры, а приложений. Притом даже если в компании установлены антивирус и брандмауэр, эти средства не очень результативны в предотвращении подобных угроз.
Для качественной защиты лучше прибегнуть к иному методу, предусматривающему глубинный анализ контента пакетных данных и учет особенностей структуры веб-приложений, и таким средством является Web Application Firewall (WAF) — специализированный файрвол, предназначенный для анализа данных, передаваемых по протоколам HTTP и HTTPS. 
Чтобы детектировать кибератаку, межсетевой экран для веб-приложений использует два ключевых подхода: сигнатурный и поведенческий. Именно работа этих двух технологий в комплексе способна обеспечить высокий уровень защиты, ведь в атаках на веб-сайты хакеры могут задействовать так называемые уязвимости нулевого дня (zero-day), которые делают совершенно неэффективным сигнатурный подход. Вместе с тем, поведенческий метод постоянно анализирует, как работает приложение, путем детального анализа сетевого трафика и системных журналов. Если наблюдаются существенные отклонения — срабатывает система предупреждения и защиты.
Кстати, гигантский объем ложных реакций на различные подозрительные события относят к одному из минусов обычного файрвола. Ведь из-за этого очень непросто понять реальную степень угрозы — во множестве уведомлений приходится «копаться»» вручную. В то же время Web Application Firewall в автоматическом режиме анализирует десятки и даже сотни событий, после чего выводит данные о развитии атаки — от начала и до конца.
Следует отметить, что многие Web Application Firewall поддерживают контроль шифрованного трафика SSL, передаваемого по протоколам HTTP и HTTPS.
Критерии выбора продукта
Сегодня системы защиты веб-приложений пользуются спросом в компаниях различного размера, поэтому большинство именитых мировых производителей уже вывели на рынок свои версии продуктов. Среди наиболее известных игроков на рынке — Barracuda Networks Citrix, F5, Fortinet и Imperva. Ниже представлен обзор популярных на рынке решений. Более подробную информацию о них можно получить в сравнительной таблице, где можно сравнить все продукты по каждой отдельной характеристике. 
А в нашем обзоре мы попробуем осветить их основные свойства и преимущества.
Barracuda Web Application Firewall
Barracuda Web Application Firewall — эффективная комплексная система, предназначенная для обеспечения безопасности веб-приложений и сайтов. Продукт дает мощный отпор злоумышленникам, эксплуатирующим слабые места в протоколах или приложениях для хищения данных, нарушения работы сервисов или дефейса веб-сайтов. Примечательно, что решение от Barracuda WAF имеет не только английский, но и русский интерфейс.
Продукт от Barracuda способен обеспечить защиту от таких атак, как внедрение SQL кода, межсайтовый скриптинг (XSS), взлом сессий и переполнение буфера. Кроме того, Barracuda WAF предотвращает хищение информации за счет мониторинга всех исходящих данных на наличие утечек каких-либо секретных сведений: номеров счетов в банках, личной пользовательской информации, паролей и прочего.
Системный администратор сможет вовремя детектировать DoS- и DDoS атаки благодаря специальной функции, контролирующей скорость передачи данных. Мощный встроенный антивирус позволяет проверить любые импортируемые в систему данные и файлы на предмет различного вредоносного кода.
Barracuda Web Application Firewall полностью совместим с большинством распространенных систем для идентификации (Active Directory, eDirectory), которые поддерживают LDAP RADIUS. Кроме того, здесь есть функция двухфакторной идентификации: система поддерживает пользовательские аутентификаторы и токены (RSASecureID), чтобы гарантировать надежную защиту аутентификации клиентов.
Citrix NetScaler Application Firewall
NetScaler Web App Firewall от компании Citrix, входящий в состав комплексного решения Citrix NetScaler, является одним из лучших в своей категории файрволом веб-приложений (WAF), защищающим как сайты, так и приложения от различных атак, включая угрозы на прикладном уровне и уязвимости нулевого дня.
Продукт предназначен для государственного сегмента, крупного и среднего бизнеса. NetScaler Web App Firewall поставляется как в виде виртуальной машины, так и аппаратного комплекса, а также в виде облачного сервиса.
NetScaler Application Firewall от Citrix защищает от атак типа SQL инъекция, XSS, от изменения скрытых параметров формы (read-only(hidden) parameters) и других атак. Имеется функция предотвращения утечек данных, которая обеспечивает профилактику хищения данных кредитных карт и других конфиденциальных сведений, фильтрует и блокирует при необходимости передаваемую информацию.
Для адаптации NetScaler WAF к изменяемому приложению создается профиль защиты веб-приложений, который по умолчанию отражает все наиболее распространенные и опасные угрозы. Со временем этот профиль постепенно корректируется и наполняется информацией.
Пропускная способность Citrix Web Application Firewall составляет от 500 Мбит/с до 44 Гбит/с. Citrix WAF предлагается как отдельное решение или же интегрируется с платформой Citrix ADC. По данным NSS Labs, именно Citrix Web Application Firewall является одним из лидеров по соотношению цена/производительность среди файрволов веб-приложений.
Для компаний, которые намерены перенести свои приложения и данные в облако, хорошую службу сослужит сервис Citrix Web App Firewall Security Service. Этот продукт более прост в конфигурировании, кроме того, при его покупке используется модель «плати по мере роста». Это позволяет тратить ровно столько денег, сколько нужно для актуальных задач, но по мере необходимости масштабировать этот продукт.
F5 Networks Silverline Web Application Firewall
Несколько лет назад F5 Networks вывела на рынок cloud-сервис Silverline Web Application Firewall (WAF), цель которого — отражать атаки на веб-приложения. Этот продукт предлагается по модели подписки.
Silverline WAF предлагает поддержку в режиме 24×7 от экспертов в области безопасности. Подобная поддержка, во-первых, дает возможность компаниям защитить данные и веб-приложения, во-вторых, обеспечить соответствие индустриальным стандартам безопасности, таким как PCI DSS.
Silverline WAF защищает приложения от атак, основанных на внедрении SQL-кода, атак типа zero-day, вложения JSON, OWASP Top Ten и др. Важное преимущество Silverline WAF —функция самообучения в автоматизированном режиме, применяющая технологии iRules и iApps для оперативного переконфигурирования в соответствии со спецификой новых угроз.
Продукт дает возможность снизить операционные затраты за счет применения специальных ресурсов Центра обеспечения безопасности F5 Networks при управлении политиками WAF. Встроенная функция проактивного мониторинга от F5 Networks задействует внешние специализированные решения для защиты приложений от новых атак. Решение генерирует отчеты о доступе через портал заказчика.
Fortinet FortiWeb
Брандмауэр для веб-приложений FortiWeb от компании Fortinet ориентирован на средний и крупный бизнес, а также интернет-сервис-провайдеров. Продукт поставляется в виде аппаратного или виртуального устройства, а также в виде облачного сервиса. Благодаря сопровождению службы безопасности от FortiGuard Labs, FortiWeb обеспечивает защиту от новейших уязвимостей приложений, ботов и подозрительных URL-адресов. Кроме того, за счет двух механизмов обнаружения угроз, построенных на технологии машинного обучения, веб-приложения защищены от таких сложных кибер рисков, как SQL-инъекция, кросс-сайт-скриптинг, переполнение буфера, вредоносное изменение файлов cookie, источники угроз и атак DoS.
Функция нахождения угроз, путем поведенческого анализа, в FortiWeb использует два уровня машинного обучения на основе AI и статистических вероятностей для обнаружения аномалий и отдельных угроз. Благодаря машинному обучению FortiWeb может обеспечить почти 100%-ную точность детектирования угроз для приложений, практически не потребляя ресурсов. За счет искусственного интеллекта FortiWeb представляет собой практически WAF «из коробки», который работает по принципу «установить и забыть», но при этом не в ущерб точности и надежности.
Fortinet перманентно ведет работу по детектированию новых угроз в собственном аналитическом центре FortiGuard Security Center. За счет такого подхода обновления сигнатур, черных списков сайтов и баз репутаций происходит несколько раз в день.
FortiWeb способен обеспечить временный патчинг приложений до тех пор, пока команды разработчиков не развернут перманентные заплаты для уязвимостей. Обычно рекомендуется перманентно исправлять известную уязвимость, однако есть много ситуаций, когда это невозможно или непрактично, например, когда речь идет об унаследованных или старых приложениях, которые будут вскоре удалены.
Полная совместимость всех продуктов Fortinet между собой дает возможность быстро и просто масштабировать систему. Высокая степень автоматизации операций и простота их сопровождения сокращает число ошибок, вызванных человеческим фактором. Кроме того, такая характеристика позволяет сократить число сотрудников отдела ИБ.
Imperva SecureSphere Web Application Firewall
Решения от компании Imperva предназначены для применения в государственном секторе, а также в крупном и среднем бизнесе. Продукты интересны синхронным применением сразу нескольких технологий киберзащиты: контролем протоколов на аномальное поведение, динамическим профилированием, анализом через сигнатуры, отслеживанием сессий. Для всех продуктов Imperva предоставляется качественная поддержка. Кроме того, это семейство продуктов известно несложной процедурой инсталляции и настройки.
Для эффективной защиты применяются механизмы на основе сигнатур бесплатной open-source системы предотвращения вторжений Snort, а также собственных SQL-сигнатур, генерируемых исследовательским центром ADC (Application Defense Center). С точки зрения отказоустойчивости, здесь имеется поддержка кластеризации Active-Active и Active-Passive.
SecureSphere WAF оснащен невстраиваемым снифером, прозрачным прокси-сервером и обратным прокси-сервером, обладает отличной поддержкой SSL. Так продукт обеспечивает пассивную расшифровку SSL, поддержку сессий, установленных на клиентских сертификатах, терминацию и детерминацию (то есть, анализ трафика SSL без терминации). Немаловажно, что разработка содержит аппаратные модули, ускоряющие обработку SSL.
Для формирования эталонной модели безопасности здесь применен метод классификации правил и применения детальных сигнатур (с использованием правил межсетевого экранирования, создания сигнатур и обработки нарушений протоколов). Для адаптации WAF к изменяемому приложению реализована возможность изменения профиля веб-приложений, созданного в режиме машинного обучения. Вместе с тем, есть настройка профиля веб-приложений в ручном режиме.Продукт может поставляться в виде виртуальной машины, аппаратного комплекса, а также в виде облачного сервиса. Максимальная поддерживаемая пропускная способность старшей модели достигает 10 Гбит/с. Помимо HTTP/HTTPS, здесь есть поддержка веб-стандартов WebSockets, XMS и JSON.
Реализованный в SecureSphere WAF генератор отчетов, предоставляет системным администраторам отчеты в соответствии с требованиями стандартов по ИБ. Также здесь есть возможность генерировать собственные кастомизированные отчеты (в том числе, и по расписанию) и экспортировать в различные форматы.
Еще одно немаловажное позитивное качество устройств SecureSphere WAF — наличие сервиса ThreatRadar, обеспечивающего практически мгновенную защиту от атак. ThreatRadar позволяет оперативно блокировать трафик, идущий от подозрительных источников, еще до момента осуществления какого-либо вредного воздействия. 
Резюме
Все продукты, описанные выше, являются лидерами на рынке и обеспечивают защиту высокого качества. Но, чтобы убедиться в правильности конфигурирования, после окончания процесса построения защитной системы, эксперты рекомендуют провести так называемый Penetration test — испытание на проникновение. С его помощью можно проверить реальную защищенность информационной системы через имитации направленных атак различного типа.
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. Но это — уже другая история.