Graylog показывает скачок DNS-трафика: рабочая станция из HR-отдела отправила за ночь 47 000 DNS-запросов вместо обычных 250. Первый рефлекс - adware. Через 35 минут разбора NetFlow-записей картина поменялась: каждый запрос содержал поддомен из 63 символов к серверу в Юго-Восточной Азии. DNS-туннель - Protocol Tunneling (T1572, Command and Control) по MITRE ATT&CK. EDR молчал: DNS-запросы формально легитимны. Аномалию поймал единственный источник - NetFlow с border-маршрутизатора.
По данным CrowdStrike Global Threat Report 2025, 75% вторжений используют действительные учётные данные без единого вредоносного файла. Сигнатуры тут бесполезны. Работает сетевая телеметрия.
Что NetFlow даёт SOC-аналитику и где его пределы
NetFlow (v5, v9), IPFIX и sFlow - протоколы экспорта метаданных сетевого трафика. Маршрутизатор или коммутатор не копирует пакеты целиком, а формирует flow-запись: src/dst IP, src/dst port, протокол, количество байт и пакетов, длительность сессии, TCP-флаги. Компактно и масштабируемо: хранение flow-данных при 10 000 потоков в секунду занимает около 1-5 ГБ в сутки против сотен гигабайт при full packet capture.
Для обнаружения аномалий в сети этих полей хватает, чтобы зафиксировать C2-beaconing, lateral movement, эксфильтрацию и сканирование - без расшифровки TLS и инспекции payload. Детектор анализирует не содержимое, а поведение: кто с кем общается, когда, сколько данных передаёт и по каким протоколам. Подход Vectra к network anomaly detection построен ровно на этом принципе.
Но у NetFlow чёткие ограничения, и знать о них нужно до того, как строить detection-стек.
Payload невидим. Если атакующий маскирует C2 внутри легитимного HTTPS к CDN-провайдеру с обычным объёмом и периодичностью, flow-анализ его не отличит от браузинга. Сэмплирование (1:100 на крупных магистралях) режет мелкие потоки - единичное подключение по RDP может просто не попасть в выборку. NetFlow - один слой detection-стека, а не замена DPI, EDR или корреляции в SIEM.
| Параметр | NetFlow / IPFIX | Full packet capture |
|---|---|---|
| Хранение (канал 10 Гбит/с) | 1-5 ГБ/сутки | 100+ ГБ/сутки |
| Видимость payload | Нет | Да |
| Масштабируемость | Высокая | Ограниченная |
| Encrypted traffic | Только метаданные | Только метаданные (без MitM) |
| Retention 90+ дней | Реально | Петабайты, нереально для большинства |
Построение baseline: без него все пороги - шум
NIST Cybersecurity Framework v2.0 в субкатегории DE.AE-01 прямо требует: "A baseline of network operations and expected data flows for users and systems is established and managed""Устанавливается и контролируется базовый уровень работы сети и ожидаемые потоки данных для пользователей и систем". На практике это значит одно: пока нет baseline, любое пороговое правило будет либо молчать, либо генерировать сотни ложных срабатываний в сутки.Требования к окружению
Прежде чем строить baseline, нужна работающая инфраструктура сбора:- Сетевое оборудование с поддержкой NetFlow v9 или IPFIX (Cisco, Juniper, MikroTik, Huawei)
- Коллектор: nfdump 1.7+ (свободный, GNU/Linux) или ntopng 5.x+, или SiLK 3.x+ для крупных сетей
- SIEM: Elastic 8.x+ с модулем Filebeat NetFlow, или Splunk Enterprise с Stream add-on, или Graylog с NetFlow-плагином
- RAM коллектора: минимум 4 ГБ, рекомендуется 8 ГБ при > 10 000 flows/sec
- Дисковое пространство: 1-5 ГБ/сутки при сэмплировании 1:1 на среднем корпоративном канале
Методика построения baseline
Период сбора - 2-4 недели чистого трафика (по данным Vectra, это стандартная практика). За это время фиксируются:- Top talkers по src_ip и dst_ip - нормальные объёмы трафика для каждого сегмента
- Протокольное распределение - доля TCP/UDP/ICMP, типичные порты
- Bytes per flow - средний и медианный размер потока по подсетям
- Временные паттерны - рабочие часы vs ночное время, будни vs выходные
- Географическое распределение - нормальные ASN и GeoIP-назначения
Быстрый срез top-talkers по подсети через
nfdump:
Bash:
nfdump -R /data/flows/2025/06/01-07 -s srcip/bytes -n 20 -f "src net 10.10.0.0/16"Обнаружение C2-каналов через NetFlow
C2-коммуникации - Application Layer Protocol (T1071), Non-Application Layer Protocol (T1095), Non-Standard Port (T1571) - имеют характерный паттерн в flow-данных, даже когда payload зашифрован.
Beaconing - периодические обращения агента к C2-серверу - оставляет в NetFlow чёткие следы:
- Регулярные интервалы: подключения каждые 30-60 секунд с jitter менее 10-15%. Легитимный трафик такой точностью не отличается - браузер, почтовый клиент и обновления работают асинхронно
- Малые объёмы per flow: типичный beacon - 100-500 байт в каждую сторону (heartbeat + команда). Если avg_bytes < 1 КБ при > 50 подключений в час к одному dst_ip - это сигнал
- Единственный destination: один внешний IP или узкий пул адресов, не входящий в baseline
- Нестандартные порты (T1571): использование 8080, 8443, 4443 вместо стандартных 80/443
netflow), который ловит подозрительный beaconing:
Код:
index=netflow dest_port=443 NOT dest_ip IN (cdn_whitelist)
| bin _time span=5m
| stats count avg(bytes) as avg_b by src_ip dest_ip _time
| where count > 10 AND avg_b < 1000
| stats stdev(count) as jitter avg(count) as avg_c by src_ip dest_ip
| where jitter/avg_c < 0.15date_histogram по @timestamp с интервалом 5 минут, затем terms по source.ip + destination.ip с фильтром по network.bytes < 1000.IBM X-Force Threat Intelligence Index 2025 фиксирует рост атак с использованием действительных учётных данных на 71% год к году. C2-каналы всё чаще работают от имени легитимных пользователей, и только поведенческий анализ сетевой телеметрии ловит аномалию.
Ограничение, о котором забывают: легитимные polling-сервисы (мониторинг, NTP, heartbeat к SaaS-платформам) тоже дают регулярные интервалы. Whitelist таких сервисов по dst_ip/dst_port обязателен для снижения false positives. Без whitelist'а первую неделю после включения правила дашборд будет завален десятками ложных алертов - и аналитики начнут их игнорировать. А потом пропустят настоящий beacon.
Lateral movement в сетевой телеметрии: детект без DPI
Lateral movement - расширение плацдарма внутри сети, Network Service Discovery (T1046) - один из самых заметных паттернов в NetFlow, если знать куда смотреть.По данным CrowdStrike Global Threat Report 2025, среднее время от initial access до начала lateral movement - 62 минуты, а рекорд сократился до 51 секунды. У SOC максимум час на обнаружение первого хопа. NetFlow-мониторинг угроз в реальном времени - один из немногих способов уложиться в этот window.
Характерные маркеры в flow-данных:
- Всплеск внутренних подключений на портах 445 (SMB), 3389 (RDP), 5985 (WinRM), 22 (SSH) с одного src_ip. Порог: > 10 уникальных dst_ip на порту 445 с одного источника за 5 минут
- Однородные малые потоки: при сканировании подсети flow-записи выглядят характерно - одинаковый dst_port, bytes_per_flow 98-150 байт (SYN/RST для TCP-сканирования), десятки dst_ip
- Активность в нерабочие часы: RDP-подключение от рабочей станции HR к файловому серверу в 2:00 при baseline с нулевым трафиком из этой подсети ночью - алерт уровня high. Тут даже думать не надо
- Peer-group отклонение: если ни одна другая машина из подсети 10.10.5.0/24 никогда не подключалась к серверу 10.20.1.15 на порту 445, а одна вдруг начала - это аномалия даже при минимальном объёме трафика
source.ip: 10.0.0.0/8 AND destination.ip: 10.0.0.0/8 AND destination.port: (445 OR 3389 OR 5985), затем агрегация по source.ip с подсчётом уникальных destination.ip. Порог > 10 за 5 минут - кандидат на расследование. В Splunk Enterprise та же логика через stats dc(dest_ip) as targets by src_ip с фильтрами по внутренним подсетям и целевым портам.Эксфильтрация: паттерны утечки данных в сетевой телеметрии
Эксфильтрация через альтернативные протоколы - Exfiltration Over Alternative Protocol (T1048) и Protocol Tunneling (T1572) - оставляет в NetFlow отчётливые следы даже без доступа к содержимому пакетов.DNS-туннель (тот самый кейс из начала). Нормальный хост генерирует 200-500 DNS-запросов в сутки. При DNS-туннелировании - тысячи. Кроме аномального количества, нетипичен bytes_per_flow: обычный DNS-ответ - 100-200 байт, при туннелировании ответы раздуваются до максимальных 512 байт (UDP) или больше (TCP). Порог для алерта: > 5 000 DNS-запросов в сутки от одного хоста ИЛИ средний размер DNS-ответа > 400 байт.
HTTPS slow-drip exfiltration. Атакующий выгружает данные небольшими порциями через легитимный HTTPS. Маркер в NetFlow - устойчивый поток данных к одному dst_ip с соотношением bytes_out / bytes_in > 10:1. Обычный HTTPS-браузинг даёт обратное: пользователь отправляет мало (GET-запросы), получает много (HTML, JS, медиа). Если хост стабильно отдаёт больше, чем получает - что-то не так.
Аномальные исходящие объёмы. Baseline показывает, что средний хост из подсети бухгалтерии отправляет наружу 50-200 МБ в сутки. Если один хост вдруг отправил 5 ГБ за ночь - даже без анализа payload понятно, что происходит. Порог: bytes_out > 3x от среднего baseline за сутки.
Медианное время нахождения злоумышленника в сети - 11 дней, по данным Mandiant M-Trends 2025. Большинство эксфильтраций происходит в последние 24-48 часов перед обнаружением. NetFlow-мониторинг с правильными порогами по исходящему трафику сокращает этот window of exposure.
Скомпрометированный легитимный хост и insider threat
Русскоязычные материалы по анализу сетевого трафика Blue Team почти не затрагивают тему insider threat - а это один из самых тяжёлых кейсов для SOC. Mandiant M-Trends 2025 указывает, что 57% организаций узнают об инциденте от внешней стороны. Часть этих инцидентов связана не с внешним атакующим, а с действиями изнутри - скомпрометированным хостом или инсайдером.NetFlow позволяет строить per-host baseline и фиксировать отклонения:
- Новые направления: хост, который годами общался только с внутренними серверами и Microsoft 365, вдруг начинает подключаться к IP-адресам в нетипичных ASN. Сам факт нового dst_ip, отсутствующего в 30-дневном baseline - повод копнуть глубже
- Смена временного профиля: пользователь работал с 9 до 18, а теперь генерирует трафик в 3 часа ночи. Если учётные данные скомпрометированы - именно так выглядит использование аккаунта атакующим из другого часового пояса
- Обращение к нетипичным внутренним ресурсам: рабочая станция менеджера по продажам начала обращаться к серверам разработки или базам данных с персональными данными. Через NetFlow это видно по комбинации dst_ip + dst_port, даже если действия выполнены через легитимную сессию
- Постепенный рост исходящего трафика: не резкий скачок, а плавное увеличение на 10-15% в неделю. Простой порог его не поймает - нужен тренд-анализ по 4-недельному окну. Именно такие вещи пропускают чаще всего
source.ip и метрикой sum(network.bytes) - при отклонении > 3 sigma система генерирует алерт без необходимости вручную выставлять жёсткие пороги. Но ML-модели требуют минимум 2 недели обучения на чистых данных, и до этого момента полагаться на них нельзя.Чеклист: настройка NetFlow-мониторинга за первую неделю
Конкретные действия для SOC-команды, начинающей работу с SIEM и NetFlow-интеграцией:Восемь из двенадцати пунктов реализуются за первую неделю. Остальные четыре (baseline, whitelist, GeoIP-обогащение, ревизия порогов) требуют 2-4 недели наблюдения.
За три года работы с NetFlow-данными в разных SOC-командах я вижу одну и ту же ошибку: команда покупает NTA-решение с ML-движком, подключает его к зеркалу трафика и ждёт, что "нейронка всё найдёт". Через месяц дашборд завален тысячами алертов, 95% - ложные. ML-модель не обучена, baseline не построен, whitelist не заведён. Через два месяца систему начинают игнорировать.
Для 80% типичных инцидентов - beaconing, lateral movement, DNS-туннель, массовая эксфильтрация - хватает пороговых правил на nfdump + Elastic. Десять правил корреляции из чеклиста выше, настроенных вручную под конкретную инфраструктуру, ловят больше реальных инцидентов, чем коробочная ML-платформа без тюнинга. ML нужен на этапе, когда простые правила уже работают и нужно ловить то, что они пропускают: slow-drip эксфильтрацию, нетипичные peer-group отклонения, сезонные аномалии. Начинать с ML - строить крышу без фундамента.
Второй момент - retention. Flow-данные компактны, но SOC-команды часто хранят их 7-14 дней из-за дисковых ограничений. При медианном dwell time в 11 дней (Mandiant M-Trends 2025) к моменту обнаружения инцидента flow-логи за начало атаки уже стёрты. 90 дней retention на NetFlow при 5 ГБ/сутки - это 450 ГБ. Стоимость дискового пространства для этого объёма - несколько тысяч рублей. Сэкономить на этом и потерять возможность провести полноценное расследование - решение, которое трудно объяснить руководству после инцидента.
Если в вашем SIEM пока нет правил корреляции под NetFlow - на codeby.net в треде по network threat hunting коллеги обмениваются рабочими конфигурациями под конкретные коллекторы и SIEM-платформы.
Последнее редактирование модератором:
