Web application firewall что это

Обновлено: 04.07.2024

Этичный хакинг и тестирование на проникновение, информационная безопасность

Что такое WAF (файервол веб приложений)

WAF, Web Application Firewall — файервол веб приложений, иногда переводится как «файловый файервол», это программа, которая анализирует поступающие на веб-сервер запросы и на основе правил отфильтровывает те из них, которые могут быть потенциально опасными для веб сайта.

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

Почему использование WAF не гарантирует защиту сайта

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

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

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

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

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

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

Инструкции по установке рассматриваемых программ вы найдёте на карточках каждого инструмента, ссылки на которые также будут даны.

Несколько сайтов для наших тестов, каждый из которых использует файловый файервол:

WAFW00F

Программа wafw00f очень быстро и точно определяет тип WAF для указанного сайта. Из дополнительных функций у wafw00f имеются следующие:

сканирование сайта через прокси
поддержка форматов ввода и вывода csv, json или text

Использование программы очень простое — просто укажите домен сайта, для которого вы хотите узнать WAF:

Строка «Number of requests» показывает количество сделанных запросов — хватило всего двух. В результате был выявлен WAF Cloudflare.

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

Для отправки запросов через прокси используйте опцию -p, после которой укажите данные прокси — SOCKS и аутентификация поддерживаются, примеры правильно указанных параметров прокси:

В следующей команде в качестве прокси используется сеть Tor:

Не смотря на медлительность сети Tor, идентификация веб защиты (которой оказалась Wordfence от производителя Defiant) прошла очень быстро и потребовала всего два запроса.

Цели для идентификации веб защиты можно собрать в файл. При запуске программы можно указать файл со списком целей, поддерживаются форматы csv, json или text. Для csv и json, требуется колонка или элемент с именем «url». Формат текстового файла: 1 URL на одну строку.

С помощью опции -t вы можете указать какой именно WAF вы хотите найти, особенно полезной эта опция должна быть с -i:

Кстати, вывести полный список поддерживаемых файерволов веб-приложений вы можете командой:

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

Из нашего небольшого списка тестовых сайтов этой программой удалось определить тип WAF для двух из четырёх.

identYwaf

identityYwaf — ещё одна простая в использовании, но эффективная программа. По аналогии с предыдущим, это инструмент идентификации, который может распознавать тип веб-защиты (например, WAF) основываясь на ответе сервера. Более того, данный инструмент делает дополнительные запросы, чтобы определить, против каких категорий уязвимости настроен WAF. Закончив сканирование, инструмент даёт оценку (в процентах) сложности эксплуатации уязвимостей (если они имеются).

В настоящее время данная программа умеет определять более 80 различных продуктов защиты (например, aeSecure, Airlock, CleanTalk, CrawlProtect, Imunify360, MalCare, ModSecurity, Palo Alto, SiteGuard, UrlScan, Wallarm, WatchGuard, Wordfence и так далее), при этом база знаний постоянно расширяется.

identityYwaf выполняет проверку двумя способами:

Пример сканирования файервола веб приложений:

Изучим вывод программы.

Определён тип веб защиты не-слепым методом, это Wordfence от Defiant:

Всего было выполнено 45 тестов с различной полезной нагрузкой (неопасные запросы, которые очень похожи на запросы для эксплуатации уязвимостей):

Результат представлен в виде диаграммы, в которой точка — это не заблокированная полезная нагрузка (отсутствие защиты против данной атаки), а крестик — это блокировка от WAF в ответ на присланную полезную нагрузку):

Сложность эксплуатации потенциальных атак — простая:

Заблокированные категории атак:

Финальное решение на основе слепого метода идентификации и его вероятность:

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

Не-слепой метод идентифицировал веб защиту как CloudFlare, слепой метод в целом пришёл к такому же выводу:

Этот пример наглядно показывает преимущество двух независимых методов идентификации WAF:

Но проверки с помощью разнообразных типов полезной нагрузки позволили идентифицировать веб защиту как Kona Site Defender, производитель Akamai Technologies:

Также была собрана информация о правилах блокировки, какие именно категории уязвимостей фильтруются:

Если вы хотите изменить Пользовательский Агент на случайный, то добавьте опцию --random-agent:

Если вы хотите, чтобы полезная нагрузка отправлялась методом POST, то добавьте опцию --post:

Но с помощью программы Privoxy эта проблема решается (подробности настройки Privoxy смотрите по указанной ссылке).

WhatWaf

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

Данный инструмент может определить более 70+ различных файерволов веб приложений и пробует более 30+ различных техник обхода

Первое, что бросается в глаза, это долгая работа данной утилиты. Дело в том, что WhatWaf не просто пытается определить веб защиту, но и ищет способы обхода файервола веб приложений. Способы обхода заключаются в использовании скриптов вмешательства (тамперов), которые модифицируют полезную нагрузку так, что с одной стороны она (практически) не теряет функциональности, но при этом она перестаёт обнаруживаться фильтрами веб защиты, которые обычно работают на основе поиска по регулярным выражениям. Примеры работы тамперов: замена пробелов на знаки плюс, вставка ненужных комментариев или ничего не значащих символов, замена пробела на несколько пробелов, кодирование или двойное кодирование в URL кодировку, изменение регистра символов, вставка бессмысленных тегов и прочее.

В строке FIREWALL указан обнаруженный файервол веб приложений:

Рассмотрим результат следующего сканирования:

В строках FIREWALL мы видим возможные системы веб защиты:

перечислены обнаруженные способы обхода фильтров файервола веб приложений.

Если вам нужно только узнать тип WAF и вы хотите пропустить проверку обходов, то используйте опцию --skip:

Если вы хотите указать множество целей, то сохраните их в файл (один URL на строку) и запустите программу с опцией -l:

Вы можете изменить USER-AGENT. Это можно сделать опцией --ra (в этом случае будет выбран случайный USER-AGENT):

Либо с помощью опции --pa вы можете указать определённый Пользовательский Агент:

WhatWaf поддерживает работу через прокси, для этого имеется опция --proxy:

Имеется несколько опций специально для сети Tor. С помощью опции --check-tor вы можете проверить подключение к Tor:

Имеется специальная опция --tor для анонимных сканирований:

Подразумевается, что служба tor прослушивает порт 9050, если у вас другая конфигурация, то используйте опцию -tP чтобы указать свой собственный порт.

Опция -W делает так, что утилита дополнительно пытается определить версию веб-сервера.

Чтобы просмотреть кэшированные результаты предыдущих сканирований, запустите утилиту с опцией -uC:

Для обновления программы перейдите в папку с ней и выполните

Онлайн сервис выявление файловых файерволов

Вам достаточно только ввести имя домена интересующего вас сайта и сервис последовательно выполнить сканирование каждой программой.

Удалось даже сохранить цветной вывод для двух утилит (существует много разнообразных экранированных последовательностей для окрашивания вывода в терминале, поэтому перевод цвета из Bash в HTML не всегда тривиальная задача).

В целом удобно сравнивать результаты сканирования сразу всех трёх инструментов.

Являются ли системы класса WAF обязательным стандартом для обеспечения безопасности веб-ресурсов или же остаются важной, но дополнительной опцией? Как выбрать и внедрить Web Application Firewall и что ждёт рынок в будущем? Об этом рассуждают представители вендоров, сервис-провайдеров и крупных заказчиков в рамках онлайн-конференции AM Live.

Введение

Очередной выпуск онлайн-конференции AM Live был посвящён системам стоящим на страже веб-ресурсов — решениям класса Web Application Firewall. Для того чтобы разобраться, что такое WAF, какие функции этих систем наиболее востребованны и как избежать проблем при внедрении, мы пригласили в студию ведущих экспертов рынка информационной безопасности. Предлагаем вашему вниманию ключевые тезисы прямого эфира, длившегося более двух часов.

В дискуссии приняли участие:

Михаил Кондрашин, технический директор компании Trend Micro в СНГ, Грузии и Монголии.
Виктор Рыжков, менеджер по продуктовому маркетингу направления Application Security компании Positive Technologies.
Вячеслав Гордеев, системный инженер компании Fortinet.
Вячеслав Алешин, руководитель направления разработки облачных продуктов кибербезопасности компании BI.ZONE.
Александр Баринов, руководитель направления сервисов Solar MSS компании «Ростелеком-Солар».
Иван Новиков, CEO компании «Валарм».

Ведущий и модератор дискуссии — Андрей Дугин, начальник отдела обеспечения информационной безопасности компании МТС.

Для чего нужен Web Application Firewall

В первую очередь мы спросили у наших экспертов, кому и зачем нужен WAF. Модератор дискуссии предложил поговорить о том, чем этот класс средств защиты отличается от обычных файрволов, в том числе — нового поколения (Next Generation Firewall, NGFW). Не проще ли вместо использования WAF банально поддерживать безопасность сайта — устанавливать актуальные патчи, устраивать пентесты и т. д.?

Виктор Рыжков:

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

Вячеслав Алешин:

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

Иван Новиков:

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

Вячеслав Гордеев:

Михаил Кондрашин:

— Если говорить образно, WAF — это продукт, который позволяет эксплуатировать уязвимый веб-сайт так, чтобы его не взломали. Что касается размещения, то NGFW устанавливается на шлюзе, а WAF — там, где находится веб-сайт.

Александр Баринов:

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

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

Ещё одна тема, которую затронули гости студии, — варианты размещения Web Application Firewall. Имеет ли смысл использовать локальный (on-premise) вариант или лучше подписаться на облачный сервис? Как отметили эксперты AM Live, в данном случае это — вопрос доверия к облачному провайдеру, поставщику услуги. Сейчас рынок безопасности веб-приложений активно мигрирует в облако, а значит, всё больше и больше заказчиков считают риски таких сервисов приемлемыми для себя.

В ходе прямого эфира мы спросили зрителей онлайн-конференции о том, используют ли они WAF в своей компании. Положительно ответил на этот вопрос 51 % респондентов. Не используют системы безопасности этого класса 49 %.

Рисунок 1. Используете ли вы WAF в своей организации?

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

Технические особенности WAF

Базовую структуру «типового» решения класса Web Application Firewall обрисовал Вячеслав Гордеев. Как сказал эксперт, у каждого WAF есть набор модулей защиты, по которым проходит весь трафик. Обычно всё начинается с базовых уровней — модулей защиты от DDoS-атак и блоков сигнатурного анализа. Уровнем выше стоит возможность разработки своих собственных политик безопасности, а также подсистема математического обучения. На одном из последних этапов обычно появляется блок интеграции со сторонними системами.

Переходя к вопросу о технологиях детектирования атак, эксперты отметили, что есть две принципиально разные задачи: валидация (проверка данных в конкретных запросах) и поведенческий анализ. Для каждой из этих моделей применяется свой собственный набор алгоритмов. Если же взглянуть на работу 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 в одно приложение занимает полторы минуты. Эксперт пояснил, что речь идёт только о мониторинге: настройка правил блокировок займёт дополнительное время. При этом другие спикеры онлайн-конференции указали, что подразумевается «чистое» время, которое не включает многие аспекты внедрения — согласования, обучение персонала и другие этапы. Иван Новиков подчеркнул, что время внедрения зависит от способа развёртывания, а также от конкретного приложения и от трафика, который необходимо контролировать.

Гости студии рассказали также о том, как правильно построенный процесс внедрения поможет уменьшить процент ложных срабатываний WAF. Виктор Рыжков отметил, что решить эту задачу поможет тестирование на подготовительном этапе (pre-production), а также после ввода системы в эксплуатацию. Эксперт отметил важность возможности «обучения» файрвола, когда на этапе теста часть вердиктов корректируется специалистом. Александр Баринов порекомендовал изучить статистику работы WAF за первый месяц работы, чтобы понять, не блокирует ли система легитимный трафик. Вячеслав Алешин подчеркнул, что не бывает WAF полностью исключающих ложные срабатывания.

Спикеры перечислили также основные направления интеграции Web Application Firewall с другими средствами безопасности. По мнению экспертов, это:

SIEM-системы (WAF выступает поставщиком данных).
Различные виды песочниц.
Антивирусные ядра.
DLP-системы.
Сканеры уязвимостей.
Средства безопасности внутри платформы Kubernetes.
NGFW.

Зрители 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 не раз отмечали приглашённые нами эксперты.

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

Что такое WAF

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

Какими были первые решения?

Первые попытки создать Web Application Firewall предпринимались еще в начале 90-х годов. Известно как минимум о трех инженерах, работавших в этой области. Первый — профессор компьютерных наук Джин Спаффорд из Университета Пердью. Он описал архитектуру файрвола приложений с прокси и в 1991 году опубликовал её в книге «Безопасность UNIX на практике».

Вторым и третьим — были ИБ-специалисты Уильям Чесвик и Маркус Ранум из Bell Labs. Они разработали один из первых прототипов файрволов приложений. Его распространением занималась компания DEC — продукт выпустили под названием SEAL (Secure External Access Link).

