Я думаю, что все согласятся с тем, что мониторинг сетевой активности является одной из приоритетных задач в процессе эксплуатации корпоративных сетей.
Все легко и просто, пока вы администрируете сеть небольшого офиса в городе N. Но что если ваша фирма пошла в гору и стала расширяться? Открытие нового филиала скорей всего повлечет начало отношений с провайдерами, организацию каналов связи и более сложные (назовем это так) манипуляции с сетью.
Нет желания описывать такие вещи, как маршрутизацию, ее необходимость и проблемы с ней связанные. Допустим вы непосредственно маршрутизацию победили. Но это не значит, что все у вас будет хорошо.

Организация канала в соседний город стоит немало. Чем «шире» канал, тем больше денег надо платить. И рано или поздно придет к вам начальник и спросит: Почему мы платим за канал огромные деньги, а нам его все равно не хватает? Ведь мы уже расширяли его дважды!.. И вообще мы тебе платим такие о#censored#е деньги!!!

Итак, прелюдий достаточно.

Задача: необходимо организовать детальный мониторинг сетевого трафика.

Имеем:

    Маршрутизируемую сеть, построенную на оборудовании Cisco.
    Каналы связи организуют различные провайдеры.

Предварительный обзор:

Коммутаторы и маршрутизаторы во внутренних сетях как правило способны переварить практически любой трафик. Нагрузка на сервера тема отдельная и скорей всего нас мало касается. Итак внутренние потоки информации нас не волнуют. На границе у нас установлены маршрутизаторы, с которых собственно и будем собирать статистику, причем со внешних интерфейсов.
Попыток создания систем мониторинга было много. Однако самыми удачными были разработки протоколов SNMP и NetFlow. Необходимо понимать, что это абсолютные разные системы. SNMP — это протокол для работы с устройствами. То есть это сбор, обработка данных и управление физическими интерфейсами. Вы сможете получить информацию о нагрузке, в некоторых случаях температуре и все в этом роде. Это очень нужный и полезный протокол, но увы он не даст нам полную картину. Мы сможем увидеть только общую картину и констатировать, что действительно каналы у нас загружены. Как показывает практика, даже один пользователь способен полностью утилизировать 100 Мбит канал.
NetFlow — Разработка Cisco systems, которая пожалуй является лучшей реализацией протокола для мониторинга сетевого трафика на третьем уровне (уровень IP). Не смотря на то, что протокол проприетарный, существует его множество не-Cisco реализаций. Это значит, что вы сможете настроить его даже на обычном серверном оборудовании.

Итак суть работы с Netflow заключается:

    Получаем данные с сенсоров и передаем их на коллектор.
    Обрабатываем и передаем на анализатор.

Настройка сенсоров.

У нас в качестве сенсора будет Cisco router

conf t
ip flow-export source GigabitEthernet0/0
ip flow-export version 5
ip flow-export destination xxx.xxx.xxx.xxx 9999
interface GigabitEthernet0/1
 ip flow ingress
 ip flow egress


Пояснения:

conf t — переход в режим конфигурации
ip flow-export source GigabitEthernet0/0 — означает от какого интерфейса будем передавать данные. Это у нас будет внутренний интерфейс, соответственно с него и будет передаваться. Если вы ошибетесь, то последствия могут быть. Например если на коллекторе установлен firewall, разрешающий трафик только со внутренней сети, а вы передаете с внешнего адреса маршрутизатора, то пакеты просто не пройдут.
ip flow-export version 5 — мы указали пятую версию протокола Netflow, так как наш коллектор работает с этой версией. Если версии сенсора и коллектора не будут совпадать, коллекторы будут выдавать весьма странные ошибки, которые довольно тяжело диагностировать.
ip flow-export destination xxx.xxx.xxx.xxx 9999 — здесь мы указываем IP адрес и UDP порт коллектора. То есть на этот адрес и порт будет отправляться информация о трафике.
interface GigabitEthernet0/1 — переходим в режим конфигурирования интерфейса GigabitEthernet0/1. (зачем я это поясняю?)
ip flow ingress — включаем мониторинг входящего на интерфейс трафика
ip flow egress — включаем мониторинг исходящего трафика.

