IpfwNg

[nuclight]

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

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

Comments

[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/]

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