Замечание 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 - реальных случайны, случайных - не реальны. ;-).