Как расследовать многоуровневые кибератаки: новые возможности Log Explorer

В мире кибербезопасности отдельная точка данных редко раскрывает полную картину. Современные злоумышленники не просто стучатся во входную дверь; они зондируют ваши API, заполняют вашу сеть "шумом", чтобы отвлечь команду, и пытаются проскользнуть через приложения и серверы, используя украденные учетные данные.

Чтобы остановить эти многомерные атаки, вам нужна полная картина. Используя Cloudflare Log Explorer для проведения расследований в области безопасности, вы получаете круговую видимость благодаря интеграции 14 новых наборов данных, охватывающих всю поверхность портфелей продуктов Cloudflare Application Services и Cloudflare One. Коррелируя телеметрию HTTP-запросов на уровне приложений, журналов DDoS и межсетевого экрана на сетевом уровне и событий Zero Trust Access, аналитики безопасности могут значительно сократить среднее время до обнаружения (MTTD) и эффективно разоблачить сложные многоуровневые атаки.

Читайте дальше, чтобы узнать больше о том, как Log Explorer предоставляет командам безопасности идеальную основу для быстрого углубленного расследования.

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

Cloudflare Log Explorer объединяет эти журналы в единый интерфейс для быстрого расследования.

Фокус: Веб-трафик, события безопасности и производительность на границе.

Фокус: Внутренняя безопасность, Zero Trust, административные изменения и сетевая активность.

Получите детальную видимость на уровне приложений с помощью HTTP-запросов, событий межсетевого экрана и DNS-журналов, чтобы точно видеть, как трафик достигает ваших публичных ресурсов. Отслеживайте внутреннее перемещение с помощью запросов доступа (Access Requests), журналов шлюза (Gateway logs) и журналов аудита (Audit logs). Если учетные данные скомпрометированы, вы увидите, куда они направились. Используйте Magic IDS и журналы сетевой аналитики (Network Analytics logs), чтобы обнаружить объемные атаки и латеральное перемещение "с востока на запад" (East-West) внутри вашей частной сети.

Злоумышленники используют сканеры и другие инструменты для поиска точек входа, скрытых каталогов или уязвимостей программного обеспечения. Чтобы выявить это, используя Log Explorer, вы можете запросить в http_requests любые коды EdgeResponseStatus 401, 403 или 404, поступающие с одного IP-адреса, или запросы к чувствительным путям (например, /.env, /.git, /wp-admin).

Кроме того, журналы magic_ids_detections также могут использоваться для выявления сканирования на сетевом уровне. Эти журналы обеспечивают видимость на уровне пакетов для угроз, нацеленных на вашу сеть. В отличие от стандартных HTTP-журналов, эти журналы ориентированы на обнаружение на основе сигнатур на сетевом и транспортном уровнях (IP, TCP, UDP). Выполняйте запросы, чтобы обнаружить случаи, когда один SourceIP вызывает несколько уникальных обнаружений в широком диапазоне значений DestinationPort за короткий промежуток времени. Сигнатуры Magic IDS могут специально помечать такие действия, как сканирование Nmap или скрытое SYN-сканирование.

Пока злоумышленник проводит разведку, он может попытаться замаскировать её одновременной сетевой атакой типа "флуд". Перейдите к журналам network_analytics_logs, чтобы увидеть, не используется ли объёмная атака в качестве дымовой завесы.

Как только злоумышленники выявляют потенциальную уязвимость, они начинают создавать своё оружие. Злоумышленник отправляет вредоносные полезные нагрузки (например, SQL-инъекции или загрузку больших/повреждённых файлов), чтобы подтвердить уязвимость. Проверьте http_requests и/или fw_events, чтобы определить, сработали ли какие-либо инструменты обнаружения Cloudflare. Cloudflare записывает сигналы безопасности в эти наборы данных, чтобы легко идентифицировать запросы с вредоносными полезными нагрузками с помощью полей, таких как WAFAttackScore, WAFSQLiAttackScore, FraudAttack, ContentScanJobResults и многих других. Ознакомьтесь с нашей документацией, чтобы полностью понять эти поля. Журналы fw_events можно использовать, чтобы определить, прошли ли эти запросы через защиту Cloudflare, изучая поля action, source и ruleID. Управляемые правила Cloudflare по умолчанию блокируют многие из этих полезных нагрузок. Проверьте Обзор безопасности приложений, чтобы узнать, защищено ли ваше приложение.

^{Показано окно сведений об Управляемых правилах, которое отображается в Обзоре безопасности, если для текущей зоны не включены Управляемые правила}

Удалось ли этому подозрительному IP-адресу войти в систему? Используйте поле ClientIP для поиска в журналах access_requests. Если вы видите "Decision: Allow" для чувствительного внутреннего приложения, вы понимаете, что учётная запись скомпрометирована.

Злоумышленники иногда используют DNS-туннелирование для обхода межсетевых экранов, кодируя конфиденциальные данные (например, пароли или SSH-ключи) в DNS-запросы. Вместо обычного запроса, такого как google.com, в журналах будут отображаться длинные закодированные строки. Ищите необычно большое количество запросов к уникальным, длинным и высокоэнтропийным поддоменам, изучая поля: QueryName: Ищите строки типа h3ldo293js92.example.com, QueryType: Часто использует записи TXT, CNAME или NULL для передачи полезной нагрузки, и ClientIP: Определите, генерирует ли один внутренний хост тысячи таких уникальных запросов.

