Мы — долго запрягаем, быстро ездим, и сильно тормозим.
www.lissyara.su —> статьи —> FreeBSD —> настройка —> Заметки об IPFW

Заметки об IPFW

Автор: -cat-.


Вместо предисловия:
Вопрос- "В FreeBSD есть 3 разных фаервалла, какой использовать?"
Ответ - "Правильно насторенный."
Далее по тексту обсуждается IPFW как наиболее часто используемый во FreeBSD фаервалл.
Как задействовать IPFW?
Как известно существует два способа подключения IPFW:
1. Подключение скомпилированного модуля ядра при загрузке системы.
2. Комплияция IPFW в ядро системы.
Начнем с последнего - компиляция IPFW в ядро, в MAN-ах этот пункт достаточно подробно освещен:
Обычно ипользуются следующие опции в конфиге ядра:

options	IPFIREWALL

- подключение IPFW

options	IPFIREWALL_VERBOSE

- проходящие пакеты записываются в лог-файл, при использовании опции log в правилах

options	IPFIREWALL_VERBOSE_LIMIT=100


-ограничение количества записей в лог-файл по одному правилу, в правилах IPFW значение можно изменить через опцию logamount

options	IPFIREWALL_FORWARD

- форвардинг пакетов, очень полезная опция при настройке прозрачного прокси на машине, где одновременно работает IPFW и прокси-сервер (например SQUID или FROX)

options	IPDIVERT


- подключение поддержки NATD (трансляция адресов)

options	DUMMYNET

- поключение функций управления трафиком (ограничение ширины канала, имитация задержек и потерь пакетов), и наконец для правила по умолчанию, которое присутствует в конфиге IPFW в любом случае под номером 65535, будет

allow ip from any to any

- если включена опция

options	IPFIREWALL_DEFAULT_TO_ACCEPT

- либо,

deny ip from any to any


- если отсутствует.
После сборки и установки нового ядра получаем IPFW встроенный в ядро системы.
Теперь о подключение модулем, тут все проще и сложнее одновременно.
Подключение IPFW в качестве модуля ядра, осуществляется одной командой:

kldload ipfw

- при этом загружается модуль ipfw.ko, который в стандартной поставке имеет поддержку функций управления трафиком (DUMMYNET), к сожалению функции форвардинга (FORWARD) не поддерживаются и без перекомпиляции тут не обойтись.
Поддержку демона NATD в IPFW можно получить, загрузив аналогичной командой модуль ipdivert.ko

kldload ipdivert

IPFW, загруженный таким образом, содержит всего одно правило по умолчанию:

deny ip from any to any

Рассмотрим теперь как происходит подключение IPFW в процессе загрузки операционой системы. Имеем достаточно типовые переменные в файле /etc/rc.conf

firewall_enable="YES"
firewall_script="/usr/local/etc/ipfw.rules"
natd_enable="YES"
natd_interface="fxp1"
natd_flags="-same_ports"

Первая строка фактически разрешает исполнение стартового скрипта /etc/rc.d/ipfw, который в свою очередь, выполняет уже известную команду

kldload ipfw

- если IPFW грузится модулем ядра,  затем запускает на выполнение скрипт с правилами IPFW, указанный во второй строке. Заметим что строка

firewall_enable="YES"

-требуется как для загрузки IPFW в виде модуля (иначе запускать придется вручную), так и для IPFW компиллированном в ядро (иначе не выполнится скрипт с правилами из второй строки, хотя IPFW все равно запустится с одним правилом по умолчанию). В процессе выполнения скрипт /etc/rc.d/ipfw установит значение системной переменной равным единице (TRUE):

net.inet.ip.fw.enable=1

Она указывает системе использовать ли IPFW вообще, так как если переменная равна нулю (FALSE), то IPFW использоваться не будет, независимо от того подгружаем ли мы модулем IPFW или он скомпилирован в ядро, попутно отметим следующее: все переменные, которыми можно управлять через sysctl действуют на IPFW одинаково, независимо от способа подключения IPFW.
Продолжим строка:

firewall_script="/usr/local/etc/ipfw.rules"


указывает расположение нашего скрипта с правилами для IPFW, в принципе её может и не быть, но тогда запустится на исполнение скрипт /etc/rc.firewall, в котором есть стандартные наборы правил, сгруппированные в секции "OPEN","SIMPLE","CLOSED","UNKNOWN", можно также приспособить его под свои нужды (хотя это и не наш метод :-)), например добавив секцию "RULES", тогда данная строка приобретёт вид:  

