The OpenNET Project / Index page

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

форумы  правила/FAQ  поиск  регистрация  вход/выход  слежка  RSS
"ipfw counter считает не все пакеты?"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (Firewall, Фильтрация пакетов)
Изначальное сообщение [ Отслеживать ]

"ipfw counter считает не все пакеты?"  +/
Сообщение от gardener email(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ообщить модератору

Оглавление

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


1. "ipfw counter считает не все пакеты?"  +/
Сообщение от gardener email(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 email(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 email(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 | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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