Средства фильтрации трафика на прикладном уровне (Web Application Firewall, WAF) защищают от целевых атак, взлома веб-приложений и сайтов компаний с целью кражи и подмены конфиденциальных данных, а также блокируют атаки из перечня OWASP TOP 10 и попытки вызвать отказ в обслуживании (DoS и DDoS). Однако у них есть свои изъяны. Как улучшить работу WAF?
- Введение
- Работа WAF по сигнатурам
- Недостатки сигнатурного метода
- Работа WAF по поведенческим моделям
- Недостатки поведенческих моделей
- Трудности при выходе новых релизов веб-приложения
- Примеры и описания регулярных выражений
- Пример оптимизации сигнатуры
- Использование ИИ в работе с WAF
- Выводы
Введение
Работа современных межсетевых экранов для защиты веб-приложений (WAF) сопровождается различными сложностями. Самые актуальные из них — пропуски атак и ложноположительные срабатывания (false positives). Для уменьшения количества последних ослабляют правила блокировки, что увеличивает число пропущенных атак. При этом актуальна и обратная проблема: усиление правил для противостояния атакам увеличивает количество ложноположительных срабатываний.
Перед нами стоит нелёгкая задача: оптимизировать процесс работы с WAF таким образом, чтобы не пропустить атаку и исключить ложноположительные срабатывания. В этой статье мы разберём плюсы и минусы сигнатурного и поведенческого методов работы с WAF, изучим потенциал использования ИИ, а также подробно рассмотрим написание оптимизированного регулярного выражения для комплексного охвата всех задач администраторов и экономии драгоценного времени.
Работа WAF по сигнатурам
Анализ трафика приложений по сигнатурам заключается в использовании определённых правил, которые представлены в виде регулярных выражений. Правила (они же сигнатуры) могут быть короткими или длинными, а также распространяться на разные директории веб-приложения.
Анализ сигнатурным методом производится следующим образом. Когда пользователь на сайте нажимает на любую кнопку, заполняет форму или просто обновляет страницу, он отправляет запрос, который содержит в себе уникальные параметры. Запрос попадает в систему Web Application Firewall, последовательно проходит через каждую сигнатуру и блокируется, если соответствует параметрам одного из правил. Блокировка может предотвратить SQL-инъекции или подделки межсайтовых запросов. Инъекции дают атакующему возможность выполнить произвольный запрос к базе данных веб-приложения; в зависимости от типа уязвимости злоумышленники могут удалять, изменять или добавлять различные данные, а также работать с локальными файлами и выполнять команды на атакуемом сервере.
Среди плюсов сигнатурного метода защиты — развитое сообщество и готовые сигнатуры от вендоров WAF: каждый продукт на рынке предлагает свой собственный готовый набор, который обеспечивает начальный уровень защищённости веб-ресурса даже без дополнительной настройки. Если администратор WAF захочет расширить этот список, в открытых источниках найдётся большое количество правил для веб-приложений разных типов.
Многие разработчики и энтузиасты выкладывают правила в открытый доступ, например на GitHub. На просторах последнего можно найти самые распространённые сигнатуры WAF для разных типов уязвимостей. Готовые сборки позволяют не писать правила «с нуля» и свободно интегрировать их в решение, которое развёрнуто на собственных мощностях.
Ещё один плюс — относительная простота написания правил: на первый взгляд, сигнатура — это комплексное регулярное выражение. Писать их нетрудно: достаточно запастись списком операторов, ресурсом для проверки регулярных выражений и тестовыми данными.
Рисунок 1. Пример списка сигнатур WAF
Недостатки сигнатурного метода
Перейдём к недостаткам. Первый из них — сигнатуры бесполезны в противостоянии уязвимостям «нулевого дня». Невозможно написать сигнатуру под уязвимость, которой ещё не существует. До выпуска патча или заявления об уязвимости WAF будет пропускать подобные запросы к веб-ресурсам как легитимные. Это значительно снижает общий уровень защищённости.
Следующий очевидный минус — сложность написания сигнатур при отсутствии должного уровня разбора и очистки трафика. Сигнатура может бесконечно долго разрастаться из-за попытки вместить в неё слишком много параметров, которые должны отсекаться на более ранних этапах другими средствами защиты.
Нагрузка на вычислительные мощности растёт пропорционально количеству проверок. WAF тратит на каждую проверку по сигнатуре много ресурсов, и при большом количестве этих проверок (если неэффективно составлены сигнатуры и их порядок) потребуется закладывать больше средств на расширение инфраструктуры. В ходе атаки WAF может просто не справиться и «захлебнуться». Учесть все варианты нелегитимных запросов даже одного типа тоже весьма сложно. Злоумышленники могут модифицировать запрос таким образом, что сигнатура не сработает, например, при замене символов.
В качестве примера подмены можно привести расщепление нагрузки:
Detect — DeTeCt — DetDETECTect
Ещё один недостаток сигнатурного метода обнаружения атак — высокая вероятность обхода WAF с большим количеством ложных срабатываний. Зачастую в компаниях малого и среднего бизнеса не хватает компетенций, мощностей и человеческого ресурса для точечной настройки WAF. Каждое веб-приложение требует комплексного подхода и изучения трафика. Без должного внимания неподготовленные правила блокируют значительную часть легитимного потока данных, что приводит к большому количеству ложноположительных срабатываний.
Тем не менее сигнатурный анализ работает быстро и обеспечивает базовую защиту веб-приложения в период обучения, а в дальнейшем служит первым эшелоном защиты, блокируя очевидные атаки.
Работа WAF по поведенческим моделям
Применение поведенческого анализа в работе WAF учитывает специфику бизнес-процессов компании. Это позволяет выстроить определённые паттерны (модели) нормального поведения пользователей и тем самым отсечь почти любые нестандартные запросы, которые потенциально являются нелегитимными, даже если вендор ещё не выпустил патча для той или иной уязвимости. В отличие от сигнатурного метода, такой подход помогает защититься от брешей класса «0-day».
Описанная модель поведения также помогает защитить веб-ресурс от ботов разной направленности, например от скрейперов. Действия ботов совсем не похожи на человеческие: они пытаются попасть на ресурс без аутентификации или используют нестандартные браузеры, так что WAF такие запросы быстро блокирует. Правда, стоит понимать, что WAF не станет полноценной заменой решениям классов Anti-DDoS или Anti-Bot. В классическом понимании Anti-DDoS нужен для защиты от атак L3–L4 на сетевом уровне. WAF же работает на прикладном уровне сетевой модели OSI.
Рисунок 2. Модель OSI
При сравнении Anti-Bot и WAF различий в функциональности меньше, но они всё ещё присутствуют. Anti-Bot рассчитан на быстрый поиск факторов, которые отличают человека от бота. Система смотрит внутрь запроса, быстро размечает трафик и может противостоять DDoS-атакам на прикладном уровне, но в то же время не сможет защитить от инъекций кода.
Эшелон защиты веб-приложения должен выстраиваться следующим образом. На первом рубеже используется Anti-DDoS — при комплексной атаке такое решение отфильтровывает примерно 60–70 % мусорного трафика по IP-адресу или географической принадлежности. Ещё 20 % отсекает система Anti-Bot — она будет смотреть внутрь трафика, расшифровывать его и блокировать на своём уровне. Оставшийся трафик, который обрабатывает WAF, фильтруется более высокоуровневым анализом и попадает на клиентский сервер.
Недостатки поведенческих моделей
Данный подход требует глубокого погружения в специфику веб-приложения: сам процесс построения моделей поведения весьма трудоёмок, и для его реализации необходимо полное понимание механизма работы приложения. Это влечёт за собой увеличение затрат на администрирование и риски пропуска той или иной функции приложения, а значит, неполного охвата веб-ресурса защитой.
Трудности при выходе новых релизов веб-приложения
Если в новой версии защищаемого веб-приложения присутствуют обновления, WAF будет рассматривать их как нелегитимные. В случае работы WAF по сигнатурам новые функции будут блокироваться, потому что для них ещё не созданы исключения и система не знает об обновлениях, а поведенческая модель будет блокировать легитимный трафик, если для приложения ещё не прописаны новые бизнес-процессы. Для стабильной работы веб-приложения и исключения нежелательных блокировок все обновления тестируются на серверах разработчиков.
Разработчики веб-приложения в тесном взаимодействии с администраторами WAF должны протестировать новую функциональность и написать правила для исключения нежелательных пропусков и блокировок. На этом этапе происходит процесс добавления новых сигнатур или моделей, о которых мы говорили ранее. После успешных тестов разработчики выкладывают обновления на ресурс, который видят пользователи.
Предварительные тесты обновлений позволяют значительно сократить количество ложноположительных срабатываний, но не у всех команд разработки есть выделенные стенды для тестирования, поэтому не исключена ситуация, когда настройка системы происходит «наживую». Без должного документирования процессов в начале работы можно столкнуться с отсечением большого количества легитимного трафика из-за нехватки прописанных бизнес-процессов.
Примеры и описания регулярных выражений
Регулярные выражения — неотъемлемая часть WAF. Это относится не только к написанию сигнатур и устранению уязвимостей, но и к выполнению рутинных задач — например, к эффективной обработке статических ресурсов в новом веб-приложении.
Следующие регулярные выражения могут помочь быстро просмотреть большинство ресурсов, которые относятся к статическим, чтобы исключить их из списка регулярных проверок.
Для JS- и CSS-файлов:
(.+\.js|.+\.css) (.+\.js|.+\.css)?[0-9a-fA-F]+ main.date.js?[0-9a-fA-F]+
Для изображений:
(.+\.jpg|.+\.jpeg|.+\.png|.+\.svg|.+\.webp|.+\.gif|)
Пример оптимизации сигнатуры
Для примера мы взяли регулярное выражение, которое позволяет отфильтровывать транзакции с попыткой провести эксплойт для библиотеки логирования Log4j. Несмотря на то что проблема не нова, многие веб-приложения всё ещё остаются незащищёнными по разным причинам.
Исходное регулярное выражение выглядит следующим образом:
(\$|%24)(\{|%7B)([^jJ][jJ])([^nN][nN])([^dD][dD])([^iI][iI])(:|%3A|\$|%24|}|%7D)(?<Exploit>.?)((\:|%3A)?)(\/\/|%2F%2F)(((?<MaliciousSource_IP>(\d{1,3}(?:\.\d{1,3}){3}))(?:(.?)))|(?<MaliciousSource_URL>((([\=\.\$\_\:\{\}]?)|(%24)|(%7B)|(%7D))?[\w\d\.]+?[\.\/\:\=]?)+))((%7D|\}){1})В этом регулярном выражении нас больше всего интересуют следующие группы:
- <Exploit> — детектирует в строке эксплойт (ldap/rmi/etc);
- <MaliciousSource_IP> — детектирует в строке IP-адрес, на который направлена атака;
- <MaliciousSource_URL> — детектирует в строке URL, на который направлена атака.
Остальные операторы направлены на анализ всего выражения и попытку обнаружения нестандартных по размеру или написанию строк. Ниже на скриншоте приведены примеры строк, которые могут встречаться в нелегитимных транзакциях. Регулярное выражение успешно их детектирует.
Рисунок 3. Примеры строк в нелегитимных транзакциях
Это регулярное выражение подразумевает выполнение большого количества шагов, каждый из которых занимает определённое процессорное время и увеличивает задержку при обработке запроса. Оптимизируем выражение таким образом, чтобы сократить количество необходимых шагов, но при этом сохранить точность выявления нелегитимных транзакций:
([\$]|[\%24]){1,3}(?<suspicious_log4j>([\{]|[\%7B]{1,3}).*[jJnNdDiI]{1,4}.+[lLdDaApPsS]{1,5}.+([\/|\%2F]).+)В этом варианте регулярного выражения мы объединили группы «Exploit», «MaliciousSource_IP» и «MaliciousSource_URL» в одну группу «suspicious_log4j». Это позволит сократить количество проходимых шагов до минимума и сохранить нужную нам информацию. Стоит заметить, что это может усложнить дальнейший сбор логов, если мы используем результаты для верхнеуровневой аналитики (например, составляем списки IP-адресов и URL), однако эти операции можно проводить на дальнейших узлах цепочки анализа. Кроме того, мы объединили операторы выявления символов, характерных для эксплойтов:
([^jJ][jJ])([^nN][nN])([^dD][dD])([^iI][iI])(:|%3A|\$|%24|}|%7D)(?<Exploit>.?)((\:|%3A)?)(\/\/|%2F%2F) → *[jJnNdDiI]{1,4}.+[lLdDaApPsS]{1,5}
Рисунок 4. Полученное регулярное выражение успешно выявляет попытку использовать эксплойт
В итоге мы получили преобразованное регулярное выражение, которое работает быстрее примерно в два раза. Важно отметить, что подобная оптимизация — не финальный вариант. Выражение всё ещё можно модифицировать, однако мы уже добились желаемого результата путём тривиальных изменений.
Использование ИИ в работе с WAF
Применение ИИ для целей фильтрации на прикладном уровне — часто обсуждаемая в сообществе тема. Специалисты уверены, что инструменты с поддержкой искусственного интеллекта могут в будущем существенно сократить временные затраты на администрирование: достаточно дать алгоритмам обучиться, и в перспективе это обеспечит хорошую защиту ресурса при минимальных затратах.
При подключении WAF к ресурсу заказчика требуется время для анализа трафика и написания новых правил. Благодаря использованию ИИ временные затраты на разметку трафика и построение корреляции значительно сократятся. Это снизит нагрузку на администраторов и оптимизирует процесс анализа нового веб-приложения. Однако написание новых правил «с нуля» — всё ещё работа для живого человека, по крайней мере по состоянию на 2024 год.
Искусственный интеллект потенциально может написать сигнатуру, описанную выше в статье, занести её в список правил или отфильтровать трафик по аналогичной модели, но всё зависит от типа ИИ, а самое главное — от формы его лицензирования. Если вендор проводит тарификацию по количеству запросов к ИИ, будет удобнее обработать простые задачи вручную или готовыми наборами правил.
Преимущества использования ИИ в работе с WAF
Одним из явных преимуществ использования ИИ называют защиту от уязвимостей «нулевого дня». Это действительно так, поскольку в своей работе подобные решения опираются на поведенческую модель.
С другой стороны, для получения желаемого результата необходимо обеспечить алгоритмам большую базу трафика для обучения. Если использовать недостаточное количество данных, можно опять столкнуться с большим количеством ложноположительных срабатываний или недостаточной степенью защиты.
Автоматизация процессов — ещё один плюс использования искусственного интеллекта. Обученная модель способна помогать в разметке действий, дописывать политики, формировать сигнатуры и отправлять их на согласование аналитикам. Ведь полностью отдавать все процессы в распоряжение автоматики — всё ещё не самая лучшая идея. Автоматизация может помочь и с постанализом данных — выявлять аномалии в трафике, незаметные невооружённым глазом. ИИ способен фиксировать корреляцию событий, а команде аналитиков останется только разобраться, что именно спровоцировало реакцию.
Искусственный интеллект может быть полезен и в случае активных атак на приложение. В режиме экстренного реагирования аналитики могут не справляться с потоком задач. Эффективным сценарием взаимодействия в этом случае будет автоматический анализ со стороны ИИ с последующим контролем от команды аналитиков.
Анализ на основе ИИ может обнаруживать тонкие закономерности, которые иногда могут остаться незамеченными:
- резкие скачки трафика, указывающие на развитие DDoS-атаки;
- подозрительные геолокации IP-адресов;
- повторные попытки авторизации;
- необычные HTTP-заголовки, пользовательские агенты или протоколы;
- вредоносные данные в запросах Postman (HTTP-клиент для тестирования API);
- специальные символы и шаблоны, указывающие на SQL-инъекцию или межсайтовый скриптинг.
Недостатки использования ИИ в работе с WAF
Одна из трудностей — процесс выставления правильных параметров для обучения модели. Возможны ситуации, в которых новая модель может либо недостаточно обучиться, либо переобучиться. Для одного короткого регулярного выражения ИИ может автоматически делать 40–50 дополнительных действий.
В рамках обработки трафика такой процесс займёт намного больше памяти и времени. Модель с применением искусственного интеллекта может также некорректно размечать правила, что приведёт к неправильной сортировке легитимных действий. Для корректной работы системы нужен постоянный контроль со стороны команды, которая отвечает за обучение.
Выводы
Мы разобрали несколько методов эффективной работы с WAF: разные сценарии защиты и перспективы обучения WAF с использованием технологий искусственного интеллекта.
Использования одного подхода для комплексной защиты веб-приложения может быть недостаточно; вместе они дают более высокий уровень защищённости ресурсов. Идеальная формула — это синергия использования нескольких подходов и экспертной квалификации специалистов по WAF. Совмещение функциональности может принести значительную пользу: cигнатурный и поведенческий методы с поддержкой ИИ будут нивелировать недостатки друг друга.
Искусственный интеллект поможет им дообучиться и найти проблемы, которые возникают на аппаратном уровне. Несмотря на то что классический подход всё ещё в приоритете и занимает большую часть рынка, бурное развитие технологий может в будущем оказать значительную помощь в разработке и тестировании СЗИ.