firewall_type="RULES"

По поводу строк с NATD сказать особо нечего, все аналогично уже рассмотренному с той разницей что исполняется скрипт /etc/rc.d/natd, и если IPFW используется в виде модуля ядра -загрузится модуль ipdivert.ko, потом скрипт выполнит команду вида:

natd -interface ${natd_interface} -same_ports

и ещё, если IP интефейсa на котором крутится NATD получен от DHCP-сервера, скрипт добавит опцию "-dynamic".
Замечание 1.
Как все-таки подключать IPFW? Пожалуй решение такое: если FreeBSD используется в целях обучения, отладки и т.д. - проще подключать модулем, а если речь идет уже о "боевом" применении - лучше компиляция в ядро.
Как IPFW работает?
Общая схема


Замечание 2.
IP- Пакет, попадая в фаервал IPFW, следует согласно порядку расположений его правил до первого удовлетворяющего, где над этим IP-пакетом, согласно данному правилу, совершаются какие-либо действия (пропускается, отбрасывается, возвращается обратно в фаервал и т.д.).
Замечание 3.
Входящие (IN) и исходящие (OUT) пакеты следует рассматривать относительно операционной системы, а не относительно сетевых интерфейсов.
Замечание 4.
Каждый маршрутизируемый IP-пакет попадает в фаервал как на входе в операционную систему, так и на выходе из неё.

Рассмотрим, с учётом этих замечаний, следующие примеры и попытаемся в итоге понять проходят IP-пакеты по правилам IPFW и как составлять эти самые правила.
Предположим:
1. Система имеет 2 сетевых интерфейса – {iif}- внутренний(fxp0)  и {oif}-внешний(fxp1), псевдоинтефейc-{lo}, который мы намеренно опустим из виду.
2.  {iip} – IP- адрес для {iif}, и соответственно {oip} – для {oif}.
3.  {MyLan} -  внутренняя сеть
4. В системе работает простейший демон NATD по трансляции внутренних адресов во внешний и наоборот.
Пример №1. Как составлять правила?
Имеем следующее не совсем очевидное, зато очень часто встречающееся правило:
{fwcmd} add allow ip from {MyLan} to any

Обычно когда пишут такое правило - подразумевают что разрешен доступ от хостов внутренней сети к любому хосту (при этом, часто полагают что речь идет только о внутренней сети :-) ), но есть и еще одна сторона медали, постараюсь её показать.
С учетом вышеописанных замечаний данное правило распишем в следующий набор правил:

1. {fwcmd} add allow  ip from {MyLan} to any in via {iif}
2. {fwcmd} add allow  ip from {MyLan} to any out via {iif}
3. {fwcmd} add allow  ip from {MyLan} to  any out via {oif}
4. {fwcmd} add allow  ip from {MyLan}  to any in via {oif}

Правило №1 - мы разрешаем обращение от любого хоста внутренней сети на любой xoст любой сети через внутренний интерфейс, аналогично и для правила №3, но через внешний интерфейс.
Фактически эти два правила разрешают  исходящие IP-пакеты от хостов внутренней сети к любым хостам любой сети.
А теперь о том, что не так очевидно: правило №2, с учётом правила №1 фактически разрешает IP-пакеты между хостами локальной сети через интерфейс {iif}, что нормально, если предположить что в локальной сети хакеров нет, пользователи послушные, сами на роутер не полезут и делать там нечего плохого не будут. Однако сюрприз!
Теперь правило №4 - с одной стороны оно достаточно бессмысленное. Действительно откуда снаружи взяться IP-пакетам от хостов внутренней сети?
Правильно – хакеры, типичный спуфинг.
Критики могут заметить, что со спуфингом умеет бороться чуть ли не каждая железяка, что демоны давно поумнели и т.д. и т.п. Тем не менее, согласитесь, такие правила боевой роутер совсем не красят, поэтому сюрприз №2.  
Можно уже делать первые выводы:
Вывод №1.
При составлении правил обязательно указывать о какой сетевом интерфейсе идет речь.
Вывод №2.
При составлении правил желательно указывать направление IP-пакетов.
Вывод №3.
При составлении правил по возможности конкретизировать сети и  IP - адреса.

