Сегодня мы расширяем возможности нашего веб-прикладного межсетевого экрана (WAF), добавляя две новые функции: полную проверку транзакций и правила для ответов. Полная проверка транзакций анализирует каждый HTTP-запрос вместе с его ответом, чтобы выявить признаки эксплуатации. Это помогает ответить на вопросы: «Выглядит ли этот запрос вредоносным?» и «Что произошло, когда приложение его обработало?». Правила для ответов позволяют блокировать ответ сервера-источника до того, как он достигнет отправителя запроса.
Эти механизмы защиты ценны, поскольку новейшие фронтирные модели выявляют уязвимости, скрытые глубоко в широко используемом программном обеспечении, давая защитникам понимание того, что нужно исправить, а злоумышленникам — новые пути для атак. Недавняя уязвимость php2shell показывает масштаб ставок: дефект в распространённом программном компоненте может подвергнуть риску приложения по всему Интернету. ИИ-агенты, сканирующие уязвимости, могут быть чрезвычайно настойчивыми, адаптируя полезные нагрузки на основе обратной связи и выстраивая цепочки из уязвимостей, учётных данных и разрешений. Ответ приложения может показать, удалась ли попытка, и дать атакующему информацию, помогающую продвинуться глубже.
Проверка входящих запросов остаётся необходимой для остановки распознаваемых атак до того, как они достигнут приложения. Однако некоторые угрозы становятся очевидными только при рассмотрении запроса вместе с тем, что возвращает сервер-источник. Подозрительный ввод, за которым следует ответ, раскрывающий конфиденциальную информацию, рассказывает совсем иную историю, чем тот же ввод, за которым следует отказ или ошибка.
С этими новыми возможностями клиенты могут использовать управляемые защиты Cloudflare или создавать собственные политики, объединяющие свойства запросов и ответов. Это расширяет нашу постоянно действующую систему защиты приложений, а результаты обнаружения доступны в Security Analytics для поддержки расследований. Наши первые управляемые защиты, использующие эту возможность, устраняют недавно раскрытую уязвимость php2shell.
И самое приятное? Мы делаем эти новые возможности общедоступными для всех клиентов Cloudflare, включая бесплатные тарифные планы.
Проверки запросов недостаточно
Cloudflare WAF обеспечивает защиту сайтов и 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 ещё до того, как он достигнет запрашивающей стороны, эффективно блокируя эксплойт за счёт недопущения попадания конфиденциальной информации к атакующему.
Обнаружение и смягчение последствий разделены по замыслу
Обнаружение на уровне полной транзакции расширяет фреймворк постоянного обнаружения, представленный нами ранее в этом году. Детекторы анализируют трафик и прикрепляют метаданные к запросу и ответу, а правила затем решают, что делать с этими результатами.
Разделение этих задач даёт клиентам видимость ещё до того, как они разработают политику. Команды безопасности могут изучать срабатывания детекторов в своём трафике, понимать, какие эндпоинты и сигнатуры задействованы, и выбирать ответ, подходящий для их приложения. Подобно подходу для основанного на запросах обнаружения сигнатур атак, результаты работы детекторов сохраняются в полях, к которым можно обращаться в пользовательских правилах ответа или использовать в управляемых детекторах для блокировки трафика.
По аналогии с полями обнаружения запросов в нашу платформу добавлены следующие новые поля:
Поле
Описание
cf.waf.signature.response.confidence
Значения уверенности, связанные с совпавшими сигнатурами
cf.waf.signature.response.categories
Категории, связанные с совпавшими сигнатурами
cf.waf.signature.response.ref
Идентификаторы ссылок сигнатур, до 10
Первые детекторы полной транзакции сосредоточены на подтверждении эксплуатации для широко известных уязвимостей. Они сопоставляют подозрительный ввод с сигналами ответа, указывающими на то, что эксплойт мог увенчаться успехом.
Со временем мы расширим охват, поддержав другие сценарии использования, включая обнаружение утечки данных и сигналов эксфильтрации. Это важно для Интернета в целом, а не для какого-то одного приложения: защита может отличать зондирование от свидетельств воздействия, а обнаружение раскрытых данных и сервисов может охватить клиентов, у которых нет выделенной команды безопасности, настраивающей каждое правило WAF.
Создание правил для ответа
Обнаружение признаков эксплуатации уязвимостей приносит максимальную пользу, когда вы можете реагировать на них в режиме реального времени. Пользовательские правила реагирования превращают полные детекции транзакций в защиту на лету, блокируя соответствующий ответ источника до того, как он достигнет запрашивающей стороны, хотя они не могут отменить действия, уже выполненные на источнике.
Теперь команды безопасности могут комбинировать свойства запросов и ответов с результатами детекции, чтобы определять, какие ответы блокировать. Когда срабатывает правило блокировки, Cloudflare заменяет ответ источника страницей блокировки WAF или пользовательским ответом.
Элементы управления фазой ответа доступны в панели управления Cloudflare в нижней части страницы Security > Security Rules, включая как управляемые защиты, так и пользовательские правила.
Мы выпустили как управляемые, так и пользовательские правила для всех тарифных планов, включая бесплатные. Со временем мы будем придерживаться того же подхода, который используем для детекции запросов, где управляемые детекции для бесплатных планов сфокусированы на широко известных уязвимостях, а платные клиенты получают более обширный каталог детекций.
Управляемые детекции
Все клиенты получают защиту полного набора детекций транзакций через набор правил Cloudflare Managed Response Firewall Default, который разработан для простого развёртывания в один клик и упрощённой настройки. При совпадении сигнатуры управляемая детекция блокирует ответ и возвращает стандартную страницу блокировки WAF.
Вы можете изменить область действия 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-страницу администрирования. Это не блокирует обычные ошибки аутентификации, перенаправления или трафик, не связанный с администрированием.
Каждый клиент может настроить до трёх пользовательских правил реагирования с действиями Log и Block. Поля и функции, доступные для пользовательских правил реагирования, полностью соответствуют тем, что уже предоставляются вашим тарифом в разделе пользовательские правила запросов. Создание правил на основе тела ответа пока недоступно.
В соответствии с подходом Attack Signature Detection, платные клиенты также получают доступ к результатам обнаружения атак через поля cf.waf.signature.response.*, перечисленные выше. Эти поля можно комбинировать с другими параметрами (такими как имя хоста, путь URL, IP-адрес источника, заголовок запроса), чтобы включить защиту на отдельном пути или ограничить политику контекстом конкретного приложения. В настоящее время мы постепенно открываем поля ответа для всех аккаунтов. Если они вам ещё недоступны, обратитесь к вашей команде поддержки.
Анализ совпадающих запросов
Когда управляемое или пользовательское правило реагирования регистрирует или блокирует транзакцию, событие становится доступно в разделе Security Events. Это позволяет специалистам по реагированию проследить любое обнаружение вплоть до полного контекста запроса и конкретного правила, которое применило действие.
На данный момент правила, работающие только с запросами, и правила для полных транзакций отображаются вместе на одной странице аналитики. В Security Events события, сгенерированные правилами реагирования, относятся к сервису Managed Rules или Custom Rules. Вы можете отфильтровать события, принадлежащие конкретному ID правила, в соответствующем разделе списка правил.
Начните уже сегодня
Обнаружение на уровне полных транзакций общедоступно для всех зон, проксирующих трафик через Cloudflare. Чтобы убедиться в наличии защиты, перейдите в раздел Security > Security Rules панели управления Cloudflare. Если вы хотите настроить свою политику, начните с изучения обнаружений полных транзакций в Security Analytics, а затем создайте политику фазы реагирования, подходящую для вашего приложения.