Привет, Хабр!

На связи Станислав Грибанов, я руководитель продуктового направления компании «Гарда», автор блога «Кибербезопасность и продуктовая экспертиза для бизнеса».

Сегодня хочу поговорить о пользе NetFlow и сетевой телеметрии для защиты сетей от хакерских атак.Тема эта не новая, но вокруг неё до сих пор существует множество противоречий.

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

Например, решение Cisco SourceFire NGIPS (datasheet 2013 года) также использует только сырой трафик, а его функциональность очень сильно пересекается с типовым отечественным анализатором сетевого трафика, позиционирующим себя, как NTA или NDR. Продукт Cisco опирается на сигнатурные методы, анализ payload, репутационные базы и комплиментарно использует машинное обучения для детекта ВПО типа червей. 

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

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

Что такое сетевая телеметрия, и зачем она нужна

Как ни странно, здесь часто возникает путаница. Некоторые ошибочно относят к сетевой телеметрии данные, собираемые агентами endpoint protection. На самом деле это не так. 

Сетевая телеметрия — это статистика сетевых потоков, собираемая с сетевого оборудования уровня L2 и выше: коммутаторов, маршрутизаторов, межсетевых экранов и других устройств. Самый распространённый протокол для сбора такой телеметрии — NetFlow. 

Немного истории

NetFlow — стандарт сетевой телеметрии, разработанный компанией Cisco в 1996 году. Фактически он стал синонимом термина «сетевая телеметрия» и самым массовым инструментом для анализа того, что происходит в сети. Существует несколько версий протокола; десятая версия известна как IPFIX (Internet Protocol Flow Information Export).

На базе NetFlow строятся решения класса NPM (Network Performance Monitoring). Например, решение известного вендора SolarWinds (уже ушедшего из России). Некоторые производители используют собственные протоколы телеметрии: NetStream (Huawei), JFlow (Juniper), AppFlow (Citrix). 

Зачем нужна сетевая телеметрия 

NetFlow позволяет детектировать угрозы в сетях, в которых сложно или невозможно получить копию сетевого трафика. Вот для примера пара таких случаев.  

Первый пример — ЦОД. Он обрабатывает огромные потоки данных в сотни Гбит/с, сложность и высокая стоимость анализа такого объёма сырого трафика делают Netflow единственным источником данных о сети в ЦОД. 

Ещё вариант — геораспределенные децентрализованные сети с большим количеством отдельных точек выхода в интернет: магазины, небольшие офисы, образовательные или медицинские учреждения и т.п. Снять копию трафика (SPAN) в таких сетях бывает сложно из-за устаревшего оборудования, ограничений каналов связи или сетевой топологии. 

Источники телеметрии

Для сбора сетевой телеметрии есть довольно широкий спектр оборудования разных производителей: от класса Enterprise, такого как Cisco, Huawei, Eltex, Juniper, Extreme, Fortinet, до решений уровня SoHo, включая Mikrotik, D-Link, TP-Link, Zyxel, Asus и других.

Сэмплирование: когда телеметрия становится бесполезной для ИБ 

Важный нюанс: задачи информационной безопасности существенно ограничивает использование сэмплированной (сокращённой) телеметрии, например, sFlow. При сэмплировании мы теряем метаданные по каждой сессии — частотность коммуникаций, индивидуальные объёмы сессий, точные количественные параметры. 

Всё это «ломает» признаки, необходимые для построения прогнозов нормального поведения хоста и детектирования аномалий. 

Для целей ИБ необходима полная телеметрия без сэмплирования.

Что даёт IPFIX? Ключевые параметры

Данные, получаемые из сетевой телеметрии, уже не раз разбирались, но я всё же повторю несколько интересных параметров IPFIX: 

• IP- и MAC-адреса отправителя и получателя;

• порты отправителя и получателя;

• транспортный протокол;

• TCP-флаги, включая причину завершения потока;

• продолжительность потока (начало и конец);

• количество пакетов и объём данных потока;

• автономные системы (AS);

• тип сервиса (TOS);

• приложение (аналог DPI) — если поддерживается на стороне экспортёра;

• метаданные HTTP: user-agent, content type и другие параметры. 

Интересно, что сетевое оборудование Cisco поддерживает собственный DPI — NBAR, который содержит обширную базу протоколов и приложений уровней L3–L7. В ином случае данные DPI могут быть переданы экспортёром в IPFIX, например, NGFW. 