Первые выводы сделаны, давайте попробуем разобраться как IP-пакеты бегают по правилам, которые мы напишем.
Пример №2. Связка IPFW-NATD, как работает, какие нужны правила?
Итак: исходные заданы, напишем правила IPFW, и прокомментируем их.

#Разрешим трафик в локальной сети, конкретизировать по
# направлению не будем и так понятно: 
1  {fwcmd} add allow  ip from {MyLan} to {MyLan} via {iif}
#Вспомним про  NATD.
2. {fwcmd} add divert natd ip from {MyLan} to any out via {oif}
3. {fwcmd} add divert natd ip from any to {oip} in via {oif}
#Роутер должен же как-то работать - изнутри мы уже все открыли,
#будем последовательны тоже сделаем и снаружи.
4. {fwcmd} add allow  ip from {oip} to any out via {oif}
5. {fwcmd} add allow  ip from  any  to {oip} in via {oif}
#Роутер у нас или нет?  Давайте разрешим локальным хостам 
# свободно лазить во внешнюю сеть.
#Для исходящих пакетов от хостов внутренней сети.
6. {fwcmd} add allow ip from {MyLan} to any in via {iif}
7.{fwcmd} add allow ip from {MyLan} to any out via {oif}
#Для входящих IP-пакетов к хостам внутренней сети.
8. {fwcmd} add allow ip from any to {MyLan} in via {oif}
9. {fwcmd} add allow ip from any to {MyLan} out via {iif}
#Для порядка завершим
10. {fwcmd} add deny ip from any to any

Получили такой вот конфиг IPFW, хотя могли обойтись всего-то одной строчкой

{fwcmd} add allow ip from any to any

Примечание - Фактически правило №1 не нужно, т.к. его расширили правилами №6,№9, однако оставим его, поскольку в реальных условиях надо редактировать как раз с №6 по №8, да и само по себе правило №1 не самое удачное решение в плане широковещательных запросов.
Пусть хост внутренней сети (192.168.0.75) запрашивает почту с gmail.com (64.233.183.109:995), для нашего роутера внешний IP- 195.34.32.55.
Забудем про DNS, сразу к делу - какими видит IPFW проходящие пакеты:
Правила №-№ 1-5 не подходят, а вот №6 как раз в точку:

TCP 192.168.0.75:1499 64.233.183.109:995 in via fxp0


так пошел запрос на внутренний интерфейс (fxp0) роутера, с хоста внутренней сети. Операционная система приняла его и по таблице маршрутизации отправила на внешний интерфейс (fxp1), здесь этот пакет стал исходящим и снова уперся в фаервал:

TCP 192.168.0.75:1499 64.233.183.109:995 out via fxp1

тут вступает в действие NATD (правило №2) он переписывает IP в заголовке пакета, составляет таблицу где запоминает что он сотворил с пакетом и благополучно отпускает путешествовать по правилам IPFW дальше, что собственно будет выглядеть так:

TCP 195.34.32.55:1499 64.233.183.109:995 out via fxp1

кстати NATD сохранил еще и первоначальный порт 1499, что бывает далеко не всегда. Этот пакет дойдет до правила №4, благополучно покинет фаервал и отправится путешествовать в сеть.
Теперь рассмотрим как идет ответ сервера:
Ответный пакет входит в файервал снаружи через внешний интерфейс fxp1:

TCP 64.233.183.109:995 195.34.32.55:1499 in via fxp1


как видно с какого порта запросили на тот ответ и получили. Правила №1,№2 он благополучно миновал а в правиле №3 его радостно встречает NATD, который проверяет свою таблицу, находит запись и переписывает заголовок уже на:

TCP 64.233.183.109:995 192.168.0.75:1499 in via fxp1


по правилу №8 пакет выходит из IPFW и попадает в операционную систему, которая маршрутизирует пакет на интерфейс внутренней сети (fxp0), здесь пакет опять упрется в фаервал но уже, как исходящий с интерфейса внутренней сети fxp0.

TCP 64.233.183.109:995 192.168.0.75:1499 out via fxp0

– правило №9 благополучно выпустит пакет из фаервала. Счастливый хост получил ответ на свой запрос.
Дайте рассмотрим ещё один случай связки IPFW-NATD - перенаправление входящего запроса на сервер внутренней сети.
Предположим мы хотим открыть для доступа снаружи Web-сервер внутренней сети с IP-адресом 192.168.0.3, для чего изменим в rc.conf строку на

