анализ трафика NetFlow - очевидное и невероятное
Сбор статистики с помощью netflow - наиболее гибкий и IMHO приятный (если такое вообще бывает) способ получения информации о том что? где? ни_фига_себе_а_это_откуда?
Основные плюсы netflow - территориально распределенная структура сенсоров/коллекторов, неплохое описание этого проприетарного протокола, приличное количество продуктов - от скриптов, написанных на коленке, находящихся в базах FreshMeat, SourceForge и т.п., до анализаторов промышленного уровня типа ManageEngine NetFlow Analyser со стоимостью более 700 у.е. за лицензию на 10 интерфейсов, HP OpenView Performance Insight Report Pack for NetFlow Interfaces. Есть возможность подобрать себе "одежку" по размеру.
Минусы netflow, как и везде - необходимость наличия определенного уровня знаний, трудоемкость настройки программных продуктов, ресурсоемкость. Для примера тот же самый NetFlow Analyser представляет собой набор java-программ, которые используют в работе сервер приложений JBoss (под Tomcat тоже работать должно) и поставляемую в комплекте СУБД MySQL. Весь этот зоопарк, необходимо отметить, весьма шустро работает на двухпроцессорном 2.8Ghz серваке. Некоторые сенсоры, работающие в userspace, склонны к чрезмерному потреблению ресурсов и потере пакетов при высоких нагрузках - особенно использующие libpcap.
Не могу сказать минус это или плюс, но это неотъемлемый атрибут netflow - агрегация. Конечно агрегация экономит место, но иногда это мешает проводить детальный анализ трафика.
Как у каждого решения, у технологии netflow помимо минусов и плюсов есть еще альтернативы. Из прямых альтернатив можно обратить свой взор на sFlow. Собирать трафик можно используя RMON, SNMP, IPFIX (детище IETF). Плюс, как вариант, если все в одной стойке, то можно сделать SPAN-порт и подключить туда сенсор. Для интересующихся рекомендую зайти на сайт SCAMPI - SCAleable Monitoring Platform for the Internet - народ в Европе заморачивается созданием крупной системы мониторинга.
netflow - cемейство протоколов
Для сбора трафика в большинстве случаев используется 5-я версия протокола. Вообще, если разобраться, то кроме 5-й версии обычному крестьянскому парню, только что оторвавшемуся от сохи, ничего и не нужно. Именно поэтому множество коллекторов и сенсоров работают с 5 версией. Если зайти на сайт Cisco, то можно прочитать, что версии 2, 3, 4 и 6 не были выпущены или не поддерживаются FlowCollector'ом.
Собственно версии Netflow:
1. Ура! Товарищи! Oно родилось. Роды были сложными - дитя вышло ублюдочным. Бобик сдох. Мурзик сбег. (c) не помню кто.
5. Добавлены поля источника и получателя AS необходимые для мониторинга BGP-маршрутизаторов и flow sequence numbers (32 битные значения, меняющееся настолько часто, что нехорошему человеку трудно вставить свои netflow-данные в экспортируемый поток).
7. Используется на коммутаторах и несовместима с маршрутизаторами Cisco.
8. Добавлены router-based aggregation schemes.
9. Очень гибкая и расширяемая версия (мне не нужна).
10. Эта версия называется IPFIX :-)
Как видим, 5-й версии вполне достаточно для повседневного использования в обстановке, не предъявляющей особых требований к сбору трафика. Анализаторы netflow потоков имеют возможность присваивать трафик определенным интерфейсам. Как это происходит? Желательно вспомнить структуру netflow пакета 5ой версии :-) шутка. Просто посмотрите на нее ниже:
0-3, srcaddr, Source IP address
4-7, dstaddr, Destination IP address
8-11, nexthop, IP address of next hop router
12-13, input, SNMP index of input interface
14-15, output, SNMP index of output interface
16-19, dPkts, Packets in the flow
20-23, dOctets, Total number of Layer 3 bytes in the packets of the flow
24-27, First, SysUptime at start of flow
28-31, Last, SysUptime at the time the last packet of the flow was received
32-33, srcport, TCP/UDP source port number or equivalent
34-35, dstport, TCP/UDP destination port number or equivalent
36, pad1, Unused (zero) bytes
37, tcp_flags, Cumulative OR of TCP flags
38, prot, IP protocol type - например TCP=6, UDP=17
39, tos, IP type of service (ToS)
40-41, src_as, Autonomous system number of the source, either origin or peer
42-43, dst_as, Autonomous system number of the destination, either origin or peer
44, src_mask, Source address prefix mask bits
45, dst_mask, Destination address prefix mask bits
46-47, pad2, Unused (zero) bytes
Не пугайтесь, обратите внимание на поле 12-13 - SNMP index of input interface. Поле с номером интерфейса, который получил этот поток. Многие сенсоры не умеют работать с этим полем. А как же быть, если интерфейс в режиме приема любых пакетов??? Получил откуда? Передал куда? Бардак, но некоторые пытаются бороться. Netflow Analyser при получении netflow-потока без этого поля вообще скажет, что информация о трафике получена, но интерфейсов для мониторинга нет. IMHO interface SNMP-index support - очень полезная вещь.
netflow - cобери и выиграй
Собирают с интерфейсов трафик у нас многочисленные сенсоры. Ну на маршрутизаторах Cisco они уже внутри, а вот для отдельно
стоящих/лежащих/висящих (в стойке, конечно же) машин их нужно ставить отдельно. Список некоторых сенсоров, позволяющих экспортировать трафик в netflow:
fprobe
Сенсор, обладающие всеми особенностями программы, основанной на libpcap. Может быть скомпилирован под любой POSIX-совместимой ОС (Linux/BSD/UNIX- like). Умеет экспортировать потоки Netflow 1/5/7 версии сразу нескольким коллекторам. Можно настроить SNMP-индексы входящих/исходящих интерфейсов, используя фильтр.
fprobe -x1:2 -ieth1 -f"ip&&dst net 10.2" localhost:2055
На примере команда запуска сенсора. Пример показывает, что трафик принимается на интерфейсе с индексом 1 и отдается на интерфейс с индексом 2. Соответственно, трафик прослушивается на интерфейсе eth1 и выбирается только IP-трафик с сетью назначения 10.2. Поток экспортируется на localhost:2055. Вот развлечение, да?
fprobe-ulog
Сенсор, работающий с ULOG-целью Netfilter. Может быть скомпилирован, ясное дело, только под Linux. Умеет экспортировать потоки Netflow 1/5/7 версии сразу нескольким коллекторам. Потеря пакетов исключена, загрузка системы минимальна. Благодаря тому, что ULOG передает, с какого и на какой интерфейс идет трафик, есть поддержка автоматического назначения SNMP индексов входящих/исходящих интерфейсов. Имеется возможность переназначения индексов. Очень приятная вещь.
nProbe
Сенсор от создателей ntop. Работает, как заверяют, под любой *NIX/Win OC. Экспортирует netflow v5/v9/IPFIX. Создатели хотят получить маленькое пожертвование, что-то около 100 евро, перед тем, как вы сможете его скачать.
ng_netflow
Сенсор для FreeBSD, использующий систему сетевых графов. Так как все реализовано на уровне ядра, то с одной стороны все очень быстро, а с другой - любые изменения лучше производить только в тестовой конфигурации. Ошибок не прощает, и это правильно. Субъективное мнение - хорошо держит нагрузки. Меня поначалу смущала версия 0.2.5, но после того, как модуль прошел все тесты и отработал неделю в окружении, максимально приближенном к боевому, я взял на себя ответственность установить его на продакшн-сервер. Не жалею, сделал правильно. Как заявляют создатели, ng_netflow заполняет все поля в netflow-пакете, которые можно заполнить. С SNMP-индексами интерфейсов работает на ура. Возможна переиндексация. Экспортирует netflow версии v5.
Softflowd
Сенсор использует libpcap для получения информации. Экспортирует netflow версии 1/5/9. Разрабатывался для Linux и OpenBSD. Есть
экспериментальная поддержка солярки. На FreeBSD тоже без проблем должен заработать. Поддержки SNMP indexes нет.
pfflowd
Сенсор для OpenBSD, использующий для сбора потоков pfsync. Умеет экспортировать Netflow версий v1/v5. Из плюсов - скорость работы. Из недостатков - не держит потоки более 4G, не считаются заблокированные пакеты и пакеты, сгенерированные ОС типа TCP RSTs, ICMP unreachables и TCP handshakes. О SNMP-индексах можно забыть. Для общего анализа самое оно - на выходе как раз усредненный результат.
ipcad
Сенсор, если можно так выразиться, собирается под большинством POSIX-платформ (Linux/BSD/Solaris x86/UNIX-like OC). Для сбора статистики могут использоваться raw BPF-девайсы, libpcap, divert, tee или Linux netwilter/iptables ULOG/IPQ. Обладает многочисленными возможностями, которые позволяют произвести очень гибкую настройку. Поддерживает экспорт Netflow v1/v5. Недостаток один, но очень для меня серьезный - в экспортируемом потоке проставляет только input interface SNMP index.
NDSAD
Сенсор от наших доблестных комрадов из NetUP. Работает под 32-битными MS Windows (NT/2000/XP), любыми BSD-платформами
(FreeBSD/NetBSD/OpenBSD/Apple Mac OS X), всеми POSIX-платформами. Для сбора трафика использует libpcap со всеми вытекающими. Поддерживает экспорт Netflow v5. Судя по исходникам, должен проставлять input interface SNMP index, про output interface SNMP index можно забыть.
netflow - анализируй это
Все коллекторы netflow-потоков можно разделить на две основные группы - анализаторы сетевого трафика и системы учета. Анализаторы сетевого трафика могут включать модули учета. Системы учета могут включать модули анализа. На мой субъективный взгляд достаточно ясно видно, чему именно разработчики уделяли особое внимание.
Я не пытаюсь рассмотреть здесь все системы, так как это довольно неблагодарное занятие. Ниже представлены только те продукты, которые вызвали у меня положительные эмоции. Объясню почему. Дело в том, что написать за пару часов UDP-сервер, который будет складывать netflow-потоки в SQL, а затем скармливать оттуда данные для построения графиков с помощью RRDtool - занятие для меня скорее нудное, чем трудное. Потратить те же пару часов (а может быть и больше, так как имеем дело с чужим кодом) на разбор аналогичных изделий желания тем более не возникает. Так что я рассматривал только то, что выглядит приличнее, чем набор утилит. Если вы хотите найти более полную информацию о коллекторах netflow, то я посоветовал бы вам использовать поиск в том же Google.
Stager
Разработка "The Norwegian research network". Звучит уже интересно. Позволяет собирать netflow-, SNMP-статистику, следить за серверами с помощью ICMP (ping). Подерживает генерацию следующих NetFlow-отчетов:
- распределение трафика по интерфейсам;
- распределение трафика по IP-протоколам;
- распределение трафика по IP типам сервиса (ToS);
- распределение трафика по IP-адресам источника;
- распределение трафика по IP-адресам получателя;
- матрица IP-адрес источника/получателя;
- AS – источники;
- AS – получатели;
- матрица AS источника/получателя;
- multicast-группы;
- multicast-источники;
- multicast AS источники;
- общая статистика multicast-трафика;
- распределение портов источников на транспортном уровне;
- распределение портов получателей на транспортном уровне;
- сводный отчет.
По сути Stager - это ПО, использующее для сбора трафика flow-tools и perl. Данные хранятся в PostgreSQL, а веб интерфейс использует PHP и Apache.
Вообщем-то, добавить здесь больше нечего.
Ntop
Для большинства читателей этот продукт в представлениях не нуждается, однако... В двух словах - это очень мощный анализатор со встроенным веб-сервером. Список его возможностей вполне может превысить размер этой статьи. Ntop содержит NetFlow-плагин, который позволяет управлять netflow-данными. Каждая запись netflow-коллектора выглядит в Ntop как отдельный сетевой интерфейс. Очень удобно.
ManageEngine NetFlow Analyser
Платный продукт. Я его решил упомянуть из-за наикрасивейших отчетов (в самом прямом смысле). На большинство людей, далеких от сетевых реалий, распечатанный отчет NetFlow Analyser действует как гипнотический амулет. Им можно вручить этот отчет и все - о человеке можно забыть. Большие минусы – это, конечно же, цена и ресурсоемкость. Еще один минус - очень сильная агрегация. Если вы забыли создать фильтр на определенный вид трафика, то вряд ли вам удастся получить необходимые данные задним числом.
Однако, если от вас хотят красивую картинку, с учетом того, что над этим продуктом трудилась не один день группа программистов - вряд ли отношение стоимость/качество вашей разработки будет меньше предлагаемого решения. IMHO в любом случае проще потратить несколько сотен у.е. и купить, чем тратить на разработку аналога существующего продукта несколько тысяч у.е. и еще не факт, что получится лучше, хотя кто знает...
NeTAMS (Network Traffic Accounting and Monitoring Software)
Приятная система учета. Цитата с сайта: многофункциональная программа по учету и управлению IP-трафиком для маршрутизаторов Cisco или компьютеров под управлением Unix (Linux/FreeBSD/Solaris). Поддерживаются различные методы сбора статистики (tee/divert/ip_queue/ulog/libpcap/netflow v5 и v9/netgraph), хранения в базе данных (BerkleyDB/MySQL/PostgresSQL/Oracle/Radius), агрегирования, отображения, оповещения и пр. Возможно проводить блокировку на базе квот, авторизации, исчерпании баланса (биллинг); управлять полосой пропускания, контролировать подмену MAC-адреса, делать связь с RADIUS, создавать гибкие политики учета и фильтрации.
Как тут с управлением трафиком не знаю, а вот с учетом все ОК, за исключением двух неприятных, но для меня не смертельных моментов - учитывается только IP и производные протоколы и в статистике при импорте netflow не работает разделение на входящий/исходящий трафик, поэтому необходимо писать правила для разделения на in/out.
Вот и все, больше ничего интересного обнаружено не было. Разве что Traffic Accounting Project - изначально разрабатывался на ASM под GPL, сейчас переписан на C с лицензией "for personal use only". Мне интересно, ну нафига оно такое нужно?
Алексей Аксенов aka ezh.
обсуждение статьи
Основные плюсы netflow - территориально распределенная структура сенсоров/коллекторов, неплохое описание этого проприетарного протокола, приличное количество продуктов - от скриптов, написанных на коленке, находящихся в базах FreshMeat, SourceForge и т.п., до анализаторов промышленного уровня типа ManageEngine NetFlow Analyser со стоимостью более 700 у.е. за лицензию на 10 интерфейсов, HP OpenView Performance Insight Report Pack for NetFlow Interfaces. Есть возможность подобрать себе "одежку" по размеру.
Минусы netflow, как и везде - необходимость наличия определенного уровня знаний, трудоемкость настройки программных продуктов, ресурсоемкость. Для примера тот же самый NetFlow Analyser представляет собой набор java-программ, которые используют в работе сервер приложений JBoss (под Tomcat тоже работать должно) и поставляемую в комплекте СУБД MySQL. Весь этот зоопарк, необходимо отметить, весьма шустро работает на двухпроцессорном 2.8Ghz серваке. Некоторые сенсоры, работающие в userspace, склонны к чрезмерному потреблению ресурсов и потере пакетов при высоких нагрузках - особенно использующие libpcap.
Не могу сказать минус это или плюс, но это неотъемлемый атрибут netflow - агрегация. Конечно агрегация экономит место, но иногда это мешает проводить детальный анализ трафика.
Как у каждого решения, у технологии netflow помимо минусов и плюсов есть еще альтернативы. Из прямых альтернатив можно обратить свой взор на sFlow. Собирать трафик можно используя RMON, SNMP, IPFIX (детище IETF). Плюс, как вариант, если все в одной стойке, то можно сделать SPAN-порт и подключить туда сенсор. Для интересующихся рекомендую зайти на сайт SCAMPI - SCAleable Monitoring Platform for the Internet - народ в Европе заморачивается созданием крупной системы мониторинга.
netflow - cемейство протоколов
Для сбора трафика в большинстве случаев используется 5-я версия протокола. Вообще, если разобраться, то кроме 5-й версии обычному крестьянскому парню, только что оторвавшемуся от сохи, ничего и не нужно. Именно поэтому множество коллекторов и сенсоров работают с 5 версией. Если зайти на сайт Cisco, то можно прочитать, что версии 2, 3, 4 и 6 не были выпущены или не поддерживаются FlowCollector'ом.
Собственно версии Netflow:
1. Ура! Товарищи! Oно родилось. Роды были сложными - дитя вышло ублюдочным. Бобик сдох. Мурзик сбег. (c) не помню кто.
5. Добавлены поля источника и получателя AS необходимые для мониторинга BGP-маршрутизаторов и flow sequence numbers (32 битные значения, меняющееся настолько часто, что нехорошему человеку трудно вставить свои netflow-данные в экспортируемый поток).
7. Используется на коммутаторах и несовместима с маршрутизаторами Cisco.
8. Добавлены router-based aggregation schemes.
9. Очень гибкая и расширяемая версия (мне не нужна).
10. Эта версия называется IPFIX :-)
Как видим, 5-й версии вполне достаточно для повседневного использования в обстановке, не предъявляющей особых требований к сбору трафика. Анализаторы netflow потоков имеют возможность присваивать трафик определенным интерфейсам. Как это происходит? Желательно вспомнить структуру netflow пакета 5ой версии :-) шутка. Просто посмотрите на нее ниже:
0-3, srcaddr, Source IP address
4-7, dstaddr, Destination IP address
8-11, nexthop, IP address of next hop router
12-13, input, SNMP index of input interface
14-15, output, SNMP index of output interface
16-19, dPkts, Packets in the flow
20-23, dOctets, Total number of Layer 3 bytes in the packets of the flow
24-27, First, SysUptime at start of flow
28-31, Last, SysUptime at the time the last packet of the flow was received
32-33, srcport, TCP/UDP source port number or equivalent
34-35, dstport, TCP/UDP destination port number or equivalent
36, pad1, Unused (zero) bytes
37, tcp_flags, Cumulative OR of TCP flags
38, prot, IP protocol type - например TCP=6, UDP=17
39, tos, IP type of service (ToS)
40-41, src_as, Autonomous system number of the source, either origin or peer
42-43, dst_as, Autonomous system number of the destination, either origin or peer
44, src_mask, Source address prefix mask bits
45, dst_mask, Destination address prefix mask bits
46-47, pad2, Unused (zero) bytes
Не пугайтесь, обратите внимание на поле 12-13 - SNMP index of input interface. Поле с номером интерфейса, который получил этот поток. Многие сенсоры не умеют работать с этим полем. А как же быть, если интерфейс в режиме приема любых пакетов??? Получил откуда? Передал куда? Бардак, но некоторые пытаются бороться. Netflow Analyser при получении netflow-потока без этого поля вообще скажет, что информация о трафике получена, но интерфейсов для мониторинга нет. IMHO interface SNMP-index support - очень полезная вещь.
netflow - cобери и выиграй
Собирают с интерфейсов трафик у нас многочисленные сенсоры. Ну на маршрутизаторах Cisco они уже внутри, а вот для отдельно
стоящих/лежащих/висящих (в стойке, конечно же) машин их нужно ставить отдельно. Список некоторых сенсоров, позволяющих экспортировать трафик в netflow:
fprobe
Сенсор, обладающие всеми особенностями программы, основанной на libpcap. Может быть скомпилирован под любой POSIX-совместимой ОС (Linux/BSD/UNIX- like). Умеет экспортировать потоки Netflow 1/5/7 версии сразу нескольким коллекторам. Можно настроить SNMP-индексы входящих/исходящих интерфейсов, используя фильтр.
fprobe -x1:2 -ieth1 -f"ip&&dst net 10.2" localhost:2055
На примере команда запуска сенсора. Пример показывает, что трафик принимается на интерфейсе с индексом 1 и отдается на интерфейс с индексом 2. Соответственно, трафик прослушивается на интерфейсе eth1 и выбирается только IP-трафик с сетью назначения 10.2. Поток экспортируется на localhost:2055. Вот развлечение, да?
fprobe-ulog
Сенсор, работающий с ULOG-целью Netfilter. Может быть скомпилирован, ясное дело, только под Linux. Умеет экспортировать потоки Netflow 1/5/7 версии сразу нескольким коллекторам. Потеря пакетов исключена, загрузка системы минимальна. Благодаря тому, что ULOG передает, с какого и на какой интерфейс идет трафик, есть поддержка автоматического назначения SNMP индексов входящих/исходящих интерфейсов. Имеется возможность переназначения индексов. Очень приятная вещь.
nProbe
Сенсор от создателей ntop. Работает, как заверяют, под любой *NIX/Win OC. Экспортирует netflow v5/v9/IPFIX. Создатели хотят получить маленькое пожертвование, что-то около 100 евро, перед тем, как вы сможете его скачать.
ng_netflow
Сенсор для FreeBSD, использующий систему сетевых графов. Так как все реализовано на уровне ядра, то с одной стороны все очень быстро, а с другой - любые изменения лучше производить только в тестовой конфигурации. Ошибок не прощает, и это правильно. Субъективное мнение - хорошо держит нагрузки. Меня поначалу смущала версия 0.2.5, но после того, как модуль прошел все тесты и отработал неделю в окружении, максимально приближенном к боевому, я взял на себя ответственность установить его на продакшн-сервер. Не жалею, сделал правильно. Как заявляют создатели, ng_netflow заполняет все поля в netflow-пакете, которые можно заполнить. С SNMP-индексами интерфейсов работает на ура. Возможна переиндексация. Экспортирует netflow версии v5.
Softflowd
Сенсор использует libpcap для получения информации. Экспортирует netflow версии 1/5/9. Разрабатывался для Linux и OpenBSD. Есть
экспериментальная поддержка солярки. На FreeBSD тоже без проблем должен заработать. Поддержки SNMP indexes нет.
pfflowd
Сенсор для OpenBSD, использующий для сбора потоков pfsync. Умеет экспортировать Netflow версий v1/v5. Из плюсов - скорость работы. Из недостатков - не держит потоки более 4G, не считаются заблокированные пакеты и пакеты, сгенерированные ОС типа TCP RSTs, ICMP unreachables и TCP handshakes. О SNMP-индексах можно забыть. Для общего анализа самое оно - на выходе как раз усредненный результат.
ipcad
Сенсор, если можно так выразиться, собирается под большинством POSIX-платформ (Linux/BSD/Solaris x86/UNIX-like OC). Для сбора статистики могут использоваться raw BPF-девайсы, libpcap, divert, tee или Linux netwilter/iptables ULOG/IPQ. Обладает многочисленными возможностями, которые позволяют произвести очень гибкую настройку. Поддерживает экспорт Netflow v1/v5. Недостаток один, но очень для меня серьезный - в экспортируемом потоке проставляет только input interface SNMP index.
NDSAD
Сенсор от наших доблестных комрадов из NetUP. Работает под 32-битными MS Windows (NT/2000/XP), любыми BSD-платформами
(FreeBSD/NetBSD/OpenBSD/Apple Mac OS X), всеми POSIX-платформами. Для сбора трафика использует libpcap со всеми вытекающими. Поддерживает экспорт Netflow v5. Судя по исходникам, должен проставлять input interface SNMP index, про output interface SNMP index можно забыть.
netflow - анализируй это
Все коллекторы netflow-потоков можно разделить на две основные группы - анализаторы сетевого трафика и системы учета. Анализаторы сетевого трафика могут включать модули учета. Системы учета могут включать модули анализа. На мой субъективный взгляд достаточно ясно видно, чему именно разработчики уделяли особое внимание.
Я не пытаюсь рассмотреть здесь все системы, так как это довольно неблагодарное занятие. Ниже представлены только те продукты, которые вызвали у меня положительные эмоции. Объясню почему. Дело в том, что написать за пару часов UDP-сервер, который будет складывать netflow-потоки в SQL, а затем скармливать оттуда данные для построения графиков с помощью RRDtool - занятие для меня скорее нудное, чем трудное. Потратить те же пару часов (а может быть и больше, так как имеем дело с чужим кодом) на разбор аналогичных изделий желания тем более не возникает. Так что я рассматривал только то, что выглядит приличнее, чем набор утилит. Если вы хотите найти более полную информацию о коллекторах netflow, то я посоветовал бы вам использовать поиск в том же Google.
Stager
Разработка "The Norwegian research network". Звучит уже интересно. Позволяет собирать netflow-, SNMP-статистику, следить за серверами с помощью ICMP (ping). Подерживает генерацию следующих NetFlow-отчетов:
- распределение трафика по интерфейсам;
- распределение трафика по IP-протоколам;
- распределение трафика по IP типам сервиса (ToS);
- распределение трафика по IP-адресам источника;
- распределение трафика по IP-адресам получателя;
- матрица IP-адрес источника/получателя;
- AS – источники;
- AS – получатели;
- матрица AS источника/получателя;
- multicast-группы;
- multicast-источники;
- multicast AS источники;
- общая статистика multicast-трафика;
- распределение портов источников на транспортном уровне;
- распределение портов получателей на транспортном уровне;
- сводный отчет.
По сути Stager - это ПО, использующее для сбора трафика flow-tools и perl. Данные хранятся в PostgreSQL, а веб интерфейс использует PHP и Apache.
Вообщем-то, добавить здесь больше нечего.
Ntop
Для большинства читателей этот продукт в представлениях не нуждается, однако... В двух словах - это очень мощный анализатор со встроенным веб-сервером. Список его возможностей вполне может превысить размер этой статьи. Ntop содержит NetFlow-плагин, который позволяет управлять netflow-данными. Каждая запись netflow-коллектора выглядит в Ntop как отдельный сетевой интерфейс. Очень удобно.
ManageEngine NetFlow Analyser
Платный продукт. Я его решил упомянуть из-за наикрасивейших отчетов (в самом прямом смысле). На большинство людей, далеких от сетевых реалий, распечатанный отчет NetFlow Analyser действует как гипнотический амулет. Им можно вручить этот отчет и все - о человеке можно забыть. Большие минусы – это, конечно же, цена и ресурсоемкость. Еще один минус - очень сильная агрегация. Если вы забыли создать фильтр на определенный вид трафика, то вряд ли вам удастся получить необходимые данные задним числом.
Однако, если от вас хотят красивую картинку, с учетом того, что над этим продуктом трудилась не один день группа программистов - вряд ли отношение стоимость/качество вашей разработки будет меньше предлагаемого решения. IMHO в любом случае проще потратить несколько сотен у.е. и купить, чем тратить на разработку аналога существующего продукта несколько тысяч у.е. и еще не факт, что получится лучше, хотя кто знает...
NeTAMS (Network Traffic Accounting and Monitoring Software)
Приятная система учета. Цитата с сайта: многофункциональная программа по учету и управлению IP-трафиком для маршрутизаторов Cisco или компьютеров под управлением Unix (Linux/FreeBSD/Solaris). Поддерживаются различные методы сбора статистики (tee/divert/ip_queue/ulog/libpcap/netflow v5 и v9/netgraph), хранения в базе данных (BerkleyDB/MySQL/PostgresSQL/Oracle/Radius), агрегирования, отображения, оповещения и пр. Возможно проводить блокировку на базе квот, авторизации, исчерпании баланса (биллинг); управлять полосой пропускания, контролировать подмену MAC-адреса, делать связь с RADIUS, создавать гибкие политики учета и фильтрации.
Как тут с управлением трафиком не знаю, а вот с учетом все ОК, за исключением двух неприятных, но для меня не смертельных моментов - учитывается только IP и производные протоколы и в статистике при импорте netflow не работает разделение на входящий/исходящий трафик, поэтому необходимо писать правила для разделения на in/out.
Вот и все, больше ничего интересного обнаружено не было. Разве что Traffic Accounting Project - изначально разрабатывался на ASM под GPL, сейчас переписан на C с лицензией "for personal use only". Мне интересно, ну нафига оно такое нужно?
Алексей Аксенов aka ezh.
обсуждение статьи
Сетевые решения. Статья была опубликована в номере 11 за 2005 год в рубрике технологии
