Разработка электроники,
Систем автоматики,
Программного обеспечения
ООО "Антех ПСБ",
Санкт-Петербург
+79811865082
anteh@bk.ru
Если в кратце, то для учёта трафика используйте flow-tools или чего-нибудь платное.
Поскольку не знал, что лучше использовать для учёта, то настроил учёт трафика с использованием flow-tools и nfsen. Трафик с интерфейса смотрящего в сеть после IPFW посредством Netgraph расщепляется на 2 потока, один уходит к flow-tools, другой к nfsen. Отсюда и столько текста)
Будет рассмотрена установка настройка nfsen и всего, что нужно для его работы.
Подключение коллектора flow-capture из набора программ flow-tools, для использования параллельно с nfsen.
Конвертация уже имеющихся данных netflow v5 к формату nfcapd, который понимает nfdump коллектор, с последующим просмотром статистики через nfsen. Правда, при конвертации внешней статистики автоматически графики в текущей версии nfsen 1.3.5 не строятся, разбираться как там nfsen с RRDTool завязан нет ни желания ни времени, но саму статистику используя web морду nfsen можно просматривать через фильтр.
Настраиваем сервер для учёта общего трафика, и параметров сетевого обмена через один сетевой интерфейс, смотрящий к провайдеру. Данные будем просматривать через web интерфейс nfsen. СУБД не используется. По аналогии можно настроить для учёта на любом количестве сетевых интерфейсов.
Реализуем цепочку: ipfw->ng_ipfw->ng_netflow->ng_ksocket->nfdump->nfsen. И ipfw->ng_ipfw->ng_netflow->ng_ksocket->flow-capture->sfttonf->nfdump->nfsen. Предполагается, что с фаерволом ipfw пользователь знаком. ipfw как то там настроен и работает. Материал местами изложен избыточно подробно, это может помочь тем кто, как и автор столкнулся с задачей наблюдения за сетевым обменом, учётом трафика, и про netgraph, да и про многое другое, впервые. Замечания принимаются. Ну и если оно вам надо, то все описанные материалы вы будете использовать на свой страх и риск.
Лирическое отступление, о netgraph
Википедия: NetFlow - сетевой протокол, предназначенный для учёта сетевого трафика, разработанный компанией Cisco Systems. Является фактическим промышленным стандартом и поддерживается не только оборудованием Cisco, но и многими другими устройствами (в частности, Juniper и Enterasys). Также существуют свободные реализации для UNIX-подобных систем. Для ознакомления с netgraph нужно почитать: http://citrin.ru/daemonnews/netgraph.html -Всё о netgraph.
Установку компонентов производилась под FreeBSD 8.2 RELEASE p6.
Netflow имеет три основных компонента:
Сенсор. Будем использовать ng_netflow
Коллектор. Возьмем nfdump -идёт в составе nfsen
Система обработки и представления данных. Через web интерфейс nfsen
Съём статистики можно производить через хуки Ethernet интерфейса или через ng_ipfw. Первый способ самый быстрый. Второй использует ng_ipfw, что незначительно добавляет нагрузки, но получаем большую гибкость. IPFW может предварительно отфильтровать ненужный трафик перед передачей его в узел ng_ipfw. ng_netflow, ng_ipfw, ng_ksocket и прочие ng_* -это узлы. Просмотреть все имеющиеся KLD-модули узлов можно, введя команду:
# ls /boot/kernel/ng_*.ko
Узлы, как составные кирпичики, для построения нужной конфигурации обработки сетевых потоков. У каждого узла есть определённый набор крючков(hook) которыми он соединяется с соседними узлами. Узел можно/нужно конфигурировать, запрашивать его состояние, принимать ответные сообщения и т. д. Каждый крючок имеет уникальное имя, которое часто отражает его назначение.
Узел ng_ipfw - интерфейс между ipfw и системой netgraph может присутствовать только в одном экземпляре, создаёт интерфейс для доступа к подсистеме netgraph из IPFW. При загрузке в ядро, модуль автоматически создает свой узел в пространстве подсистемы netgraph с именем "ipfw:". ng_ipfw принимает подключения к произвольным номерным хукам, номера хуков указываются в правилах IPFW. Узел ng_netflow способен получать информацию о проходящем через него трафике и экспортировать ее в виде совместимым с протоколом NetFlow фирмы Cisco. Создание узла всегда происходит с подключением одного из хуков создаваемого узла.
Для взаимодействия ipfw и netgraph в ipfw существует два правила ngtee и netgraph, пример:
ipfw add netgraph 10 all from any to any - направит весь трафик попавший в правило, в хук ipfw:10 модуля ng_ipfw
ipfw add ngtee 20 ip from any to any - скопирует весь трафик попавший в правило, в хук ipfw:20 модуля ng_ipfw
ng_netflow поддерживает максимальное число крючков, равное NG_NETFLOW_MAXIFACES. Хуки Ng_netflow имеют имена iface0, iface1, iface2, ifaceN. Также соответствующие им out0, out1, out2, outN. И хук экспорта статистики export. Входящий трафик в ifaceN обрабатывается модулем учета. Если подключен соответственный хук outN, трафик без изменений уходит в него, если не подключен - никуда не уходит. Трафик вошедший в хук outN без изменений проходит к хуку ifaceN, без обработки модулем учета. Т.е. фактически на счетчики попадает только входящий трафик в ifaceN. Для управления поведением учета трафика есть настройки, о которых будет рассказано ниже. В итоге через хук export будут выходить UDP дейтаграммы netflow, этот кух обычно подключают к хуку inet/dgram/udp модуля ng_ksocket.
Экспортирует netflow версии v5. Принимаемые модулем контрольные сообщения, они же команды: info, ifinfo, setdlt, setifindex, settimeouts, setconfig, show. Setdlt устанавливает тип интерфейса, подключенного к ifaceN. Из всех возможных вариантов.
(/usr/src/sys/net/bpf.h)
#define DLT_NULL 0 /* BSD loopback encapsulation */
#define DLT_EN10MB 1 /* Ethernet (10Mb) */
#define DLT_EN3MB 2 /* Experimental Ethernet (3Mb) */
#define DLT_AX25 3 /* Amateur Radio AX.25 */
#define DLT_PRONET 4 /* Proteon ProNET Token Ring */
#define DLT_CHAOS 5 /* Chaos */
#define DLT_IEEE802 6 /* IEEE 802 Networks */
#define DLT_ARCNET 7 /* ARCNET */
#define DLT_SLIP 8 /* Serial Line IP */
#define DLT_PPP 9 /* Point-to-point Protocol */
#define DLT_FDDI 10 /* FDDI */
#define DLT_ATM_RFC1483 11 /* LLC/SNAP encapsulated atm */
#define DLT_RAW 12 /* raw IP */
Поддерживаются только Ethernet и голый IP, соответственно варианты 1 и 12. Первый вариант установлен по умолчанию. Синтаксис setdlt {iface=0 dlt=12}. Settimeouts - устанавливает таймауты активных и не активных потоков, после которых статистика будет отправлена в коллектор. Синтаксис settimeouts {inactive=15 active=1800}. Таймаут активного потока - по умолчанию 1800 секунд. И таймаут не активного потока по умолчанию 15 секунд. C помощью Info можно просмотреть информацию о настройках таймаутов и проверить работоспособность ng_netflow.
Установка/настройка сенсора ng_netflow v5
В общем можем убедиться, что /boot/kernel/ng_netflow.ko, /boot/kernel/netgraph.ko, /boot/kernel/ng_ipfw.ko и т.д. в наличии.
Добавляем в конфигурационный файл ядра параметры и пере собираем его. Кому не нравится пересборка, могут подключить соотвецтвующие модули динамически. Файл ядра лежит в паке /usr/src/sys/amd64/conf в зависимости от типа вашей системы вместо amd64 может быть другая папка. Не используем оригинальный файл конфигурации ядра GENERIC. Копируем и переименовываем GENERIC например в NNKER. Добавляем параметры в NNKER:
options NETGRAPH
options NETGRAPH_SOCKET
options NETGRAPH_IPFW
options NETGRAPH_NETFLOW
options NETGRAPH_KSOCKET
Пере собираем и устанавливаем новое ядро:
Проверяем, что есть папка /usr/src/sys/amd64/compile, если папки нет, то создаём её, иначе команда config не отработает будет ругаться No such file or directory.
NNKER в текущем случае имя конфигурационного файла ядра, если всё в в порядке то увидим что то вроде:
Если не всё в порядке, то исправляем ошибки в файле конфигурации ядра.
Далее идём в:
И выполняем команду:
Через минут 40 или несколько часов, процесс завершится и производим перезагрузку.
Предполагается, что с IPFW пользователь знаком, и сейчас IPFW настроен и работает. В текущей конфигурации используется IPFW + ядерный NAT. В общем параметры ядра для ядерного NAT:
options IPFIREWALL
options IPFIREWALL_NAT
options LIBALIAS
Нужен ли вам NAT решаем сами. Добавляем в файл конфигурации IPFW строки:
(Это только пример, чтобы через # ipfw show | more посмотреть, что правила срабатывают и трафик уходит в ng_ipfw. re1 имя сетевого интерфейса)
/sbin/ipfw -q add 00440 ngtee 10 ip from any to any out xmit re1 # Исходящий трафик
/sbin/ipfw -q add 00450 ngtee 20 ip from any to any in recv re1 # Входящий трафик
/sbin/ipfw -q add 00460 ngtee 30 ip from any to any via re1 # Исходящий + входящий
Куда их добавлять, сколько и в каком виде решаем сами, здесь приведён пример. Сам использовал только одно правило, если как в примере, то правило с номером 00460. Разница между правилами ngtee и netgraph в том, что все пакеты попавшие в правило netgraph передаются только в ng_ipfw и дальше по цепочке IPFW не передаются. Пакеты попавшие в ngtee передаются и в ng_ipfw и дальше по цепочке IPFW. Или другими словами netgraph направляет весь поток в ng_ipfw, а ngtee направляет копию потока в ng_ipfw и сам поток далее по цепочке IPFW.
Возможно удобней всего входящий и исходящий трафик учитывать отдельно, т.е. если как в примере, то использовать правила 00440 и 00450. Но для упрощения описания будет приведён пример для 00460 правила.
Перезапустить правила IPFW после изменения, в общем случае, можно командами:
# ipfw -q -f flush #Очистка правил ipfw. Разумеется работаем локально. Нужно, если в правилах ipfw не предусмотрена автоматическая очистка.
# /bin/sh /etc/fwall.conf & #Загрузка правил. fwall.conf конфигурационный файл фаервола, создаётся вручную, может иметь любое имя и располагаться где угодно.
Проверяем работоспособность модуля ng_ipfw скомпилированного с ядром, нужно убедиться, что происходит передача пакетов от ipfw к ng_ipfw:
# ngctl
+ list
Увидим примерно следующее:
Ipfw -узел ng_ipfw
Ngctl1724 -узел запущенного экземпляра ngctl
# kldstat
Здесь увидим только kernel модуль, если будут присутствовать другие подгруженные netgrapg модули, то после компиляции соответствующих модулей в ядро их здесь не будет.
Проверяем происходит ли передача пакетов от фаервола IPFW к узлу ng_ipfw:
Произведём какие либо действия, приводящие к сетевому обмену, например обновление портов #portsnap fetch, или обновим интернет страницу на компьютере локальной сети стоящим за NAT. Далее запускаем команду просмотра правил IPFW:
# ipfw show | more
Ищем номера ipfw правил(первый столбец), указанных для ngtee и должны увидеть, что количество пакетов(второй столбец), к-во байт(третий) для каждого из правил не нулевое пример:
Правило 00440 направит/скопирует весь трафик попавший в правило в хук ipfw:10 модуля ng_ipfw. Правило 00450 направит/скопирует весь трафик попавший в правило в хук ipfw:20 модуля ng_ipfw. Правило 00460 направит/скопирует весь трафик попавший в правило в хук ipfw:30 модуля ng_ipfw.
Три правила 00440, 00450, 00460 использовались исключительно для примера, можно обойтись и одним для одного сетевого интерфейса.
В общем убедились, что из фаервола ipfw пакеты передаются в netgraph узел "ipfw:".
Чтобы не плодить конфигурационные файлы, в конфигурационный файл фаервола ipfw добавляем скрипт настройки узлов, плохо или нет туда его добавлять не знаю, всё работает. Добавляется до начала описания правил. Кусок конфигурационного файла фаервола:
#netgraph ipfw->ng_ipfw->ng_netflow->ng_ksocket->127.0.0.1:56783
/usr/sbin/ngctl -f- <<-SEQ
mkpeer ipfw: netflow 30 iface0
name ipfw:30 IPFWtoNetFlow
msg IPFWtoNetFlow: setdlt {iface=0 dlt=12} #Interfase type: possible 1 or 12
msg IPFWtoNetFlow: setifindex {iface=0 index=3} #Number equivalent re1 is 3
msg IPFWtoNetFlow: settimeouts {inactive=16 active=1801}
mkpeer IPFWtoNetFlow: ksocket export inet/dgram/udp
name IPFWtoNetFlow:export Ksock
msg Ksock: connect inet/127.0.0.1:56783 # nfcadp(nfsen)
SEQ
mkpeer ipfw: netflow 30 iface0 #производит создание безымянного узла типа netflow и устанавливает соединение между крючками ipfw:30 и <пока безымянный узел типа netflow>:iface0. Цифра 30 берётся из конфигурационного файла фаервола ipfw она идёт за именем правила ngtee. iface0 стандартное имя крючка для узла типа netflow.
name ipfw:30 IPFWtoNetFlow #назначаем имя "IPFWtoNetFlow" безымянному узлу типа netflow.
msg IPFWtoNetFlow: setdlt {iface=0 dlt=12} #устанавливаем тип интерфейса 12 для крючка iface0. Варианта два либо 1 либо 12, 1 установлен по умолчанию и здесь не подходит. 12 -принимать через iface0 чистые IP пакеты.
msg IPFWtoNetFlow: setifindex {iface=0 index=3} #Здесь устанавливаем номер интерфейса(параметр index=), в который пакет вошел. Каждому имени интерфейса re1 re2 nfe0 и т.д. сопоставляется некий номер. При некоторых вариантах реализации сетевого обмена получается так, что этот номер для узла ng_netflow неизвестен или неправильный и явное указание этого номера решает проблему. Предполагаю, что т.к. пакеты мы берём из ipfw то правильный индекс уже был проставлен и эта настройка ни на что не повлияет и нахрен не нужна. Но если уж приспичило, то для выяснения чему равен index=??? или номер сетевого интерфейса, с которого снимаем статистику, делаем следующее:
Создаём файл с расширением .c например if_nametoindex.c. В пустой if_nametoindex.c файл добавляем:
#include <sys/socket.h>
#include <net/if.h>
using namespace std;
#include <iostream>
int main(int argc, char **argv)
{ for (int i = 1; i < argc; i++)
{ cout << argv[i] << " = " << if_nametoindex(argv[i]) << "\n";
}
return 0;
}
ПЕРЕВОД СТРОКИ В КОНЦЕ ФАЙЛА ОБЯЗАТЕЛЕН
Находясь в тойже директории, что и if_nametoindex.c выполняем компиляцию:
# c++ -o if_nametoindex if_nametoindex.c
Появится исполняемый файл, который зелёный если через mc-light на него смотреть. Далее запускаем исполняемый файл:
# ./if_nametoindex "re1" "re2" "lo0"
re1 = 3
re2 = 4
lo0 = 7
Запускается одним или несколькими параметрами через пробел. В качестве параметра в main передаётся имя/имена сетевого/ых интерфейса/ов и в ответ выдаётся соответствующий номер, который и присваиваем index=3 для re1.
Соответственно, если произвести добавление/удаление сетевой карты, то эти цифры могут поменяться, нужно будет подправлять значения. На разных компьютерах соответствие имени сетевого интерфейса его номеру может быть/будет разным.
msg IPFWtoNetFlow: settimeouts {inactive=16 active=1801} #устанавливает таймауты активных и не активных потоков, после которых статистика будет отправлена в коллектор. Синтаксис «settimeouts { inactive=15 active=1800 }» По умолчанию таймаут активного потока 1800 секунд, не активного 15 секунд.
mkpeer IPFWtoNetFlow: ksocket export inet/dgram/udp #производит создание безымянного узла типа ksocket и устанавливает соединение между крючками IPFWtoNetFlow:export и <пока безымянный узел типа ksocket>: inet/dgram/udp.
name IPFWtoNetFlow:export Ksock #назначаем имя "Ksock" безымянному узлу типа ksocket.
msg Ksock: connect inet/127.0.0.1:56783 #Куда отправляем netflow данные задаём хост и порт, на который будут уходить наши пакеты. В текущем случае коллектор находится на этом же компьютере поэтому всё засылаем на loopback.
Перезапускаемся на всякий
Настройку цепочки "ipfw -> ng_ipfw -> ng_netflow -> ng_ksocket ->127.0.0.1:56783" закончили, проверим что получилось.
Проверяем собралась ли нужная нам цепь:
# ngctl
+ ls
Если вывод подобный, то всё в порядке.
Проверим принимаются ли данные в узел ng_netflow "IPFWtoNetFlow:":
# ngctl
+ msg IPFWtoNetFlow: info
Видим, что чтото принимается.
Проверим отправляет ли узел "Ksock" что ни будь на 56783 порт. В конфигурационном файле фаервола прописываем разрешающее правило для 127.0.0.1 на 56783 порт и при наличии обмена, после команды
# ipfw show | more
можем видеть, что вторая и третья колонки соответствующего правила не нулевые, значит какие то данные узел "Ksock" передаёт, например, если вместо 127.0.0.1 был бы настроен 192.168.10.1, то увидим:
Убираем всё лишнее из конфигурационного файла ipfw.
Цепочка ipfw->ng_ipfw->ng_netflow->ng_ksocket-> inet/127.0.0.1:56783 настроена.
Теперь к 56783 порту теперь можем подключить какой либо коллектор. В текущем случае, подключаем либо nfsen(коллектор + веб морда), либо flow-capture(коллектор).
Установка/настройка коллектора flow-capture вместо nfdump(если устанавливаем nfsen, то раздел пропускаем):
Для разграничения nfsen и flow-capture коллекторов можно использовать разные номера портов. Можно настроить и одновременную работу, в этом случае нужно настроить несколько ksocket один на nfsen второй на flow-capture. Но для упрощения описания оставим настройки netgraph такими же. Т.е. если используем flow-capture то nfsen не запускаем и наоборот.
Устанавливаем из портов flow-tools:
# make install clean
Создаём каталог /usr/flows для хранения записей netflow потока. Группа flowtools и пользователь flowtools создаются автоматически при установке flow-tools.
Назначаем группу(flowtools) и владельца(flowtools) папке /usr/flows:
# chown -R flowtools:flowtools /usr/flows
В /etc/rc.conf добавляем строки:
#flow-tools
flow_capture_enable="YES"
flow_capture_user="flowtools"
flow_capture_group="flowtools"
flow_capture_datadir="/usr/flows"
flow_capture_localip="127.0.0.1" #ip машины, на которой запущен коллектор flow-tools
flow_capture_remoteip="127.0.0.1" #ip машины, с которой мы принимаем flow поток
flow_capture_port="56783" #порт коллектора flow-capture на котором он слушает и получает данные
flow_capture_flags="-N 3 -n 288 -z 0 -E 100G -V 5 -S 5"
#-N3 хранение файлов данных в папках YYYY/YYYY-MM/YYYY-MM-DD/flow-file, задает глубину иерархии каталогов
#-n288 24*60/288=5min количество записей в день т.е. если =288 то файл создаётся раз в 5 минут
#-z0 уровень сжатия данных выбирается от 0 до 9. 0-без компрессии, 9-максимальная компрессия. На компрессию потребуется дополнительные ресурсы процессора.
#-E100G под данные netflow отводится 100G -100 гигабайт. По достижению предела, судя по всему данные будут циклически перезаписываться.
#Параметр -S5 указывает размер интервала в минутах, в течение которого flow-capture будет записывать информацию о счетчиках пакетов в лог-файл.
#-V5 версия netflow
#-S5 Интервал времени в минутах, по истечении которого демон будет генерировать статистику о числе полученных потоков, числе обработанных пакетов, а также число потерянных потоков. Информация заносится в системный журнал /var/log/messages. Правда не наблюдал, чтобы туда что либо записывалось.
Проверяем, чтобы в конфигурационном файле фаервола ipfw была строка
msg Ksock: connect inet/127.0.0.1:56783
Перезагружаемся и проверяем, запустился ли сервис flow-capture:
# sockstat -4 -l | grep flow
Если видим подобное, то всё в порядке. Проверяем также, что в папке /usr/flows с интервалом в 5 минут появляются файлы. Через mc-light выглядеть это будет так:
Можно по обновлять страницы в браузере, и убедиться, что размеры последующего файла будут меняться. Согласно настройкам за 24часа будет создано 288 файлов(параметр -n 288) файл раз в 5 минут. Если нужно запустить несколько копий flow-capture, необходимо задать несколько каталогов для записи данных в переменной flowcapture_dir. Прослушиваемый порт, в этом случае, будет автоматически увеличиваться на 1для каждой копии flow-capture.Например, пусть:
flowcapture_dir="/var/netflow/in /var/netflow/out"
flowcapture_port=8818
Тогда данные, поступающие на порт 8818 буду попадать в каталог /var/netflow/in,а, поступающие на порт 8819 - в каталог /var/netflow/out.
Содранный пример настроек для нескольких коллекторов трафика, на случай если придётся(нижеприведённые строки настроек никуда не вписываем, не обращаем внимания):
# Разрешаем старт flow_capture
flow_capture_enable="YES"
#Указываем ip адрес на котором будет слушать flow_capture
flow_capture_localip="107.25.214.157"
#Делаем 2 разных коллектора трафика для 2 роутеров
flow_capture_profiles="router1 router2"
#Директория где будут сохраняться принятые флоу записи для первого роутера
flow_capture_router1_datadir="/var/db/flows/router1"
#Порт на котором слушает флоу для первый роутера
flow_capture_router1_port="5632"
#Флаги для первого роутера
flow_capture_router1_flags="-E20G -n287 -N-2"
#Далее аналогично, но для второго роутера
flow_capture_router2_datadir="/var/db/flows/router2"
flow_capture_router2_port="5633"
flow_capture_router2_flags="-E5G -n287 -N-2"
flow-capture настроили. Теперь пользуясь различными flow-tools программами можно просматривать трафик на настроенном сетевом интерфейсе.
Установка/настройка nfsen apache22 php5
Устанавливаем в следующей последовательности:
apache22
PHP5 с поддержкой apache
nfsen
Устанавливаем web сервер apache22
# whereis apache22
apache22: /usr/ports/www/apache22
# cd /usr/ports/www/apache22
# make && make install && make clean
# rehash
в /etc/rc.conf добавляем строку
apache22_enable="YES"
редактируем /usr/local/etc/apache22/httpd.conf
Listen 192.168.200.2:80 #-IP локальной сети, сетевой карты компьютера, на котором установлен apache. Apache будет обрабатывать запросы пришедшие только на этот сетевой интерфейс и на указанный порт.
ServerName 192.168.200.2 #Можно не указывать, но на всякий случай рекомендуют чтоб было. Поскольку DNS записи нет, то в качестве имени указываем IP
DocumentRoot "/usr/local/www/nfsen"
Или
DocumentRoot "/usr/local/www/apache22/data"
Alias /nfsen "/usr/local/www/nfsen"
После:
<Directory />
AllowOverride None
Order deny,allow
Deny from all
</Directory>
Добавляем:
<Directory "/usr/local/www/nfsen">
Options Indexes FollowSymLinks
DirectoryIndex nfsen.php
AllowOverride None
Order allow,deny
Allow from all #1 Что в строках 1 и 2 написать решаем сами
#Allow from 192.168.ля.ля #2 в общем случае доступ разрешён отовсюду
</Directory>
Комментируем:
#<Directory "/usr/local/www/apache22/data">
# Options Indexes FollowSymLinks
# AllowOverride None
# Order allow,deny
# Allow from all
#</Directory>
Раз комментируем
# Various default settings
Include etc/apache22/extra/httpd-default.conf
Комментируем:
#<IfModule ssl_module>
#SSLRandomSeed startup builtin
#SSLRandomSeed connect builtin
#</IfModule>
После установки php проверяем, чтобы в конце файла были строки:
Include etc/apache22/Includes/*.conf
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps
Редактируем /usr/local/etc/apache22/extra/httpd-default.conf
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5
UseCanonicalName Off
AccessFileName .htaccess
ServerTokens Prod
ServerSignature Off
HostnameLookups Off
файл /usr/local/etc/apache22/httpd.conf проверяем на ошибки командой
# apachectl configtest
Syntax OK
Всё хорошо.
Просто инфа: управление apache возможно следующими командами:
# apachectl start
# apachectl restart
# apachectl graceful
# apachectl stop
Устанавливаем PHP5, для apache22 и nfsen.
# whereis php5
php5: /usr/ports/lang/php5
# cd /usr/ports/lang/php5
# make && make install && make clean
Нужно, чтобы была выбрана опция Build Apache module
Если в процессе установки/переустановки окно с опциями не появилось, то:
# make deinstall удаляем то, что было установлено
# make config вызов
# make && make install && make clean снова установка
Проверяем, чтобы в /usr/local/etc/apache22/httpd.conf появились строки:
…
…
LoadModule php5_module libexec/apache22/libphp5.so
…
…
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps
Если последние 2 строки не появились, добавляем их вручную в конец файла.
Устанавливаем nfsen:
nfsen не работает с flow-tools данными, он использует свой коллекто nfdump, у которой свой формат хранения netflow данных, отличный от flow-tools. Но есть ft2nfdump - конвертор данных из формата flow-tools в nfdump.
Нужно проверить версию порта libtool
# pkg_info | grep libtool
Во время текущей установки, с версией libtool-2.2.10 выдаётся ошибка и требует обновления до 2.4. Обновляем через portupgrade. Если не установлен portupgrade, то ставим:
Инфа про portupgrade:
-r с рекурсивным обновлением всех зависимостей
-b создание резервной копии старых версий пакетов
-a обновление всех установленных пакетов
-f форсированное обновление пакетов - здесь следует подробно изучить UPDATING
Вместо имени обновляемого пакета могут использоваться выражения, например при обновление всех пакетов начинающихся на php5 можно использовать команду: #portupgrade 'php5*'
Настройка поведения portupgrade производится в файле /usr/local/etc/pkgtools.conf.
# rehash
Проверяем, какие порты можно обновить:
# pkg_version -v | grep "need"
Выводится ряд строк, в том числе и:
libtool-2.2.10 < needs updating (port has 2.4_1)
Смотрим информацию о пакете:
# pkg_info | grep libtool информация о порте
# portupgrade libtool обновление порта
# pkg_info | grep libtool информация о порте
libtool-2.4_1 Generic shared library support script
libtool обновили до libtool-2.4_1
снова запускаем установку пакета nfsen, вместе с ним установятся все нужные зависимости:
# rehash
Если в процессе установки периодически наблюдаем строки
"===> WARNING: Vulnerability database out of date, checking anyway"
То ждём, когда закончится установка и делаем:
# portaudit -Fad
Если portaudit не установлен, то ставим.
Видим, что с пакетом косяк "Affected package: ruby-1.8.7.302,1"
# pkg_version -v | grep "need" выводим список портов, которые можно обновить
И в списке видим ruby-1.8.7.302,1
# portsnap fetch ;на всякий
# portupgrade ruby обновление порта
# pkg_info | grep ruby
ruby-1.8.7.352_2,1 An object-oriented interpreted scripting language
# portaudit -Fad
auditfile.tbz 100% of 72 kB 62 kBps
New database installed.
Database created: Wed Jan 18 01:45:00 GMT-4 2012
0 problem(s) in your installed packages found.
Теперь всё ок.
# find / -name ft2nfdump
/usr/local/bin/ft2nfdump
Видим, что nfdump и нужный нам ft2nfdump установлены.
Если нужно, то для проверки возможности конвертации из файлов созданных flow-capture в файлы nfdump производим такое преобразование над одним из файлов.
ns1# ft2nfdump -r /usr/flows/2012/2012-01/2012-01-17/ft-v05.2012-01-17.000459+0400 | nfdump | less
Date flow start Duration Proto Src IP Addr:Port Dst IP Addr:Port Packets Bytes Flows
2012-01-17 00:04:12.429 0.000 UDP 85.21.78.91:123 -> 120.18.125.114:123 1 76 1
2012-01-17 00:04:12.429 0.000 TCP 61.128.172.133:16348 -> 120.88.125.114:22 1 48 1
2012-01-17 00:04:25.429 4.000 TCP 94.245.82.12:80 -> 120.88.125.114:42055 3 308 1
…
…
…
Видим, что один из файлов netflow потока созданный flow-capture был прочитан, даже видим, что какая то зараза на 22й порт ломится во второй строке. И данные какого то сервера времени на 123й порт.
Просто инфа про управление nfsen
Файл настроек nfsen находится в /usr/local/etc/nfsen.conf
Запуск nfsen:
/usr/local/bin/nfsen start
# nfsen start
Перезапуск после внесения изменений в /usr/local/etc/nfsen.conf
/usr/local/bin/nfsen reload
# nfsen reload
# nfsen stop
Всегда проверяем на ошибки syslog файл /var/log/messages
Для автозапуска nfsen можно, например в конфигурационный файл файервола, добавить строку:
#Nfsen start:
/usr/local/bin/nfsen start
Запустим nfsen:
# nfsen start
Видим, что стартовало 3 коллектора настроенных по умолчанию, они не нужны, отключаем. Информация собираемая коллекторами находится в папке /usr/local/var/nfsen/profiles-data/live
В файле конфигурации /usr/local/etc/nfsen.conf отключаем три работающих коллектора. Точнее 2 коллектора и один(upstream1) не нашол что это такое. Сбор информации, по умолчанию, производится с источников peer1 peer2 и upstream1. Для их отключения параметру 'port' присваиваем значение 0:
%sources = (
'upstream1' => { 'port' => '0', 'col' => '#0000ff', 'type' => 'netflow' },
'peer1' => { 'port' => '0', 'IP' => '172.16.17.18' },
'peer2' => { 'port' => '0', 'IP' => '172.16.17.19' },
);
# nfsen stop
# nfsen start
Видим, что коллекторы отключены, отлично.
Проверяем работу nfsen, пока без файлов данных:
В браузере набираем, ну или какой адрес был выбран:
http://192.168.200.2/nfsen/nfsen.php
Если в браузере видим:
ERROR: nfsend connect() error: No such file or directory!
ERROR: nfsend - connection failed!!
ERROR: Can not initialize globals!
Значит nfsen не запущен
# nfsen start
В браузере видим что то вроде этого:
Переходим на вкладку Stats и видим:
Подобные проблемы возможно возникают, если вопрос с переходом на летнее/зимнее время, в связи с его отменой, был решён при копировании файла /usr/share/zoneinfo/Etc/GMT-4 (если для московского времени) в папку /etc и последующим его переименованием в localtime. При таких действиях на команду
# date будет следующий вывод.
В общем нужно сделать всё по честному:
# whereis zoneinfo
zoneinfo: /usr/ports/misc/zoneinfo
# cd /usr/ports/misc/zoneinfo
# make && make install && make clean
# tzsetup
Появляется первый диалог отвечаем нет, далее по ходу пьесы
Рекомендуется сделать перезагрузку, далее
# date
Thu Jan 19 17:00:15 MSK 2012
Всё отлично
Проверяем, что получилось и… ничего не получилось, ну хоть время стало временней чем было.
Тогда файл /usr/local/etc/php.ini-production копируем в эту же директорию /usr/local/etc/ с заменой имени на php.ini, далее в php.ini находим строки:
[Date]
; Defines the default timezone used by the date functions
; http://php.net/date.timezone
;date.timezone =
Раз комментируем (удаляем ;) четвёртую строку и присвоим ей следующее значение:
date.timezone = Europe/Moscow
либо перезапускаем apache, либо компьютер, проверяем что получилось:
Предупреждений нет, пол дела сделано. Для полного фен Шуя нужно установить ntp сервер времени, как это сделать и зачем оно надо, можно посмотреть в сети.
Настраиваем коллектор nfdump на приём данных от ранее настроенного сенсора:
конфигурации nfsen /usr/local/etc/nfsen.conf
# nfsen stop
Заменяем существующие настройки для %sources = (… на строки:
%sources = (
'allin' => { 'port' => '56784', 'IP' => '127.0.0.1' },
);
allin здесь имя папки /usr/local/var/nfsen/profiles-data/live/allin в эту папку коллектор и будет складывать все данные.
ns1# nfsen start
Configured sources do not match existing sources. Run 'nfsen reconfig' first!
ns1# nfsen reconfig
New sources to configure : allin
Remove configured sources: peer2 upstream1 peer1
Continue? [y/n] y
Add source 'allin'
…
…
Подождём минут 15 и посмотрим в папку /usr/local/var/nfsen/profiles-data/live/allin там должны появиться файлы коллектора.
В браузере пишем http://192.168.200.2/nfsen/nfsen.php и видим что то похожее на картинку ниже. На картинке данные накопленные за несколько дней. В общем что то видим.
На картинке не показана нижняя часть со статистикой.
Как, что, и где настраивается в nfsen смотрим в сети.
Подгрузить существующие данные, собранные не nfdump получилось, но картинок для них не строится. Т.е. графики видны только для данных собранных местным nfdump коллектором. Данные сконвертированные из flow-capture можно посмотреть через фильтр в nfsen, но графики для них не рисуются. Как произвести преобразование из flow-capture в nfdump и поместить в nfsen речь пойдёт ниже.
На всякий поставим на сбор данных ещё и flow-capture коллектор, что удобней будет потом разберёмся, благо трафик никакой и места лишнего на винчестере полно.
Установка одновременно работающих коллекторов flow-capture и nfdump
ng_hub - принимает данные на любом подключенном хуке с произвольным именем, и отправляет эти данные без изменений на все подключенные хуки. Контрольных сообщений не принимает.
В конфигурационном файле фаервола меняем скрипт настройки netgraph. Добавляем модуль ng_hub, для размножения потоков netflow v5 на 2 порта для flow-capture и nfdump, меняем скрипт настройки netgraph на следующий:
# NETGRAPH
# ipfw->ng_ipfw->ng_netflow->ng_hub|-> ng_ksocket->127.0.0.1:56783 #flow-capture
# |-> ng_ksocket->127.0.0.1:56784 #nfdump
/usr/sbin/ngctl -f- <<-SEQ
mkpeer ipfw: netflow 30 iface0
name ipfw:30 IPFWtoNetFlow
msg IPFWtoNetFlow: setdlt {iface=0 dlt=12} #Interfase type: possible 1 or 12
msg IPFWtoNetFlow: setifindex {iface=0 index=3} #Number equivalent re1 is 3
msg IPFWtoNetFlow: settimeouts {inactive=16 active=1801}
mkpeer IPFWtoNetFlow: hub export hook0
name IPFWtoNetFlow:export hubb
mkpeer hubb: ksocket hook1 inet/dgram/udp
name hubb:hook1 KsockFC
msg KsockFC: connect inet/127.0.0.1:56783 #for flow-capture collector
mkpeer hubb: ksocket hook2 inet/dgram/udp
name hubb:hook2 KsockNFCD
msg KsockNFCD: connect inet/127.0.0.1:56784 #for nfdump(nfsen) collector
SEQ
Кому хочется можно ng_hub, запускаемый модулем на данный момент, скомпилировать с ядром (options NETGRAPH_HUB).
Можем посмотреть, что подгруженно как модуль:
# kldstat
Файлы netflow v5 сгенерированные flow-capture будут конвертированы и помещены в нужные папки, согласно текущим настройкам иерархии директорий nfsen. nfsen настроен и работает.
В файле /usr/local/etc/nfsen.conf добавляем запись отключённого коллектора flowcapt параметр 'port' => '0'. Работающий коллектор allin, или то что у вас настроено не трогаем.
%sources = (
'flowcapt' => { 'port' => '0', 'col' => '#0000ff', 'type' => 'netflow' },
'allin' => { 'port' => '56784', 'IP' => '127.0.0.1' },
);
Далее:
# nfsen stop
Configured sources do not match existing sources. Run 'nfsen reconfig' first!
# nfsen reconfig
New sources to configure : flowcapt
Continue? [y/n] y
Add source 'flowcapt'
Start/restart collector on port '0' for [no collector]
Restart nfsend:[68019]
Появилась новая директория /usr/local/var/nfsen/profiles-data/live/flowcapt
Пусть данные netflow v5 созданные flow-capture коллектором находятся в папке /usr/flows
Качаем утилиту sfttonf и конфигурационный файл к ней. Помещаем sfttonf и конфигурационный файл пускай в одну и туже папку /aa. Что за sfttonf такой описано ниже.
sfttonf использует ft2nfdump конвертор netflow v5. Не знаю, конвертирует ли ft2nfdump сжатые данные flow-capture, проверял только на не сжатых.
Убеждаемся, что в /usr/local/etc/nfsen.conf параметр:
$SUBDIRLAYOUT = 1; это # 1 %Y/%m/%d year/month/day -иерархия директорий, в которых хранятся данные, эту структуру можно менять, но потребуется перезапуск nfsen и некоторые манипуляции о которых nfsen сообщит при запуске. nfsen stop, nfsen start.
К месту, nfsen читает как сжатые, так и несжатые nfcapd. Файлы.
Редактируем конфигурационный файл sfttonf.conf, в текущем случае интересует только одна строка /usr/flows > /usr/local/var/nfsen/profiles-data/live/flowcapt %Y/%m/%d %z которая означает: брать flow-capture файлы из /usr/flows преобразовывать, сжимать(%z) и помещать в /usr/local/var/nfsen/profiles-data/live/flowcapt/YYYY/mm/dd согласно году месяцу и дате содержащимся в имени их файла. Параметр %z означает что выходные файлы nfcapd. будут сжиматься. %Y/%m/%d такая иерархия директорий соответствует параметру $SUBDIRLAYOUT = 1; в /usr/local/etc/nfsen.conf. Nfsen жестко привязан к иерархии папок, в которых хранятся netflow данные. А также к именам файлов данных, и даже к времени их создания раз в 5 минут.
НАЧАЛО конфигурационного файла для sfttonf
…
…
# For creation sub hierarchy you can use %Y %m %d %H key words and another character
# in any combination
# If key words for sub hierarche will not be used that will be used sub hierarchy the sam
#--EXAMPL-----------------------EXAMPL------------------------------EXAMPL--
#</flow-capture source folder> > </nfsen destination folder>
#</flow-capture source folder> > </nfsen destination folder> %Y / %m / % d %z
#</flow-capture source folder> > </nfsen destination folder> %Ybla /%Ybla%mb
#</flow-capture source folder> > </nfsen destination folder> %Y/%Y-%m/%Y-%m-%
#---------------------------------------------------------------------------
/usr/flows > /usr/local/var/nfsen/profiles-data/live/flowcapt %Y/%m/%d %z
# /3 > /T5 %Y/%m/%d
#/usr/flows > /T6 %Y/%m/%d
#/usr/flows > /T3 %Ynah%de%mhr%H/lala%H%Y/%mmumu
#/usr/flows/in > /usr/local/var/nfsen/profiles-data/live/allin
#/usr/flows/out > /usr/local/var/nfsen/profiles-data/live/allout
#ServSt. Not remove last string
ОКОНЧАНИЕ
Запускаем из /aa директории sfttonf:
# ./sfttonf /etc/sfttonf/sfttonf.conf
…
…
ft2nfdump -r /usr/flows/2012/2012-02/2012-02-01/ft-v05.2012-02-01.011945+0400 | nfdump -z -w /usr/local/var/nfsen/profiles-data/live/flowcapt/2012/02/01/nfcapd.201202010119
ft2nfdump -r /usr/flows/2012/2012-02/2012-02-01/ft-v05.2012-02-01.012443+0400 | nfdump -z -w /usr/local/var/nfsen/profiles-data/live/flowcapt/2012/02/01/nfcapd.201202010124
ft2nfdump -r /usr/flows/2012/2012-02/2012-02-01/ft-v05.2012-02-01.012943+0400 | nfdump -z -w /usr/local/var/nfsen/profiles-data/live/flowcapt/2012/02/01/nfcapd.201202010129
Convertion finished
=== anteh.ru ===
Выполняем команды:
# nfsen -r live #что то вроде применения последних изменений
После выполнения должен появиться файлик .nfstat в /usr/local/var/nfsen/profiles-data/live/flowcapt.
# nfsen -l live #проверка применения последних изменений
Набираем в браузере:
http://<ip адрес на котором слушает web сервер>/nfsen/nfsen.php
приведу ещё раз картинку с настроенным nfsen, графики от встроенного nfdump коллектора, от внешне подключённой статистики графиков не будет.
Нижняя часть скриншота не влезла
На скриншоте данные записываемые встроенным коллектором nfdump. Ну в общем картинки по крайней мере в моём случае мало интересны, интерес представляет просмотр данных статистики через фильтр. Для того, чтобы как то научиться пользоваться nfsen, нужно к нему привыкнуть, многие вещи тут по началу не очевидны.
Не удалось разобраться, почему nfsen не рисует графики для внешних netflow баз статистики. Даже если свои собственные прикреплять как внешние(копирование существующей nfcapd статистики в …/live/<папка>), то графиков всё равно не видно. Возможно нужны какие-то манипуляции с RRDTool. Но просматривать статистику для внешних баз, через фильтр по web интерфейсу, можно, но только с профиля live, собственно что ещё нужно. Ни с одного созданного профиля что-либо прочитать не удалось.
Для работы с внешней подключённой базой нужно на вкладке details в профиле live в нижней части экрана после надписи Netflow Processing выбрать Source: ранее созданный flowcapt. Чтобы просматривать статистику через фильтр на пустом графике нужно указать диапазон времени, в котором будем просматривать базу. Нужно выбрать channel: только flowcapt затем Select->Time window и растащить курсор в разные стороны, попутно выбрав в Display масштаб времени за который нужно просматривать статистику. Задать какое-нибудь значение в фильтре, например any. И ещё левой половиной курсора просмотра на графике умудриться попасть в нужный начальный интервал времени, короче должен существовать файл с именем содержащем такую же дату и время, как указано в параметре tstart 2012-02-01-02-45 иначе будет выдано предупреждение, что такого файла нет. Можно файл в ручную переименовать, или посмотреть, чтобы такой существовал и выставить на него левую границу курсора. Но если учесть что коллектор nfdump формирует файлы только каждые 5 минут, а nfsen заточен строго на эти 5 минут, а файлы flow-capture не выровнены по границе в 5 минут и при преобразовании имя файла остаётся таким же, то даже если в настройках flow-captute стоит параметр 288 файлов в день(в лучшем случае), ааа б… какого….
В общем так и живём.
Основные неприятности с временной разбивкой файлов, nfsenу нужны файлы с именами выровненными по 5 минут. Опробовалась версия nfsen 1.3.5, возможно с последующими версиями будет попроще, а то скриншоты на программу всегда аж с переливающимися всеми цветами радуги картинками, а на деле пользоваться конечно можно…. В общем со временем разберёмся.
В теории с помощью sfttonf можно nfdump коллектор заменить на flow-capture коллектор. Задумка по началу заключалась именно в этом, но из за проблем с текущей версией nfsen-1.3.5 подобное решение не реализовывалось. Зачем вообще это нужно? Ну возможно, чтобы не использовалась библиотека libcap, возможность использования flow-tools, да и мало ли для чего ещё. Правда не знаю поддерживает ли ft2nfdump что-либо кроме netflow v5 и работает ли он с сжатыми flow-capture файлами.