The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"Обработка сетевых пакетов ядром Linux"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Программирование под UNIX (Public)
Изначальное сообщение [Проследить за развитием треда]

"Обработка сетевых пакетов ядром Linux"  
Сообщение от Gekt0r email(??) 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 email 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 email(??) 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 email(??) 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 email(??) 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 email(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

И отчасти вот тут:
http://www.opennet.me/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 email 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 email 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]




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру