LINUX.ORG.RU

nDPI как замена l7filter

 ,


23

17

Если кому интересно, то вот рецепт

На большом потоке ( >300мбит/с ) c большим числом протоколов (>20) используется примерно 40% одного ядра Intel(R) Xeon(R) CPU E31230@3.20GHz. Если поток больше или процессор слабее, то включаем RPS или используем сетевые карты с multi-queue и irq-affinity :)

Требуется много памяти. На каждое соединение расходуется примерно 800+264*0.7 байт.

Исходники теперь есть на https://github.com/vel21ripn/nDPI/tree/netfilter

★★★★★

Последнее исправление: vel (всего исправлений: 3)
Ответ на: комментарий от anonymous

выложил обновленное. Там кроме протоколов, еще есть исправления.

vel ★★★★★
() автор топика
Ответ на: комментарий от anonymous

я бы начал с v.3.10.20

Оно должно прикладываться без режектов.

Возможно подойдет от 3.12

Там нет существенной разницы

vel ★★★★★
() автор топика
Ответ на: комментарий от vel

Да что я такой невезучий: все скачал, пробую пропатчить ядро patch -p0 /home/ramadann/nDPI-1.4.0.r7867/kernel-patch/v3.12.7.diff и он думает... думает... думает ...думает... и ни ошибок, ни результата

anonymous
()
Ответ на: комментарий от anonymous

man patch

c "-p0" оно точно не приложиться.

или

patch -p1 -i /home/ramadann/nDPI-1.4.0.r7867/kernel-patch/v3.12.7.diff
или
patch -p1 </home/ramadann/nDPI-1.4.0.r7867/kernel-patch/v3.12.7.diff
в каталоге с исходниками ядра.

vel ★★★★★
() автор топика
Ответ на: комментарий от vel

Понял спасибо. nf_conntrack_extend.h пропатчило и сказало что: Reversed (or previously applied) patch detected! Assume -R? [n] y patching file net/netfilter/nf_conntrack_acct.c Reversed (or previously applied) patch detected! Assume -R? [n] y patching file net/netfilter/nf_conntrack_extend.c Reversed (or previously applied) patch detected! Assume -R? [n] y patching file net/netfilter/nf_conntrack_standalone.c Reversed (or previously applied) patch detected! Assume -R? [n] y

Видимо из-за того, что я до этого тренировался) Я везде проставил «y», ошибок не выдало - значит норм пропатчило?

anonymous
()
Ответ на: комментарий от vel

При сборке ядра выдало:

In file included from include/net/netfilter/nf_conntrack_helper.h:13:0, from net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c:23: include/net/netfilter/nf_conntrack_extend.h:30:33: error: ‘CONFIG_NF_CONNTRACK_CUSTOM’ undeclared here (not in a function) NF_CT_EXT_NUM=NF_CT_EXT_CUSTOM+CONFIG_NF_CONNTRACK_CUSTOM, ^ make[3]: *** [net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.o] Error 1 make[2]: *** [net/ipv4/netfilter] Error 2 make[1]: *** [net/ipv4] Error 2 make: *** [net] Error 2

Что ему могло не понравиться?

anonymous
()
Ответ на: комментарий от anonymous

Значит либо в результате экспериментов что-то криво проложилось, либо для этого ядра нужен другой патч. Если брал от 3.12, значит его нужно откатить (patch -R) и поставить от 3.10 .

3.11 - мертвая ветка.

Есть патч для 3.4.97...

vel ★★★★★
() автор топика
Ответ на: комментарий от vel

Да ты прав - я откатил мои действия и начал с самого начала и в патч приложился без проблем. У меня в ./config нет NF_CONNTRACK_CUSTOM=2, но есть CONFIG_NF_CONNTRACK_CUSTOM=4 - это одно и тоже? В открывшемся меню по команде make menuconfig нужно что-то менять?

anonymous
()
Ответ на: комментарий от vel

Ядро собралось без проблем. И я не устанавливаю его решил собрать модуль и он возмутился, что нет нудной ему директории:

