forum.opennet.ru - "ipfw counter считает не все пакеты?" (6)

форумы

правила/FAQ

поиск

регистрация

вход/выход

слежка

"ipfw counter считает не все пакеты?"

Форум Открытые системы на сервере (Firewall, Фильтрация пакетов)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"ipfw counter считает не все пакеты?"	+/–
Сообщение от gardener (ok) on 12-Май-17, 14:18
Здравствуйте! Столкнулся с ненормальным поведением ipfw. На машине [FreeBSD 11.0-STABLE] стоит isc-dhcpd. Машина используется для различных тестов. В частности сейчас мне нужно внедрить netgraph в исходящее правило, а оно не срабатывает. Смотрю на каунтерсы, а они не меняются: # ipfw show 00100 5848 10090294 allow ip from any to any via lo0 00105 0 0 count ip from any to any proto udp out xmit em1 00110 0 0 count ip from any to any src-port 67 out xmit em1.512 00115 3 1143 count ip from any to any dst-port 67 in via em1.512 00120 0 0 count ip from any to any out via em1.512 при этом tail /var/log/dhcpd.log : May 12 13:51:16 <daemon.info> test dhcpd: DHCPREQUEST for 172.18.27.5 from 00:1b:24:45:44:52 (tazik) via em1.512 May 12 13:51:16 <daemon.info> test dhcpd: DHCPACK on 172.18.27.5 to 00:1b:24:45:44:52 (tazik) via em1.512 и tazik получает ответ, и tcpdump видит пакет, и ng_tee на уровне ng_ether все видит, а ipfw не фиксирует. Уже и ipfw включил в ядро, добавив опции: options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=50 options LIBALIAS options DUMMYNET а все одно. Проверил дома (там таже версия) все считается, а на работе нет. Куда рыть уже не знаю. Как починить ipfw чтобы он начал срабатывать на исходящем правиле?!
Ответить \| Правка \| Cообщить модератору

Оглавление

ipfw counter считает не все пакеты?, gardener, 17:27 , 15-Май-17, (1)

ipfw counter считает не все пакеты?, butcher, 11:04 , 17-Май-17, (2) +1

ipfw counter считает не все пакеты?, gardener, 23:04 , 18-Май-17, (3)

ipfw counter считает не все пакеты?, butcher, 14:50 , 19-Май-17, (4) +2

ipfw counter считает не все пакеты?, gardener, 15:39 , 19-Май-17, (5)
ipfw counter считает не все пакеты?, gardener, 17:58 , 22-Май-17, (6)

Сообщения по теме [Сортировка по времени | RSS]

1. "ipfw counter считает не все пакеты?" +/–

Сообщение от gardener (ok) on 15-Май-17, 17:27

Хочу добавить, что исходящие icmp пакеты ipfw все-таки регистрирует.
Но вот непонятно почему udp игнорирует?!

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "ipfw counter считает не все пакеты?" +1 +/–

Сообщение от butcher (ok) on 17-Май-17, 11:04

> Хочу добавить, что исходящие icmp пакеты ipfw все-таки регистрирует.
> Но вот непонятно почему udp игнорирует?!
DHCP не использует IP стек для отправки пакетов, пакеты формируются и отправляются через BPF. От сюда и ограничение, чтобы ipfw мог видеть и блокировать такие пакеты, вам нужно это делать на layer2. Читайте про net.link.ether.ipfw.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "ipfw counter считает не все пакеты?" +/–

Сообщение от gardener (ok) on 18-Май-17, 23:04

> DHCP не использует IP стек для отправки пакетов, пакеты формируются и отправляются
> через BPF. От сюда и ограничение, чтобы ipfw мог видеть и
> блокировать такие пакеты, вам нужно это делать на layer2. Читайте про
> net.link.ether.ipfw.
Я конечно не гуру, но по-моему BPF не интерфейс, а фильтр. Им могут фильтроваться, но не формироваться и не отправляться пакеты?
И как может не участвовать стек IP, если dhcp пакет имеет заголовки вплоть до L7?
С другой стороны, на машине, на которой счетчики исправно растут (о чем я упоминал ранее) значение переменной net.link.ether.ipfw = 0.
Ну и все статьи о "net.link.ether.ipfw" касаются фильтрации по MAC. А мне это ни к чему. Я не знаю MAC-ов. В том смысле что какие есть, все хороши.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "ipfw counter считает не все пакеты?" +2 +/–

Сообщение от butcher (ok) on 19-Май-17, 14:50

>> DHCP не использует IP стек для отправки пакетов, пакеты формируются и отправляются
>> через BPF. От сюда и ограничение, чтобы ipfw мог видеть и
>> блокировать такие пакеты, вам нужно это делать на layer2. Читайте про
>> net.link.ether.ipfw.
> Я конечно не гуру, но по-моему BPF не интерфейс, а фильтр. Им
> могут фильтроваться, но не формироваться и не отправляться пакеты?
Прочтите man 4 bpf
> И как может не участвовать стек IP, если dhcp пакет имеет заголовки
> вплоть до L7?
DHCP клиент формирует весь пакет со всеми заголовками и отправляет его прямо в интерфейс используя BPF и минуя IP стек.
> С другой стороны, на машине, на которой счетчики исправно растут (о чем
> я упоминал ранее) значение переменной net.link.ether.ipfw = 0.
В приведённом вами выводе счётчики растут только для входящих пакетов. Так как исходящий пакет отправляется мимо IP стека, PFIL хук файрвола не вызывается.
PFIL хуки вызываются из функций IP стека ip_input(), ip_output() и ip_tryforward(). В случае отправки пакета через BPF, пакет минует IP стек и отправляется из ether_output(). Чтобы файрвол увидел этот пакет, PFIL хук должен быть вызван из ether_output(), а это происходит только при включенном net.link.ether.ipfw.
Для входящих DHCP пакетов ситуация немного другая. Приложение, использующее BPF видит все пакеты, настроенные в фильтре, но изъять пакет из стека оно не может. Поэтому, т.к. пакет является IP пакетом, он попадает в ip_input(), а от туда уже в файрвол.
> Ну и все статьи о "net.link.ether.ipfw" касаются фильтрации по MAC. А мнене
> это ни к чему. Я не знаю MAC-ов. В том смысле
> что какие есть, все хороши.
На layer2 ipfw может выполнять бОльшую часть всех действий, которые он умеет, за исключением nat и fwd. Он точно так же парсит все пакеты до заголовков транспортного уровня и правила могут матчить по всем параметрам, которые доступны в layer3.
Фильтрация по MAC адресам тут является просто дополнительной возможностью, т.к. у пакета ещё не отброшен ethernet заголовок.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "ipfw counter считает не все пакеты?" +/–

Сообщение от gardener (ok) on 19-Май-17, 15:39

> DHCP клиент формирует весь пакет со всеми заголовками и отправляет его прямо
> в интерфейс используя BPF и минуя IP стек.
Только в моем случае "сервер".
> В приведённом вами выводе счётчики растут только для входящих пакетов. Так как
> исходящий пакет отправляется мимо IP стека, PFIL хук файрвола не вызывается.
Да, счетчики я приводил для проблемной машины. На другой счет ведется. Но тут после Вашего сообщения вспомнил, что на проблемной DHCP сервер отдает все бродкастом.
И точно, если отключить "always-broadcast off;", то счетчики считают, правда только offer-ы, аки улетают неучтенными :)
А в случае с "always-broadcast on;" не считают ничего.
В общем пошел читать. Направление похоже верное ;)

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "ipfw counter считает не все пакеты?" +/–

Сообщение от gardener (ok) on 22-Май-17, 17:58

>>> Читайте про net.link.ether.ipfw.
Благодарю за информацию. После установки этой переменной в 1 счетчики нормально считают весь исходящий трафик.
>> Я конечно не гуру, но по-моему BPF не интерфейс, а фильтр. Им
>> могут фильтроваться, но не формироваться и не отправляться пакеты?
> Прочтите man 4 bpf
Ага!
A packet can be sent out on the network by writing to a bpf file descriptor.
То есть isc-dhcp пишет в дескриптор символьного устройства, не в сокет или куда, а именно в дескриптор /dev/bpf.
Понял. Благодарю.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "ipfw counter считает не все пакеты?"	+/–
Сообщение от gardener (ok) on 15-Май-17, 17:27
Хочу добавить, что исходящие icmp пакеты ipfw все-таки регистрирует. Но вот непонятно почему udp игнорирует?!
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	2. "ipfw counter считает не все пакеты?"	+1 +/–
	Сообщение от butcher (ok) on 17-Май-17, 11:04
	> Хочу добавить, что исходящие icmp пакеты ipfw все-таки регистрирует. > Но вот непонятно почему udp игнорирует?! DHCP не использует IP стек для отправки пакетов, пакеты формируются и отправляются через BPF. От сюда и ограничение, чтобы ipfw мог видеть и блокировать такие пакеты, вам нужно это делать на layer2. Читайте про net.link.ether.ipfw.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	3. "ipfw counter считает не все пакеты?"	+/–
	Сообщение от gardener (ok) on 18-Май-17, 23:04
	> DHCP не использует IP стек для отправки пакетов, пакеты формируются и отправляются > через BPF. От сюда и ограничение, чтобы ipfw мог видеть и > блокировать такие пакеты, вам нужно это делать на layer2. Читайте про > net.link.ether.ipfw. Я конечно не гуру, но по-моему BPF не интерфейс, а фильтр. Им могут фильтроваться, но не формироваться и не отправляться пакеты? И как может не участвовать стек IP, если dhcp пакет имеет заголовки вплоть до L7? С другой стороны, на машине, на которой счетчики исправно растут (о чем я упоминал ранее) значение переменной net.link.ether.ipfw = 0. Ну и все статьи о "net.link.ether.ipfw" касаются фильтрации по MAC. А мне это ни к чему. Я не знаю MAC-ов. В том смысле что какие есть, все хороши.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	4. "ipfw counter считает не все пакеты?"	+2 +/–
	Сообщение от butcher (ok) on 19-Май-17, 14:50
	>> DHCP не использует IP стек для отправки пакетов, пакеты формируются и отправляются >> через BPF. От сюда и ограничение, чтобы ipfw мог видеть и >> блокировать такие пакеты, вам нужно это делать на layer2. Читайте про >> net.link.ether.ipfw. > Я конечно не гуру, но по-моему BPF не интерфейс, а фильтр. Им > могут фильтроваться, но не формироваться и не отправляться пакеты? Прочтите man 4 bpf > И как может не участвовать стек IP, если dhcp пакет имеет заголовки > вплоть до L7? DHCP клиент формирует весь пакет со всеми заголовками и отправляет его прямо в интерфейс используя BPF и минуя IP стек. > С другой стороны, на машине, на которой счетчики исправно растут (о чем > я упоминал ранее) значение переменной net.link.ether.ipfw = 0. В приведённом вами выводе счётчики растут только для входящих пакетов. Так как исходящий пакет отправляется мимо IP стека, PFIL хук файрвола не вызывается. PFIL хуки вызываются из функций IP стека ip_input(), ip_output() и ip_tryforward(). В случае отправки пакета через BPF, пакет минует IP стек и отправляется из ether_output(). Чтобы файрвол увидел этот пакет, PFIL хук должен быть вызван из ether_output(), а это происходит только при включенном net.link.ether.ipfw. Для входящих DHCP пакетов ситуация немного другая. Приложение, использующее BPF видит все пакеты, настроенные в фильтре, но изъять пакет из стека оно не может. Поэтому, т.к. пакет является IP пакетом, он попадает в ip_input(), а от туда уже в файрвол. > Ну и все статьи о "net.link.ether.ipfw" касаются фильтрации по MAC. А мнене > это ни к чему. Я не знаю MAC-ов. В том смысле > что какие есть, все хороши. На layer2 ipfw может выполнять бОльшую часть всех действий, которые он умеет, за исключением nat и fwd. Он точно так же парсит все пакеты до заголовков транспортного уровня и правила могут матчить по всем параметрам, которые доступны в layer3. Фильтрация по MAC адресам тут является просто дополнительной возможностью, т.к. у пакета ещё не отброшен ethernet заголовок.
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	5. "ipfw counter считает не все пакеты?"	+/–
	Сообщение от gardener (ok) on 19-Май-17, 15:39
	> DHCP клиент формирует весь пакет со всеми заголовками и отправляет его прямо > в интерфейс используя BPF и минуя IP стек. Только в моем случае "сервер". > В приведённом вами выводе счётчики растут только для входящих пакетов. Так как > исходящий пакет отправляется мимо IP стека, PFIL хук файрвола не вызывается. Да, счетчики я приводил для проблемной машины. На другой счет ведется. Но тут после Вашего сообщения вспомнил, что на проблемной DHCP сервер отдает все бродкастом. И точно, если отключить "always-broadcast off;", то счетчики считают, правда только offer-ы, аки улетают неучтенными :) А в случае с "always-broadcast on;" не считают ничего. В общем пошел читать. Направление похоже верное ;)
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	6. "ipfw counter считает не все пакеты?"	+/–
	Сообщение от gardener (ok) on 22-Май-17, 17:58
	>>> Читайте про net.link.ether.ipfw. Благодарю за информацию. После установки этой переменной в 1 счетчики нормально считают весь исходящий трафик. >> Я конечно не гуру, но по-моему BPF не интерфейс, а фильтр. Им >> могут фильтроваться, но не формироваться и не отправляться пакеты? > Прочтите man 4 bpf Ага! A packet can be sent out on the network by writing to a bpf file descriptor. То есть isc-dhcp пишет в дескриптор символьного устройства, не в сокет или куда, а именно в дескриптор /dev/bpf. Понял. Благодарю.
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору