Установка сенсора netflow на CentOS

а чем плохи сенсоры, реализованные как утилиты (сервисы)? Например, fprobe? или где-то «родной» для UTM сенсор ndsad (поскольку сделан тоже NetUp) или nProbe дешево и сердито. и ничего пересобирать не надо. стартуешь и работает.

а вообще этих сенсоров море. и вполне гуглятся.

а чем плохи сенсоры, реализованные как утилиты (сервисы)?

Потреблением ресурсов. Никакого сравнения с ipt_netflow.

но и анализировать трафик.

Что значит анализировать ? Что-то можно посредством nfsen посмотреть, например.

Или лучше использовать другие сенсоры?

Зависит от пропускаемого трафика и мощности шлюза. Не лучше - это точно. Но допустимо, если мощность позволяет трафик каким-то другим сенсором обработать.

Я вот не могу ни ipt_netflow, ни утилиту настроить, потому что под CentOS это не собрано. Подключены репозитории EPEL и ELREPO, но что-то я в них не вижу искомого.

Что значит анализировать ? Что-то можно посредством nfsen посмотреть, например.

flow-tools, nfsen, попытки чего-то программировать - это я уже проходил, с централизованным биллингом никакого сравнения.

Подключены репозитории EPEL и ELREPO, но что-то я в них не вижу искомого.

Значит собирать. Ядро, кстати, не нужно, если в CentOS пакеты с хитерами ядер есть соответствующие. Только модуль дособрать, и всё. А вот iptables пересобрать придётся.

с централизованным биллингом никакого сравнения.

Так биллинг надо, или анализатор трафика? В качестве биллинга можно http://www.netams.com/netams4.html посмотреть.

Так биллинг надо, или анализатор трафика?

Сейчас объясню как я себе представляю работу системы. Сенсор netflow отслеживает транзитные пакеты и посылает об этом информацию коллектору. Коллектор netflow записывает полученные от сенсора потоки netflow в таблицу базы mysql. Раз в определённые промежутки времени (например раз в минуту) запускается преданализатор, он очищает вышеописанную таблицу, чтобы она не распухала, но перед этим считает для этой информации промежуточную статистику и записывает её в другую таблицу. Для того, чтобы посчитать эту статистику, преданализатор должен знать какой ip-адрес в настоящее время арендуется каждым пользователем, для этого преданализатор должен уметь взаимодействовать с dhcp-сервером. Предстатистика должна быть такой: для входящего трафика ip получателя заменяется на имя пользователя, а ip отправителя проходит обратное преобразование ip-адреса в домен, для исходящего трафика наоборот. Процесс формирования предстатистики должен быть неприрывен. С предстатистикой, сформированной преданализатором работает анализатор, он имеет GUI или web-интерфейс, анализатор может, например посчитать трафик каждого пользователя за период времени или показать подоменному статистику посещений для каждого пользователя или, если период снятия предстатистики уменьшить до секунды, может показать процент нагрузки канала каждым пользователем в режиме реального времени.
Примерно такая задача стояла передо мной 3,5 года назад и я с ней не справился. А недавно получил практический опыт работы с таким классом программ как системы биллинга. Для того, чтобы описанная система работала, нужно, чтобы были не просто три разные программы: фаерволл, dhcp-сервер и анализатор, а чтобы они были частью одной системы. UTM как раз позволяет это. С помощью скриптов в ней можно настроить управление фаерволлом и dhcp-сервером непосредственно из биллинга. К сожалению она не позволяет построить статистику того характера что я описал и является платной.

Раз в определённые промежутки времени (например раз в минуту) запускается преданализатор

Тут слабое место. Это надо сенсор заставить сбрасывать статистику не реже этого же времени. Это возможно, но, боюсь, поток данных будет через чур. В общем, оно точно надо такой ценой ?

Я, честно говоря, вариантом обработки netflow в реальном времени не интересовался даже из-за этого. А так - у нас сенсор сбрасывает статистику с 10-минутным интервалом (то есть, принудительный обрыв учёта цепочки такой, если он сам обнаруживает окончание, то раньше сбрасывает). Собирает всё nfdump, а уже дальше его данные обрабатываются. Привязка пользователь-ip обеспечивается легко. Следующее слабое место: а ip отправителя проходит обратное преобразование ip-адреса в домен. А если с DNS, обслуживающем обратную зону беда ? Обработка встанет на время, сравнимое с вечностью. Я бы даже не в реалтайме такое делать не стал.

В общем, если всё вместе сложить, то я не знаю такой системы. И, вероятно, её просто нет.

Следующее слабое место: а ip отправителя проходит обратное преобразование ip-адреса в домен. А если с DNS, обслуживающем обратную зону беда ? Обработка встанет на время, сравнимое с вечностью. Я бы даже не в реалтайме такое делать не стал.

Ага, согласен. Я это делаю уже потом на суммарных данных.