Настройка ipfw для шлюза под управлением FreeBSD.

Данный документ описывает принцип построения цепочек правил для фильтрации ip трафика.

Данный документ описывает принцип построения цепочек правил для фильтрации ip трафика.
Подразумевается, что вы знакомы с принципом работы стека TCP/IP, а так же прочитали man ipfw Wink

Сразу хочу отметить, что здесь не будут рассмотрены вопросы использования traffic shaper(dummynet), а также построение динамических правил. В этой статье в качестве базиса использовались правила на моем работающем шлюзе
под управлением FreeBSD 4.10-Stable, так что на абсолютную истину не претендую Cool

Итак, начнем.
Дано: локальная сеть (пусть это будет 192.168.0.0/24), подключенная к машине с установленной FreeBSD, которая имеет выделенный канал в Интернет. Версия FreeBSD принципиального значение не имеет.
Задача: правильно сконфигурировать firewall, то есть с одной стороны максимально обезопасить себя от внешних вторжений, а с другой ограничить доступ к Интернету из локальной сети.

Для начала нужно пересобрать ядро с поддержкой ipfw:

bsd-gate# cd /usr/src/sys/i386/conf/
bsd-gate# cp GENERIC MYKERNEL

Открываем MYKERNEL в текстовом редакторе и добавляем строчки:

options IPFIREWALL #firewall
options IPFIREWALL_VERBOSE #enable logging to syslogd
options IPFIREWALL_VERBOSE_LIMIT=500 #limit verbosity
options IPFIREWALL_FORWARD #enable transparent proxy support
options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by default

По-порядку:

IPFIREWALL:
Дает базовую поддержку ipfw, хотя на самом деле некоторые минимальные действия можно осуществлять и без, но смысла в этом мало.

IPFIREWALL_VERBOSE
Позволяет записывать определенные сетевые события в лог файл.

IPFIREWALL_VERBOSE_LIMIT=500
Ограничивает количество событий, которые могут быть записаны в лог файл.
В противном случае возникает вероятность заполнения этим логом всего дискового пространства (особенно в том случае,если злоумышленник намеренно вас "флудит" с данной целью).

IPFIREWALL_FORWARD
Включает возможность перенаправления пакетов. Например, для создания transparent proxy или для скрытия какого-либо сервера(web, mail) внутри локальной сети, который должен быть доступен извне.

IPFIREWALL_DEFAULT_TO_ACCEPT
По-умолчанию firewall блокирует весь трафик, который явно не разрешен. Эта же опция инвертирует поведение, т.е. - по умолчанию разрешает все, что явно не запрещено.
Неоднозначная опция. Многие категорически не рекомендуют ее включать, но я ее использую. Это бывает очень удобно при удаленном конфигурировании, когда в процессе отладки и настройки шлюза приходится на пару минут делать ipfw –q flush(такие случаи крайне редки, но если у вас эта машина за N километров….). Поэтому если вы параноик и боитесь возможного взлома в эти минуты – эта опция не для вас. В противном случае достаточно последним правилом своего скрипта указать ipfw add deny all from any to any, чтобы ваш firewall вел себя почти также, как в случае отключения этой опции. Я написал «почти», потому что тут есть один нюанс. Дело в том, что правило deny all from any to any работает только для ip-трафика, а отключение опции DEFAULT_TO_ACCEPT приводит к автоматическому запрещению ВСЕГО трафика(arp-протокол, например). Но и это можно обойти, потому что в коде IPFIREWALL-a есть маленькая хитрость: если в правиле для upd пакета указать src-ip как 0.0.0.0., то src-port в этом случае будет играть роль номера протокола Ethernet. Ну, это уже детали, лучше вернемся к нашим баранам.

Следующая опция не обязательна, но желательна:

options TCP_DROP_SYNFIN
Отбрасывает пакеты с одновременно установленными TCP флагами SYN и FIN(В 99,99% случаев ненормальная ситуация, пакет одновременно и инициирует соединение, и завершает его). Иногда используется злоумышленниками, например, для сканирования хоста.

Сохраняем, собираем и компилируем:

bsd-gate# cd /usr/src/
bsd-gate# make buildkernel KERNCONF=MYKERNEL

если удачно, то:

bsd-gate# make installkernel KERNCONF=MYKERNEL
bsd-gate# shutdown -r now

Если новое ядро загрузилось, нужно подправить /etc/rc.conf, а именно прописать там следующие строчки:

gateway_enable="YES"
firewall_enable="YES" # Set to YES to enable firewall functionality
firewall_script="/etc/rc.ipfw" # Which script to run to set up the firewall
firewall_logging="YES" # Set to YES to enable events logging
natd_enable="YES" # Enable natd (if firewall_enable == YES).
natd_program="/sbin/natd" # path to natd, if you want a different one.
natd_flags="-f /etc/natd.conf" # Additional flags for natd.

Думаю, все опции понятны (некоторые из них, кстати, необязательны, к примеру, natd_program), а rc.ipfw я взял для примера, пусть так называется наш будущий скрипт.
Дефолтным скриптом для firewall, который создается самой системой, является /etc/rc.firewall, с такими вариантами работы как OPEN, CLOSED, SIMPLE, CLIENT, UNKNOWN. Рассматривать этот файл мы не будем, мы все равно свой собираемся писать.

Собственно, поехали:

bsd-gate# vi /etc/rc.ipfw:

#!/bin/sh
# Manual script for ipfw

echo -n "Starting firewall..."

определим основные переменные (интерфейсы, сети, айпишники, диапазоны портов):

ipfw="/sbin/ipfw"
uports="1025-65535"

int_if="em0"
ext_if="xl0"

int_ip="192.168.0.254"
ext_ip="66.66.66.65"

int_net="192.168.0.0/24"
ext_net="66.66.66.64/30"
vip_net="192.168.0.0/27"

Далее нужно определиться, какие службы должны быть доступны пользователям локальной сети, vip пользователям и самой фришке.
Пусть все пользователи должны ходить по http, https, иметь доступ по pop3 и smtp.
Привилегированные пользователи(vip_net, машины которых являются частью общей локальной сети, к примеру, машины дирекции и админов) должны иметь доступ также к icq, ftp, ssh.
Фришка должна иметь доступ по ftp,ssh.
И, конечно же, чтобы все работало, все должны разрешать dns-имена запрашиваемых серверов.

Определим для этого переменные:

for_lan="smtp,pop3,domain,http,https"
for_vip="aol,ftp.ssh"
for_rout="ftp,domain,ssh"

Services="smtp,pop3,http,https,domain,aol,ssh,ftp"
*В Services занесем все сервисы, которые будут доступны, неважно кому.

На всякий случай напомню, что firewall переводит имена портов в числовую форму с помощью файла /etc/services.
Да, и еще. При создании переменных следует помнить, что количество портов в одной строчке правила ограничено девятью, по крайней мере в ipfw. В ipfw2 обещали это поправить, но вот поправили ли - не знаю.

Далее опишем стандартные правила для loopback, antispoofing и т.д.:

${ipfw} add allow all from any to any via lo0
${ipfw} add deny all from any to 127.0.0.0/8

Защитимся от подмены адресов извне. Ведь внутренней сети обычно(и в нашем случае тоже) больше разрешено, чем внешней, поэтому злоумышленник может попытаться подменить свой source ip для обхода некоторых правил:

${ipfw} add deny all from 127.0.0.0/8 to any in recv $ext_if
${ipfw} add deny all from 10.0.0.0/8 to any in recv $ext_if
${ipfw} add deny all from 172.16.0.0/16 to any in recv $ext_if
${ipfw} add deny all from 192.168.0.0/24 to any in recv $ext_if

Далее, полагая, что в нашей внутренней сети нету "хакеров", которые могут попытаться получить неавторизованный доступ к нашей фришке(стандартная практика, но которая легко может быть пересмотрена) будем фильтровать трафик только на внешнем интерфейсе, а для внутреннего все пропускаем:

${ipfw} add allow all from $int_net to any in recv $int_if
${ipfw} add allow all from any to $int_net out xmit $int_if

После этого "завернем" весь нужный трафик демону natd, который виртуальный айпи машин из локальной сети (трафик которых, как известно, не маршрутизируется на просторах Интернета) подменяет на свой реальный (при входящем трафике – наоборот). Этот демон мы повесим на внешний интерфейс (собственно, если мы его повесим на внутренний, то ничего работать не будет). Подробнее о работе демона natd читайте man natd.

Тут на самом деле скользкий момент. В смысле, в каком именно месте (до или после каких правил) "заворачивать" трафик демону... Иногда из-за этого firewall не работает, или работает не так, как надо.
Для этого нужно понимать, что после того, как пакеты попали демону natd, и он с ними что-то сделал (поменял dst- или src-ip) или оставил без изменений, они возвращаются в скрипт в том месте, из которого они туда ушли, и продолжают дальше следовать по цепочкам.
Немного сумбурно, попробую объяснить на отвлеченном примере:

Разрешим трафик извне с 80 порта на фришку, потом завернем весь трафик в natd:
${ipfw} add allow tcp from any 80 to me
${ipfw} add divert natd all from any to any via $ext_if

В данном случае наши машины из локальной сети никогда не увидят ни одной http страницы, потому что после того, как пакет пришел от web-сервера, он сразу принимается нашей фришкой(согласно первому правилу) и заканчивает свое путешествие по цепочкам, а вот куда дальше ему деваться, на какой внутренний айпи идти - он не знает...
Поэтому нужно сначала "завернуть" трафик демону, а затем разрешить http трафик для нашей локалки(а не для фришки, потому что natd уже подменил реальный ip назначения на внутренний айпи локальной машины).

${ipfw} add divert natd all from any to any via $ext_if
${ipfw} add allow tcp from any 80 to $int_net

Это грубый пример, дальше напишем собственные правила и будет понятнее, но вывод отсюда такой:
!все правила на трафик, который должен быть обработан демоном natd, то есть тот, который должен (или может) доставляться машинам из локальной сети, должны следовать ПОСЛЕ правила на divert.

Вернемся к нашему скрипту.
Итак, "дивертим" исходящий трафик из локалки и входящий трафик из Интернета:
${ipfw} add divert natd all from $int_net to not $int_net out xmit $ext_if
${ipfw} add divert natd all from any to $ext_ip in recv $ext_if
*Вместо стандартного natd, можно указать другой численный порт, на котором висит наш демон, но для этого этот же самый порт нужно указать в конфиге /etc/natd.conf.

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

Разрешим исходящий трафик с фришки на нужные сервисы:
${ipfw} add allow tcp from $ext_ip $uports to any $Services out xmit $ext_if

Разрешим входящий трафик в нашу локалку, причем только тот, который этой локалке необходим:
${ipfw} add allow tcp from any $for_lan to $int_net $uports in recv $ext_if established
*Обратите внимание на флаг established , который ограничивает это правило только теми пакетами, которые пришли в ответ(пакетами, у которых установлены tcp флаги ACK или RST).

Аналогично не забудем о наших VIP:
${ipfw} add allow tcp from any $for_vip to $vip_net $uports in recv $ext_if established

И о фришке:
${ipfw} add allow tcp from any $for_rout to $ext_ip $uports in recv $ext_if established

А вот и DNS lookup, без него, понятное дело, www.ru превращается только в набор букв:

${ipfw} add allow udp from $ext_ip $uports to any domain out xmit $ext_if
${ipfw} add allow udp from any domain to $ext_ip $uports in recv $ext_if
${ipfw} add allow udp from any domain to $int_net $uports in recv $ext_if
*Первое правило разрешает исходящий udp трафик на 53 порт, а следующие два разрешают ответы на dns запрос для фришки и локалки.

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

${ipfw} add allow icmp from any to me icmptypes 0,3,4,11,12 in
${ipfw} add allow icmp from any to $int_net icmptypes 0,3,4,11,12 in recv $ext_if
${ipfw} add allow icmp from me to any icmptypes 3,8,12 out

*На всякий случай дам расшифровку icmp кодов:
echo reply 0, destination unreachable 3, source quench 4, redirect 5, echo request 8, router adver-tisement 9,
router solicitation 10, time-to-live exceeded 11, IP header bad 12, timestamp request 13, timestamp reply 14,
information request 15, information reply 16, address mask request 17 and address mask reply 18.

На данном этапе наш скрипт почти готов к продуктивной работе, но вот ftp все же работать не будет...
FTP мы разрешим только в пассивном режиме(опять же, стандартная практика, позволяет избежать разрешения syn-пакетов с 20 порта ftp сервера).
Для этого нужно открыть исходящий и ответный входящий трафик между высокими портами локалки и Интернета, а также фришки и Интернета:

${ipfw} add allow tcp from $ext_ip $uports to any $uports out xmit $ext_if
${ipfw} add allow tcp from any $uports to $ext_ip $uports in recv $ext_if established
${ipfw} add allow tcp from any $uports to $vip_net $uports in recv $ext_if established
*На самом деле тут мы разрешили, конечно же, не только ftp, а вообще все сервисы, которые "висят" на портах >1024.
К примеру, столь необходимый cvsup будет работать именно из-за этих правил.
Но пользоваться этими "всеми" сервисами можно только с фришки, или с машин, входящих в vip_net.

Ну и, наконец, самые главные правила.
Заносим в лог попытки установить соединение с нашей фришкой(а наш скрипт вообще не разрешает устанавливать никаких соединений, может быть принят только ответный трафик):
${ipfw} add deny log logamount 700 tcp from any to $ext_ip in recv $ext_if setup
*logamount перебивает настройку IPFIREWALL_VERBOSE_LIMIT.

И запрещаем весь остальной трафик:
${ipfw} add deny all from any to any
echo "DONE"

Все, сохраняем и выходим.

Наш скрипт должен выглядеть примерно следующим образом:

#!/bin/sh
# Manual script for ipfw
echo -n "Starting firewall..."

ipfw="/sbin/ipfw"
uports="1025-65535"
int_if="em0"
ext_if="xl0"

int_ip="192.168.0.254"
ext_ip="66.66.66.65"

int_net="192.168.0.0/24"
ext_net="66.66.66.64/30"
vip_net="192.168.0.0/27"
for_lan="smtp,pop3,domain,http,https"
for_vip="aol,ftp,ssh"
for_rout="ftp,domain,ssh"
Services="smtp,pop3,http,https,domain,aol,ssh,ftp"

${ipfw} add allow all from any to any via lo0
${ipfw} add deny all from any to 127.0.0.0/8

${ipfw} add deny all from 127.0.0.0/8 to any in recv $ext_if
${ipfw} add deny all from 10.0.0.0/8 to any in recv $ext_if
${ipfw} add deny all from 172.16.0.0/16 to any in recv $ext_if
${ipfw} add deny all from 192.168.0.0/24 to any in recv $ext_if

${ipfw} add allow all from $int_net to any in recv $int_if
${ipfw} add allow all from any to $int_net out xmit $int_if

${ipfw} add divert natd all from $int_net to not $int_net out xmit $ext_if
${ipfw} add divert natd all from any to $ext_ip in recv $ext_if

${ipfw} add allow tcp from $ext_ip $uports to any $Services out xmit $ext_if
${ipfw} add allow tcp from any $for_lan to $int_net $uports in recv $ext_if established
${ipfw} add allow tcp from any $for_vip to $vip_net $uports in recv $ext_if established
${ipfw} add allow tcp from any $for_rout to $ext_ip $uports in recv $ext_if established

${ipfw} add allow udp from $ext_ip $uports to any domain out xmit $ext_if
${ipfw} add allow udp from any domain to $ext_ip $uports in recv $ext_if
${ipfw} add allow udp from any domain to $int_net $uports in recv $ext_if

${ipfw} add allow tcp from $ext_ip $uports to any $uports out xmit $ext_if
${ipfw} add allow tcp from any $uports to $ext_ip $uports in recv $ext_if established
${ipfw} add allow tcp from any $uports to $vip_net $uports in recv $ext_if established

${ipfw} add allow icmp from any to me icmptypes 0,3,4,11,12 in
${ipfw} add allow icmp from any to $int_net icmptypes 0,3,4,11,12 in recv $ext_if
${ipfw} add allow icmp from me to any icmptypes 3,8,12 out

${ipfw} add deny log logamount 700 tcp from any to $ext_ip in recv $ext_if setup
${ipfw} add deny all from any to any
echo "DONE"

Запускаем и проверяем, все должно работать:
#bsd-gate: /bin/sh /etc/rc.ipfw

Данная статья никоим образом не претендует на полноту раскрытия темы firewall-ов вообще или ipfw в частности, а особенно проблем сетевой безопасности.
Если возникнут вопросы, касающиеся данной статьи, пишите fencer@bsdportal.ru.
Удачи.

p.s. непонятно, зачем я все это написал, раз тут столько похожих доков. В следующий раз сначала полезу сюда Rolling Eyes

от блин.. лучшеб насчт pf расказали =)

если кто pf знает опишите пример использования с комментариями

эхх.. еслиб знал написал..

Fencer
отличная статья - спасибо!

на здоровье Smile