Заметки об 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="fxp0"
natd_flags="-same_ports"

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

Код: Выделить всё

kldload ipfw

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

Код: Выделить всё

firewall_enable="YES"

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

Код: Выделить всё

sysctl 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 работает?
Общая схема

IPFW

IPFW.jpg (5.19 КБ) 2988 просмотров

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

– по правилу №7 пакет выходит из 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. TCP 195.34.32.55:80 195.34.32.56:1076 out via fxp1

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

Код: Выделить всё

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

Ну и последнее замечание по поводу IPFW-NATD:
Что делать если требуется что-то прикрыть в интернете для хостов внутренней сети? Ответ достаточно очевиден:
1. Впереди правил для локальной сети пишем свои запреты
Ну и наоборот если требуется все запретить, разрешив только что-то: к примеру 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
#И наконец ответ хосту, а здесь уже интересно, поскольку прокси-сервер ответил следующим образом:
Count TCP 77.73.24.4:80 192.168.0.100:1083 out via fxp0

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

Код: Выделить всё

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

правда на практике чаще пишут :-):

Код: Выделить всё

{fwcmd} add allow tcp from any to any via ${iif}

, в то время как с обычным прокси вполне обойдемся более безопасной строкой:

Код: Выделить всё

{fwcmd} add allow  ip from {MyLan} to {MyLan} via {iif}

.

Очень хочется думать, что помог вам в создании безопасных, а главное осознанных правил IPFW, спасибо всем кто сумел сие прочитать, за сим откланиваюсь.
-cat- ICQ: 328908584 e-mail: mfoleg@gmail.com
P.S. Автор сознательно не использовал конструкции setup-established и check-state keep-state.
setup-established запутали бы процесс понимания правил
keep-state же требует отдельного исследования.
P.P.S. В процессе сочинения сего использовался вывод работающего IPFW, а именно строчка {fwcmd} add count log all from any to any, а также различные виртуальные машины.
Совпадения IP - реальных случайны, случайных - не реальны. .

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[dikens3]

Про NATD понравилось, будто сам писал.

Рекомендую заменить {ilan}:{imask} на {$mylan}
Понимать удобнее написанное.

Код: Выделить всё

кстати NATD сохранил еще и первоначальный порт 1499, что бывает далеко не всегда.

Если есть желание можешь типы NAT'ов упомянуть.
И быть может средства определения этого типа. :-)

[-cat-]

Про NATD понравилось, будто сам писал.

Идея как проверить NATD твоя и есть (использовать в IPFW - count).
По поводу {mylan} возможно, на мой взгляд - мелочи.
Больше вопрос занимает нужно ли вообще такое писать? Все как то по детски все просто. Взрослые мужики скажут - мы и так все знаем.

[Alex Keda]

пиши.
зато куча народу скажет спасибо.

[dikens3]

Взрослые как раз не скажут, а прочтут и ничего не скажут. Просто вспомнят, если чё забыли.
Надо или нет, к Лису. Он в принципе всё любит, да и начинать с чего то нужно?

P.S. Он уже отписался. :-)

[Alex Keda]

не всё
линух вот не очень.
тока последнее время я уже не такой буйный стал.
притираюсь

[Alex Keda]

тока вот на кнопочке code меня хорошо заклинило.
а так - да, всё люблю.

[-cat-]

Спасибо за поддержку,
постараюсь рисунок нормальный сделать, да наверное переписать окончание, нет жизнеутверждающего финала.

[chuchundra]

2 -cat- большой сенкс... я месяс как на Freebsd перешел и для меня это лучше и легче всяких мануалов

особенно

Код: Выделить всё

Входящие (IN) и исходящие (OUT) пакеты следует рассматривать относительно операционной системы, а не относительно сетевых интерфейсов.

я до этого думал что пакет 2 раза входит и 2 раза выходит


если можно про setup и established моно несколько слов?

[dikens3]

1 {fwcmd} add allow ip from {MyLan} to {MyLan} via {iif}

Это несовсем корректно. Почему?

Код: Выделить всё

00300      501     108049 allow udp from 192.168.1.0/24 137,138 to 192.168.1.255 in via rl0

Как думаешь, почему у меня есть такая строка? Правильно, Samba у меня стоит и через NETBIOS она не видима, т.к. принцип работы у него такой.

[-cat-]

По поводу этого правила, я написал что оно не самое удачное, подразумевал как раз широковещательные запросы и не только SMB, но и DHCP. A потом если мы говорим о роутере не самая удачная идея делать из него файл-сервер, нет?

[dikens3]

По поводу этого правила, я написал что оно не самое удачное, подразумевал как раз широковещательные запросы и не только SMB, но и DHCP. A потом если мы говорим о роутере не самая удачная идея делать из него файл-сервер, нет?

У меня есть на некоторых, я не рекомендую, но люди просят. Тут пофиг, изнутри они через samb'у маловероятно, что-нибудь сломают.(А наружу её нет.)
Сервак вот грузят, и концепцию безопасности нарушают.

[f0s]

я тут свой конфиг подрихтовал ) старался везде прописать inout и и нтерфейс.. не везде конечно получилось.. но рад бы послушать замечания/предложения

Код: Выделить всё

[f0s@router] /var/log/> cat /etc/rc.firewall

#!/bin/sh
ipfw="/sbin/ipfw   "
#
LanOut="xl0"                    # Внешняя сетевуха
NetOut="255.255.255.240/28"     # внешняя сеть
IpOut="84.54.X.X"             # Внешний IP
#
LanIn="nve0"                    # внутренняя сетевуха
NetIn="192.168.10.0/24"         # Внутренняя сеть
IpIn="192.168.10.7"
#
ssh="84.54.X.X"               # Кому можно подключаться по ssh
#

###############################################################################

# Очищаем все правила
${ipfw} -f flush
${ipfw} -f pipe flush
${ipfw} -f queue flush


# Подключаемся по SSH к серверу из инета
${ipfw} add allow tcp from ${ssh} 1024-65535 to me 22 in via ${LanOut}
${ipfw} add allow tcp from me 22 to ${ssh} 1024-65535 out via ${LanOut} established

# Блокрируем атаки
${ipfw} add deny log icmp from any to any in icmptype 5,9,13,14,15,16,17
${ipfw} add deny log ip from any to ${IpOut} 137-139,445 in via ${LanOut}
${ipfw} add deny log ip from any to ${IpOut} 137-139,445 in via ${LanIn}

# Разрешаем весь траффик по внутреннему интерфейсу (петле)
${ipfw} add allow ip from any to any via lo0

# рубим попытки lo0 куда-то лезть и откуда-то лезть на lo0
${ipfw} add deny ip from any to 127.0.0.0/8
${ipfw} add deny ip from 127.0.0.0/8 to any

# рубим пакеты `от внутр. сети на внеш. инт-се` и `от внеш.сети на внут. инт-се`
${ipfw} add deny ip from ${NetIn} to any in via ${LanOut}
${ipfw} add deny ip from ${NetOut} to any in via ${LanIn}

# режем частные сети на внешнем интерфейсе
${ipfw} add deny ip from any to 0.0.0.0/8,10.0.0.0/8,127.0.0.0/8,169.254.0.0/16,172.16.0.0/12,192.0.2.0/24,192.168.0.0/16,204.152.64.0/23,224.0.0.0/3 in via ${LanOut}

# рубим фрагментированные icmp
${ipfw} add deny icmp from any to any frag

# рубим широковещательные icmp на внешнем интерфейсе
${ipfw} add deny icmp from any to 255.255.255.255 in via ${LanOut}
${ipfw} add deny icmp from any to 255.255.255.255 out via ${LanOut}

# NAT
${ipfw} add deny log all from not 195.144.122.1,195.144.123.1 to ${IpOut} 25 in via ${LanOut}
${ipfw} add deny all from not ${ssh} to ${IpOut} 3389 in via ${LanOut}
${ipfw} add divert natd ip from ${NetIn} to any out via ${LanOut}
${ipfw} add divert natd ip from any to ${IpOut} in via ${LanOut}

${ipfw} add allow tcp from any to 192.168.10.8 25 in via ${LanOut}
${ipfw} add allow tcp from any to 192.168.10.8 25 out via ${LanIN}
${ipfw} add allow tcp from any to 192.168.10.8 3389 in via ${LanOut}
${ipfw} add allow tcp from any to 192.168.10.8 3389 out via ${LanIN}

# рубим траффик к частным сетям через внешний интерфейс
${ipfw} add deny ip from 0.0.0.0/8,10.0.0.0/8,127.0.0.0/8,169.254.0.0/16,172.16.0.0/12,192.0.2.0/24,192.168.0.0/16,204.152.64.0/23,224.0.0.0/3 to any out via ${LanOut}

# разрешаем эхо-запрос, эхо-ответ и время жизни пакета истекло
${ipfw} add allow icmp from any to any icmptypes 0,8,11

# Разрешаем выходить в инет серверам по всем портам
${ipfw} add allow all from 192.168.10.0/24{5,6,7,8} to any setup

# Разрешаем траффик внутренней сети на внутреннем интерфейсе (вх/исх)
${ipfw} add allow ip from any to ${NetIn} in via ${LanIn}
${ipfw} add allow ip from ${NetIn} to any out via ${LanIn}

# разрешаем tcp-пакеты по уже установленным соединениям
${ipfw} add allow tcp from any to any established

# разрешаем UDP (для синхронизации времени - 123 порт)
${ipfw} add allow udp from me to any 123 via ${LanOut}
${ipfw} add allow udp from any 123 to me via ${LanOut}

# Запрещем дальнейшее прохождение для всех
${ipfw} add reject tcp from ${NetIn} to any via ${LanIn}

# Разрешаем DNS

${ipfw} add allow udp from ${IpOut} 53 to 195.177.122.1 53 out via ${LanOut}
${ipfw} add allow udp from 192.168.10.8 53 to 195.177.122.1 53 in via ${LanIn}
${ipfw} add allow udp from 195.177.122.1 53 to 192.168.10.8 53 in via ${LanOut}
${ipfw} add allow udp from 195.177.122.1 53 to 192.168.10.8 53 out via ${LanIn}

${ipfw} add allow udp from ${IpOut} 53 to 195.177.123.1 53 out via ${LanOut}
${ipfw} add allow udp from 192.168.10.8 53 to 195.177.123.1 53 in via ${LanIn}
${ipfw} add allow udp from 195.177.123.1 53 to 192.168.10.8 53 in via ${LanOut}
${ipfw} add allow udp from 195.177.123.1 53 to 192.168.10.8 53 out via ${LanIn}

# Разрешаем UDP во всей сети
${ipfw} add allow udp from any to ${NetIn} in via ${LanIn}
${ipfw} add allow udp from ${NetIn} to any out via ${LanIn}

# Всем остальным все запрещаем и пишем в лог
${ipfw} add deny log all from any to any

[Mr Alter Ego]

спасибо за веточку. мне оч пригодилась. надеюсь поможет кому то ещё

автору спасибо !

[f0s]

dikens3, пасиб, но я там их фальшивые написал

[-cat-]

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

[Alex Keda]

поддерживаю

[Savage]

пример №2:
2. {fwcmd} add divert natd ip from {MyLan} to any out via {oif}
7. {fwcmd} add allow ip from {MyLan} to any out via {oif}

Так и должно быть? или я чего-то не понимаю.

TCP 64.233.183.109:995 192.168.0.75:1499 in via fxp1
по правилу №7 пакет выходит из IPFW и попадает в операционную систему

не понимаю, как он может попасть под 7-е правило

[-cat-]

Правило 7 естественно описка, должно быть №8, уже исправил.
Просто логи собирались на одной машине и с одними правилами, статья писалась дома на другой, а тестировалось все вообще на третьей, я больше боялся путаницы с интерфейсами, поскольку они все были разные.
А правило №7, вобщем-то я хотел удалить вообще (и в одной из редакций удалил), но потом решил оставить, так как раз уж написал

Код: Выделить всё

allow ip from any to any

то надо бы быть последовательным, хотя все равно список правил не имеет полного соответствия.
Вобщем спасибо за замечание.
Надо бы конечно внести кое-какие коррективы, по поводу "исследований" , а может и ненадо.

[barsykoff]

Код: Выделить всё

options	IPDIVERT

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

Я бы сказал, что не "подключение поддержки NATD", а "включение поддержки переадресации потока на другой порт". Потому что тут можно экспериментировать не с одним натом, а с netams, например.

[f0s]

меня вот интересует такой вопрос, разумно ли писать такое правило:

Код: Выделить всё

allow ip from any to any via nve0

где nve0 - сетевуха смотрящая в локалку. или лучше что-то типа:

Код: Выделить всё

allow tcp from 192.168.10.0/24 to 192.168.10.0/24 in via nve0
allow tcp from 192.168.10.0/24 to 192.168.10.0/24 out via nve0

то есть четко сказать, что пускать только нашу локалку?

просто у меня еще есть правила такие в самом верху:

Код: Выделить всё

allow ip from any to any via gif0
allow udp from 81.111.125.232 to me dst-port 500
allow esp from me to 81.111.125.232
allow esp from 81.111.125.232 to me

эти правила рекомендовали поставить в мануале по настройке IPSEC. однако тут мы наблюдаем схожее правило: allow ip from any to any via gif0, то есть фактически разрешить любой траффик пол этому интерфейсу.... соотсветсвенно в связи с этим, на мой взгляд, надо либо:

1) в дополнение к

Код: Выделить всё

allow ip from any to any via gif0
allow udp from 81.111.125.232 to me dst-port 500
allow esp from me to 81.111.125.232
allow esp from 81.111.125.232 to me

приписать правило

Код: Выделить всё

allow ip from any to any via nve0

либо:
2) преобразовать:

Код: Выделить всё

allow ip from 192.168.10.0/24,192.168.0.0/24 to 192.168.10.0/24,192.168.0.0/24 in via gif0
allow ip from 192.168.10.0/24,192.168.0.0/24 to 192.168.10.0/24,192.168.0.0/24 out via gif0
allow udp from 81.111.125.232 to me dst-port 500
allow esp from me to 81.111.125.232
allow esp from 81.111.125.232 to me

+ модифицировать правило касающееся интерфейса физического, смотрящего в локалку, путем добавления разрешенной сети 192.168.0.0/24 (которая будет с удаленного офиса)

Код: Выделить всё

allow ip from 192.168.10.0/24,192.168.0.0/24 to 192.168.10.0/24,192.168.0.0/24 in via nve0
allow ip from 192.168.10.0/24,192.168.0.0/24 to 192.168.10.0/24,192.168.0.0/24 out via nve0

кто что думает? какие +\- у первого или у второго вариант? или может есть какие-то лучшие пути решения?

[dikens3]

кто что думает? какие +\- у первого или у второго вариант? или может есть какие-то лучшие пути решения?

Хватит издеваться над людьми. Ты б ещё спросил какой полюс лучше: Серверный или Южный? Это ведь зависит много от чего. Делай как тебе удобнее и какую задачу решаешь.

[khiluck]

#Вспомним про 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}

Поясните мне тупому, никак немогу понять почему именно так, а не вот так:
{fwcmd} add divert natd ip from {MyLan} to any in via {oif}
{fwcmd} add divert natd ip from any to {oip} out via {oif}

Прошу не смеяться, просто не очень понятно

[dikens3]

1. Почитай про NAT вообще, для чего он нужен и что делает.

Поясните мне тупому, никак немогу понять почему именно так, а не вот так:
{fwcmd} add divert natd ip from {MyLan} to any in via {oif}

С интернета входящий трафик от IP-Адресов выделенных для нашей сети?

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

{oip} - это IP-Адрес самого шлюза (внешний адрес). Как он может выйти в интернет, если адрес назначения сам шлюз? Зачем его натить?

P.S. Лучше сам опиши как понимаешь эти строки, а я поправлю.

[khiluck]

Как я понимаю суть НАТа в подмене обратного адреса при прохождении пакета в инет из локалки И обратной подмене адреса назначения при его возвращении. Ну и возможность подмены портов. Я так - думаю

#Вспомним про 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}

Вижу, я, это так:

2. добавить маршрут для НАТа "айпи адреса" из локальной сети в любое место через внешний интерфейс ????? (помоему бред какой-то получился:)

3. добавить маршрут для НАТа "айпи адреса" из любого места??? к ....

Эх... проще скажите, плиз, КАК прально читать правила?

Да, и еще как будет выглядеть 3я строчка если внешний IP выдается DHCP сервером провайдера?