nDPI как замена l7filter

Имелось ввиду не ndpi (там кстати живенько все, скайп отефакторили, teredo добавили...), а сабжевая сборка от vel. Слежу за топиком давно, на сколько понял по последним страницам что были проблемы с не верным определением dns трафика и прочее. А так как 2 месяца тут молчанка, решил апнуть, а то вдруг тут уже все хорошо и можно собирать и использовать на работах в продакшене. Написал именно тебе, как главному тестеру, т.к. у тебя и дома и на работе на шлюзах данный патч крутится :).

времени нет :( Хотел в отпуске заняться, да #$%^&^%$ ремонт отнимает все время.

1. Могу сказать, что с DNS и ICMP у меня проблем лично нет. Все работает как часы.
2. Я ndpi использую в качестве доп функционала к моему скрипту динамического шейпера. Все что можно отловить через tc, я делаю через него. Остальное через ndpi, так как он создает более высокую нагрузку. Например через ndpi отлавливаю https, http и битторрент. То что может работать не по стандартным портам.

К слову если кому интересно шейпер можете взять и проверить/поковырять у себя. Шейпер этот по сути доделанный/подправленный nShaper, который делали для роутеров на олеговской прошивке. У меня уже больше 2 лет работает как дома так и на работе. Как часы. Правда для него надо патчить ядро (нужен IMQ). Конечно местами может встретиться говнокод. Но меня он устраивает =). Допиливать надоело.

Взять можно тут http://forum.ubuntu.ru/index.php?topic=261155.msg2065607#msg2065607 местные не заинтересовались. Когда будет время у себя в Blogger тоже добавлю.

А если там в логах персональные данные присутствуют? Так ведь и присесть в случае чего можно.

Неплохо бы его как нибудь на githubе оформить

Если честно не понял, что за цитата и откуда...

) Ну можно репозиторий сделать с этим скриптом,глядишь во что то нормально выльеться

Если кто-то им займется, я только за. У меня смена рабочего места. Сейчас времени мало заниматься этим. Он в принципе в большинстве своем нормальный. Просто может какие участки можно в более логический вид привести.

На гитхаб залей, да посмотрим.

было б время залил бы... Да и гитхабом не умею пользоваться >_<

Новостей с обновлением в скором времени стоит ожидать?)

я тут попытался смержить с 1.7. Оказыватся там дофига переделали. Часть изменений проста, а вот разделение результата на master_protocol и protocol требует существенных изменений...

Будем ждать.

Если через пару суток не упадет, выложу обновление до 1.7 .

Есть существенные изменения. Раньше протоколы разрешались по мере их использования в правилах и запрещались по мере удаления правил, теперь все совсем иначе: сначала через /proc/net/xt_ndpi/proto нужно будет запретить все ненужные протоколы (запрещать можно до первого добавления правила с NDPI матчем и таргетом), а потом трафик будет анализироваться на все разрешенные. Проблема в том, что после разрешения протокола его уже не запретить. IMHO это ограничение незначительное.

Народ который пилит старый вариант ndpi-netfilter сделали интересный шаг. У них есть специальное правило в match которое анализирует пакет и другой тип правил, который сравнивает протоколы. В принципе, у меня сейчас все равно рекомендуется именно такая же схема - первое правило «match all», а потом выбирай то, что нужно. Может есть смысл сделать анализ и сравнение раздельно ?

Там еще пилят user-defined протоколы, что IMHO полезно, но пока нет времени разобраться.

Все некогда на гитхабе форк выложить :(

выложил на https://github.com/vel21ripn/nDPI.git ветка netfilter

git clone -b netfilter https://github.com/vel21ripn/nDPI.git

Каких-либо существенных изменений пока нет.

Чуть позже выложу у себя.

Отлично! Будем тестить.

Вопрос к тем, кто читает этот тред и пользуется ndpi

Есть ли смысл доделать к ndpi-netfilter возможность загружать базу известных сервисов (все равно часть протоколов определяется именно так)? У ndpiReader есть возможность указать только порт для протокола.

Сейчас в ndpi уже есть «велосипед» для поиска по дереву с длиной ключа до 128 бит. Каждый мог бы создать свою базу в формате типа

protocol_name|id,(tcp|udp),network,port_list

А может где-то уже есть такие списки сервисов ?

IMHO это единственный способ идентифицировать шифрованные сервисы.

Я часто наблюдаю резкие пики неизвестного udp трафика. Хотелось бы их рассмотреть и приписать в какой-нибудь vpn. Возможность ведения такой базы избавит от необходимости перекомпилировать ndpi в случае изменения списка сетей используемого некоторыми протоколами (сейчас оно прибито гвоздями внутри).

Можно будет сделать протоколы определяемые пользователем. Проблема будет только с одним - как указать в iptables протокол который определен пользователем.

ndpi состоит из двух частей: модуля ядра и либы к iptables. Сейчас имена протоколов вкомпилированы в обе части. Если кто-то отдельно обновит модуль ядра от расширения iptables, то эти данные будут разные и результаты скорее всего странные. Введение пользовательских протоколов потребует пересмотра этого решения (может оно и к лучшему).

Стоит динамически заргужаемую бд делать.

А может где-то уже есть такие списки сервисов ?

Ну можно попытаться выкопать такие данные из микротиковских l7-filter но там немного не то

С другой стороны зачем в ndpi дублировать функционал, который есть в том же iptables|tc. Как по мне ndpi нужен когда с помощью какого-то анализа определяется тип протокола.

А про дублирование в iptables/ipset/tc можно по-подробнее? Возможно я о чем-то не знаю. В принципе, ipset hash:ip,port и hash:net,port можно было бы использовать.

А лучьше бы интерпритировать в ndpi функционал suricata

protocol_name|id,(tcp|udp),network,port_list

-A PREROUTING -m set --match-set SRC_VLANS src,src -m set --match-set DST_TOR dst -p tcp -m tcp -m multiport --dports 80,443 -j DNAT --to-destination 192.168.155.1:9052

Типа такое имеется ввиду? ipset хорошо подходит под списки, умеет и порт, но не уммет tcp/udp. В примере использованы hash:net,iface и hash:net. А вот portlist не умеет, да.

hash:ip,port - умеет tcp/udp/udplite/sctp с диапазоном портов

Единственная проблема в ipset hash - отсутствие проверки пересечения подсетей.

А как идея добавить в nDPI поддежку pload string и блок по url

iptables -t mangle -A PREROUTING|POSTROUTING -p tcp|udp|etc --dport|sport -s|-d -j MARK --set-mark xx

или тоже но tc

tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip dport|sport 80 0xffff match ip dst|src xxx.xxx.xxx.xxx match ip protocol 1|6|17|etc 0xff flowid 1:1

Ну и все в таком духе. Я к тому, что если определение типа трафика идет только на основе его порта|протокола|адреса зачем это добавлять в модуль, если это можно стандартными средствами делать.

Другое дело если ndpi используется без iptables|tc, но мне что-то не приходят в голову примеры такого использования.

Через ipset еще удобнее. Оно уже давно умеет skbmark делать и класс определять.

Мне бы хотелось определять тип трафика в каком-то одном месте. т.к. внутри nDPI появился готовый механизм, то почему бы им не воспользоваться? В 1.5 такого механизма небыло.

Не знаю что они там намутили с bittorrent но он перестал определять. На предыдущей версии не знаю как работало (маркировал трафик по id юзера от которого работал торрент клиент), но в этой версии вообще не видит.

Блин да когда же будет «пока все работает, вроде» чтобы уже потрогать нормально...

Исправлены 2 небольшие ошибки:

в ndpi/dns не смертельно, но ядро ругалось.

Исправлена ошибка с счетчиком использования модуля. Не влияет на работоспособность.

Доп тесты с bittorrent протоколом не проводили?

а как там баг с ppp в некоторых сетях

После первой жалобы на торренты в 1.7 я решил не рисковать и не ставить новую версию на боевой сервер, но вот сейчас таки рискнул и обновил модуль.

Торренты определяет. Может конечно не все и не всегда (не набралось еще достаточно статистики), но мои личные несколько тестовых закачек определились все, да и клиентский трафик в правило залетает примерно в таком же количестве как и до обновления.

При выгрузке уже обновленного модуля (забыл включить bt_hash) получил вот это:

[Sun Oct 11 07:53:20 2015] xt_ndpi v1.2 ndpi 1.7.0-netfilter-176-4b10824 with IPv6
                            bt hash size 0k gc timeout 1200 sec
                            sizeof hash_ip4p_node  44
                            sizeof id_struct 288
                            sizeof flow_struct 904
                             sizeof packet_struct 416
                             sizeof flow_tcp_struct 38
                             sizeof flow_udp_struct 18
                             sizeof int_one_line_struct 4
                            sizeof ndpi_ip_addr_t 16
                            ext ID 11
[Sun Oct 11 08:01:05 2015] xt_ndpi 1.2 unload.
[Sun Oct 11 08:01:05 2015] ------------[ cut here ]------------
[Sun Oct 11 08:01:05 2015] WARNING: CPU: 3 PID: 835762 at kernel/module.c:1120 module_put+0x54/0x60()
[Sun Oct 11 08:01:05 2015] Modules linked in: xt_ndpi(O-) xt_ratelimit(O) cls_flower xt_conntrack xt_hashlimit xt_IMQ ipt_weburl xt_connlabel xt_TEE xt_TCPMSS xt_time xt_mark xt_CLASSIFY xt_length ip_set_bitmap_port(O) iptable_mangle xt_NETMAP xt_comment xt_bpf xt_nat xt_set(O) iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat ipt_rpfilter xt_multiport xt_recent iptable_raw ip_tables act_police cls_fw ip_set_hash_net(O) ip_set(O) cls_flow sch_hfsc l2tp_ppp l2tp_netlink l2tp_core ip6_udp_tunnel udp_tunnel pptp pppoe pppox ppp_generic slhc ipip tunnel4 ip_tunnel bonding ipoe(O) imq nf_conntrack_netlink nfnetlink ipt_NETFLOW(O) ipv6 sch_prio_codel sch_fq_codel sch_codel ifb iTCO_wdt crct10dif_pclmul e1000e(O) crct10dif_common igb(O) lpc_ich crc32_pclmul mfd_core button [last unloaded: xt_ndpi]
[Sun Oct 11 08:01:05 2015] CPU: 3 PID: 835762 Comm: rmmod Tainted: G           O    4.2.3+ #2
[Sun Oct 11 08:01:05 2015]  0000000000000000 ffffffff814b91f2 ffffffff8136ef0f 0000000000000000
[Sun Oct 11 08:01:05 2015]  ffffffff810374e7 ffff8802169c8394 ffffffff8163f200 ffff8802169c8008
[Sun Oct 11 08:01:05 2015]  ffff8802169c8000 0000000001bb2370 ffffffff81088134 ffff880226857978
[Sun Oct 11 08:01:05 2015] Call Trace:
[Sun Oct 11 08:01:05 2015]  [<ffffffff8136ef0f>] ? dump_stack+0x47/0x67
[Sun Oct 11 08:01:05 2015]  [<ffffffff810374e7>] ? warn_slowpath_common+0x77/0xb0
[Sun Oct 11 08:01:05 2015]  [<ffffffff81088134>] ? module_put+0x54/0x60
[Sun Oct 11 08:01:05 2015]  [<ffffffffa02ba02c>] ? ndpi_disable_protocols+0x1c/0x30 [xt_ndpi]
[Sun Oct 11 08:01:05 2015]  [<ffffffffa02ba587>] ? ndpi_net_exit+0x47/0x130 [xt_ndpi]
[Sun Oct 11 08:01:05 2015]  [<ffffffff812b1b12>] ? ops_exit_list.isra.8+0x32/0x70
[Sun Oct 11 08:01:05 2015]  [<ffffffff812b1c48>] ? unregister_pernet_operations+0x88/0xd0
[Sun Oct 11 08:01:05 2015]  [<ffffffff812b1ca8>] ? unregister_pernet_subsys+0x18/0x30
[Sun Oct 11 08:01:05 2015]  [<ffffffffa02ff330>] ? ndpi_mt_exit+0x57/0x64 [xt_ndpi]
[Sun Oct 11 08:01:05 2015]  [<ffffffffa02ff2d9>] ? ndpi_check_for_YmsgCommand+0xa3/0xa3 [xt_ndpi]
[Sun Oct 11 08:01:05 2015]  [<ffffffff8108993d>] ? SyS_delete_module+0x15d/0x220
[Sun Oct 11 08:01:05 2015]  [<ffffffff8110408c>] ? mntput_no_expire+0xc/0x190
[Sun Oct 11 08:01:05 2015]  [<ffffffff81373a17>] ? entry_SYSCALL_64_fastpath+0x12/0x6a
[Sun Oct 11 08:01:05 2015] ---[ end trace 90486867ae3b6929 ]---
[Sun Oct 11 08:01:31 2015] xt_ndpi v1.2 ndpi 1.7.0-netfilter-176-4b10824 with IPv6
                            bt hash size 32k gc timeout 1800 sec
                            sizeof hash_ip4p_node  44
                            sizeof id_struct 288
                            sizeof flow_struct 904
                             sizeof packet_struct 416
                             sizeof flow_tcp_struct 38
                             sizeof flow_udp_struct 18
                             sizeof int_one_line_struct 4
                            sizeof ndpi_ip_addr_t 16
                            ext ID 11

Вот еще статистика самого модуля по протоколам:

cat /proc/net/xt_ndpi/proto | sort -k5 -n -r | head -n20
25        25/000000ff bittorrent       # 29146880
07         7/000000ff http             # 1930719
05         5/000000ff dns              # 1723384
5b        5b/000000ff ssl              # 398298
83        83/000000ff http_proxy       # 264148
7d        7d/000000ff skype            # 209491
51        51/000000ff ip_icmp          # 206441
7e        7e/000000ff google           # 127963
03         3/000000ff mail_smtp        # 88144
46        46/000000ff yahoo            # 20894
82        82/000000ff http_connect     # 20251
4d        4d/000000ff telnet           # 19686
58        58/000000ff rdp              # 19145
78        78/000000ff twitter          # 11247
72        72/000000ff mssql            # 11105
09         9/000000ff ntp              # 8063
64        64/000000ff sip              # 6241
4a        4a/000000ff steam            # 5951
0e         e/000000ff snmp             # 5833
7c        7c/000000ff youtube          # 5261

а что за версия ядра ? Это с версией 20151010 ?

Битторрент с шифрованием? У меня раньше шифрованный определял.

версия ядра 4.2.3

это на обоих версиях, 20151010 и какая там была до неё. но на тестовом серваке такая бяка случилась только после первой выгрузки, последующие выгрузки-загрузки уже без проблем.

ставил в utorrent принудительное шифрование на исход и галку разрешить входящие. Судя по флагам на пирах, большинство шифрованный utp.

уточнение - предыдущий вывод был от коммита 4b10824.

на последнем 20151010 (b2468bb) немного отличается:

[Sun Oct 11 08:32:30 2015] ------------[ cut here ]------------
[Sun Oct 11 08:32:30 2015] WARNING: CPU: 0 PID: 111070 at mm/page_alloc.c:2992 __alloc_pages_nodemask+0x4fb/0x7a0()
[Sun Oct 11 08:32:30 2015] Modules linked in: xt_ndpi(O+) l2tp_ppp l2tp_netlink l2tp_core ip6_udp_tunnel udp_tunnel xt_ratelimit(O) xt_length act_police xt_conntrack xt_hashlimit xt_IMQ xt_connlabel xt_TEE xt_TCPMSS ipt_weburl xt_time xt_mark xt_CLASSIFY ip_set_bitmap_port(O) iptable_mangle xt_NETMAP xt_comment xt_bpf xt_nat xt_set(O) iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat xt_multiport xt_recent iptable_raw ip_tables act_mirred cls_fw ip_set_hash_net(O) ip_set(O) cls_flow sch_hfsc pptp pppoe pppox ppp_generic slhc ipip tunnel4 ip_tunnel bonding ipoe(O) imq nf_conntrack_netlink nfnetlink ipt_NETFLOW(O) ipv6 sch_prio_codel sch_fq_codel sch_codel ifb iTCO_wdt e1000e(O) crct10dif_pclmul crct10dif_common lpc_ich crc32_pclmul mfd_core button [last unloaded: xt_ndpi]
[Sun Oct 11 08:32:30 2015] CPU: 0 PID: 111070 Comm: modprobe Tainted: G           O    4.2.3+ #3
[Sun Oct 11 08:32:30 2015]  0000000000000000 ffffffff814b9cbf ffffffff8136eeff 0000000000000000
[Sun Oct 11 08:32:30 2015]  ffffffff810374e7 00000000000000d0 000000000000000b ffffffff8164a700
[Sun Oct 11 08:32:30 2015]  0000000001ffffff ffff880224d85a80 ffffffff810a976b ffff88021342bbc4
[Sun Oct 11 08:32:30 2015] Call Trace:
[Sun Oct 11 08:32:30 2015]  [<ffffffff8136eeff>] ? dump_stack+0x47/0x67
[Sun Oct 11 08:32:30 2015]  [<ffffffff810374e7>] ? warn_slowpath_common+0x77/0xb0
[Sun Oct 11 08:32:30 2015]  [<ffffffff810a976b>] ? __alloc_pages_nodemask+0x4fb/0x7a0
[Sun Oct 11 08:32:30 2015]  [<ffffffffa0274df6>] ? ac_automata_add+0x96/0xd0 [xt_ndpi]
[Sun Oct 11 08:32:30 2015]  [<ffffffffa027551b>] ? ndpi_string_to_automa.isra.2+0x3b/0x70 [xt_ndpi]
[Sun Oct 11 08:32:30 2015]  [<ffffffff810bbcf3>] ? kmalloc_order+0x13/0x50
[Sun Oct 11 08:32:30 2015]  [<ffffffffa02861f6>] ? hash_ip4p_init+0x26/0x80 [xt_ndpi]
[Sun Oct 11 08:32:30 2015]  [<ffffffffa02888ac>] ? ndpi_bittorrent_init+0x1c/0x90 [xt_ndpi]
[Sun Oct 11 08:32:30 2015]  [<ffffffffa02739a6>] ? ndpi_net_init+0x116/0x3f0 [xt_ndpi]
[Sun Oct 11 08:32:30 2015]  [<ffffffff812b21a8>] ? ops_init+0x38/0x110
[Sun Oct 11 08:32:30 2015]  [<ffffffffa00b8000>] ? 0xffffffffa00b8000
[Sun Oct 11 08:32:30 2015]  [<ffffffff812b2471>] ? register_pernet_operations+0xe1/0x1a0
[Sun Oct 11 08:32:30 2015]  [<ffffffff810cdb66>] ? vunmap_page_range+0x1d6/0x2c0
[Sun Oct 11 08:32:30 2015]  [<ffffffff812b254f>] ? register_pernet_subsys+0x1f/0x40
[Sun Oct 11 08:32:30 2015]  [<ffffffffa00b8069>] ? ndpi_mt_init+0x69/0x25a [xt_ndpi]
[Sun Oct 11 08:32:30 2015]  [<ffffffff810002be>] ? do_one_initcall+0x7e/0x1a0
[Sun Oct 11 08:32:30 2015]  [<ffffffff8136e7c5>] ? do_init_module+0x50/0x1ce
[Sun Oct 11 08:32:30 2015]  [<ffffffff8108b612>] ? load_module+0x1b92/0x1e50
[Sun Oct 11 08:32:30 2015]  [<ffffffff81088af0>] ? ref_module+0x100/0x100
[Sun Oct 11 08:32:30 2015]  [<ffffffff8108ba36>] ? SyS_finit_module+0x66/0x70
[Sun Oct 11 08:32:30 2015]  [<ffffffff81373a17>] ? entry_SYSCALL_64_fastpath+0x12/0x6a
[Sun Oct 11 08:32:30 2015] ---[ end trace e31e5a8461746200 ]---
[Sun Oct 11 08:32:30 2015] xt_ndpi v1.2 ndpi 1.7.0-netfilter-180-b2468bb with IPv6

на 4.2 я вообще пока не пробовал.

А мне пришлось несколько дней назад попробовать после неудачного обновления c 4.1.6 на 4.1.9-10 с его softlockup. )

Как бы проблема не серьезная, проявляется только при выгрузке модуля, ни к каким фатальным последствиям не ведет. Может она у меня давно была, просто я модуль не выгружал принудительно уже давно, это вот при обновлении без ребута пришлось выгрузить...

При сборке появляются варнинги

/usr/src/nDPI-1.7.20151010/ndpi-netfilter/src/../lib/protocols/bittorrent.c: In function ‘ndpi_search_bittorrent’:
/usr/src/nDPI-1.7.20151010/ndpi-netfilter/src/../lib/protocols/bittorrent.c:1290:7: warning: unused variable ‘no_bittorrent’ [-Wunused-variable]
   int no_bittorrent = 0;
/usr/src/nDPI-1.7.20151010/ndpi-netfilter/src/../lib/protocols/ftp_data.c: In function ‘ndpi_search_ftp_data’:
/usr/src/nDPI-1.7.20151010/ndpi-netfilter/src/../lib/protocols/ftp_data.c:232:30: warning: unused variable ‘packet’ [-Wunused-variable]
   struct ndpi_packet_struct *packet = &flow->packet;
/usr/src/nDPI-1.7.20151010/ndpi-netfilter/src/../lib/protocols/mpegts.c: In function ‘ndpi_search_mpegts’:
/usr/src/nDPI-1.7.20151010/ndpi-netfilter/src/../lib/protocols/mpegts.c:36:15: warning: unused variable ‘pkt_id’ [-Wunused-variable]
     u_int32_t pkt_id;
               ^
/usr/src/nDPI-1.7.20151010/ndpi-netfilter/src/../lib/protocols/mpegts.c:30:24: warning: unused variable ‘sport’ [-Wunused-variable]
   u_int16_t dport = 0, sport = 0;
                        ^
/usr/src/nDPI-1.7.20151010/ndpi-netfilter/src/../lib/protocols/mpegts.c:30:13: warning: unused variable ‘dport’ [-Wunused-variable]
   u_int16_t dport = 0, sport = 0;

Это нормально? Есть и на другие протоколы, но они мне не интересны, поэтому не привел их.

Только что проверил. С шифрованием не видит. Снимаю шифрование и сразу видит трафик. Попробуйте включить шифрование и перезапустить клиент.

Сделал. В списке пиров теперь исключительно шифрованные соединения - видит!

На всякий случай - у меня выключен BT_ANNOUNCE и включен bt_hash. Не знаю, может это как-то влияет...

Попробую сейчас выключить BT_ANNOUNCE и собрать еще раз. bt_hash включал. Может именно из-за этого у вас детектится? Типа сперва без шифрования он увидел, а так как был включен хеш, то после включения шифрования он «видит» трафик? Если не сложно проверьте выгрузив модуль и загрузив но без хеша.

оказывается действительно дело было в BT_ANNOUNCE о_О. Отключил, и теперь видит шифрованный трафик тоже. vel с чем связанно не скажите?

в ftp_data & mpegts я не хочу исправлять эти предупреждения, чтоб потом конфликты не образовывались.

а в bittorrent - исправлю.

Я как раз утром это проверял, несколько раз выгружал-загружал модуль, с хэшем и без него, очищая коннтрэк, и сразу запускал торрент с шифрованием соединений. Все новые сессии модуль видел, а старые активные, висящие у клиентов, естественно, не всегда.

Рано радовался. Входящий вроде бы нормально определяет. А вот исходящий все так же почти не ловит...

Еще вопрос, вот весь исходящий проходит через правила, это нормально что два первых правила не матчат весь трафик? Или это то, что еще неопределилось никак?

12   1339K  354M ACCEPT  all  --  *   *  0.0.0.0/0     0.0.0.0/0     ndpi protocol all
13   33675 5049K ACCEPT  all  --  *   *  0.0.0.0/0     0.0.0.0/0     ndpi protocol unknown
14   21791   33M ACCEPT  all  --  *   *  0.0.0.0/0     0.0.0.0/0

Кстати, спасибо что напомнили про unknown и all. Проверил сейчас. У меня исходящий bittorrent ни в тот ни в другой не попадает) То есть ни в all, ни в bittorrent ни в unknown. Вот такие дела... Точнее что-то попадает, но 0,5-1% от всего трафика.