OpenNET: статья - Черновой перевод "man ipfw" (freebsd ipfw)

Ключевые слова: freebsd, ipfw, (найти похожие документы)
From: GreN Newsgroups: email Date: Mon, 21 Jul 2003 14:31:37 +0000 (UTC) Subject: Черновой перевод "man ipfw" Неофициальный перевод документации по ipfw FreeBSD 4.x ИМЯ ipfw - система сетевой защиты IP и управляющая программа формирователя трафика РЕЗЮМЕ ipfw [-cq] add rule ipfw [-acdeftNS] {list | show} [number ...] ipfw [-f | -q] flush ipfw [-q] {delete | zero | resetlog} [set] [number ...] ipfw set [disable number ...] [enable number ...] ipfw set move [rule] number to number ipfw set swap number number ipfw set show ipfw {pipe | queue} number config config-options ipfw [-s [field]] {pipe | queue} {delete | list | show} [number ...] ipfw [-q] [-p preproc [-D macro[=value]] [-U macro]] pathname ОПИСАНИЕ Утилита 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, управляющими его вызовами. ^ to upper layers V | | +----------->-----------+ ^ V [ip_input] [ip_output] net.inet.ip.fw.enable=1 | | ^ V [ether_demux] [ether_output_frame] net.link.ether.ipfw=1 | | +-->--[bdg_forward]-->--+ net.link.ether.bridge_ipfw=1 ^ V | to devices | Как видно из приведенной схемы, число прохождений одного и того же пакета через систему сетевой защиты может изменяться от 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). ФОРМАТ ПРАВИЛА Формат правил ipfw - следующий: [rule_number] [set set_number] [prob match_probability] action [log [logamount number]] body где тело правила определяет, какая информация используется для фильтрации пакетов, среди следующего: Поля заголовка Уровня 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 dst-ip, dst-port, layer2, mac, mac-type, src-ip, src-port. Дополнительно, следующие варианты не поддерживаются в правилах 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 pipe 1 ip from 192.168.2.0/24 to any out ipfw add pipe 2 ip from any to 192.168.2.0/24 in ipfw pipe 1 config mask src-ip 0x000000ff bw 200Kbit/s queue 20Kbytes ipfw pipe 2 config mask dst-ip 0x000000ff bw 200Kbit/s queue 20Kbytes НАБОРЫ ПРАВИЛ Чтобы добавить набор правил, например набор 18: ipfw disable set 18 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", таким образом, восстановив предыдущую ситуацию. СМ. ТАКЖЕ cpp(1), m4(1), bridge(4), divert(4), dummynet(4), ip(4), ipfirewall(4), protocols(5), services(5), init(8), kldload(8), reboot(8), sysctl(8), syslogd(8) 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 г.

2.4, GreN (?), 10:07, 29/07/2003 [^] [^^] [^^^] [ответить]	+/–
А почему бы уважаемому poige не написать лучше???? Можно даже с нуля!!!! Я понимаю что не крут в переводе однако есть люди которые вообще не шарят ни в переводе ни в сабже, но хотят знать! Вот именно для них я перевел (кривовато как для poige). А в общем спасибо тебе я обязательно подкорректирую статью, ведь начинающему это будет хоть както помогать.

2.12, dusty (??), 07:16, 21/08/2007 [^] [^^] [^^^] [ответить]	+/–
>Юрген Анцилевич (Ugen J. S. Antsilevich), >Пол-Хёнинг Камп (Poul-Henning Kamp), >Алекс Нэш (Alex Nash), >Арчи Коббс (Archie Cobbs), >Луиджи Риццо (Luigi Rizzo). >перевод В. Кравчук, OpenXS Initiative Вот, это действительно то что нужно!

3.13, Гремлин (?), 15:14, 13/09/2007 [^] [^^] [^^^] [ответить]	+/–
Это перевод мана хз какой давности, смотри, даже опции не все совпадают в этом переводе и в сабж.

4.15, dusty (??), 14:50, 05/03/2008 [^] [^^] [^^^] [ответить]	+/–
Здесь перевод не такой корявый, я прочел этот вариант перевода по диагонали, а потом в оригинале на английском языке "man ipfw" был прочитан и осознан легко и непринужденно.