make -C ipt make[1]: Entering directory `/home/ramadann/nDPI-1.4.0.r7867/ndpi-netfilter/ipt' cc -fPIC -I../include -I../lib -I../src -DOPENDPI_NETFILTER_MODULE -O2 -Wall -D_INIT=libxt_ndpi_init -c -o libxt_ndpi.o libxt_ndpi.c; cc -shared -o libxt_ndpi.so libxt_ndpi.o; rm libxt_ndpi.o make[1]: Leaving directory `/home/ramadann/nDPI-1.4.0.r7867/ndpi-netfilter/ipt' make -C src make[1]: Entering directory `/home/ramadann/nDPI-1.4.0.r7867/ndpi-netfilter/src' make -C /lib/modules/3.11.10-17-desktop/build M=$PWD modules; make: Entering an unknown directory make: *** /lib/modules/3.11.10-17-desktop/build: No such file or directory. Stop. make: Leaving an unknown directory make[1]: *** [modules] Error 2 make[1]: Leaving directory `/home/ramadann/nDPI-1.4.0.r7867/ndpi-netfilter/src' make: *** [all] Error 2

Это в следствии того, что я ядро новое не установил? Иными словами /build появится после установки свежо скомпилированного ядра?

anonymous
()
Ответ на: комментарий от vel

Если не сложно - можешь выложить патчи для более ранних ядер >3.xx? Был бы очень тебе благодарен.

anonymous
()
Ответ на: комментарий от anonymous

да, но если в make-у указать путь к ядру в явном виде, то соберется.

в ndpi-netfilter/src

make modules KERNEL_DIR=....

отдельно выложил патч для 3.4.97. IMHO оно подойдет и любого 3.4

vel ★★★★★
() автор топика
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от vel

Ядро установил. Модуль установил.

iptables -m ndpi -help

выдает:

ndpi match options:
--unknown Match for unknown protocol packets.
--ftp_control Match for ftp_control protocol packets.
--mail_pop Match for mail_pop protocol packets.
--mail_smtp Match for mail_smtp protocol packets.
--mail_imap Match for mail_imap protocol packets.
--dns Match for dns protocol packets.
--ipp Match for ipp protocol packets.
--http Match for http protocol packets.
--mdns Match for mdns protocol packets.
--ntp Match for ntp protocol packets.
--netbios Match for netbios protocol packets.
--nfs Match for nfs protocol packets.
--ssdp Match for ssdp protocol packets.
--bgp Match for bgp protocol packets.
... и так далее 

Но при добавлении правила

iptables -A FORWARD -s 192.168.0.0/24 -m ndpi --bittorrent -j DROP

выдает:

iptables: No chain/target/match by that name.
anonymous
()
Ответ на: комментарий от anonymous

Пытаюсь выполнить:

modprobe xt_ndpi

и получаю:

FATAL: Error inserting xt_ndpi (/lib/modules/3.11.10-17-desktop/extra/xt_ndpi.ko): Invalid argument

в /var/log/messeges вот такая картина:

linux-95gu kernel: [ 2985.832269] xt_ndpi: disagrees about version of symbol nf_ct_extend_unregister
linux-95gu kernel: [ 2985.832274] xt_ndpi: Unknown symbol nf_ct_extend_unregister (err -22)
linux-95gu kernel: [ 2985.832320] xt_ndpi: Unknown symbol nf_ct_extend_custom_register (err 0)
linux-95gu kernel: [ 2985.832331] xt_ndpi: disagrees about version of symbol nf_ct_iterate_cleanup
linux-95gu kernel: [ 2985.832332] xt_ndpi: Unknown symbol nf_ct_iterate_cleanup (err -22)
linux-95gu kernel: [ 2985.832349] xt_ndpi: disagrees about version of symbol __nf_ct_ext_add_length
[ 2985.832350] xt_ndpi: Unknown symbol __nf_ct_ext_add_length (err -22)
anonymous
()
Ответ на: комментарий от anonymous

значит в linux/net/netfilter/nf_conntrack_extend.c нет строки

EXPORT_SYMBOL(__nf_ct_ext_add_length);
(после самой функции)

или что-то криво собралось

vel ★★★★★
() автор топика
Ответ на: комментарий от anonymous

если модуль не загружен - да.

vel ★★★★★
() автор топика
Ответ на: комментарий от vel

EXPORT_SYMBOL(__nf_ct_ext_add_length); эта строка присутствует.

Порекомендуешь что-то?

anonymous
()
Ответ на: комментарий от vel

Решил все по новой начать. Наложил патч - без проблем.

linux-95gu:/home/ramadann/nDPI-1.4.0.r7867/ndpi-netfilter # W=`pwd` ; cd /usr/src/linux; patch -p1 <$W/kernel-patch/v3.10.20.diff
patching file include/net/netfilter/nf_conntrack_extend.h
patching file net/netfilter/Kconfig
patching file net/netfilter/nf_conntrack_acct.c
patching file net/netfilter/nf_conntrack_extend.c
patching file net/netfilter/nf_conntrack_standalone.c

в ./config нашел строчку «CONFIG_NF_CONNTRAVK_CUSTOM=4» - исправил на 2.

сделал make oldconfig

перешел в ndpi-netfilter и выполнил

 make KERNEL_DIR=/usr/src/linux

вывод получил вот такой :

make -C ipt
make[1]: Entering directory `/home/ramadann/nDPI-1.4.0.r7867/ndpi-netfilter/ipt'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/ramadann/nDPI-1.4.0.r7867/ndpi-netfilter/ipt'
make -C src
make[1]: Entering directory `/home/ramadann/nDPI-1.4.0.r7867/ndpi-netfilter/src'
make -C /usr/src/linux M=$PWD modules;
make[2]: Entering directory `/usr/src/linux-3.11.10-17'
  CC [M]  /home/ramadann/nDPI-1.4.0.r7867/ndpi-netfilter/src/main.o
  CC [M]  /home/ramadann/nDPI-1.4.0.r7867/ndpi-netfilter/src/../lib/protocols/../third_party/src/node.o
  CC [M]  /home/ramadann/nDPI-1.4.0.r7867/ndpi-netfilter/src/../lib/protocols/../third_party/src/ahocorasick.o
  CC [M]  /home/ramadann/nDPI-1.4.0.r7867/ndpi-netfilter/src/../lib/ndpi_main.o
/home/ramadann/nDPI-1.4.0.r7867/ndpi-netfilter/src/../lib/ndpi_main.c: In function ‘ndpi_detection_process_packet’:
/home/ramadann/nDPI-1.4.0.r7867/ndpi-netfilter/src/../lib/ndpi_main.c:3631:11: warning: unused variable ‘text’ [-Wunused-variable]
       int text = NDPI_BITMASK_COMPARE(ndpi_struct->callback_buffer_udp[a].detection_bitmask,detection_bitmask);
           ^
  CC [M]  /home/ramadann/nDPI-1.4.0.r7867/ndpi-netfilter/src/../lib/protocols/afp.o
  CC [M]  /home/ramadann/nDPI-1.4.0.r7867/ndpi-netfilter/src/../lib/protocols/aimini.o
 ТУТ ВСЁ ХОРОШО БЫЛО
  CC [M]  /home/ramadann/nDPI-1.4.0.r7867/ndpi-netfilter/src/../lib/protocols/tvuplayer.o
  CC [M]  /home/ramadann/nDPI-1.4.0.r7867/ndpi-netfilter/src/../lib/protocols/twitter.o
/home/ramadann/nDPI-1.4.0.r7867/ndpi-netfilter/src/../lib/protocols/twitter.c:42:2: warning: large integer implicitly truncated to unsigned type [-Woverflow]
  { .addr = IPTOINT(192,133,76,0), .mask=LEN2MASK(22) },
  ^
/home/ramadann/nDPI-1.4.0.r7867/ndpi-netfilter/src/../lib/protocols/twitter.c:43:2: warning: large integer implicitly truncated to unsigned type [-Woverflow]
  { .addr = IPTOINT(199,16,156,0), .mask=LEN2MASK(22) },
  ^
/home/ramadann/nDPI-1.4.0.r7867/ndpi-netfilter/src/../lib/protocols/twitter.c:44:2: warning: large integer implicitly truncated to unsigned type [-Woverflow]
  { .addr = IPTOINT(199,59,148,0), .mask=LEN2MASK(22) },
  ^