natd_flags="-same_ports -redirect_port tcp 192.168.0.3:80 80"

В логах IPFW можно будет увидеть примерно следующее:

1. TCP 195.34.32.56:1076 195.34.32.55:80 in via fxp1
2. TCP 195.34.32.56:1076 192.168.0.3:80 in via fxp1
3. TCP 195.34.32.55:1076 192.168.0.3:80 out via fxp0
4. TCP 192.168.0.3:80 195.34.32.56:1076 in via fxp0
5. TCP 192.168.0.3:80 195.34.32.56:1076 out via fxp1
6. TСP 195.34.32.55:80 195.34.32.56:1076 out via fxp1

Ситуация аналогична уже рассмотренной:
первая строка и вторая строка - один и тот же пакет - входящий запрос, который попадает в NATD через внешний интрефейс fxp1. NATD переписывает заголовок пакета и далее по правилам IPFW пакет попадает в операционную систему.
третья строка - пакет прошедший по таблице маршрутизации операционной системы, исходящий через внутренний интерфейс fxp0.
четвертая строка - ответ сервера входящий на внутренний интерфейс fxp0.
пятая и шестая строки - один и тот же пакет, прошедший через NATD и ставший исходящим через внешний интерфейс fxp1.
Примечание:MAN NATD - "После трансляции адреса, демон NATD, возвращает IP-пакет в фаервал IPFW к правилу со следующим номером после правила с DIVERT (не следующее правило, а правило со следующим номером)."
Чтобы закончить со связкой IPFW-NATD, составим примерный список правил для конфига IPFW, обеспечивающий работоспособность данной связки :

#Разрешаем все по интерфейсу обратной петли
{fwcmd} add allow ip from any to any via lo 
#Разрешаем все внутри локальной сети, 
#кроме того эти правила необходимы для связки IPFW-NATD
#Для защиты роутера от пользователей локальной сети перед этими правилами
#нужно вcтавить что-то запрещающее
#Если есть необходимость роутеру в широковещательных запросах
#нужно вставить что-то разрешающее
{fwcmd} add allow ip from {MyLan} to any in via {iif} 
{fwcmd} add allow ip from any to {MyLan} out via {iif}
#Разрешаем входящие соединения к роутеру, 
#это правило напрямую к связке IPFW-NATD отношения не имеет, 
#оно необходимо для обеспечения работоспособности демонов роутера.
#Естественно правило необходимо расширить с учетом потребностей демонов.
#Внимание!!! правила расположены выше DIVERT,
# т.е в этом примере для хостов внутренней сети 
#DNS сервер должен быть внутри сети 
{fwcmd} add allow ip from any to {oip} 53 in via {oif} 
{fwcmd} add allow ip from any 53 to {oip} in via {oif} 
#NATD для исходящих соединений 
{fwcmd} add divert natd ip from {MyLan} to any out via {oif}
#Внимание!!! Правило - разрешает исходящие соединения как для самого роутера, 
#так и для хостов внутренней сети, IP которых транслировал NATD
{fwcmd} add allow ip from {oip} to any out via {oif}
#NATD для входящих соединений
{fwcmd} add divert natd ip from not {MyLan} to {oip} in via {oif}
#Внимание!!! Правило - разрешает входящие соединения только к хостам внутренней сети,
#IP которых транслировал NATD
{fwcmd} add allow ip from not {MyLan} to {MyLan} in via {oif}
{fwcmd} add deny ip from any to any

Ну и последнее замечание по поводу IPFW-NATD:
Что делать если требуется что-то прикрыть в интернете для хостов внутренней сети? Ответ достаточно очевиден:
1. Впереди правил для локальной сети (строки 2-3) пишем свои запреты.
Ну и наоборот если требуется все запретить, разрешив только что-то: к примеру HTTP?
2. Приводим строки 2-3 к следующему виду:

{fwcmd} add allow ip from {MyLan} to {MyLan} via {iif} 
{fwcmd} add allow tcp from {MyLan} to any http in via {iif}
{fwcmd} add allow tcp from any http to {MyLan} out via {iif}

Полагаю тема связки IPFW-NATD закрыта.
Продолжим исследования, разберем еще один частоиспользуемый случай IPFW-SQUID.
Сначала без прозрачного прокси. Вернемся к первому варианту конфига IPFW и рассмотрим что происходит. Вот и подходящий кусочек лога:    

TCP 192.168.0.112:1212 192.168.0.9:3128 in via fxp0


-входящий пакет от внутреннего хоста к роутеру с работающим Squid - правило №1, Squid его обработает и сам отправит в сеть.

TCP 195.34.32.55:52439 64.12.24.102:443 out via fxp1

-исходящий пакет от SQUID к удаленному хосту - правило №4

TCP 64.12.24.102:443 195.34.32.55:52439 in via fxp1

- входящий ответ на интерфейс внешней сети - правило № 5, Squid опять же его обработал, и ответил хосту локальной сети

TCP 192.168.0.9:3128 192.168.0.112:1212 out via fxp0

- правило №1, пакет вышел из фаервала и побежал к адресату.
Пример несколько утрированный, однако интересен следующим:
Первое - NATD не используется, а вернее так: в NATD входящий пакет от хоста 64.12.24.102:443 все равно попадет, правило №3 никто не отменял. Однако NATD об этом пакете ничего не знает, поэтому делать ничего не будет, он отправит пакет дальше путешествовать по правилам IPFW, пока последний не доберется до правила №4.
Второе - сам адресат: 64.12.24.102:443 - протокол https, а хост из сети 64.12.0.0/16 AOL-MTC, т.е. ICQ.
Продолжим, теперь на очереди прозрачный прокси, для него изменим правила IPFW следующим образом: добавив строку для форвардинга в итоге получим:

1. {fwcmd} add allow  ip from {MyLan} to {MyLan} via {iif}
2. {fwcmd} add fwd {iip},3128 tcp from {MyLan} to not {MyLan} 80 in via {iif}
3. {fwcmd} add divert natd ip from {MyLan} to any out via {oif}
4. {fwcmd} add divert natd ip from to any to {oip} in via {oif}
5. {fwcmd} add allow  ip from {oip} to any out via {oif}
6. {fwcmd} add allow  ip from  any  to {oip} in via {oif}
7. {fwcmd} add allow ip from {MyLan} to any in via {iif} 
8. {fwcmd} add allow ip from {MyLan} to any out via {oif}
9. {fwcmd} add allow ip from any to {MyLan} in via {oif}
10. {fwcmd} add allow ip from any to {MyLan} out via {iif}
11. {fwcmd} add deny ip from any to any

Предположим хост внутренней сети с IP 192.168.0.100 запрашивает http://www.yandex.ru, на входе в фаервал имеем:
TCP 192.168.0.100:1083 77.73.24.4:80 in via fxp0

-пакет доходит до правила №2, по которому переправляется на вход локального прокси-сервера, далее уже знакомая картина самостоятельной обработки прокси-сервером запроса:
TCP 195.34.32.55:57415 77.73.24.4:80 out via fxp1
TCP 77.73.24.4:80 195.34.32.55:57415 in via fxp1

- наконец ответ хосту, а здесь уже интересно, поскольку прокси-сервер ответил следующим образом:
TCP 77.73.24.4:80 192.168.0.100:1083 out via fxp0

Как видим для хоста внутренней сети все махинации с прокси-сервером остались не заметны.
Опять оговоримся: в примере рассмотрен только принцип прохождения пакета, реальный лог совсем не такой однозначный.
Чтобы закончить тему связки IPFW-SQUD напишем примерные правила для IPFW:

{fwcmd} add allow ip from any to any via lo 
#Собственно следующие строки не только для локальной сети,
#они ещё задают варианты использование прокси для обычного достаточно
{fwcmd} add allow ip from {MyLan} to {MyLan} via {iif} 
#для прозрачного
#Здесь мы попали в засаду с портами, впрочем это только начало
#{fwcmd} add fwd {iip},3128 tcp from {MyLan} to not {MyLan} 80,443 in via {iif}
#{fwcmd} add allow tcp from {MyLan} to any 80,443 in via {iif} 
#{fwcmd} add allow tcp from any 80,443 to {MyLan} out via {iif}
#{fwcmd} add allow ip from {MyLan} to {MyLan} via {iif}
#Так подробно расписано специально чтобы была видна разница в правилах.

#Разрешаем входящие соединения к роутеру, 
#вообще эти правила напрямую к связке IPFW-SQUID отношения не имеют, 
#правда с DNS не все так однозначно.
{fwcmd} add allow ip from any to {oip} 53 in via {oif} 
{fwcmd} add allow ip from any 53 to {oip} in via {oif} 

#Правила для SQUID, тут чтобы опять не попасть в засаду с портами, 
#извернемся следующим образом
{fwcmd} add deny  tcp from any to {oip} in via {oif} tcpflags syn,!ack
{fwcmd} add allow tcp from any to {oip} in via {oif} 
#Завершим традиционно
{fwcmd} add allow ip from {oip} to any out via {oif}
{fwcmd} add deny ip from any to any

Расставим точки над i - обьединим два рассморенных случая вместе, тем самым создадим эдакий скелет конфига IPFW для подгонки под свои требования.

#!/bin/sh -
fwcmd=/sbin/ipfw

# Внешний интерфейс
oif=xxx
oip=xxx.xxx.xxx.xxx

# Внутренний интерфейс
iif=xxx
iip=xxx.xxx.xxx.xxx
MyLan=xxx.xxx.xxx.0/24

# Хосты сети, которым разрешим свободно ходить в инет  через роутер
pdc=xxx.xxx.xxx.xxx,xxx.xxx.xxx.xxx

${fwcmd} flush -f

#Стандартное средство защиты от спуффинга :-)
${fwcmd} add deny ip from any to any not verrevpath in

# Убьем фрагменты
${fwcmd} add deny ip from any to any frag

${fwcmd} add allow ip from any to any via lo
${fwcmd} add denny ip from any to 127.0.0.0/8 
${fwcmd} add denny ip from 127.0.0.0/8 to any

${fwcmd} add allow ip from ${MyLan} to ${MyLan} via {iif}  
${fwcmd} add allow ip from ${pdc} to any in via ${iif} 
${fwcmd} add allow ip from any to ${pdc} out via ${iif}

${fwcmd} add divert natd ip from ${MyLan} to any out via ${oif}
${fwcmd} add allow ip from ${oip} to any out via ${oif}

${fwcmd} add divert natd ip from any to ${oip} in via {oif}
${fwcmd} add allow ip from any to ${MyLan} in via {oif}

#Правила для демонов перенесли ниже потому что они
# перекрывают входящие пакеты для NATD
#Следующие два правила равносильны одному
#${fwcmd} add allow tcp from any to ${oip} in via ${oif} established
${fwcmd} add deny  tcp from any to ${oip} in via ${oif} tcpflags syn,!ack
${fwcmd} add allow tcp from any to ${oip} in via ${oif} 

${fwcmd} add allow udp from any to ${oip} 53 in via ${oif} 
${fwcmd} add allow udp from any 53 to ${oip} in via ${oif} 

${fwcmd} add allow icmp from any to ${oip} in via ${oif} icmptype 0,3,4,8,11,12

${fwcmd} add deny log ip from any to any



Как правило IPFW, NATD, SQUID и еще куча различных демонов крутится на одной машине-роутере, как уже было видно для каждого демона по отдельности правила IPFW имеют много общего, но и каждый имеет свои нюансы, поэтому при составлении (редактировании) необходимо крайне внимательно проверять то что уже есть, добавляя  только то что требуется, иначе вместо логичной и непробиваемой огненной стены можно получить абсолютно непонятное решето.
Очень хочется думать, что статья поможет вам в создании безопасных, а главное осознанных правил IPFW, спасибо всем кто сумел сие прочитать, за сим откланиваюсь.
-cat-
P.S. Автор сознательно не использовал конструкции setup-established и check-state keep-state.
setup-established запутали бы процесс понимания правил, keep-state же напустил бы туману еще больше.
P.P.S. В процессе сочинения сего использовались логи реально работающего роутера,  а также различные виртуальные машины, логи собраны при помощи строки {fwcmd} add count log all from any to any.
Совпадения IP - реальных случайны, случайных - не реальны. ;-).



размещено: 2007-10-24,
последнее обновление: 2007-11-01,
автор: -cat-


smilealex, 2007-10-24 в 14:01:25

Спасибо! Данная заметка о составлении правил для IPFW внесла необходимую лепту в дело укрепления понимания моим слегка тугим мозгом логики работы файерволла! следующим буду вдалбливать в себя необходимое понимание синтаксиса написания правил!
в частности директива "virrevpath" ваще на глаза ни разу не попадалась!

www2, 2007-10-24 в 15:14:13

В документации virrevpath описано как verrevpath. А ещё есть antispoof.

