СМАРТС-ТУЛС

Сервис приёма и анализа данных NetFlow

Сервис предназначен для приема потока данных от маршрутизаторов Cisco ASR, выполняющих функции BRAS и NAT. От маршрутизатора идут два потока:

Поток 1. NetFlow в формате IPFIX

Порт UDP 2055. Это статистика (кто, куда, сколько байт передал). Формат полей данных следующий:

{
  "ip_src": "10.10.145.224",
  "ip_dst": "54.191.232.8",
  "port_src": 44354,
  "port_dst": 443,
  "bytes": 4934,
  "packets": 5,
  "ip_proto": 6,
  "timestamp_start": 1787910941512000000,
  "timestamp_end": 1787910941737000000,
  "peer_ip_src": "172.19.0.2"
}

Поток 2. NEL в формате NetFlow v9

Порт UDP 2056. Это события состояния сессии NAT (создалась сессия NAT, удалилась сессия NAT). NEL может передаваться разными шаблонами. В системе используется самый простой шаблон, который маршрутизатор отдаёт постоянно. Формат данных следующий:

{
  "peer_ip_src": "172.19.0.2",
  "ip_src": "10.10.148.170",
  "port_src": 49534,
  "post_nat_ip_src": "91.220.112.206",
  "post_nat_port_src": 58001,
  "nat_event": 1,
  "ip_proto": "udp",
  "timestamp_start": "2026-09-07 16:36:10.415000"
}

nat_event: 1 = CREATE, 2 = DELETE

Архитектура обработки данных

Данные принимаются и разбираются на лету сервисом pmacct. Каждое сообщение преобразуется в JSON-формат и передаётся в агрегатор Kafka, который выступает буфером, сглаживающим пики и объединяющим порции данных перед вставкой в ClickHouse. ClickHouse постоянно читает топики Kafka и забирает новые данные в базу. Поток flow и поток nel хранятся в разных таблицах базы. В Kafka данные хранятся до 24 часов. В ClickHouse глубина хранения данных — 6 месяцев. Архитектура сервиса NetFlow

Просмотр данных

Просмотр данных базы ClickHouse доступен через WEB-интерфейс в СМАРТС-ТУЛС в разделе «Сервис» → «NetFlow». При открытии страницы отображается статистика трафика NetFlow за последний час.

Главный экран раздела NetFlow

Возможные поля поиска — справа. Результаты поиска — слева. Искать можно по основной таблице (flow), по таблице NAT-трансляций (NEL) и в смешанном режиме (flow+NEL). Чем меньше интервал времени — тем быстрее выполняется запрос в базе. При поиске среди большого временного интервала (более 72 часов) рекомендуется отключать отображение графика трафика за этот период галочкой «График». Для построения графика используется отдельный запрос, собирающий объём трафика за весь период, который может выполняться неприлично долго. При использовании в поиске фильтра по порту получателя порты можно перечислять через запятую.

Кнопки быстрого поиска ТОП

Внизу слева располагается ряд кнопок, обеспечивающих быстрый поиск по таблице flow IP-адресов, которые превосходят другие IP по объёму трафика. При использовании этих кнопок задействуются только поля фильтра «Дата от / до». Остальные поля фильтра игнорируются. График данных при отображении статистики ТОПов не отображается.

  • «ТОП-100 SRC» показывает 100 IP-адресов-источников, имеющих наибольший суммарный трафик за период.
  • «ТОП-100 DST» показывает 100 IP-адресов-получателей, имеющих наибольший суммарный трафик за период.
  • «ТОП-100 SPAM» показывает 100 IP-адресов-отправителей, которые за заданный период времени устанавливали максимальное количество TCP-соединений с наибольшим числом получателей по типовым портам отправки почты: 25, 587, 465, 2525.
  • «ТОП-100 DDOS» выявляет 100 IP-адресов-получателей внутри сети (10.0.0.0/8), которые имеют аномально интенсивный трафик. Алгоритм вычисляет медианные значения скорости обмена пакетов IP-адресами и обнаруживает резкие всплески (≥ 3 от медианы). Учитываются количество источников (≥ 50 уникальных внешних IP), высокий пиковый трафик, малый размер пакетов, преобладание UDP над TCP. Каждому инциденту присваивается оценка аномальности на основе комбинации факторов: интенсивность пика, коэффициент всплеска, размер пакетов, количество источников и доля коротких сессий. Если оценка превышает 80 — IP-адреса являются подозрительными. Пример результатов ТОП-поиска

Последние две колонки показывают время начала и окончания всплесков аномального трафика.

Пример поиска клиента, рассылающего СПАМ

Допустим, получили письмо с жалобой на IP-адрес, от которого зафиксирована рассылка СПАМа. В письме как правило есть информация о времени отправки письма и возможно даже об IP-адресе получателя. В моём случае отчёт о доставке СПАМа был расположен в базе netcraft.com:

Отчёт netcraft.com

Отчёт netcraft.com

В отчёте в полях Received перечислена цепочка получения. Первая строка в списке — это какой-то внутренний сервис системы с IP 172.18.48.34. По нему мы ничего не найдём. А вторая строчка уже содержит реальный домен получателя.

Итого извлекаем данные для поиска:

  1. Время получения письма — 02.10.2026 16:43:06 (1)
  2. IP-адрес после NAT — 91.220.112.201 (2)
  3. Домен получателя — park-mx.above.com (3)

Получаем IP, зная домен:

# dig park-mx.above.com +short
103.224.212.34

Забиваем данные в поиск (период времени берём на 10 минут раньше и 10 минут позже события) и получаем внутренний IP-адрес пользователя: 10.10.144.91. Результаты поиска внутреннего IP

IP-адрес в общем случае выдаётся пользователю динамически. При каждой сессии PPPoE IP-адрес может быть разным. Определить, кому принадлежал IP-адрес во время рассылки СПАМа, можно по базе сессий абонента «Сервис» → «Сессии». Период времени тут нужно задать побольше, чтобы захватить момент начала или окончания сессии. Карточка абонента

Теперь, зная логин, можно перейти на карточку абонента.

Если в биллинге к каждой учётной записи PPPoE жёстко привязан IP-адрес, абонента можно найти на странице IP-адресов: Страница IP-адресов