Netflow коллектор и анализатор под windows

Linuxoid

OpenSource forever

Собираем статистику при помощи NetFlow

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

Несколько слов о NetFlow

Сетевой протокол NetFlow изначально разрабатывался Cisco (goo.gl/vM2l7) для технологии коммутации пакетов в устройствах этой корпорации, но сегодня используется, в основном, для учета трафика. Его спецификации открыты, поэтому со временем NetFlow стал стандартом и применяется не только в Cisco, но и решениях других фирм (вроде Juniper и Enterasys) и ОС.
На сегодня известно несколько версий. Протокол NetFlow v1, созданный в 1990 году, использовался в маршрутизаторах для коммутации пакетов, когда первый пакет потока создавал запись в таблице маршрутизации (по сути кэш), которая затем применялась ко всему потоку. Примерно такая же технология сегодня задействуется и в Netfilter. Последней на сегодня является девятая версия протокола, вышедшая в октябре 2004 года и описанная в RFC 3954. На основе v9 с несколькими расширениями был создан протокол IPFIX (IP Flow Information Export, RFC 3917), который в кулуарах называют NetFlow v10. При этом v2-4 являются внутренней реализацией Cisco, не получившей большого распространения. Поэтому после первой версии сразу появилась наиболее популярная v5, возможностей которой достаточно для большинства задач в IPv4 сетях. Сетевой трафик анализируется на уровне сеансов, запись (flow record) создается для каждой транзакции TCP/IP. В v5 сохраняются данные о версии протокола, интерфейсах, времени начала и окончания соединения, IP и портах источника и назначения, количестве байт и пакетов, TOS и TCP флаги. Девятая версия понимает заголовки IPv6, метки потоков MPLS, адрес шлюза BGP и дополнительные поля. Например, в Cisco ASA NetFlow используется для динамического отслеживания потоков. Чтобы выявить различные события, как раз и задействуются специальные поля v9 (Netflow Security Event Loging, NSEL), которые затем сопоставляются с шаблонами.
Для сбора и последующего анализа информации о трафике по протоколу NetFlow требуется наличие следующих компонентов:

Сенсор — собирает статистику по всем сеансам (потокам трафика, flows) и отправляет коллектору. Сенсоры устанавливаются на всех маршрутизаторах или других устройствах, статистику с которых необходимо собрать. В зависимости от настроек, информация сбрасывается после того, как сенсор определил, что поток закончился, или периодически по мере накопления данных.
Коллектор — собирает данные, получаемые от сенсоров по UDP или SCTP (Stream Control Transmission Protocol), и обеспечивает их хранение, формат хранения зависит от реализации. Коллектор обычно принимает данные о трафике на 2055 порту, но в некоторых реализациях это может быть 9555, 9995 или любой другой определенный админом;
Анализатор — анализирует собранные коллектором данные и выводит их ввиде отчетов (таблицы и графики).

Можно установить комплексное решение, когда разработчик предлагает все три компоненты, или собрать свой вариант — сенсор + коллектор + анализатор. В последнем случае следует учитывать совместимость форматов коллектор – анализатор, хотя некоторые проекты предлагают свои конвертеры из одного формата в другой.
В перегруженных сетях возможна потеря UDP пакетов, а UDP не информирует о необходимости повтора, это может исказить статистику, особенно учитывая, что сенсор не хранит сброшенные данные. Эта проблема особенно актуальна для v8 и v9, где в один пакет может быть объединена информация о нескольких потоках. В этом случае некоторые реализации позволяют использовать SCTP. Хотя этот протокол тоже неидеален, так как требует взаимодействия между коллектором NetFlow и каждым сенсором NetFlow. В случае если коллектор обслуживает большое количество сенсоров, могут быть задержки и, опять же, потери. Также использование UDP предпочтительнее, когда сенсор завязан на несколько коллекторов, ведь UDP очень просто реплицировать. Для этих целей можно использовать программу вроде samplicator (code.google.com/p/samplicator), отправляющую копии UDP на несколько адресов. Кроме этого, ретранслировать полученные данные могут и некоторые коллекторы. Кстати, по номерам пакетов коллектор может определить, что информация пропущена, и учитывать это в своих расчетах.
Протокол TCP, в силу своей специфики, не подходит для передачи такого объема данных, так как будут возникать задержки из-за установления связи и сбора всех пакетов (потребуется также выделить некоторый буфер, что также повлечет затраты).
В некоторых маршрутизаторах, работающих на высоконагруженных магистралях, используется упрощенная реализация Sampled NetFlow, когда считаются не все пакеты, а некоторые, через определенный промежуток (в разных реализациях свой алгоритм). Нетрудно догадаться, что Sampled NetFlow показывает не точную, а приблизительную статистику, хотя для некоторых задач этого вполне достаточно.

