net flows что это
NetFlow
Данная статья рассказывает о том, как организовать сбор, обработку и визуализацию информации о сетевом трафике. Она составлена на основе статей [1] и [2], и их переводов на русский язык [3] и [4] соответственно.
Кроме того, добавлены:
Рассматривается случай, когда в качестве основной операционной системы используется FreeBSD. При использовании Linux необходимы небольшие изменения в скриптах и именах конфигурационных файлов.
Содержание
Архитектура NetFlow
Netflow предоставляет возможность анализа сетевого трафика на уровне сеансов, делая запись о каждой транзакции TCP/IP. Информация не столь подробна, как предоставляемая tcpdump’ом, но представляет довольно подробную статистику.
Netflow имеет три основых компонента:
Наконец, система обработки читает эти файлы и генерирует отчеты в форме, более удобной для человека. Эта система должна быть совместима с форматом данных, предоставляемых коллектором.
В качестве каждого из элементов системы может использоваться несколько разных вариантов программ. Список доступного программного обеспечения, предназначенного для работы с NetFlow приведен ниже.
Мы рассмотрим свзяку:
Инсталляция и настройка сенсора
Инсталляция сенсора
В качестве программного обеспечения сенсора будем использовать softflowd [5]. Другое программное обеспечение, которое может использоваться как сенсор, перечислено ниже.
Для работы softlflowd требуется наличие libpcap. В FreeBSD может использоваться ng_netflow, в этом случае libpcap не обязателен.
Запуск сенсора
После того, как softflowd был установлен, необходимо выбрать интерфейс, мониторинг которого будет производиться, указать IP адрес и UDP порт коллектора. Например, для интерфейса em0 и коллектора 172.16.13.5:8818 запуск softflowd будет выглядеть следующим образом:
Сенсор немедленно начнет слушать сеть и посылать информацию на коллектор.
Для того чтобы программа работала после перезагрузки, необходимо убедиться, что она стартует на этапе начальной загрузки!
Проверка
Softflowd включает в себя программу контроля softflowctl, с помощью которой можно проверить работоспособность softflow:
Для того чтобы посмотреть информацию о самих потоках, дайте команду:
В этом выводе нас будет интересовать число активных потоков (2298) и строка «exported», сообщающая о количестве экспортированных потоков в коллектор.
Проверить, действительно ли данные отправляются и достигают коллектора можно с помощью ethereal, tcpdump или другого анализатора трафика. В случае каких-либо проблем можно использовать флаг -D демона softflowd. Softflowd посылает информацию о потоке после того, как тот будет завершен, например, прекратится FTP-сессия или загрузится web-страница. Это означает, что в любой момент времени у softflowd имеется некий кэш открытых потоков, в связи с чем остановку демона необходимо выполнять командой softflowctl shutdown. В противном случае вы потеряете данные активных потоков, которые еще не были завершены и отправлены на коллектор.
Стартовый скрипт
Для того чтобы softflowd стартовал при загрузке автоматически, необходимо создать скрипт запуска и добавить его в загрузку системы. К сожалению, пока что в порт softflowd такой скрипт не входит, поэтому его прийдётся создать самостоятельно:
После того как скрипт создан, необходимо:
Для запуска скрипта в файле /etc/rc.conf следует установить переменные:
Запуск и останов скрипта выполняются командами:
Инсталляция и настройка коллектора
Коллектор NetFlow предназначен для сбора данных, предоставляемых сенсором и сохранения их на диск для дальнейшего хранения и обработки.
Инсталляция коллектора
В качестве Netflow-коллектора будем использовать flow-capture, очень популярный коллектор Netflow, входящий в состав пакета flow-tools.
В FreeBSD порт flow-tools располагается в каталоге /usr/ports/net-mgmt/flow-tools. Установите его обычным «make all install.» Не делайте «make clean», так как, возможно, вам придется устанавливать некоторые компоненты вручную. По этой самой причине не рекомендуется использовать прекомпилированный пакет.
Создайте каталог в котором flow-capture будет хранить свои данные. Пусть это будет /var/netflow. Убедитесь, что на дисковом разделе, в котором создается каталог, достаточно свободного места: на скоростной сети данные Netflow могут составить несколько гигабайт в неделю.
Для работы системы отображения, необходимо создать каталог saved.
Запуск коллектора
Теперь нам необходимо выполнить стартовый скрипт flow-capture. Выглядит он следующим образом:
Большинство параметров можно оставить без изменеия. Флаг -w указывает каталог данных, заключительный аргумент обозначает локальный IP, удаленый IP и прослушиваемый UDP порт. В этом случае, значение 0/0/8818 указывает коллектору слушать на всех локальных IP адресах, принимать данные с любых удаленных хостов, порт 8818. В случае, если вы опасаетесь принимать чужие данне, то жестко задайте адрес сенсора.
Параметр -n указывает, сколько раз flow-capture должен создавать новый файл. Параметр -N задает глубину иерархии каталогов, в которых будут храниться файлы с данными NetFlow. Параметр -S указывает размер интервала в минутах, в течение которого flow-capture будет записывать информацию о счетчиках пакетов в файл.
Проверка
Для того, чтобы убедиться, что данные собираются, посмотрите, во-первых, появились ли файлы в каталоге netflow, а во-вторых, увеличивается ли размер временного файла.
Стартовый скрипт
Точно также как и для softflowd, для того чтобы коллектор стартовал автоматически, необходимо создать скрипт запуска и добавить его в загрузку системы. В порт flow-tools такой скрипт не входит, поэтому его прийдётся создать самостоятельно:
После того как скрипт создан, необходимо:
Для запуска скрипта в файле /etc/rc.conf следует установить переменные:
Если нужно запустить несколько копий flow-capture, необходимо задать несколько каталогов для записи данных в переменной flowcapture_dir. Прослушиваемый порт, в этом случае, будет автоматически увеличиваться на 1 для каждой копии flow-capture. Например, пусть:
Запуск и останов скрипта выполняются командами:
Инсталляция модуля Cflow.pm
Информация в этих файлах находится в бинарном формате, требующем для просмотра специальных инструментальных средств. Многие из тех инструментальных средств используют модуль Cflow.pm.
Cflow это perl-модуль, предоставляющий API для чтения двоичнх файлов данных NetFlow-коллекторов, таких как argus, cflowd, flow-tools и lfapd.
Большое количество программ составления отчетов Netflow используют perl модуль Cflow.pm для чтения файлов Netflow. Этот модуль включает в себя библиотеки и утилиты командной строки, необходимые для просмотра и редактирования файлов данных. Каждый коллектор имеет собственный формат хранения файлов и хотя Cflow.pm изначально создавался для чтения файлов cflowd(8), сейчас он способен обрабатывать и другие форматы.
В последних версиях FreeBSD /usr/ports/net-mgmt/p5-Cflow автоматически обнаруживает библиотеки flow-tools. Cflow вызывает их как -lnsl и в случае ошибки выдается предупреждение.
Если предупреждения не появилось, необходимо выполнить проверку работоспособности. Cflow включает в себя утилиту flowdumper(1), которая читает файлы данных из командной строки. Воспользуемся ей.
Если инсталляция прошла успешно, можно перейти к следующему разделу. В противном случае необходимо выполнить действия, описанные ниже.
Установка Cflow из flow-tools/contribs
В случае некорректной установки, flowdumper выведет ошибку или ничего не выведет.
Если такая ситуация произошла, продолжать работу не получится. Необходимо деинсталлировать p5-Cflow и попытаться установить его другим способом.
В каталоге исходных текстов flow-tools должен находиться каталог contrib. В подкаталоге contrib у нас усть другой архив Cflow. Распакуем его:
Cflow часто собирает правильную библиотеку, когда устанавливается flow-tools. Выполним сборку модуля:
Пробуйте flowdumper снова, все должно работать.
В противном случае, применим решение «в лоб». Flow-tools устанавливает libft.a в каталог /usr/local/lib. Отредактируем Makefile.PL модуля Cflow.pm в части, касающейся библиотек flow-tools:
После выполнения make и make install чего мы работоспособный flow-tools должен быть установлен.
С помощью CFlow можно написать множество разнообразных скриптов, решающих самые разные задачи обработки и визуализации.
Обработка и визуализация данных NetFlow
FlowScan является скриптом, написанным на Perl и, анализируя записи NetFlow, сохраняет их в базе данных RRD, Round Robin Database. RRD предназначен для хранения постоянно изменяющихся данных, наиболее важными из которых являются последние данные, а более старые имеют не такое важное значение, и поэтому могут храниться не целиком, а в усреднённом виде. За счёт этого RRD не требует много дискового пространства даже для хранения информации о больших промежутках времени.
Установка FlowScan
Установку flowscan мы будем делать из системы портов, каталог программы находится в /usr/ports/net-mgmt/flowscan. Таже будут установлениы несколько модулей Perl в качестве зависимостей. Весь инструментарий FlowScan будет по умолчанию установлен в /usr/local/var/db/flows/bin. Учтите, что сразу после установки FlowScan не работоспособен!
Сначала, нам необходимо обновить модуль FlowScan, так как официальный дистрибутив долгое время не обновлялся и не способен обрабатывать записи потока. Автор написал обновленный модуль flowscan.pm, но не включил его в состав дистрибутива. Получите FlowScan.pm версии [6] и скопируйте ее в каталог /usr/local/var/db/flows/bin, перезаписав модуль версии 1.5.
В Этом же самом каталоге находится образцовый файл конфигурации FlowScan flowscan.cf.sample. В первую очередь необходимо указать FlowScan, где искать файлы потока. FlowScan будет пытаться обработать каждый файл в каталоге, если вы не укажите регулярное выражение, описывающее необходимые файлы, включая временные файли и вложенные каталоги. В следующем примере мы обрабатываем только завершенные файлы потока, хранящиеся в каталоге /var/netflows:
В ReportClasses перечисляются все используемые для вывода отчетов модули. FlowScan поставляется с двумя модулями: CampusIO и SubNetIO. Возможно, они впоследтсвии окажутся кому-то полезными, но сейчас будет использоваться CUFlow.
Параметр WaitSeconds задает интервал ожидания между попытками FlowScan проверить каталог. Довольно много инструментальных средств используют пятиминутный интервал и могут некорректно работать с меньшим значением.
В заключение, включим отладку для проверки правильности установки:
Конфигурирование FlowScan закончено, но нам все еще необходимо настроить модуль отчетов для правильного отображения информации.
Конфигурирование CUFlow
Скачайте [7], распакуйте и скопируйте CUFlow.pm и CUFlow.cf в /usr/local/var/db/flows/bin. Сам модуль можно оставить без изменений, но необходимо отредактировать cuflow.cf, чтобы он соответствовал вашим настройкам Perl.
Инструкция Subnet указывает принадлежащие вам сети. На основании этих данных CUFlow будет различать входящий и исходящий трафик.
Инструкция Network описывает сети, которые вы хотите обрабатывать отдельно друг от друга. Каждая инструкция будет отображаться как вариант в CGI скрипте. Как вы видите в этом примере, диапазоны могут перекрываться:
Директивой OutputDir указывается, где сохранять отчеты. Не храните их в доступном по сети месте или в каталоге flow-capture.
CUFlow также вычисляет самые активные сайты и строит «хит-парад» IP адресов, передавших большее количество трафика в течении 5 минут. За этот параметр отвечает опция Scoreboard. Эта опция использует три аргумента: число IP в «хит-параде», имя каталога для хранения старых списков и имя файла текущего списка. В следующем примере указывается вести «Top 10» IP адресов, сохранять отчеты в /usr/local/www/data/scoreboard и текущим считать файл /usr/local/www/data/scoreboard/topten.html:
В то время как список самых больших потребителей/генераторов трафика в данный пятиминутный период полезен для предотвращения проблем, так же был бы полезен список самых активных хостов. Опция AggregateScore позволяет вам сделать это:
Если у вас довольно сложная сеть, то может возникнуть необходимость в нескольких сенсорах Netflow. CUFlow может отделять данные от разных сенсоров, при этом различные маршрутизаторы буду доступны в CUFlow CGI.
Директива Services предназначена для указания TCP/IP портов, которые вы хотите отслеживать отдельно. Эта директива позволяет вам делать такие выводы как «80% нашего трафика приходится на HTTP» и тому подобное. Учтите, что это повышает нагрузку на сервер, поэтому не стоит здесь указывать весь /etc/services. Не стоит указывать сервисы, которые заблокированы, например Gnutella, Edonkey и т.д:
Директива Protocol очень похожа на Services, только вместо Layer 4 используется Layer 4 модели OSI. Я рекомендую указывать Protocol 1 (ICMP), Protocol 6 (UDP) и Protocol 17 (TCP) в качестве базового минимума. Если есть много пользователей VPN то стоит отслеживать IPSec и GRE.
Так как Netflow был разработан в Cisco, то неудивительно, что много Netflow датчиков включают информацию BGP. CUFlow может отображать информацию о трафике к/от различных AS, используя для этого номер AS (опция ASNumber), softflowd не предосталяет информацию о номере автономной системы. В случае использования softflowd закомментируйте опцию ASNumber.
Сохранение записей Netflow из FlowScan
По умолчанию, FlowScan удаляет записи после обработки. Можно сохранять эти записи в течении нескольких месяцев или пока позволяет дисковое пространство. Создайте подкаталог saved в директории Netflow и тогда FlowScan автоматически будет сохранять там обработанные файлы. Даже если вы не планируете хранение старых файлов потока, я рекомендую делать это хотябы первое время, пока вы не убедитесь, что FlowScan работает правильно. В случае, если что-то пойдет не так, наличие этих данны облегчит поиск и устранение неисправности.
Запуск FlowScan
Теоретически у нас все готово к запуску:
FlowScan должен запуститься, выводя подобные сообщения:
FlowScan анализирует все старые файлы потока, при этом процесс можеть занять довольно продолжительное время, все зависит от того, сколько файлов накопилось в системе. Достойной упоминания вещью здесь является «flow hit ratio», котороя указывает на количество файлов, не соответствующих формату FlowScan и это очень хороший показатель. Если этот параметр равен 0, то скорее всего вы неправильно указали параметр Subnet.
Если FlowScan выдает ошибку «ERROR updating /var/netflow/. unknown option», необходимо внести исправления в файл FlowScan.pm, описанные в [8].
Стартовый скрипт flowscan.sh:
Построение графиков
Теперь перейдем на URL и выберем, для примера, сеть. Вы должны будете увидеть массив раскрывающихся меню. Выберете любой и нажмите «Generate graph».
Разбор пакетов NetFlow v.9 на C#
NetFlow это сетевой протокол, созданный компанией Cisco Systems для учёта сетевого трафика. Наиболее распространёнными версиями данного протокола являются 5 и 9. Девятая версия более гибкая так как используются шаблоны, согласно которым присылаются данные. В пятой версии данные присылаются согласно спецификации. 
О разработки части функций анализатора на C#, а точнее разбор пакетов NetFlow я и расскажу
В качестве сенсора был использован MikroTik маршрутизатор.
Включаем на нем NetFlow для ether1 интерфейса:
/ip traffic-flow set enabled=yes interfaces=ether1
И добавляем коллектор (как правило, коллектор слушает порт 2055, 9555 или 9995):
/ip traffic-flow target add disabled=no version=9 address=192.168.0.100:9995
Или тоже самое но через WinBox:
Теперь на компьютер с IP адресом 192.168.0.100 на 9995 порт по UDP (или SCTP) будут приходить пакеты NetFlow 9 версии. Пакеты приходят и есть с чем работать.
Разбор приходящих пакетов
Есть еще так называемый опциональный шаблон и данные по нему. Я их рассматривать не буду, они мне не встречались, по этой причине в реализации библиотеки отсутствуют, но все можно дописать.
Составил UML диаграмму классов (с помощью NClass):
или в pdf
И написал библиотеку для разбора приходящих пакетов.
Основной класс с которого все начинается, это Packet. Его единственный конструктор принимает входящий пакет NetFlow в байтах и объект класса Templates, представляющий из себя список текущих Template (шаблонов).
Далее в конструкторе класса Packet вызывается функция Parse, которая принимает объект класса Templates.
В этой функции идет разбивка пакета на заголовок — 20 байт и дальнейшая работа с ним через класс Header; на FlowSet`ы и передача каждого FlowSet`а на обработка соответствующему классу FlowSet.
Ввиду того, что FlowSet`ов может быть несколько, приходится вторую часть пакета (без 20 байт заголовка), анализировать и разбивать на разные FlowSet`ы. Примечательно что в MikroTik`е FlowSet`ы в единственном экземпляре в пакете, а вот пользуясь Netflow Simulator in C# удалось поработать с пакетами с несколькими FlowSet`ами в пакете. Кроме того благодаря ему был найден забавный баг в реализации NetFlow v9 на MikroTik`е, о чем подробнее тут.
Netflow Simulator in C#:
Вот участок кода разбивающий часть пакета на FlowSet`ы:
В классе Header идет разбор заголовка пакета на его поля. Прежде чем это сделать, выполняется реверсия заголовка:
Далее конвертируем биты в тот тип поля, которым он является, например поле version:
Да в Header поля sysUpTime имеет тип TimeSpan, приводим к этому типу:
и поле UNIX Secs имеет тип DateTime:
Перейдем к обработке FlowSet`ов. После получения полей FlowSet ID и Length идет разбор остальных полей в зависимости от FlowSet ID. Если он равен 0 или 1 то это шаблон, а если это число от 256 до 65535 то это данные.
Если это шаблон то передаем его обработку классу Template после чего проверяем наше хранилище шаблонов (объект класса Templates) на наличие шаблона с таким же ID и заменяем его, иначе просто добавляем шаблон.
Если это данные то проверяем есть ли в хранилище (объект класса Templates) такой шаблон (FlowSet ID == Template ID) и если есть то копируем этот шаблон функцией DeepClone и заполняем его поля — Field, иначе ничего не делаем, ведь без шаблона это просто набор байтов.
Причем Field в Template в хранилище находятся без параметров Value т.е. Value пусты, а вот при обработке пакетов Template в FlowSet в объекте Packet уже содержит поля Value.
Кроме всего этого есть еще перечисление FieldType — перечисление в котором имени типа соответствует номер данного типа. (параметр Type в Field)
Для работы данной библиотеки был написан пример:
Создаем сокет и слушаем по UDP 9995 порт на нашем ПК. _templates — это наше хранилище шаблонов. Каждый приходящий пакет мы скармливаем объекту packet класса Packet передавая еще и наше хранилище шаблонов. А далее выполняем packet.ToString() Это перегруженная функция выводит нам содержание пакета и нужна только для проверки, что у нас все получается.
На этом с библиотекой все, теперь ее можно использовать для дальнейшего написания Анализатора трафика по NetFlow протоколу.
Получили пакет без наличия шаблона в хранилище:
Получили шаблон от сенсора:
Получили данные, для которых есть шаблон в хранилище:
Ошибка реализации NetFlow v9 в MikroTik`е
Count
The total number of records in the Export Packet, which is the
sum of Options FlowSet records, Template FlowSet records, and
Data FlowSet records.
т.е. содержит все записи, во всех FlowSet`ах, а в MikroTik`е данное поле всегда равно 1 (см. скрины выше), даже если передается несколько шаблонов или данных. т.е. по логике MikroTik`а поле Count = количеству FlowSet`ов (о чем они мне и написали в письме и видно по скринам), а должно быть равно общему количеству всех шаблонов и данных, как звучит в спецификации. По этой причине использовать в разборе пакетов поле Count чревато.
Вот же пример от Netflow Simulator in C# (Хотелось бы получить данные и от Cisco, но у меня нет такой возможности, может кто из читателей проверит это):
Получили пакет без наличия шаблона в хранилище (обратите внимание на Count):
Получили шаблон от сенсора (тут одновременно два FlowSet`а пришло, что в MikroTik`е не бывает. Обратите внимание на Count он равен 7 = 1 шаблон и 6 записей с данными. По логике MikroTik`а Count должен был бы равен 2 = 2 FlowSet`а):
Получили данные, для которых есть шаблон в хранилище (обратите внимание на Count):
Ну и еще раз пакет в Wireshark Помечено поле Count:
Еще раз: буду очень благодарен всем кто пришлет скрин с Wireshark`ом от Cisco. Вставлю его сюда.
Исходный код доступен здесь.
Сегодня (19:05 30/07/2013)
MikroTik support [Dzintars] support@mikrotik.com
Thank you for reporting a problem (the author of the article correctly pointed out
that count value in netflow packet header not always is set correctly). The
problem will be fixed in the next version of RouterOS.
UPD: В версии RouterOS 6.2 данный баг исправлен.
Сегодня (13:22 13/09/2013)
MikroTik support [Dzintars] support@mikrotik.com
The NetFlow V9 count field problem was fixed in version 6.2
NetFlow
Материал из Xgu.ru
Данная статья рассказывает о том, как организовать сбор, обработку и визуализацию информации о сетевом трафике. Она составлена на основе статей [1] и [2], и их переводов на русский язык [3] и [4] соответственно.
Кроме того, добавлены:
Рассматривается случай, когда в качестве основной операционной системы используется FreeBSD. При использовании Linux необходимы небольшие изменения в скриптах и именах конфигурационных файлов.
Содержание
[править] Архитектура NetFlow
Netflow предоставляет возможность анализа сетевого трафика на уровне сеансов, делая запись о каждой транзакции TCP/IP. Информация не столь подробна, как предоставляемая tcpdump’ом, но представляет довольно подробную статистику.
Netflow имеет три основных компонента:
Сенсор — демон, который слушает сеть и фиксирует данные сеанса. Также как Snort или любая другая система обнаружения вторжений, сенсор должен иметь возможность подключиться к хабу, «зеркалированному» порту коммутатора или любому другому устройству, для просмотра сетевого трафика. Если вы используете систему пакетной фильтрации на базе BSD или Linux, то это превосходное место для сенсора Netflow, так как весь трафик будет проходить через эту точку. Сенсор будет собирать информацию о сеансах и сбрасывать ее в коллектор.
Коллектор — второй демон, который слушает на UDP порту, указанному вами и осуществляет сбор информации от сенсора. Полученные данные он сбрасывает в файл для дальнейшей обработки. Различные коллекторы сохраняют данные в различных форматах.
Наконец, система обработки читает эти файлы и генерирует отчеты в форме, более удобной для человека. Эта система должна быть совместима с форматом данных, предоставляемых коллектором.
В качестве каждого из элементов системы может использоваться несколько разных вариантов программ. Список доступного программного обеспечения, предназначенного для работы с NetFlow приведен ниже.
Мы рассмотрим связку:
[править] Инсталляция и настройка сенсора
[править] Инсталляция сенсора
В качестве программного обеспечения сенсора будем использовать softflowd [5]. Другое программное обеспечение, которое может использоваться как сенсор, перечислено ниже.
Для работы softlflowd требуется наличие libpcap. В FreeBSD может использоваться ng_netflow, в этом случае libpcap не обязателен.
[править] Запуск сенсора
После того, как softflowd был установлен, необходимо выбрать интерфейс, мониторинг которого будет производиться, указать IP адрес и UDP порт коллектора. Например, для интерфейса em0 и коллектора 172.16.13.5:8818 запуск softflowd будет выглядеть следующим образом:
Сенсор немедленно начнет слушать сеть и посылать информацию на коллектор.
Для того чтобы программа работала после перезагрузки, необходимо убедиться, что она стартует на этапе начальной загрузки!
[править] Проверка
Softflowd включает в себя программу контроля softflowctl, с помощью которой можно проверить работоспособность softflow:
Для того чтобы посмотреть информацию о самих потоках, дайте команду:
В этом выводе нас будет интересовать число активных потоков (2298) и строка «exported», сообщающая о количестве экспортированных потоков в коллектор.
Проверить, действительно ли данные отправляются и достигают коллектора можно с помощью ethereal, tcpdump или другого анализатора трафика. В случае каких-либо проблем можно использовать флаг -D демона softflowd. Softflowd посылает информацию о потоке после того, как тот будет завершен, например, прекратится FTP-сессия или загрузится web-страница. Это означает, что в любой момент времени у softflowd имеется некий кэш открытых потоков, в связи с чем остановку демона необходимо выполнять командой softflowctl shutdown. В противном случае вы потеряете данные активных потоков, которые еще не были завершены и отправлены на коллектор.
[править] Стартовый скрипт
Для того чтобы softflowd стартовал при загрузке автоматически, необходимо создать скрипт запуска и добавить его в загрузку системы. К сожалению, пока что в порт softflowd такой скрипт не входит, поэтому его придётся создать самостоятельно:
После того как скрипт создан, необходимо:
Для запуска скрипта в файле /etc/rc.conf следует установить переменные:
Запуск и останов скрипта выполняются командами:
[править] Инсталляция и настройка коллектора
Коллектор NetFlow предназначен для сбора данных, предоставляемых сенсором и сохранения их на диск для дальнейшего хранения и обработки.
[править] Инсталляция коллектора
В качестве Netflow-коллектора будем использовать flow-capture, очень популярный коллектор Netflow, входящий в состав пакета flow-tools.
В FreeBSD порт flow-tools располагается в каталоге /usr/ports/net-mgmt/flow-tools. Установите его обычным «make all install.» Не делайте «make clean», так как, возможно, вам придется устанавливать некоторые компоненты вручную. По этой самой причине не рекомендуется использовать прекомпилированный пакет.
Создайте каталог в котором flow-capture будет хранить свои данные. Пусть это будет /var/netflow. Убедитесь, что на дисковом разделе, в котором создается каталог, достаточно свободного места: на скоростной сети данные Netflow могут составить несколько гигабайт в неделю.
Для работы системы отображения, необходимо создать каталог saved.
[править] Запуск коллектора
Теперь нам необходимо выполнить стартовый скрипт flow-capture. Выглядит он следующим образом:
Большинство параметров можно оставить без изменения. Флаг -w указывает каталог данных, заключительный аргумент обозначает локальный IP, удаленный IP и прослушиваемый UDP порт. В этом случае, значение 0/0/8818 указывает коллектору слушать на всех локальных IP-адресах, принимать данные с любых удаленных хостов, порт 8818. В случае, если вы опасаетесь принимать чужие данные, то жестко задайте адрес сенсора.
Параметр -n указывает, сколько раз в сутки flow-capture должен создавать новый файл. Параметр -N задает глубину иерархии каталогов, в которых будут храниться файлы с данными NetFlow. Параметр -S указывает размер интервала в минутах, в течение которого flow-capture будет записывать информацию о счетчиках пакетов в лог-файл.
[править] Проверка
Для того, чтобы убедиться, что данные собираются, посмотрите, во-первых, появились ли файлы в каталоге netflow, а во-вторых, увеличивается ли размер временного файла.
[править] Стартовый скрипт
Точно также как и для softflowd, для того чтобы коллектор стартовал автоматически, необходимо создать скрипт запуска и добавить его в загрузку системы. В порт flow-tools такой скрипт не входит, поэтому его придётся создать самостоятельно:
После того как скрипт создан, необходимо:
Для запуска скрипта в файле /etc/rc.conf следует установить переменные:
Если нужно запустить несколько копий flow-capture, необходимо задать несколько каталогов для записи данных в переменной flowcapture_dir. Прослушиваемый порт, в этом случае, будет автоматически увеличиваться на 1 для каждой копии flow-capture. Например, пусть:
Тогда данные, поступающие на порт 8818 буду попадать в каталог /var/netflow/in, а, поступающие на порт 8819 — в каталог /var/netflow/out.
Запуск и останов скрипта выполняются командами:
[править] Инсталляция модуля Cflow.pm
Информация в этих файлах находится в бинарном формате, требующем для просмотра специальных инструментальных средств. Многие из тех инструментальных средств используют модуль Cflow.pm.
Большое количество программ составления отчетов Netflow используют perl модуль Cflow.pm для чтения файлов Netflow. Этот модуль включает в себя библиотеки и утилиты командной строки, необходимые для просмотра и редактирования файлов данных. Каждый коллектор имеет собственный формат хранения файлов и хотя Cflow.pm изначально создавался для чтения файлов cflowd(8), сейчас он способен обрабатывать и другие форматы.
В последних версиях FreeBSD /usr/ports/net-mgmt/p5-Cflow автоматически обнаруживает библиотеки flow-tools. Cflow вызывает их как -lnsl и в случае ошибки выдается предупреждение.
Если вы увидели это предупреждение, то самая пора начать волноваться — это означает, что Cflow работать не будет! В этом случае необходимо деинсталлировать пакет и установить его как рассказано ниже.
Если предупреждения не появилось, необходимо выполнить проверку работоспособности. Cflow включает в себя утилиту flowdumper(1), которая читает файлы данных из командной строки. Воспользуемся ей.
В коротком(short, -s) режиме каждая строка — поток. Она включает в себя адрес источника и назначения, тип транзакции и количество пакетов и байтов в этом потоке в следующем формате:
В показанном выше примере представлено две TCP/IP сессии — первая строка указывает на трафик, исходящий с 172.16.30.247, порт 80, на хост 216.98.200.250. Следующая строка показывает трафик, идущий в обратном направлении.
Если инсталляция прошла успешно, можно перейти к следующему разделу. В противном случае необходимо выполнить действия, описанные ниже.
[править] Установка Cflow из flow-tools/contribs
В случае некорректной установки, flowdumper выведет ошибку или ничего не выведет.
Если такая ситуация произошла, продолжать работу не получится. Необходимо деинсталлировать p5-Cflow и попытаться установить его другим способом.
В каталоге исходных текстов flow-tools должен находиться каталог contrib. В подкаталоге contrib у нас усть другой архив Cflow. Распакуем его:
Cflow часто собирает правильную библиотеку, когда устанавливается flow-tools. Выполним сборку модуля:
Пробуйте flowdumper снова, все должно работать.
В противном случае, применим решение «в лоб». Flow-tools устанавливает libft.a в каталог /usr/local/lib. Отредактируем Makefile.PL модуля Cflow.pm в части, касающейся библиотек flow-tools:
(добавлено 09.08.2006, os: FreeBSD 6.1) если и это не поможет (мой случай) измените
Checking if your kit is complete.
Writing Makefile for Cflow
ОДНАКО После установки у меня заработал flowdumper (несмотря на ругань на библиотеку), до этого команда ничего не возвращала. Я посчитал это решением проблемы, смотрю дальше.
После выполнения make и make install чего мы работоспособный flow-tools должен быть установлен.
С помощью CFlow можно написать множество разнообразных скриптов, решающих самые разные задачи обработки и визуализации.
[править] Обработка и визуализация данных NetFlow
FlowScan является скриптом, написанным на Perl и, анализируя записи NetFlow, сохраняет их в базе данных RRD, Round Robin Database. RRD предназначен для хранения постоянно изменяющихся данных, наиболее важными из которых являются последние данные, а более старые имеют не такое важное значение, и поэтому могут храниться не целиком, а в усреднённом виде. За счёт этого RRD не требует много дискового пространства даже для хранения информации о больших промежутках времени.
FlowScan позволяет сторонним модулям использовать свои процессы, для генерирования собственных отчетов. Ниже рассматривается один из таких модулей — CUFlow и CGI-скрипт CUGrapher.pl, который позволяет получить доступ к нему через Web-интерфейс.
[править] Установка FlowScan
Установку flowscan мы будем делать из системы портов, каталог программы находится в /usr/ports/net-mgmt/flowscan. Также будут установлены несколько модулей Perl в качестве зависимостей. Весь инструментарий FlowScan будет по умолчанию установлен в /usr/local/var/db/flows/bin. Учтите, что сразу после установки FlowScan не работоспособен!
Сначала, нам необходимо обновить модуль FlowScan, так как официальный дистрибутив долгое время не обновлялся и не способен обрабатывать записи потока. Автор написал обновленный модуль flowscan.pm, но не включил его в состав дистрибутива. Получите FlowScan.pm версии [6] и скопируйте ее в каталог /usr/local/var/db/flows/bin, перезаписав модуль версии 1.5.
В этом же самом каталоге находится образцовый файл конфигурации FlowScan flowscan.cf.sample. В первую очередь необходимо указать FlowScan, где искать файлы потока. FlowScan будет пытаться обработать каждый файл в каталоге, если вы не укажите регулярное выражение, описывающее необходимые файлы, включая временные файлы и вложенные каталоги. В следующем примере мы обрабатываем только завершенные файлы потока, хранящиеся в каталоге /var/netflows:
В ReportClasses перечисляются все используемые для вывода отчетов модули. FlowScan поставляется с двумя модулями: CampusIO и SubNetIO. Возможно, они впоследствии окажутся кому-то полезными, но сейчас будет использоваться CUFlow.
Параметр WaitSeconds задает интервал ожидания между попытками FlowScan проверить каталог. Довольно много инструментальных средств используют пятиминутный интервал и могут некорректно работать с меньшим значением.
В заключение, включим отладку для проверки правильности установки:
Конфигурирование FlowScan закончено, но нам все еще необходимо настроить модуль отчетов для правильного отображения информации.
[править] Конфигурирование CUFlow
Скачайте [7] (инфа http://www.columbia.edu/acis/networks/advanced/CUFlow/CUFlow.html), распакуйте и скопируйте CUFlow.pm и CUFlow.cf в /usr/local/var/db/flows/bin. Сам модуль можно оставить без изменений, но необходимо отредактировать cuflow.cf, чтобы он соответствовал вашим настройкам Perl.
Инструкция Subnet указывает принадлежащие вам сети. На основании этих данных CUFlow будет различать входящий и исходящий трафик. Subnet 192.168.2/23
Инструкция Network описывает сети, которые вы хотите обрабатывать отдельно друг от друга. Каждая инструкция будет отображаться как вариант в CGI скрипте. Как вы видите в этом примере, диапазоны могут перекрываться: Network 192.168.2.3,192.168.2.5,192.168.3.80 webservers Network 192.168.2.9,192.168.3.1 mailservers Network 192.168.2.0/25 infrastructure Network 192.168.2.128/25 dmz Network 192.168.3.0/25 administration Network 192.168.3.128/25 development
Директивой OutputDir указывается, где сохранять отчеты. Не храните их в доступном по сети месте или в каталоге flow-capture. OutputDir /var/log/cuflow
CUFlow также вычисляет самые активные сайты и строит «хит-парад» IP адресов, передавших большее количество трафика в течении 5 минут. За этот параметр отвечает опция Scoreboard. Эта опция использует три аргумента: число IP в «хит-параде», имя каталога для хранения старых списков и имя файла текущего списка. В следующем примере указывается вести «Top 10» IP адресов, сохранять отчеты в /usr/local/www/data/scoreboard и текущим считать файл /usr/local/www/data/scoreboard/topten.html:
В то время как список самых больших потребителей/генераторов трафика в данный пятиминутный период полезен для предотвращения проблем, так же был бы полезен список самых активных хостов. Опция AggregateScore позволяет вам сделать это:
Если у вас довольно сложная сеть, то может возникнуть необходимость в нескольких сенсорах Netflow. CUFlow может отделять данные от разных сенсоров, при этом различные маршрутизаторы буду доступны в CUFlow CGI.
Директива Services предназначена для указания TCP/IP портов, которые вы хотите отслеживать отдельно. Эта директива позволяет вам делать такие выводы как «80% нашего трафика приходится на HTTP» и тому подобное. Учтите, что это повышает нагрузку на сервер, поэтому не стоит здесь указывать весь /etc/services. Не стоит указывать сервисы, которые заблокированы, например Gnutella, Edonkey и т.д:
Директива Protocol в ней указываются другие протоколы транспортного уровня (layer4), в которых не нужно смотреть по какому порту идет трафик.
(ICMP), Protocol 6 (UDP) и Protocol 17 (TCP) в качестве базового минимума. Если есть много пользователей VPN то стоит отслеживать IPSec и GRE.
Так как Netflow был разработан в Cisco, то неудивительно, что много Netflow датчиков включают информацию BGP. CUFlow может отображать информацию о трафике к/от различных AS, используя для этого номер AS (опция ASNumber), softflowd не предоставляет информацию о номере автономной системы. В случае использования softflowd закомментируйте опцию ASNumber.
[править] Сохранение записей Netflow из FlowScan
По умолчанию, FlowScan удаляет записи после обработки. Можно сохранять эти записи в течении нескольких месяцев или пока позволяет дисковое пространство. Создайте подкаталог saved в директории Netflow и тогда FlowScan автоматически будет сохранять там обработанные файлы. Даже если вы не планируете хранение старых файлов потока, я рекомендую делать это хотя бы первое время, пока вы не убедитесь, что FlowScan работает правильно. В случае, если что-то пойдет не так, наличие этих данных облегчит поиск и устранение неисправности.
[править] Запуск FlowScan
Теоретически у нас все готово к запуску:
FlowScan должен запуститься, выводя подобные сообщения:
(У меня появились еще Use of uninitialized value in numeric gt (>) at /usr/local/lib/perl5/site_perl/5.8.8/HTML/Table.pm line 1732 ) На opennet.ru прочел, что это штатно. Проверяю, но файлы rrd действительно появились. Донат)
FlowScan анализирует все старые файлы потока, при этом процесс может занять довольно продолжительное время, все зависит от того, сколько файлов накопилось в системе.(Внимание! Лично у меня после запуска flowscan все файлы из указанной папку удалились. Донат) Достойной упоминания вещью здесь является «flow hit ratio», которая указывает на количество файлов, не соответствующих формату FlowScan и это очень хороший показатель. Если этот параметр равен 0, то скорее всего вы неправильно указали параметр Subnet.
Если FlowScan выдает ошибку «ERROR updating /var/netflow/. unknown option», необходимо внести исправления в файл FlowScan.pm, описанные в [8].
[править] Построение графиков
Теперь перейдем на URL и выберем, для примера, сеть. Вы должны будете увидеть массив раскрывающихся меню. Выберете любой и нажмите «Generate graph».
[править] Интеграция средств визуализации Netflow и Cacti
[править] Дополнительная информация
При написании этого раздела использовались следующие материалы:
[править] Программное обеспечение
Программы визуализации данных NetFlow:
[править] Источники
При написании использовались материалы статей: