Jump to content
Калькуляторы
42 minutes ago, aabc said:

По-умолчанию он не выключен, а равен 0. Если у вас один экспортер, то так и оставьте. Если несколько, то сделайте им номера по порядку.

просветите немного Observation Domain ID  = что содержит?

ID как число ? и как его с доменом связать?

или

будет в поле

300 observationDomainName
Edited by banec

Share this post


Link to post
Share on other sites

А чем сейчас модно netflow собирать? Сколько уходит на это ресурсов? Можно ли делать это на бордере, например? Трафика 1,5г

Share this post


Link to post
Share on other sites
On 31.03.2018 at 8:54 PM, aabc said:

По-умолчанию он не выключен, а равен 0. Если у вас один экспортер, то так и оставьте. Если несколько, то сделайте им номера по порядку.

Поднял эластик+кибану + https://github.com/manitonetworks/flowanalyzer

 

Кибана в  Дисковери не показывает что в пакетах ipfix урлов или доменов :(

как я понимаю должно быть поле observationDomainName  - но его нет.  или я что-то не до понимаю ?

 

Share this post


Link to post
Share on other sites

aabc

Как я понял все таки IPFIX не содержит доменов  :( (подтвердите или опровергните плиз)

 

просто в flowanalyzer есть опция DNS lookup  - и на питоне, я глянул, юзает socket.getfqdn

но не все адреса резольвятся. даже если они имеют домен.

 

 

Share this post


Link to post
Share on other sites
1 hour ago, aabc said:

Каких доменов?

фактически мне нужно хранить кто куда ходил - ip внутренний и внешний, ip и сайт назначения.

по факту нет только сайтов (сопоставление ip c именем FQDN )

 

observationDomainName в ipfix думал как раз содержит FQDN

но это походу имя идентификатора id.

 

Хотелось бы всё в одном, но нужно городить огород по ходу.

 

 

 

Share this post


Link to post
Share on other sites

Я, кстати, думал что есть возможность добавить к каждому flow первые n-байт из его содержания. Анализаторы протоколов уже могли бы определить тип соединения (для IDS, например), может влезть начало http запроса, dns запросы, начало ответов на них (в обратные flows). Есть две проблемы - 1) нет стандарта для такого, хоть и определён элемент ipPayloadPacketSection, но он для PSAMP, а следовательно per-packet, в то время как идея чтоб было per-flow; 2) нет софта который бы это ожидал и парсил. Ну и недостаток что это будет занимать больше памяти и увеличивать нагрузку на экспорт.

Share this post


Link to post
Share on other sites

посылать первый пакет из flow по sflow :)

Для него тулзы есть, они и сопоставят потом

Share this post


Link to post
Share on other sites
On 03.04.2018 at 10:01 AM, banec said:

Хотелось бы всё в одном, но нужно городить огород по ходу

Сомневаюсь что без огорода получится. Анализировать http|https на NAT-е, имхо слишком, но и никто не запрещает. Только это нечто иное нежели задачи решаемые этим модулем. Даже идеологически, как мне кажется.
Для логирования обращения по http/https можно сгородить небольшой анализатор, кторотый будет выдирать SNI из TLS Handshake, для https, для http, мернее проблемно. Пусть это не полный пусть, по которому обращение было, но всё же. Ну и разумеется не netflow протоколом экспортировать.  К примеру, зеркалировать трафик с обращениями, на железке, а на сервере с анализатором получать зеркалированный трафик и логировать из нужных пакетов SNI.

Edited by bomberman

Share this post


Link to post
Share on other sites

Как можно слить netflow в несколько destination, но при этом на один из них нужно natevents=0. 

 

options ipt_NETFLOW destination=172.23.255.1:8889@172.23.255.10,172.23.255.1:9996@172.23.255.1 natevents=1 protocol=5

 

Т.е. отправляем с 172.23.255.10 на 172.23.255.1:8889 обычный NetFLOW 5, а на 172.23.255.1:9996 ещё natevents=1

 

Возможна такая конфигурация? указывать несколько разных destination не получится? И будут ли видны NAT трансляции в NetFLOW v5 ?

Edited by hsvt

Share this post


Link to post
Share on other sites
4 часа назад, hsvt сказал:

Возможна такая конфигурация? указывать несколько разных destination не получится? И будут ли видны NAT трансляции в NetFLOW v5 ?

 

пересобирали для этого модуль с другим именем. работает

 

Share this post


Link to post
Share on other sites
2 часа назад, LostSoul сказал:

пересобирали для этого модуль с другим именем. работает

 

Типа как в два инстанса запущено два модуля с разными именами? Можно подробней чуть, что править )

 

По сути нужно указывать два разных протокола, в один dst 9, в другой dst 5. А сейчас protocol только глобально можно на один модуль.

Edited by hsvt

Share this post


Link to post
Share on other sites
6 часов назад, hsvt сказал:

Типа как в два инстанса запущено два модуля с разными именами? Можно подробней чуть, что править )

Да, два инстанса.

я не помню, очень давно.

могу спросить товарища, который повторял опыт на centos 7 недавно.

 

Share this post


Link to post
Share on other sites

Добрый день. Решил кто-то задачу с отправкой neflow на два разных адреса ?

Share this post


Link to post
Share on other sites
2 часа назад, Susanin сказал:

Добрый день. Решил кто-то задачу с отправкой neflow на два разных адреса ?

а в чём проблема???

Share this post


Link to post
Share on other sites

1)Как привести в порядок именование интерфейсов при экспорте? На шлюзе 50+ VPN туннелей и VLAN + ppp до провадеров.

В fprobe-ulog можно было гвоздями прибить соответствие.

Сейчас при падении туннеля или ppp я вижу новый номер интерфейса при экспорте.

2)Как размножить ipt_NETFLOW по всем маршрутизаторам? (достаточно ли перенести модуль ядра?)

 

Использую- тестирую debian10

Share this post


Link to post
Share on other sites
2 часа назад, andrei.madiarov сказал:

1)Как привести в порядок именование интерфейсов при экспорте? На шлюзе 50+ VPN туннелей и VLAN + ppp до провадеров.

В fprobe-ulog можно было гвоздями прибить соответствие.

Сейчас при падении туннеля или ppp я вижу новый номер интерфейса при экспорте.

2)Как размножить ipt_NETFLOW по всем маршрутизаторам? (достаточно ли перенести модуль ядра?)

 

Использую- тестирую debian10

нашел в доках.

snmp-rules=eth0:0,ppp0:100,tun_cisco:999

snmp-rules=string...
- Few SNMP-index conversion rules similar to fproble-ulog.
 
Quoting man fprobe-ulog:
 
"Comma separated list of interface name to SNMP-index conversion
rules. Each rule consists of interface base name and SNMP-index
base separated by colon (e.g. ppp:200). Final SNMP-index is sum
of corresponding SNMP-index base and interface number.
In the above example SNMP-index of interface ppp11 is 211.
 
If interface name did not fit to any of conversion rules then
SNMP-index will be taken from kernel."
 
This implementation isn't optimized for performance (no rule caching
or hashing), but should be fast if rules list are short.
 

Rules are parsed in order from first to last until first match.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now