Устанавливаем сенсор на Linux

Поддержка сенсоров NetFlow сегодня реализована во многих аппаратных маршрутизаторах, прошивках DD-WRT и ОС. Например, в анонсированном недавно VMware vSphere 5 появилась поддержка Netflow v5, предоставляющая возможность просматривать трафик между виртуальными машинами на одном или разных хостах. Отслеживая поток трафика приложений внутри виртуальной машины, админ может контролировать производительность сети и целевое использование трафика. Для Cisco активация NetFlow для передачи на коллектор 192.10.0.2:9001 очень проста:

Вот далеко не все варианты NetFlow-сенсоров, при помощи которых можно собирать статистику в разных ОС:

fprobe (fprobe.sourceforge.net) — работает в Linux, базируется на libpcap, есть форк fprobe-ulog, использующий libipulog;
ipt-netflow — работает в Linuх и состоит из двух модулей: ядра и iptables;
Softflowd (code.google.com/p/softflowd) — работает в Linux/FreeBSD, поддерживает NetFlow v1/v5/v9/;
Pfflowd (mindrot.org/projects/pfflowd) — работает в OpenBSD;
nProbe (ntop.org/products/nprobe) — расширяемый сенсор/коллектор под Linux, FreeBSD и Windows, поддерживающий NetFlow v5/v9/IPFIX;
ipcad (lionet.info/ipcad) — сенсор для Linux, FreeBSD, OpenBSD, Mac OS X/Darwin и Solaris, поддерживающий raw BPF-устройства, PCAP, iptables ULOG & IPQ;
fSonar (softpiua.com/ru/products/softpi/fsonar.html) — сенсор для Windows, поддерживающий NetFlow v5/v9;
ndsad (ndsad.sf.net) — сенсор, поддерживающий NetFlow v5 для Windows (winpcap), Linux (libpcap), Mac OS X и FreeBSD;
PRTG Network Monitor (paessler.com/netflow_monitoring) – проприетарное «все в одном» решение для мониторинга Windows от XP и выше (10 сенсоров бесплатно).

Если в сети уже есть работающий маршрутизатор, выдающий NetFlow, эту часть статьи можно пропустить. Мы же предположим, что у нас настроен роутер на Ubuntu/Debian, и мы хотим собирать статистику.

В процессе установки пакета будут заданы вопросы относительно интерфейса для сбора статистики и хоста коллектора (нужно указать IP-адрес и номер порта). После чего стартует демон с указанными настройками. В последующем все параметры можно изменить в файле /etc/default/fprobe:

Аргументов у fprobe очень много, в высоконагруженных сетях возможно потребуется корректировка приоритета (установкой r больше 0), буфера ядра для захвата пакетов (B и q), задержки между отправками (t). Теперь при помощи tcpdump можно просмотреть отправляемые на удаленную систему пакеты.

Для удобства можно использовать фильтр для отлова только NetFlow «-T cnfp«. Также просто настраивается и Softflowd. Все, информация пошла, но пока «в никуда», самое время начать ее собирать.

Коллектор

Выбор связки коллектор + анализатор дело ответственное и зависит от необходимости в дальнейшей обработке данных и их визуализации. Самым известным коллектором является пакет flow-tools, разрабатываемый Марком Фуллмером и содержащий массу полезных инструментов, с помощью которых можно обрабатывать собранную информацию. Вместе с flow-tools можно использовать несколько анализаторов — Perl-скрипт flowscan (caida.org/tools/utilities/flowscan), обрабатывающий полученные flow-capture (коллектор NetFlow из пакета flow-tools) данные и сохраняющий итог в базе данных RRD. Для визуализации flowscan может использовать дополнительные модули отчетов: CUFlow, CampusIP, SubNetIO. Это очень интересный вариант, но мне больше нравится nfdump (nfdump.sf.net), поддерживающий NetFlow v1/v5/v7/v9 и IPFIX (пока бета), для просмотра собранной информации которого используют фронтэнд NfSen (Netflow Sensor, nfsen.sf.net). Причем доступна и NSEL версия nfdump, поддерживающая дополнительные записи Cisco ASA.
Сам nfdump представляет собой пакет из нескольких утилит: nfcapd (демон, читающий поток и сохраняющий информацию в файл), nfdump (считывает данные из файла и выводит статистику), nfprofile (считывает данные из файла и применяет к ним фильтры, информацию сохраняет в другой файл для дальнейшего использования), nfreplay (считывает данные из файла и отправляет по сети на удаленную систему/коллектор), nfclean.pl (удаление старых данных), ft2nfdump (конвертер данных flow-tools в формат nfdump).
По умолчанию демон nfcapd каждые 5 минут создает файл с новым именем (включает метку времени, чтобы не повторяться), который затем анализируется nfdump. Нужный пакет есть в репозитарии, поэтому установка nfdump в Ubuntu/Debian очень проста.

Работу nfcapd и nfdump в большинстве случаев настраивают через NfSen. Именно поэтому все демоны пакета nfdump по умолчанию не стартуют, в чем легко убедиться, заглянув в /etc/default/nfdump:

Но для начала удостоверимся, что все работает. Запускаем демон для сбора nfcapd статистики, в качестве параметра указываем каталог для хранения файлов и UDP порт:

Если адресов несколько, а нужно выбрать один, указываем нужный при помощи ‘-b‘. Параметр «-R host/port» позволяет сразу переправить NetFlow пакеты на другой узел. При помощи параметра ‘-p’ можно считывать данные не из сети, а из pcap файла.
Чтобы прочитать и вывести таблицу со всеми собранными данными при помощи nfdump, достаточно указать каталог:

На первый взгляд, информации немного, но это если не знать, что nfdump умеет выводить информацию в четырех разных форматах (line, long, extended и custom), а по умолчанию используется самый «молчаливый» line. Чтобы изменить формат, следует использовать параметр ‘–o’. Утилита nfdump имеет большое количество параметров и фильтров, позволяющих отобрать нужную информацию, все это описано в «man nfdump», поэтому подробно останавливаться здесь не будем.

Настраиваем NFSen

Переходим к настройке NFSen. В репозитариях нужного пакета нет, поэтому установку нужно производить вручную. Само приложение написано на PHP и Perl, для построения графиков используется RRDtool. Для его работы потребуется стандартный LAMP сервер и Perl модули Mail::Header и Mail::Internet. Устанавливаем приложения для удовлетворения зависимостей:

Скачиваем и распаковываем последнюю версию.

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

Кроме этого, в файле можно установить буфер для nfcapd, расширения для каждого коллектора, настроить каталоги для сбора данных и многое другое. Ставим.

Скрипт проверит наличие необходимых Perl-модулей, после чего скопирует компоненты по указанным в nfsen.conf каталогам. Запускаем nfsen, он активирует процессы nfcapd:

Создаем настройки для Apache:

Теперь набираем в браузере адрес http://имя_сервера/nfsen/nfsen.php и наслаждаемся генерируемыми графиками и собранной статистикой. Интерфейс позволяет при помощи фильтров и запросов отобрать информацию только по определенным протоколам, IP-адресам, портам и т.д. По умолчанию используется для всего профиля «any», для вывода графиков «proto TCP».

Возможности NFsen расширяются при помощи плагинов (sf.net/apps/trac/nfsen-plugins). Для установки плагина его нужно распаковать в подкаталог plugins, а затем подключить в nfsen.conf, взяв за пример имеющиеся там шаблоны.

Например, чтобы отследить только SSH трафик, пишем «src or dst port 22«, при необходимости можно указать IP и прочие параметры. Изначально используется только один профиль — Live, в который записываются данные со всех источников, указанных в nfsen.conf. Чтобы построить графики для различных источников или критериев, следует создать соответствующие профили (Live -> New Profile).

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

5 комментариев

Если попробовать сделать такое в новых дистрибутивах, то ничего не получится, начиная от того, что коллектор не будет работать, заканчивая тем, что это будет отваливаться…

Тогда какой способ вы бы посоветовали?

статья хорошая, но устаревшая, начиная с php, и заканчивая допиливанием вручную некоторых моментов, таких как Socket6, ошибок с RRD и т.д.
Вот обновили бы статейку — вообще цены бы не было.

Народ, подскажите. Как с одного сервера перенести данные на другой ?

был сервер без nfsen собирал статистику через nfdump. На другом сервере поднял nfsen (по этой статье) данные закинул в папку с пользователем live. Графики пустые. Создал нового пользователя через веб, автоматически создались нужные каталоги. Согласно их структуре скинул в него данные (nfcapd.20171111 и тд). Перезапустил службы. Графики всё равно пустые.

Собственно есть данные nfcapd. от старого сервака. Нужно добавить их к новому. Просто скопировать не помогло. Может есть ньюансы ? подскажите пожалуйста.

Источник