Представляем обнаружение полных транзакций для Cloudflare WAF21.10.2026 17:10

Сегодня мы расширяем наш межсетевой экран веб-приложений (WAF), добавляя две новые возможности: выявление угроз с учетом всей транзакции и правила для ответов. При выявлении угроз с учетом всей транзакции каждый HTTP-запрос анализируется вместе с ответом на него, чтобы обнаружить признаки эксплуатации уязвимости. Это помогает ответить на два вопроса: «Выглядит ли этот запрос вредоносным?» и «Что произошло, когда приложение его обработало?» Затем правила для ответов могут заблокировать ответ сервера-источника, прежде чем он достигнет отправителя запроса.

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

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

Благодаря новым возможностям клиенты могут использовать управляемые Cloudflare средства защиты или создавать собственные политики, учитывающие свойства запросов и ответов. Это расширяет нашу постоянно действующую систему защиты приложений, а результаты обнаружения становятся доступны в разделе «Аналитика безопасности» и помогают расследовать инциденты. Первые управляемые средства защиты с использованием этой возможности предназначены для недавно раскрытой уязвимости php2shell.

И самое главное — мы предоставляем эти новые возможности всем клиентам Cloudflare, в том числе пользователям бесплатных тарифных планов.

Одной проверки запросов недостаточно

WAF Cloudflare защищает веб-сайты и API с помощью управляемых и пользовательских правил, а также ограничения частоты запросов. Управляемые правила обеспечивают защиту от известных методов атак и уязвимостей, а пользовательские позволяют командам создавать собственные политики на основе таких параметров, как IP-адрес, путь URL, заголовки и тело запроса. Эти механизмы работают на уровне запросов и не дают эксплойтам или нежелательному трафику достичь сервера-источника.

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

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

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

GET /download?file=../../config/database.ini

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

200 OK
Content-Type: text/plain
[database]
username=app_service
password=EXAMPLE_SECRET

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

Обнаружение и блокировка намеренно разделены

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

Структура запроса и ответа в межсетевом экране веб-приложений (WAF) Cloudflare.

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

В дополнение к полям обнаружения запросов на платформе появились следующие новые поля:

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

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

Создание правил для ответов

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

Теперь специалисты по безопасности могут объединять свойства запросов и ответов с результатами обнаружения, чтобы определять, какие ответы блокировать. Если срабатывает блокирующее правило, Cloudflare заменяет ответ сервера-источника страницей блокировки WAF или пользовательским ответом.

Настройки этапа обработки ответов доступны в нижней части страницы «Безопасность» > «Правила безопасности» в панели управления Cloudflare — как для управляемых средств защиты, так и для пользовательских правил.

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

Управляемые механизмы обнаружения

Все клиенты получают защиту благодаря полному набору механизмов выявления угроз с учетом всей транзакции, входящему в набор правил Cloudflare Managed Response Firewall Default. Он рассчитан на простое развертывание одним щелчком мыши и упрощенную настройку. При совпадении с сигнатурой управляемый механизм обнаружения заблокирует ответ и вернет стандартную страницу блокировки WAF.

Область действия набора Cloudflare Managed Response Firewall Default можно изменить, чтобы выполнять обнаружение только для части приложений — например, исключить определенные пути или ограничить ими область проверки. Платные клиенты могут использовать поля обнаружения в пользовательских правилах для ответов, создавая более адаптированные политики.

По умолчанию Cloudflare Managed Response Firewall Default применяется к каждому запросу. Чтобы снизить риск ложных срабатываний, клиенты могут ограничить область действия мер защиты частью приложения.

Пользовательские правила

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

http.request.uri.path starts_with "/admin" and not http.request.headers["x-internal-user"][0] eq "true" and http.response.code eq 200 and http.response.headers["content-type"][0] contains "text/html"

Это правило блокирует запрос, только если неаутентифицированный пользователь обращается к `/admin`, а сервер-источник действительно возвращает успешную HTML-страницу администрирования. Оно не блокирует обычные ошибки аутентификации, перенаправления и трафик, не связанный с администрированием.

Все клиенты могут создавать правила для ответов, объединяя поля запросов и ответов.

Все клиенты могут создать до трех пользовательских правил для ответов с действиями «Журналировать» и «Блокировать». Набор полей и функций, доступных в пользовательских правилах для ответов, соответствует возможностям вашего тарифного плана, уже доступным в пользовательских правилах для запросов. Создавать правила на основе тела ответа пока нельзя.

Как и в случае с обнаружением атак по сигнатурам, платным клиентам также доступны результаты обнаружения атак через перечисленные выше поля cf.waf.signature.response.*. Их можно сочетать с другими параметрами — например, именем хоста, путем URL, IP-адресом источника и заголовком запроса, — чтобы включить защиту для отдельного пути или ограничить действие политики контекстом конкретного приложения. Сейчас мы постепенно открываем доступ к полям ответов для всех учетных записей. Если они вам пока недоступны, обратитесь к своему менеджеру по работе с клиентами.

Расследование совпавших запросов

Когда управляемое или пользовательское правило для ответов журналирует транзакцию или блокирует ее, соответствующее событие становится доступно в разделе «События безопасности». Это позволяет специалистам по реагированию восстановить полный контекст запроса и определить конкретное правило, которое выполнило действие.

Сейчас правила, анализирующие только запросы, и правила, учитывающие всю транзакцию, отображаются на одной странице аналитики. В разделе «События безопасности» события, созданные правилами для ответов, относятся к службе управляемых или пользовательских правил. Чтобы отфильтровать события по определенному идентификатору правила, воспользуйтесь соответствующим разделом со списком правил.

Начните использовать уже сегодня

Выявление угроз с учетом всей транзакции доступно всем зонам, в которых трафик проходит через прокси Cloudflare. Чтобы проверить, защищена ли ваша зона, откройте раздел «Безопасность» > «Правила безопасности» в панели управления Cloudflare. Если вы хотите настроить политику, сначала изучите результаты выявления угроз с учетом всей транзакции в разделе «Аналитика безопасности», а затем создайте подходящую для вашего приложения политику на этапе обработки ответов.

© Cloudflare Blog