Олег Воробьёв опубликовал статью (http://www.lissyara.su/?id=1536)
с рассказом о принципе построения правил пакетного фильтра IPFW.URL: http://www.lissyara.su/?id=1536
Новость: http://www.opennet.me/opennews/art.shtml?num=12522
В правиле 4 не должно ли быть deny?
Во Фре есть очень полезная фича: переименование сетевых интерфейсов, так, например, {iif} и {oif} лучше сразу писать типа internal, external.Делается это в /etc/rc.conf так:
ifconfig_em0_name="internal"
ifconfig_em1_name="external"Это удобно тем, что вне зависимости какого производителя у вас карточка и на какую вы её в случае чего замените, вам потребуется поменять всего лишь обозначение в /etc/rc.conf, а не отлавливать все скрипты на предмет изменения названия интерфейса.
Плюс размещение в файле строчек типа:
${fwcmd} add allow ip from any to ${MyLan} in via {oif}
не очень удобно в плане дальнейшего модифицирования файрволла на ходу без перезагрузки всех правил, гораздо удобнее всё-таки писать /sbin/ipfw вместо {fwcmd} (благо его не часто переносят):
/sbin/ipfw table 1 add 10.10.10.0/24
/sbin/ipfw add allow ip from any to table(1) in via externalТаким образом можно после редактирования файлика сразу исполнить эту строчку и тем самым добавить в файрволл новое правило.
Всё ИМХО, основанное на продолжительном опыте эксплуатации фри в качестве роутера.
а почему народ не любит стандартный
/etc/rc.firewall
и старается писать свои правила?
Например, в /etc/rc.firewall адреса внутренней сетИ заданы внутри скрипта, а их надо задавать в /etc/rc.conf - этого уже достаточно, чтобы делать свой набор правил.А вот подгружать правила из текстового файла тоже не очень хорошо, т.к. конструкция с проверкой необходимости natd очень разумна, и $natd_interface берётя из /etc/rc.conf.
>Во Фре есть очень полезная фича: переименование сетевых интерфейсовЭто таки хорошая фича, да, но есть одно но (не знаю, пофиксили ли это в 7 ветке, но на 6.2 этот баг все еще есть) - NETGRAPH очень странно работает с переименованными интерфейсами. Например, у меня mpd категорически отказывается подключаться по pppoe через переименованный интерфейс. Погуглил - оказалось, таки да. Судя по всему, валится ng_ether, который собран с ядром. По идее, его нужно подгружать уже после переименования интерфейса, тогда может быть все и будет нормально, но пока руки не дошли проверить. Кто-то уже боролся?
там тонкость: ng_ether надо грузить модулем после переименования интерфейсов
Так я об этом же и говорю.
Но все равно это своеобразный косяк, с которым еще попританцовывать надо. Может быть кому-то и пригодится, потому как в нете не сильно много об этой проблеме написано.
Замечание к статье.
В /etc/rc.conf в firewall_type="" можно указать просто имя файла, из которого стандартный rc.firewall и считает правила, и в самом rc.firewall ничего править не нужно.
В очередной раз можно сказать "читайте man" (man ipfw) - лучший источник знаний.1. Правила загружать правильней не скриптом, который для добавления каждого правила вызывает ipfw, а из текстового файла: /sbin/ipfw /etc/ipfwrules.txt.
2. Для сложных случаев с переменными пользуемся препроцессором:
/sbin/ipfw -p /usr/bin/m4 /etc/ipfwrules.m4 .
а если маленькая ошибочка в этом текстовом файле?
по умолчанию таки в виде скрипта все сделано. Разработчики кто по вашему тогда? идиоты чтоль? ;)
>а если маленькая ошибочка в этом текстовом файле?
>по умолчанию таки в виде скрипта все сделано. Разработчики кто по вашему
>тогда? идиоты чтоль? ;)Разработчики чего ? Скрипта rc.firewall ?
А если ошибочка в скрипте - тогда что делать ?Читаем man ipfw и узнаём о ipfw -n . Позволяет проверить правила без реальной загрузки.
Для этого есть set, сначала правила загружаются в неактивный, потом проверяются, потом он делается активным. Есть пример в examples
ммм....у меня к ночи мозги клинят или я непойму....откуда в правилах 7 и 8 айпишники внутренней сетки появяться на внешнем интерфейсе?
>2. Для сложных случаев с переменными пользуемся препроцессором:
>/sbin/ipfw -p /usr/bin/m4 /etc/ipfwrules.m4 .Только не m4... в прочем если вы используете sendmail и в ручную пишите sendmail.cf, то m4 вам понравится.
Автор, как всегда, в своем репертуаре... Экспериментально устанавливал, что происходит с пакетом после divert, тогда как это есть в мане, даже в двух - и divert(4), и natd(8)/
дык маньяк он и с маном маньяк и без мана
>Автор, как всегда, в своем репертуаре...Мы не знакомы, это моя первая статья чтобы говорить о моём репертуаре.
Очень рад что заставил лишний раз перечитать MAN.
Да ладно вам автору респект - я сам часто методом научного тыка все пытаюсь выявить а уж если совсе бяд -вот тогда мана. Да я уверен что 70% админов сами с усами...народ у нас такой...
Не в тему.
Если уж начали изучать firewall-ы на FreeBSD то
лучше СРАЗУ изучайте pf !
После него на ipfw,iptables смотреть даже не будете :)
Вот только с документацией и примерами не густо но есть хорошие статьи про pf для OpenBSD ( со списком отличий в FreeBSD )
>Не в тему.
>Если уж начали изучать firewall-ы на FreeBSD то
>лучше СРАЗУ изучайте pf !
>После него на ipfw,iptables смотреть даже не будете :)
>Вот только с документацией и примерами не густо но есть хорошие статьи
>про pf для OpenBSD ( со списком отличий в FreeBSD )
>Не всё так как кажется.
1. Он не умеет на FreeBSD блокировать в ядре IP до запуска себя. Приходится это делать скриптами запуска.
2. В ipfw удобно добавляются, удаляются отдельные правила или наборы.
3. IPFW+Dummynet - удобная вещь для справедливого деления канала между пользователями.Ну и ещё всякое разное.
> 1. Он не умеет на FreeBSD блокировать в ядре IP до запуска себя. Приходится это делать скриптами запуска.Ничего не понял, как это скриптами запуска? А при старте ядра загрузить модуль религия не дает?
> 2. В ipfw удобно добавляются, удаляются отдельные правила или наборы.
Аналогично и в pf
> 3. IPFW+Dummynet - удобная вещь для справедливого деления канала между пользователями.
PF замечательно умеет делить канал как вашей душе угодно.
Ничего не имею против IPFW, но прежде чем говорить что какая-то из служб что-то не умеет все же стоит документацию хотя бы глянуть.
Оба фильтра замечательно выполняют свои функции, и могут полностью заменить друг друга.
Тут дело вкуса, и кто к чему привык/лучше знает.
Уважаемый серг, а какая-нить альтернатива natd есть в OpenBSD? Я согласен что, ПФ Опенка гораздо приятнее ipfw, но вот када нада извраты с натд...
>Уважаемый серг, а какая-нить альтернатива natd есть в OpenBSD? Я согласен что,
>ПФ Опенка гораздо приятнее ipfw, но вот када нада извраты с
>натд...там слава богу нет этого угребищного natd, там nat в ядре и сделан прямыми руками, в отличие от возни с divert и левой программой, которая поднимается отдельно.
>> 1. Он не умеет на FreeBSD блокировать в ядре IP до запуска себя. Приходится это делать скриптами запуска.
>
>Ничего не понял, как это скриптами запуска? А при старте ядра загрузить
>модуль религия не дает?Если PF по каким-либо причинам не загрузится, то будет дыра. Без IPFW в таких случаях будет Deny All.
>> 2. В ipfw удобно добавляются, удаляются отдельные правила или наборы.
>
>Аналогично и в pf"Удобно".
>
>> 3. IPFW+Dummynet - удобная вещь для справедливого деления канала между пользователями.
>
>PF замечательно умеет делить канал как вашей душе угодно.pipe 1 config bw 10Mbit/s
pipe 2 config bw 10Mbit/s
pipe 3 config bw 768Kbit/s mask dst-ip 0xFFFFFFFF
queue 1 config pipe 1 mask src-ip 0xFFFFFFFF
queue 2 config pipe 2 mask dst-ip 0xFFFFFFFF
add pipe 3 all from 192.168.15.1 to any src-port 3128 out
add queue 1 all from any to any out xmit vlan0
add queue 2 all from 192.168.15.1 to any outДля каждого клиентского IP-адреса по маске динамически создаёт по одной очереди в каждом направлении и справедливо распределяет пропускную способность между ними не требуя указания пропускной способности канала Internet. Сделайте подобное на FreeBSD с помощью PF.
>Ничего не имею против IPFW, но прежде чем говорить что какая-то из
>служб что-то не умеет все же стоит документацию хотя бы глянуть.Это вы товарищу Осторожный скажите. Я ему хотел сказать, что если он не знает недостатки PF значит он его плохо знает.
>Оба фильтра замечательно выполняют свои функции, и могут полностью заменить друг друга.
Отличия есть и потому использую оба в разных ситуациях.
>Тут дело вкуса, и кто к чему привык/лучше знает.
Не согласен. Знать надо оба три :-) (ipfw,pf,ipf) чтобы выбрать и использовать лучшее или более подходящее к конкретной ситуации.
По поводу natd и всяких извратов в несколько сетей во FreeBSD - http://www.it-ramenskoe.ru/freebsd_1.html
>По поводу natd и всяких извратов в несколько сетей во FreeBSD - http://www.it->ramenskoe.ru/freebsd_1.htmlну чего вы лажу всякую тут продвигаете!
Эта "лажа" как раз и работает без всяких проблем.
А если у Вас есть Ваша "не лажа" - будьте добры поделиться с остальными (В чем я сильно сомневаюсь ...)