Настройка сенсора закончена.
Теперь сенсор будет усердно отправлять данные на коллектор. Если у нас больше одного интерфейса на сенсоре — прописываем 6 и 7 строки на каждом интерфейсе. Если у нас больше одного сенсора стоит озаботиться вопросом — хотим ли мы передавать все в один коллектор, т.к. это может «размазать» картину. Лично я предпочитаю разные сенсоры направлять на разные коллекторы. Кроме того я бы не рекомендовал вам включать мониторинг одновременно на внутреннем и внешнем интерфейсах сенсора.

Настройка коллекторов.

Коллектор из себя представляет сервер, на который стекается информация с сенсоров.

Установка и настройка FreeBSD.
FreeBSD — наш выбор серверной ОС (а разве бывают другие?). Качаем, ставим и настраиваем, читая руководство (тысячи их). Устанавливаем коллекцию портов.
Я скачал boot-only образ для amd64 и установил систему пользуясь исходными данными полученными с интернет. Потом установил мой любимый midnight commander, с его помощью сконфигурировал новое ядро, пересобрал его и установил. Однако это было не совсем последовательно (что поделать — привычка).

Лучший путь:

    Установить систему
    Сконфигурировать ядро с помощью ee или vi. Пересобрать/установить.
    Установить (если не установлена) и/или обновить (если установлена) коллекцию портов.
    Обновить установленные порты. (обычно установщик системы что-нибудь да постановит еще на старте).
    А вот теперь мы можем начинать ставить необходимое нам ПО.


На подготовку сервера у меня ушел весь рабочий день. Основное время у меня потратилось на то, что установщик долго тянул данные для установки с интернета (в тот день интернет был плохим). Еще много времени потратилось на то, что я неправильно написал команды на сборку ядра и понял ошибку только после того, как сборка завершилась и пришлось ее перезапускать. Неподготовленным гражданам это может вылиться в долгие вечера возле консоли. Но не все так плохо на самом деле.
Стоит предупредить, что коллектор как правило очень требователен дисковому пространству. В моей корп сети с одного сенсора приходит около 400 MB необработанной информации в сутки. То есть если мы хотим хранить информацию довольно крупной компании (более 1500 хостов) хотя бы за месяц — нам необходимо около 15 GB свободного места только под исходные данные на каждый сенсор. Также следует учитывать, что данные находятся в «сжатом» состоянии. В зависимости от ваших хотелок конечные данные могут занимать в десятки раз больше дискового пространства. Естественно мы постараемся быть экономичными, но об этом далее…

Установка flow-tools.
flow-tools это очень мощный пакет инструментов для работы с NetFlow.

# whereis flow-tools
flow-tools: /usr/ports/net-mgmt/flow-tools
# cd /usr/ports/net-mgmt/flow-tools
# make install clean


Если погуглить, то станет видно, что многие не рекомендуют «делать clean», но лично я по своему опыту не сталкивался с проблемами, описанными в этих статьях.

Настройка flow-capture.
flow-capture это демон, который принимает данные от сенсоров на указанном UDP порту. Мы направляем данные с сенсора на 9999 UDP порт. Итак настраиваем:

1) Настраиваем rc.conf:
# cat >> /etc/rc.conf

flow_capture_enable="YES"
flow_capture_localip="xxx.xxx.xxx.xxx"
flow_capture_port="9999"
flow_capture_remoteip="0.0.0.0"
flow_capture_datadir="/var/db/flows/"
flow_capture_flags="-V5 -n287 -N2"
ctrl+C
^C

2) Настраиваем логирование:
# cat >> /etc/syslog.conf
!flow-capture
*.*                                             /var/log/flow-capture.log
ctrl+C
^C
# touch /var/log/flow-capture.log

3) Настраиваем ротацию логов иначе они съедят весь диск за несколько дней:
# cat >> /etc/newsyslog.conf
/var/log/flow-capture.log               644  5     100  @0101T JC
ctrl+C
^C

4) запускаем демон:
# /usr/local/etc/rc.d/flow_capture start

5) Проверяем:
# ps -ax | grep flow-capture
Если все хорошо, то получаем примерно такую картину:
33042 ??  Ss      0:14.25 /usr/local/bin/flow-capture -V5 -n287 -N2 -w /var/db/flows -p /var/run/flow-capture/flow-capture.pid xxx.xxx.xxx.xxx/0.0.0.0/9999

Пояснения:

