nDPI как замена l7filter

Версия ядра какая ? 32/64 ? Ядро патченное ?

kernel oops можешь показать ? Например через альтернативный вариант с ramoops

Ядро 3.18.3 и 3.17.8, ванильное, 64 бита, из патчей IMQ (но его выгружал и не задействовал).

как тут лучше oops запостить? может на мыло, а то сливаются строки? )

А все не нужно.

интересует строка с «EIP is at ...» и первые 5-7 строк после «Call Trace:»

в тег code оберни, чтоб не сливалось

Такой строки почему-то нет... Может что-то в конфиге ядра выключено?

Трейс вот:

[ 1176.031397] RIP [<ffffffff811d5508>] memcmp+0x8/0x50

[ 1176.029639] Call Trace:

[ 1176.029678] <IRQ>

[ 1176.029684] [<ffffffffa02de241>] ? ndpi_id_search_or_insert+0x41/0x130 [xt_ndpi]

[ 1176.029805] [<ffffffffa02df5e7>] ? ndpi_mt+0x5b7/0x6f0 [xt_ndpi]

[ 1176.029860] [<ffffffff81392766>] ? ipt_do_table+0x296/0x5f0

[ 1176.029913] [<ffffffff8138501d>] ? fib_table_lookup+0x2bd/0x320

[ 1176.029967] [<ffffffff81347400>] ? inet_del_offload+0x40/0x40

[ 1176.030020] [<ffffffff8132057d>] ? nf_iterate+0x5d/0x90

[ 1176.030071] [<ffffffff81347400>] ? inet_del_offload+0x40/0x40

[ 1176.030123] [<ffffffff81320629>] ? nf_hook_slow+0x79/0x130

[ 1176.030175] [<ffffffff81347400>] ? inet_del_offload+0x40/0x40

[ 1176.030228] [<ffffffff813479e3>] ? ip_local_deliver+0x63/0x80

При загрузке модуля xt_ndpi в лог пишется размер структуры «sizeof id_struct». Сколько он у тебя получился ?

Я воспроизвел проблему.

обновил версию до nDPI-1.5.1.r8636_v3d.tar.gz. Была какая-то странная проблема связанная с выравниванием в структурах.

as_lan!

Спасибо! Бегло проверил - пока не падает. )

Спасибо. Сегодня обновлюсь.

Обратил внимание на то, что ndpi к торрентам часто относит, например, NETFLOW, CounterStrike. (

у BT используется кеширование адрес/порт, так что возможно.

как добиться повышения точности - пока не знаю.

Пока из нереализованного - возможность загружать свой список соответствия [адрес:]port - протокол (как это сделано в примере) и описывать свои протоколы.

Мне кажется дело не в этом, так как можно не запускать вообще торрент, сразу какую-нибудь игру и он начнет ее трафик детектировать как bittorrent

образец такого трафика в формате pcap получить бы. Тогда можно было бы понять почему так происходит.

Согласен. На примере NETFLOW заметил, «голый» сервер с которого летит только и только нетфлоу сразу же попадает в торрент с перврго же пакета. В лог пишет BT: plain BitTorrent protocol detected. Пакеты сгенерены модулем ipt_NETFLOW.

к сожалению контры нет сейчас под рукой) но могу завтра скинуть трафик WoT.

образец в Pcap сделал - как «получить бы» ?? ))

WoT да, часто попадает, но я думал что из-за того что клиент в своей работе использует торрент для обновления. Ну а дальше хэш с адресом-портом и пошло поехало...

А исключать из сборки не используемые протоколы все еще нельзя? Мне например не больше десятка протоколов нужны. Остальные даже в перспективе не буду использовать.

Если есть образец netflow v9 или IPFIX, то пришли мне на vel21ripn dog gmail point com

Но, оно должно быть с начала передачи данных ( начиная с передачи template).

Для v5 у меня есть образцы и они не путаются с BT.

В тот то и дело что v5 и путаются с BT, а в --netflow тупо не детектятся... (

странно. Пока не могу это подтвердить.

В nDPI есть example/ndpiReader (нужно собрать nDPI). Попробуй через него пропустить свой .pcap образец или пришли мне

Попробовал выключить #define BT_ANNOUNCE, но файлик /proc/net/xt_ndpi/announce создается и заполняется.

по ошибке оно определено в 2-х местах. в ndpi-netfilter/src/main.c:57 и в ndpi-netfilter/include/ndpi_typedefs.h:30

Закомментарить нужно обе.

яснопонятно

кстати, как безболезненно увеличить (>32) хэш для БТ раз так в 8 или даже больше ?

Это начальный размер хеша bt_hash_size*1024

До 64 скорее всего можно увеличить без проблем. Но зачем ?

По моим прикидкам bt_hash_size=32 это до 10М элементов. Ты уверен, что тебе нужно больше ?

до 64 я и сам увеличил, работает. 128 пробовал, но задействуется только половина, больше 192(вроде) не устанавливается вообще... )

нет, не уверен ) просто памяти валом и где-то читал что оптимальный размер хэша для скорости - четверь от кол-ва элементов, в моем случае это 256-384 где-то при кол-ве элементов 1-2 млн.

дальше нужно изменять функцию вычисления хеша hash_calc в bittorent.c

Я выбирал из рельного трафика за пару часов уникальные пары ip:port и загонял в хеш. Если распределение было очень неравномерным, то менял значение M.

#ifdef BT_ANNOUNCE
static const struct file_operations nann_proc_fops = {
        .open    = ninfo_proc_open,
        .read    = nann_proc_read,
};
#endif

еще пришлось один ifdef добавить

Спасибо. Потом подправлю.

Обновления под новые ревизии будут?)

пока нет времени этим заниматься. Наверно после праздников посмотрю что и как.

обновил до 8994.

Вроде работает.

багфиксы для предыдущих версий в 8994 включены?

Еще не выложили? Что-то не вижу на страничке ссылку...

http://devel.aanet.ru/ndpi/nDPI-1.5.1.r8994.tar.gz

Благодарствую.

Вернусь к теме ложного срабатывания bittorrent. Имеем:

перенаправляю копию как бы торрента (на самом деле самый что ни есть dns) на пустой интерфейс

-A FORWARD -p udp -m ndpi  --bittorrent  -m multiport --ports 53 -j TEE --gateway 10.99.99.2 --oif vlan412

потом запускаю «ndpiReader -i vlan412 -s 60 -n 4» и получаю результат

Detected protocols:
        DNS                  packets: 106707        bytes: 10791428      flows: 56259
        MSN                  packets: 43            bytes: 6621          flows: 19
        Yahoo                packets: 1753          bytes: 221037        flows: 793
        Facebook             packets: 248           bytes: 45128         flows: 108
        Twitter              packets: 160           bytes: 27228         flows: 68
        DropBox              packets: 40            bytes: 7724          flows: 12
        GMail                packets: 40            bytes: 7008          flows: 16
        YouTube              packets: 832           bytes: 157920        flows: 376
        Skype                packets: 104           bytes: 21296         flows: 48
        Google               packets: 3843          bytes: 557025        flows: 1706
        Apple                packets: 152           bytes: 35528         flows: 48
        WhatsApp             packets: 16            bytes: 3408          flows: 8
        AppleiCloud          packets: 16            bytes: 1988          flows: 8
        Viber                packets: 40            bytes: 10536         flows: 20
        AppleiTunes          packets: 8             bytes: 2468          flows: 4
        H323                 packets: 4             bytes: 404           flows: 4
        Wikipedia            packets: 16            bytes: 1392          flows: 4
        Amazon               packets: 144           bytes: 31160         flows: 60

Хэш в модуле отключен.

Если бы еще образец трафика - то цены бы не было этому багрепорту.

Завтра попробую на тестовой машине.

ушло на мыло

Я смог повторить ошибку. Проблема похоже именно в ядерной версии.

ndpiReader правильно опознает как dns трафик

гм. пока то, что маскируется под dns на 53 порту им совсем не является!

Есть host 5.45.62.77 на 53 порту там совсе не dns!

я допускаю, что в 53 удп может быть не днс в каком-то небольшом количестве. Но хостов там уйма в т.ч. 8.8.8.8 гугловские и мои днс-сервера, которые уж точно только днс и ни что иное.

Я пока настроил сбор данных через nflog & tcpdump.

PS #$&^$&^! Везде разложены грабли! ndpiReader не понимает тип линка NFLOG :( Пришлось похакать.

я тоже наступил на эти грабли в прошлый раз )

Еще хуже то, что tcpdump не умеет фильтровать собранный им же трафик!

вроде фильтрует, например

tcpdump -tttt -r dns3.pcap udp and host 8.8.8.8 -n

то, что с link layer NFLOG - не может :(

tcpdump -nr bag_dns2 udp
reading from file bag_dns2, link-type NFLOG (Linux netfilter log messages)
tcpdump: NFLOG link-layer type filtering not implemented

Это гвоздями прибито в libpcap

Пока все что я собрал не позволяет сказать, что есть явная ошибка.

У меня есть подозрение на некий сценарий:

Юзер со своего ip:port общался с BT, потом перестал и дальше этот порт стал использоваться для запросов к DNS. Из кеша был взят старый результат BT.

Я подумаю как это можно было бы избежать.

В принципе «conntrack -F» можно использовать как сброс кеша.