(конфигурирование сенсора-источника пропущено, оно несложно, аналогично NetFlow и очень сильно вендорнозависимо)
Использовался пакет nfdump-1.6.10. Пакет скачивали и распаковывали, затем конфигурировали с ключом —enable-sflow
, так как по умолчанию этот режим не включен.
Далее make, make install — как обычно, трудностей не возникло.
За работу с sflow отвечает демон sfcapd
. У него достаточно много конфигурационных параметров, например можно задать путь к директориям, куда будут записываться flow-файлы, временнОй интервал, за который формируется файл, «выровнять» файл по минутной границе, разрешить прием от определенного источника и др.
Первый запуск (большинство параметров по умолчанию) — слушаем IPv4 и IPv6-данные от сенсора 10.0.0.11, файлы будут формироваться в директории /var/sflow/10_0_0_11, включен режим отладки — то есть смотрим на результаты на экране
sfcapd -n TEST,10.0.0.11,/var/sflow/10_0_0_11 -E
Если пошли строки с данными такого вида
Flow Record:
Flags = 0x81 FLOW, Sampled
export sysid = 1
size = 68
first = 1375095311 [2013-07-29 14:55:11]
last = 1375095311 [2013-07-29 14:55:11]
msec_first = 977
msec_last = 977
src addr = 2001.0dd5:78f4
dst addr = 2001.0d::144:1
src port = 51412
dst port = 53
fwd status = 0
tcp flags = 0x00
……
proto = 17 UDP
(src)tos = 0
(in)packets = 256
(in)bytes = 26880
FLOW,192.168.144.44,10,2,e8113270d7d3,e06995d72b5e,0x86dd,0,0,IP:
0.0.0.0,0.0.0.0,17,0x00,64,51412,53,0x00,105,101,256
(кстати, вид строк зависит от ОС) — то прерываем процесс и запускаем в режиме демона:
sfcapd -n TEST,10.0.0.11,/var/sflow/10_0_0_11 -D
Демон «по умолчанию» слушает на UDP:6343, но порт можно и изменить, не забыв изменить его и на сенсоре-источнике. Также (при необходимости) нужно разрешить входящий трафик для этого источника в файерволе.
Смотрим — раз в 5 минут в соответствующей директории должен появляться новый файл с именем вида nfcapd.yyyymmddhhmm.
(директорию нужно создать заранее, процесс должен иметь право записи в эту директорию). Если файл не появился — то желательно проверить с помощю tcpdump прилетают ли пакеты по UDP:6343 от сенсора-источника.
Просматриваем полученный файл:
nfdump -r <имя файла>
Появляется что-то вроде этого:
Date first seen Duration Proto Src IP Addr:Port Dst IP Addr:Port Packets Bytes Flows
…
2013-07-29 11:01:47.108 0.000 TCP 37.146.194.51:57852 -> 192.168.144.161:25 256 17920 1
2013-07-29 11:01:56.107 0.000 UDP 2001.0d::144:1.53 -> 2001.0dd5:78f4.58687 256 39680 1
2013-07-29 11:07:24.109 0.000 TCP 88.78.101.235:51186 -> 192.168.144.157:25 256 16384 1
2013-07-29 11:11:01.101 0.000 TCP 117.218.6.72:14588 -> 192.168.144.168:3389 256 16896 1
2013-07-29 11:11:10.148 0.000 TCP 46.253.196.82:25765 -> 192.168.144.149:984 256 16384 1
2013-07-29 11:12:08.100 0.000 TCP 2001.0dd5:78f4.64805 -> 2a00:14..c03::65.80 256 19968 1
2013-07-29 11:12:16.100 0.000 ICMP 124.122.3.122:8 -> 192.168.144.129:0.0 256 16384 1
2013-07-29 11:12:26.100 0.000 UDP fe80::2..22:c7ad.57857 -> ff02::1:3.5355 256 22528 1
2013-07-29 11:13:29.099 0.000 UDP fe80::2..22:c7ad.53912 -> ff02::1:3.5355 256 22528 1
…
Summary: total flows: 30, total bytes: 536320, total packets: 7680, avg bps: 5645, avg pps: 10, avg bpp: 69
Time window: 2013-07-29 11:00:49 - 2013-07-29 11:13:29
Total flows processed: 30, Blocks skipped: 0, Bytes read: 1532
Sys: 0.001s flows/second: 15007.5 Wall: 0.000s flows/second: 33936.7
Обратите внимание на 4ю строку сверху: это не ошибка, это так nfdump «сокращает» IPv6-адрес. Выводим в csv-режиме: (показан вывод только для IPv6)
nfdump -o csv -r <имя файла>
ts,te,td,sa,da,sp,dp,pr,flg,fwd,stos,ipkt,ibyt,opkt,obyt,in,out,sas,das,smk,dmk,dtos,dir,nh,nhb,svln,
dvln,ismc,odmc,idmc,osmc,mpls1,mpls2,mpls3,mpls4,mpls5,mpls6,mpls7,mpls8,mpls9,mpls10,cl,sl,al,ra,eng,exid,tr
…
2013-07-29 11:01:56,2013-07-29
11:01:56,0.000,2001.0db8:0:a::144:1,2001.0db8:0:a:9d2b:39c2:27d5:78f4,53,58687,UDP,……,
0,0,256,39680,0,0,0,0,0,0,0,0,0,0,0.0.0.0,0.0.0.0,0,0,00:00:00:00:00:00,00:00:00:00:00:00,
00:00:00:00:00:00,00:00:00:00:00:00,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,
0-0-0, 0.000, 0.000, 0.000,0.0.0.0,0/0,1,1970-01-01 03:00:00.000
2013-07-29 11:12:08,2013-07-29
11:12:08,0.000,2001.0db8:0:a:9d2b:39c2:27d5:78f4,2a00:1450:4010:c03::65,64805,80,TCP,.A....,
0,0,256,19968,0,0,0,0,0,0,0,0,0,0,0.0.0.0,0.0.0.0,0,0,00:00:00:00:00:00,00:00:00:00:00:00,
00:00:00:00:00:00,00:00:00:00:00:00,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,
0.000, 0.000, 0.000,0.0.0.0,0/0,1,1970-01-01 03:00:00.000
2013-07-29 11:12:26,2013-07-29
11:12:26,0.000,fe80::211e:d72:9322:c7ad,ff02::1:3,57857,5355,UDP,......,
0,0,256,22528,0,0,0,0,0,0,0,0,0,0,0.0.0.0,0.0.0.0,0,0,00:00:00:00:00:00,
00:00:00:00:00:00,00:00:00:00:00:00,00:00:00:00:00:00,0-0-0,0-0-0,0-0-0,
0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0, 0.000, 0.000, 0.000,0.0.0.0,0/0,1,1970-01-01 03:00:00.000
2013-07-29 11:13:29,2013-07-29
11:13:29,0.000,fe80::211e:d72:9322:c7ad,ff02::1:3,53912,5355,UDP,......,
0,0,256,22528,0,0,0,0,0,0,0,0,0,0,0.0.0.0,0.0.0.0,0,0,00:00:00:00:00:00,
00:00:00:00:00:00,00:00:00:00:00:00,00:00:00:00:00:00,0-0-0,0-0-0,0-0-0,
0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0,0-0-0, 0.000, 0.000, 0.000,0.0.0.0,0/0,1,1970-01-01 03:00:00.000
…
Summary
flows,bytes,packets,avg_bps,avg_pps,avg_bpp
30,536320,7680,5645,10,69
Выводится много мусора, но в csv-режиме IPv6-адреса выводятся без сокращений! Кстати, ключ -q подавляет вывод заголовков и итогов, то есть получается в чистом виде csv-файл.
Опция -x для sfcapd позволяет запускать внешний обработчик при закрытии файла. Несложный скрипт (приведен в конце текста) убирает лишнее из файла и дописывает полученную «выжимку» в конец CSV-файла, после чего перемещает sflow-файл в соответствующую директорию с путём, отражающим дату формирования файла.
Экспорт в CSV-файл легко заменить экспортом в таблицу базы данных.
Файлы сохраняются для возможности проведения детализации в дальнейшем (по запросам), а csv-файл простейшей структуры ‘дата-ip источника-ip-приемника-байты’ можно использовать для экспорта в БД и формирования статистики для клиентов. Вот пример такого файла со структурой дата ip-источник ip-приемник байты`:
2013-07-29 12:58:15,2001.0db8:0:a:9d2b:39c2:27d5:78f4,2a01:6e00:10:410::2,49767
2013-07-29 12:58:15,2001.0db8:0:a:9d2b:39c2:27d5:78f4,2a01:6e00:10:410::2,49767
2013-07-29 12:58:17,2a01:6e00:10:410::2,2001.0db8:0:a:9d2b:39c2:27d5:78f4,80
2013-07-29 12:58:25,2a01:6e00:10:410::2,2001.0db8:0:a:9d2b:39c2:27d5:78f4,80
2013-07-29 12:58:27,2a01:6e00:10:410::2,2001.0db8:0:a:9d2b:39c2:27d5:78f4,80
2013-07-29 12:58:28,2a01:6e00:10:410::2,2001.0db8:0:a:9d2b:39c2:27d5:78f4,80
2013-07-29 12:58:29,2001.0db8:0:a:9d2b:39c2:27d5:78f4,2a01:6e00:10:410::2,49767
2013-07-29 12:58:37,2001:67c:2e8:22::c100:68b,2001.0db8:0:a:9d2b:39c2:27d5:78f4,443
2013-07-29 12:58:47,2001:67c:2e8:22::c100:68b,2001.0db8:0:a:9d2b:39c2:27d5:78f4,443
2013-07-29 12:58:47,2001:67c:2e8:22::c100:68b,2001.0db8:0:a:9d2b:39c2:27d5:78f4,443
2013-07-29 12:58:47,2001.0db8:0:a:9d2b:39c2:27d5:78f4,2001:67c:2e8:22::c100:68b,49794
2013-07-29 12:58:51,2001.0db8:0:a:9d2b:39c2:27d5:78f4,2a01:4f8:121:30a3::78:16,49790
2013-07-29 12:58:51,2001.0db8:0:a:9d2b:39c2:27d5:78f4,2a01:4f8:121:30a3::78:16,49792
Начиная с версии 5.6.3 в MySQL появились две очень удобные функции для экспортно-импортных операций. Это
INET6_ATON(expr) — преобразует IPv6-адрес в число
INET6_NTOA(expr) — делает обратное преобразование, числа в IPv6-адрес.
Как сказано в документации, данные хранятся в виде VARBINARY(16), то есть 128бит, поскольку при преобразовании IPv6-адреса (по аналогии с IPv6) в целое число полученый результат требует больше бит, чем отводится под самое большое целое число в MySQL.
Сенсором служил L3-коммутатор Dlink-DES3528 (другого не было). У него есть особенности: flow-пакеты отправляются только от адреса интерфейса System, причем только от IPv4-адреса. Так что в «чистом» IPv6-sflow потоке попробовать данную связку не удалось.
Подробнее: у данного устройства невозможно удалить IPv4-адрес для интерфейса System. В случае, если задать для этого интерфейса и v4, и v6-адресы, то flow-пакеты будут отправляться с адресом источника v4-System. Далее, при конфигурировании коллектора sflow (то есть получателя пакетов) можно задать только IPv4-адрес. И — если запретить работу интерфейса System по IPv4, то генерация flow-пакетов останавливается. Ложечка меда: SSH-управление устройством прекрасно работает по IPv6.
Запуск коллектора осуществляется так:
/path/to/sfcapd -n MySensor, 10.0.0.11, /var/sflow/sensor01 -x ‘/convert.py %d %f’ -D
При завершении временнОго интервала (по умолчанию — 300сек) будет сформирован результирующий flow-файл, а его имя и директория будут переданы как параметры скрипту.
Сам скрипт достаточно прост: открывает свежий flow-файл, с помощью nfdump преобразует его в CSV-формат, результат работы nfdump добавляется к файлу sflow.csv, затем исходный flow-файл перемещается в директорию ./yyyy/mm/dd/
#!/usr/bin/python
# v6net.ru, 20130730
# base directories: take from sys.argv, after export delete csv files
# and move sflow files to yyyy/mm/dd directory
# ----------------
import os
import sys
import subprocess
fdir = sys.argv[1] # basedir without trailing '/'
fname = sys.argv[2] # filename
fullpath = sys.argv[1]+"/"+sys.argv[2]
os.chdir(fdir)
fn=fname.split(".")
# convert nfcapd.* ==> csv
cmdline = "/usr/local/bin/nfdump -o csv -q -r "+fullpath
proc = subprocess.Popen(cmdline, shell=True, stdout=subprocess.PIPE)
out = proc.stdout.readlines()
f2=open("sflow.csv","a") # APPEND !!!!!!!!!!!
for line in out:
____ls = line.split(",")
____f2.write(ls[0]+","+ls[3]+","+ls[4]+","+ls[5]+"\n")
# move src (sflow) file to chronological DIRs %basedir% / yyyy / mm / dd / %file%
# structure of filename: nfcapd.201307221930 ( nfcapd.yyyymmddhhmm )
fpath = fdir+"/"+fn[1][0:4]+"/"+fn[1][4:6]+"/"+fn[1][6:8]
if not os.path.exists(fpath):
____os.makedirs(fpath)
os.rename(fname,fpath+"/"+fname)
# The End