Сбор журналов сетевого трафика

от

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

Зачем собирать сетевые логи

Каждый пакет, проходящий через сеть, содержит не только полезную нагрузку, но и метаданные: IP-адреса отправителя и получателя, порты, тип протокола, временные метки и размер. Эти данные формируют объективную картину происходящего, независимую от журналов отдельных приложений или систем. Они становятся основой для трёх ключевых задач: расследования инцидентов, мониторинга производительности и соответствия регуляторным требованиям, таким как 152-ФЗ и приказы ФСТЭК, которые предписывают регистрацию событий безопасности.

Архитектура системы сбора определяется её целями. Расследование сложных инцидентов или анализ вредоносного ПО требует полного захвата пакетов (Full Packet Capture) с сохранением содержимого. Для мониторинга трафика, планирования загрузки каналов или биллинга достаточно агрегированных flow-данных (NetFlow, IPFIX), которые сокращают объём информации на 95-99%. Требования регуляторов диктуют сроки хранения и меры по обеспечению целостности логов. Попытка сохранять всё и всегда ведёт к неподъёмным затратам на хранилище.

Главное техническое ограничение — объём. Гигабитный канал, полностью загруженный, генерирует около 125 мегабайт сырых данных в секунду. Без продуманной фильтрации и агрегации дисковое пространство закончится за несколько часов. Эффективная стратегия — многоуровневая: сбор flow-данных по всей инфраструктуре для общей картины и выборочный полный захват пакетов на критичных сегментах, например, на границе сети или в сегментах с важными данными.

Уровни детализации сетевых логов

Уровень Что фиксируется Объём данных Сценарии использования
Flow-данные Ключевые атрибуты потока: IP-адреса и порты источника/назначения, протокол, количество пакетов и байт, флаги. ~100 байт на поток, сжатие до 1% от raw-трафика. Мониторинг трафика, обнаружение аномалий, биллинг, планирование мощности.
Логи сессий Расширенные данные о сессии: длительность, состояние TCP, распознанный протокол приложения (HTTP, DNS), метаданные TLS. ~500 байт на сессию, до 5% от raw. Анализ работы приложений, детектирование угроз, поиск неисправностей.
Полный захват пакетов (FPC) Полные пакеты с заголовками и полезной нагрузкой, включая реассемблированные потоки данных. 100% трафика, ~125 MB/s на 1 Gbps канал. Форензик-анализ, глубокое расследование инцидентов, анализ вредоносного ПО.
Извлечение метаданных Выделенные объекты: передаваемые файлы, SSL/TLS-сертификаты, DNS-запросы, заголовки HTTP. Зависит от трафика, обычно 10-20% от raw. Контроль утечек информации (DLP), обнаружение malware, отчётность для compliance.

Методы сбора сетевого трафика

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

SPAN / Mirror порты

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

Критичный недостаток — ненадёжность при перегрузке. Пропускная способность SPAN-порта ограничена, и коммутатор, как правило, молча отбрасывает пакеты, которые не успевает скопировать, когда нагрузка превышает его возможности. Кроме того, многие модели не копируют ошибочные кадры и пакеты, отброшенные самим коммутатором.

! Конфигурация SPAN на коммутаторе Cisco
monitor session 1 source interface Gi0/1 both
monitor session 1 source interface Gi0/2 rx
monitor session 1 destination interface Gi0/24
no monitor session 1 filter packet-type good

Сетевой TAP

Аппаратное устройство, которое физически встраивается в разрыв сетевого кабеля. Оно пассивно копирует оптический или электрический сигнал, создавая точные копии трафика в обоих направлениях. Гарантирует нулевую потерю пакетов даже при пиковых нагрузках.

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

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

# Пример конфигурации пакетного брокера
input port 1-4: 10Gbps TAP feeds
output port 5-6: 10Gbps to capture servers
filter: vlan 100-200 → port 5
filter: vlan 300-400 → port 6
load-balance: src-dst-ip hash

Экспорт потоков (NetFlow / IPFIX)

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

Современный стандарт IPFIX (на основе NetFlow v9) поддерживает шаблоны, позволяя экспортировать произвольные дополнительные поля. Для снижения нагрузки на устройство может использоваться сэмплирование (анализ каждого N-го пакета), но это приводит к потере информации о короткоживущих потоках.

! Настройка NetFlow/IPFIX на маршрутизаторе Cisco
flow exporter FLOW-EXPORT
 destination 192.168.1.100
 transport udp 2055
 source GigabitEthernet0/0
!
flow monitor FLOW-MONITOR
 exporter FLOW-EXPORT
 cache entries 10000
 cache timeout active 60
 record netflow ipv4 original-input
!
interface GigabitEthernet0/1
 ip flow monitor FLOW-MONITOR input

Агентский сбор на хостах

Программные агенты, установленные на конечных серверах и рабочих станциях, перехватывают трафик на уровне операционной системы (через libpcap, eBPF, аудит ядра). Этот метод уникален тем, что видит трафик уже после расшифровки TLS (если терминация происходит на хосте) и фиксирует локальную межпроцессную коммуникацию (loopback).

Инструменты: osquery для сбора разнородных данных, eBPF-программы для низкоуровневого мониторинга. Недостаток — нагрузка на ресурсы хоста и сложность управления парком агентов.

// Пример eBPF-программы для отслеживания сетевых подключений
SEC("tracepoint/syscalls/sys_enter_connect")
int trace_connect(struct trace_event_raw_sys_enter *ctx)
{
    struct event_t event = {};
    event.pid = bpf_get_current_pid_tgid() >> 32;
    event.timestamp = bpf_ktime_get_ns();
    // Извлечение информации о сокете и отправка в userspace
    bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU, &event, sizeof(event));
    return 0;
}

Инструменты для сбора и обработки

Инструмент Тип данных Производительность Особенности
tcpdump Raw pcap, фильтрация через командную строку. До ~1 Gbps с потерями на одноядерных системах. Универсальный, есть во всех дистрибутивах, легко автоматизируется.
Wireshark / tshark Raw pcap с глубоким анализом протоколов. До ~500 Mbps для live-захвата. Поддержка тысяч протоколов, мощный язык фильтров, GUI и CLI.
Zeek (ранее Bro) Логи сессий, извлечённые файлы, метаданные. До 10 Gbps в кластерной конфигурации. Ориентирован на безопасность, имеет свой скриптовый язык, детальный анализ протоколов.
Suricata Логи IDS/IPS, flow-данные, извлечённые файлы. До 20 Gbps с многопоточностью. Обнаружение по правилам (Snort-совместимый синтаксис), вывод в структурированном JSON.
Moloch / Arkime Полный захват пакетов с индексацией. До 40 Gbps capture в кластере. Веб-интерфейс для полнотекстового поиска по захваченному трафику, интеграция с Elasticsearch.
nProbe / nTopng Обработка NetFlow/IPFIX, анализ потоков. До 100 Gbps обработки flow. Коммерческий продукт с open-source версией, веб-интерфейс, алертинг.

Настройка Zeek для сбора структурированных логов

Zeek не просто сохраняет пакеты, а анализирует трафик на уровне прикладных протоколов и генерирует структурированные логи (например, отдельно для HTTP, DNS, SSL). Это сокращает объём хранимых данных и сразу предоставляет их в удобном для анализа виде.

Базовая конфигурация Zeek

# /opt/zeek/etc/node.cfg - конфигурация кластера
[manager]
type=manager
host=localhost

[worker-1]
type=worker
host=localhost
interface=eth0
lb_method=pf_ring
lb_procs=4

# /opt/zeek/etc/local.zeek - загружаемые скрипты и настройки
@load base/frameworks/logging
@load base/protocols/http
@load base/protocols/dns
@load base/protocols/ssl
@load policy/tuning/json-logs.zeek

# Включение вывода в JSON для упрощения интеграции
redef LogAscii::use_json = T;
redef LogAscii::json_timestamps = JSON::TS_ISO8601;

В результате Zeek будет создавать файлы вроде conn.log (сведения о соединениях), http.log, dns.log, ssl.log, каждый с набором специфичных полей.

Пример записи в conn.log

{
  "ts": "2026-02-27T14:23:01.234Z",
  "uid": "C8xKqp2Z3kqVpM1jS5",
  "id.orig_h": "192.168.1.100",
  "id.orig_p": 45678,
  "id.resp_h": "10.0.0.50",
  "id.resp_p": 443,
  "proto": "tcp",
  "service": "ssl",
  "duration": 12.456,
  "orig_bytes": 1024,
  "resp_bytes": 51200,
  "conn_state": "SF",
  "local_orig": true,
  "local_resp": true,
  "missed_bytes": 0,
  "history": "^ShadDfA",
  "orig_pkts": 15,
  "orig_ip_bytes": 2048,
  "resp_pkts": 35,
  "resp_ip_bytes": 52224
}

Поле conn_state — ключевое для анализа. Значение «SF» (SYN, FIN) указывает на нормально установленное и завершённое соединение. Такие состояния, как «RSTO» (RST от инициатора) или «REJ» (отказ), могут быть индикаторами сканирования или проблем с сетевыми службами.

Хранение и ротация сетевых логов

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

Уровень хранения Тип данных Срок хранения Технология
Горячее (Hot) Flow-данные и логи сессий за последние 1-7 дней. 1-7 дней Кластер Elasticsearch на SSD, репликация, индексация для мгновенного поиска.
Тёплое (Warm) Агрегированные flow-данные, метаданные за предыдущий период. 8-90 дней Elasticsearch на HDD, сжатие индексов, поиск с небольшой задержкой.
Холодное (Cold) Полные дампы трафика (pcap) по критичным инцидентам. 90-365 дней Объектное хранилище (S3-совместимое), архивное сжатие, извлечение по запросу за минуты.
Архивное Агрегированная статистика, требуемая для аудита и compliance. >1 года Ленточные библиотеки или сверхдешёвое облачное cold storage, извлечение занимает часы.

Ротацией управляют политики жизненного цикла индексов (ILM) в Elasticsearch или скрипты, которые перемещают и удаляют данные по расписанию. Для кольцевых буферов полного захвата (FPC) используется простое правило: при заполнении диска старейшие данные перезаписываются.

Нормализация и обогащение событий

Данные из разных источников (flow с коммутатора, логи от Zeek, алерты от Suricata) имеют различный формат. Нормализация преобразует их в единую схему, что необходимо для корреляции событий и работы SIEM-систем.

Структура нормализованного события

{
  "timestamp": "2026-02-27T14:23:01.234Z",
  "event_type": "network_flow",
  "source": {
    "ip": "192.168.1.100",
    "port": 45678,
    "mac": "00:1a:2b:3c:4d:5e",
    "hostname": "workstation-01",
    "user": "john.doe",
    "geo": {"country":"RU","city":"Moscow"},
    "asn": "AS12345"
  },
  "destination": {
    "ip": "10.0.0.50",
    "port": 443,
    "mac": "00:5e:4d:3c:2b:1a",
    "hostname": "server-db-01",
    "service": "https"
  },
  "network": {
    "protocol": "tcp",
    "bytes_sent": 1024,
    "bytes_received": 51200,
    "packets_sent": 15,
    "packets_received": 35,
    "duration_ms": 12456,
    "tcp_flags": "SYN,ACK,FIN"
  },
  "security": {
    "threat_score": 0.1,
    "categories": [],
    "rules_matched": []
  }
}

Обогащение контекстом

Сама по себе запись «IP 192.168.1.100 подключился к порту 443» малоинформативна. Обогащение добавляет критически важный контекст:

  • GeoIP: Определение страны и города по IP-адресу. Позволяет сразу увидеть подключения из неожиданных географических регионов.
  • ASN и провайдер: Указывает, к какой автономной системе принадлежит IP. Полезно для выявления трафика из сетей, известных как хостинг для ботнетов или сканеров.
  • Корреляция с IAM: Связывание IP-адреса или имени хоста с учётной записью пользователя в момент события. Это основа для анализа поведения пользователей и сущностей (UEBA).
  • Классификация приложений: Определение типа сервиса (например, «Веб-почта», «Облачное хранилище», «Корпоративный мессенджер») на основе анализа трафика, а не только порта.

Обогащение выполняется в конвейере обработки с использованием локальных баз данных (например, MaxMind для GeoIP) или запросов к внутренним API (CMDB, Active Directory) с обязательным кэшированием для снижения задержек.

Анализ для обнаружения угроз

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

Сценарий угрозы Индикаторы в сетевых логах Логика детектирования
Командно-аппаратная инфраструктура (C2) Периодические «маяковые» подключения с точным интервалом, использование DNS-туннелинга, шифрованный трафик на IP из списков угроз. Обнаружение соединений с одного внутреннего хоста на один внешний IP с интервалом 60±5 секунд в течение длительного периода.
Перемещение внутри сети (Lateral Movement) Множественные попытки подключения с одной взломанной машины на разные внутренние хосты, особенно по портам административных протоколов (SMB, RDP, SSH). Более 20 уникальных IP-адресов назначения за 10 минут с одного источника на порты 445, 3389, 22.
Утечка данных Аномально большой объём исходящего трафика с рабочей станции или сервера, особенно на внешние облачные хранилища или в нерабочее время. Исходящий трафик > 1 ГБ за час для хоста, не являющегося файловым сервером или бэкап-системой.
Сканирование сети Множество коротких неудачных соединений (RST, REJ) на разные порты и/или разные хосты с одного источника. Более 100 соединений со состоянием RSTO или REJ за 5 минут с одного IP-адреса источника.

Чтобы избежать лавины ложных срабатываний, правила необходимо настраивать с учётом контекста: исключать IP-адреса сканеров безопасности, учитывать график работы, создавать белые списки для легитимной активности. Новые правила сначала запускаются в режиме «тени», только логируя срабатывания без генерации алертов.

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

Загрузка…

Оставьте комментарий