Утилита ipfw - интерфейс пользователя для управления системой сетевой
защиты ipfw (4)и формирователя трафика dummynet (4) в FreeBSD.
ОБРАТИТЕ ВНИМАНИЕ: эта страница относится к более новой версии ipfw,
представленной в июле 2002 г., также известной как ipfw2. Команды,
перечисленные здесь - надмножество старой системы сетевой защиты,
которую мы назовем ipfw1, когда необходимо различить две версии.
ipfw2 стандарт в FreeBSD CURRENT, тогда как FreeBSD STABLE все еще
использует ipfw1, если ядро не откомпилировано с options IPFW2 и
/sbin/ipfw, и /usr/lib/libalias не перетранслированы с -DIPFW2 и
повторно не переустановлены (тот же самый эффект может быть достигнут,
добавив перед buildworld IPFW2=TRUE к /etc/make.conf).
См. список особенностей в разделе РАСШИРЕНИЙ IPFW2, которые не
присутствуют в ipfw1. Этот список может быть также полезен при
пересмотре ваших правил для более эффективной их записи.
Конфигурация ipfw, или наборы правил, состоит из списка правил,
пронумерованных от 1 до 65535. Пакеты попадают в ipfw из множества
различных мест в стеке протокола (в зависимости от источника и адресата
пакета, возможно, что ipfw вызывается множество раз для одного и того же
пакета). Пакет, пришедший в систему сетевой защиты, сравнивается с
каждым из правил набора правил в системе сетевой защиты. Когда найдено
соответствие правилу, выполняется соответствующее действие.
В зависимости от действия и некоторых системных параметров настройки,
пакеты могут быть повторно введены в систему сетевой защиты в правило
после правила, вызвавшего соответствие, для дальнейшей обработки.
Набор правил ipfw всегда содержит заданное по умолчанию правило (с
номером 65535), которое не может быть изменено, и соответствует всем
пакетам. Действие, связанное с заданным по умолчанию правилом может быть
или deny или allow в зависимости от того, как сконфигурировано ядро.
Если набор правил включает одно или более правил с опцией keep-state или
limit, то ipfw создаст динамические правила, соответствующие точным
параметрам (адрес и порт) пакета соответствия.
Динамические правила, которые имеют ограниченное время жизни,
проверяются при первом возникновении правил check-state, keep-state или
limit, и типично используются для того чтобы открыть систему сетевой
защиты по требованию только для законного трафика. См. STATEFUL СИСТЕМУ
СЕТЕВОЙ ЗАЩИТЫ и раздел ПРИМЕРОВ ниже для получения более подробной
информации относительно stateful поведения ipfw.
Все правила (включая динамические) имеют несколько связанных счетчиков:
количество пакетов, количество байт, количество регистраций и индикация
времени последнего соответствия. Счетчики могут быть отображены или
сброшены командами ipfw.
Правила можно добавить командой add; удалить индивидуально или в группах
командой delete, и глобально командой flush; произвольно отобразить с
содержанием счетчиков, используя команды show и list. Наконец, счетчики
могут быть сброшены командами resetlog и zero.
Также, каждое правило принадлежит одному из 32 различных наборов, и есть
команды ipfw для глобального управления наборами, типа включить,
отключить, заменить наборы, переместить все правила в другой набор,
удалить все правила в наборе. Они могут быть полезны для установки
временных конфигураций или их проверки. См. раздел НАБОРЫ ПРАВИЛ для
получения более подробной информации относительно наборов.
Доступны следующие ключи ipfw:
-a При распечатке, показать значениям счетчиков. Команда show
подразумевает только эту опцию.
-c При вводе или показе правил, печатать их в компактной форме, то есть
без дополнительной строки " ip from any to any ", когда это не несет
никакой дополнительной информации.
-d При распечатке, показать динамические правила в дополнение к
статическим.
-e При распечатке, если -d опция была определена, также показывать
устаревшие динамические правила.
-f Не запрашивать подтверждения для команд, которые могут вызвать
проблемы при неправильном использовании, то есть flush. Это
подразумевается если нет номера tty, связанного с процессом.
-N Пробовать разрешать адреса и имена сервисов в выводе.
-q При выполнении комманд add, zero, resetlogили flush, не выдавать
информацию о действиях (подразумевается -f). Это полезно при изменении
правил, выполняя множественные команды ipfw в сценарие (например
`sh/etc/rc.firewall'), или при обработке файла с множеством правил ipfw,
через удаленный сеанс входа в систему. Если flush выполнняется в
нормальном режиме (с заданной по умолчанию конфигурацией ядра), ipfw
напечатает сообщение. Поскольку все правила сброшены, сообщение нельзя
направить сеансу входа в систему, тем самым вызывая завершение
удаленного сеанса входа в систему и остаток от набора правил будет не
обработан. При этом придется восстановить набор правил с системной
консоли.
-S При распечатке правил, показать набор, которому принадлежит каждое
правило. Если этот флажок не определен, отключенные правила не будут
показаны.
-s [поле] При распечатке каналов, сортировать согласно одному из четырех
счетчиков (полные и текущие пакеты или байты).
-t При распечатке, показать метку времени последнего соответствия.
Чтобы упростить конфигурацию, правила могут быть помещены в файл,
который обрабатывается, используя ipfw, как показано в первой строке
резюме. Должен использоваться полный путь. Файл будет читаться строка за
строкой и каждая строка будет применена как аргумент утилиты ipfw.
При необходимости, может быть определен препроцессор (-p препроцессор),
у которого путь должен быть каналом. Полезными препроцессорами являются
cpp(1) и m4(1). Если первый символ препроцессора не наклонная черта
вправо ('/'), применяется обычная процедура поиска ПУТИ. В средах, где
не все файловые системы смонтированы во время выполнения ipfw (например,
если они монтируются по NFS) должны быть предприняты меры
предосторожности. Если после определенного параметра -p, могут
следовать дополнительные спецификации -D и -U и они будут переданы
препроцессору. Это позволяет строить гибкие файлы конфигурации (подобно
зависимости их от имени хоста) и использовать макроопределения для
централизации часто используемых параметров (подобно адресам IP).
ipfw pipe и команды очереди используются для конфигурирования
формирователя трафика, как показано ниже в разделе КОНФИГУРАЦИИ
ФОРМИРОВАТЕЛЯ ТРАФИКА.
ПОТОК ПАКЕТОВ
ipfw может быть вызван из различных мест в стеке протокола, под
управлением нескольких системных параметров и для проектирования
надлежащего набора правил, важно понять, когда это происходит. Места из
которых вызывается ipfw, упомянуты ниже, вместе с переменными sysctl,
управляющими его вызовами.
Как видно из приведенной схемы, число прохождений одного и того же
пакета через систему сетевой защиты может изменяться от 0 до 4 в
зависимости от источника пакета, адресата и системной конфигурации. В
каждом из этих мест, пакет передается ipfw со всеми (и только) полями,
которые принадлежат данному уровню. То есть, входящие пакеты будут
включать MAC заголовок, если ipfw вызван из ether_demux (), но когда
ipfw вызван из ip_input () MAC заголовок из пакетов будет удален.
Всегда используется Законченный набор правил, независимо от места, из
которого вызван ipfw, или адреса-источника пакета. Если правило содержит
некоторые образцы соответствия или действия, которые не допустимы для
места вызова (например, требующие соответствия MAC заголовка, если ipfw
вызывают из ip_input ()), образец соответствия не будет соответствовать.
Однако оператор not перед такими образцами заставит образец всегда
соответствовать на тех пакетах, которые могли бы вызвать нежелательные
результаты. Таким образом, на ответственности программиста в случае
необходимости записывать подходящий набор правил для дифференцирования
среди возможных мест. Здесь может быть полезно правило skipto, как
пример:
# пакеты от ether_demux или bdg_forward
ipfw add 10 skipto 1000 all from any to any layer2 in
# пакеты от ip_input
ipfw add 10 skipto 2000 all from any to any not layer2 in
# пакеты от ip_output
ipfw add 10 skipto 3000 all from any to any not layer2 out
# пакеты от ether_output_frame
ipfw add 10 skipto 4000 all from any to any layer2 out
(да, в настоящее время нет никакого способа дифференцировать между
ether_demux и bdg_forward).
где тело правила определяет, какая информация используется для
фильтрации пакетов, среди следующего:
Поля заголовка Уровня 2 если доступно
Протокол IPv4 TCP, UDP, ICMP, и т.д.
Источник и назначение адрес и порт
Направление См. Раздел ПОТОК ПАКЕТОВ
Интерфейс передачи и получения по имени или адресу
Поля заголовка IP версия, тип службы, длинна дейтаграммы, идентификация,
флаг фрагментации (ненулевой IP оффсет), время жизни
Поля заголовка TCP флаги TCP (SYN, FIN, ACK, RST,и т.д.), порядковый
номер, номер подтверждения, окно
типы ICMP для ICMP пакетов
код пользователя/группы когда пакет может быть асоциирован с локальным
гнездом.
Обратите внимание, что часть вышеупомянутой информации, например
исходный MAC или IP адрес и TCP/UDP порты, могут быть легко подменены,
таким образом, при фильтрации по этим полям, не могут быть гарантированы
требуемые результаты.
rule_number
Каждое правило имеет номер (rule_number ) в диапазоне 1.. 65535, с
последним, зарезервированным для заданного по умолчанию правила. Правила
проверяются последовательно по номерам правил. Несколько правил могут
иметь один и тот же номер, при проверке они обрабатываются в том же
порядке, в котором добавлялись. Если правило введено без определения
номера, ядро назначит такой номер, что правило станет последним перед
заданным по умолчанию правилом. Автоматические номера правил
назначаются, увеличивая последний номер правила не по умолчанию
значением переменной sysctl net.inet.ip.fw.autoinc_step который имеет
значение по умолчанию 100. Если это не возможно (например, потому что
номер получился бы больше максимально допустимого номера правила),
используется номер последнего правила не по умолчанию.
set set_number
Каждое правило связано с номером набора (set_number) в диапазоне от 0
до 31, с последним, зарезервированным для заданного по умолчанию
правила. Наборы могут быть индивидуально заблокированы и активированы,
так что этот параметр имеет фундаментальное значение для глобальной
манипуляции наборами правил. Это может также использоваться для
упрощения удаление групп правил. Если правило введено, без определения
номера набора, номер набора устанавливается в 0.
prob match_probability
Соответствие объявлено только с указанной вероятностью (число с
плавающей точкой между 0 и 1). Это может быть полезно для многих
приложений типа случайного отбрасывания пакетов или (вместе с
dummynet(4)) для моделирования эффекта множественных путей, ведущих к
повреждению пакета при доставке.
log [logamount number]
Если пакет соответствует правилу с ключевым словом log, сообщение будет
зарегистрировано в syslogd(8) с уровнем LOG_SECURITY. Регистрация
происходит только если переменная sysctl net.inet.ip.fw.verbose
установлена в 1 (значение по умолчанию, если ядро откомпилировано с
IPFIREWALL_VERBOSE) и количество зарегистрированных пакетов для
определенного правила не превышает параметр logamount. Если logamount не
определен, предел берется из переменной sysctl
net.inet.ip.fw.verbose_limit. В любом случае, значение 0 удаляет предел
регистрации.
Как только предел достигнут, регистрацию можно опять возобновить,
очистив счетчик регистрации или счетчик пакетов для того правила, см.
команду resetlog.
ДЕЙСТВИЯ ПРАВИЛА
Правило может быть связано с одним из следующих действий, которые будут
выполнены, если пакет соответствует условию правила.
allow | accept | pass | permit Пропустить пакеты, соответствующие
правилу. Просмотр правил заканчивается
check-state Проверяет пакет динамическим набором правил. Если
соответствие найдено, выполняется действие, связанное с правилом,
которое сгенерировало это динамическое правило, иначе переход к
следующему правилу. Правила сheck-state не имеют тела. Если не найдено
никаких правил check-state, динамический набор правил проверяется в
первом правиле keep-state или limit.
count Обновить счетчики для всех пакетов соответствующих правилу. Поиск
продолжается со следующего правила.
deny | drop Отброс пакетов, соответствующих этому правилу. Поиск
заканчивается.
divert port Отклонить пакеты, которые соответствуют этому правилу в
divert (4) гнездо, связанное с портом port. Поиск заканчивается.
fwd | forward ipaddr[,port] Изменить следующий переход при соответствии
пакетов с ipaddr, который может быть адрес IP в точечной нотации или
именем хоста. При соответствии поиск заканчивается.
pipe pipe_nr Направить пакет в "канал" dummynet(4) (для ограничения
полосы пропускания, задержки, и т.д.). См. Раздел КОНФИГУРАЦИИ
ФОРМИРОВАТЕЛЯ ТРАФИКА для дальнейшей информации. Поиск заканчивается;
однако, на выходе из канала и если sysctl (8) переменная
net.inet.ip.fw.one_pass не установлена, пакет передают снова к коду
системы сетевой защиты, начинающемуся со следующего правила.
queue queue_nr Направить пакет через "очередь" dummynet (4) (для
ограничения полосы пропускания, используя WF2Q).
reject Синоним для unreach host.
reset Забраковать пакеты, которые соответствуют этому правилу, и если
пакет - пакет TCP, попробовать послать сообщение TCP "сброс" (RST).
Поиск заканчивается.
skipto number Пропустить все последующие правила с номерами меньше чем
number. Поиск продолжается с первого правила с номером number или
больше.
tee port Посылать копию пакетов, соответствующих этому правилу в
divert(4) гнездо, связанное с портом port. Поиск заканчивается, и
первоначальный пакет пропускается (но см. раздел ОШИБКИ(ДЕФЕКТЫ) ниже).
unreach code Забраковать пакеты, которые соответствуют этому правилу, и
попробовать послать ICMP сообщение о недостижимости с кодом code, где
code число от 0 до 255, или один из псевдонимов: net, host, protocol,
port, needf needfrag, srcfail, net-unknown, host-unknown, isolated,
host-prohib, tosnet, toshost, filter-prohib, host-precedence или
precedence-cutoff. Поиск заканчивается.
ТЕЛО ПРАВИЛА
Тело правила содержит нуль или больше образцов (типа определения адресов
источника и назначения или портов, вариантов протокола, входящих или
исходящих интерфейсов, и т.д.), которым пакет должен соответствовать для
того, чтобы быть признанным. Вообще, образцы связаны (неявным)
оператором and - то есть все должны соответствовать для соответствующего
правила. Индивидуальные образцы могут быть обозначены оператором not для
того, чтобы полностью изменить результат соответствия, как в
ipfw add 100 allow ip from not 1.2.3.4 to any
Дополнительно, наборы альтернативного соответствия (или-блокировки),
могут быть созданы, помещая образцы в списках, заключенных между
круглыми скобками () или фигурными скобками {}, и используя оператор or
следующим образом:
ipfw add 100 allow ip from { x or not y or z } to any
Допускается только один уровень круглых скобок. Обратите внимание на то,
что большинство оболочек имеет специальные назначения для круглых скобок
или фигурных скобок, так что, для предотвращения таких интерпретаций,
желательно их экранировать наклонной чертой влево ().
Тело правила должно вообще включать спецификацию адреса источника и
назначения. Ключевое слово any может использоваться в различных местах,
для определения того, что содержимое требуемого поля является
безразличным.
Тело правила имеет следующий формат:
Поля правила имеют следующее значение:
proto: protocol | { protocol or ... }
IPv4 протокол (или блок ч-з оператор or нескольких протоколов)
указанных по номерам, или именам (законченный список см.
/etc/protocols). Ключевые слова ip или all подразумевают, что любой
протокол будет соответствовать.
src и dst: ip-address | { ip-address or ... } [ports]
Отдельный ip-адрес, илиблок адресов ч-з оператор или, произвольно
сопровождаемые спецификаторами портов.
ip-address:
Адрес (или набор адресов) указанный одним из следующих способов,
произвольно которым предшествуют оператор not:
any
любой адрес IP.
me
любой адрес IP, сконфигурированный на интерфейсе системы. Список адресов
оценивается во время анализа пакета.
numeric-ip | hostname
Соответствует отдельному адресу IPv4, указанному в точечной нотации или
именем хоста. Имя хоста разрешается во время добавления правила к списку
правил системы сетевой защиты.
addr/masklen
Все адреса с базовым адресом (указанный в точечной нотации или именем
хоста) и маской шириной masklen бит. Как пример, 1.2.3.4/25 будет
соответствовать всем IP адресам от 1.2.3.0 до 1.2.3.127.
addr/masklen{num,num,...}
Все адреса из диапазона определенного парой addr/masklen (указанном в
точечной нотации или именем хоста) и чей последний байт находится в
списке, заключенном между фигурными скобками {}. Обратите внимание, что
не должно быть пробелов между фигурными скобками, запятыми и числами.
Поле masklen используется для того, чтобы ограничить размер набора
адресов, и может иметь любое значение между 24 и 32. Как пример, адрес,
указанный как 1.2.3.4/24{128,35,55,89} будет соответствовать следующим
IP адресам: 1.2.3.128 1.2.3.35 1.2.3.55 1.2.3.89. Этот формат особенно
полезен для обработки разреженных наборов адресов в пределах одного
правила. Поскольку проверка соответствия происходит, используя битовую
маску, это занимает постоянное время и кардинально уменьшает сложность
наборов правил.
ports: [not] {port | port-port} [,...]
Для протоколов, которые поддерживают, номера портов (типа TCP и UDP),
могут быть определены дополнительные порты, как один или более портов
или диапазоны портов, отделенных запятыми и дополнительный оператор not
. Примечание '-' определяет диапазон портов (включая границы).
Вместо числовых значений портов могут использоваться имена служб
(из/etc/services). Длина списка портов ограничена 30 портами или
диапазонами, хотя можно определить большие диапазоны, используя блоки
объединенные оператором or в разделе вариантов правила.
Наклонная черта влево ('') может использоваться для экранирования
символа черточки ('-') в имени сервиса (в оболочке, наклонная черта
влево должна быть напечатана дважды для того, чтобы избежать
использование ее самой оболочкой как символа ESC).
ipfw add count tcp from any ftp\-data-ftp to any
Фрагментированные пакеты, которые имеют ненулевое смещение (то есть не
сначала, фрагмента), никогда не будут соответствовать правилу, которое
имеет одну или более спецификацию порта. См. опцию frag для подробностей
относительно соответствия фрагментированных пакетов.
ВАРИАНТЫ ПРАВИЛА (ОБРАЗЦЫ СООТВЕТСТВИЯ)
В пределах правил могут использоваться дополнительные образцы
соответствия. В правиле могут присутствовать нуль или больше этих, так
называемых вариантов, произвольно предваренных операндом not, и возможно
сгруппированных в или-блоки.
Могут использоваться следующие образцы соответствия (перечисленные в
алфавитном порядке):
bridged Совпадают только с пакетами моста.
dst-ip ip_address Совпадают IP пакеты, IP адрес назначения которых один
из адреса(ов) указанных как параметр.
dst-port source ports Совпадают IP пакеты, порт назначения которых один
из порта(ов) указанных как параметр.
established Совпадают пакеты TCP, в которых установлен бит RST или ACK.
frag Совпадают пакеты, которые являются фрагментами, но не первым
фрагментом дейтаграммы IP. Обратите внимание, что эти пакеты не будут
иметь заголовков протокола (напр. TCP, UDP), так варианты, которые
контролируют их заголовки, никогда не будут соответствовать.
gid group Совпадают все TCP или UDP пакеты, посланные или полученные для
группы. Группа может быть определена по имени или номеру.
icmptypes types Совпадают ICMP пакеты, тип ICMP которых находится в
списке types. Список может быть определен как любая комбинация
диапазонов или индивидуальных типов отделенных запятыми. Поддерживаемые
типы ICMP:
Совпадают входящие или исходящие пакеты, соответственно. in и out
являются взаимоисключающими (фактически, out это not in).
ipid id Совпадают IP пакеты, ip_id поле которых имеет значения id.
iplen len Совпадают IP пакеты, полная длина которых, включая заголовок и
данные, составляет len байт.
ipoptions spec Совпадают пакеты, заголовок IP которых содержит
разделенный запятыми список вариантов, указанных в spec. Поддерживаемые
варианты IP: ssrr (строгий исходный маршрут), lsrr (свободный исходный
маршрут), rr (запись маршрута пакета) и ts (временная метка). отсутствие
определенной опции может быть обозначено с '!'.
ipprecedence precedence Совпадают IP пакеты, поле старшинства которых
равно precedence.
iptos spec Совпадают IP пакеты, поле tos которых содержит разделенный
запятыми список типов обслуживания, указанных в spec. Поддерживаемые
типы обслуживания IP:
limit {src-addr | src-port | dst-addr | dst-port} N Система сетевой
защиты позволит только N подключений с тем же самым набором параметров,
определенных в правиле. Могут быть определены один или более адресов
источника и назначения и портов.
{ MAC | mac } dst-mac src-mac Пакеты соответствия с данными адресами
dst-mac и src-mac, указанными как ключевое слово any (соответствующий
любому MAC адресу), или шестью группами шестнадцатеричных цифр,
отделенных двоеточиями и необязательно сопровождаемые маской,
указывающей, сколько бит существенно, напр: MAC 10:20:30:40:50:60/33 any
Обратите внимание, что порядок MAC адресов (сначала адресат, затем
источник) такой же, как на проводе, но противоположен используемому для
адресов IP.
mac-type mac-type Совпадают пакеты, поле Ethernet Type которых
соответствует одному из определенных как параметр типов. mac-type
определяется тем же самым способом как номера портов (то есть одно или
более отделенных запятыми отдельных значений или диапазонов). Вы можете
использовать символические имена для известных значений, таких как vlan,
ipv4, ipv6. Значения могут быть введены как десятичные или
шестнадцатеричные числа (если предшествует 0x) и они всегда выводятся
как шестнадцатеричные числа (если не используется опция -N, тогда типы
будут разрешены в символический вид).
proto protocol Совпадают пакеты с соответствующим протоколом IPv4.
recv | xmit | via {ifX | if* | ipno | any} Совпадают пакеты, полученные,
переданные или проходящие через соответствующий интерфейс, указанный
точным именем (ifX), именем устройства (if*), адресом IP или через любой
интерфейс.
Ключевое слово via заставляет проверять интерфейс всегда. Если
используется recv или xmit вместо via, то проверяется только получающий
или передающий интерфейс (соответственно). Определяя оба, возможно
установить соответствие пакетам, основанным и на получающем, и
передающем интерфейсе, например:
ipfw add deny ip from any to any out recv ed0 xmit ed1
Интерфейс recv может быть проверен на входящих или на исходящих пакетах,
в то время как интерфейс xmit может быть проверен только на исходящих
пакетах. Так требуется out (и in недопустим) всякий раз, когда
используется xmit.
tcpflags spec Только пакеты TCP. Соответствуют, если заголовок TCP
содержит разделенный запятыми список флагов, указанных в spec.
Поддерживаемые TCP флги:
fin, syn, rst, psh, ack и urg. Отсутствие отдельного флага может
быть обозначено с '!'. Правило, которое содержит спецификацию tcpflags,
никогда не может соответствовать фрагментированному пакету, который
имеет ненулевое смещение. См. опцию frag для подробностей относительно
соответствия фрагментированных пакетов.
tcpseq seq Только пакеты TCP. соответствует, если поле порядкового
номера заголовка TCP установлено в seq.
tcpwin win Только пакеты TCP. Соответствует, если поле окна заголовка
TCP установлено в win.
tcpoptions spec Только пакеты TCP. Соответствует, если заголовок TCP
содержит разделенный запятыми список вариантов, указанных в spec.
Поддержываемые варианты TCP:
mss (максимальный размер сегмента), window (объявление окна tcp), sack
(выборочный ack), ts (rfc1323 временная метка) и cc (rfc1644 t/tcp
счетчик подключений). Отсутствие определенной опции может быть
обозначено с '!'.
uid user Соответствует всем TCP или UDP пакетам, посланным или
полученным для пользователя. Пользователь может быть определен по имени
или идентификационному номеру.
НАБОРЫ ПРАВИЛ
Каждое правило принадлежит одному из 32 различных наборов,
пронумерованных от 0 до 31. Набор 31 зарезервирован для заданного по
умолчанию правила.
По умолчанию правила помещаются в набор 0, если Вы не используете
атрибут set N при вводе нового правила. Наборы можно индивидуально и
множественно активировать или блокировать, так что этот механизм
позволяет простым способом хранить множественные конфигурации системы
сетевой защиты и быстро переключаться между ними. Команда, для
активизации/отключения набора:
ipfw set disable number ... [enable number ...]
где может быть определено множество разделов enable или disable.
Выполнение команды является общим на всех наборах, указанных в команде.
По умолчанию, все наборы включены.
Когда Вы отключаете набор, его правила ведут себя так, как будто они не
существуют в конфигурации системы сетевой защиты только с одним
исключением:
динамические правила, созданные из правила до блокировки, будут
активными до устаревания. Чтобы удалить динамические правила, Вы явно
должны удалить родительское правило, которое их сгенерировало; элемент
набора правил может быть изменен командой:
ipfw set move {rule rule-number | old-set} to new-set
Также, Вы можете глобально поменять два набора правил командой:
ipfw set swap first-set second-set
См. Раздел ПРИМЕРОВ по некоторым возможным использованиям наборов
правил.
СИСТЕМА СЕТЕВОЙ ЗАЩИТЫ СОСТОЯНИЯ
Операция состояния - путь для системы сетевой защиты, динамически
создающей правила для определенных потоков при обнаружении пакетов
соответствующих данному образцу. Поддержка операций состояния доступна
через варианты правил check-state, keep-state и limit.
Динамические правила создаются, когда пакет соответствует правилу
keep-state или limit, вызывая создание динамического правила, которое
будет соответствовать всем пакетам только с данным протоколом между
парой адресов src-ip/src-port dst-ip/dst-port (src и dst используются
здесь только для того, чтобы обозначить начальные адреса соответствия,
но впоследствии они полностью эквивалентны). Динамические правила будут
проверены при первом возникновении check-state, keep-state или limit, и
их выполняемое действие будет таким же, как и в родительском правиле.
Обратите внимание, что в динамических правилах никакие другие
дополнительные атрибуты кроме протокола и адреса IP и порта не
проверяются.
Типичное использование динамических правил должно сохранить конфигурацию
закрытой системы сетевой защиты, но позволить первому TCP SYN пакету из
внутренней сети установить динамическое правило для потока так, чтобы
пакеты, принадлежащие этому сеансу, прошли через систему сетевой защиты:
ipfw add check-state
ipfw add allow tcp from my-subnet to any setup
ipfw add deny tcp from any to any
Подобный подход может использоваться для UDP, где UDP пакет, исходящий
из внутренней сети, установит динамическое правило, позволяющее
прохождение ответа через систему сетевой защиты:
ipfw add check-state
ipfw add allow udp from my-subnet to any
ipfw add deny udp from any to any
Динамические правила устаревают после некоторого времени, которое
зависит от состояния потока и установки некоторых переменных sysctl. Для
большего количества подробностей см. раздел ПЕРЕМЕННЫЕ SYSCTL. Для
сеансов TCP динамические правила могут быть сконфигурированы так, чтобы
для обновления состояния правила до устаревания периодически посылались
пакеты keepalive.
См. раздел ПРИМЕРЫ для большего количества примеров о том, как
использовать динамические правила.
КОНФИГУРАЦИЯ ФОРМИРОВАТЕЛЯ ТРАФИКА
ipfw это также интерфейс пользователя для формирователя трафика
dummynet(4). Формирователь работает, деля пакеты на потоки согласно
указанной пользователем маске по различным полям заголовка IP. Пакеты,
принадлежащие тому же самому потоку, передаются двум различным объектам,
называемым каналом или очередью.
Канал эмулирует связь с данной полосой пропускания, задержкой
распространения, размером очереди и нормой потери пакетов. Пакеты
проходят через канал согласно его параметрам.
Очередь - абстракция, осуществляющая политику WF2Q+. Очередь ассоциирует
с каждым потоком вес и ссылку канала. Все потоки, связанные с одним и
тем же каналом чередуются по норме, установленной каналом, согласно
политике WF2Q+.
Формат конфигурации канала ipfw следующий:
pipe number config pipe-configuration
Формат конфигурации очереди ipfw следующий:
queue number config queue-configuration
Следующие параметры могут быть установлены для канала:
bw bandwidth | device Полоса пропускания, взвешенная в [K|M]
{bit/s|Byte/s}.
Значение 0 (значение по умолчанию) означает неограниченную полосу
пропускания. Единицы измерения должны следовать сразу за номером, как в
ipfw pipe 1 config bw 300Kbit/s
Если имя устройства определено вместо числового значения, то передачи
синхронизируется с указанным устройством. На текущий момент только
устройство tun(4) поддерживает эти функциональные возможности для
использование вместе с ppp(8).
delay ms-delay Задержка распространения, выраженная в миллисекундах.
Значение округляется к следующему множителю такта системных часов (как
правило 10ms, но это - хорошая практика для работы с ядром при "options
HZ=1000" для того, чтобы уменьшить степень детализации до 1ms или
меньше). Значение по умолчанию - 0, никакой задержки.
Следующие параметры могут быть определены для очереди:
pipe pipe_nr Подключает очередь к указанному каналу. Множество очередей
(обычно с различными весами) могут быть связаны с одним и тем же
каналом, который определяет составную норму для набора очередей.
weight weight Определяет вес, который используется для потоков,
соответствующих этой очереди. Вес должен быть в диапазоне 1.. 100,
значение по умолчанию 1.
Наконец, следующие параметры могут быть сконфигурированы и для каналов и
для очередей:
plr packet-loss-rate Норма потери пакетов. Параметр packet-loss-rate
число с плавающей точкой между 0 и 1, с значением 0 никаких потерь,
значение 1 - 100% потеря пакетов. Внутреннее представление нормы потерь
- 31 битное.
queue {slots | sizeKbytes} Размер очереди в слотах или КИЛОБАЙТАХ.
Значение по умолчанию - 50 слотов, которое является типичным размером
очереди для устройств Ethernet. Обратите внимание, что для медленных
соединений, Вы должны установить меньший размер очереди или ваш трафик
будет иметь существенную задержку в очереди. Например, 50 пакетов сети
стандарта Ethernet максимального размера (1500 байт) означают 600Kbit
или 20 секундную очередь на канале 30Kbit/s. Может получиться даже
худший эффект, если Вы получаете пакеты от интерфейса с большим
максимальным блоком передачи данных, например петлевой интерфейс с его
пакетами по 16 КБ.
red | gred w_q/min_th/max_th/max_p Использовать алгоритм управления
очередью RED (Случайное Раннее Обнаружение). w_q и max_p - числа с
плавающей запятой между 0 и 1 (исключая 0), в то время как min_th и
max_th - целые числа, определяющие пороги для управления очередью
(пороги вычисляются в байтах, если очередь была определена в байтах, в
иначе слотах). dummynet(4) также поддерживает нежный вариант RED (gred).
Три переменные sysctl(8) могут использоваться для управления поведением
RED:
net.inet.ip.dummynet.red_lookup_depth
опр. точность в вычислении средней очереди, когда соединение простаивает
(значение по умолчанию 256, должно быть больше нуля)
net.inet.ip.dummynet.red_avg_pkt_size
опр. ожидаемый средний размер пакета (знач. по умолчанию 512, должно
быть больше нуля)
net.inet.ip.dummynet.red_max_pkt_size
определяет ожидаемый максимальный размер пакета, используется только
тогда, когда пороги очереди определены в байтах (значение по умолчанию
1500, должно быть больше нуля).
КОНТРОЛЬНЫЙ СПИСОК
Вот некоторые важные пункты для рассмотрения при проектировании ваших
правил:
Помните, что Вы фильтруете оба вида пакетов, входящие и исходящие.
Большинству соединений нужны пакеты, проходящие в обоих направлениях.
Не забывайте проверять очень тщательно. Лучше всего быть рядом с
консолью при выполнении этих операций. Если Вы не можете быть около
консоли, используйте сценарий автовосстановления типа
/usr/share/examples/ipfw/change_rules.sh.
Не забывайте петлевой интерфейс.
ПОЛЕЗНЫЕ РЕКОМЕНДАЦИИ
Есть обстоятельства, при которых фрагментированные дейтаграммы
безоговорочно отбрасываются. Пакеты TCP отбрасываются, если они не
содержат не менее 20 байт заголовка TCP, UDP пакеты отбрасываются, если
они не содержат полный 8 байтовый UDP заголовок и ICMP пакеты
отбрасываются, если они не содержат 4 байта ICMP заголовка, достаточно
определить тип ICMP, код, и контрольную сумму. Эти пакеты регистрируются
просто как "pullup failed'' ", т.к. мало данных в пакете для полноценной
регистрации.
Другой тип пакетов, которые безоговорочно отбрасываются - пакет TCP со
смещением фрагмента один. Это допустимый пакет, но это имеет только одно
использование, попытаться обойти систему сетевой защиты. Если
регистрация включена, об этих пакетах сообщается как об отброшенных в
соответствии с правилом -1.
Если Вы вошли в систему из сети, необходимо загружать kld(4)-версия ipfw
не столь прямо, как Вы бы думали. Я рекомендую следующую командную
строку:
kldload /modules/ipfw.ko &&
ipfw add 32000 allow ip from any to any
По тем же причинам, делать
ipfw flush
в подобной среде - также плохая идея.
Список фильтра ipfw не может измениться, если системный уровень защиты
установлен в 3 или выше (см. init (8) для информации относительно
уровней системной защиты).
ПЕРЕАДРЕСАЦИЯ ПАКЕТОВ
Гнездо divert (4), связанное с указанным портом, получит все пакеты,
переадресованные на этот порт. Если нет гнезда, связанного с портом
адресата, или если ядро не было откомпилировано с поддержкой гнезда
переадресации, пакеты отбрасываются.
ПЕРЕМЕННЫЕ SYSCTL
Набор переменных sysctl (8) управляет поведением системы сетевой защиты
и связанных модулей (dummynet, bridge). Они показаны ниже вместе с их
значением по умолчанию (но всегда проверяйте командой sysctl (8), какое
фактически значение используется):
net.inet.ip.dummynet.expire: 1
Лениво удалить динамические каналы/очереди при отсутствии ждущего
обработки трафика. Вы можете отключить этот параметр, установив
переменную в 0, в этом случае каналы/очереди удалены будут только тогда,
когда будет достигнут порог.
net.inet.ip.dummynet.hash_size: 64
Заданный по умолчанию размер хеш-таблицы, используемой для динамических
каналов/очередей. Это значение используется, когда не определена опция
buckets при конфигурировании канала/очереди.
net.inet.ip.dummynet.max_chain_len: 16
Целевое значение для максимального количества каналов/очередей в
области хеш-памяти. Программа max_chain_len*hash_size используется для
определения порога, по которому пустые каналы/очереди устареют даже
когда net.inet.ip.dummynet.expire=0.
net.inet.ip.dummynet.red_lookup_depth: 256
net.inet.ip.dummynet.red_avg_pkt_size: 512
net.inet.ip.dummynet.red_max_pkt_size: 1500
Параметры, используемые в вычислениях вероятности отбрасывания для
алгоритма RED.
net.inet.ip.fw.autoinc_step: 100
Разность между номерами правил при их автогенерации. Значение должно
быть в диапазоне 1.. 1000.
net.inet.ip.fw.dyn_buckets
net.inet.ip.fw.dyn_keepalive: 1
Включает генерацию пакетов keepalive для keep-state правил на сеансы
TCP. keepalive генерируются в обе стороны подключения каждые 5 секунд в
течение последних 20 секунд времени жизни правила.
net.inet.ip.fw.dyn_max: 8192
Максимальное количество динамических правил. Когда Вы устанавливаете
этот предел, ни одно динамическое правило будет создано, пока не истечет
время жизни старого.
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: 5
net.inet.ip.fw.dyn_short_lifetime: 30
Эти переменные управляют временем жизни динамических правил, в
секундах. На начальный SYN-обмен сохраняется короткое время жизни, после
фиксации обоих SYN, время жизни увеличивается, затем уменьшается снова в
течение заключительного FIN обмена или когда получен RST. Оба, и
dyn_fin_lifetime и dyn_rst_lifetime должны быть обязательно меньше 5
секунд, периода повторения keepalives. Система сетевой защиты
предписывает это.
net.inet.ip.fw.enable: 1
Включает систему сетевой защиты. Установка этой переменной в 0
позволила бы Вам работать на вашей машине без системы сетевой защиты,
даже если она скомпилирована.
net.inet.ip.fw.one_pass: 1
Если установлена, пакет, выходящий из канала dummynet (4) повторно не
проходит систему сетевой защиты. Иначе, после действия канала, пакет
повторно вводится в систему сетевой защиты в следующем правиле.
Обратите внимание: пакеты моста и пакеты 2 уровня, выходящие из канала
никогда повторно не проходят систему сетевой защиты независимо от
значения этой переменной.
net.inet.ip.fw.verbose: 1
Включает более подробные сообщения.
net.inet.ip.fw.verbose_limit: 0
Ограничивает количество сообщений, сгенерированных "многословной"
системой сетевой защиты.
net.link.ether.ipfw: 0
Контроль передачи пакетов 2 уровня в ipfw. Значение по умолчанию - нет.
net.link.ether.bridge_ipfw: 0
Контроль передачи пакетов моста в ipfw. Значение по умолчанию - нет.
РАСШИРЕНИЯ IPFW2
Эти раздел описывает особенности, которые были введены в ipfw2 и не
присутствуют в ipfw1. Мы перечислим их в порядке потенциального
воздействия, которое они могут иметь при написании ваших наборов
правил. Вы можете рассмотреть использование этих особенностей, для
записи вашего набора записей более эффективно.
Обработка не-IPv4 пакетов
ipfw1 молча примет все не-IPv4 пакеты (какие ipfw1 будет только видеть
когда net.link.ether.bridge_ipfw=1). ipfw2 фильтрует все пакеты (включая
не-IPv4) согласно набору правил. Достигнуть того же самого поведения,
как и в ipfw1 Вы можете, используя следующее самое первое правило в
вашем наборе правил:
ipfw add 1 allow layer2 not mac-type ip
layer2 опции могут казаться избыточными, но это необходимо - пакеты
прошедшие в систему сетевой защиты из layer3, не будут иметь MAC
заголовка, так что образец mac-type ip никогда на них не даст
соответствия и оператор not даст положительное соответствие на всех
пакетах.
Наборы адресов
Незначительное различие между ipfw1 и ipfw2 в том, что прежний допускает
определение адресов как ipno:mask, где маска может быть произвольной
битовой маской вместо набора последовательных бит. ipfw2 больше не
поддерживает этот синтаксис, хотя было бы логично повторно это ввести,
поскольку это поддерживается со стороны ядра.
Спецификации порта
ipfw1 позволяет только один диапазон портов при определении портов TCP и
UDP, и ограничен 10 входами вместо 15, допускаемых в ipfw2. Также в
ipfw1 Вы можете определить порты только тогда, когда правило описывает
tcp или udp пакеты. В ipfw2 Вы можете поместить спецификации порта в
правилах, соответствующих всем пакетам, и соответствие будет
положительным только на пакетах протоколов, которые включают
идентификаторы порта.
Наконец, ipfw1 позволяет первому входу порта быть определенным как
port:mask, где маска может быть произвольной 16-разрядной маской. Этот
синтаксис имеет сомнительную полноценность, и он не поддерживается
больше в ipfw2.
Или-блоки
ipfw1 не поддерживает Или-блоки.
keepalives
ipfw1 не генерирует keepalives для stateful сеансов. Как следствие, это
могло бы отбрасывать неактивные сеансы, потому что время жизни
динамических правил ограничено.
Наборы правил
ipfw1 не поддерживает наборы правил.
Фильтрация по MAC заголовкам и использование систем защиты сетей на
уровне 2.
ipfw1 не осуществляет фильтрацию по полям MAC заголовков на пакетах
вызванных, ни от ether_demux() ни от ether_output_frame(). Переменная
sysctl net.link.ether.ipfw там не действует.
Дополнительно, следующие варианты не поддерживаются в правилах ipfw1
(RELENG_4):
ipid, iplen, ipprecedence, iptos, ipttl, ipversion, Cm tcpack, tcpseq,
tcpwin.
Варианты Dummynet
Следующая опция для каналов/очередей dummynet не поддерживается:
noerror.
ПРИМЕРЫ
Есть слишком много всевозможных использований ipfw, так что этот раздел
даст только маленький набор примеров.
БАЗОВАЯ ФИЛЬТРАЦИЯ ПАКЕТОВ
Эта команда добавляет вход, который запрещает все tcp пакеты от
cracker.evil.org на порт telnet wolf.tambov.su:
ipfw add deny tcp from cracker.evil.org to wolf.tambov.su telnet
Это правило запрещает пакеты с сети класса С на мой компьютер:
ipfw add deny ip from 123.45.67.0/24 to my.host.org
Первый и эффективный способ ограничить доступ (не использующий
динамические правила) - использование следующих правил:
ipfw add allow tcp from any to any established
ipfw add allow tcp from net1 portlist1 to net2 portlist2 setup
ipfw add allow tcp from net3 portlist3 to net3 portlist3 setup
...
ipfw add deny tcp from any to any
Первое правило даст соответствие для нормальных пакетов TCP, но оно не
будет соответствовать начальным SYN пакетам, которые будут
соответствовать правилу setup только для выбранных пар источник/адресат.
Все другие SYN пакеты будут отброшены заключительным правилом deny.
Если Вы управляете одной или более подсетями, Вы можете использовать
синтаксис ipfw2 для того, чтобы при записи наборов правил, иметь
возможность определить чрезвычайно компактные наборы адресов и
или-блоков, избирательно допускающих к услугам и блокам клиентов, как
указано ниже :
goodguys="{ 10.1.2.0/24{20,35,66,18} or 10.2.3.0/28{6,3,11} }"
badguys="10.1.2.0/24{8,38,60}"
ipfw add allow ip from ${goodguys} to any
ipfw add deny ip from ${badguys} to any
... normal policies ...
Синтаксис ipfw1, в вышеупомянутом примере, требовал бы отдельного
правила для каждого IP.
ДИНАМИЧЕСКИЕ ПРАВИЛА
Чтобы защитить сайт от нападений, использующих поддельные TCP пакеты,
более безопасно использовать динамические правила:
ipfw add check-state
ipfw add deny tcp from any to any established
ipfw add allow tcp from my-net to any setup keep-state
Это позволит системе сетевой защиты устанавливать динамические правила
только для тех подключений, которые начинаются с правильного SYN пакета,
исходящего из внутренней сети. Динамические правила проверяются при
столкновении с первым правилом check-state или keep-state. Правило
check-state обычно должно помещаться в начале набора правил для
минимизации работы по просмотру набора правил.
Чтобы ограничить количество подключений открываемых пользователем, Вы
можете использовать следующий тип правил:
ipfw add allow tcp from my-net/24 to any setup limit src-addr 10
ipfw add allow tcp from any to me setup limit src-addr 4
Первое (в предположении, что это выполняется на шлюзе), позволит каждому
компьютеру в /24 сети открывать не более 10 TCP подключений. Последнее
может быть помещено на сервер, для гарантии того, что отдельный клиент
не использует больше чем 4 одновременных подключений.
ОСТЕРЕГАЙТЕСЬ: динамические правила могут привести к нападениям типа
отказа в обслуживании при помощи SYN-мусора, который открывает огромное
количество динамических правил. Последствия таких нападений могут быть
частично ограничены, действуя на набор переменных sysctl (8), которые
управляют действиями системы сетевой защиты.
Вот хорошее использование команды list для просмотра поясняющего отчета
и информации с отметками времени:
ipfw -at list
или в короткой форме без информации об временных отметках:
ipfw -a list
что является эквивалентным:
ipfw show
Следующее правило перенаправляет все входящие пакеты от 192.168.2.0/24
на порт переадресации 5000:
ipfw divert 5000 ip from 192.168.2.0/24 to any in
ФОРМИРОВАНИЕ ТРАФИКА
Следующие правила показывают некоторые варианты применения ipfw и
dummynet(4) для моделирования и т.п..
Это правило случайно отбрасывает входящие пакеты с вероятностью 5 %:
ipfw add prob 0.05 deny ip from any to any in
Подобный эффект может быть достигнут, используя каналы dummynet:
ipfw add pipe 10 ip from any to any
ipfw pipe 10 config plr 0.05
Мы можем использовать каналы для искусственного ограничиения полосы
пропускания, например на машине, действующей как маршрутизатор, если мы
хотим ограничить трафик от локальных клиентов на 192.168.2.0/24, тогда
мы делаем:
ipfw add pipe 1 ip from 192.168.2.0/24 to any out
ipfw pipe 1 config bw 300Kbit/s queue 50KBytes
обратите внимание, что мы используем модификатор out для того, чтобы
правило не использовалось дважды. Помните, что правила ipfw фактически
проверяются и на входящих и на исходящих пакетах.
Если требуется смоделировать двунаправленную связь с ограничениями
полосы пропускания, правильный путь следующий:
ipfw add pipe 1 ip from any to any out
ipfw add pipe 2 ip from any to any in
ipfw pipe 1 config bw 64Kbit/s queue 10Kbytes
ipfw pipe 2 config bw 64Kbit/s queue 10Kbytes
Вышеупомянутое может быть очень полезно, например если Вы хотите
поверить, как ваша Web-страница будет загружаться через медленное
сединение. Если Вы не хотите моделировать полудуплексную среду (например
AppleTalk, Ethernet, IRDA), Вы не должны использовать один канал для
обоих направлений,. Необязательно оба канала должны иметь одинаковую
конфигурацию, так что мы можем моделировать асимметричные соединения.
Если мы хотим проверить работу сети с алгоритмом управления очереди RED:
ipfw add pipe 1 ip from any to any
ipfw pipe 1 config bw 500Kbit/s queue 100 red 0.002/30/80/0.1
Другое типичное применение формирователя трафика в вводе некоторой
задержки связи. Это может затронуть приложения удаленного управления, в
которых для соединений время прохождения туда и обратно часто бывает
более критичным, чем полоса пропускания:
ipfw add pipe 1 ip from any to any out
ipfw add pipe 2 ip from any to any in
ipfw pipe 1 config delay 250ms bw 1Mbit/s
ipfw pipe 2 config delay 250ms bw 1Mbit/s
Попоточная организация очередей может быть полезна для разнообразных
целей. В простейшем случае подсчет трафика:
ipfw add pipe 1 tcp from any to any
ipfw add pipe 1 udp from any to any
ipfw add pipe 1 ip from any to any
ipfw pipe 1 config mask all
Вышеупомянутый набор правил создаст очереди (и соберетстатистику) для
всего трафика. Поскольку каналы не имеют никаких ограничений,
единственный эффект - сбор статистики. Обратите внимание, что необходимо
3 правила, не только последнее, потому что, когда ipfw проверяет
соответствие пакетов IP, он не будет рассматривать порты и мы не увидим
статистику по отдельным портам.
Более сложный пример ограничивает внешний трафик в сети с помашинными
ограничениями, а не с ограничениями для сети:
ipfw add NN set 18 ... # повторить если необходимо
ipfw enable set 18
Чтобы удалять набор правил, просто команда:
ipfw delete set 18
Проверка набора правил, если кое-что идет не так, как надо и отключить
его, восстановив управление:
ipfw disable set 18
ipfw add NN set 18 ... # повторить если необходимо
ipfw enable set 18 ; echo done; sleep 30 && ipfw disable set 18
Здесь, если все нормально, Вы нажимаете комбинацию клавиш CRTL-C прежде,
чем закончится "sleep", и ваш набор правил останется активным. Иначе,
например если Вы не можете обратиться к вашей системе, набор правил
будет заблокирован после того, как закончится "sleep", таким образом,
восстановив предыдущую ситуацию.
S. Floyd and V. Jacobson, Random Early Detection gateways for Congestion
Avoidance, August 1993.
B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, D. Estrin, S.
Floyd, V. Jacobson, G. Minshall, C. Partridge, L. Peterson, K.
Ramakrishnan, S. Shenker, J.
W?????????????????????????????????????????????????????????????
ОШИБКИ
Синтаксис усложнялся за эти годы, и иногда это могло вызвать путаницу. К
сожалению, совместимость вниз делает невозможность очистку ошибок,
сделанных при определении синтаксиса.
!!! ПРЕДУПРЕЖДЕНИЕ!!!
Неправильная конфигурация системы сетевой защиты может перевести ваш
компьютер в нестабильное состояние, возможно завершая поддержку сети и,
тем самым, вызвав необходимость вмешательства с системной консоли для
восстановления управления.
Входящие фрагменты пакета, переадресованные divert или tee, повторно
собираются перед доставкой в гнездо. Действие, применяемое к собранному
пакету, определяется тем из правил, которое соответствует первому
фрагменту пакета.
Пакеты, которые соответствуют правилу tee, не должны быть немедленно
приняты, но должны пройти проверку по списку правил. Это может быть
исправлено в более поздней версии.
Пакеты, перенаправленные к пользовательскому процессу, а затем повторно
вставленный пользовательским процессом (типа natd (8)) потеряют
различные атрибуты пакета, включая их исходный интерфейс. Если пакет
повторно вставлен этим способом, более поздние правила могут быть
неправильно применены, поэтому порядок divert правил в очень важный.
АВТОРЫ
Ugen J. S. Antsilevich,
Poul-Henning Kamp,
Alex Nash,
Archie Cobbs,
Luigi Rizzo.
API базировался на коде, написанном Дэниелом Буетом (Daniel Boulet) для
BSDI.
Работа формирователя трафика dummynet (4) поддерживается Akamba Corp.
ХРОНОЛОГИЯ
Утилита ipfw сначала появилась в FreeBSD 2.0. dummynet (4) был введен в
FreeBSD 2.2.8. Динамические расширения были введены в FreeBSD 4.0. ipfw2
был представлен Летом 2002 г.
Vova