-cat-, 2007-10-24 в 15:37:44

Ошибку исправил, antispoof частный случай verrevpath о чем MAN собственно предупреждает

smilealex, 2007-10-24 в 15:39:01

сори за офтоп)) ковыряюсь в мануале по ipfw, и вот что я там вижу))

  BASIC PACKET FILTERING
    This command adds an entry which denies all tcp packets from
    cracker.evil.org to the telnet port of wolf.tambov.su from being for-
    warded by the host:

          ipfw add deny tcp from cracker.evil.org to wolf.tambov.su telnet

улыбнуло))

Corvin, 2007-10-24 в 23:26:04

Наконец-то появилась действительно классная статья на РОДНОМ языке! Огромное человеческое спасибо! Пока настраивал свой роутер пол нета перерыл, собирая информацию по крупицам... А тут такая статья!!! Еще раз, спасибо!

alcohollica, 2007-10-25 в 1:26:44

не раскрыта тема пропуска трафика из внутреней сети по ftp протоколу :(

tigos2, 2007-10-25 в 6:08:59

а разве следующие строки в rc.conf не нужны для пущей надёжности:
tcp_extensions="NO"
tcp_drop_synfin="YES"
icmp_drop_redirect="YES"
icmp_log_redirect="YES"

butcher, 2007-10-25 в 8:36:54

Везде потерян символ доллара в конструкциях типа {fwcmd}

max, 2007-10-25 в 9:01:41

Можно полюбопытствовать?
А зачем убивать фрагменты IP?
add deny ip from any to any frag

-cat-, 2007-10-25 в 10:46:40

1. Друзья мои!!!!
Даже не знаю как обратиться, давайте все несущественные замечания перенесем в форум там есть ветка называется "Заметки о IPFW, надо ли это?" убедительно прошу все замечания складывать туда, обязуюсь ответить.
2. Комментарии прошу оставлять по поводу найденных ошибок.
3. Ни в коем случае не следует рассматривать показанные  правила IPFW как руководство к действию, это лишь скелет который требует основательной доработки, причем не лишенный ощибок.

Дед Пихто, 2007-10-26 в 10:31:18

автор мудаг

lissyara, 2007-10-26 в 11:09:44

ну вот и гоблины :)

andrej, 2007-11-09 в 18:17:44

Автор на высоте. Статья расставила все на свои места, и теперь возникло желание перестроить свой ipfw наново. Прямо таки чувтвую прозрение и ясность мысли :). Раньше слова ipfw и ясность мысли я бы не рискнул упоминать вместе. Спасибо! Продолжайте- отличный сайт !!!

Dyr, 2007-11-11 в 21:20:36

Статья вроде неплохая, но просматривал наискосок. Из того, что хотелось бы отметить
1. Начиная с 6.2-STABLE, если не ошибаюсь, в man ipfw употребление NAT'a дано через ядерный nat, и соответственно, конфигурирование как ipfw nat xxx config... и требующему наличия в ядре опции LIBALIAS.
2. natd всё же не самое удачное по производительности решение, я рекомендую ng_nat, как достаточно простой и быстрый способ.

adre, 2007-11-19 в 3:43:17

всю ночь ковырялся не понемал почему негуда не ходит =)
автору +1

brahmann, 2008-04-20 в 15:24:04

автор молодец!+1
спасибо) хоть и лет 12 во фре уже.. со старых времен.. но негде нету на родном языке мануалов, а народу давать читать на аглицком это убийство) спасибо

adminMK, 2008-05-09 в 16:22:37

Хорошая статья. Для понимания основ самое оно. Теперь бы продолжение с пояснением директив:
setup-established;
check-state; keep-state.
Спасибо!

denzill, 2008-06-05 в 13:01:19

denny в конечном конфиге надо исправить на deny

denzill, 2008-06-05 в 13:17:21

кстати, https через прозрачный прокси - не работает
про denny->deny я уже отписал
а так статья классная, спасибо.

индеец, 2008-09-04 в 16:40:25

про пайпы бы ещё расписать также
цены бы не было

alex3, 2008-09-16 в 9:41:36

Замечание 4.
Каждый маршрутизируемый IP-пакет попадает в фаервал как на входе в операционную систему, так и на выходе из неё.
Надо уточнить, что это действует, если машина не в режиме моста, а в режиме gateway, иначе пакет проходит по правилам один раз.

Сергей, 2008-09-17 в 15:27:39

На сколько, я понял ipfw, схема прохода пакета такая
->|+-----||->
<-|| ОС  ||<-
 ||     ||
 |+-----+|
 +-------+
т.е. пакет входит через ipfw, входит в ОС и выходит, попадая опять в ipfw, или отбрасывается на каком-либо этапе (это для шлюза)

Damon_X, 2008-11-18 в 14:43:26

Спасибо большое за статью. Ничего подобного нигде больше не видел. Все очень доходчиво и понятно. Просто незаменимая на начальных этапах!

F2x0FF004, 2008-12-05 в 11:33:39

Спасибо и от меня :) Я стал лучше понимать теорию.

Temik, 2008-12-29 в 19:30:33

Спасибо автору за статью! Базовые вещи отлично описаны! Хорошо бы ng_nat разжевать еще:)

Ща пивка бы, 2008-12-30 в 23:17:23

да собственно гуру поработал на славу

adminMK, 2009-01-20 в 22:36:23

-ЦИТИРУЮ:
#Вспомним про  NATD.
2. {fwcmd} add divert natd ip from {MyLan} to any out via {oif}
3. {fwcmd} add divert natd ip from any to {oip} in via {oif}
#.....
..cut..
......
7.{fwcmd} add allow ip from {MyLan} to any out via {oif}
--
не совсем ясно, что делает правило №7 если все пакеты которые оно должно пропустить уже перенаправлены в НАТ (правило 2).

lubitel, 2009-02-03 в 22:21:24

${fwcmd} flush -f
в в ерсии FreeBSD 6.2-RELEASE-p12

при  загрузке системы давало остановку  с вопростом и "вы уверены?(да/нет)"

сменил на ${fwcmd} -f flush , заработало нормально

ZooBastik, 2009-07-16 в 18:34:40

>> {fwcmd} add allow ip from any to {oip} 53 in via {oif}
>> {fwcmd} add allow ip from any 53 to {oip} in via {oif}

Правила ipfw с указанием портов могут применяться только к протоколам tcp и udp. Если указать их в таком виде система укажет на ошибку использования обматюкавшись на вражьем языке. Можно переписать на :
{fwcmd} add allow tcp,udp from any to {oip} 53 in via {oif}
Хотя конкретно для запросов DNS наличие tcp сомнительно, по udp они ходят.

Отличная статья! Очень понятно, логично, четко. Автор - пиши исчо! :)

Bionicman, 2009-07-19 в 17:14:30

ZooBastik, по порту 53/tcp DNS тоже используется, к примеру для трансфера зон.

erg, 2009-10-22 в 12:56:06

[url=введите_адресоля для ввода комментариев к статье, а не для вопросов. Сюда пишите найденные баги, или какие-то фичи :)
Для вопросов есть форум![/url][url=введите_адрес]

mediamag, 2010-02-18 в 12:43:20

хотелось бы точно такую же статью, но по keep-state и check-state

ups91, 2010-09-03 в 2:48:54

Сама статья довольно точно представляет собой перевод
файла /etc.rc.firewall для случая "simple".
Автор сделал только дополнение с пайпами, контру и
еще парочку НЕ УДАЧНЫХ "исправлений" для ДНС.
Для хостов ЗА таким файрволом будет доступен ТОЛЬКО ДНС сервер на ЭТОЙ ЖЕ машине (а если его там нет - то имена развязываться НЕ БУДУТ).

lerico, 2011-08-26 в 14:11:36

спасибо большое за статью

Михаил, 2017-03-04 в 16:01:20

В 2017 настройки ещё актуальны?



 

  Этот информационный блок появился по той простой причине, что многие считают нормальным, брать чужую информацию не уведомляя автора (что не так страшно), и не оставляя линк на оригинал и автора — что более существенно. Я не против распространения информации — только за. Только условие простое — извольте подписывать автора, и оставлять линк на оригинальную страницу в виде прямой, активной, нескриптовой, незакрытой от индексирования, и не запрещенной для следования роботов ссылки.
  Если соизволите поставить автора в известность — то вообще почёт вам и уважение.

© lissyara 2006-10-24 08:47 MSK

Время генерации страницы 0.2495 секунд
Из них PHP: 64%; SQL: 36%; Число SQL-запросов: 78 шт.
Исходный размер: 85133; Сжатая: 17870