Независимо от того, указан ли тип брандмауэра в /etc/rc.conf, если в нём есть строка firewall_enable="YES", при запуске системы будет выполняться сценарий /etc/rc.firewall. В этом сценарии, для начала, будут выполнены следующие команды:

ipfw add 100 pass all from any to any via lo0
ipfw add 200 deny all from any to 127.0.0.0/8
ipfw add 300 deny ip from 127.0.0.0/8 to any
          

Их назначение — пропускать весь локальный трафик на кольцевом интерфейсе и предотвращать попытки обращения к внутренним адресам машины из внешнего мира. Если этих правил не будет, поломается множество внутренних сервисов — RPC, X11 и др.

Если тип брандмауэра в rc.conf определёно как OPEN, то слеующим срабатывает правило

ipfw add 65000 pass all from any to any
          

Это правило пропускает весь внешний трафик внутрь и весь внутренний трафик наружу. Оно выполняет ту же функцию, что и опция IPFIREWALL_DEFAULT_TO_ACCEPT в ядре. Если в ядре вкомпилирована открытая политика, то при этом создаётся правило номер 65535, allow ip from any to any, вместо deny ip from any to any, что делает правило номер 65000 ненужным. Чтобы избежать добавления правила номер 65000, можно использовать тип брандмауэра UNKNOWN. Это имеет смысл сделать тем, кто просто хочет поупражняться с брандмауэром или просто заброкировать трафик с какого-то конкретного хоста. Для этого, оставьте брандмауэр открытым и переходите к Раздел E.1.2, «Основы синтаксиса правил ipfw». Если же вы не хотите использовать открытый брандмауэр, ни тип OPEN, ни UNKNOWN, разумеется, вам не годятся.

E.1.1.1.1. Загрузка правил

Есть две возможности: либо использовать предопределённые типы брандмауэра из rc.firewall, либо создать пользовательский тип. Второе предпочтительнее по следующим причинам:

• Вы можете создавать собственные правила соответствующие вашим потребностям не модифицируя системный скрипт rc.firewall.
• Вы будете вынуждены разобраться в синтаксисе ipfw(8), что, быть может, стимулирует вас к созданию действительно качественного межсетевого экрана.

E.1.1.1.1.1. Предопределённые типы брандмауэров

Разумеется последнее слово в выборе типа брандмауэра за администратором. Если вам почему-то хочется именно использовать один из предустановленных типов, хотя бы посмотрите скрипт rc.firewall, чтобы понимать, что он делает. Тип брандмауэра задаётся в файле /etc/rc.conf(5) опцией

firewall_type="..."
              

Тип брандмауэра можно задавать в любом регистре: OPEN, open, OpEn. Помимо обсуждавшегося выше типа OPEN имеются ещё три:

CLIENT

Этот тип брандмауэра предназначен, главным образом, для рабочих станций и немного для маршрутизаторов (и в том и в другом качестве он крайне примитивен!). Имейте в виду, что вам всё равно придётся редактировать файл rc.firewall, так как в нём надо указать номера IP адресов хоста и сети, а так же сетевую маску, так что лучше уж написать пользовательский тип.

SIMPLE

Несмотря на название, этот тип более сложен, чем CLIENT. Назначение этого типа брандмауэра — работа на шлюзе (маршрутизаторе). В брандмауэре присутствует защита от спуфинга (см. spoofing), Блокируется трафик в немаршрутизируемые сети и из немаршрутизируемых сетей на внешнем интерфейсе (что не всегда удачная идея, будьте внимательны если у вас есть приватные сети во внешнем окружении), осуществляется трансляция NAT (при включении опции natd_enable в rc.conf). Брандмауэр написан в расчёте на то, что на шлюзе работает DNS сервер, Web сервер и принимается почта, а так же работает служба NTP. Остальной трафик блокируется политикой.

Этот тип вам так же придётся отредактировать, чтобы вписать реальные названия интерфейсов и адреса.

CLOSED

Решительно всё блокируется. Фактически этот тип Брандмауэра ничего не делает, поскольку rc.firewall расчитан на работу при политике блокирующей любой трафик.

	Внимание
	Корректная работа скрипта rc.firewall возможна только если в ядре выбрана блокирующая политика. Если вы выставили в ядре опцию IPFIREWALL_DEFAULT_TO_ACCEPT, все перечисленные типы окажутся непригодны. В частности тип Брандмауэра CLOSE ничего не закроет. Мораль — остерегайтесь искуственного интеллекта пока не поймёте как он работает. Пишите правила фильтрации сами.

E.1.1.1.1.2. Пользовательские типы брандмауэров

Разумная практика состоит в том, чтобы самому написать правила брандмауэра, и подгружать их как пользовательский тип в rc.conf. Например так:

firewall_enable="YES"
firewall_type="/etc/rc.firewall.rules" 
firewall_quiet="YES" 
              

	Загружать правила из файла /etc/rc.firewall.rules
	Загружать правила «молча» — не выводить информации о загружаемых правилах на экран.

Синтаксис файла rc.firewall.rules будет слегка отличаться от rc.firewall. rc.firewall.rules — самостоятельный sh(1) сценарий и в нём не определены переменные, исользовавшиеся в rc.firewall. Если программирование в sh(1) представляет для вам проблему — не пугайтесь. Вам просто надо подряд много раз вызвать команду ipfw(8) с некоторыми аргументами, которые мы ниже обсудим. Но если вы хотите использовать всю мощь sh(1) обратитесь к Раздел 7.7, «Написание несложных Bourne-скриптов».

Команда list позволяет просмотреть список активированных правил:

# ipfw list
65000 allow ip from any to any
65535 deny ip from any to any
          

Опция -t позволяет увидеть когда прошёл последний пакет соответствовавший данному правилу:

# ipfw -t list
65000 Wed Jun  6 13:41:05 2007 allow ip from any to any
65535                         deny ip from any to any
          

Опция -a или команда show показывает значение счётчиков — сколько пакетов и сколько байт прошло через каждое правило.

# ipfw -a list
65000 722 331414 allow ip from any to any
65535   0      0 deny ip from any to any
# ipfw show
65000 760 336294 allow ip from any to any
65535   0      0 deny ip from any to any
          

Теперь посмотрим, какие правила можно использовать для настройки stateless фильтрации. (Т.е. фильтрации без учёта состояния соединений. stateful фильтрация — фильтрация с учётом состояния соединений, позволяет заметно упростить набор правил и повысить эффективность работы брандмауэра. Они будут рассмотрены в Раздел E.1.5, «Фильтрация с учётом состояния соединений»).

Правила в брандмауэр можно добавлять как при помощи утилиты ipfw(8) так и из файла:

# ipfw /etc/ipfw.rules
          

В последнем случае в файл строка за строкой кладутся аргуметы команды ipfw(8). Например:

add 1000 allow all from any to any
          

Мы с вами уже встречали это правло раньше, когда смотрели на открытый тип брандмауэра. Ключевые слова allow, accept, pass и permit — синонимы. В данном правиле разрешено проходит всем пакетам в любом направлении. В большинстве случаев, когда оказывается, что пакет соответствует данному правилу, его прохождение по цепочке правил прекращается и к нему применяется указанное в правиле действие. Т.е. первое правило выигрывает.

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

<команда> [<номер правила>] <действие> <протокол> from <источник> to <назначение>
          

Важные команды: add и delete — их смысл очевиден из названия. Номера правил колеблются от 0 до 65535. Последнее правило зарезервировано — это политика указанная в ядре. Даже если у вас открытый тип брандмауэра, последнее правило будет отражать политику указанную в ядре. Однако, поскольку первое правило выигрывает, правило с номером 65000, открывающее брандмауэр, будет работать, а на политику не попадёт ни один пакет.

Действие может быть одним из следующего списка:

В поле протокола можно указать любой протокол транспортного уравня. Как правило это tcp, udp или icmp, но может быть и любой другой из указанных в файле /etc/protocols. Протокол можно указывать как по имени, так и по номеру.

Адрес источника и адрес назначения имеют одинаковый формат:

Перед каждым адресом можно указать ключевое слово not с очевидным смыслом. Адреса можно указывать через запятую:

# ipfw add 100 allow all from mx1.yandex.ru, mx2.yandex.ru to me    
00100 allow ip from 213.180.200.10,213.180.223.121 to me
          

После указания хоста или сети, можно указать номер порта или название протокола из файла /etc/services. Перед портами можно указывать, а можно не указывать ключевые слова dst-port или src-port.

# ipfw add 100 allow all from me to any 22,25,80,1024-65535
00100 allow ip from me to any dst-port 22,25,80,1024-65535
# ipfw add 200 allow all from me to 172.19.0.34 telnet
00200 allow ip from me to 172.19.0.34 dst-port 23
          

Если в названии протокола встретится знак минус, его необходимо защищать обратным слешем: ftp\-data. (А если вы вводите команды в оболочке, или пишите сценарий, то сам обратный слеш тоже надо экранировать: ftp\\-data.) Если его не защищать, то минус будет воспринят как диапазон:

# ipfw add 100 allow tcp from any to me ftp\\-data-ftp
00100 allow tcp from any to me dst-port 20-21
          

Если операции с масками сети кажутся вам неясными, попробуйте обратиться к Раздел 6.8.2, «Маска подсети в формате CIDR».

Дествие unreach «код> — отбрасывает пакет и генерирует ответное ICMP сообщение с указанным кодом недостижимости. (Например network unreachable или host unreachable, т.е. сеть недоступна или хост недоступен). Код можно указывать как по номеру, так и по имени. Если вы не знаете, что значат эти коды, то значит вам не надо их употрелять.

Важная возможность брандмауэра IPFW не рассмотренная в Раздел E.1.2, «Основы синтаксиса правил ipfw» — возможность контроля за тем, на каком интерфейсе появился пакет и в каком он движется направлении. До сих пор мы делали предположения о направлении пакетов просто на основании адресов источника и назначения, однако узнать откуда пакет пришёл в самом деле мы не могли.

Если вы хотите, чтобы правило срабатывало только в отношении пакетов идущих внутрь или наружу, вы можете указывать ключевые слова in и out. Оба ключевых слова должны указываться там, где на приведённой выше диаграмме указано слово <интерфейс>, т.е. в конце правила, перед возможными опциями.

Например, если мы хотим обрабатывать все входящие пакеты вне зависимости от их направления, мы можем использовать правило

add 1000 allow all from any to any in
          

Например:

# ipfw add 100 count icmp from any to any in
00100 count icmp from any to any in
# ipfw add 200 count icmp from any to any out
00200 count icmp from any to any out
# ipfw add 300 count icmp from any to any      
00300 count icmp from any to any
$ ping -c3 172.19.0.34
PING 172.19.0.34 (172.19.0.34): 56 data bytes
64 bytes from 172.19.0.34: icmp_seq=0 ttl=64 time=1.358 ms
64 bytes from 172.19.0.34: icmp_seq=1 ttl=64 time=1.110 ms
64 bytes from 172.19.0.34: icmp_seq=2 ttl=64 time=1.174 ms

--- 172.19.0.34 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.110/1.214/1.358/0.105 ms
# ipfw show
00100     3      252 count icmp from any to any in
00200     3      252 count icmp from any to any out
00300     6      504 count icmp from any to any
65535     0        0 deny ip from any to any
          

Как видно, правило 100 считало только исходящие «пинги», правило 200 считало входящие «понги», а правило 300 считало и те и другие пакеты. («пинг» — echo-request пакет, «понг» — echo-reply пакет.)

Чтобы определять пакеты, идущие через конкретный интерфейс, используйте ключевое слово via и имя интерфейса. Например, если вы используете сетевую карту PCI 3Com 3c59x, Ваш сетевой интерфейс вероятно называется xl0. Чтобы пропустить все пакеты идущие через этот интерфейс вне зависимости от направления, используйте правило:

add 1100 allow all from any to any in via xl0
          

Или если вы хотите детектировать трафик направленный от любого хоста любому хосту, но выходящий через любой интерфейс:

add 1200 allow all from any to any out via any
          

В старых реализациях IPFW, если вы использовали сочетание ключевых слов in via xl0 в выводе команды ipfw list они заменялись на recv xl0, а out via xl0 на xmit xl0, сейчас это не так:

# ipfw add 100 allow all from any to any out via rl0
00100 allow ip from any to any out via rl0
# ipfw list
00100 allow ip from any to any out via rl0
65535 deny ip from any to any
          

Однако вы можете использовать ключевые слова recv и xmit в правилах. Причём даже одновременно. Например, следующее правило ищет исходящие пакеты, которые пришли через интерфейс ed0, а уйти собираются через интерфейс ed1:

ipfw add allow ip from any to any out recv ed0 xmit ed1
          

Пакеты ICMP, TCP и UDP бывают различного типа в зависимости от выставленных в них флагах. Мы можем определять типы этих пакетов при помощи описанных ниже правил.

1000 allow icmp from any to any out icmptypes 8
1100 allow icmp from any to any in icmptypes 0
1200 deny icmp from any to any in icmptypes 8
            

# ipfw 'add 100 allow all from any to me 80 tcpflags syn,!ack'
00100 allow ip from any to me dst-port 80 setup
            

allow 1000 from any to me established
allow 1100 from any to me 22,25,80 setup
deny 65535 from any to any
            

Ключевое слово frag используется для того, чтобы детектировать (и блокировать) фрагментированный трафик. Обилие такого трафика может свидетельствовать о совершении на вас DOS атаки (см. DOS атака и POD). С появлениес stateful фильтрации значение этой опции пошло на убыль, так как брандмауэры, осуществляющие фильтрацию на основе таблицы состояний, собирают заново фрагментированный трафик. Тем не менее, если вы используете stateless брандмауэр, с правилами подобными описанным в предыдущем разделе (setup и established), не лишне будет добавить перед ними такое правило:

900 deny all from any to any in frag
          

Одна из интереснейших возможностей IPFW — фильтрация на основе UID и GID сокета от которого получен пакет. Это значит, что исходящие соединения можно фильтровать по признаку «кто это соединение открыл». После ключевых слов uid и/или gid указывается номер или имя пользователя или группы.

Например, если мы хотим, чтобы только george мог ходить в интернет с нашей машины, мы можен написать следующее правило:

1000 allow all from me to any uid george
65535 deny all from any to any
          

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

Другое возможное назначение таких правил — ограничение полосы пропускания применительно к конкретным локальным пользователям в нашей системе. При этом надо понимать, что речь идёт лишь о локальных пользователях, если полосу пропускания надо ограничить пользователю вне нашего шлюза, находящемуся в локальной сети, на основе логина и пароля, то для этого удобнее использовать пакетный фильтр OpenBSD. (см. Раздел C.2.3.4, «Authpf: авторизация в пакетном фильтре»).

Наша система полностью готова к принятию журнальной информации, теперь мы можем задавать правила в брандмауэре, которые будут журналировать сообщения через syslogd(8).

Ключевое слово log заставляет брандмауэр генерировать сообщение для системного журнала каждый раз, когда срабатывае данное правило. данное ключевое слово должно идти вслед за действием:

65000 deny log all from any to any
          

Параметр logamount <num> — указывает на ограничение количества пакетов журналируемых через данное правило. Этот параметр перебивает глобальные настройки сделанные при помощи опции ядра IPFIREWALL_VERBOSE_LIMIT.

65000 deny log logamount 100 all from any to any
          

При журналировании в сохраняется следующая информация:

Например:

# sysctl net.inet.ip.fw.verbose=1
net.inet.ip.fw.verbose: 0 -> 1
# ipfw add 100 allow log icmp from me to any
00100 allow log icmp from me to any
$ ping -c3 172.19.0.34
PING 172.19.0.34 (172.19.0.34): 56 data bytes
64 bytes from 172.19.0.34: icmp_seq=0 ttl=64 time=1.603 ms
64 bytes from 172.19.0.34: icmp_seq=1 ttl=64 time=3.701 ms
64 bytes from 172.19.0.34: icmp_seq=2 ttl=64 time=1.220 ms

--- 172.19.0.34 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.220/2.175/3.701/1.091 ms
$ ping -c3 194.87.0.50
PING www.ru (194.87.0.50): 56 data bytes
64 bytes from 194.87.0.50: icmp_seq=0 ttl=59 time=5.026 ms
64 bytes from 194.87.0.50: icmp_seq=1 ttl=59 time=5.322 ms
64 bytes from 194.87.0.50: icmp_seq=2 ttl=59 time=5.600 ms

--- www.ru ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 5.026/5.316/5.600/0.234 ms
# cat /var/log/ipfw.log
Jun  7 12:55:58 house kernel: ipfw: 100 Accept ICMP:8.0 172.19.0.2 172.19.0.34 out via rl1
Jun  7 12:56:00 house last message repeated 2 times
Jun  7 12:56:28 house kernel: ipfw: 100 Accept ICMP:8.0 172.19.0.2 194.87.0.50 out via rl1
          

Обратите внимание как демон syslogd(8) обрабатывает ситуацию с повторяющимися событиями. Мы послали три пинга на адрес 172.19.0.34. syslogd(8) занёс в журнал первое событие, а остальные поместил в буфер, так как они по его мнению однотипные. После этого мы послали три пинга на другой адрес, это другое событие, поэтому syslog(8) освободил свой буфер выдав сообщение о двух непрожурналированных событиях: last message repeated 2 times. С одной строны, такое поведение экономит место в журнале, с другой стороны, оно затрудняет работу парсеров и главное, препятсвует сбору данных о времени совершения атаки. К сожалению, данную особенность syslogd(8) отключить невозможно. В этом смысле журналирование средствами пакетного фильтра OpenBSD выглядит более разумно (см. Раздел C.2.3.1, «Журналирование в пакетном фильтре»). Зато такая система может быть применена для конструирования системы активного реагирования на события, так как журналируемые события можно направлять из syslogd(8) на стандартный ввод любой программе, которая, например, может автоматически на лету переписывать правила брандмауэра. Впрочем, лучший вариант состоит в заворачивании пакетов в программу при помощи правила divert.

Для нашего первого примера мы используем старый функционал IPFW. Многие, кто использует в качестве примера для своего брандмауэра файл /etc/rc.firewall могут найти там подобные строки. В приведённом ниже примере мы, на основании TCP-флагов, разрешаем прохождение через наш брандмауэр. трафика SSH.

add 1000 allow tcp from any to any established
add 2000 allow tcp from any to any 22 in setup
          

Итак, мы предполагаем, что политика брандмауэра закрытая, т.е. в ядре отсутствует опция IPFIREWALL_DEFAULT_TO_ACCEPT, и у нас нигде нет правила вроде allow all from any to any. Приведённые строки разрешают весь уже установленный TCP трафик и разрешают открывать TCP соединения на 22-й порт. Мы можем расчитывать на то, что никакой другой TCP трафик через брандмауэр не пройдёт, так как правило номер 2000 позволяет открывать только соединения идущие на 22-й порт. В тоже время, данные правила будут пропускать «неправильные» пакеты, осколки не принадлежащие никаким соединениям на том основании, что в них есть флаг ACK. Настоящий брандмауэр с учётом состояния соединений должен был бы отфильтровать такие пакеты.

Аналогичного эффекта можно добиться при помощи правил, в которых вообще нет критериев изучающих флаги заголовка TCP, т.е. при помощи заведомо stateless брандмауэра:

add 1000 allow tcp from any to any out
add 2000 allow tcp from any to any 22 in
          

В приведённом примере разрешён любой исходящий трафик в любом направлении, а входящий трафик разрешён только на 22-й порт.

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

Вот более комплексный пример. Приведём правила, которые разрешают трафик FTP, SSH, SMTP и DNS в сеть 172.16.0.0/27:

add 1000 allow tcp from any to any established
add 2000 allow tcp from any to 172.16.0.0/27 21,22,25 setup
add 3000 allow udp from 172.16.0.0/27 to any 53
add 3100 allow udp from any 53 to 172.16.0.0/27
          

Поскольку трафик DNS осуществляется по протоколу UDP, мы не используем в правилах 3000 и 3100 ключевые слова established и setup. Заметим так же, что в приведённом примере мы открыли только командный канал для FTP. Между тем как нам надо ещё пропустить данные FTP. Подробнее о функционировании этого протокола можно прочитать в Раздел C.2.3.3.1, «Режимы FTP».

Как уже было сказано выше, проверка только флагов заголовка TCP ограничивает применимость stateful фильтрации. Начиная с FreeBSD 4.0 в IPFW появилась полноценная фильтрация с учётом состояния соединений. Это достигнуто путём создания так называемых динамических правил. Динамические правила образуются автоматически, если пакет соответствует правилу, в котором присутсвует ключевое слово keep-state или ключевое слово limit.

Динамические правила находятся в цепочке правил там же, где они заведены, т.е. если правило keep-state имеет номер 50000 и перед ним имеется пятьсот правил, проверяющих разнообразные параметры пакетов, то каждый из потенциально разрешённых пакетов, проходит проверку на этих пятистах правилах. Это не очень удачное решение с точки зрения производительности. Чтобы пропустить все потенциально разрешённые пакеты, мы можем в самом начале брандмауэра указать правило check-state:

add 1000 check-state
add 2000 allow tcp from any to any 22 in setup keep-state
          

Вот переменные ядра влияющие на величины таймаутов:

$ sysctl -a | grep dyn.*lifetime
net.inet.ip.fw.dyn_ack_lifetime: 300
net.inet.ip.fw.dyn_syn_lifetime: 20
net.inet.ip.fw.dyn_fin_lifetime: 1
net.inet.ip.fw.dyn_rst_lifetime: 1
net.inet.ip.fw.dyn_udp_lifetime: 10
net.inet.ip.fw.dyn_short_lifetime: 5
$ sysctl -ad | grep dyn.*lifetime
net.inet.ip.fw.dyn_ack_lifetime: Lifetime of dyn. rules for acks
net.inet.ip.fw.dyn_syn_lifetime: Lifetime of dyn. rules for syn
net.inet.ip.fw.dyn_fin_lifetime: Lifetime of dyn. rules for fin
net.inet.ip.fw.dyn_rst_lifetime: Lifetime of dyn. rules for rst
net.inet.ip.fw.dyn_udp_lifetime: Lifetime of dyn. rules for UDP
net.inet.ip.fw.dyn_short_lifetime: Lifetime of dyn. rules for other situations
          

Мне кажется, что таймауты по умолчанию принятые в FreeBSD для корпоративного шлюза являются слишком жёсткими. Возможно в ряде случаев их стоит увеличить. Особенно если вы не слишком лимитированы объёмом оперативной памяти и можете увеличить размер таблицы с динамическими правилами (см. ниже).

Рассмотрим, как работают приведённые здесь два правила.

Надо заметить, что в примере приведённом в Раздел E.1.5.1, «Основы учёта состояний соединений (stateful inspection)», поддельный пакет был бы пропущен правилом с ключевым словом established.

Существует так же такой тип сетевых атак как SYN-флуд. Он заключается в том, что злоумышленник организует большой поток TCP пакетов с выставленным в них флагом SYN. (См. так же Раздел C.2.1.4.9, «TCP SYN proxy».) Такой флуд переполняет таблицы сокетов на атакуемой машине, что не даёт возможности открыть соединения для легальных пользователей. Т.е. совершается DOS-атака.

В брандмауэре такая атака приводит к росту количества динамических правил. Текущее количество динамических правил можно узнать из переменной net.inet.ip.fw.dyn_count, а размер таблицы с динамическими правилами ограничен переменной net.inet.ip.fw.dyn_max, которая по умолчанию равна 1000.

Если количество разрешённых соединений достигнет предела, то новые динамические правила перестанут образовываться и новые соединения не будут разрешены в брандмауэре.

Фильтрация с учётом состояния применима не только к трафику TCP. Например, ниже приведено правило, позволяющее нам пинговать из внутренней сети внешнюю, но не пропускающее обратные пинги:

add 1000 check-state
add 2000 allow icmp from any to any out icmptypes 8 keep-state
          

Правило номер 2000 заводит динамическое правило в момент, когда мы посылаем пинг, нас можно будет пропинговать только с той машины, которую мы пингуем, и только в тот самый момент, пока не истёк таймаут от нашего пинга. (По умолчанию 5 секунд — net.inet.ip.fw.dyn_short_lifetime).

Впрочем, надо заметить, что во-первых, чтобы мы могли пинговать хост снаружи, нам надо, чтобы он откликался быстрее чем за 5 секунд, а это не всегда так. Во-вторых, если злоумышленник нащупает время, когда мы пингуем его, он может продлевать действие динамического правила непрерывно бомбя нас пингами. Опять-таки, я говорю это не как о потенциальной опастности, а для понимания механизма действия динамических правил.

Для просмотра текущих динамических правил, можно применять агрумент -d для команды ipfw:

# ipfw -d show
01000   0      0 check-state
02000 1194 704133 allow tcp from any to any keep-state
65535   0      0 deny ip from any to any
## Dynamic rules (18):
02000  44  38497 (296s) STATE tcp 194.1.161.14 2316 <-> 172.19.0.2 80
02000  26  18377 (296s) STATE tcp 194.1.161.14 2318 <-> 172.19.0.2 80
02000   4    320 (1s) STATE tcp 172.19.0.34 38100 <-> 172.19.0.2 22
            

Обратите внимание, что в счётчике указано 18 динамических правил, а в листинге приведено только три. Это связано с тем, что правила, которые истекли по таймауту не удалены из таблицы динамических правил. Они не работают, но в таблице присутсвуют и будут замещены только когда это понадобится. Полностью таблицу динамических правил можно просмотреть при помощи опции -e (от слова expired):

# ipfw -de show
01000   0      0 check-state
02000 1194 704133 allow tcp from any to any keep-state
65535   0      0 deny ip from any to any
## Dynamic rules (18):
02000  44  38497 (296s) STATE tcp 194.1.161.14 2316 <-> 172.19.0.2 80
02000  26  18377 (296s) STATE tcp 194.1.161.14 2318 <-> 172.19.0.2 80
02000   4    320 (1s) STATE tcp 172.19.0.34 38100 <-> 172.19.0.2 22
02000    0       0 (0s) STATE tcp 195.222.87.11 62801 <-> 172.19.0.2 80
02000    8    1320 (0s) STATE tcp 195.222.87.11 56912 <-> 172.19.0.2 80
02000    9    1660 (0s) STATE tcp 193.108.240.20 45900 <-> 172.19.0.2 80
02000    8    1321 (0s) STATE tcp 195.222.87.11 54613 <-> 172.19.0.2 80
02000    0       0 (0s) STATE tcp 195.222.87.11 61268 <-> 172.19.0.2 80
02000    9    1906 (0s) STATE tcp 193.108.240.20 45910 <-> 172.19.0.2 80
02000    9    1958 (0s) STATE tcp 193.108.240.20 45911 <-> 172.19.0.2 80
02000    8    1603 (0s) STATE tcp 193.108.240.20 45909 <-> 172.19.0.2 80
02000    8    1598 (0s) STATE tcp 193.108.240.20 45907 <-> 172.19.0.2 80
02000    9    1662 (0s) STATE tcp 193.108.240.20 45904 <-> 172.19.0.2 80
02000    8    1585 (0s) STATE tcp 193.108.240.20 45905 <-> 172.19.0.2 80
02000  123  108527 (0s) STATE tcp 80.249.130.195 61576 <-> 172.19.0.2 80
02000   41   26403 (0s) STATE tcp 80.249.229.26 57170 <-> 172.19.0.2 80
02000   79   67509 (0s) STATE tcp 80.249.130.195 58511 <-> 172.19.0.2 80
02000  164  136800 (0s) STATE tcp 195.222.87.11 55679 <-> 172.19.0.2 80
            

В составе IPFW имеется полезный инструмент для тестирования сети, с помощью которого можно случайно отбрасывать пакеты с некоторой вероятностью. Эта возможность активируетя при помщи опции prob и следующей за ним вероятностью — дробным числом от 0 до 1. Т.е. критерий prob 0.9 будет удовлетворён в 90% случаев и неудовлетворён в 10% случаев. Ниже приведена синтаксическая диаграмма:

<command> [<rule #>] [prob <match_probability>] <action> [log
[logamount <number>]] <proto> from <source> to <destination>
[<interface-spec>] [<options>]
          

Например, чтобы отбрасывать 20% «пингов», мы можем использовать следующее правило:

add 1000 prob 0.8 allow icmp from any to any in icmptypes 8
          

Или мы можем отбрасывать половину пакетов TCP SYN идущих к web-серверу, для того, чтобы эмулировать состояние перегрузки:

add 1000 prob 0.5 allow tcp from any to any in setup via ep0
          

Любые дополнительные возможности по контролю за трафиком требуют наличия dummynet(4). Эта система должна быть встроена в ядро при помощи опции

options         DUMMYNET
          

либо подгружена в виде модуля:

# kldload dummynet
          

Когда dummynet(4) окажется доступен, мы сможем используя ключевое слово pipe направлять трафик в некоторые пронумерованные каналы. Например:

# kldload dummynet
# ipfw pipe 10 config bw 100Kb/s
# ipfw pipe list
00010: 100.000 Kbit/s    0 ms   50 sl. 0 queues (1 buckets) droptail
          

Это простое правило позволяет ограничить полосу пропускания для трафика направляемого в 10-й канал величиной 100 килобит в секунду. Ширину полосы пропускания можно указывать в разных единицах: bit/s, Byte/s, Kbit/s, KByte/s Mbit/s, MByte/s. Ключевое слово bw указывает на то, что данное правило влияет на полосу пропускания (bandwidth).

Другое действие, которое можно выполнить при помощи dummynet(4) — введение задержек, при помощи которых можно эмурировать реальные задержки происходящие при работе в распределённых сетях:

pipe 10 config delay 100
          

После ключевого слова delay указывается величина задержки в миллисекундах. В приведённом примере трафик принадлежащий 1-му каналу будет задерживаться на 100 миллисекунд.

Ключевое слово plr позволяет средствами dummynet(4) реализовывать то же, что мы делали в предыдущем разделе при помощи опции prob. Например, того же эффекта, что и при помощи опции prob 0.8 можно добиться при помощи канала

pipe 10 config plr 0.2
          

plr расшифровывается как packet loss rate и определяет вероятность, с которой пакеты теряются в распределённой сети.

$ ifconfig rl0
rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=8<VLAN_MTU>                             ~~~~~~~~
        inet 172.20.0.2 netmask 0xffffff00 broadcast 172.20.0.255
        ether 00:80:48:2d:f7:15
        media: Ethernet autoselect (none)
        status: no carrier
            

pipe 10 config bw 56Kbit/s
            

pipe 10 config bw 56Kbit/s queue 5Kbytes
            

pipe 10 config mask src-ip 0x000000ff bw 100Kbit/s queue 10Kbytes
pipe 20 config mask dst-ip 0x000000ff bw 100Kbit/s queue 10Kbytes
add 1000 add pipe 10 all from 192.168.0.0/16 to any out via xl0
add 2000 add pipe 20 all from 192.168.0.0/16 to any in via xl0