flow_capture_enable=«YES» — запуск демона при загрузке
flow_capture_localip=«xxx.xxx.xxx.xxx» — принимать данные на xxx.xxx.xxx.xxx IP адрес.
flow_capture_port=«9999» — принимать данные на 9999 UDP порт.
flow_capture_remoteip=«0.0.0.0» — принимать данные с любого IP сенсора.
flow_capture_datadir="/var/db/flows/" — складировать данные в указанную папку
flow_capture_flags="-V5 -n287 -N2" — версия протокола 5; ротировать файл 287 раз в сутки (каждые пять минут) и складывать по форме «YYYY/YYYY-MM/flow-file»

Все, коллектор настроен.

Конструирование анализатора.

Да, именно конструирование. Как правило «коробочное» решение стоит денег и я спешу заверить — не малых. В конторе, которой работаю я за такое решение было выложено около 20 000$ (и что самое смешное нормально так и не было запущено в эксплуатацию). Кроме того часто бывает так, что платные/бесплатные решения не всегда удовлетворяют нашим потребностям. Потому структура анализа трафика действительно напоминает конструктор. На каждом этапе мы можем изменять/применять те или иные параметры. Ну и если голова достаточно светлая — можем сами упаковать в красивую web-упаковку.

Первичный анализ.
Естественно у нас будет желание сразу посмотреть данные, полученные с сенсоров на коллектор. Пакет программ flow-tools, которые мы установили имеют некоторые вполне неплохие инструменты для анализа трафика:
flow-cat — программа, которая связывает анализаторы с коллектором. Как правило программа сама по себе не используется, а только в связках с программами ниже.
flow-print — программа преобразования netflow файлов в ASCII формате. Также программа форматирует вывод в нужный вам вид (читабельный для человека).
flow-stat — программа формирования статистики.
flow-filter — программа фильтрации данных. Как правило нам не нужны все данные. Интерес представляют отдельные граждане. Для использования нам необходимо создать в папке запуска команды файл 'flow.acl', в котором пишем access-lists. Примеры ниже.

Синтаксис:
# flow-cat 'имя файла'
# flow-cat 'имя файла' | flow-print -параметр1 -параметр2
# flow-cat 'имя файла' | flow-stat -параметр1 -параметр2
# flow-cat 'имя файла' | flow-filter -параметр1 -параметр2 | flow-print


В таком виде программы просто выдадут результаты на экран. Если хотим записать в файл, пользуемся "> 'имя файла' (для перезаписи) или '>> имя файла' (для добавления). (зачем я то объясняю??)

Синтаксис:
# flow-cat 'имя файла' > 'имя файла1'
# flow-cat 'имя файла' | flow-print -параметр1 -параметр2 > 'имя файла1'
# flow-cat 'имя файла' | flow-stat -параметр1 -параметр2 > 'имя файла1'
# flow-cat 'имя файла' | flow-filter -параметр1 -параметр2| flow-print > 'имя файла1'


Для полноты картины раскрасим это примерами. Мы будем брать данные из папки /var/db/flows/2013/2013-01/ и класть в папку /usr/home/netflow/

1) Запишем в файл 'temp' кто и что качал 23.01.2013:
# flow-cat /var/db/flows/2013/2013-01/ft-v05.2013-01-23.*  flow-print > temp
2) Запишем в файл 'report' отчет за 23.01.2013 о том, кто сколько скачал:
# flow-cat /var/db/flows/2013/2013-01/ft-v05.2013-01-23.* | flow-stat -f10 -p -S3 > report
3) Отследим нехорошего (а может он не такой и плохой) дядьку с полной детализацией за сутки:
# echo ip access-list standard very_bad_boy permit host xxx.xxx.xxx.xxx > flow.acl
# flow-cat /var/db/flows/2013/2013-01/ft-v05.2013-01-23.* | flow-filter -S very_bad_boy | flow-stat -f10 -p -S3 > report
# flow-cat /var/db/flows/2013/2013-01/ft-v05.2013-01-23.* | flow-filter -S very_bad_boy | flow-print -f5 >> report


… И вот мы радостные несемся к начальнику и говорим ему, что зря он кричал на нас… и что он сам является причиной плохой работы конторы… и что просмотр порно-сайтов в рабочее время мешает нашей работе и работе сотрудников… Ну и предлагаем заодно повысить нам зарплату, за что получаем увольнение и… устраиваемся в уютный офис администрировать 10 компьютеров.


Источники:
1) Официальный сайт FreeBSD
2) Поиск Google
3) man flowtools; man flow-capture; man flow-cat; man flow-print и т. д.