форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Программирование под UNIX (Public)
Изначальное сообщение		[Проследить за развитием треда]

"Обработка сетевых пакетов ядром Linux"

Сообщение от Gekt0r (??) on 09-Апр-07, 16:57

Затрудняюсь, в каком разделе создавать топик, создам здесь, так как он связан с кодингом. При поступлении сетевого пакета в ОС Linux он сохраняется в каком-то буфере в ядре до обработки фаерволлом. Вопрос: можем ли мы получить доступ к этому буферу и пакетам в нем? Каким функциями это можно сделать? И вообще, где можно про это почитать? Пол-инета облазил, нашел пару более менее путных статей, но там мало...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Сообщения по теме

[Сортировка по времени, UBB]

1. "Обработка сетевых пакетов ядром Linux"

Сообщение от pavel_simple (ok) on 09-Апр-07, 20:56

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	2. "Обработка сетевых пакетов ядром Linux"
	Сообщение от gekt0r on 09-Апр-07, 22:10
	>если очень хочеться менять/считать/ещё.. что нибудь делать с пакетами -- то самый >верный путь это libipq -- она устарела, и сейчас нужно юзать >libconntrack_ipq Насчет  libconntrack_ipq и Яндекс, и Гугл молчат... А что касается libipq, это, кажется, какая-то утилита уровня пользователя? А мне нужно получить доступ именно к функциям ядра
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	3. "Обработка сетевых пакетов ядром Linux"
	Сообщение от pavel_simple (ok) on 09-Апр-07, 23:20
	netfilter.org смотри -- вот если вопрос в обработке пакетов, до firewall'а -- то я правильный путь показываю, и да это в юзерспейсе обрабатывается, а перехватывается ядром. libconntrack_queue она называется -- обшибся немного. а если есть дикое желание написать именно какой-нибудь модуль ядра -- то, как говориться бог в помощь -- я тут подсказать ни чем не могу.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	5. "Обработка сетевых пакетов ядром Linux"
	Сообщение от Gekt0r (??) on 10-Апр-07, 16:24
	>netfilter.org смотри -- вот если вопрос в обработке пакетов, до firewall'а -- >то я правильный путь показываю, и да это в юзерспейсе обрабатывается, >а перехватывается ядром. > >libconntrack_queue она называется -- обшибся немного. > >а если есть дикое желание написать именно какой-нибудь модуль ядра -- то, >как говориться бог в помощь -- я тут подсказать ни чем >не могу. libconntrack_queue тоже в гугле нет... Да, мне нужна именно обработка пакетов до их анализа netfilter. Это вообще возможно?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	10. "Обработка сетевых пакетов ядром Linux"
	Сообщение от perece on 10-Апр-07, 21:21
	>>netfilter.org смотри -- вот если вопрос в обработке пакетов, до firewall'а -- >>то я правильный путь показываю, и да это в юзерспейсе обрабатывается, >>а перехватывается ядром. >> >>libconntrack_queue она называется -- обшибся немного. >> >>а если есть дикое желание написать именно какой-нибудь модуль ядра -- то, >>как говориться бог в помощь -- я тут подсказать ни чем >>не могу. > > >libconntrack_queue тоже в гугле нет... >Да, мне нужна именно обработка пакетов до их анализа netfilter. Это вообще >возможно? до анализа...iptables, осмелюсь предположить? iptables != netfilter можно добавить свой модуль netfilter и зацепить за prerouting и output до всех модулей iptables. это не то, что нужно? возможно, вам сюда: http://www.iptables.org/documentation/HOWTO/netfilter-hacking-HOWTO.html (google netfilter hacking howto - первая ссылка) \^P^/
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Обработка сетевых пакетов ядром Linux"

Сообщение от int_0dh on 10-Апр-07, 00:04

>Затрудняюсь, в каком разделе создавать топик, создам здесь, так как он связан >с кодингом. >При поступлении сетевого пакета в ОС Linux он сохраняется в каком-то буфере >в ядре до обработки фаерволлом. Вопрос: можем ли мы получить доступ >к этому буферу и пакетам в нем? Каким функциями это можно >сделать? И вообще, где можно про это почитать? >Пол-инета облазил, нашел пару более менее путных статей, но там мало... 1) Если я правильно понял вопрос, то существует ровно 2 способа из ядра - зарегистрировать свою packet_type структуру с нужным proto id - мы будем получать пакет в коллбеке Выглядит это примерно так: ... int my_rcv_callback(struct sk_buff *skb, /* это наш пакет */, struct net_device *dev, struct packet_type *pt) {   ...что нибудь сделать с пакетом...   return 1/0; - мы не/приняли пакет } .... struct packet_type my_packet_type = { __constant_htons(НУЖНЫЙ_ПРОТО_ИД),   NULL,   my_rcv_callback,   NULL,   NULL }; ... int module_init() { ....dev_add_pack(&my_packet_type); ... } ну и т п. 2) способ - из userspace - использовать PF_PACKET сокеты с ETH_P_ALL. Если ядро умеет - их можно отмапить. Вообще чума будет.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	6. "Обработка сетевых пакетов ядром Linux"
	Сообщение от Gekt0r (??) on 10-Апр-07, 16:27
	>>Затрудняюсь, в каком разделе создавать топик, создам здесь, так как он связан >>с кодингом. >>При поступлении сетевого пакета в ОС Linux он сохраняется в каком-то буфере >>в ядре до обработки фаерволлом. Вопрос: можем ли мы получить доступ >>к этому буферу и пакетам в нем? Каким функциями это можно >>сделать? И вообще, где можно про это почитать? >>Пол-инета облазил, нашел пару более менее путных статей, но там мало... > >1) Если я правильно понял вопрос, то существует ровно 2 способа >из ядра - зарегистрировать свою packet_type структуру с нужным proto id - >мы будем получать пакет в коллбеке >Выглядит это примерно так: >... >int my_rcv_callback(struct sk_buff *skb, /* это наш пакет */, struct net_device *dev, >struct packet_type *pt) >{ >  ...что нибудь сделать с пакетом... >  return 1/0; - мы не/приняли пакет >} > .... > struct packet_type my_packet_type = >{ __constant_htons(НУЖНЫЙ_ПРОТО_ИД), >  NULL, >  my_rcv_callback, >  NULL, >  NULL >}; >... >int module_init() { > ....dev_add_pack(&my_packet_type); > ... >} ну и т п. > >2) способ - из userspace - использовать PF_PACKET сокеты с ETH_P_ALL. Если >ядро умеет - их можно отмапить. Вообще чума будет. А можно подробней? Что за proto id? И callback? Можете какой-нибудь док посоветовать?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	7. "Обработка сетевых пакетов ядром Linux"
	Сообщение от Doka (??) on 10-Апр-07, 17:52
	Можете какой-нибудь док >посоветовать? RAW ethernet например документации море
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	8. "Обработка сетевых пакетов ядром Linux"
	Сообщение от Gekt0r (??) on 10-Апр-07, 18:03
	>>Затрудняюсь, в каком разделе создавать топик, создам здесь, так как он связан >>с кодингом. >>При поступлении сетевого пакета в ОС Linux он сохраняется в каком-то буфере >>в ядре до обработки фаерволлом. Вопрос: можем ли мы получить доступ >>к этому буферу и пакетам в нем? Каким функциями это можно >>сделать? И вообще, где можно про это почитать? >>Пол-инета облазил, нашел пару более менее путных статей, но там мало... > >1) Если я правильно понял вопрос, то существует ровно 2 способа >из ядра - зарегистрировать свою packet_type структуру с нужным proto id - >мы будем получать пакет в коллбеке >Выглядит это примерно так: >... >int my_rcv_callback(struct sk_buff *skb, /* это наш пакет */, struct net_device *dev, >struct packet_type *pt) >{ >  ...что нибудь сделать с пакетом... >  return 1/0; - мы не/приняли пакет >} > .... > struct packet_type my_packet_type = >{ __constant_htons(НУЖНЫЙ_ПРОТО_ИД), >  NULL, >  my_rcv_callback, >  NULL, >  NULL >}; >... >int module_init() { > ....dev_add_pack(&my_packet_type); > ... >} ну и т п. > >2) способ - из userspace - использовать PF_PACKET сокеты с ETH_P_ALL. Если >ядро умеет - их можно отмапить. Вообще чума будет. Все, с первым способом я фактически разобрался. Если найду способ в своей функции-обработчике убивать пакеты, чтобы онм не шли дальше, то это будет именно то, что мне нужно))
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	9. "Обработка сетевых пакетов ядром Linux"
	Сообщение от int_0dh on 10-Апр-07, 19:44
	>>>Затрудняюсь, в каком разделе создавать топик, создам здесь, так как он связан >>>с кодингом. >>>При поступлении сетевого пакета в ОС Linux он сохраняется в каком-то буфере >>>в ядре до обработки фаерволлом. Вопрос: можем ли мы получить доступ >>>к этому буферу и пакетам в нем? Каким функциями это можно >>>сделать? И вообще, где можно про это почитать? >>>Пол-инета облазил, нашел пару более менее путных статей, но там мало... >> >>1) Если я правильно понял вопрос, то существует ровно 2 способа >>из ядра - зарегистрировать свою packet_type структуру с нужным proto id - >>мы будем получать пакет в коллбеке >>Выглядит это примерно так: >>... >>int my_rcv_callback(struct sk_buff *skb, /* это наш пакет */, struct net_device *dev, >>struct packet_type *pt) >>{ >>  ...что нибудь сделать с пакетом... >>  return 1/0; - мы не/приняли пакет >>} >> .... >> struct packet_type my_packet_type = >>{ __constant_htons(НУЖНЫЙ_ПРОТО_ИД), >>  NULL, >>  my_rcv_callback, >>  NULL, >>  NULL >>}; >>... >>int module_init() { >> ....dev_add_pack(&my_packet_type); >> ... >>} ну и т п. >> >>2) способ - из userspace - использовать PF_PACKET сокеты с ETH_P_ALL. Если >>ядро умеет - их можно отмапить. Вообще чума будет. > > >Все, с первым способом я фактически разобрался. Если найду способ в своей >функции-обработчике убивать пакеты, чтобы онм не шли дальше, то это будет >именно то, что мне нужно)) это очень просто. твой обработчик будет первый в цепочке => чтобы пакет не пошёл дальше его нужно испортить (например так - memset(skb->data, 0, skb->len), skb будет освобождена в следующем обработчике.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	11. "Обработка сетевых пакетов ядром Linux"
	Сообщение от Gekt0r (ok) on 11-Апр-07, 10:03
	>>>>Затрудняюсь, в каком разделе создавать топик, создам здесь, так как он связан >>>>с кодингом. >>>>При поступлении сетевого пакета в ОС Linux он сохраняется в каком-то буфере >>>>в ядре до обработки фаерволлом. Вопрос: можем ли мы получить доступ >>>>к этому буферу и пакетам в нем? Каким функциями это можно >>>>сделать? И вообще, где можно про это почитать? >>>>Пол-инета облазил, нашел пару более менее путных статей, но там мало... >>> >>>1) Если я правильно понял вопрос, то существует ровно 2 способа >>>из ядра - зарегистрировать свою packet_type структуру с нужным proto id - >>>мы будем получать пакет в коллбеке >>>Выглядит это примерно так: >>>... >>>int my_rcv_callback(struct sk_buff *skb, /* это наш пакет */, struct net_device *dev, >>>struct packet_type *pt) >>>{ >>>  ...что нибудь сделать с пакетом... >>>  return 1/0; - мы не/приняли пакет >>>} >>> .... >>> struct packet_type my_packet_type = >>>{ __constant_htons(НУЖНЫЙ_ПРОТО_ИД), >>>  NULL, >>>  my_rcv_callback, >>>  NULL, >>>  NULL >>>}; >>>... >>>int module_init() { >>> ....dev_add_pack(&my_packet_type); >>> ... >>>} ну и т п. >>> >>>2) способ - из userspace - использовать PF_PACKET сокеты с ETH_P_ALL. Если >>>ядро умеет - их можно отмапить. Вообще чума будет. >> >> >>Все, с первым способом я фактически разобрался. Если найду способ в своей >>функции-обработчике убивать пакеты, чтобы онм не шли дальше, то это будет >>именно то, что мне нужно)) >это очень просто. твой обработчик будет первый в цепочке => чтобы пакет не пошёл дальше его нужно испортить (например так - memset(skb->data, 0, skb->len), skb будет освобождена в следующем обработчике. Ты даже не представляешь, насколько не помог)) Фактически дал пищу третьей главе моего диплома)) Спасибо большое) Жаль только для исходящих пакетов такой обход фаерволла не действует(
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	12. "Обработка сетевых пакетов ядром Linux"
	Сообщение от Gekt0r (ok) on 11-Апр-07, 11:48
	>>>>Затрудняюсь, в каком разделе создавать топик, создам здесь, так как он связан >>>>с кодингом. >>>>При поступлении сетевого пакета в ОС Linux он сохраняется в каком-то буфере >>>>в ядре до обработки фаерволлом. Вопрос: можем ли мы получить доступ >>>>к этому буферу и пакетам в нем? Каким функциями это можно >>>>сделать? И вообще, где можно про это почитать? >>>>Пол-инета облазил, нашел пару более менее путных статей, но там мало... >>> >>>1) Если я правильно понял вопрос, то существует ровно 2 способа >>>из ядра - зарегистрировать свою packet_type структуру с нужным proto id - >>>мы будем получать пакет в коллбеке >>>Выглядит это примерно так: >>>... >>>int my_rcv_callback(struct sk_buff *skb, /* это наш пакет */, struct net_device *dev, >>>struct packet_type *pt) >>>{ >>>  ...что нибудь сделать с пакетом... >>>  return 1/0; - мы не/приняли пакет >>>} >>> .... >>> struct packet_type my_packet_type = >>>{ __constant_htons(НУЖНЫЙ_ПРОТО_ИД), >>>  NULL, >>>  my_rcv_callback, >>>  NULL, >>>  NULL >>>}; >>>... >>>int module_init() { >>> ....dev_add_pack(&my_packet_type); >>> ... >>>} ну и т п. >>> >>>2) способ - из userspace - использовать PF_PACKET сокеты с ETH_P_ALL. Если >>>ядро умеет - их можно отмапить. Вообще чума будет. >> >> >>Все, с первым способом я фактически разобрался. Если найду способ в своей >>функции-обработчике убивать пакеты, чтобы онм не шли дальше, то это будет >>именно то, что мне нужно)) >это очень просто. твой обработчик будет первый в цепочке => чтобы пакет не пошёл дальше его нужно испортить (например так - memset(skb->data, 0, skb->len), skb будет освобождена в следующем обработчике. Кстати, а в исходящих пакетах можно таким образом, к примеру, менять ip адрес получателя? Вот так, например: skb->nh.iph->daddr=my_address Ведь если наш обработчик стоит в самом начале, то по сути можно перенаправлять пакеты куда мы хотим
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "Обработка сетевых пакетов ядром Linux"
	Сообщение от pavel_simple (ok) on 11-Апр-07, 12:18
	рыбяты -- а поделитесь сцылками пожалуйста.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	14. "Обработка сетевых пакетов ядром Linux"
	Сообщение от Gekt0r (ok) on 11-Апр-07, 12:21
	>рыбяты -- а поделитесь сцылками пожалуйста. ссылками на что конкретно? То, на что меня натолкнул int_0dh, я нашел вот в этой статье: http://www.hackzona.ru/hz.php?name=News&file=print&sid=2263 И отчасти вот тут: https://www.opennet.ru/base/sec/p55-12.txt.html
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	15. "Обработка сетевых пакетов ядром Linux"
	Сообщение от pavel_simple (ok) on 11-Апр-07, 13:35
	спасибо.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	16. "Обработка сетевых пакетов ядром Linux"
	Сообщение от int_0d on 11-Апр-07, 19:59
	>>>>>Затрудняюсь, в каком разделе создавать топик, создам здесь, так как он связан >>>>>с кодингом. >>>>>При поступлении сетевого пакета в ОС Linux он сохраняется в каком-то буфере >>>>>в ядре до обработки фаерволлом. Вопрос: можем ли мы получить доступ >>>>>к этому буферу и пакетам в нем? Каким функциями это можно >>>>>сделать? И вообще, где можно про это почитать? >>>>>Пол-инета облазил, нашел пару более менее путных статей, но там мало... >>>> >>>>1) Если я правильно понял вопрос, то существует ровно 2 способа >>>>из ядра - зарегистрировать свою packet_type структуру с нужным proto id - >>>>мы будем получать пакет в коллбеке >>>>Выглядит это примерно так: >>>>... >>>>int my_rcv_callback(struct sk_buff *skb, /* это наш пакет */, struct net_device *dev, >>>>struct packet_type *pt) >>>>{ >>>>  ...что нибудь сделать с пакетом... >>>>  return 1/0; - мы не/приняли пакет >>>>} >>>> .... >>>> struct packet_type my_packet_type = >>>>{ __constant_htons(НУЖНЫЙ_ПРОТО_ИД), >>>>  NULL, >>>>  my_rcv_callback, >>>>  NULL, >>>>  NULL >>>>}; >>>>... >>>>int module_init() { >>>> ....dev_add_pack(&my_packet_type); >>>> ... >>>>} ну и т п. >>>> >>>>2) способ - из userspace - использовать PF_PACKET сокеты с ETH_P_ALL. Если >>>>ядро умеет - их можно отмапить. Вообще чума будет. >>> >>> >>>Все, с первым способом я фактически разобрался. Если найду способ в своей >>>функции-обработчике убивать пакеты, чтобы онм не шли дальше, то это будет >>>именно то, что мне нужно)) >>это очень просто. твой обработчик будет первый в цепочке => чтобы пакет не пошёл дальше его нужно испортить (например так - memset(skb->data, 0, skb->len), skb будет освобождена в следующем обработчике. > >Кстати, а в исходящих пакетах можно таким образом, к примеру, менять ip >адрес получателя? >Вот так, например: >skb->nh.iph->daddr=my_address >Ведь если наш обработчик стоит в самом начале, то по сути можно >перенаправлять пакеты куда мы хотим в исходящих нельзя. это коллбек на input, с исходящими  до файервола нужно хучить ip_queue_xmit, что некрасиво. можно правда определить свою qdisc и менять адрес в её  коллбеке. можно и ище кой-чего :) в src/net все есть.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	17. "Обработка сетевых пакетов ядром Linux"
	Сообщение от gekt0r on 11-Апр-07, 21:31
	>>>>>>Затрудняюсь, в каком разделе создавать топик, создам здесь, так как он связан >>>>>>с кодингом. >>>>>>При поступлении сетевого пакета в ОС Linux он сохраняется в каком-то буфере >>>>>>в ядре до обработки фаерволлом. Вопрос: можем ли мы получить доступ >>>>>>к этому буферу и пакетам в нем? Каким функциями это можно >>>>>>сделать? И вообще, где можно про это почитать? >>>>>>Пол-инета облазил, нашел пару более менее путных статей, но там мало... >>>>> >>>>>1) Если я правильно понял вопрос, то существует ровно 2 способа >>>>>из ядра - зарегистрировать свою packet_type структуру с нужным proto id - >>>>>мы будем получать пакет в коллбеке >>>>>Выглядит это примерно так: >>>>>... >>>>>int my_rcv_callback(struct sk_buff *skb, /* это наш пакет */, struct net_device *dev, >>>>>struct packet_type *pt) >>>>>{ >>>>>  ...что нибудь сделать с пакетом... >>>>>  return 1/0; - мы не/приняли пакет >>>>>} >>>>> .... >>>>> struct packet_type my_packet_type = >>>>>{ __constant_htons(НУЖНЫЙ_ПРОТО_ИД), >>>>>  NULL, >>>>>  my_rcv_callback, >>>>>  NULL, >>>>>  NULL >>>>>}; >>>>>... >>>>>int module_init() { >>>>> ....dev_add_pack(&my_packet_type); >>>>> ... >>>>>} ну и т п. >>>>> >>>>>2) способ - из userspace - использовать PF_PACKET сокеты с ETH_P_ALL. Если >>>>>ядро умеет - их можно отмапить. Вообще чума будет. >>>> >>>> >>>>Все, с первым способом я фактически разобрался. Если найду способ в своей >>>>функции-обработчике убивать пакеты, чтобы онм не шли дальше, то это будет >>>>именно то, что мне нужно)) >>>это очень просто. твой обработчик будет первый в цепочке => чтобы пакет не пошёл дальше его нужно испортить (например так - memset(skb->data, 0, skb->len), skb будет освобождена в следующем обработчике. >> >>Кстати, а в исходящих пакетах можно таким образом, к примеру, менять ip >>адрес получателя? >>Вот так, например: >>skb->nh.iph->daddr=my_address >>Ведь если наш обработчик стоит в самом начале, то по сути можно >>перенаправлять пакеты куда мы хотим > >в исходящих нельзя. это коллбек на input, с исходящими  до файервола >нужно хучить ip_queue_xmit, что некрасиво. можно правда определить свою qdisc и >менять адрес в её  коллбеке. можно и ище кой-чего :) >в src/net все есть. а можно ли как-то зарегить обработчик исходящих пакетов после всех остальных функций-обработчиков, фаерволла в том числе. Так, чтобы фаер получал легитимный исходящий траффик, пропускал его, а потом наша функция изменяла пакеты как нам хочется?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	18. "Обработка сетевых пакетов ядром Linux"
	Сообщение от int_0d on 12-Апр-07, 00:16
	>>>>>>>Затрудняюсь, в каком разделе создавать топик, создам здесь, так как он связан >>>>>>>с кодингом. >>>>>>>При поступлении сетевого пакета в ОС Linux он сохраняется в каком-то буфере >>>>>>>в ядре до обработки фаерволлом. Вопрос: можем ли мы получить доступ >>>>>>>к этому буферу и пакетам в нем? Каким функциями это можно >>>>>>>сделать? И вообще, где можно про это почитать? >>>>>>>Пол-инета облазил, нашел пару более менее путных статей, но там мало... >>>>>> >>>>>>1) Если я правильно понял вопрос, то существует ровно 2 способа >>>>>>из ядра - зарегистрировать свою packet_type структуру с нужным proto id - >>>>>>мы будем получать пакет в коллбеке >>>>>>Выглядит это примерно так: >>>>>>... >>>>>>int my_rcv_callback(struct sk_buff *skb, /* это наш пакет */, struct net_device *dev, >>>>>>struct packet_type *pt) >>>>>>{ >>>>>>  ...что нибудь сделать с пакетом... >>>>>>  return 1/0; - мы не/приняли пакет >>>>>>} >>>>>> .... >>>>>> struct packet_type my_packet_type = >>>>>>{ __constant_htons(НУЖНЫЙ_ПРОТО_ИД), >>>>>>  NULL, >>>>>>  my_rcv_callback, >>>>>>  NULL, >>>>>>  NULL >>>>>>}; >>>>>>... >>>>>>int module_init() { >>>>>> ....dev_add_pack(&my_packet_type); >>>>>> ... >>>>>>} ну и т п. >>>>>> >>>>>>2) способ - из userspace - использовать PF_PACKET сокеты с ETH_P_ALL. Если >>>>>>ядро умеет - их можно отмапить. Вообще чума будет. >>>>> >>>>> >>>>>Все, с первым способом я фактически разобрался. Если найду способ в своей >>>>>функции-обработчике убивать пакеты, чтобы онм не шли дальше, то это будет >>>>>именно то, что мне нужно)) >>>>это очень просто. твой обработчик будет первый в цепочке => чтобы пакет не пошёл дальше его нужно испортить (например так - memset(skb->data, 0, skb->len), skb будет освобождена в следующем обработчике. >>> >>>Кстати, а в исходящих пакетах можно таким образом, к примеру, менять ip >>>адрес получателя? >>>Вот так, например: >>>skb->nh.iph->daddr=my_address >>>Ведь если наш обработчик стоит в самом начале, то по сути можно >>>перенаправлять пакеты куда мы хотим >> >>в исходящих нельзя. это коллбек на input, с исходящими  до файервола >>нужно хучить ip_queue_xmit, что некрасиво. можно правда определить свою qdisc и >>менять адрес в её  коллбеке. можно и ище кой-чего :) >>в src/net все есть. > >а можно ли как-то зарегить обработчик исходящих пакетов после всех остальных функций-обработчиков, >фаерволла в том числе. Так, чтобы фаер получал легитимный исходящий траффик, >пропускал его, а потом наша функция изменяла пакеты как нам хочется? > можно. самый простой способ - зарегестрируйте свою qdisc и смените во всех net_device их qdisc на свой. список нет девайсов экспортируется так что грязных хаков не нужно.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	19. "Обработка сетевых пакетов ядром Linux"
	Сообщение от gekt0r on 13-Апр-07, 11:56
	>>>>>>>>Затрудняюсь, в каком разделе создавать топик, создам здесь, так как он связан >>>>>>>>с кодингом. >>>>>>>>При поступлении сетевого пакета в ОС Linux он сохраняется в каком-то буфере >>>>>>>>в ядре до обработки фаерволлом. Вопрос: можем ли мы получить доступ >>>>>>>>к этому буферу и пакетам в нем? Каким функциями это можно >>>>>>>>сделать? И вообще, где можно про это почитать? >>>>>>>>Пол-инета облазил, нашел пару более менее путных статей, но там мало... >>>>>>> >>>>>>>1) Если я правильно понял вопрос, то существует ровно 2 способа >>>>>>>из ядра - зарегистрировать свою packet_type структуру с нужным proto id - >>>>>>>мы будем получать пакет в коллбеке >>>>>>>Выглядит это примерно так: >>>>>>>... >>>>>>>int my_rcv_callback(struct sk_buff *skb, /* это наш пакет */, struct net_device *dev, >>>>>>>struct packet_type *pt) >>>>>>>{ >>>>>>>  ...что нибудь сделать с пакетом... >>>>>>>  return 1/0; - мы не/приняли пакет >>>>>>>} >>>>>>> .... >>>>>>> struct packet_type my_packet_type = >>>>>>>{ __constant_htons(НУЖНЫЙ_ПРОТО_ИД), >>>>>>>  NULL, >>>>>>>  my_rcv_callback, >>>>>>>  NULL, >>>>>>>  NULL >>>>>>>}; >>>>>>>... >>>>>>>int module_init() { >>>>>>> ....dev_add_pack(&my_packet_type); >>>>>>> ... >>>>>>>} ну и т п. >>>>>>> >>>>>>>2) способ - из userspace - использовать PF_PACKET сокеты с ETH_P_ALL. Если >>>>>>>ядро умеет - их можно отмапить. Вообще чума будет. >>>>>> >>>>>> >>>>>>Все, с первым способом я фактически разобрался. Если найду способ в своей >>>>>>функции-обработчике убивать пакеты, чтобы онм не шли дальше, то это будет >>>>>>именно то, что мне нужно)) >>>>>это очень просто. твой обработчик будет первый в цепочке => чтобы пакет не пошёл дальше его нужно испортить (например так - memset(skb->data, 0, skb->len), skb будет освобождена в следующем обработчике. >>>> >>>>Кстати, а в исходящих пакетах можно таким образом, к примеру, менять ip >>>>адрес получателя? >>>>Вот так, например: >>>>skb->nh.iph->daddr=my_address >>>>Ведь если наш обработчик стоит в самом начале, то по сути можно >>>>перенаправлять пакеты куда мы хотим >>> >>>в исходящих нельзя. это коллбек на input, с исходящими  до файервола >>>нужно хучить ip_queue_xmit, что некрасиво. можно правда определить свою qdisc и >>>менять адрес в её  коллбеке. можно и ище кой-чего :) >>>в src/net все есть. >> >>а можно ли как-то зарегить обработчик исходящих пакетов после всех остальных функций-обработчиков, >>фаерволла в том числе. Так, чтобы фаер получал легитимный исходящий траффик, >>пропускал его, а потом наша функция изменяла пакеты как нам хочется? >> >можно. самый простой способ - зарегестрируйте свою qdisc и смените во всех >net_device их qdisc на свой. >список нет девайсов экспортируется так что грязных хаков не нужно. Спасибо за совет.ду копаться в этом направлении
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]