Кроме того, злоумышленники могут попытаться скрыть конфиденциальные данные в нестандартных протоколах или использовать обычные протоколы (такие как DNS или ICMP) необычными способами для обхода стандартных межсетевых экранов. Выявите это, запросив журналы magic_ids_detections, чтобы найти сигнатуры, помечающие аномалии протоколов, такие как обнаружения "ICMP tunneling" или "DNS tunneling" в поле SignatureMessage.

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

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

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

Сценарий: Пользователь проходит аутентификацию через Cloudflare Access, но его последующий HTTP-трафик выглядит как бот.

Шаг 1: Определите сессии с высоким риском в http_requests.

SELECT RayID, ClientIP, ClientRequestUserAgent, BotScore
FROM http_requests
WHERE date = '2026-02-22' 
  AND BotScore < 20 
LIMIT 100

Шаг 2: Скопируйте RayID и выполните поиск в access_requests, чтобы увидеть, с какой учётной записью пользователя связана эта подозрительная бот-активность.

SELECT Email, IPAddress, Allowed
FROM access_requests
WHERE date = '2026-02-22' 
  AND RayID = 'INSERT_RAY_ID_HERE'

Сценарий: Сотрудник перешёл по ссылке в фишинговом письме, что привело к компрометации его рабочей станции. Эта рабочая станция отправляет DNS-запрос на известный вредоносный домен, а затем немедленно вызывает срабатывание сигнала IDS.

Шаг 1: Найдите фишинговые атаки, проверив оповещения email_security_alerts на нарушения.

SELECT Timestamp, Threatcategories, To, Alertreason
FROM email_security_alerts
WHERE date = '2026-02-22' 
  AND Threatcategories LIKE 'phishing'

Шаг 2: Используйте журналы Access, чтобы сопоставить email пользователя (To) с его IP-адресом.

SELECT Email, IPAddress
FROM access_requests
WHERE date = '2026-02-22' 

Шаг 3: Найдите внутренние IP-адреса, запрашивающие конкретный вредоносный домен в журналах gateway_dns.

SELECT SrcIP, QueryName, DstIP, 
FROM gateway_dns
WHERE date = '2026-02-22' 
  AND SrcIP = 'INSERT_IP_FROM_PREVIOUS_QUERY'
  AND QueryName LIKE '%malicious_domain_name%'

Сценарий: Пользователь входит через Zero Trust, а затем пытается сканировать внутреннюю сеть.

Шаг 1: Найдите успешные входы из неожиданных мест в access_requests.

SELECT IPAddress, Email, Country
FROM access_requests
WHERE date = '2026-02-22' 
  AND Allowed = true 
  AND Country != 'US' -- Замените на страну вашего головного офиса

Шаг 2: Проверьте, не вызывает ли этот IPAddress срабатывание сигнатур на сетевом уровне в magic_ids_detections.

SELECT SignatureMessage, DestinationIP, Protocol
FROM magic_ids_detections
WHERE date = '2026-02-22' 
  AND SourceIP = 'INSERT_IP_ADDRESS_HERE'

С самого начала Log Explorer создавался с учётом расширяемости. Схема каждого набора данных определена с использованием JSON Schema, широко принятого стандарта для описания структуры и типов данных JSON. Это конструктивное решение позволило нам легко выйти за пределы HTTP-запросов и событий брандмауэра и охватить весь спектр телеметрии Cloudflare. Тот же подход, основанный на схемах, который питал наши первоначальные наборы данных, естественным образом масштабировался, чтобы вместить логи Zero Trust, сетевую аналитику, оповещения безопасности электронной почты и всё остальное.

Что более важно, эта стандартизация открывает двери для приёма данных за пределами собственной телеметрии Cloudflare. Поскольку наш конвейер приёма данных управляется схемами, а не жёстко запрограммирован, мы готовы принимать любые структурированные данные, которые можно выразить в формате JSON. Для команд безопасности, управляющих гибридными средами, это означает, что Log Explorer в конечном итоге может служить единой панелью управления, коррелируя телеметрию периметра Cloudflare с журналами из сторонних источников, всеми запрашиваемыми через тот же SQL-интерфейс. Хотя сегодняшний выпуск сосредоточен на завершении охвата продуктового портфеля Cloudflare, архитектурный фундамент заложен для будущего, в котором клиенты смогут подключать свои собственные источники данных с пользовательскими схемами.

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

Вот почему мы оптимизировали наш процесс приёма данных для повышения скорости и устойчивости. Увеличив параллелизм в одной части нашего пути приёма данных, мы устранили узкие места, которые могли вызывать проблемы "шумного соседа", гарантируя, что всплеск данных одного клиента не замедлит видимость другого. Эта архитектурная работа снизила нашу задержку приёма данных P99 примерно на 55%, а P50 — на 25%, сократив время, необходимое для того, чтобы событие на периметре стало доступным для ваших SQL-запросов.

^{График в Grafana, показывающий снижение задержки приёма данных после архитектурных улучшений}

Мы только начинаем. Мы активно работаем над ещё более мощными функциями, чтобы улучшить ваш опыт работы с Log Explorer, включая возможность запускать эти запросы для обнаружения по заданному вами расписанию. 

^{Макет дизайна готовящейся функции Log Explorer Scheduled Queries}

Подпишитесь на блог и следите за новыми обновлениями Log Explorer в нашем Журнале изменений.