Примерно в одно время с 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 Валарм.

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

Анализ поведения ответа приложения (пассивное)
Сканирование/фаззер (активное)
Файлы отчетов/процедуры-перехватчики/ловушки (пост фактум)
Ручное (определяется супервизором)

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

Далее рассмотрим технологические возможности различных вариантов реализации WAF.

Железо, ПО или облако — что выбрать?

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

Другой вариант развертывания WAF — программная реализация. Решение устанавливается в качестве дополнения для какого-либо ПО (например, ModSecurity настраивается поверх Apache) и работает на одном сервере с ним. Как правило, подобные решения можно развернуть как на физическом сервере, так и в облаке. Их минус — это ограниченные возможности масштабируемости и поддержки со стороны вендора.

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

Почему сейчас все чаще смотрят в сторону облачного WAF, расскажем далее.

Что может WAF в облаке

С точки зрения технологических возможностей:

За обновления отвечает провайдер. WAF предоставляется по подписке, поэтому за актуальностью обновлений и лицензий следит поставщик сервиса. Обновления касаются не только программного, но и аппаратного обеспечения. Провайдер апгрейдит серверный парк и занимается его обслуживанием. Он также отвечает за балансировку нагрузки и резервирование. Если происходит отказ в работе сервера WAF, трафик немедленно перенаправляется на другую машину. Рациональное распределение трафика позволяет избежать ситуаций, когда файрвол входит в режим fail open — не справляется с нагрузкой и перестает фильтровать запросы.
Виртуальный патчинг. Виртуальные патчи ограничивают доступ к скомпрометированным частям приложения до закрытия уязвимости разработчиком. В результате заказчик облачного провайдера получает возможность спокойно дождаться пока поставщик того или иного программного обеспечения опубликует официальные «заплатки». Сделать это максимально оперативно — приоритет для поставщика ПО. К примеру, в платформе «Валарм» за виртуальный патчинг отвечает отдельный программный модуль. Администратор может добавлять кастомные регулярные выражения для блокировки вредоносных запросов. Система дает возможность отмечать некоторые запросы флагом «Конфиденциальные данные». Тогда их параметры маскируются, а сами они ни при каких условиях не передаются за пределы рабочей зоны файрвола.
Встроенный сканер периметра и уязвимостей. Это позволяет самостоятельно определять сетевые границы ИТ-инфраструктуры, используя данные DNS-запросов и протокола WHOIS. После WAF автоматически анализирует работающие внутри периметра службы и сервисы (выполняет сканирование портов). Файрвол способен обнаруживать все распространённые типы уязвимостей — SQLi, XSS, XXE и др. — и выявлять ошибки в конфигурации ПО, например, несанкционированный доступ к репозиториям Git и BitBucket и анонимные обращения к Elasticsearch, Redis, MongoDB.
Атаки мониторятся ресурсами облака. Как правило, облачные провайдеры обладают большими объемами вычислительных мощностей. Это позволяет производить анализ угроз с высокой точностью и скоростью. В облаке развертывается кластер из фильтрующих узлов, через которые проходит весь трафик. Эти узлы блокируют атаки на веб-приложения и отправляют статистику в Центр аналитики. Он использует алгоритмы машинного обучения, чтобы обновить правила блокировки для всех защищаемых приложений. Реализация подобной схемы указана на рис. 4. Подобные адаптированные правила безопасности минимизируют число ложных срабатываний файрвола.

Теперь немного об особенностях облачных WAF с точки зрения организационных моментов и управления:

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

Текст подготовил Александр Карпузиков, менеджер по развитию продуктов ИБ облачного провайдера MTS Cloud.

В этом году компанию 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-порта коммутатора.

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

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

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

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

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

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

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

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

WAF	IPS	NGFW/UTM
Multiprotocol Security	-	+	+
IP Reputation	±	±	±
Сигнатуры атак	+	±	±
Автоматическое обучение, поведенческий анализ	+	-	-
Защита пользователей	+	-	-
Сканнер уязвимостей	+	-	-
Виртуальный патчинг	+	-	-
Корреляции, цепочки атак	+	-	-

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

Кроме того, продвинутые модели 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 всегда будут отличаться набором функций. Поэтому перечислим здесь лишь наиболее известные дополнительные фичи современных защитных экранов уровня приложений:

Читайте также: