Затрудняюсь, в каком разделе создавать топик, создам здесь, так как он связан с кодингом.
При поступлении сетевого пакета в ОС Linux он сохраняется в каком-то буфере в ядре до обработки фаерволлом. Вопрос: можем ли мы получить доступ к этому буферу и пакетам в нем? Каким функциями это можно сделать? И вообще, где можно про это почитать?
Пол-инета облазил, нашел пару более менее путных статей, но там мало...
если очень хочеться менять/считать/ещё.. что нибудь делать с пакетами -- то самый верный путь это libipq -- она устарела, и сейчас нужно юзать libconntrack_ipq
>если очень хочеться менять/считать/ещё.. что нибудь делать с пакетами -- то самый
>верный путь это libipq -- она устарела, и сейчас нужно юзать
>libconntrack_ipqНасчет libconntrack_ipq и Яндекс, и Гугл молчат... А что касается libipq, это, кажется, какая-то утилита уровня пользователя? А мне нужно получить доступ именно к функциям ядра
netfilter.org смотри -- вот если вопрос в обработке пакетов, до firewall'а -- то я правильный путь показываю, и да это в юзерспейсе обрабатывается, а перехватывается ядром.libconntrack_queue она называется -- обшибся немного.
а если есть дикое желание написать именно какой-нибудь модуль ядра -- то, как говориться бог в помощь -- я тут подсказать ни чем не могу.
>netfilter.org смотри -- вот если вопрос в обработке пакетов, до firewall'а --
>то я правильный путь показываю, и да это в юзерспейсе обрабатывается,
>а перехватывается ядром.
>
>libconntrack_queue она называется -- обшибся немного.
>
>а если есть дикое желание написать именно какой-нибудь модуль ядра -- то,
>как говориться бог в помощь -- я тут подсказать ни чем
>не могу.
libconntrack_queue тоже в гугле нет...
Да, мне нужна именно обработка пакетов до их анализа netfilter. Это вообще возможно?
>>netfilter.org смотри -- вот если вопрос в обработке пакетов, до firewall'а --
>>то я правильный путь показываю, и да это в юзерспейсе обрабатывается,
>>а перехватывается ядром.
>>
>>libconntrack_queue она называется -- обшибся немного.
>>
>>а если есть дикое желание написать именно какой-нибудь модуль ядра -- то,
>>как говориться бог в помощь -- я тут подсказать ни чем
>>не могу.
>
>
>libconntrack_queue тоже в гугле нет...
>Да, мне нужна именно обработка пакетов до их анализа netfilter. Это вообще
>возможно?
до анализа...iptables, осмелюсь предположить? iptables != netfilter
можно добавить свой модуль netfilter и зацепить за prerouting и output до всех модулей iptables. это не то, что нужно?
возможно, вам сюда:
http://www.iptables.org/documentation/HOWTO/netfilter-hackin...
(google netfilter hacking howto - первая ссылка)\^P^/
>Затрудняюсь, в каком разделе создавать топик, создам здесь, так как он связан
>с кодингом.
>При поступлении сетевого пакета в ОС 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. Если ядро умеет - их можно отмапить. Вообще чума будет.
>>Затрудняюсь, в каком разделе создавать топик, создам здесь, так как он связан
>>с кодингом.
>>При поступлении сетевого пакета в ОС 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? Можете какой-нибудь док посоветовать?
Можете какой-нибудь док
>посоветовать?
RAW ethernet
например документации море
>>Затрудняюсь, в каком разделе создавать топик, создам здесь, так как он связан
>>с кодингом.
>>При поступлении сетевого пакета в ОС 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. Если
>ядро умеет - их можно отмапить. Вообще чума будет.
Все, с первым способом я фактически разобрался. Если найду способ в своей функции-обработчике убивать пакеты, чтобы онм не шли дальше, то это будет именно то, что мне нужно))
>>>Затрудняюсь, в каком разделе создавать топик, создам здесь, так как он связан
>>>с кодингом.
>>>При поступлении сетевого пакета в ОС 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 будет освобождена в следующем обработчике.
>>>>Затрудняюсь, в каком разделе создавать топик, создам здесь, так как он связан
>>>>с кодингом.
>>>>При поступлении сетевого пакета в ОС 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 будет освобождена в следующем обработчике.Ты даже не представляешь, насколько не помог)) Фактически дал пищу третьей главе моего диплома)) Спасибо большое)
Жаль только для исходящих пакетов такой обход фаерволла не действует(
>>>>Затрудняюсь, в каком разделе создавать топик, создам здесь, так как он связан
>>>>с кодингом.
>>>>При поступлении сетевого пакета в ОС 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
Ведь если наш обработчик стоит в самом начале, то по сути можно перенаправлять пакеты куда мы хотим
рыбяты -- а поделитесь сцылками пожалуйста.
>рыбяты -- а поделитесь сцылками пожалуйста.ссылками на что конкретно?
То, на что меня натолкнул int_0dh, я нашел вот в этой статье:
http://www.hackzona.ru/hz.php?name=News&file=print&sid=2263И отчасти вот тут:
http://www.opennet.me/base/sec/p55-12.txt.html
спасибо.
>>>>>Затрудняюсь, в каком разделе создавать топик, создам здесь, так как он связан
>>>>>с кодингом.
>>>>>При поступлении сетевого пакета в ОС 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 все есть.
>>>>>>Затрудняюсь, в каком разделе создавать топик, создам здесь, так как он связан
>>>>>>с кодингом.
>>>>>>При поступлении сетевого пакета в ОС 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 все есть.а можно ли как-то зарегить обработчик исходящих пакетов после всех остальных функций-обработчиков, фаерволла в том числе. Так, чтобы фаер получал легитимный исходящий траффик, пропускал его, а потом наша функция изменяла пакеты как нам хочется?
>>>>>>>Затрудняюсь, в каком разделе создавать топик, создам здесь, так как он связан
>>>>>>>с кодингом.
>>>>>>>При поступлении сетевого пакета в ОС 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 на свой.
список нет девайсов экспортируется так что грязных хаков не нужно.
>>>>>>>>Затрудняюсь, в каком разделе создавать топик, создам здесь, так как он связан
>>>>>>>>с кодингом.
>>>>>>>>При поступлении сетевого пакета в ОС 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 на свой.
>список нет девайсов экспортируется так что грязных хаков не нужно.
Спасибо за совет.ду копаться в этом направлении