IpfwNg

[nuclight]

В честь 26 годовщины 26 апреля уволился с текущей работы и таки наконец начал проект http://wiki.freebsd.org/IpfwNg — хотя на работе FreeBSD и была основной системой, реальную возможность пилить ядро я так и не получил (хотя тот же NAT64 нам бы понадобился не через полгода, так через год). В ближайшие недели посижу дома и надеюсь сделать хотя бы скелет, который можно будет потом уже в свободное время потихоньку пилить — работы по проекту предстоит очень много.

Желающие обсудить по делу — велкам в каменты (хотя я туда еще не все наброски оформил).

Comments

[nuclight.livejournal.com]

> тут надо очень много излагать, возможно имело бы смысл поговорить (по скайпу к примеру).

Скайпа у меня нет, и вообще на слух я воспринимаю плохо - мне нужно видеть буквы перед глазами. Тут разве что в реале еще куда ни шло, где можно бумажки порисовать. Из вариантов неплох IRC, и я и тот же denis_sotchenko (ibl) в RusNet обитаем, реалтаймовый чат. Еще он предложил всем заинтересованным в реале собраться обсудить, благо погода позволяет, но мы в Мск, как с Питером, хз.

По остальному - да, ессно stateful, про несколько разных таблиц _стейтов_ - надо смотреть, зачем оно может быть нужно на практик, и каким быть.

По правилам последовательно - я там в wiki черканул про nf-hipac и про счетчики, погляди.

[http://users.livejournal.com/_slw/]

не, я имел ввиду именно поговорить, поскольку текста слишком много набирать.
что бы картинки рисовать -- ну можно найти с desctop sharing, в конце концов у webex вроде бесплатный месяц есть.

про несколько разных таблиц _стейтов_ - надо смотреть, зачем оно может быть нужно на практик, и каким быть.

если файрвол применяется в корпоративной среде, то там может быть требование, что пакет от серверов в dmz не может прилететь иначе, чем с bge0. а lan -- исключительно на bge1. вот что бы не думать -- мы говорим, что bge0-bge1 -- относятся к одной таблице состояний, а bge1-bge2 -- к другой. а может быть так, что пакет может прилететь и em0 и em1. тогда у нас будет bge0-{em0,em1}. ну или вообще без разницы.

По правилам последовательно - я там в wiki черканул про nf-hipac и про счетчики, погляди.

не очень понял-то. т.е. некоторые мысли от капитана очевидность, ну да, сложно в чем-то. а кто обещал просто? ну и исходник можно вместе с компиленым хранить и показывать его.

[http://users.livejournal.com/_dyr/]

Чтобы не думать, в ipfw специально для целей rpf check есть antispoof и verrev-path.

[http://users.livejournal.com/_slw/]

ты никогда не имел дела с корпоративными сетями и файрволами для них?

нет, на эти проверки роутинг вляеть не должен. наличие протоколов динамической маршрутизации и анонс кем-то нехорошим такого роута не должен приводить ни к гроханию стэйта ни к допустимости нового такого стейта

[dadv.livejournal.com]

В динамике есть фильтрация маршрутов, конкретно в OSPF есть md5 для нейборов.

[http://users.livejournal.com/_slw/]

проанонсить может кто-то более дальний, чем непосредственный сосед.
в любом случае закладываться на то, что не проанонсят -- неверно.
т.е. кому-то может и достаточно, но принципиально рубить такую возможность -- неверно.

[http://users.livejournal.com/_dyr/]

Каким образом файервол должен отслеживать маршрутизацию? Что за каша?

[http://users.livejournal.com/_slw/]

я не знаю что ты имеешь ввиду под отслеживать, но в любом случае отслеживать маршрутизацию я не говорил

[http://users.livejournal.com/_dyr/]

Бля.
Ещё раз, чётко ответьте, что вы хотите делать с помощью firewall для [некорректной работы] динамической маршрутизации.

[http://users.livejournal.com/_slw/]

э, какой еще некорректной? я где сказал слово некорректная?

ну что тут сложного. есть у нас bge0 с серверами. 10.1.2.0/24. там сервер 10.1.2.3. у клиентов (bge2) с ним сессии.

нехороший редиска с сети подключенной к bge1 анонсит 10.1.2.3/32. никакие rpf не запретят ходить пакетам с bge1 с src 10.1.2.3. и трафик имеющихся сессий клиентов с bge2 попрет на этот подложный сервер. так вот, состояния сессиий этого не должны допускать (если админу это надо, конечно). т.е. состоянии сессии привязанно к паре интерфейсов (bge0-bge2) в нашем случае. и для bge2-bge1 у нас такой сессии нет, пакет сессии не соответсвует, он должен быть дропнут а в логах сообщение о событии "пакет вне сессии".

[http://users.livejournal.com/_dyr/]

А теперь обьясните, чем для данного случая вас не устраивает имеющийся механизм ipfw verrevpath и, шире, RPF check?

На всякий случай напомню:

     verrevpath
	     For incoming packets, a routing table lookup is done on the
	     packet's source address.  If the interface on which the packet
	     entered the system matches the outgoing interface for the route,
	     the packet matches.  If the interfaces do not match up, the
	     packet does not match.  All outgoing packets or packets with no
	     incoming interface match.

	     The name and functionality of the option is intentionally similar
	     to the Cisco IOS command:

		   ip verify unicast reverse-path

	     This option can be used to make anti-spoofing rules to reject all
	     packets with source addresses not from this interface.  See also
	     the option antispoof.

[http://users.livejournal.com/_slw/]

потому что он просто не работает тут.
не согласен? покажи как он тут сработает.

[http://users.livejournal.com/_slw/]

потому что он тут просто не сработает
не согласен? покажи как сработает.

[http://users.livejournal.com/_dyr/]

Ваш набор слов почему-то совершенно не складывается в осмысленную фразу. Поясните, что вы хотите сказать и при чём здесь роутинг?

[http://users.livejournal.com/_slw/]

почемуто dadv меня понял верно.
роутинг тут при rpf и verrev.

Способ коммуникации лучше тот, который удобен мне, а не

[nuclight.livejournal.com]

Нащот всего коммента разом - я только из ветки ответивших людей понял, что на самом деле потребность не в нескольких таблицах состояний, а в фиксировании исходный интерфейсов в стейте с отсеканием при не тех (опционально с воплями). Рисовать на компе - это тот еще пиздец, совсем не реалтаймовый. Скайпы и прочее - пардон, _мне_ аудио-режим неудобен. Разговаривать в реале и на бумажке при этом чёркать - это да, это может быть продуктивно. Написать несколько экранов текста в оффлайне с картинками - это тоже продуктивно. Всё остальное - варьируется, и поскольку реализовывать мне - причем мне за это не платят - то и выбирать мне. Если хочешь что-то донести, то уж будь добр, приложи к тому усилия - от тебя их и так на порядки меньше требуется, чем от меня. А пока что меня несколько раздражает даже корявое оформление комментариев - больших букв в предложениях нет, цитаты не отделены, приходится тратить лишнее время и напрягать глаза, чтобы распарсить и поскипать ненужное.

[http://users.livejournal.com/_slw/]

Нащот всего коммента разом - я только из ветки ответивших людей понял, что на самом деле потребность не в нескольких таблицах состояний, а в фиксировании исходный интерфейсов в стейте с отсеканием при не тех (опционально с воплями).

фактически для реализации этого и надо несколько пространств стейтов. поскольку, например, адрес A в двух разных FIB может являться разным адресом. ну в двух разных VIRTNET -- просто однозначно. но (я про это не писал, но это есть следствие того, за что я агитирую) -- должен ли файрвол [транзитный] для своей работы иметь в ядре сконфигурированные сущности (протоколы, virtnetы), по которым работает? я считаю -- нет, не обязательно. т.е. например фильтрацию в vlan можно устраивать не создавая интерфейс vlan в ядре.

Скайпы и прочее - пардон, _мне_ аудио-режим неудобен. Разговаривать в реале и на бумажке при этом чёркать - это да, это может быть продуктивно. Написать несколько экранов текста в оффлайне с картинками - это тоже продуктивно.

это правильно, но долго. все это можно было бы проговорить за полчаса, а у нас ушел месяц астрономического времени и несколько часов долбежа по кнопкам. да, на данный момент уже не так актуально, большая часть уже изложена.

А пока что меня несколько раздражает даже корявое оформление комментариев - больших букв в предложениях нет, цитаты не отделены, приходится тратить лишнее время и напрягать глаза, чтобы распарсить и поскипать ненужное.

скажем спасибо жж. на почту твои каменты тоже приходят в несколько странном виде. в вебинтерфейсе с цитатами понятнее. хорошо хоть лимит на объем камента подняли, с четыремя килобайами вообще ничего длинного не изложить было.

[nuclight.livejournal.com]

По нескольким пространствам стейтов - для генерализованного решения да, это полезно. Но задачи, их требующие, не столь часты, и даже в линуксе поддержка неймспейсов появилась очень недавно. И конкретно описанная задача лучше решается не несколькими пространствами, а security-обработчиком flow, который записывает интерфейсы на первых проходящих пакетах в регистры dynrule и сравнивает их далее на каждом проходящем. Что касается одинаковых адресов в разных FIB - ну так для этого в ядре таки должны быть сконфигурены разные fib, например. Не всё везде так однозначно.

По переписке - ну, если большая часть уже изложена, это хорошо. Здесь ветки уж слишком разрослись, надо уточнить некоторые моменты здесь, а потом сухой остаток предварительного итога в новый пост вынести.

[http://users.livejournal.com/_slw/]

По нескольким пространствам стейтов - для генерализованного решения да, это полезно. Но задачи, их требующие, не столь часты, и даже в линуксе поддержка неймспейсов появилась очень недавно.

это проблемы линуха. почему это должно меня волновать? виртуальные файрволы в asa появились очень давно. не регулируемое поведение было вообще изначально, в pix. регулируемое появилось относительно недавно, но достаточно давно на самом деле, кажется даже раньше нэймспэйсов. и это с твоей колокольни они не часты -- это типичная задача в корпоративной среде. ну да, как ее можно увидеть не работая там? просто поверь мне.

И конкретно описанная задача лучше решается не несколькими пространствами, а security-обработчиком flow, который записывает интерфейсы на первых проходящих пакетах в регистры dynrule и сравнивает их далее на каждом проходящем

это криво. это будет плохо работать. особенно если у нас что-то типа {bge0,bge1,bge2}-{bge3,bge4,bge5}

Что касается одинаковых адресов в разных FIB - ну так для этого в ядре таки должны быть сконфигурены разные fib, например.

почему в ядре должны быть сконфигурированны сущности, по которым работает файрвол?
разве для фильтрации транзитного tcp в ядре должны быть tcp сокеты? ну или stcp.
файрволу не требуется поддержка ядра для этих действий.
и я уже приводил пример -- файрвол может фильтровать трафик в транзитном GRE-туннеле, не терминируюя его на машине. точно так же можно фильтровать трафик в езернетовском транке, не терминируя и не заводя vlanы в ядре, просто поставив в режим бриджа и самостоятельно разбирая 802.1q заголовки. ну и с метками mpls та же история. зачем делать урезанную функциональность, если достаточно простыми и дешевыми средствами можно получить гораздо большую гибкость?

По переписке - ну, если большая часть уже изложена, это хорошо. Здесь ветки уж слишком разрослись, надо уточнить некоторые моменты здесь, а потом сухой остаток предварительного итога в новый пост вынести.

может я и не прав и мне не удалось многое до тебя до нести. но раз в неделю -- я уже непомню что сказал, что нет.