/home/ramadann/nDPI-1.4.0.r7867/ndpi-netfilter/src/../lib/protocols/twitter.c:45:2: warning: large integer implicitly truncated to unsigned type [-Woverflow]
  { .addr = IPTOINT(199,96,56,0),  .mask=LEN2MASK(21) }};
  ^
  
  LD [M]  /home/ramadann/nDPI-1.4.0.r7867/ndpi-netfilter/src/xt_ndpi.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /home/ramadann/nDPI-1.4.0.r7867/ndpi-netfilter/src/xt_ndpi.mod.o
  LD [M]  /home/ramadann/nDPI-1.4.0.r7867/ndpi-netfilter/src/xt_ndpi.ko
make[2]: Leaving directory `/usr/src/linux-3.11.10-17'
make[1]: Leaving directory `/home/ramadann/nDPI-1.4.0.r7867/ndpi-netfilter/src'

То что оно ругнулось на:

ndpi_main.c:3631:11: warning: unused variable ‘text’
существенно?

anonymous
()
Ответ на: комментарий от anonymous

нет. Это все предупреждения.

Первое предупреждение и у меня есть, а вот про twitter - сейчас подправлю (long int на x86_64 - 64 бита а не 32 как на i386).

ругань на __nf_ct_ext_add_length можно исправить заменив

return __nf_ct_ext_add_length(ct,nf_ct_ext_id_ndpi,0,GFP_ATOMIC);

на

return __nf_ct_ext_add(ct,nf_ct_ext_id_ndpi,GFP_ATOMIC);

это особенно актуально для 3.4

Вечером обновлю.

vel ★★★★★
() автор топика
Ответ на: комментарий от vel

Исправил и получил:

/home/ramadann/nDPI-1.4.0.r7867/ndpi-netfilter/src/main.c: In function ‘nf_ct_ext_add_ndpi’:
/home/ramadann/nDPI-1.4.0.r7867/ndpi-netfilter/src/main.c:264:2: error: implicit declaration of function ‘__nf_ct_ext_add’ [-Werror=implicit-function       -declaration]
  return __nf_ct_ext_add(ct,nf_ct_ext_id_ndpi,GFP_ATOMIC);
  ^
/home/ramadann/nDPI-1.4.0.r7867/ndpi-netfilter/src/main.c:264:2: warning: return makes pointer from integer without a cast [enabled by default]
cc1: some warnings being treated as errors
anonymous
()
Ответ на: комментарий от anonymous

Значит у тебя где-то в системе есть неправильный «nf_conntrack_extend.h»

__nf_ct_ext_add в ядрах 3.4

__nf_ct_ext_add_length в ядрах >= 3.10

У меня в ядре __nf_ct_ext_add упоминается в 2-х файлах

vel@sdo:/usr/src/kts/linux $ grep -sIR __nf_ct_ext_add
include/net/netfilter/nf_conntrack_extend.h:__nf_ct_ext_add(struct nf_conn *ct, enum nf_ct_ext_id id, gfp_t gfp);
include/net/netfilter/nf_conntrack_extend.h:    ((id##_TYPE *)__nf_ct_ext_add((ct), (id), (gfp)))
net/netfilter/nf_conntrack_extend.c:void *__nf_ct_ext_add(struct nf_conn *ct, enum nf_ct_ext_id id, gfp_t gfp)
net/netfilter/nf_conntrack_extend.c:EXPORT_SYMBOL(__nf_ct_ext_add);
net/netfilter/nf_conntrack_extend.h инклюдится в main.c, т.ч. отсутствие прототипа этой функции невозможно.

В /usr/include/* nf_conntrack_extend.h такого файла быть не должно!

Вообще, я всегда после изменений ядра делаю «make headers_install», делаю из них пакет и обновляю его в системе.

Версия gcc какая ? Я пока на 4.6,4.7.

vel ★★★★★
() автор топика
Последнее исправление: vel (всего исправлений: 2)
Ответ на: комментарий от vel

gcc ver 4.8-2.1.2 мм так у меня же ядро 3.11.10-17.

 grep -sIR __nf_ct_ext_add
include/net/netfilter/nf_conntrack_extend.h:void *__nf_ct_ext_add_length(struct nf_conn *ct, enum nf_ct_ext_id id,
include/net/netfilter/nf_conntrack_extend.h:    ((id##_TYPE *)__nf_ct_ext_add_length((ct), (id), 0, (gfp)))
include/net/netfilter/nf_conntrack_extend.h:    ((id##_TYPE *)__nf_ct_ext_add_length((ct), (id), (len), (gfp)))
include/net/netfilter/nf_conntrack_extend.h.orig:void *__nf_ct_ext_add_length(struct nf_conn *ct, enum nf_ct_ext_id id,
include/net/netfilter/nf_conntrack_extend.h.orig:       ((id##_TYPE *)__nf_ct_ext_add_length((ct), (id), 0, (gfp)))
include/net/netfilter/nf_conntrack_extend.h.orig:       ((id##_TYPE *)__nf_ct_ext_add_length((ct), (id), (len), (gfp)))
Module.symvers:0x6bff899c       __nf_ct_ext_add_length  net/netfilter/nf_conntrack      EXPORT_SYMBOL
net/netfilter/nf_conntrack_extend.c.orig:void *__nf_ct_ext_add_length(struct nf_conn *ct, enum nf_ct_ext_id id,
net/netfilter/nf_conntrack_extend.c.orig:EXPORT_SYMBOL(__nf_ct_ext_add_length);
net/netfilter/nf_conntrack_extend.c:void *__nf_ct_ext_add_length(struct nf_conn *ct, enum nf_ct_ext_id id,
net/netfilter/nf_conntrack_extend.c:EXPORT_SYMBOL(__nf_ct_ext_add_length);
anonymous
()
Ответ на: комментарий от anonymous

Бр....

xt_ndpi: Unknown symbol __nf_ct_ext_add_length

тогда такого сообщения не должно быть - «__nf_ct_ext_add_length» - экспортируемая глобальная функция. А ядро загружено какое ?

vel ★★★★★
() автор топика
Ответ на: комментарий от vel
# uname -a
Linux linux-95gu 3.11.10-17-desktop #1 SMP PREEMPT Wed Jul 9 22:45:19 EEST 2014 x86_64 x86_64 x86_64 GNU/Linux
anonymous
()
Ответ на: комментарий от anonymous

Хорошая ссылка. У меня слака и проблемы остальных мне неизвестны.

Я выложил обновления и комменты к ним.

vel ★★★★★
() автор топика
Ответ на: комментарий от vel

при попытке пропатчить ядро 3.14.5 патчем из ndpi ревизии 7867 выдал режект:

linux-vrfz:/usr/src/linux # patch -p1 < ../nDPI-1.4.0.r7867/ndpi-netfilter/kernel-patch/v3.14.2.diff
patching file include/net/netfilter/nf_conntrack_extend.h
Hunk #2 FAILED at 48.
1 out of 4 hunks FAILED -- saving rejects to file include/net/netfilter/nf_conntrack_extend.h.rej
patching file net/netfilter/Kconfig
patching file net/netfilter/nf_conntrack_acct.c
patching file net/netfilter/nf_conntrack_extend.c
patching file net/netfilter/nf_conntrack_standalone.c
anonymous
()
Ответ на: комментарий от anonymous

а вот сам режект:

--- include/net/netfilter/nf_conntrack_extend.h
+++ include/net/netfilter/nf_conntrack_extend.h
@@ -48,8 +49,8 @@
 /* Extensions: optional stuff which isn't permanently in struct. */
 struct nf_ct_ext {
        struct rcu_head rcu;
-       u8 offset[NF_CT_EXT_NUM];
-       u8 len;
+       u16 offset[NF_CT_EXT_NUM];
+       u16 len;
        char data[0];
 };
anonymous
()
Ответ на: комментарий от anonymous

с 3.14.5 эта правка стала в официальной ветке.

vel ★★★★★
() автор топика
Ответ на: комментарий от anonymous

От 3.0 до 3.4 изменения сетевого стека и netfilter были незначительные.

в патче для 3.4.97 надо заменить RCU_INIT_POINTER на rcu_assign_pointer.

В принципе оно собирается. Но надо проверять работоспособность.

vel ★★★★★
() автор топика
Ответ на: комментарий от vel

Торренты дают большой процент неопределенного трафика из-за неудачных попыток установления соединения и шифрования :(

Это значит, что nDPI не сможет блокировать полностью torrent? А если в связке с ipp2p его применить?

Еще хотел уточнить у тебя: я заглянул на https://github.com/ewildgoose/ndpi-netfilter и там единственный патч hack-conntrack-events.patch и он для ядер до 3.х, я правильно понял?

anonymous
()
Ответ на: комментарий от anonymous

Я проводил небольшой эксперимент над машиной где кроме торрентов больше ничего небыло. Много tcp syn без ответа.

Traffic statistics:
        Ethernet bytes:        29260813      (includes ethernet CRC/IFC/trailer)
        Discarded bytes:       68052
        IP packets:            86150         of 87434 packets total
        IP bytes:              27193213      (avg pkt size 311 bytes)
        Unique flows:          11091
        TCP Packets:           14835
        UDP Packets:           70202
        Max Packet size:       2928
        Packet Len < 64:       34677
        Packet Len 64-128:     20736
        Packet Len 128-256:    5604
        Packet Len 256-1024:   14893
        Packet Len 1024-1500:  10219
        Packet Len > 1500:     21
        nDPI throughput:       372.85 K pps / 966.16 Mb/sec
        Guessed flow protos:   23


Detected protocols:
        Unknown              packets: 12416         bytes: 8337629       flows: 2021
        DNS                  packets: 222           bytes: 24856         flows: 111
        HTTP                 packets: 177           bytes: 22499         flows: 17
        BitTorrent           packets: 72149         bytes: 18662662      flows: 8710
        ICMP                 packets: 1113          bytes: 134340        flows: 204
        SSL                  packets: 14            bytes: 826           flows: 7
        HTTP_Proxy           packets: 13            bytes: 840           flows: 6

Unknown 30%

Эти же 2 торрента, но без шифрования

Traffic statistics:
        Ethernet bytes:        28395621      (includes ethernet CRC/IFC/trailer)
        Discarded bytes:       16324
        IP packets:            38946         of 39254 packets total
        IP bytes:              27460917      (avg pkt size 699 bytes)
        Unique flows:          1443
        TCP Packets:           3821
        UDP Packets:           34822
        Max Packet size:       4376
        Packet Len < 64:       15572
        Packet Len 64-128:     4154
        Packet Len 128-256:    690
        Packet Len 256-1024:   1314
        Packet Len 1024-1500:  17069
        Packet Len > 1500:     147
        nDPI throughput:       183.97 K pps / 1023.38 Mb/sec
        Guessed flow protos:   6

Detected protocols:
        Unknown              packets: 105           bytes: 8153          flows: 104
        DNS                  packets: 165           bytes: 20522         flows: 83
        HTTP                 packets: 107           bytes: 13212         flows: 9
        BitTorrent           packets: 35622         bytes: 26640881      flows: 1133
        ICMP                 packets: 303           bytes: 34782         flows: 104

Есть разница!

https://github.com/ewildgoose/ndpi-netfilter - первоисточник, который я попробовал подправить для актуальных версий nDPI & kernel. Он непригоден для работы. Очень странный патч (безумный хак с колбеками), memory leak и ребуты в непонятный момент (похоже из-за неправильных блокировок), неправильная логика работы с nDPI.

Полгода назад я написал этому чуваку, что есть версия для новых ядер и nDPI, но кроме ответа «посмотрю когда будет время» больше ничего не случилось.

vel ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Полностью заблокировать BT средствами только nDPI нельзя.

Нужно анализировать трафик определенный как BT, выявлять в нем трекеры и блокировать обмен с ними. В этом может помочь snort, в который можно отдать через NQUEUE/NFLOG обнаруженный BT трафик для дальнейшего анализа и добавления в ipset proto:ip:port.

vel ★★★★★
() автор топика
Ответ на: комментарий от vel

Жаль конечно, что первоисточник заброшен. Так значит ndpi-netfilter и патчи, что выложены у тебя твоего личного производства?

anonymous
()
Ответ на: комментарий от anonymous

да

Причина достаточно проста - l7filter развиваться перестал, а может искать данные только по строкам/регекспам. Нет связи между разными потоками. С одной стророны это универсальное средство блокировки по содержанию, но для определения сложных протоколов оно не подходит.

Других проектов кроме nDPI - нет. Поскольку хаком сетевой части ядра приходилось заниматься аж с 1995, то дописать очередное расширение было несложно, там более, что 2 важных момента ( инициализация разных структур и работа с ndpi_node_ip ) в https://github.com/ewildgoose/ndpi-netfilter была сделана правильно. Он не смог подружить nDPI с nf_conntrack и упустил некоторые важные моменты.

А для борьбы с BT IMHO нужно выделить в отдельный протокол передачу данных с трекера, его данные передавать в userspace, там отпарсить их, выделить адреса и порты сидеров и блокировать обмен с ними у линчеру. На сколько я понял, передача между трекером и клиентом не шифруется, а шифруется обмен между седером/линчером.

vel ★★★★★
() автор топика
Ответ на: комментарий от vel

Мне все не дает покоя проблема блокировки ВТ.

С помощью:

iptables -A FORWARD -m ndpi --bittirrent -j NFQUEUE --queue-num 2

я передаю интересующий меня трафик в очередь 2 снорт проверяет эту очередь:

snort -Q --daq nfq --daq-var queue=2 -c ../etc/snort.conf -l /var/log/snort -A full

в snort.conf подключаю правила

include $RULE_PATH/test.rules

и вот то что я не пойму:

reject tcp any any -> any any (msg:"Test pattern for snort abc123"; content:"abc123"; classtype:shellcode-detect; sid:310; rev:1;)
Это правило говорит, что в случае обнаружения во входящих tcp пакетах подстроки abc123, то источнику немедленно будет послан RST, и сеанс будет прерван.

Это вариант со строкой «abc123», а как «научить» снорт понимать, что это торрент

anonymous
()
Ответ на: комментарий от anonymous

гм. К снорту надо писать плагин для разбора обмена между трекером и клиентами. Трекер сообщает клиенту список адресов и портов других клиентов. Попытки обращения к ним этим адресам/портам можно идентифицировать как BT без анализа данных.

С трекерами обмен идет не только по tcp, но и по udp!

К снорту есть отдельный набор правил для BT http://www.sans.org/reading-room/whitepapers/detection/detecting-torrents-sno... . IMHO Они как раз определяют обмен с трекером. Неплохое описание формата данных BT есть на https://wiki.theory.org/BitTorrentSpecification

С другой стороны, если блокировать общение с трекером, то дальше клиент уже ничего не сможет сделать.

IMHO самое простое, это разбить в nDPI протокол BT на 2 части - BT-tracker & BT-peer.

BT-tracker (это небольшой объем данных) скармливать в userspace, парсить и добавлять адреса/порты для блокировки/идентификации, собирать статистику по трекерам/пирам.

vel ★★★★★
() автор топика
Ответ на: комментарий от anonymous

А все)))) Это у меня файл xtables.h был пустой внутри. Перезалил его и собралось) ща закончу с этим ядром и проверю на 3,4 ядре

anonymous
()
Ответ на: комментарий от vel

хм. теперь все собралось, все подгрузилось, но

 iptables -m ndpi -help
iptables v1.4.19.1: Couldn't load match `ndpi':No such file or directory
Try `iptables -h' or 'iptables --help' for more information.

хотя lsmod | grep xt_ndpi говорит:

xt_ndpi               353345  0
x_tables               29963  1 xt_ndpi
nf_conntrack           93887  1 xt_ndpi

anonymous
()
Ответ на: комментарий от anonymous

«make install» сказал в ndpi-netfilter ?

Есть пара вариантов

1) iptables слинкован статически и он вообще не ищет модули

2) «pkg-config --variable=xtlibdir xtables» выдает неправильный путь.

Оба варианта проверяются через

strace -e stat,stat64 iptables -m ndpi --help >/dev/zero

xt_ndpi.so должен лежать там, где его ищут.

vel ★★★★★
() автор топика
Ответ на: комментарий от vel
linux-vrfz:/usr/src/linux # strace -e stat,stat64 iptables -m ndpi --help >/dev/zero
stat("/usr/lib64/xtables/libxt_ndpi.so", 0x7fff6cc59170) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/xtables/libipt_ndpi.so", 0x7fff6cc59170) = -1 ENOENT (No such file or directory)
iptables v1.4.19.1: Couldn't load match `ndpi':No such file or directory

Try `iptables -h' or 'iptables --help' for more information.
+++ exited with 2 +++

libxt_ndpi.so я положил в usr/lib64/xtables/, а вот libipt_ndpi.so я что-то не нахожу

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.