Забудьте о выборе: WAF теперь блокирует угрозы без ложных срабатываний

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

Команды вынуждены идти на компромисс: видимость в режиме логирования или защита в режиме блокировки. Когда правило блокирует запрос, оценка останавливается, и вы теряете возможность увидеть, как его оценили бы другие сигнатуры — ценное понимание, которое могло бы помочь вам настроить и усилить защиту.

Сегодня мы решаем эту проблему, представляя следующую эволюцию наших управляемых правил: Обнаружение сигнатур атак.

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

Но мы идем на шаг дальше. Мы выходим за рамки анализа только запросов к чему-то гораздо более мощному: Обнаружение полной транзакции.

Вместо анализа только входящего запроса, это новое обнаружение коррелирует всю HTTP-транзакцию: запрос и ответ. Анализируя полный контекст, мы значительно сокращаем ложные срабатывания по сравнению с традиционными механизмами сигнатур, работающими только с запросами. Что еще важнее, мы выявляем угрозы, которые другие упускают, такие как отраженная SQL-инъекция, скрытые паттерны эксфильтрации данных и опасные конфигурационные ошибки, которые проявляются только в ответе.

Обнаружение сигнатур атак уже доступно в раннем доступе — зарегистрируйтесь здесь, чтобы выразить интерес. Обнаружение полной транзакции находится в разработке; зарегистрируйтесь здесь, чтобы стать одним из первых, кто попробует его, когда оно будет готово.

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

Эта «всегда включенная» инфраструктура разделяет обнаружение и меры реагирования. Обнаружение работает непрерывно, обогащая аналитику метаданными о сработавших детекторах. Эти метаданные также добавляются к запросу как новое поле, которое клиенты могут использовать для создания пользовательских политик в рамках правил безопасности.

^{Разделение обнаружения вредоносных нагрузок и действий, предпринимаемых правилами безопасности, является основой всегда включенной инфраструктуры. Этот подход улучшает аналитику и повышает уверенность при развертывании новых средств защиты.}

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

Добавляет ли это дополнительную задержку к запросу? Нет — эта модель разработана для эффективности. Если клиент не создал правило блокировки на основе обнаружения, само обнаружение может быть выполнено после отправки запроса на исходный сервер, гарантируя, что обнаружение не вносит дополнительной задержки в трафик. Следовательно, при внедрении обнаружение включено по умолчанию, но не влияет на производительность трафика. Когда правило создано, обнаружение перемещается в линию с запросом, который может испытывать дополнительную задержку. Точное значение зависит от профиля трафика приложения.

По сравнению с традиционными системами на основе правил, такими как Cloudflare Managed Ruleset, новое обнаружение предлагает существенный прогресс в безопасности веб-приложений. Этот подход делает идентификацию вредоносных веб-нагрузок и развертывание правил безопасности значительно более удобными для пользователя.

Cloudflare Managed Ruleset — это место, где наша команда аналитиков разрабатывает детекторы для распространенных векторов атак, включая SQL-инъекции (SQLi), межсайтовый скриптинг (XSS), удаленное выполнение кода (RCE), и конкретные уязвимости и эксплойты (CVE). Аналитики обычно выпускают новые правила еженедельно, с экстренными выпусками для высокопрофильных уязвимостей (таких как недавний React2Shell релиз). В настоящее время в нашем Managed Ruleset активно более 700 управляемых правил. Новые детекторы также известны как правила-сигнатуры или просто сигнатуры. Они используют те же эвристики, что и Управляемые правила, но не применяют действия к трафику напрямую.

Каждая сигнатура уникально идентифицируется Ref ID (аналогично Rule ID для Managed Ruleset) и снабжена тегами категории и уверенности. Категория указывает на векторы атак, на которые нацелена сигнатура, а уровень уверенности указывает на вероятность ложного срабатывания (триггера на легитимном трафике). Правило может иметь только один уровень уверенности, но несколько категорий.

Категория указывает, к какому вектору атак относится правило. Список категорий длинный, но включает теги, такие как SQLi, XSS, RCE или конкретные CVE с их номерами.

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

Анализ запроса функцией обнаружения заполняет три поля. Эти поля доступны в аналитике безопасности и Edge Rules Engine, нашем основном механизме для правил безопасности.

Аналитика безопасности находится в центре набора инструментов безопасности приложений Cloudflare, предоставляя всесторонний, основанный на данных взгляд на то, как сигнатуры взаимодействуют с вашим веб-трафиком. Она дает вам инструменты, необходимые для понимания, измерения и оптимизации вашей веб-защиты. Распространенные сценарии использования аналитики вместе с сигнатурами включают: разработку стратегии безопасности в процессе внедрения, проверку наиболее частых попыток атак и создание исключений для обработки ложных срабатываний.

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

^{Разбивка общего объема запросов, соответствующих сигнатурам атак, сгруппированная по соответствующим Категориям или Сигнатурам.}

Аналитика предоставляет информацию о шаблонах атак, таких как наиболее частые CVE на основе объёма трафика с течением времени. Эта функция предназначена для быстрого выявления преобладающих вредоносных нагрузок, нацеленных на приложения, и проверки эффективности текущей защиты от связанных CVE. Например, аналитики могут отслеживать частоту атак на определённую часть приложения, например /api/, или подтверждать, достигают ли известные вредоносные нагрузки, такие как React2Shell, определённой конечной точки, например пути Node.js POST /_next/. Для проведения такого анализа можно использовать как фильтры Аналитики, так и инструмент Анализа атак.

^{Визуализация в Security Analytics предлагает представление временного ряда вредоносных нагрузок, нацеленных на конечную точку /api/. Это представление группирует данные, чтобы выделить топ-5 CVE по объёму.}

Аналитика также помогает создавать исключения и выявлять ложные срабатывания. Например, увеличение числа совпадений для конкретного правила может указывать на ложные срабатывания, а не на активную эксплуатацию. Например, приложение, позволяющее пользователям отправлять расширенный HTML-контент (например, система управления контентом или система тикетов поддержки), может на законных основаниях содержать разметку, соответствующую более общим сигнатурам XSS. В таких случаях можно применить ограниченное исключение для затронутой конечной точки, сохраняя защиту включённой для остальной части приложения. 

Такой подход особенно полезен для оценки сигнатур со средней уверенностью, которые балансируют между агрессивным блокированием и риском ложных срабатываний. Инструмент позволяет проводить сценарии «что если» на историческом трафике, чтобы эмпирически определить производительность в рабочей среде. Этот процесс помогает определить, подходит ли сигнатура со средней уверенностью для общего профиля трафика, или же высокий уровень ложных срабатываний требует ограничить её развёртывание определёнными URL-адресами или типами запросов. 

Как правило, сигнатуры, которые имеют очень низкий уровень совпадений на историческом трафике, можно безопаснее развернуть в режиме блокировки без значительного нарушения легитимного трафика. Для достижения такого уровня уверенности Security Analytics предоставляет инструменты для глубоких криминалистических расследований.

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

^{Доступен поисковый каталог сигнатур, предоставляющий более подробную информацию о критических обнаружениях, чтобы помочь клиентам понять угрозы и действия по устранению.}

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

^{Создание правила для блокировки запросов, соответствующих сигнатурам с высокой уверенностью.}

Это эквивалентно настройке развёртывания по умолчанию Managed Ruleset от Cloudflare.

Если вы хотите блокировать все запросы, соответствующие хотя бы одному правилу, вам нужно добавить тег Medium confidence (Средняя уверенность). Это эквивалентно включению всех правил Managed Ruleset от Cloudflare. В качестве альтернативы вы можете настроить несколько правил, применяя более строгое действие (например, «Блокировать») для обнаружений с высокой уверенностью и менее строгое действие (например, «Запрос подтверждения») для тех, у кого средняя уверенность.

^{Выбрав как High, так и Medium confidence, вы можете активировать правило, если совпадает любая сигнатура.}

Чтобы создать правило для блокировки конкретного CVE или вектора атаки, вы будете использовать Categories (Категории). Конструктор правил позволяет вам комбинировать теги категорий векторов атак со всеми существующими данными HTTP-запросов. Это позволяет создавать детализированные правила (или исключения) и адаптировать вашу безопасность к разным частям вашего приложения. 

^{Клиенты могут создавать правила для блокировки (или разрешения) запросов, соответствующих определённым CVE или категориям атак.}

Для создания правил на основе конкретной Signalure (Сигнатуры) вы можете использовать Ref ID (Идентификатор ссылки). Вы можете найти нужный Ref ID в конструкторе правил, изучая доступные правила Attack Signature (Сигнатура атаки). Это особенно полезно, если вы хотите создавать исключения для управления ложными срабатываниями.

^{Клиенты могут просматривать правила сигнатур прямо из конструктора правил.}

Все клиенты по-прежнему имеют доступ к нашему классическому Managed Ruleset. Когда функция Attack Signature Detection станет общедоступной, клиенты смогут выбрать модель развёртывания, которая лучше всего соответствует их потребностям: будь то Attack Signature Detection или Managed Rules. Наши команды аналитиков обеспечивают одновременный выпуск новых обнаружений как в Managed Ruleset, так и в Attack Signature Detection.

Традиционное обнаружение веб-атак в основном сосредоточено на «запросе»: HTTP-запросе. Однако запрос рассказывает только половину истории. Чтобы узнать, удалась ли атака на самом деле, нужно посмотреть на «ответ»: HTTP-ответ.

Объединяя метаданные запроса и ответа в одно событие обнаружения, мы можем dramatically reduce false positives и выявлять успешные эксплойты, которые пропускают системы, анализирующие только запросы.

Например, рассмотрим запрос, содержащий распространённую строку SQL-инъекции в параметре запроса.

GET /user?id=1' UNION SELECT username, password FROM users--

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

С Full-Transaction Detection система отмечает сигнатуру SQLi в запросе, но ждёт ответа. Если источник отвечает с 500 Internal Server Error или стандартной 404, уверенность в «успешном эксплойте» низка. Если источник отвечает с 200 OK и телом, содержащим строку, соответствующую сигнатуре «конфиденциальные данные» (например, список имён пользователей), система помечает это как Successful Exploit Confirmation (Подтверждение успешного эксплойта).

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

• Попытки эксплуатации. Обнаружение предоставляет детектирование веб-атак путём проверки всего цикла от HTTP-запроса до ответа. Оно сосредоточено на трёх ключевых областях: выявление эксплуатации входных данных, таких как XSS и SQLi, через вредоносные сигнатуры; остановка автоматизированных злоупотреблений, таких как сканирование уязвимостей; и подтверждение успешных эксплойтов путём корреляции подозрительных запросов с необычными ответами сервера.

• Сигналы раскрытия и эксфильтрации данных. Эта система также позволяет нам обнаруживать эксфильтрацию данных, которая на этапе входящего трафика выглядит как легитимный трафик. Запрос к /api/v1/export — это стандартное административное действие. Но если этот конкретный запрос вызывает ответ, содержащий, например, 5000 номеров кредитных карт (идентифицированных, скажем, через сигнатуры алгоритма Луна), транзакция помечается как Data Exposure (Раскрытие данных). 

• Некорректные конфигурации. Открытые административные интерфейсы часто являются векторами атак. Традиционные проверки безопасности упускают эту ошибку конфигурации, потому что сам трафик выглядит действительным (реальные конечные точки или административные страницы). Проблема не в трафике, а в его общедоступности. Мы расставляем приоритеты обнаружения на основе распространённых в реальном мире ошибок конфигурации, наблюдаемых в данных клиентов, таких как публичные неаутентифицированные кластеры Elasticsearch, общедоступные административные панели и раскрытые чувствительные конечные точки Apache.

Обнаружение, подобно Attack Signatures, будет сохранять результаты в двух конкретных полях. Эти поля доступны в нашей панели управления и регистрируются в Security Analytics.

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

^{Диаграмма, иллюстрирующая места выполнения и соответствующие заполненные поля для Детектирования сигнатур атак и Полного детектирования транзакций.}