ИБ-сценарии, для которых можно применять анализ на основе сетевой телеметрии

Репутационный анализ (Threat Intelligence Feeds)

Самый простой вариант — проверка IP-адресов по репутационным базам (TI feeds). Например, в нашем продукте «Гарда NDR» мы используем данные Threat Intelligence. Это фиды, включающие:

• C&C (командно-контрольные центры);

• активность ботсетей;

• DDoS;

• криптомайнинг;

• TOR, прокси;

• фишинг, вредоносное ПО;

• брутфорс, спам, подозрительные хосты. 

В расширенной версии TI feeds доступны дополнительные поля обогащения: автономные системы, дата последней активности. 

Но IP — это только начало. Как быть с именами хостов, которых в стандартной телеметрии нет? Мы используем модуль анализа DNS-запросов к корпоративным DNS-серверам и собственную систему обогащения метаданными сессий на этапе их сборки из пакетов. Это позволяет проверять хосты на соответствие спискам TI feeds. Виды репутационных списков могут быть самыми разными — главное, чтобы они содержали поддерживаемые параметры, такие как IP, имена хостов и др.

Корпоративная инфраструктура и Shadow IT 

Базовых данных IP/MAC достаточно, чтобы формировать профили подсетей по IP или портам, детектировать новые протоколы, IP-адреса или нарушение правил сетевой сегментации на межсетевых экранах.

А если нет DPI и известен только порт? Мы в этом случае используем собственную базу соответствия портов и протоколов, которая помогает выявлять нестандартные порты для известных протоколов. Понятно, что такой подход эффективен только для статических портов. Для динамических потребуется извлечение applicationId. 

С помощью сетевой телеметрии можно также детектировать некорпоративные DNS, DHCP или даже поддельные контроллеры домена. Логика проста: ищем трафик вне заданных корпоративных ресурсов. Для этого используются группы пользовательских активов. Мы применяем конструктор логических групп активов с поддержкой иерархии, чтобы масштабировать логику детектирования на территориально распределённые объекты. Например, для DHCP детектируем использование портов 67/68 для всех хостов, не входящих в группу DHCP-серверов.  

Анализ портов и протоколов также помогает выявлять, например, нарушения сегментации сети, проброс удалённого доступа и другие инциденты.

При обогащении телеметрии данными о пользователях и хостах (например, из Windows Event Collector) можно отловить использование привилегированных учётных записей или увидеть недопустимые события авторизации. 

Детектирование атак: от сигнатур к поведению 

И так мы подходим к самому интересному — детектированию атак на основе телеметрии. Здесь кроется принципиальное отличие NDR от NGIDPS.

В чём же разница?

IDPS опирается на заранее известный вредоносный payload или характерные сигнатуры, которые доступны только в полной копии трафика. В случае шифрованного трафика NGIDPS может работать только с цифровыми отпечатками и только для известных угроз. Да, часть вертикального трафика можно расшифровать через MITM, но не весь. Многие приложения не поддерживают MITM, их приходится исключать, предоставляя атакующему возможность для туннелирования. 

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

Таким образом, в любой инфраструктуре есть зоны, где NGIDPS на основе анализа payload неэффективен. То же касается инструментов Red Team с открытым исходным кодом: на каждый можно написать сигнатуру, но модификация инструмента делает сигнатуры бесполезными. APT-группировки как раз используют кастомизированные инструменты. 

Как детектировать атаки в сетевой телеметрии без payload 

Ответ — несигнатурными методами через построение профилей нормального сетевого трафика и выявление аномальных отклонений. Этот подход известен как NTA (Network Traffic Analysis) и появился ещё в 2017 году. Пионерами несигнатурного детектирования с использованием машинного обучения стали Vectra (с 2011 года) и Darktrace (с 2013 года). 

С 2020 года NTA эволюционировал в NDR. В 2025 году Gartner выпустила первый квадрант для сегмента NDR (Network Detection and Response). Все четыре лидера квадранта используют в своей работе сетевую телеметрию. 

С точки зрения несигнатурного анализа разница между полным захватом трафика и телеметрией — в объёме метаданных. ML-модели для детектирования аномальных отклонений от нормального поведения работают именно с метаданными (похоже на принцип Zeek), а не с payload, как IDPS.

Почему сетевая телеметрия становится новым трендом 

Встаёт закономерный вопрос: «Почему переход на телеметрию стал трендом именно сейчас?». Дело не только в эффективности алгоритмов, но и в физической невозможности использовать старые методы в современных инфраструктурах. Классический подход с анализом полной копии трафика (SPAN) упирается в бурный рост объёма приватной и публичной облачной инфраструктуры. Причём как с точки зрения возможностей анализа больших объёмов, так и сточки зрения стоимости. 

Мировой тренд: облака и телеметрия 

Анализ огромных объёмов данных в облаках (Amazon, Google, Azure) — современный мировой тренд. Облака поддерживают специфичный формат сетевой телеметрии — VPC Flow Logs.

Именно для работы с телеметрией в облаках Vectra приобрела стартап Netography, специализирующийся на облачной безопасности, а также на анализе NetFlow, sFlow, IPFIX и VPC Flow Logs. Основатель Netography — Марти Роуч (Marty Roesch), создатель и разработчик IDPS Snort, основатель компании SourceFire, поглощённой Cisco.

Символично, что основатель классической легендарной IDPS теперь развивает анализ сетевой телеметрии. 

Ситуация в России

В РФ по-прежнему доминирует on-prem-инфраструктура, но потребность в анализе больших объёмов данных никуда не уходит. Фактически в enterprise публичные облака заменены частными.

Главное преимущество сетевой телеметрии — её размер. Он составляет примерно 5–10 % от объёма сырых данных. Особенно это важно при высокой утилизации каналов и больших объёмах трафика. 

Детектирование угроз на основе поведенческого анализа в сетевой телеметрии 

Теперь — к сути. Как именно детектировать угрозы в сетевой телеметрии?

Спойлер: ровно так же, как и на копии трафика — по метаданным.

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

Использование ML позволяет сравнивать поведение хоста с его прогнозируемым профилем. Его можно строить двумя способами:

• исторически — сравнивая хост с самим собой за прошлые периоды;

• по схожести — сравнивая хост с другими хостами, изначально похожими на него. 

Для построения профилей применяются модели unsupervised learning (обучение без учителя). Они обучаются на данных прямо на площадке.

Для некоторых типов атак эффективнее анализировать пары («отправитель –получатель») с индивидуальным прогнозом для каждой пары. Например, это важно для брутфорс, password spraying или туннелей. 

Для повышения точности детектирования крайне важно:

• формировать индивидуальные профили для каждого хоста или пары (а не группы);

• использовать небольшие временные интервалы (например, всплеск сессий за пять минут ярко выражен, а за пять часов — размыт). 

Также unsupervised learning можно использовать для детектирования определённых типов атак. Например, коммуникаций с C&C или C2, и применения туннелей для их маскировки. Для детектирования некоторых ВПО можно использовать ML-модели, обученные на датасетах с примерами вредоносного и нормального трафика.

Для работы на сетевой телеметрии признаки ML-модели должны поддерживаться в сетевой телеметрии. 

Данный подход был реализован в Encrypted traffic analysis от компании Cisco. В решении SNA (бывший Stealthwatch) на базе обогащённой сетевой телеметрии зашифрованного трафика вендор классифицировал различные потоки, содержащие разные типы угроз.

Повышение точности с помощью TI feeds 

Обычно время жизни вредоносного IP составляет несколько часов. Точность детектирования можно увеличить, добавив в признаки сессий, на которых обучается модель ML, наличие индикаторов TI feeds. Если поведенческая модель указывает на аномалию и при этом IP присутствует в TI feeds, уверенность в компрометации хоста становится крайне высокой. 

Какие атаки можно обнаружить с помощью поведенческого анализа и ML

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

Что не поддерживается на базе сетевой телеметрии? 

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

Заключение 

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

• при высоких нагрузках на сеть (сотни гигабит и выше);

• в территориально распределённых сетях со множеством точек выхода;

• в облачных средах с огромными объёмами передаваемых данных (VPC Flow Logs).

Главный миф о том, что NetFlow — это «только для ИТ», давно опровергнут практикой. Современные NDR-решения строятся именно на несигнатурном анализе метаданных сетевого трафика, а не только на сигнатурах систем IDPS.

Этот факт подтверждает и наша аналитика. По данным проведённого нами исследования, более 50% решений класса NDR на мировом рынке работают с сетевой телеметрией и её аналогами.