Мы — долго запрягаем, быстро ездим, и сильно тормозим.

FreeBSD
  настройка
  начальная настройка
  Установка FreeBSD
  DUMMYNET
  Сборка ядра
  IPFW
  обновление
  portsnap
  CP1251 на FreeBSD
  loader.conf
  defaults/rc.conf
  jail
  Ntpdate/Ntpd
  diskless
  Обновление мира ("world")
  PBR & PF
  bsnmpd
  newsyslog
  if_bridge
  make.conf
  PBR & IPFW
  Работа с HDD
  sshd & AD
  Удаленное разбиение HDD
  Заметки об IPFW
  FreeBSD на VDS
  CVSUP и софт через Proxy
  i386=>amd64
  ALTQ в IPFW
  Виртуальный свитч
  VPN сервер по средствам mpd5.
  NTP
  sysupdate
  mpd5 L2TP
  freebsd + webcamera
  IPFW policy (PBR)
  RAID1 via LAN
  зеркальный RAID1 на ОС FreeBSD
  4.x => 7.x
  portdowngrade
  Быстрое обновление портов
  ipfw nat
  Использование csup
  UTF-8 console
  cvs, svn, portsnap
  dump/restore
  hast carp zfs ucarp cluster
  ng_nat
  Wi-FI роутер + DHCP + DNS
  backup/restore & ZFS
  Обновление ОС и портов через SVN.
  подсчёт трафика
  программы
  почтовые системы
  Шелезяки
  Мелочи
  Файловая система
  WWW
  Security
  system
  Games Servers
  X11
  Programming
Очумелые Ручки
OpenBSD
Cisco


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



Ссылка на обсуждение: http://forum.lissyara.su/viewtopic.php?t=5511.

размещено: 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

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


Оставьте свой комментарий:
Ваше имя:   *
e-mail:  
жирный
наклонный
подчёркнутый
ссылка
цвет
Нынешний год:   *
 


Хостинг HOST-FOOD

2014-07-27, lissyara
gmirror

Удалённое создание софтверного зеркала средствами gmirror, на диске разбитом с использованием gpart. Использование меток дисков для монтирования разделов.
2013-08-20, zentarim
Scan+Print server FreeBSD 9

Настройка сервера печати и сервера сканирования под управлением операционной системы FreebSD 9 для МФУ Canon PIXMA MP540
2011-11-20, BlackCat
Разъём на WiFi-карту

Делаем съёмной несъёмную антену на WiFi-карте путём установки ВЧ-разъёма
2011-09-14, manefesto
Настройка git+gitosis

Настройка системы контроля версия исходного кода в связке git+gitosis+ssh
2011-08-14, zentarim
Wi-FI роутер + DHCP + DNS

Настройка Wi-Fi роутера на Freebsd 8 + DNS сервер + DHCP сервер: чтобы Wi-Fi клиенты были в одной подсети с проводными, проводные и беспроводные клиенты получали адреса автоматически по DHCP, кэширующ
2011-06-15, -ZG-
Охранная система на FreeBSD+LPT

В этой статье описана попытка реализации простой охранной системы на базе FreeBSD с подключением к ней охранных устройтсв на LPT порт и видеорегистрацией.
2011-03-13, terminus
ng_nat

Описание работы ng_nat, практическое использование, достоинства и недостатки в сравнении с ipfw nat
2011-02-20, Капитан
Nagios+Digitemp

Статья описывает создание системы оповещения о превышении температуры в специальных помещениях на основе Nagios с использованием программы Digitemp.
2011-02-17, Le1
Zyxel Configuration

Скрипт для массового изменения конфига свичей Zyxel. Берет из файла iplist список ip-шек, заходит последовательно на каждый и выполняет комманды из файла commands, записывая происходящее в лог файл.
2011-02-16, fox
hast carp zfs ucarp cluster

HAST (Highly Available Storage), CARP, UCARP, ZFS, Cluster настройка и одаптация плюс личные размышления…
2011-02-04, BlackCat
Восстановление ZFS

История о том, как был восстановлен развалившийся RAIDZ ZFS-пул (перешедший в FAULTED) с помощью скотча и подручных средств. Или о том, какие приключения ожидают тех, кто не делает резервных копий.
2011-02-03, Капитан
1-Wire

Статья описывает самостоятельное изготовление контроллера DS9097 для съёма показаний с датчиков температуры DS1820 с помощью программы Digitemp.
2011-01-28, Капитан
Температура в серверной

Статья описывает построение системы наблюдения за температурой в помещении серверной с использованием программы Digitemp и выводом графиков в MRTG
2011-01-21, m4rkell
Syslog server

Как то буквально на днях, у нас завалилось, что то в еве) или не в еве не суть. Суть в том, что когда захотели снять логи с хостов esx обнаружили, что хранят эти негодяи логии только за последнии сутк
2011-01-11, Fomalhaut
cvs, svn, portsnap

Обновление сорцов системы через CVS и SVN, портов - CVS и portsnap. Обновление через Proxy-сервер.
2011-01-07, lissyara
Canon/gphotofs

Монтирование цифровых фотоаппаратов Canon (PTP) как файловой системы, автоматизация этого процесса через события devd и внешние скрипты.
2010-12-13, Al
IPSec

Описание принципов работы IPSEC и способов аутентификации.
2010-12-07, manefesto
FreeBSD on flash

Было принято решении переехать на USB Flash и установить минимальный джентельменский набор для работы своего роутера. Делаем =)
2010-12-05, Fomalhaut
root ZFS, GPT

Инструкция по установке FreeBSD с использованием в качестве таблицы разделов GPT и в качестве основной файловой системы - ZFS
2010-09-05, Cancer
Настройка аудиоплеера на ximp3

Цели: Простенький аудиоплеер, для того что бы тетя продавец в магазине утром пришла нажала на кнопку Power и заиграла в зале музыка, так же был доступ по сети, общая шара куда можно заливать музыку, к
2010-08-31, Cancer
Установка и настройка OpenVPN

На днях появилась задача - объединить головной офис и 3 филиала в одну сеть через интернет посредством OpenVPN, чтобы люди могли подключаться через RDP к базам 1С на серверах.
2010-08-25, manefesto
freebsd lvm

Использование linux_lvm для работы с LVM разделами из-под FreeBSD. Проблемы которые возники при монтирование lvm раздела
2010-04-30, gonzo111
proftpd file auth&quota

Proftpd - квоты и авторизация из файлов, без использования базы данных и/или системных пользователей
2010-04-22, lissyara
tw_cli

Пошаговая инструкция по восстановлению RAID на контроллере 3ware, из которого выпал один диск. Настройка мониторинга состояния рейда и отчётов о его состоянии на email.
2010-04-14, fox
MySQL Master+Master

MySQL (Master Master) and (Master Slave) Как настроить репликацию…
2010-03-22, Mufanu
named 9.7.0

Система доменных имен (Domain Name Service, DNS) - одна из тех незаметных, закулисных программ, которым не уделяется и половины того внимания, которого они заслуживают.
2010-03-09, terminus
DNS zones

Краткий ликбез про управление DNS зонами. Примеры проведения делегирования прямых и обратных DNS зон.
2010-03-09, aspera
Squid+AD (group access)

Настройка прокси сервера SQUID с автроризацией пользователей в AD. Разделение пользователей на группы
2010-03-02, BlackCat
Шлюз: Часть 4

Настройка дополнительных сервисов: синхронизация времени (OpenNTPD), клиент DynDNS.org.
2010-03-01, BlackCat
Шлюз: Часть 3

Настройка DHCP и DNS серверов для работы внутри частной сети, c поддержкой внутренних (частных зон) DNS, а так же интеграция DHCP и DNS сервисов.
2010-03-01, BlackCat
Шлюз: Часть 2

Конфигурация МСЭ pf для проброса портов с изменением порта назначения и без, а так же поддержки активного режима FTP и ограничения максимального размера сегмента
2010-03-01, BlackCat
Шлюз: Часть 1

Быстрая настройка шлюза/маршрутизатора с установлением PPPoE-соединения, поддержкой NAT и DNS-forwarding.
2010-02-23, Morty
darkstat

Простая считалка траффика, со встроенным веб-сервером. Очень маленькая, может делать отчеты трафика по хостам, портам, протоколам, а также строить графики
2010-01-23, gonzo111
squid+sams+sqstat

Пилим squid и sams - примеры конфигов с объяснениями. Установка SqStat.
2009-12-19, schizoid
mpd5 + radius + ng_car + Abills

Настройка pppoe-сервера с биллинговой системой Abills и шейпером ng_car
2009-11-16, lissyara
UFS->ZFS

Удалённая миграция с UFS на ZFS. Загрузка с раздела zfs. Настройка для работы с малым количеством памяти под архитектурой i386.
2009-11-13, gx_ua
fusefs-ntfs

Установка, настройка и использование fusefs-ntfs, драйвер NTFS, предназанченного для монтирования NTFS разделов под FreeBSD
2009-11-12, Morty
LiveCD

Создание собственного LiveCD с необходимыми вам изменениями, автоматизирование данного процесса, а так же вариант скоростной сборки СД.
2009-09-27, lissyara
Samba как PDC

Контроллер домена - аналог M$ NT4 домена под самбой, без использования LDAP и прочей хиромантии. Просто и быстро =)
2009-08-30, terminus
ipfw nat

Подробное руководство по ipfw nat, сложные случаи конфигурации.
2009-08-24, levantuev
HotSpot

Установка Hotspot системы в общественное заведение.
2009-08-18, lissyara
diskless

Создание бездисковых терминалов под управлением FreeBSD - с загрузкой по сети. Используются для старта rdesktop и подключения к виндовому серверу терминалов.
2009-07-29, BAV_Lug
Видеонаблюдение

Настройка бюджетного варианта видеонаблюдения на удаленном объекте
2009-07-22, Cancer
OpenLDAP адресная книга

Настройка и создание адресной книги на базе OpenLDAP + phpLDAPadmin
2009-06-30, SergeySL
AimSniff

Руководство по созданию системы мониторинга ICQ-переписки на базе AimSniff, использующей базу данных MySQL для хранения и Web-интерфейс WAS (Web Aim Sniff) для просмотра перехваченных сообщений
2009-06-25, atrium
Управление правами доступа

Полномочия пользователей и файлов, принадлежащих им, формирует концепцию ОС UNIX.
2009-06-16, DNK
Exim+PgSQL

Установка почтовой системы exim+pgsql на FreeBSD 7.1
2009-05-30, mvalery
HDD(mbr) -> HDD(gpt)

Как разбить диск размером более 2TB на разделы, сделать загрузочным, а затем перенести на него информацию с рабочей системы — донора.
2009-05-22, Cancer
SendXMPP

Отправка сообщений на Джаббер сервер по средствам SendXMPP
2009-05-11, Raven2000
Network UPS Tools

Network UPS Tools представляет собой набор программ, которые обеспечивают общий интерфейс для мониторинга и администрирование UPS оборудования.
2009-04-29, m0ps
IPSEC over GRE with RIP

Пример IPSEC over GRE и динамическим роутингом (RIP), с ADSL в качестве последней мили на оборудовании Cisco.
2009-04-24, WhiteBear777
qemu network

Появилась необходимость поставить на БСД эмулятор(qemu) и настроить в качестве гостевой ОС Windows XP, предоставив ей выход в локалку и в сеть internet...
2009-04-22, vp
freebsd + huawei 162 gsm modem

В статье описывается простой способ подключения модема huawei 162 к freebsd + первичная настройка smstools
2009-04-12, mvalery
Мониторинг RAID

Мониторинг из командной строки RAID компаний AMCC 3ware, HighPoint, Dell (Perc 5/i и PERC 6/i) и LSI (MegaRAID SAS 8408E и SAS1078)
2009-04-09, texnotronic
RAID1 via LAN

Функциональности DRBD во FreeBSD можно добиться примонтировав блочное устройство по сети при помощи GEOM Gate (ggate) и добавив его в зеркало с локальным диском средствами gmirror.
2009-04-03, Raven2000
Оптимизация хоста для CMS

В последнее время на старый и не очень быстрый ПК (Celeron 800 RAM 256) мною было навешано с десяток сайтов и некоторые были из серии тяжелых CMS. И так нам дано FreeBSD 7.1 и ~10 сайтов/CMS.
2009-04-01, atrium
VSFTPD + AD && MySQL

Настройка самого безопасного сервера FTP - vsftpd.
подписка

    вверх      
Статистика сайта
Сейчас на сайте находится: 13 чел.
За последние 30 мин было: 68 человек
За сегодня было
13215 показов,
1682 уникальных IP
 

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

© lissyara 2006-10-24 08:47 MSK

веселые картинки развлекательные гифки интресные факты смешные видео смешные истории из соцсетей

Время генерации страницы 0.9028 секунд
Из них PHP: 97%; SQL: 3%; Число SQL-запросов: 78 шт.
У Вас отключено GZIP-сжатие в браузере. Размер страницы 191489