Iptables: различия между версиями

'''iptables'''  — утилита [[w:Интерфейс командной строки |командной строки]], является стандартным интерфейсом управления работой [[w:Межсетевой экран |межсетевого экрана]] (брандмауэра) '''{{w |netfilter}}''' для [[w:Ядро Linux |ядер Linux]] версий 2.4, 2.6, 3.x, 4.x . Для использования утилиты iptables требуются привилегии [[w:Root |суперпользователя]] (root).

iptables сохраняет идеологию, ведущую начало от ipfwadm: функционирование фаервола определяется набором правил, каждое из которых состоит из критерия и действия, применяемого к пакетам, подпадающим под этот критерий. В ipchains появилась концепция ''цепочек''  — независимых списков правил. Были введены отдельные цепочки для фильтрации входящих (INPUT), исходящих (OUTPUT) и транзитных (FORWARD) пакетов. В продолжении этой идеи, в iptables появились ''таблицы''  — независимые группы цепочек. Каждая таблица решала свою задачу  — цепочки таблицы filter отвечали за фильтрацию, цепочки таблицы nat  — за преобразование сетевых адресов ({{w |NAT}}), к задачам таблицы mangle относились прочие модификации заголовков пакетов (например, изменение [[w:Time to live |TTL]] или [[w:Тип обслуживания |TOS]]). Кроме того, была слегка изменена логика работы цепочек: в ipchains все входящие пакеты, включая транзитные, проходили цепочку INPUT. В iptables через INPUT проходят только пакеты, адресованные самому хосту.

Такое разделение функциональности позволило iptables при обработке отдельных пакетов использовать информацию о соединениях в целом (ранее это было возможно только для NAT). В этом iptables значительно превосходит ipchains, так iptables может отслеживать состояние соединения и перенаправлять, изменять или отфильтровывать пакеты, основываясь не только на данных из их заголовков (источник, получатель) или содержимом пакетов, но и на основании данных о соединении. Такая возможность фаервола называется stateful-фильтрацией, в отличие от реализованной в ipchains примитивной stateless-фильтрации (подробнее о видах фильтрации см. статью о [[w:Межсетевой экран |фаерволах]]). Можно сказать, что iptables анализирует не только передаваемые данные, но и контекст их передачи, в отличие от ipchains, и поэтому может принимать более обоснованные решения о судьбе каждого конкретного пакета. Более подробно о stateful-фильтрации в netfilter/iptables см. [[w:Netfilter#Механизм определения состояний]].

В будущем, разработчики netfilter планируют заменить iptables на [[nftables]]  — инструмент нового поколения, пока находящийся в ранней стадии разработки<ref>[http://www.opennet.ru/opennews/art.shtml?num=20843 Разработчики Netfilter представили замену iptables]</ref>.

* '''Правило'''  — состоит из ''критерия'', ''действия'' и ''счетчика''. Если пакет соответствует критерию, к нему применяется действие, и он учитывается счетчиком. Критерия может и не быть  — тогда неявно предполагается критерий «все пакеты». Указывать действие тоже не обязательно  — в отсутствие действия правило будет работать только как счетчик.

** '''Критерий'''  — логическое выражение, анализирующее свойства пакета и/или соединения и определяющее, подпадает ли данный конкретный пакет под действие текущего правила.

** '''Действие'''  — описание действия, которое нужно проделать с пакетом и/или соединением в том случае, если они подпадают под критерий этого правила. О действиях более подробно будет рассказано ниже.

** '''Счетчик'''  — компонент правила, обеспечивающий учет количества пакетов, которые попали под критерий данного правила. Также счетчик учитывает суммарный объем таких пакетов в байтах.

* '''Цепочка'''  — упорядоченная последовательность правил. Цепочки можно разделить на ''пользовательские'' и ''базовые''.

** '''Базовая цепочка'''  — цепочка, создаваемая по умолчанию при инициализации таблицы. Каждый пакет, в зависимости от того, предназначен ли он самому хосту, сгенерирован им или является транзитным, должен пройти положенный ему набор базовых цепочек различных таблиц. Схема следования пакетов приведена на рисунке. Кроме того, базовая цепочка отличается от пользовательской наличием «действия по умолчанию» (default policy). Это действие применяется к тем пакетам, которые не были обработаны другими правилами этой цепочки и вызванных из нее цепочек (см. переходы). Имена базовых цепочек всегда записываются в верхнем регистре (PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING).

** '''Пользовательская цепочка'''  — цепочка, созданная пользователем. Может использоваться только в пределах своей таблицы. Рекомендуется не использовать для таких цепочек имена в верхнем регистре, чтобы избежать путаницы с базовыми цепочками и встроенными действиями.

* '''Таблица'''  — совокупность ''базовых'' и ''пользовательских'' цепочек, объединенных общим функциональным назначением. Имена таблиц (как и модулей критериев) записываются в нижнем регистре, так как в принципе не могут конфликтовать с именами пользовательских цепочек. При вызове команды iptables таблица указывается в формате <tt>-t имя_таблицы</tt>. При отсутствии явного указания, используется таблица filter. Более подробно таблицы будут рассмотрены ниже.

Теперь цепочка INPUT таблицы filter содержит единственное правило, которое пропускает все пакеты, относящиеся к уже установленным соединениям. Ко всем остальным входящим пакетам будет применено действие по умолчанию  — DROP. Цепочка же OUTPUT вообще не содержит правил, поэтому ко всем исходящим пакетам будет применяться действие по умолчанию ACCEPT. Таким образом хост, настроенный согласно этому примеру и подключенный к {{w |Интернет}}у, будет недоступен извне (все попытки установить соединение снаружи блокируются), однако с самого хоста доступ к Интернету будет свободный (исходящие пакеты разрешены, а ответы на них уже относятся к установленным соединениям).

* '''ip_tables'''  — фаервол для протокола [[w:IPv4|IPv4]]. Обеспечивает фильтрацию пакетов, модификацию их заголовков и [[w:NAT|трансляцию сетевых адресов]].

* '''ip6_tables'''  — фаервол для протокола [[w:IPv6|IPv6]]. Обеспечивает фильтрацию пакетов и модификацию их заголовков.

* '''arp_tables'''  — фаервол для протоколов [[w:ARP|ARP]] и [[w:RARP|RARP]]. Обеспечивает фильтрацию и модификацию пакетов.

* '''x_tables'''  — бэкенд для ip_tables, ip6_tables и arp_tables. В этом модуле определены основные операции для работы с фаерволами «таблично-цепочечной» структуры и их компонентами.

* '''ebtables'''  — [[w:Ethernet|Ethernet]]-фаервол (префикс eb от Ethernet Bridge). В отличие от трех перечисленных выше фаерволов, работающих с протоколами [[w:Сетевой уровень|сетевого]] и более высоких уровней, ebtables работает на канальном уровне, выполняя фильтрацию и модификацию ethernet-кадров, проходящих через [[w:Сетевой мост|сетевые мосты]], если таковые имеются на хосте.

Принципы работы с ip_tables и ip6_tables практически идентичны, с тем небольшим отличием, что в ip6_tables отсутствует таблица nat и соответствующие действия (NAT уже присутствует в ip6tables). В то же время, принципы построения правил в arp_tables и ebtables несколько иные. В частности, arp_tables и ebtables имеют четыре базовых действия  — ACCEPT (пропустить), DROP (заблокировать), CONTINUE (продолжить обработку в данной цепочке) и RETURN (прекратить обработку в данной цепочке, вернуть в цепочку уровнем выше). Эти действия могут использоваться отдельно, либо применяться к пакетам после выполнения какого-либо преобразующего действия (например, маркировки). Таким образом, после применения преобразования пакет может быть, скажем, немедленно пропущен фаерволом (ACCEPT), либо будет вынужден проследовать через последующие правила (CONTINUE). Этим arptables и ebtables отличаются от ip_tables и ip6_tables  — в последних существует четкое разделение действий на терминальные и нетерминальные, которое нельзя изменить при составлении набора правил, а чтобы, например, пропустить пакет после некоторого нетерминального преобразования, необходимо добавлять дополнительное правило («<tt>iptables ... -j MARK ...; iptables ... -j ACCEPT</tt>» вместо «<tt>ebtables ... -j mark ... --mark-target ACCEPT</tt>»). Также, система conntrack не&nbsp; производит отслеживание соединений для ARP/RARP и Ethernet, поэтому возможности stateful-фильтрации в arp_tables и ebtables отсутствуют (нет критерия conntrack и таблицы raw).

* Классификация пакетов на основе различных критериев. В качестве критерия могут выступать, например, [[w:IP-адрес|IP-адресадреса]]а источника и/или назначения, состояние соединения (новое/уже установленное), [[w:Порт (TCP/IP)|порты]] источника и/или назначения (для протоколов [[w:Транспортный уровень|транспортного уровня]], имеющих порты), вспомогательные значения в заголовках пакетов (скажем, длина пакета, [[w:Type_of_ServiceType of Service|TOS]], [[w:Time_to_liveTime to live|TTL]]) и  т.  п. Результаты этой классификации используются при решении других задач из данного списка.

** Трансляцию сетевых адресов ([[w:NAT|NAT]]), включая [[w:маскарадинг|маскарадинг]] (SNAT или MASQUERADE), [[w:Трансляция_портТрансляция порт-адрес|«проброс»]] адресов и портов (DNAT) и даже целых подсетей (NETMAP). Эта задача касается только модуля ip_tables. Модуль ip6_tables не&nbsp; производит трансляции адресов.

** Изменение различных вспомогательных величин в заголовках пакетов, например, [[w:Type_of_ServiceType of Service|TOS]], [[w:Time_to_liveTime to live|TTL]], [[:en:Maximum Segment Size|TCP MSS]].

* Внутренние задачи, связанные с обеспечением работы критериев и действий netfilter. Например, сопровождение списков [[w:IP-адрес|IP-адресадресов]]ов для критериев recent и hashlimit.

Также в комплект поставки вместе с iptables обычно входят вспомогательные утилиты, обеспечивающие сохранение (iptables-save) и последующее восстановление (iptables-restore) состояния фаервола, его инициализацию при запуске системы ({{w |init}}-скрипт) и  т.  п.

* '''libiptc'''  — содержит функции, осуществляющие вышеперечисленные операции по управлению цепочками и правилами. Именно с этими функциями и работают утилиты iptables (библиотека libip4tc) и ip6tables (библиотека libip6tc). Приложения, использующие эти библиотеки, могут обращаться к netfilter напрямую, минуя вызов утилит iptables и ip6tables. В качестве примера такого приложения можно назвать [[Perl]]-модуль [http://search.cpan.org/~hawk/IPTables-libiptc-0.18/lib/IPTables/libiptc.pm IPTables::libiptc], предоставляющий доступ к функциям этих библиотек из Perl-{{w |скрипт}}ов.

* '''libipq'''  — содержит функции, позволяющие пользовательским приложениям принимать [[IP-пакет]]ы на обработку. Отправка со стороны ядра выполняется через модуль ip_queue (ip6_queue для IPv6), что соответствует действию QUEUE. В настоящее время этот механизм [http://netfilter.org/projects/libnetfilter_queue/index.html объявлен устаревшим], и вместо него рекомендуется использовать действие NFQUEUE, работа которого реализуется через модуль ядра nfnetlink_queue и библиотеку libnetfilter_queue.

* Отслеживание состояний отдельных соединений с тем, чтобы классифицировать каждый пакет либо как относящийся к уже установленному соединению, либо как открывающий новое соединение. При этом понятие "«состояние соединения"» искусственно вводится для протоколов, в которых оно изначально отсутствует ({{w |UDP}}, {{w |ICMP}}). При работе же с протоколами, поддерживающими состояния (например, {{w |TCP}}), conntrack активно использует эту возможность, тесно взаимодействуя с базовой сетевой подсистемой ядра Linux.

* Отслеживание связанных соединений, например, {{w |ICMP}}-ответов на {{w |TCP}} и {{w |UDP}}-пакеты. Более сложный вариант  — протоколы, использующие несколько соединений в одной сессии, например, {{w |FTP}}. Для правильной обработки таких протоколов conntrack использует специальные модули (conntrack helpers), которые анализируют трафик и «выхватывают» информацию протокола о новых соединениях (например, порт, на который оно будет открыто), что позволяет обеспечить их корректную фильтрацию, маршрутизацию, шейпинг и пропускание через NAT.

* Трекеры протоколов [[w:Протоколы сетевого уровня |сетевого уровня]]: nf_conntrack_ipv4 и nf_conntrack_ipv6. Реализуют операции, специфичные для «своих» протоколов ({{w |IPv4}} и {{w |IPv6}} соответственно), а также механизмы отслеживания соответствующих протоколов управляющих сообщений ({{w |ICMP}} и {{w |ICMPv6}} соответственно).

* Трекеры протоколов [[w:Транспортный уровень |транспортного уровня]] (кроме {{w |TCP}} и {{w |UDP}}, реализованных в главном модуле): nf_conntrack_proto_sctp ({{w |SCTP}}), nf_conntrack_proto_dccp ({{w |DCCP}}), nf_conntrack_proto_gre ([[w:GRE (протокол) |GRE]]), nf_conntrack_proto_udplite ({{w |UDP Lite}}).

* Вспомогательные модули (helpers), обеспечивающие отслеживание протоколов [[w:Протоколы прикладного уровня |прикладного]] и [[w:Сеансовый уровень |сеансового]] уровней: nf_conntrack_ftp, nf_conntrack_irc, nf_conntrack_pptp, nf_conntrack_netbios_ns и  т.  п. Требуются далеко не&nbsp; для всех протоколов, а только для тех, отслеживание которых требует знания специфики протокола. Например, неоднократно упоминающийся в этой статье протокол {{w |FTP}} использует в одном сеансе два соединения (управляющее соединение и соединение передачи данных), и чтобы корректно отследить соединение передачи данных, необходимо анализировать трафик управляющего соединения и выделять в нем информацию, касающуюся открытия соединения данных.

* Модуль nf_nat. Реализует базовую функциональность [[w:NAT |трансляции сетевых адресов]] и [[w:Трансляция порт-адрес |портов]] с учетом информации о соединениях. Также этот модуль содержит механизмы трансляции для протоколов {{w |IPv4}}, {{w |TCP}}, {{w |UDP}} и {{w |ICMP}} ({{w |IPv6}} и {{w |ICMPv6}} не&nbsp; поддерживаются NAT-подсистемой conntrack).

* NAT-трекеры протоколов [[w:Транспортный уровень |транспортного уровня]]: nf_nat_proto_sctp, nf_nat_proto_dccp, nf_nat_proto_gre, nf_nat_proto_udplite.

* Вспомогательные модули NAT для протоколов [[w:Протоколы прикладного уровня |прикладного]] и [[w:Сеансовый уровень |сеансового]] уровней: nf_nat_ftp, nf_nat_irc, nf_nat_pptp и  т.  п.

* Кроме того, к conntrack можно условно отнести и модули netfilter, обеспечивающие взаимодействие этих двух подсистем: критерий conntrack (xt_conntrack), действия NOTRACK и CT (xt_NOTRACK и xt_CT), практически все действия [[#Таблица nat|таблицы nat]], а также соответствующие модули (библиотеки iptables/ip6tables): libxt_conntrack, libxt_NOTRACK, libxt_CT и  т.  п.

* '''conntrack'''  — инструмент, позволяющий [[w:Root |системному администратору]] наблюдать таблицы состояний соединений и взаимодействовать с ними: очищать таблицы целиком, удалять отдельные записи, маркировать соединения вручную (аналог действия CONNMARK), устанавливать [[Тайм-аут (Телекоммуникации)|тайм-аутауты]]ы соединений. Поддерживается фильтрация вывода (например, на основании адресов и/или портов источника и/или назначения), а также вывод в различных форматах, включая {{w |XML}}. Кроме того, данная утилита позволяет отслеживать в реальном времени события системы conntrack, например, открытие новых соединений или изменение состояния существующих.

* '''conntrackd'''  — демон, обеспечивающий синхронизацию таблиц состояний с другими хостами, что в сочетании с возможностями демона [[keepalived]] позволяет создавать фаерволы на {{w |кластер}}ах высокой доступности (High Availability)  — при выходе из строя одного из хостов кластера его соединения будут «подхвачены» другими хостами кластера и корректно обработаны с учетом состояний. Также conntrackd можно использовать просто для удаленного сбора статистики по соединениям.

* '''libnetfilter_conntrack''' (ранее libnfnetlink_conntrack и libctnetlink)  — обеспечивает взаимодействие приложений с системой conntrack. В качестве примеров приложений, использующих эту библиотеку, можно упомянуть:

** '''iptstate'''  — в какой-то мере аналог утилиты conntrack, хотя и не&nbsp; имеющий таких богатых возможностей. Предназначена для непрерывного вывода таблицы состояний соединений с периодическим обновлением, в стиле широко известной утилиты {{w |top}}. Поддерживает различные виды сортировки (по адресам/портам источника/назначения, [[Тайм-аут (Телекоммуникации)|тайм-ауту]], счетчикам и  т.  п.). Позволяет удалять записи из таблицы состояний. Не&nbsp; поддерживает работу с таблицей ожидаемых (expected) соединений.

* '''libnetfilter_queue''' (ранее libnfnetlink_queue)  — отвечает за передачу пакетов демонам на предмет анализа. По результатам этого анализа пакет может быть заблокирован или пропущен. При пропускании пакета возможна установка или изменение его маркировки (nfmark). Идеологическим предшественником libnetfilter_queue была ныне устаревшая библиотека libipq. В качестве примеров приложений, использующих libnetfilter_queue, можно упомянуть:

** '''nufw'''  — фаервол, выполняющий фильтрацию трафика на основе авторизации пользователей. Позволяет устанавливать ограничения на доступ к сетям, находящимся за фаерволом, для отдельных пользователей. Авторизация пользователей на фаерволе обеспечивается отдельным демоном nuauth. Например, в случае, если клиенты используют [[Linux]], авторизация может выполняться совершенно прозрачно, благодаря возможностям {{w |PAM}} (модуль pam_nufw) в момент входа пользователя в систему. Особенно удобны подобные системы в корпоративных сетях, где используются системы централизованного управления аккаунтами пользователей (nufw/nuauth поддерживает {{w |LDAP}} и [[winbind]]).

** '''{{w |l7-filter}}-userspace'''  — демон, позволяющий определить протокол [[w:Протоколы прикладного уровня |7-го (прикладного) уровня]] [[w:Сетевая модель OSI |модели OSI]], которому принадлежит полученный пакет, на основании анализа его содержимого при помощи [[Регулярные выражения|регулярных выражений]]. Результат анализа возвращает в маркировке пакета. Полезен при фильтрации и [[w:Шейпинг (информатика) |шейпинге]] трафика протоколов, не&nbsp; имеющих фиксированных номеров портов для соединений данных, например, [[BitTorrent]]. Впрочем, в настоящее время существуют и альтернативные решения  — {{w |P2P}}-протоколы можно выделять при помощи критерия ipp2p (из набора xtables-addons), а вспомогательные соединения в известных системе conntrack протоколах ({{w |FTP}}, {{w |IRC}}, {{w |SIP}}) можно выделять при помощи критерия helper и маркировки соединений.

** '''iplist'''  — userspace-альтернатива ipset. Как и ipset, позволяет считывать большие списки {{w |IP-адрес}}ов и проверять пакеты на предмет нахождения адреса их источника/назначения в данном списке. В зависимости от результата проверки, пакет может быть пропущен или заблокирован, либо промаркирован соответствующим образом. Разумеется, ipset, работая на уровне ядра, обеспечивает более высокую скорость проверки, а также поддерживает дополнительные возможности, например, динамическое изменение списков при помощи действия SET (добавление и удаление записей), сохранение дополнительной информации (номера [[w:Порт (компьютерные сети) |портов]], {{w |MAC-адрес}}а, [[Тайм-аут (Телекоммуникации)|тайм-ауты]] записей). Несмотря на то, что в настоящий момент ipset пока что не&nbsp; принят в ядро, современные дистрибутивы ipset позволяет произвести сборку и установку необходимых компонентов без необходимости наложения {{w |патч}}ей на ядро и iptables, благодаря возможностям подгружаемых модулей ([[:en:LKM]]) ядра [[Linux]]. Поэтому, с учетом вышесказанного, необходимость в iplist в настоящее время сомнительна.

* '''libnetfilter_log''' (ранее libnfnetlink_log)  — предоставляет демонам интерфейс для получения служебной информации о пакетах на предмет регистрации и учета трафика. В настоящее время известен только один проект, использующий данную библиотеку  — '''ulogd2''' ([netfilter] userspace logging daemon, версия&nbsp; 2). Данный проект находится пока в бета-стадии разработки. Надо заметить, что ulogd2 может получать информацию не&nbsp; только через libnetfilter_log (действие NFLOG), но и через классический механизм libipulog (действие ULOG), а также через libnetfilter_conntrack (данный метод позволяет получать информацию не&nbsp; об отдельных пакетах, а о соединениях в целом).

* Модули расширений, определяющие конкретные структуры записей и методы работы с ними, например, ip_set_hash_ip (тип данных hash: ip), ip_set_bitmap_port (тип данных bitmap: port) и  т.  д.

* Модули расширений для утилиты ipset, соответствующие модулям расширений в ядре, например, ipset_hash_ip (тип данных hash: ip), ipset_bitmap_port (тип данных bitmap: port) и  т.  д. Каждый такой модуль отвечает за обеспечение {{w |интерфейс}}а между «своим» модулем ядра и конечным пользователем, в частности, проверку корректности вводимых и форматирование выводимых данных, а также вывод справочной информации по допустимым командам и параметрам. В ранних версиях ipset (до 4 включительно) такие модули выделялись в виде подгружаемых библиотек, однако в современных версиях ipset они статически включаются в основной бинарник, поэтому разделение существует лишь в исходном коде.

* Модуль netfilter xt_set (критерий set и действие SET), а также соответствующие модули (библиотеки) iptables (libxt_set и libxt_SET). Критерий set позволяет проверять различные параметры пакета ([[w:IP-адрес |IP]]/{{w |MAC-адрес}}а, {{w |TCP}}/{{w |UDP}}-[[w:Порт (компьютерные сети) |порты]] источника и/или получателя) на предмет нахождения или отсутствия в списке. Действие SET позволяет добавлять или удалять записи из списка на основании указанных параметров пакета. <!-- Отметим, что, начиная с версии iptables 1.4.9 {{w |IPv4}}-специфичные модули libipt_set и libipt_SET [http://git.netfilter.org/cgi-bin/gitweb.cgi?p=iptables.git;a=commit;h=d40f1628c3717daebc437a398a285e371b5b6f7f заменены] на более универсальные libxt_set и libxt_SET, которые могут использоваться как в iptables, так и в ip6tables. -->

ipset поддерживает следующие типы данных (в скобках приведены названия согласно терминологии устаревшей версии ipset&nbsp; 4):

* '''bitmap: ip''' (ipmap)  — полный перечень {{w |IP-адрес}}ов.

* '''bitmap: ip, mac''' (macipmap)  — полный перечень IP-адресов, причем вместе с каждым IP-адресом может быть сохранен {{w |MAC-адрес}}.

* '''bitmap: port''' (portmap)  — полный перечень [[w:Порт (компьютерные сети) |портов]].

* '''hash: ip''' (iphash)  — выборочный перечень IP-адресов (либо IP-подсетей с одинаковой маской).

* '''hash: net''' (nethash)  — выборочный перечень IP-подсетей (блоков IP-адресов). В отличие от hash: ip, в одном списке могут присутствовать подсети с различными масками.

* '''hash: ip, port''' (ipporthash)  — выборочный перечень IP-адресов, причем с каждым адресом может быть сохранен порт. В версии ipset&nbsp; 4 и более ранних существует ограничение: адреса в пределах одного перечня должны принадлежать одному [[w:Бесклассовая адресация |блоку /16]] (/255.255.0.0, максимум 65536 адресов). Начиная с версии ipset&nbsp; 5, для каждого номера порта можно также сохранять идентификатор протокола [[w:Транспортный уровень |транспортного уровня]].

* '''hash: ip, port, ip''' (ipportiphash)  — выборочный перечень IP-адресов, причем с каждым адресом может быть сохранен порт и еще один IP-адрес. В версии ipset&nbsp; 4 и более ранних ограничение на «первичные» адреса (первые в тройке адрес-порт-адрес) такое же, как и для ipporthash. Начиная с версии ipset&nbsp; 5, для каждого номера порта можно также сохранять идентификатор протокола транспортного уровня.

* '''hash: ip, port, net''' (ipportnethash)  — выборочный перечень IP-адресов, причем с каждым адресом может быть сохранен порт и IP-подсеть. В версии ipset&nbsp; 4 и более ранних ограничение на «первичные» адреса такое же, как и у типа ipporthash. Начиная с версии ipset&nbsp; 5, для каждого номера порта можно также сохранять идентификатор протокола транспортного уровня.

* '''list: set''' (setlist)  — список списков. Может содержать списки любого перечисленного здесь типа, кроме list: set. При обращении к такому объекту из netfilter, включенные в него списки рассматриваются как один большой список. Поиск записей (критерий set) производится по всем вложенным спискам соответствующего типа. При добавлении записей (действие SET), вложенные списки поочередно проверяются (согласно порядку их перечисления) на соответствие типа и наличие свободного места, и запись добавляется в первый же подходящий. В то же время, при обращении к такому списку через утилиту ipset, он рассматривается именно как совокупность элементов-списков, что позволяет добавлять, удалять и проверять наличие именно вложенных списков, но не их элементов.

* '''hash: net, iface'''  — выборочный перечень IP-подсетей, причем с каждой подсетью может быть сохранено название сетевого интерфейса. Появился в версии ipset 6.7 (входит в [[w:Ядро Linux |Linux]] 3.1), ранние версии ipset не имеют подобных возможностей. Существует ограничение: нельзя сохранять более 64 имен интерфейсов с одним и тем же адресом подсети. Этот тип данных удобен при наличии в системе большого количества сетевых интерфейсов (например, сотен {{w |VLAN}}-интерфейсов).

* '''iptree'''  — выборочный перечень IP-адресов, причем с каждым адресом может быть сохранено значение [[Тайм-аут (Телекоммуникации)|тайм-аута]] в секундах. По истечении тайм-аута адрес удаляется из списка. Чтобы активировать возможность использование тайм-аутов для определенного списка, нужно при его создании задать тайм-аут по умолчанию (опция <tt>--timeout</tt>). Начиная с версии ipset&nbsp; 5, данный тип не&nbsp; поддерживается, при попытке его использования автоматически заменяется на hash: ip. Заметим, что начиная с пятой версии тайм-ауты реализованы для всех поддерживаемых типов данных.

* '''iptreemap'''  — гибридный перечень, позволяющий сохранять адреса, блоки и диапазоны адресов. Начиная с версии ipset&nbsp; 5, данный тип не&nbsp; поддерживается, при попытке его использования автоматически заменяется на hash: ip. Стоит отметить, что в современных версиях ipset при работе с адресами IPv4 можно указывать диапазоны адресов и подсети, которые при обращении к внутренним спискам будут автоматически преобразованы в наборы соответствующих элементов, Например, <tt>ipset create foo hash:ip; ipset add foo 192.168.0.0-192.168.0.3</tt> добавит в список <tt>foo</tt> адреса 192.168.0.0, 192.168.0.1, 192.168.0.2 и 192.168.0.3 (аналогичный эффект может быть достигнут и командой <tt>ipset add foo 192.168.0.0/30</tt>).

Таким образом, выбор необходимого вам типа данных определяется конкретными условиями задачи, прежде всего, отношением усредненного количества элементов в списке к требуемому диапазону охвата. Например, если вы собираетесь хранить в списке блэк-листы адресов, замеченных в атаках на ваш сервер, целесообразнее использовать тип hash: ip, потому что атакующие вас ботнеты, как бы они ни&nbsp; были велики, все равно занимают незначительную долю адресного пространства {{w |IPv4}}. К тому же, как следует из сказанного в предыдущем абзаце, тип bitmap: ip все равно не&nbsp; может хранить адреса, выходящие за предел одной подсети [[w:Бесклассовая адресация |префикса&nbsp; 16]]. Но в том случае, если вам, например, нужно задать список хостов из вашей локальной сети, имеющих доступ к каким-либо услугам (службам вашего {{w |сервер}}а, выходу в {{w |Интернет}}), и этот доступ должно иметь значительное количество хостов (а не&nbsp; единицы), то целесообразнее будет использовать bitmap: ip.

По поводу хранения адресов подсетей ([[w:Бесклассовая адресация |блоков]] {{w |IP-адрес}}ов) можно сказать следующее. Если вам нужно хранить большое количество блоков одного размера из ограниченного диапазона (не&nbsp; более 65536 возможных значений), например, блоки /24 из подсети /8, вы можете использовать тип bitmap: ip, указав маску. Если же вам нужно хранить блоки одного размера из достаточно широкого диапазона, например, /24 из всего адресного пространства {{w |IPv4}}, используйте тип hash: ip, также с указанием маски. При необходимости хранить в одном списке блоки ''разного'' размера, воспользуйтесь типом hash: net.

Что касается улучшений в версиях 5 и 6 по сравнению с четвертой и более ранними, то, помимо уже упомянутых (поддержка адресов {{w |IPv6}}, поддержка [[Тайм-аут (Телекоммуникации)|тайм-аутов]] для всех типов данных, возможность сохранения идентификатора протокола транспортного уровня в типах hash: ip, port, hash: ip, port, ip и hash: ip, port, net), стоит также отметить переход на использование nfnetlink (см. выше) для связи ядра и userspace, а также более простой синтаксис. Например, те действия, которые в ipset&nbsp; 4 выглядели бы так:

Кроме того, современные версии ipset поддерживают работу в режиме простой [[w:Командный интерпретатор |оболочки]], принимающей команды со [[stdin]]. При этом в них обеспечивается полная обратная совместимость синтаксиса с четвертой версией, то есть синтаксис, корректно работающий для четвертой версии ipset, будет точно так же работать в пятой и шестой.

* '''Прямая {{w |маршрутизация}} (gatewaying)'''  — применяется в том случае, если между балансировщиком и обработчиками отсутствуют {{w |маршрутизатор}}ы, т.е.то есть они находятся в одном сегменте сети. В этом случае адрес назначения в заголовке пакетов сохраняется неизменным («кластерный» адрес), подменяются лишь {{w |MAC-адрес}}а назначения при отправке [[w:Кадр (телекоммуникации) |кадров]] с этими пакетами.

* '''[[w:Инкапсуляция (компьютерные сети) |Инкапсуляция]] IPIP'''  — модификация предыдущего метода на тот случай, когда балансировщик и обработчики находятся в разных сегментах сети. При помощи инкапсуляции IP-в-IP создаются [[w:Туннелирование (компьютерные сети) |сетевые туннели]], которые объединяют балансировщик и обработчик в один сегмент виртуальной сети.

* '''{{w |Маскарадинг}} ({{w |NAT}})'''  — наиболее гибкое и универсальное решение: балансировщик подменяет адреса/порты назначения проходящих пакетов на реальные адреса/порты обработчиков ({{w |трансляция порт-адрес}}). При этом обеспечивается как простота настройки (не нужно поднимать дополнительные адреса на обработчиках и туннели между балансировщиком и обработчиком), так и гибкость (целевой порт обработчика может отличаться от порта кластерной службы, что невозможно в рамках других методов). Недостатком данного метода является несколько большее потребление системных ресурсов (трансляция адресов является довольно ресурсоемкой задачей).

* '''rr (round robin)'''  — классическая [[w:Round-robin (алгоритм) |кольцевая схема]], когда все обработчики получают новые соединения поочередно.

* '''wrr (weighted round robin)'''  — модификация кольцевой схемы на тот случай, когда одни сервера могут обрабатывать больше соединений, чем другие. Такие сервера включаются в один проход очереди по нескольку раз, и соответственно получают больше соединений.

* '''lc (least-connection)'''  — новое соединение передается тому серверу, который на текущий момент обрабатывает наименьшее число соединений.

* '''wlc (weighted least-connection)'''  — модификация предыдущего метода на случай, когда возможности серверов отличаются. При выборе нового сервера сравниваются не непосредственно количества открытых соединений, а отношения количества соединений к весовому коэффициенту (весу) обработчика (который и характеризует его возможности).

* '''lblc (locality-based least-connection)'''  — формирует привязку обработчиков к кластерному адресу назначения (их может быть несколько). В том случае, если для запрошенного адреса такой привязки еще нет, или привязанный обработчик сильно перегружен ­— выбирает (по алгоритму lc) и привязывает новый обработчик.

* '''lblcr (locality-based least-connection with replication)'''  — несколько усложненный вариант предыдущего алгоритма. К каждому кластерному адресу привязывается группа обработчиков, которая периодически обновляется (исключаются наиболее нагруженные обработчики, вместо них включаются наименее нагруженные).

* '''dh (destination hashing)'''  — обеспечивает жесткую, неуправляемую привязку обработчиков к кластерным адресам назначения (выбор обработчика производится исключительно на основании элементарных арифметических операций над кластерным адресом и ''никак не учитывает'' загруженности обработчиков). Может привести к перегрузкам отдельных обработчиков  — в этом случае кластер просто перестает обслуживать соответствующий адрес. В такой ситуации нужно либо увеличить лимит соединений на обработчик, либо выбрать другой алгоритм.

* '''sh (source hashing)'''  — аналогично dh, но обработчики привязываются к адресам клиентов. Как и dh, в случае перегрузки прекращает обслуживание. Отметим, что для формирования ''временных'' привязок обработчиков к адресам клиентов целесообразнее использовать механизм устойчивых соединений (persistent connections), доступный для всех алгоритмов.

* '''sed (shortest expected delay)'''  — выбирает сервер с наименьшей ожидаемой задержкой ответа. Эта задержка определяется как отношение числа обрабатываемых соединений плюс единица к весу обработчика. Таким образом, этот метод по принципу близок к wlc (отличается лишь прибавлением единицы к числителю сравниваемой величины, что немного меняет влияние веса обработчика на выбор).

* '''nq (never queue)'''  — пытается передать новое соединение обработчику, который в данный момент не обрабатывает других соединений. Если все обработчики уже заняты, использует предыдущий алгоритм (sed).

Заметим, что классификация пакетов по отношению к соединениям, реализуемая системой conntrack, во многих случаях отличается от официального описания сетевых протоколов. Например, с точки зрения критерия conntrack, TCP-пакет SYN/ACK (отвечающий на SYN)  — уже часть существующего сеанса, а по определению TCP такой пакет  — всего лишь элемент открытия сеанса.

Более сложный вариант связанного соединения  — соединение данных в пассивном режиме {{w |FTP}}. FTP-сервер самостоятельно выбирает порт для прослушивания из достаточно большого диапазона, и сообщает номер порта клиенту через управляющее соединение, после чего клиент подключается к этому порту и передает данные. {{w |netfilter}}, а точнее модуль conntrack_ftp, выделяет в потоке данных управляющего соединения нужный номер порта, что позволяет корректно определить новое соединение как связанное и, соответственно, корректно пропустить его через правила фильтрации.

В некоторых случаях целесообразно отключить отслеживание состояния соединений. Например, если ваш сервер находится под [[w:DoS-атака |(D)DoS-атакой]] типа флуд, и вам удалось локализовать ее источники, отслеживать соединения с атакующих хостов и тратить для этого ресурсы своей системы явно не имеет смысла. В подобных случаях используется действие NOTRACK, применяемое в [[#Таблица raw|таблице raw]].

Заменив в предыдущем правиле <tt>ESTABLISHED</tt> на <tt>ESTABLISHED,RELATED</tt> и подгрузив соответствующие модули ядра, вы автоматически обеспечите корректную фильтрацию протоколов, использующих связанные соединения  — {{w |FTP}}, {{w |SIP}}, {{w |IRC}}, {{w |H.323}} и других. Такое простое (с точки зрения пользователя) решение сложной (с технической точки зрения) проблемы является безусловным достоинством фаервола {{w |netfilter}} и ядра [[Linux]] в целом.

Более подробно об использовании этого критерия вы можете почитать [[#conntrack_2conntrack 2|ниже]].

Кроме критерия conntrack, стоит упомянуть и его идеологического предшественника  — [[#state|критерий state]]. Изначально для определения состояния соединения использовался именно он, то есть вместо <tt>-m conntrack --ctstate ESTABLISHED,RELATED</tt> использовалось <tt>-m state --state ESTABLISHED,RELATED</tt>. Подобные формулировки до сих пор сохраняются во многих руководствах по iptables. Однако в настоящее время критерий state считается устаревшим, и разработчики iptables [http://jengelh.medozas.de/documents/Perfect_Ruleset.pdf рекомендуют] использовать вместо него критерий conntrack. Также заметим, что критерий conntrack обладает более широкими возможностями, нежели state, и позволяет использовать дополнительную информацию о соединении, в частности, состояние самого соединения (ctstatus), факт применения к нему [[w:NAT |трансляции адресов]], тайм-аут для «повисших» соединений (ctexpire) и  т.  п.

* '''ACCEPT''', '''DROP''' и '''REJECT'''  — базовые операции фильтрации. Более подробно они рассмотрены ниже, при описании таблицы filter.

* '''RETURN'''  — обеспечивает возврат из текущей цепочки. В частности, если из цепочки A правилом номер 3 пакет был направлен в цепочку B, то применение к нему в цепочке B действия RETURN приведет к его переходу обратно в цепочку A, и он продолжит ее прохождение со следующего правила (номер 4).

Например, предположим, что нам нужно обеспечить доступ к определенным [[w:Порт (компьютерные сети) |портам]] нашего сервера для всех хостов из подсети 10.134.0.64/26, ''кроме'' 10.134.0.67 и 10.134.0.100.

Теперь все новые входящие пакеты, отправленные из нашей подсети 10.134.0.64/26, отправляются на проверку в цепочку <tt>our_subnet</tt>. К пакетам с «запрещенных» хостов применяется операция RETURN, и они покидают эту цепочку и впоследствии блокируются действием по умолчанию цепочки INPUT. Пакеты с остальных хостов этой подсети пропускаются в том случае, если они адресованы на порты [[w:Прокси-сервер |прокси]] (8080/tcp), {{w |SSH}} (22/tcp), {{w |SMB}} (139,445/tcp, 137,138/udp), {{w |DNS}} (53/tcp, udp), {{w |NTP}} (123/udp). Также для этих хостов разрешены {{w |ICMP}}-эхо-запросы (пинги). Все остальные пакеты (включая пакеты не из нашей подсети, пакеты с запрещенных хостов и пакеты на неразрешенные порты) блокируются действием по умолчанию DROP.

Нетрудно заметить, что в нашем простом примере вместо RETURN можно было использовать и DROP. Однако, существует понятие «принципа одного запрета». При организации фильтрующих правил в рамках этого принципа, сначала следует серия разрешающих правил, исключения оформляются в виде RETURN, а все не разрешенные пакеты доходят до конца базовой цепочки и блокируются действием по умолчанию либо последним правилом. Следование этому принципу позволяет достичь гибкости в выборе и смене метода блокирования пакетов. Допустим, вы хотите сменить блокирующее действие DROP на REJECT. Нет ничего проще  — просто меняете правило по умолчанию. Так же просто вводятся специфические методы блокировки для TCP, например, REJECT <tt>--reject-with tcp-reset</tt> или DELUDE  — достаточно просто добавить это действие (вместе с указанием протокола <tt>-p tcp</tt>) в конец цепочки. Все не-TCP пакеты при этом будут по-прежнему блокироваться действием по умолчанию.

Впрочем, изложенный принцип теряет первоначальный смысл, если в разных случаях нужно обеспечить разные способы блокирования. Рассмотрим чуть более сложный пример: допустим, наш сервер подключен к локальной сети 10.0.0.0/8. В ней есть некий «недоверенный» сегмент, скажем, 10.122.0.0/16, для которого нужно полностью заблокировать доступ к нашему серверу. Но в этом сегменте есть несколько «хороших» хостов (скажем, 10.122.72.11 и 10.122.180.91), которые блокировать не&nbsp; нужно. Поставленную задачу можно решить следующим образом:

Заметим, что в данном примере хосты из недоверенного сегмента блокируются «молча» (DROP), в то время как при обращении «хороших» хостов на неправильные порты сервер вежливо сообщает им об отказе (REJECT). Этот принцип также является очень важным при построении фаерволов  — чем меньше информации попадает к потенциальному злоумышленнику, тем лучше, поэтому на опасных направлениях целесообразно использовать «молчаливое» блокирование, в то время как явные сообщения для «своих» упрощают диагностику работы сети и поиск ошибок.

Например, предположим, что у нас есть объединенная через один [[w:Сетевой коммутатор |свитч]] подсеть 10.134.0.64/26, к которой наш компьютер подключен через интерфейс eth1. Тогда защиту от {{w |спуфинг}}а (подделки адресов отправителя) через проверку {{w |MAC-адрес}}а можно обеспечить следующим образом:

Все новые входящие пакеты с обратным адресом из подсети 10.134.0.64/26 проходят двойную проверку в цепочке <tt>check_ours</tt>. Первый этап проверки  — соответствие интерфейса. Ведь к нашей подсети, по условию задачи, мы подключены только интерфейсом eth1. Если пакет якобы из этой подсети придет с любого другого интерфейса, он будет заблокирован. Второй этап проверки заключается в последовательном чтении списка соответствующих [[w:IP-адрес |IP]]- и {{w |MAC-адрес}}ов (цепочка <tt>check_ours_sp00f</tt>). Каждое правило этой цепочки, кроме последнего, выделяет пакеты от одного конкретного хоста нашей подсети. К пакетам, прошедшим проверку, применяется операция RETURN, выводящая пакет из этой цепочки. Если же пакет не подошел ни по одному из этих правил, он считается не прошедшим проверки и блокируется последним правилом <tt>-j DROP</tt>. Для прошедших же проверку пакетов дальнейшая судьба зависит от того, кому они адресованы. Если они идут через наш хост в другие подсети, то они пропускаются. Если же они адресованы непосредственно нашему хосту, то пропускаются только соединения на некоторые {{w |TCP}}-[[w:Порт (компьютерные сети) |порты]] ([[w:Прокси-сервер |прокси]], {{w |SSH}}, {{w |SMB}}).

* '''LOG'''  — позволяет записывать информацию о пакетах в журнал ядра (см. {{w |syslog}}).

Такая запись содержит очень много полезной информации. Начинается она с даты и времени получения пакета. Затем идет имя нашего хоста (interdictor) и источник сообщения (для сообщений фаервола это всегда ядро). Потом идет заданный нами префикс (<tt>New connection from ours:</tt>), после чего следуют данные о самом пакете: входящий интерфейс (определен для цепочек PREROUTING, INPUT и FORWARD), исходящий интерфейс (определен для цепочек FORWARD, OUTPUT и POSTROUTING), далее  — сцепленные вместе {{w |MAC-адрес}}а источника и назначения (сначала идет адрес назначения, в данном случае это наш интерфейс eth1 с маком 00:15:17:4C:89:35, затем адрес источника, в нашем случае это 00:1D:60:2E:ED:A5, и в конце следует значение [[:en:EtherType|EtherType]], 08:00 соответствует протоколу {{w |IPv4}}<ref>Если кратко, EtherType указывает тип протокола, инкапсулированного в {{w |Ethernet}}-[[w:Кадр (телекоммуникации) |кадр]]. При работе с iptables это значение будет всегда равно 08:00 (протокол {{w |IPv4}}), при работе с ip6tables  — 86:DD ({{w |IPv6}}). Полный список EtherTypes доступен [http://www.iana.org/assignments/ethernet-numbers на сайте IANA], список поддерживаемых netfilter’ом  — в файле /etc/ethertypes, который в большинстве дистрибутивов находится в пакете {{w |ebtables}}.</ref>), потом {{w |IP-адрес}}а источника (10.134.0.67) и получателя (10.134.0.65, это наш хост), а затем идет различная техническая информация. Например, протокол ({{w |TCP}}), [[w:Порт (компьютерные сети) |порты]] источника и назначения (31521 и 8080 соответственно), [[w:Тип обслуживания |TOS]] и [[w:Time to live |TTL]], длина пакета (48 байт), наличие флага SYN и  т.  д.

Указав соответствующие параметры действия LOG, можно дополнить эту информацию [[w:TCP#Номер последовательности |номером TCP-последовательности]] (опция <tt>--log-tcp-sequence</tt>), выводом включенных опций протоколов TCP (опция <tt>--log-tcp-options</tt>) и {{w |IP}} (<tt>--log-ip-options</tt>), а также идентификатором пользователя, процесс которого отправил данный пакет (<tt>--log-uid</tt>, имеет смысл только в цепочках OUTPUT и POSTROUTING).

Параметр <tt>--log-prefix</tt> позволяет задать поясняющую надпись, упрощающую поиск сообщений в системных журналах. Параметр <tt>--log-level</tt> определяет уровень важности лог-сообщения, от которого зависит, в частности, в какой именно из журналов будет записано это сообщение. За более подробными сведениями обратитесь к документации по вашему [[w:Syslog |демону системного лога]].

* '''LOGMARK'''  — специальная модификация действия LOG, реализованная в комплекте xtables-addons. Отличается тем, что заносит в лог информацию, специфичную для системы [[conntrack]], в частности, маркировку соединения (connmark aka ctmark), состояния соединения (ctstate и ctstatus) и  т.  п. Например:

<tt>iif</tt> показывает внутренний идентификатор интерфейса, через который прошел пакет (1 в данном случае соответствует eth0, 0  — lo), <tt>hook</tt>  — имя цепочки, из которой было вызвано действие LOGMARK, <tt>nfmark</tt>  — маркировку пакета (mark), <tt>secmark</tt>  — контекст безопасности {{w |SELinux}} данного пакета (secmark), <tt>classify</tt>  — класс шейпера (также известный как <tt>skb->priority</tt>, соответствует обычной для [[w:Iproute2 |tc]] форме записи ''MAJOR'':''MINOR'' согласно формуле <tt>skb->priority == ''MAJOR'' << 16 | ''MINOR''</tt>), <tt>ctdir</tt>  — направление передачи информации с точки зрения conntrack, <tt>ct</tt>  — внутренний идентификатор соединения в системе conntrack (точнее говоря, адрес в памяти, по которому расположена структура, хранящая информацию о соединении), <tt>ctmark</tt>  — маркировку соединения (connmark), <tt>ctstate</tt>  — состояние соединения, <tt>ctstatus</tt>  — статус соединения в системе cоnntrack. Более подробно о параметрах ctdir, ctstate и ctstatus вы можете прочитать [[#conntrack|ниже]], в описании критерия conntrack. Здесь же ограничимся замечаниями, что «<tt>ctstate=NEW ctstatus=</tt>» соответствует первому пакету в соединении, «<tt>ctstate=ESTABLISHED ctstatus=SEEN_REPLY,CONFIRMED</tt>»  — второму и нескольким последующим пакетам, «<tt>ctstate=ESTABLISHED ctstatus=SEEN_REPLY,ASSURED,CONFIRMED</tt>»  — пакетам в полностью установленном соединении, «<tt>ct=NULL ctmark=NULL ctstate=INVALID ctstatus=NONE</tt>»  — пакету, который не удалось отнести к существующим соединениям, «<tt>ct=UNTRACKED ctmark=NULL ctstate=UNTRACKED ctstatus=NONE</tt>»  — пакету, для которого была отключена трассировка conntrack (обычно это выполняется действием NOTRACK в таблице raw, см. [[#Таблица raw|ниже]]).

* '''ULOG'''  — позволяет передавать информацию об обработанных пакетах специальным демонам, таким, как [http://www.netfilter.org/projects/ulogd/ ulogd]. Такой подход позволяет эффективно управлять информацией о трафике, в частности, заносить ее в {{w |базы данных}}, такие как {{w |MySQL}}, {{w |PostgreSQL}} или {{w |SQLite}}. Впоследствии эти данные могут быть проанализированы и визуализированы с помощью таких средств, как [http://software.inl.fr/trac/wiki/EdenWall/NuLog NuLog].

* '''NFLOG'''  — более универсальный вариант ULOG, обеспечивающий передачу информации о пакете не напрямую в netlink-[[w:Сокет (программный интерфейс) |сокет]] (как это делает ULOG), а специальной подсистеме  — logging backend. Например, бэкенд nfnetlink_log обеспечивает передачу данных в netlink-сокет, то есть с ним NFLOG работает аналогично ULOG.

* '''NFQUEUE'''  — во многом похоже на ULOG, но передает специальному демону не информацию о пакете, а сам пакет целиком. Применяется, в частности, для организации работы {{w |l7-filter}}-userspace.

* '''QUEUE'''  — устаревшая версия NFQUEUE. Не имеет параметров, так как работает только с очередью номер 0.

Выше были рассмотрены действия «общего назначения», то есть не привязанные по своей специфике к таблицам. Далее, при рассмотрении отдельных таблиц, будут описываться действия, специфичные для каждой таблицы. Термин «специфичные» надо понимать так: совсем не обязательно, что действие, специфичное для одной таблицы, будет в принципе недопустимо в другой, но в любом случае использование этого действия в других таблицах будет «плохим тоном»  — ведь таблицы и действия четко разделены по назначению. Не стоит «забивать гвозди микроскопом».

* ''Нетерминальными'', соответственно, являются действия, ''не'' прерывающие процесс прохождения пакета через цепочки. Нетерминальными являются действия, специфичные для таблицы mangle, а из перечисленных выше  — LOG, ULOG и NFLOG.

Действие RETURN с точки зрения такой классификации занимает промежуточное положение  — оно может прервать прохождение пакета через отдельную цепочку (или несколько цепочек, если для перехода в них использовалась опция <tt>-g</tt>, а не <tt>-j</tt>), но совсем не обязательно, чтобы это приводило к завершению обработки пакета в рамках текущей базовой цепочки.

Данная таблица предназначена для операций по классификации и маркировке пакетов и соединений, а также модификации заголовков пакетов (поля [[w:Time to live |TTL]] и [[w:Тип обслуживания |TOS]]).

* '''PREROUTING'''  — позволяет модифицировать пакет ''до'' принятия решения о маршрутизации.

* '''INPUT'''  — позволяет модифицировать пакет, предназначенный самому хосту.

* '''FORWARD'''  — цепочка, позволяющая модифицировать транзитные пакеты.

* '''OUTPUT'''  — позволяет модифицировать пакеты, исходящие от самого хоста.

* '''POSTROUTING'''  — дает возможность модифицировать все исходящие пакеты, как сгенерированные самим хостом, так и транзитные.

* '''TOS'''  — изменяет поле [[w:Тип обслуживания |TOS]] данного пакета. Поддерживаются опции <tt>--set-tos</tt> (установить поле TOS в заданное значение), а также <tt>--and-tos</tt>, <tt>--or-tos</tt> и <tt>--xor-tos</tt>, комбинирующие текущее значение поля TOS с заданным в правиле значением по соответствующему логическому правилу и записывающие результат как новое значения поля TOS.

Кроме того, опция <tt>--set-tos</tt> поддерживает расширенный синтаксис <tt>--set-tos ''значение''/''маска''</tt>. При использовании такого синтаксиса в исходном значении TOS пакета зануляются те биты, которые установлены в маске, затем полученное число XOR’ится с указанным в параметрах значением, и полученная величина записывается в поле TOS. Используя синтаксис [[w:Си (язык программирования) |языка C]], это можно записать так: <tt>NEW_TOS = (OLD_TOS & ~''маска'') ^ ''значение''</tt>. Заметим, что в случае с {{w |IPv6}} операция отрицания маски не&nbsp; выполняется (то есть в исходном значении зануляются те биты, которые в маске ''не&nbsp; установлены''), хотя это и не&nbsp; отражено в документации.

Также, в случае {{w |IPv4}} (iptables) в параметре <tt>--set-tos</tt> вы можете указать одно из допустимых символьных обозначений: Minimize-Delay (TOS 16, требование минимальной задержки), Maximize-Throughput (TOS 8, требование максимальной пропускной способности), Maximize-Reliability (TOS 4, максимальная надежность доставки), Minimize-Cost (TOS 2, минимальная стоимость), Normal-Service (TOS 0, специальные требования отсутствуют). В ip6tables использование этих обозначений не&nbsp; запрещено, однако в этом случае более корректным будет использование действия DSCP (см. ниже).

Отметим, что, в соответствии с современными соглашениями, поле TOS в заголовке IP-пакета разделяется на две части: {{w |DSCP}} (первые шесть бит кода TOS) и [[w:Explicit Congestion Notification |ECN]] (последние два бита TOS). Современные версии netfilter/iptables не&nbsp; поддерживают изменение значений ECN в IP-заголовках, поэтому фактически действие TOS работает только с полем DSCP, отличаясь от действия DSCP (см. чуть ниже) разве что интерфейсом (фактически, синтаксисом).

* '''DSCP'''  — изменяет поле {{w |DSCP}} (класс [[:en:Differentiated services|DiffServ]]) в заголовке пакета. Поддерживаются опции <tt>--set-dscp</tt> (позволяет задать значение DSCP числом) и <tt>--set-dscp-class</tt> (позволяет установить заданный класс DiffServ, например, EF или AF13).

* '''TTL'''  — изменяет поле [[w:Time to live |TTL]] данного пакета (работает только с {{w |IPv4}}, для {{w |IPv6}} используется действие HL). Поддерживаются опции <tt>--ttl-set</tt> (установить поле TTL в заданное значение), а также <tt>--ttl-inc</tt> и <tt>--ttl-dec</tt> (соответственно увеличить или уменьшить текущее значение поля TTL на заданное значение). Допустимые значения TTL  — от 0 до 255. При достижении TTL=0 пакет уничтожается.

делающую наш шлюз невидимым для большинства [[w:Traceroute |трассировщиков]].

Другой полезный пример  — выравнивание TTL на выходе в Интернет (интерфейс eth0)

* '''HL'''  — изменяет поле Hop Limit в заголовке {{w |IPv6}}-пакета. Является аналогом IPv4-действия TTL и поддерживает те же операции: <tt>--hl-set</tt> (установить поле HL в заданное значение), а также <tt>--hl-inc</tt> и <tt>--hl-dec</tt> (соответственно увеличить или уменьшить текущее значение поля HL на заданное значение).

* '''MARK'''  — устанавливает или изменяет маркировку пакета. Поддерживает опции <tt>--set-mark</tt>, <tt>--and-mark</tt>, <tt>--or-mark</tt> и <tt>--xor-mark</tt>, аналогичные опциям действия TOS. Важно понимать, что маркировка пакета не хранится в его заголовке или содержимом, и поэтому действует только в пределах одного хоста. Также нужно отличать маркировку пакета от маркировки соединения. Маркировка пакетов может применяться для их дальнейшей обработки фаерволом (критерии mark и connmark), а также для классификации трафика фильтрами [[w:Шейпинг (информатика) |шейпинговой]] подсистемы [[w:Iproute2 |tc]] (лексема handle ''mark'' fw).

* '''CONNMARK'''  — устанавливает или изменяет маркировку соединения. Поддерживает те же опции, что и MARK, а также дополнительные опции <tt>--restore-mark</tt> (копирует маркировку соединения в маркировку пакета) и <tt>--save-mark</tt> (копирует маркировку пакета в маркировку соединения).

* '''CLASSIFY'''  — устанавливает [[:en:Class Based Queueing|CBQ]]-класс пакета для его последующей обработки [[w:Шейпинг (информатика) |шейпером]] (опция <tt>--set-class</tt>).

* '''TCPMSS'''  — устанавливает [[:en:Maximum segment size|максимальный размер TCP-сегмента]]. Бывает крайне полезной при использовании {{w |VPN}}-подключения<ref>Обычно проблемы с пониженным {{w |MTU}} в {{w |Ethernet}}-сетях возникают как раз из-за {{w |VPN}}-туннелей</ref> в том случае, если VPN-сервер блокирует {{w |ICMP}}-сообщения destination unreachable/fragmentation needed (тип 3, код 4), тем самым нарушая работу процедуры [[w:Maximum transmission unit#Технология Path MTU discovery |Path MTU discovery]].

которая обеспечит автоматическую установку размера сегмента в TCP-заголовках SYN- и SYN,ACK-пакетов в соответствии с минимальным из известных нашему шлюзу значений {{w |MTU}} на пути следования пакета. Например, если пакет пришел с интерфейса eth0 (MTU 1500) и уходит через интерфейс ppp0 (MTU 1492), а суммарный размер заголовков [[w:Протоколы сетевого уровня |сетевого]] и [[w:Транспортный уровень |транспортного]] уровней составляет 40 {{w |байт}} (20 байт {{w |TCP}} и 20 байт {{w |IP}}), то целесообразно установить MSS равным 1452 байтам.

* '''ECN'''  — обеспечивает обнуление [[w:Explicit Congestion Notification |ECN]]-битов (флаги CWR и ECE) в TCP-заголовке (единственная опция <tt>--ecn-tcp-remove</tt>). Может использоваться только в {{w |IPv4}}-модуле (iptables, но не&nbsp; ip6tables) для {{w |TCP}}-пакетов (<tt>-p tcp</tt>). Данное действие предназначено для защиты пакетов от ECN blackholes (маршрутизаторов, которые некорректно обрабатывают пакеты с установленными в TCP-заголовке ECN-битами)  — рекомендуется применять это действие ко всем пакетам, уходящим на такие маршрутизаторы. Обратите внимание, что данное действие никак не&nbsp; влияет на ECN-биты в {{w |IP}}-заголовках (последние два бита поля [[w:Тип обслуживания |TOS]]).

Кроме того, данное действие поддерживает три потенциально опасные опции, не отраженные в документации: <tt>--ecn-tcp-cwr</tt> (установка значения бита CWR в TCP-заголовке, 0 или 1), <tt>--ecn-tcp-ece</tt> (установка значения бита ECE в TCP-заголовке, 0 или 1) и <tt>--ecn-ip-ect</tt> (установка значения ECT codepoint в IPv4-заголовке, от 0 до 3). Использование этих опций настолько опасно, что они не отражены даже во встроенной справке iptables (<tt>iptables -j ECN -h</tt>)  — их можно увидеть, только изучив [http://git.netfilter.org/cgi-bin/gitweb.cgi?p=iptables.git;a=blob;f=extensions/libipt_ECN.c исходный код]. Без крайней необходимости применять их не рекомендуется.

* '''TCPOPTSTRIP'''  — выполняет удаление заданных TCP-опций из заголовка TCP-пакета (единственный параметр <tt>--strip-options ''значение''[,''значение''[,...]]</tt>). Удаляемые опции могут быть указаны через их номера (согласно [http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml списку на сайте IANA]) или в виде символьных обозначений (список обозначений, поддерживаемых в вашей версии iptables можно посмотреть, выполнив команду <tt>iptables -j TCPOPTSTRIP -h</tt>). Разумеется, данное действие допустимо только для протокола TCP (<tt>-p tcp</tt>). Например,

обеспечит удаление штампов времени (RFC 1323). С одной стороны, такое правило будет препятствовать удаленному злоумышленнику определить {{w |аптайм}} нашего хоста, а также тех хостов, маршрут от которых до злоумышленника проходит через наш хост. С другой стороны, блокирование штампов времени может негативно сказаться на быстродействии сети, особенно если вы используете подключения на скорости [[w:Fast Ethernet |100&nbsp; МБит]] и выше. Заметим также, что если вам нужно управлять использованием именно штампов времени для TCP IPv4-пакетов, исходящих от вашего хоста, вы можете воспользоваться {{w |sysctl}}-параметром net.ipv4.tcp_timestamps (1  — штампы включены, 0  — выключены).

* '''TPROXY'''  — реализует механизм полностью прозрачного [[w:Прокси-сервер |проксирования]]. Такой подход отличается от традиционно используемого «прозрачного» проксирования (действие REDIRECT [[#Таблица nat|таблицы nat]], см. ниже) тем, что заголовок пакета никак не&nbsp; модифицируется, в том числе не&nbsp; заменяется {{w |IP-адрес}} назначения (при традиционном прозрачном проксировании он заменяется на адрес проксирующего хоста). Кроме того, полностью прозрачное проксирование является прозрачным с точки зрения обеих общающихся сторон. Например, при проксировании обращений некоторой подсети клиентов к серверам из другой подсети, можно сделать так, чтобы не&nbsp; только клиенты считали, что обращаются напрямую к серверам, но и сервера «видели» настоящие исходные адреса клиентов и могли бы устанавливать с ними обратные соединения (например, в случае активного режима {{w |FTP}}). При традиционном же «прозрачном» проксировании, сервера могут видеть только адрес прокси-сервера.

TPROXY позволяет перенаправить транзитный пакет на локальный [[w:Сокет (программный интерфейс) |сокет]] типа AF_INET (iptables) или AF_INET6 (ip6tables), заданный портом, а также может промаркировать пакет таким образом, чтобы система марушрутизации ({{w |iproute2}}) не&nbsp; позволила пакету покинуть наш хост. Разумеется, поддержка полностью прозрачного проксирования должна быть реализована и в самом {{w |прокси-сервер}}е. В частности, прозрачное проксирование {{w |IPv4}} {{w |HTTP}} [http://wiki.squid-cache.org/Features/Tproxy4 поддерживается] прокси-сервером {{w |Squid}} начиная с версии 3.1.

* '''PREROUTING'''  — в эту цепочку пакеты попадают ''до'' принятия решения о маршрутизации. По сути, термин «решение о маршрутизации» подразумевает деление трафика на входящий (предназначенный самому хосту) и транзитный (идущий через этот хост на другие хосты). Именно на данном этапе нужно проводить операции проброса (DNAT, REDIRECT, NETMAP).

* '''OUTPUT'''  — через эту цепочку проходят пакеты, сгенерированные процессами самого хоста. На данном этапе при необходимости можно повторить операции проброса, так локально сгенерированные пакеты ''не'' проходят цепочку PREROUTING и ''не'' обрабатываются ее правилами. См. пример для действия DNAT ниже.

* '''POSTROUTING'''  — через эту цепочку проходят все исходящие пакеты, поэтому именно в ней целесообразно проводить операции {{w |маскарадинг}}а (SNAT и MASQUERADE).

* '''MASQUERADE'''  — подменяет адрес источника для исходящих пакетов адресом того интерфейса, с которого они исходят, то есть осуществляет {{w |маскарадинг}}. Такая операция позволяет, например, предоставлять доступ в {{w |Интернет}} целым [[w:Локальная вычислительная сеть |локальным сетям]] через один [[w:Сетевой шлюз |шлюз]].

Допустим, у нас есть локальная сеть 192.168.1.0/255.255.255.0 с несколькими компьютерами, имеющими адреса 192.168.1.2, 192.168.1.3 и  т.  д. Адрес 192.168.1.1 имеет внутренний (подключенный к локальной сети) сетевой интерфейс шлюза, назовем этот интерфейс eth1. Другой его интерфейс, назовем его eth0, подключен к сети Интернет и имеет адрес, допустим, 208.77.188.166. Тогда, чтобы обеспечить выход хостов из этой локальной сети в Интернет, на шлюзе достаточно выполнить следующие команды

Теперь, если один из хостов локальной сети, например, 192.168.1.2, попытается связаться с одним из интернет-хостов, например, 199.204.44.194 (kernel.org), при проходе его пакетов через шлюз, их исходный адрес будет подменяться на внешний адрес шлюза, то есть 208.77.188.166. С точки зрения удаленного хоста (kernel.org), это будет выглядеть, как будто с ним связывается непосредственно сам шлюз. Когда же удаленный хост начнет ответную передачу данных, он будет адресовать их именно шлюзу, то есть 208.77.188.166. Однако, на шлюзе адрес назначения этих пакетов будет подменяться на 192.168.1.2, после чего пакеты будут передаваться настоящему получателю. Для такого обратного преобразования никаких дополнительных правил указывать не нужно  — это будет делать все та же операция MASQUERADE. Простота трансляции сетевых адресов является одним из важнейших достоинств stateful-фильтрации.

Если же такой трансляции не производить, удаленный хост просто не сможет ответить на адрес 192.168.1.2, так как адресные пространства локальных сетей изолировано от адресного пространства Интернета. В мире могут существовать миллионы локальных сетей 192.168.1.0/255.255.255.0, и в каждой может быть свой хост 192.168.1.2. Эти сети могут и не быть связаны с Интернетом. Но если они с ним связаны  — то только благодаря механизмам трансляции сетевых адресов.

* '''SNAT''' (Source Network Address Translation)  — работает аналогично MASQUERADE, однако позволяет указать адрес «внешнего» интерфейса (опция <tt>--to-source</tt>). Такой подход позволяет экономить процессорное время шлюза, так как в случае с MASQUERADE для каждого пакета адрес внешнего интерфейса определяется заново. Таким образом, если в предыдущем примере внешний адрес шлюза 208.77.188.166 является статическим (то есть никогда не меняется), команду

* '''DNAT''' (Destination Network Address Translation)  — подменяет адрес назначения для входящих пакетов, позволяя «пробрасывать» адреса или отдельные порты внутрь локальной сети.

Теперь, с точки зрения 192.168.1.2, к нему будет обращаться только сам шлюз (192.168.1.1), поэтому ответ также пойдет через шлюз, где будет корректно оттранслирован. Такое решение тоже имеет недостаток  — подмена исходного адреса пакета приводит к тому, что компьютер, на который мы пробрасываем соединение, не может определить реального инициатора соединения. Чтобы уменьшить «вредность» этого правила, в него добавлена опция «-s 192.168.1.0/24», которая ограничивает применение этого правила только пакетами из локальной сети. Таким образом, соединения из локальной сети будут выглядеть как соединения, инициированные шлюзом, а соединения из внешней сети будут иметь свои оригинальные адреса.

Кроме того, при помощи действия DNAT можно пробрасывать не только сразу весь IP-адрес, но и отдельные {{w |TCP}}- или {{w |UDP}}-[[w:Порт (компьютерные сети) |порты]]. Например, если в предыдущем примере мы в каждое из правил

то мы «пробросим» не сам адрес 208.77.188.166, а только его {{w |TCP}}-[[w:Порт (компьютерные сети) |порт]] 80 ({{w |HTTP}}). Обращения на все остальные {{w |TCP}}- и {{w |UDP}}-порты, а также {{w |ICMP}}-пакеты, поступившие на адрес 208.77.188.166, будут обрабатываться шлюзом, и лишь входящие TCP-соединения на порт 80 будут передаваться на 192.168.1.2.

* '''REDIRECT'''  — подменяет номер порта в TCP- или UDP-пакете, а также подменяет адрес назначения на свой собственный. Например,

позволяет «завернуть» все исходящие из локальной сети TCP-соединения на порт 80, на TCP-порт 8080 шлюза. Если этот порт обслуживается специально настроенным {{w |прокси-сервер}}ом, то можно организовать «прозрачное проксирование»  — клиенты из локальной сети даже не будут подозревать, что их запросы идут через прокси-сервер. Разумеется, входящие соединения из локалки на TCP-порт 8080 должны быть разрешены в таблице filter.

* '''SAME'''  — в зависимости от цепочки (PREROUTING или POSTROUTING) может работать как DNAT или SNAT. Однако, при указании (в параметре <tt>--to-ip</tt>) одного или нескольких диапазонов IP-адресов, определяет для каждого нового соединения подставляемый адрес не случайно, а базируясь на IP-адресе клиента. Таким образом, адрес для подмены остается постоянным для одного и того же клиента при повторных соединениях (что ''не'' выполняется для обычных DNAT/SNAT). В некоторых случаях это бывает важным. Примечание: в соответсвиисоответствии с iptables-extensions'sextensions’s man page действие SAME убрано и заменено на опцию --persistent для действий '''DNAT'''/'''SNAT'''.

* '''NETMAP'''  — позволяет «пробросить» целую сеть. Например, для шлюза, стоящего между сетями 192.168.1.0/24 и 192.168.2.0/24 можно организовать следующий проброс:

Теперь, при обращении, например, хоста 192.168.1.3 на IP-адрес 192.168.3.2 он будет попадать на 192.168.2.2 (при условии, что такой транзитный трафик разрешен на шлюзе в цепочке FORWARD таблицы filter, а также на хостах сети 192.168.1.0/24 наш шлюз [[w:Маршрутизация |прописан]] в качестве шлюза для подсети 192.168.3.0/24).

* '''MIRROR'''  — довольно интересная игрушка. Меняет местами адрес источника и назначения и высылает пакет обратно. Создано исключительно для демонстрационных целей. Однако, может, например, применяться для защиты от сканирования портов  — в результате атакующий сканирует свои собственные порты. Однако наличие двух встречных MIRROR’ов на двух хостах может повлечь бесконечное блуждание одних и тех же пакетов, забивающее канал. Поэтому применяйте это действие с осторожностью.

* '''INPUT'''  — эта цепочка обрабатывает трафик, поступающий непосредственно самому хосту.

* '''FORWARD'''  — позволяет фильтровать транзитный трафик.

* '''OUTPUT'''  — эта цепочка позволяет фильтровать трафик, исходящий от самого хоста.

* '''ACCEPT'''  — пропуск пакета. Пакет покидает текущую базовую цепочку и следует дальше по потоковой диаграмме (см. рис.).

* '''REJECT'''  — заблокировать пакет и сообщить его источнику об отказе. По умолчанию об отказе сообщается отправкой ответного {{w |ICMP}}-пакета «icmp-port-unreachable». Однако, это действие поддерживает опцию <tt>--reject-with</tt>, позволяющую указать формулировку сообщения об отказе (возможные значения: <tt>icmp-net-unreachable</tt>, <tt>icmp-host-unreachable</tt>, <tt>icmp-proto-unreachable</tt>, <tt>icmp-net-prohibited</tt>, <tt>icmp-host-prohibited</tt>). Для протокола {{w |TCP}} поддерживается отказ в форме отправки RST-пакета (<tt>--reject-with tcp-reset</tt>).

* '''DROP'''  — заблокировать пакет, не сообщая источнику об отказе. Более предпочтительна при фильтрации трафика на интерфейсах, подключенных к интернету, так как понижает информативность сканирования портов хоста злоумышленниками.

* '''STEAL'''  — аналогично DROP, но в случае использования в цепочке OUTPUT при блокировании исходящего пакета не сообщает об ошибке приложению, пытавшемуся отправить этот пакет.

* '''TARPIT'''  — «подвесить» {{w |TCP}}-соединение. Используется лишь в самых крайних случаях, например, при борьбе с {{w |DoS-атака}}ми. Отвечает на входящее соединение, после чего уменьшает размер фрейма до нуля, блокируя возможность передачи данных. Соединение будет «висеть» в таком состоянии пока не истечет тайм-аут на атакующей стороне (обычно 20—30 минут). При этом на такое соединение расходуются системные ресурсы атакующей стороны (процессорное время и оперативная память), что может быть весьма ощутимо при значительном количестве соединений. В случае правильного использования действия TARPIT ресурсы атакуемой стороны практически не расходуются.

* '''DELUDE'''  — создать видимость открытого TCP-порта. На SYN-пакеты отвечает пакетами SYN/ACK, на все прочие пакеты отвечает RST. Очень полезно для введения в заблуждение злоумышленника, сканирующего порты вашего хоста.

* '''CHAOS'''  — для каждого нового TCP-соединения случайно выбрать одно из двух действий. Первое из них  — REJECT, второе, в зависимости от выбранной опции, либо TARPIT (<tt>--tarpit</tt>), либо DELUDE (<tt>--delude</tt>). В частности, при использовании действия <tt>CHAOS --delude</tt> для всех неиспользуемых портов, сканирующий ваши порты злоумышленник получит совершенно неверную информацию о состоянии ваших портов. В случае с <tt>CHAOS --tarpit</tt> ситуация усугубится еще и «подвисающими» соединениями.

Особо заметим, что все действия, перечисленные в качестве допустимых в таблице filter, можно применять в любой из цепочек любой из таблиц (конечно, с разумными ограничениями  — например, не стоит ставить действия TARPIT, CHAOS и DELUDE для собственных исходящих пакетов). Однако эти действия предназначены именно для фильтрации, и применение их за пределами таблицы filter является дурным тоном. Как и, например, применение действий, специфичных для таблицы mangle, в таблицах filter и nat.

* '''INPUT'''  — эта цепочка обрабатывает трафик, поступающий непосредственно самому хосту.

* '''FORWARD'''  — через эту цепочку проходит транзитный трафик.

* '''OUTPUT'''  — эта цепочка позволяет обрабатывать трафик, исходящий от самого хоста.

Обратите внимание, что в данной таблице не&nbsp; будут срабатывать критерии, которым для корректной работы необходим conntrack (это критерии conntrack, connmark, connlimit, connbytes).

* '''NOTRACK'''  — позволяет предотвратить обработку пакетов системой conntrack. Разумеется, применять его стоит не ко всем пакетам подряд, а только к тем, для которых такая обработка не нужна и даже вредна. Например, к пакетам, к которым впоследствии применяется действие TARPIT (см. выше).

* '''CT'''  — более функциональный инструмент, добавленный в версии [[w:Ядро Linux |Linux]] 2.6.34. Позволяет задать различные настройки [[conntrack]], в соответствии с которыми будет обрабатываться соединение, открытое данным пакетом. В частности, можно:

: будет предписывать для всех соединений на {{w |TCP}}-[[w:Порт (компьютерные сети) |порт]] 8000 генерировать только события «открытие соединения» (NEW) и «завершение соединения» (DESTROY), игнорируя все прочие события. Полный список возможных событий: new, related, destroy, reply, assured, protoinfo, helper, mark, natseqinfo, secmark.

:* Задать ''зону conntrack'' для данного пакета (параметр <tt>--zone</tt>). Механизм зон conntrack позволяет корректно отслеживать, фильтровать и {{w |NAT}}'ить соединения даже в том случае, если хост подключен к нескольким сетям, использующим одинаковые пространства имен, через различные интерфейсы (например, интерфейсы eth0 и eth1 подключены к двум разным сетям, но обе эти сети используют пространство 192.168.0.0/24). Традиционно, для идентификации соединений conntrack использует кортежи (tuples)  — набор значений в который входят адреса и порты (в случае ICMP  — типы и коды ICMP) источника и назначения при передаче данных в прямом и обратном направлении. Очевидно, что при наличии нескольких подсетей с одинаковыми адресными пространствами, возможно возникновение путаницы, когда сразу нескольким соединениям ставится в соответствие одна и та же запись в таблице соединений. Чтобы избежать такой ситуации, в кортеж был добавлен идентификатор зоны conntrack  — целое число, которое можно устанавливать через специальное правило в таблице raw в зависимости от входящего/исходящего интерфейса (как уже говорилось выше, цепочки таблицы raw пакеты проходят еще до обработки их conntrack’ом). Например,

: Таким образом, пакеты, входящие или исходящие через интерфейс eth1, будут получать идентификатор зоны 1, в то время как пакеты интерфейса eth0 будут по-прежнему использовать зону по умолчанию (идентификатор 0), и путаницы не&nbsp; произойдет.

* '''RAWDNAT'''  — позволяет выполнять [[w:NAT |«проброс»]] адресов и портов «сырым» методом  — без использования системы conntrack, то есть без учета состояний соединений. Это действие реализовано в рамках проекта xtables-addons. Применять его можно только в таблице raw. Имеет единственную опцию <tt>--to-destination ''адрес''[/''маска'']</tt>, по смыслу аналогичную опции <tt>--to</tt> действия NETMAP, то есть при указании маски заменяются только те биты в адресе, которые соответствуют единичным битам маски. Биты адреса, соответствующие нулевым битам маски, остаются неизменными. При отсутствии маски изменяется весь адрес.

: Отметим, что в отличие от действий [[#Таблица nat|таблицы nat]], которые работают только с соединениями в целом, операции «сырого» преобразования адресов работают только с отдельными пакетами, никак не&nbsp; учитывая контекст их передачи. Вышесказанное можно проиллюстрировать, скажем, таким простым примером: для элементарной операции «проброса» внешнего адреса на другой адрес при использовании обычных операций NAT достаточно одного правила<ref>На самом деле, для «чистого» проброса адреса, даже при использовании stateful NAT, необходимо обычно два или три правила, в частности, для проброса соединений с самого сервера в цепочке OUTPUT. Более подробно это описано при рассмотрении операции DNAT [[#Таблица nat|таблицы nat]], и здесь, с целью упрощения понимания примера, эти аспекты опущены</ref>

: Как уже говорилось выше, при использовании обычной операции DNAT в ответных пакетах, приходящих с пробрасываемого адреса (199.181.132.250), производится автоматическая (без необходимости писать для этого отдельные правила) подмена исходного адреса на изначальный (212.201.100.135), и обращающиеся по адресу 212.201.100.135 хосты даже не&nbsp; подозревают, что общаются с кем-то другим. В случае же «сырого» преобразования такая автоматическая обработка невозможна, так как она требует возможности проверять пакеты на принадлежность соединению. С другой стороны, операции «сырого» преобразования являются более гибким инструментом, а также могут работать даже с UNTRACKED и INVALID-пакетами.

Если же при задании правила маску /16 в параметре <tt>--to-source</tt> опустить, адрес будет заменен на 192.168.0.20. Но так лучше не&nbsp; делать, потому что мы выполняем трансляцию для всех пакетов из подсети 10.125.0.0/16, и без отслеживания соединений не&nbsp; сможем отличить, какие пакеты следует вернуть 10.125.32.28, а какие  — другим хостам из этой подсети. Сама же операция «возвращения» пакетов требует отдельного RAWDNAT-правила:

которое выполняет обратную подмену, заменяя адреса назначения в пакетах-ответах. Таким образом, хост 172.18.1.100 будет считать, что к нему обращаются хосты из подести 10.125.0.0/16, а вовсе не&nbsp; из 192.168.0.0/16.

Также многие критерии и параметры критериев можно инвертировать, поставив перед ними восклицательный знак. В описании синтаксиса таких критериев присутствует пометка «<tt>[!]</tt>». Инверсия меняет смысл критерия или его параметра на ровно противоположный. Например, критерию <tt>-s 127.0.0.1</tt> соответствуют все пакеты, имеющие обратный адрес 127.0.0.1, а критерию <tt>! -s 127.0.0.1</tt>  — все пакеты, ''кроме'' имеющих обратный адрес 127.0.0.1. В ранних версиях iptables восклицательный знак можно было ставить между названием критерия и значением, например, <tt>-s ! 127.0.0.1</tt>, однако последние версии iptables (в частности, 1.4.3.2 и выше), уже не поддерживают этот синтаксис, выдавая следующую ошибку:

При указании протокола становится возможным использовать специфичные для него критерии. Например, для {{w |TCP}} и {{w |UDP}} доступны критерии <tt>--sport</tt> и <tt>--dport</tt>, для {{w |ICMP}}  — <tt>--icmp-type</tt>. Подробнее эти критерии будут рассмотрены ниже.

Определяет адрес отправителя. В качестве адреса может выступать {{w |IP-адрес}} (возможно с [[w:Маска подсети |маской]]), имя хоста из /etc/hosts, или {{w |доменное имя}} (в последних двух случаях перед добавлением правила в цепочку имя [[w:DNS |резольвится]] в IP-адрес). Маска подсети может быть указана в классическом формате (например, 255.255.0.0) либо в формате {{w |CIDR}} (например, 16)<ref>Заметим, что для расчета масок подсетей и диапазонов адресов существует очень удобная утилита [[ipcalc]].</ref>. Например,

(где eth0  — интерфейс, подключенный к интернету), позволяет заблокировать простейший вид {{w |спуфинг}}а  — из интернета ''не могут'' приходить пакеты с обратным адресом, принадлежащим к диапазону, зарезервированному для локальных сетей.

Настойчиво не рекомендуется использовать доменные имена, для разрешения (резольва) которых требуются {{w |DNS}}-запросы, так как на этапе конфигурирования фаервола DNS может работать некорректно. Также, заметим, имена резольвятся всего один раз  — при добавлении правила в цепочку. Впоследствии соответствующий этому имени IP-адрес может измениться, но на уже записанные правила это никак не повлияет (в них останется старый адрес). Если указать доменное имя, которое резольвится в несколько {{w |IP-адрес}}ов, то для каждого адреса будет добавлено отдельное правило (как и в случае перечисления нескольких адресов, см. выше).

позволит принимать весь трафик, входящий через интерфейс [[w:Loopback |обратной петли]].

будет [[w:Маскарадинг |маскарадить]] весь трафик, исходящий через интерфейс eth0.

==== Протоколы [[w:Транспортный уровень |транспортного уровня]] ====

заблокирует все входящие соединения с [[w:Список портов TCP и UDP |привилегированных]] портов (''привилегированными'' в TCP/UDP считаются порты с 0 по 1023 включительно, так как для их использования нужны привилегии [[w:Root |суперпользователя]], и обычно такие порты используются [[w:Демон (программа) |демонами]] только в режиме прослушивания).

Позволяет указать список установленных и снятых [[w:TCP#Флаги (управляющие биты) |TCP-флагов]]. В ''маске'' перечисляются (через запятую, без пробелов) все проверяемые флаги, далее, после пробела, перечисляются (также через запятую) те из них, которые должны быть установлены. Все остальные перечисленные в маске флаги должны быть сняты. Возможные флаги: SYN ACK FIN RST URG PSH. Также можно использовать псевдофлаги ALL и NONE, обозначающие «все флаги» и «ни одного флага» соответственно.

Позволяет анализировать набор [[:en:SCTP_packet_structureSCTP packet structure|секций (chunks)]], входящих в состав SCTP-пакета. Возможные типы секций: DATA INIT INIT_ACK SACK HEARTBEAT HEARTBEAT_ACK ABORT SHUTDOWN SHUTDOWN_ACK ERROR COOKIE_ECHO COOKIE_ACK ECN_ECNE ECN_CWR SHUTDOWN_COMPLETE ASCONF ASCONF_ACK. Также, для секций, имеющих флаги (DATA, ABORT и SHUTDOWN_COMPLETE) можно проверить состояние флагов, указав соответствующие буквы после названия секции (для DATA  — U, B и E, для ABORT и SHUTDOWN_COMPLETE  — T). Литера в верхнем регистре предполагает установленный флаг, в нижнем  — снятый. Ключевое слово в начале позволяет определить логику работы: в случае <tt>all</tt> должны присутствовать ''все'' перечисленные секции, для <tt>any</tt>  — хотя бы одна из них, для <tt>only</tt>  — пакет должен состоять только из перечисленных секций. Примеры:

У второго и последующего фрагментов нет заголовка транспортного уровня, поэтому бессмысленно пытаться использовать для них критерии номеров [[w:Порт (компьютерные сети) |TCP/UDP-портов]] или типа ICMP.

* '''addrtype'''  — позволяет проверить тип адреса источника и/или назначения с точки зрения подсистемы маршрутизации сетевого стека ядра. Допустимые типы адресов: UNSPEC (адрес 0.0.0.0), [[w:Unicast |UNICAST]], LOCAL (адрес принадлежит нашему хосту), [[w:Broadcast |BROADCAST]], [[w:Anycast |ANYCAST]], [[w:Мультивещание |MULTICAST]], [[:en:Black hole (networking)|BLACKHOLE]], UNREACHABLE, PROHIBIT, THROW, NAT, XRESOLVE. Подробнее о большинстве перечисленных типов адресов и их использовании в [[w:Ядро Linux |Linux]] (точнее, в подсистеме {{w |iproute2}}) можно почитать [http://linux-ip.net/html/routing-tables.html здесь]. Данный критерий поддерживает следующие параметры:

<tt>[!] --src-type ''тип''[,''тип''...]</tt>  — проверка, принадлежит ли исходный адрес пакета одному из перечисленных типов.

<tt>[!] --dst-type ''тип''[,''тип''...]</tt>  — проверка, принадлежит ли адрес назначения пакета одному из перечисленных типов.

<tt>--limit-iface-in</tt>  — ограничивает проверку типа адреса только записями для интерфейса, через который пакет вошел на хост. Допускается использовать этот параметр только в цепочках PREROUTING, INPUT и FORWARD.

<tt>--limit-iface-out</tt>  — ограничивает проверку типа адреса только записями для интерфейса, через который пакет вышел с хоста. Допускается использовать этот параметр только в цепочках POSTROUTING, OUTPUT и FORWARD.

* '''ecn'''  — позволяет проверять значения битов [[w:Explicit Congestion Notification |ECN]] в заголовках {{w |TCP}} и {{w |IPv4}}. Допустимые параметры:

<tt>[!] --ecn-tcp-cwr</tt>  — проверка флага ECN CWR (Congestion Window Received) в TCP-заголовке пакета.

<tt>[!] --ecn-tcp-ece</tt>  — проверка флага ECN ECE (ECN Echo) в TCP-заголовке пакета.

<tt>[!] --ecn-ip-ect ''значение''</tt>  — проверка значения, сформированного ECN-битами поля [[w:Тип обслуживания |TOS]] (последние два бита). Возможные значения от 0 до 3.

* '''realm'''  — проверка области маршрутизации (realm) пакета. Имеет единственный параметр

<tt>[!] --realm ''значение''[/''маска'']</tt>, позволяющий указать численный идентификатор области. Если указана маска, то значение realm каждого проверяемого пакета сначала объединяется с маской при помощи [[w:Битовые операции#Побитовое И (AND) |побитового AND]], а затем сравнивается со значением, указанным в правиле. Также вместо числа можно указать символьное название области согласно обозначениям в файле <tt>/etc/iproute2/rt_realms</tt> (в этом случае маску использовать нельзя).

* '''ttl'''  — обеспечивает проверку поля [[w:Time to live |TTL]] в заголовке пакета. Позволяет установить, является ли значение TTL проверяемого пакета большим (<tt>--ttl-gt</tt>), меньшим (<tt>--ttl-lt</tt>), равным или не&nbsp; равным (<tt>[!] --ttl-eq</tt>) указанному значению.

<tt>[!] '''--icmp-type''' ''тип''</tt>  — обеспечивает проверку [[w:ICMP#Типы ICMP пакетов (полный список) |типа]] ICMP-пакета. Список возможных типов выводится по команде <tt>iptables -p icmp -h</tt>. Также можно указать стандартные числовые тип и, при

гласящее, что в такое правило никогда не&nbsp; будет срабатывать. Если вы видите подобное предупреждение, удалите правило, которое его вызвало, и перепишите это правило с использованием корректного синтаксиса (<tt>-m</tt>).

С другими же критериями, которые представляют более или менее самостоятельные протоколы ({{w |ICMPv6}}, [[MH]], {{w |IPSec}} [[:en:IPSec#Authentication_HeaderAuthentication Header|AH]] и [[:en:IPSec#Encapsulating_Security_PayloadEncapsulating Security Payload|ESP]]), все ровно наоборот, и для них корректным будет использование именно синтаксиса протокола (ключ <tt>-p</tt>), а не&nbsp; расширенного критерия. Во избежание путаницы, такие критерии вынесены в отдельные подзаголовки, по аналогии с протоколами транспортного уровня (выше).

* '''dst'''  — проверят опции назначения (подзаголовок 60 Destination Options). Имеет две опции:

<tt>[!] --dst-len ''значение''</tt>  — проверяет длину подзаголовка;

<tt>[!] --dst-opts ''код''[:''длина''][,''код''[:''длина'']...]</tt>  — позволяет проверить вхождение в данный подзаголовок конкретных опций. Также можно проверить длину каждой из них. Можно указать до 16 опций (представленных числовыми кодами), разделяя их запятой.

* '''eui64'''  — сравнивает младшие 64 бита исходного IPv6-адреса с битами исходного {{w |MAC-адрес}}а, преобразованными согласно правилам автоконфигурирования IPv6-адресов на основании MAC-адресов. Таким образом, позволяет проверить, является ли IPv6-адрес отправителя пакета автоматически сконфигурированным (работает, если отправитель находится в одном [[w:Широковещательный домен |широковещательном домене]] с нашим хостом, так как в противном случае сохранность MAC-адреса отправителя не&nbsp; может быть гарантирована).

* '''frag'''  — позволяет проверять параметры фрагментации (подзаголовок 44 Fragment). Допустимые опции:

<tt>[!] --fragid ''мин''[:''макс'']</tt>  — сверяет величину идентификатора фрагмента. Если указано одно значение, проверяется равенство, если указан диапазон  — проверяется вхождение значения в этот диапазон (включая границы).

<tt>--fragres</tt>  — проверяет, заполнены ли нулями зарезервированные поля заголовка (биты 29-30).

<tt>--fragfirst</tt>  — проверяет, является ли данный фрагмент первым в последовательности.

<tt>--fraglast</tt>/<tt>--fragmore</tt>  — проверяют M-флаг, показывающий, является ли данный фрагмент последним в последовательности (в этом случае <tt>--fraglast</tt> дает истину, а <tt>--fragmore</tt> ложь), или после него должны быть еще фрагменты (соответственно, наоборот). Эти две опции являются взаимоисключающими.

Также в документации можно найти упоминание параметра <tt>--fraglen </tt>, который якобы проверяет длину подзаголовка Fragment. Однако, согласно текущим соглашениям, длина этого подзаголовка фиксирована и равна 8&nbsp; {{w |байт}}ам, а названная опция ни на что не&nbsp; влияет.

* '''hbh'''  — проверяет опции Hop-by-Hop (подзаголовок 0 Hop-by-Hop). Синтаксис аналогичен параметру dst.

* '''hl'''  — обеспечивает проверку поля Hop Limit в IPv6-заголовке. Позволяет установить, является ли значение HL проверяемого пакета большим (<tt>--hl-gt</tt>), меньшим (<tt>--hl-lt</tt>), равным или не&nbsp; равным (<tt>[!] --hl-eq</tt>) указанному значению.

* '''ipv6header'''  — позволяет проверить наличие вспомогательных подзаголовков IPv6. Допустимыми типами заголовков являются: hop (hop-by-hop 0), dst (ipv6-opts 60), route (ipv6-route 43), frag (ipv6-frag 44), auth (ah 50), esp (esp 59). В скобках указаны «длинные» названия и числовые идентификаторы протокола. Используя опцию

вы можете указывать любые из этих обозначений  — короткие названия, длинные названия или числовые идентификаторы. Отметим, что пакет будет соответствовать критерию в том случае, если будет содержать ''только'' перечисленные подзаголовки. Изменить это поведение можно, указав опцию <tt>--soft</tt>  — в этом случае достаточно, чтобы пакет содержал хотя бы один из перечисленных подзаголовков.

* '''rt'''  — позволяет проверять параметры маршрутизации пакета (подзаголовок 43 Routing). Допустимые параметры:

<tt>[!] --rt-type ''тип''</tt>  — тип маршрутизации (0, 1 или 2);

<tt>[!] --rt-segsleft ''мин''[:''макс'']</tt>  — проверка значения поля Segment Left (показывает, сколько еще узлов должен пройти данный пакет, прежде чем достигнет цели);

<tt>[!] --rt-len ''значение''</tt>  — проверка длины всего подзаголовка.

<tt>--rt-0-res</tt>  — проверять зарезервированные поля;

<tt>--rt-0-addrs ''адрес''[,''адрес''...]</tt>  — проверяет адреса, перечисленные в подзаголовке. Можно указать не&nbsp; более 16 адресов, разделяя их запятыми. Пакет считается удовлетворяющим критерию, если подзаголовок содержит все адреса, которые были перечислены в правиле, в том же порядке;

<tt>--rt-0-not-strict</tt>  — делает условие проверки по предыдущем параметру не&nbsp; таким жестким: достаточно, чтобы хотя бы один из перечисленных адресов совпадал с соответствующим адресом в подзаголовке, при соблюдении порядка перечисления.

* <tt>'''--ahspi''' ''значение''[:''значение'']</tt>  — позволяет указать значение (или диапазон значений) [[:en:Security_Parameter_IndexSecurity Parameter Index|SPI (Security Parameter Index)]].

:* '''NEW'''  — соединение не открыто, то есть пакет является первым в соединении. Полезные примеры использования этого состояния приведены выше, в частности, при описании [[#TCP|TCP-специфичных критериев]].

:* '''ESTABLISHED'''  — пакет относится к уже установленному соединению. Обычно такие пакеты принимаются без дополнительной фильтрации, как и в случае с RELATED.

:* '''RELATED'''  — пакет открывает новое соединение, логически связанное с уже установленными, например, открытие канала данных в пассивном режиме {{w |FTP}}.

:* '''INVALID'''  — пакет по смыслу должен принадлежать уже установленному соединению (например, ICMP-сообщение port-unreachable), однако такое соединение в системе не зарегистрировано. Обычно к таким пакетам применяют действие DROP:

:* '''UNTRACKED'''  — отслеживание состояния соединения для данного пакета было отключено. Обычно оно отключается с помощью действия NOTRACK в таблице raw.

:* '''DNAT'''  — показывает, что к данному соединению применена операция подмены адреса назначения (об операциях преобразования адресов см. [[#Таблица nat|выше]]).

:* '''SNAT'''  — показывает, что к данному соединению применена операция подмены адреса источника (об операциях преобразования адресов см. [[#Таблица nat|выше]]).

:* '''EXPECTED'''  — данное соединение ожидалось системой conntrack по результатам анализа других соединений. Например, после того, как клиент и сервер через управляющее {{w |FTP}}-соединение согласуют номер порта для соединения данных в пассивном режиме, система [[conntrack]] на сервере будет ожидать входящее соединение на этот порт.

:* '''CONFIRMED'''  — подтвержденное соединение. Такой статус присваивается соединению после того, как инициатор начал передачу пакетов.

:* '''SEEN_REPLY'''  — соединение, по которому поступил ответ, то есть имеет место передача данных в обоих направлениях (поддержка данного состояния появилась сравнительно недавно).

:* '''ASSURED'''  — соединение можно считать полностью установленным. Этот статус присваивается соединению после передачи определенного количества данных. Присвоение данного статуса приводит к увеличению conntrack-тайм-аута для данного соединения (эти тайм-ауты используются для определения и удаления «повисших» и оборванных соединений).

:* '''NONE'''  — нет статуса. Соединение не соответствует ни одному из перечисленных критериев.

Протокол [[w:Транспортный уровень |транспортного уровня]], определенный системой conntrack. Синтаксис аналогичен стандартному критерию <tt>-p</tt>.

Позволяет указать направление прохождения пакетов (ORIGINAL  — от инициатора к отвечающему, REPLY  — наоборот). Если не указывать эту опцию, под критерий будут подпадать пакеты, идущие в обоих направлениях.

::  — Адрес источника (ctorigsrc): 192.168.1.2 (адрес клиента)

::  — Адрес назначения (ctorigdst): 192.168.1.1 (адрес сервера)

::  — Адрес источника (ctreplsrc): 192.168.1.1 (адрес сервера)

::  — Адрес назначения (ctrepldst): 192.168.1.2 (адрес клиента)

::  — Адрес источника (ctorigsrc): 192.168.1.2 (внутренний адрес клиента)

::  — Адрес назначения (ctorigdst): 204.152.191.37 (адрес интернет-сервера)

::  — Адрес источника (ctreplsrc): 204.152.191.37 (адрес интернет-севера)

::  — Адрес назначения (ctrepldst): 208.77.188.166 (внешний адрес нашего сервера)

::  — Адрес источника (ctorigsrc): 204.152.191.37 (адрес клиента)

::  — Адрес назначения (ctorigdst): 208.77.188.166 (наш внешний адрес)

::  — Адрес источника (ctreplsrc): 192.168.1.2 (адрес внутреннего сервера)

::  — Адрес назначения (ctrepldst): 204.152.191.37 (адрес клиента)

* '''multiport'''  — позволяет указать несколько (до 15) портов и/или их диапазонов (для протоколов {{w |TCP}}, {{w |UDP}}, {{w |SCTP}}, {{w |DCCP}} и {{w |UDP Lite}}). Поддерживает следующие параметры

<tt>[!] --sports</tt>, <tt>--source-ports ''порт''[:''порт''][,''порт''[:''порт''][,...]]</tt>  — улучшенная версия критерия <tt>--sport</tt>, описанного выше. Позволяет перечислить (без пробелов, через запятую) до 15 портов или их диапазонов.

<tt>[!] --dports</tt>, <tt>--destination-ports ''порт''[:''порт''][,''порт''[:''порт''][,...]]</tt>  — улучшенная версия критерия <tt>--dport</tt>, описанного выше. Например,

<tt>[!] --ports ''порт''[:''порт''][,''порт''[:''порт''][,...]]</tt>  — пакет будет подпадать под этот критерий, если его исходный порт ''или'' порт назначения присутствует в указанном списке.

* '''iprange'''  — позволяет указать диапазон {{w |IP-адрес}}ов, не являющийся подсетью. Поддерживает следующие параметры:

<tt>[!] --src-range ''адрес''[-''адрес'']</tt>  — позволяет указать диапазон исходных адресов. Например,

<tt>[!] --dst-range ''адрес''[-''адрес'']</tt>  — позволяет указать диапазон адресов назначения.

Если указана маска, то перед сравнением с заданным значением маркировка каждого пакета комбинируется с этой маской посредством логической операции [[w:Конъюнкция |AND]], то есть проверяется условие <tt>x & ''маска'' == ''значение''</tt> (где x  — маркировка текущего пакета). Такой подход позволит сравнивать значения отдельных {{w |бит}}. Например, критерию

будет отлавливать пакеты, в маркировке которых установлен 7-й бит (<math>2^6=64</math>, при этом первый бит соответствует <math>2^0</math>). В частности, 64…127, 192…255, 320…383 и  т.  д.

будет определять пакеты, в маркировке которых установлен второй бит, но снят первый. Такие числа будут нацело делиться на два, но не делиться на четыре  — 2, 6, 10, 14, …

* '''connmark'''  — полностью аналогичен mark, но проверяет не маркировку пакета (nfmark), а маркировку соединения (ctmark). Также имеет параметр <tt>--mark</tt> с аналогичным синтаксисом.

Userspace-вариант {{w |l7-filter}} является [[w:Демон (программа) |демоном]], взаимодействующим с {{w |netfilter}} через подсистему nfnetlink_queue  — действие NFQUEUE в терминологии iptables. При помощи этого действия определенные пакеты можно направить на анализ демону l7-filter. По результатам анализа демон выставит маркировку пакетов: 1  — пакет принадлежит новому соединению, тип которого пока не идентифицирован; 2  — пакет принадлежит соединению, тип которого идентифицировать так и не удалось. Другие значения соответствуют установленным типам соединений (соответствие задается в конфигурационном файле демона) [http://l7-filter.sourceforge.net/HOWTO-userspace#Does].

Задача l7-filter  — определить тип протокола [[w:Протоколы прикладного уровня |прикладного уровня]] (см. {{w |модель OSI}}) для данного пакета/соединения. Решается эта задача путем анализа содержимого пакета с применением [[Регулярные выражения|регулярных выражений]], позволяющих определить типовые лексемы, характерные для различных протоколов (например, «<tt>220 ftp server ready</tt>» для {{w |FTP}} или «<tt>HTTP/1.1 200 OK</tt>» для {{w |HTTP}}). Пакет, в котором встречаются такие лексемы, может быть однозначно классифицирован. В принципе, это дает достаточное основание классифицировать соединение в целом. Однако, в этом поведение kernel и userspace версий l7-filter существенно различается.

Как описывается в [http://l7-filter.sourceforge.net/technicaldetails документации], версия l7-filter-kernel ''хранит'' данные о соединениях и ''использует'' их для классификации пакетов, принадлежащих к соединениям, тип которых уже установлен. В то же время, аналогичное утверждение в отношении l7-filter-userspace в документации отсутствует. И, как показывает практика, userspace-версия ''не&nbsp; использует'' информацию о соединениях. Возможно, это обусловлено техническими ограничениями nfnetlink_queue как средства взаимодействия l7-filter с системой netfilter.

Описанный недостаток значительно снижает эффективность l7-filter  — ведь однозначно классифицированы могут быть всего несколько пакетов из каждого соединения, а всего в соединении могут быть миллионы и миллиарды пакетов. Соответственно, применение l7-filter по своему основному назначению  — классификация трафика для последующего [[w:Шейпинг (информатика) |шейпинга]]  — не оправдывает себя.

Для начала, запустим демон l7-filter-userspace. Небольшое замечание: в его конфигурационном файле (назовем его, например, <tt>l7-filter.conf</tt>) будем помечать протоколы метками в диапазоне от 16 до 31 включительно (почему  — станет понятно из дальнейших пояснений).

Параметр <tt>-f</tt> указывает путь к конфигурационному файлу, <tt>-q</tt>  — номер очереди, <tt>-m</tt>  — задает биты маркировки, модифицируемые демоном l7-filter (в нашем случае  — с первого по пятый, что соответствует диапазону значений маркировки от 0 до 31).

Добавлять второе из этих правил в цепочку POSTROUTING не стоило  — ведь в нее попадает как трафик, исходящий от самого хоста, так и транзитный трафик, который уже был обработан ранее, в цепочке PREROUTING. Посмотрев на диаграмму выше, вы можете убедиться, что приведенные правила обрабатывают весь трафик, как принадлежащий самому хосту, так и транзитный, за исключением локального. Локальный трафик (идущий через интерфейс [[w:Loopback |lo]]), бессмысленно шейпить, а значит, не стоит и классифицировать.

Поясним два момента. Во-первых, добавление этих правил в цепочки PREROUTING и OUTPUT, сразу после правил, передающих трафик демону l7-filter, не имеет смысла  — после обработки пакетов демон [http://l7-filter.sourceforge.net/HOWTO-userspace#Does применяет] к ним действие ACCEPT, прекращающее обработку пакета в рамках исходных цепочек. Поэтому мы добавляем эти правила в цепочки, идущие «ниже по течению». Как вы можете заметить по диаграмме выше, такая комбинация правил также обеспечивает обработку всего трафика.

Второй момент, который стоит пояснить  — маски специального вида. По сути, они позволяют проверить, лежит ли маркировка пакета в диапазоне от 16 до 31. Такая защита позволяет избежать обработки маркировок 0 (такую маркировку имеет локальный трафик, так как он не проходит процедуру анализа), 1 и 2 (эти значения маркировки, как уже было замечено выше, означают, что тип пакета не определен), а также 32 и выше (эти значения мы оставляем для других задач).

Как показывает [http://www.linux.org.ru/jump-message.jsp?msgid=3790164&cid=3791754 практика], даже в самом примитивном случае (детекция протокола {{w |HTTP}}, сервер  — {{w |nginx}} 0.6.32, клиент  — [http://www.hping.org/wbox/ wbox] 4), эффективность детекции возрастает  — без использования маркировки соединений регистрируются лишь 2 исходящих пакета (l7-filter работает на сервере), с использованием  — 3 исходящих и 2 входящих. Детальное исследование показывает, что детекции избегают лишь первые четыре пакета в соединении  — 2 SYN-пакета и 2 пакета с данными. Это цифры, характерные для тестовой задачи  — при передаче больших объемов данных количество детектированных пакетов будет значительно больше, в то время как количество не определенных пакетов сохранит тот же порядок.

Более того, предложенный метод решает задачу, не решенную даже в реализации l7-filter-kernel  — маркировка связанных соединений. Согласно документации iptables, маркировка соединений автоматически копируется с исходных соединений на связанные с ними (например, с управляющего {{w |FTP}}-соединения на соединение данных).

В качестве практического примера использования меток пакетов и соединений можно рассмотреть задачу [[w:Случайная величина |стохастической]] балансировки соединений между несколькими [[аплинк]]ами.

устанавливающие соответствие между внутренними номерами таблиц маршрутизации и их символьными именами. Используемые здесь имена prov1, prov2 и prov3, разумеется, условны. Таблица static  — особая, ее мы рассмотрим чуть ниже.

Обратите внимание, что это действие выполняется только один раз  — не надо повторять его при каждой загрузке системы!

Таблица static предназначена для обслуживания статических маршрутов. В частности, в нее мы занесем подсети провайдеров (предположим, что все они [[w:Бесклассовая адресация |класса 1C]]), а также наши внутренние локальные сети (если таковые есть):

Таким образом, если нашему хосту нужно будет обратиться в подсеть провайдера prov2 (208.77.189.0/24), то маршрут пойдет сразу через интерфейс eth1. Также в этой таблице присутствуют маршруты для наших внутренних локальных сетей  — с ними тоже все просто.

По сути дела, таблица static обычно содержит те же маршруты, что и таблица main (главная таблица маршрутизации), за исключением маршрута по умолчанию  — таких маршрутов у нас несколько и каждый из них размещается в отдельной таблице, выбор между которыми осуществляется на основании назначенной iptables/netfilter маркировки.

Заметим, что ни в таблицу static, ни в какие-либо другие таблицы не&nbsp; нужно вносить {{w |loopback}}-маршруты, например «127.0.0.1/8 dev lo», так как все эти маршруты фигурируют в автоматически создаваемой таблице local, которую любой пакет проходит в первую очередь (нетрудно убедиться в этом, посмотрев вывод команды «ip rule show»).

Reverse path filtering  — штука, конечно, удобная и полезная но, к сожалению, совершенно не совместимая с динамической маршрутизацией.

Если вы планируете использовать этот компьютер не&nbsp; только как [[w:Сетевой шлюз |шлюз]], и но и как интернет-{{w |сервер}} (то есть предоставлять доступ к нему извне), необходимо выполнить привязку входящих соединений к их интерфейсам&nbsp; — в противном случае могут возникнуть проблемы, если обращение извне придет через одного провайдера, а сервер ответит через другого.

Теперь, в сочетании с операцией <tt>-j CONNMARK --restore-mark</tt>, которой мы подвергнем исходящий с нашего сервера трафик (см. ниже), эта процедура обеспечит корректную обработку входящих соединений. (Отметим, что, если бы нам не нужно было бы балансировать исходящие соединения, мы могли бы обойтись вообще без помощи iptables/netfilter, выполнив привязку входящих соединений через правила вида <tt>ip rule add from 208.77.188.100 table prov1</tt> и  т. п.  — ответные пакеты всегда уходят с того же адреса, на который пришел запрос, так что в качестве критерия для выбора шлюза можно использовать исходный адрес.)

А теперь  — самое интересное. Используя описанный ниже критерий statistic, мы будем случайно распределять метки между пакетами.

Первое правило в этой цепочке пройдут все пакеты, вошедшие в нее. После этого, 34  % (примерно треть из них) покинет цепочку согласно второму правилу. Далее, оставшиеся пакеты (66  % от первоначального количества) получат маркировку 2. После этого половина из них (то есть 33  % от начального) покинут цепочку с этой маркировкой. Оставшаяся половина (тоже 33  % от начального количества) получат маркировку 3.

Через цепочку <tt>select_prov</tt> мы прогоняем только новые пакеты, то есть первые пакеты каждого соединения. После этой процедуры соединение уже имеет маркировку. К сожалению, на данный момент роутинговая подсистема ядра [[w:Ядро Linux |Linux]] не умеет маршрутизировать пакеты на основании маркировки соединения  — только на основании маркировки пакетов. Поэтому действием <tt>CONNMARK --restore-mark</tt> мы копируем маркировку соединений в маркировку пакетов.

Разумеется, при этом должна быть разрешена передача транзитного трафика, как в таблице filter, так и на уровне sysctl. Как это делается  — см. выше.

Заметим, что кроме алгоритма случайной балансировки, критерий statistic позволяет реализовать балансировку в режим [[w:Round-robin (алгоритм) |round robin]]. Для этого поменяем цепочку <tt>select_prov</tt> следующим образом:

Стоит обратить особое внимание на тот факт, что данный метод балансирует ''пакеты'', а не соединения. Например, в том случае, если вы хотите организовать выход в интернет из локальной сети через нескольких провайдеров, не имея единого внешнего адреса, этот метод может работать некорректно  — часть пакетов пройдет через одного провайдера и после операции {{w |NAT}} получит один исходный адрес, часть пойдет через другого и соответственно получит другой адрес, и в результате удаленные хосты не смогут правильно обрабатывать соединения, исходящие из вашей сети. Однако, в большинстве случаев этот негативный эффект нивелируется другим фактором  — кэшированием маршрутов. При прохождении через такое правило серии пакетов, адресованных некоторому хосту, действительно случайным выбор будет только для первого из них, после чего выбранный маршрут будет закэширован, и остальные пакеты к этому хосту будут маршрутизироваться через тот же шлюз. С одной стороны, подобный эффект позволяет соединениям корректно функционировать, с другой стороны  — балансировка оказывается не такой уж и случайной. К тому же, после очистки кэша маршрутов (например, посредством ввода команды <tt>ip route flush cached</tt>), работа существующих на этот момент соединений может быть нарушена. В качестве наиболее безопасного и целесообразного применения описанного метода можно привести задачу балансировки транзитного трафика в сетях без NAT (условия «прямой видимости» между балансирующим маршрутизатором и точкой схождения потоков трафика). В том случае, если доступ к шлюзам осуществляется через один сетевой интерфейс, этим методом можно балансировать и соединения, исходящие от самого хоста.

* '''limit'''  — позволяет ограничить количество пакетов в единицу времени. Параметры:

<tt>--limit ''количество''[/second|/minute|/hour|/day]</tt>  — задает ограничение на количество пакетов в секунду (second), минуту (minute), час (hour) или сутки (day). Пакеты в пределах этого количества считаются удовлетворяющими критерию, сверх этого количества  — не удовлетворяющими.

<tt>--limit-burst ''количество''</tt>  — задает длину очереди, то есть максимальную пропускную способность.

Критерий -limit использует модель «дырявого ведра», и --limit-burst задает «объем ведра», а --limit  — «скорость вытекания». Каждому такому критерию соответствует своя очередь, длина которой задается параметром --limit-burst. Если в очереди есть пакеты, то со скоростью, заданной в --limit, они покидают очередь и считаются удовлетворяющими критерию. Если же вся очередь занята, то новые пакеты в ней не регистрируются и считаются ''не'' удовлетворяющими критерию.

Типичная ошибка новичков  — использовать limit для ограничения TCP-трафика, например, так:

Это пример попытки защитить {{w |web-сервер}} от [[w:DoS-атака |DDoS-атаки]], ограничив количество пакетов в единицу времени. Однако, это правило не помешает без особого труда завалить сервер запросами (считая, что на один запрос требуется два входящих пакета  — SYN-пакет и пакеты данных, содержащий, например, только GET /, согласно спецификации HTTP 0.9). При этом могут возникнуть помехи для легальных пользователей, например, загружающих на сервер большой файл методом POST. Более корректным решением будет ограничивать не скорость входящего потока данных, а скорость открытия новых соединений:

* '''hashlimit'''  — позволяет применять ограничения, аналогичные критерию limit, к группам хостов, подсетей или портов, используя всего одно правило. При этом для каждого хоста, подсети или порта создается отдельная очередь. Можно задвать, например, такие критерии:

<tt>--hashlimit-mode {srcip|srcport|dstip|dstport}[,...]</tt>  — задает список контролируемых параметров: адреса (ip) и порты (port) источника (src) и назначения (dst). Например, если указать параметр

то будет создаваться отдельная очередь для каждой пары «адрес источника  — адрес назначения», то есть ограничение будет вводиться на количество пакетов, передаваемых с каждого хоста на другой хост (разумеется, если эти пакеты идут через наш сервер). Или, например,

<tt>--hashlimit-upto ''количество''[/second|/minute|/hour|/day]</tt>  — этот параметр задает скорость движения очереди (аналог <tt>--limit</tt>). Если пакеты поступают с такой же или меньшей скоростью, они считаются подпадающими под критерий. Обратите внимание, что этот параметр ''не'' поддерживает логической инверсии (отрицания) через восклицательный знак (см. ниже).

<tt>--hashlimit-above ''количество''[/second|/minute|/hour|/day]</tt>  — этот параметр таке задает скорость движения очереди, но смысл его противоположный  — если пакеты поступают с ''большей'' скоростью, они считаются подпадающими под критерий.

<tt>--hashlimit-burst ''количество''</tt>  — задает длину каждой очереди. Аналогичен <tt>--limit-burst</tt>.

<tt>--hashlimit-srcmask ''префикс''</tt>  — задает размер подсети исходных адресов, для которой вводится своя очередь. Имеет смысл, только если в haslimit-mode указан режим srcip. Как уже говорилось выше,

<tt>--hashlimit-dstmask ''префикс''</tt>  — задает размер подсети исходных адресов, для которой вводится своя очередь. Имеет смысл, только если в haslimit-mode указан режим dstip. Принцип использования аналогичен hashlimit-srcmask.

<tt>--hashlimit-name ''имя''</tt>  — позволяет использовать несколько независимых таблиц очередей (hashes), распознаваемых по имени. Обязательный параметр. Например,

Критерий haslimit также имеет ряд параметров, не описанных здесь (максимальный размер таблицы, время жизни записи в таблице, интервал [[w:Сборка мусора (программирование) |«сбора мусора»]], и  т.  п.). За подробными сведениями обратитесь к документации.

* '''connlimit'''  — позволяет ограничивать количество одновременно открытых соединений с каждого IP-адреса (или подсети). Параметры:

<tt>[!] --connlimit-above количество</tt>  — минимальное количество соединений. Все пакеты, проходящие по соединениям, установленным сверх заданного количества, считаются удовлетворяющими критерию. Например,

<tt>--connlimit-mask</tt>  — маска подсети, для которой устанавливается общее ограничение на количество соединений. Например,

разрешит не более пяти одновременных соединений на порт 80 с каждой подсети [[w:Бесклассовая адресация |класса 1C]].

Не надо путать connlimit с hashlimit  — hashlimit позволяет ограничить ''скорость'' поступления пакетов с хостов или подсетей (в сочетании с <tt>-m conntrack --ctstate NEW</tt>  — скорость открытия новых соединений), а connlimit  — ''количество'' одновременно открытых соединений.

* '''connbytes'''  — позволяет ограничивать количество переданных байт или пакетов. Параметры:

<tt>[!] --connbytes ''мин'':[''макс'']</tt>  — собственно задает количество пакет или байт. Можно указать просто минимальное количество или диапазон.

<tt>--connbytes-dir {original|reply|both}</tt>  — задает направление движения пакетов. Проверяются только пакеты, движущиеся от инициатора соединения к отвечающему (original), наоборот (reply) или в обоих направлениях (both).

<tt>--connbytes-mode {packets|bytes|avgpkt}</tt>  — задает собственно учитываемую величину: количество пакетов (packets), количество байт (bytes) или средний размер пакета (avgpkt).

Таким образом, все пакеты, принадлежащие «легким» соединениям, будут маркироваться как наиболее приоритетные, а пакеты, проходящие по «тяжеловесным» соединениям  — как наименее приоритетные. Такой подход позволит рационально распределять канал между различными задачами, например, просмотром веб-страниц («легкие» соединения) и скачиванием файлов («тяжелые» соединения).

Конечно, при таком подходе даже «тяжелые» соединения будут занимать канал с наивысшим приоритетом, пока не превысят ограничение. Но даже на медленных соединениях (128 Кбит/с) для этого достаточно всего четырех секунд (если эта закачка в данный момент единственная). После превышения лимита 50 Кбайт соединение получит средний приоритет ([[w:Тип обслуживания |TOS]] не установлен), а еще через некоторое время соединение превысит второй лимит  — 500 Кбайт, и получит минимальный приоритет. В то же время, «легкие» соединения в большинстве случаев не превышают даже первого лимита, и поэтому целиком проходят с повышенным приоритетом.

* '''quota'''  — позволяет задать квоту в байтах для данного конкретного правила. Имеет единственный параметр

<tt>--quota количество_байт</tt>  — собственно задает квоту.

* '''quota2'''  — критерий из уже упоминавшегося набора xtables-addons. Является результатом развития идей, заложенных в критерии quota. Позволяет создавать именованные счетчики квот (для совместного использования одного счетчика в нескольких правилах), считать не только байты, но и пакеты, а также создавать отдельные правила для пакетов, превышающих квоту (логическая инверсия параметра <tt>--quota</tt>). Поддерживаются следующие параметры:

<tt>--name ''имя''</tt>  — задает имя счетчика. Текущее значение счетчика содержится в файле <tt>/proc/net/xt_quota/''имя''</tt>. Его можно вывести на экран

Для осуществления этих действий, как и для работы с iptables, нужны полномочия [[w:Root |суперпользователя]].

<tt>[!] --quota ''количество''</tt>  — проверяет текущее значение счетчика и уменьшает его на размер текущего пакета. Этот же параметр задает начальное значение счетчика (если счетчик с таким именем уже существует, он не сбрасывается). Пакет считается подпадающим под критерий, если счетчик еще не дошел до нуля (при указании логической инверсии  — наоборот). Если немного усложнить наш предыдущий пример,

<tt>--packets</tt>  — при указании этого параметра счетчик учитывает количество пакетов, а не их суммарный размер.

<tt>--grow</tt>  — ''увеличивает'' счетчик, вместо того, чтобы уменьшать его. Критерий с этим параметром всегда возвращает истину. Позволяет создавать счетчики «приходно-расходного типа». Например,

Обратите внимание, что при указании параметра grow критерий quota2 ''всегда'' будет возвращать истину. Действие для такого правила обычно назначать не имеет смысла  — правило изменяет только счетчик квоты, а не сам пакет.

* '''length'''  — позволяет использовать в качестве критерия размер пакета. Проверятся размер пакета протокола транспортного уровня ({{w |TCP}}, {{w |UDP}}, {{w |SCTP}}, {{w |DCCP}} и  т.  д.) или, иначе говоря, размер пакета протокола сетевого уровня ({{w |IP}}, {{w |IPv6}}) за вычетом размера заголовков сетевого уровня. Данный критерий имеет единственный параметр

: <tt>--length ''размер''</tt>  — пакет проверяется на точное соответствие заданному размеру,

: <tt>--length ''мин_размер'':</tt>  — размер пакета должен быть больше или равен заданной величине,

: <tt>--length :''макс_размер''</tt>  — размер пакета должен быть меньше или равен заданной величине,

: <tt>--length ''мин_размер'':''макс_размер''</tt>  — размер пакета должен попадать в указанный диапазон (включая границы).

В качестве практического примера использования данного критерия можно рассмотреть установку высокого приоритета [[w:Тип обслуживания |TOS]] (требование минимальной задержки) для небольших транзитных пакетов (размер до 512 байт):

* '''length2'''  — расширение критерия length, доступное в наборе xtables-addons. Отличается от классического length возможностью проверять размеры пакетов на различных уровнях [[w:Сетевая модель OSI |модели OSI]]. Принимает следующие опции:

<tt>--layer3</tt>  — проверка размера пакета сетевого уровня (например, IPv4-пакета).

<tt>--layer4</tt>  — проверка размера пакета транспортного уровня (например, TCP-пакета).

<tt>--layer5</tt>  — проверка размера полезной нагрузки транспортного уровня (например, содержимого TCP-пакета, ''не''&nbsp; учитывая размер заголовков TCP). Работает корректно только для некоторых протоколов транспортного уровня, на момент написания этих строк (конец 2009) поддерживаются: {{w |TCP}}, {{w |UDP}}, [[UDPLite]] ([[:en:UDPLite|en]]), {{w |ICMP}}, {{w |ICMPv6}} ([[:en:ICMPv6|en]]), {{w |DCCP}}, {{w |SCTP}}, {{w |IPSec}} (AH и ESP). Для {{w |SCTP}}-пакета в этот размер включаются все [[:en:SCTP_packet_structureSCTP packet structure|секции (chunks)]] вместе с их заголовками.

<tt>--layer7</tt>  — для SCTP проверяется суммарный размер DATA-секций в пакете (то есть его полезная нагрузка), для остальных протоколов аналогично <tt>--layer5</tt>.

Это ''не''&nbsp; является ошибкой (только предупреждением о возможной неоднозначности). Заданное вами правило должно добавиться успешно.

<tt>[!] --length ''размер''[:''макс_размер'']</tt>  — собственно, задает нужные значения размера. В отличие от аналогичного параметра в классическом критерии length, его синтаксические формы несколько беднее. Допускаются два варианта записи:

: <tt>--length ''размер''</tt>  — пакет проверяется на точное соответствие заданному размеру,

: <tt>--length ''мин_размер'':''макс_размер''</tt>  — размер пакета должен быть попадать в указанный диапазон (включая границы).

Будьте внимательны: в отличие от length, length2 не&nbsp; проверяет взаимное соответствие границ диапазона (<tt>''мин_размер'' <= ''макс_размер''</tt>), и если вы зададите их неправильно (<tt>''мин_размер'' > ''макс_размер''</tt>), ваше правило просто никогда не&nbsp; будет срабатывать. <!-- По крайней мере в xtables-addons 1.21 этот баг присутствует. -->

'''Подводя краткий итог по разделу «Лимитирующие критерии»''', хотелось бы заметить, что перечисленные в этом разделе критерии предназначены главным образом для ограничения доступа и защиты от различных атак. Не&nbsp; стоит пытаться ограничивать с их помощью трафик. Для ограничения и приоритезации трафика в [[Linux]] рекомендуется использовать стандартный [[w:Шейпинг (информатика) |шейпер]] ядра, управляемый при помощи утилиты [[w:Iproute2 |tc]].

<!-- Если же вам нужно ограничить именно трафик, а не отдельные пакеты или соединения, то рекомендуем использовать для этого [[w:Шейпинг (информатика) |шейпер]]. Управление шейпером ядра Linux производится при помощи утилиты [[w:Iproute2 |tc]]. Впрочем, этот шейпер позволяет эффективно управлять лишь исходящим трафиком.-->

<tt>[!] --set</tt>  — запомнить адрес источника/назначения пакета (внести его во внутренний список). Если такая запись уже присутствует в списке  — обновить время последнего доступа для нее. Обратите внимание, что критерию recent с опцией <tt>--set</tt> удовлетворяют ''все'' пакеты. Чтобы ему не удовлетворял ни один пакет  — используйте логическую инверсию (<tt>! --set</tt>).

<tt>[!] --rcheck</tt>  — позволяет проверить, присутствует ли адрес источника/назначения пакета во внутреннем списке. Критерий recent с этой опцией вернет истину, если адрес в списке присутствует.

<tt>[!] --update</tt>  — работает аналогично <tt>--rcheck</tt>, но еще и обновляет время последнего доступа для данной записи.

<tt>[!] --remove</tt>  — работает аналогично <tt>--rcheck</tt>, но еще и удаляет найденную запись из списка. Если запись не найдена, пакет считается ''не''&nbsp; соответствующим критерию.

<tt>--seconds ''число''</tt>  — дополнительная опция в режимах <tt>--rcheck</tt> и <tt>--update</tt>. Пакет считается соответствующим критерию, только если последний доступ к записи был не позднее, чем ''число'' секунд назад.

<tt>--hitcount ''число''</tt>  — дополнительная опция в режимах <tt>--rcheck</tt> и <tt>--update</tt>. Пакет считается удовлетворяющим критерию, если было не менее ''число'' обращений к данной записи. Обычно используется вместе с <tt>--seconds</tt>  — тогда критерий имеет смысл «не менее n обращений за последние m секунд».

Заметим, что, хотя в официальной документации для параметров <tt>--seconds</tt> и <tt>--hitcount</tt> указывается возможность отрицания (указания перед ними восклицательного знака), на самом деле такое отрицание никак не&nbsp; обрабатывается в коде и не&nbsp; меняет смысла параметров, так что указывать его бессмысленно. Эта ошибка в документации исправлена в версии iptables 1.4.7.

<tt>--rttl</tt>  — дополнительно к адресу источника/назначения, заносить в список и проверять еще и [[w:Time to live |TTL]] пакета.

<tt>--rsource</tt>  — эта опция появилась в последних версиях iptables, с тех пор, как критерий recent начал поддерживать запоминание адресов не только источника, но и назначения. Позволяет явно указать, что в список вносится именно адрес источника пакета. Однако в целях обратной совместимости этот режим используется по умолчанию, и поэтому указывать данную опцию не обязательно.

<tt>--rdest</tt>  — эта опция появилась в последних версиях iptables. Позволяет явно указать, что в список вносится именно адрес назначения пакета.

<tt>--name ''имя''</tt>  — позволяет указать имя списка при использовании нескольких списков. По умолчанию используется список DEFAULT. Каждый список представлен псевдофайлом <tt>/proc/net/xt_recent/''имя''</tt> (на старых ядрах критерий recent реализован только для {{w |IPv4}}, но не&nbsp; для {{w |IPv6}}, поэтому вместо <tt>xt_recent</tt> будет <tt>ipt_recent</tt>). В частности, вы можете:

Теперь все попытки открыть новое SSH-соединение проверяются, и с одного {{w |IP-адрес}}а можно открывать не более 2 соединений за 10 минут. Обратите внимание, что за одно соединение злоумышленник может проверить несколько паролей  — число попыток аутентификации до обрыва соединения задает параметр MaxAuthTries в файле <tt>/etc/ssh/sshd_config</tt>. По умолчанию это число равно 6, так что в нашем примере злоумышленник сможет проверять не более 12 паролей за 10 минут.

Данная реализация имеет недостаток по сравнению с recent  — вы не можете произвольно задавать временной период.

Проводя аналогию с ныне почившим проектом [http://www.opennet.ru/docs/RUS/portsentry/portsentry-security.html.gz PortSentry], первый наш пример соответствует режиму PortSentry «Advanced Stealth Scan Detection», а второй  — «Enhanced Stealth Scan Detection». (Правда, заметим, что в режиме Advanced Stealth Scan Detection блокировка производится после ''первого'' попадания пакета на нерабочий порт&nbsp; — для достижения такого же эффекта в нашем примере достаточно выкинуть проверки на seconds и hitcount из блокирующих правил.) Однако, использование iptables/recent имеет значительное преимущество перед примитивными userspace-системами наподобие PortSentry&nbsp; — возможность интеграции с системой [[conntrack]], что позволяет избежать ошибочной блокировки, например, при использовании высоких портов для {{w |NAT}}.

Port knocking  — метод защиты портов, при котором доступ к определенному порту с отдельно взятого IP-адреса открывается после серии пакетов на заданную последовательность портов с заданными интервалами. <!-- Обычно эта задача решается демоном [[knockd]]. Также сходной функциональностью обладает критерий [http://www.netfilter.org/projects/patch-o-matic/pom-external.html#pom-external-pknock pknock] из [http://www.netfilter.org/projects/patch-o-matic/pom-external.htm patch-o-matic-ng], однако он, к сожалению, потерял разработчика и прекратил развиваться.--> Обычно эта задача решается при помощи демона [[knockd]] либо критерия pknock из комплекта xtables-addons.

Самое простое  — открывать порт ssh (22) после стука в заданный высокий порт:

Принцип прост  — при стуке в порт, соответствующий очередной фазе, проверяется наличие записи в предыдущей фазе. Теперь порт 22 откроется на 5 секунд после стука в порты 21210, 11992, 16043, 23050 со строгим соблюдением порядка перечисления и интервалами не более 5 секунд.

Обратите внимание на технику реализации процесса  — цепочки фаз вызываются не через <tt>-j</tt>, а через <tt>-g</tt>, поэтому после прохождения этих цепочек к пакетам сразу применяется правило по умолчанию цепочки INPUT, то есть DROP. В противном случае пакеты доходили бы до правила сброса (которое с multiport), и процесс стука все время сбрасывался бы.

* '''='''  — оператор сравнения. Собственно, на его основе и формируются все производимые проверки. Синтаксис его вполне очевиден: <tt>выражение = значение</tt>. В качестве значения можно использовать одно число, диапазон (в формате <tt>мин:макс</tt>) или список чисел и/или диапазонов разделенных запятой (например, <tt>1,3:5,8,11:14</tt>). В одном списке можно указывать не более 10 чисел/диапазонов.

* '''&&'''  — оператор логического И, объединяющий все производимые в программе проверки. В одном критерии u32 можно указывать не более 10 таких проверок. Обратите внимание, что операция логического ИЛИ отсутствует, так как это противоречит идеологии iptables (в каждом правиле все проверки объединяются логическим И, а логическое ИЛИ объединяет правила в одной цепочке).

* '''&'''  — оператор побитового логического И, позволяющий применить к обрабатываемому значению битовую маску.

* '''<<«''' и '''>>»'''  — операторы побитового сдвига влево и вправо соответственно. Эквивалентны домножению или делению обрабатываемого значения на 2 в соответствующей степени. Обратите внимание, что в одном выражении для проверки можно использовать не более 9 операторов &, << и >>.

* '''@'''  — оператор задания смещения. Добавляет результат предыдущего выражения к текущему значению начального смещения (в начале работы программы, до выполнения @-операций, начальное смещение считается нулевым). Очень полезен в тех случаях, когда нужно сместиться на некоторое значение, полученное в результате обработки пакета, например, узнав после некоторых вычислений длину IP-заголовка, мы можем сместиться на данные непосредственно после него, т.е.то есть на начало полезной нагрузки IP-пакета (как правило, там находится заголовок [[w:Транспортный уровень |транспортного уровня]]).

Обратите внимание, что программа рассматривает все значения как целые беззнаковые величины, заданные 32 битами, или четырьмя октетами (что соответствует значениям от 0 до 4294967295). Именно поэтому критерий имеет такое название (u32  — unsigned 32-bit).

Другой не вполне очевидный момент  — синтаксис операторов =, &, << и >>. Дело в том, что в качестве первого операнда указывается не само значение, а его ''адрес'' в пределах пакета, заданный смещением в байтах от текущего начального смещения. Например, <tt>8 = 0x12345678</tt> означает, что нужно взять четыре байта, начиная с восьмого (обратите внимание, что нумерация байтов в пакете начинается с нуля), т.е.то есть байты 8, 9, 10 и 11, и сравнить полученное значение с шестнадцатеричным числом 0x12345678. Как уже говорилось, критерий u32 ''всегда'' манипулирует блоками по четыре байта, поэтому, если вас интересуют блоки меньшего размера, используйте оператор & и маску, например, <tt>8 & 0xFF = 0x78</tt> позволяет проверить только последний в блоке (11-й от начального смещения) байт. Также можно использовать и оператор смещения, например, <tt>8 >> 24 = 0x12</tt> возьмет первый в блоке (8-й от начального смещения) байт и сравнит его с числом 0x12. Более подробно о битовых операциях можно почитать в [[w:Битовые операции |соответствующей статье]].

Эта программа предписывает взять четыре байта, начиная с нулевого, затем занулить первые два байта (в них [[w:IP#Пакет (датаграмма) |содержится]] информация о версии протокола, длине заголовка и [[w:Тип обслуживания |типе обслуживания]], которая нас сейчас не интересует), и проверить значение, формируемого оставшимися двумя байтами (это и есть полная длина пакета в байтах) на принадлежность диапазону от 0x100 (256 в десятичном счислении) до 0xFFFF (65535, максимально возможная длина пакета).

:* '''6 & 0xFF = 1'''  — проверка кода протокола. Код протокола хранится в 9-м (считая с нуля) байте IPv4-заголовка. Чтобы получить это значение, мы берем 4-х байтовый блок с шестого по девятый байт, а затем при помощи маски выделяем последний, интересующий нас байт в это блоке, и сравниваем его с единицей (код протокола ICMP).

:* '''4 & 0x3FFF = 0'''  — проверка, не является ли наш пакет фрагментом. Фрагменты ICMP-пакетов не содержат ICMP-заголовка, в котором должен храниться тип ICMP, поэтому для них дальнейшая проверка не имеет смысла. Пользуясь описанным выше принципом, наша программа выделяет последние 14 бит в блоке с 4-го по 7-й байт, и сравнивает полученное значение с нулем. Строго говоря, для наших целей достаточно было бы и 13 бит (маска 0x1FFF), выделяющих только поле смещения фрагмента (fragment offset, оно должно быть равным нулю для первого пакета в цепочке фрагментов), а использование 14 бит, как это сделано в примере из официальной документации, также захватит и флаг MF (more fragments), что отсечет вообще все фрагментированные пакеты, даже те, которые являются первыми в последовательности и содержат все нужные нам заголовки.

:* '''0 >> 22 & 0x3C @'''  — определение длины IP-заголовка в байтах. Последние четыре бита в первом байте IP-пакета показывают длину IP-заголовка в блоках по четыре байта. Смещая это значение на 22 позиции вправо, мы оставляем справа «зазор» в два бита, которые впоследствии зануляем при помощи маски (3C₁₆ = 111100₂). Также эта маска отсекает лишние биты слева (версия протокола). Полученные два нулевых бита справа соответствуют умножению на четыре, так что в результате мы получаем длину заголовка уже в байтах. Например, если длина IP-заголовка составляет 5 четырехбайтовых блоков (т.е.то есть 20 байт), то изначально первый блок заголовка имеет вид <tt>xxxx0101 yyzzzzzz uuuuuuuu uuuuuuuu</tt> (где биты <tt>xxxx</tt> задают версию протокола, 0101₂=5₁₀­  — собственно длину заголовка, <tt>yyzzzzzz</tt>  — тип обслуживания, а два байта <tt>uuuuuuuu uuuuuuuu</tt> показывают полную длину пакета вместе с нагрузкой), то после смещения вправо на 22 бита мы получим в этом блоке следующую картину: <tt>00000000 00000000 000000xx xx0101yy</tt>. После применения маски она пример вид <tt>00000000 00000000 00000000 00010100</tt>. Полученное число  — 10100₂=20₁₀ и будет равно длине заголовка в байтах. Наконец, оператор @ устанавливает полученное значение в качестве начального смещения, поэтому вся дальнейшая адресация ведется уже начиная с начала ICMP-заголовка, который следует непосредственно после IP-заголовка.

:* '''0 >> 24 = 0'''  — выделяет блок с нулевого по третий байт ICMP-заголовка, а затем при помощи смещения (на три байта вправо) оставляет от него только один, нулевой, байт, в котором и хранится тип ICMP. Нас интересует тип 0, поэтому мы и сравниваем этот байт с нулем.

:* '''6 & 0xFF = 6'''  — выделение байта с кодом протокола и сравнение его с кодом 6 (соответствует TCP). Описание этой проверки уже приведено при рассмотрении предыдущего примера.

:* '''4 & 0x3FFF = 0'''  — проверка, не является ли данный пакет фрагментом. Полностью аналогична описанной в предыдущем примере.

:* '''0 >> 22 & 0x3C @'''  — определение длины IP-заголовка в байтах. Также полностью аналогично описанному в предыдущем примере. После данной операции, начальное смещение указывает на нулевой байт TCP-заголовка.

:* '''12 >> 26 & 0x3C @'''  — определение длины TCP-заголовка в байтах. Принцип действия аналогичен предыдущей операции, с тем лишь отличием, что длина TCP-заголовка закодирована в первых четырех битах двенадцатого байта (а не в последних четырех битах нулевого байта, как в случае с IP-заголовком), поэтому необходимое нам смещение вправо составляет уже 26 бит. Как и в предыдущей операции, мы оставляем справа зазор в два бита, которые впоследствии зануляем маской, и таким образом сразу получаем длину заголовка в байтах. Итак, после второго оператора @, начальное смещение будет указывать на начало полезной нагрузки TCP-пакета (следует непосредственно после заголовка).

:* '''8 = 1,2,5,8'''  — эта операция сравнения вполне тривиальна: выделяется четырехбайтовый блок, начиная с восьмого байта (разумеется, считая от начала полезной нагрузки), и полученное значение сравнивается с одним из допустимых по условию задачи.

Также, в качестве полезных примеров использования критерия u32, можно упомянуть проверку портов источника и назначения в протоколе [[UDPLite]] ([[:en:UDPLite|en]]): <tt>--u32 "6 & 0xFF = 136 && 4 & 0x3FFF = 0 && 0 >> 22 & 0x3C @ 0 >> 16 = исходный_порт"</tt> и <tt>--u32 "6 & 0xFF = 136 && 4 & 0x3FFF = 0 && 0 >> 22 & 0x3C @ 0 & OxFFFF = порт_назначения"</tt> соответственно (после сказанного выше нетрудно догадаться, что исходный порт указывается в первой паре байт UDPLite-заголовка, а порт назначения  — во второй, согласно [http://tools.ietf.org/html/rfc3828 RFC3828]).

* -F - — Удалить все правила из цепочки

* -L - — Просмотреть цепочку

* -Z - — Обнулить счётчики пакетов в цепочке

* -A - — добавить правило в конец

* -С - — проверить, что такое правило есть в таблице

* -D - — удалить правило по описанию или по rulenum

* bitmap: ip  — список IP адресов из определенной подсети

* bitmap: ip,mac mac — связки IP+MAC

* bitmap: port  — список портов

* hash: ip  — произвольный набор IP

* hash: net  — произвольный набор сетей

* hash: mac

* hash: net, net

* hash: ip, port

* hash: net, port

* hash: ip, port, ip

* hash: ip, port, net

* hash: ip, mark

* hash: net, port, net

* hash: net, iface

* list: set

--><blockquote>iptables -L -n -v #Статистика всех правил iptables и счетчики обработанных пакетов<br>

[http://www.117.su iptadmin] - — это пользовательский web интерфейс для iptables, редактор настроек файрволла операционной системы Linux. Реализован в виде отдельного http(s) сервера.

Программа позволяет задать правила, которым должны соответствовать проходящие через [[w:Межсетевой экран |брандмауэр]] [[IP-пакет]]ы. Эти правила, как и все настройки [[Linux]], записываются в текстовый файл, находящийся в папке /etc. Последовательность правил называется цепочкой (CHAIN). Для одного и того же сетевого интерфейса используются несколько цепочек. Если проходящий пакет не соответствует ни одному из правил, то выполняется действие по умолчанию.

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

Ограничение отправителя. Адрес может быть {{w |IP-адрес}}ом (возможно с [[w:Маска подсети |маской]]), именем хоста, или доменным именем. Маска может быть в стандартном формате (например 255.255.255.0) или же в виде числа, указывающего число единиц с «левой стороны» маски (например 24). Знак «!» перед адресом изменяет критерий на противоположенный.

NEW  — типов пакетов, участвующих в установке нового соединения.

ESTABLISHED  — пакет уже установленного соединения

RELATED  — Соединение получает статус RELATED если оно связано с другим соединением, имеющим признак ESTABLISHED. Это означает, что соединение получает признак RELATED тогда, когда оно инициировано из уже установленного соединения, имеющего признак ESTABLISHED.

INVALID  — неправильный/ошибочный/испорченный пакет. Обычно для таких пакетов применяют действие DROP

<tt>[!] --connlimit-above n</tt>  — пакет подойдет под описание, если количество одновременных подключений на данный момент больше (меньше), чем n

<tt>--connlimit-mask bits</tt>  — позволяет задать маску блока адресов

* [http://security.maruhn.com/iptables-manual.html Man page of iptables] {{ref-en}}

* [http://wiki.archlinux.org/index.php/Simple_stateful_firewall_HOWTO#Prerequisites Простой полноценный межсетевой экран (готовый шаблон для дектопа)] {{ref-en}}

* {{Unix man |iptables|8}} {{ref-en}}

* {{Unix man |ufw|8}} {{ref-en}}

* {{Unix man |gufw|8}} {{ref-en}}

* https://help.ubuntu.com/community/IptablesHowTo {{ref-en}}

* https://help.ubuntu.com/community/UFW {{ref-en}}

* https://help.ubuntu.com/community/Gufw {{ref-en}}

* https://help.ubuntu.com/9.10/serverguide/C/firewall.html {{ref-en}}

* https://wiki.ubuntu.com/UncomplicatedFirewall {{ref-en}}

* https://help.ubuntu.com/community/Firewall {{ref-en}}