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

|programming_language = [[w:Си (язык программирования) |C]]

|operating_system = часть [[w:Ядро Linux (ядро)|ядра Linux]]

|genre = [[{{w |Межсетевой экран]]}}

|license = [[w:GNU General Public License |GNU GPL]]

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

Изначально разработка netfilter и iptables шла совместно, поэтому в ранней истории этих проектов есть много общего. Подробности см. в статье про [[{{w |netfilter]]}}.

Предшественниками iptables были проекты [[{{w |ipchains]]}} (применялась для администрирования фаервола ядра Linux версии 2.2) и [[ipfwadm]] (аналогично для ядер Linux версий 2.0). Последний был основан на [[{{w |BSD]]}}-утилите [[{{w |ipfw]]}}.

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

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

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

Userspace-утилита, через которую [[w:Root (суперпользователь)|системный администратор]] может управлять [[{{w |IPv4]]}}-фаерволом (ip_tables). К ее задачам относятся:

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

Сегментом фаервола, отвечающим за фильтрацию [[{{w |IPv6]]}}-пакетов (ip6_tables), управляет утилита ip6tables. Так как обычно она поставляется вместе с iptables, имеет похожий синтаксис и выполняет схожие задачи, под термином «iptables» часто подразумевают сразу обе эти утилиты.

* '''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 |скрипт]]}}ов.

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

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

Более подробно о возможностях системы conntrack и их использовании при работе с iptables/netfilter см. [[iptables#Механизм определения состояний|чуть ниже]].

* Главный модуль nf_conntrack. Реализует базовую функциональность отслеживания соединений, интерфейсы для работы с модулями расширений, а также механизмы отслеживания протоколов [[{{w |TCP]]}} и [[{{w |UDP]]}}.

* Трекеры протоколов [[Сетевой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 и т. п. Требуются далеко не для всех протоколов, а только для тех, отслеживание которых требует знания специфики протокола. Например, неоднократно упоминающийся в этой статье протокол [[{{w |FTP]]}} использует в одном сеансе два соединения (управляющее соединение и соединение передачи данных), и чтобы корректно отследить соединение передачи данных, необходимо анализировать трафик управляющего соединения и выделять в нем информацию, касающуюся открытия соединения данных.

* Модуль nf_nat. Реализует базовую функциональность [[w:NAT |трансляции сетевых адресов]] и [[w:Трансляция порт-адрес |портов]] с учетом информации о соединениях. Также этот модуль содержит механизмы трансляции для протоколов [[{{w |IPv4]]}}, [[{{w |TCP]]}}, [[{{w |UDP]]}} и [[{{w |ICMP]]}} ([[{{w |IPv6]]}} и [[{{w |ICMPv6]]}} не поддерживаются 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), практически все действия [[iptables#Таблица nat|таблицы nat]], а также соответствующие модули (библиотеки iptables/ip6tables): libxt_conntrack, libxt_NOTRACK, libxt_CT и т. п.

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

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

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

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

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

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

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

В версии ipset 4 и более ранних поддерживалась работа только с семейством адресов [[{{w |IPv4]]}}, однако начиная с пятой версии реализована также и поддержка [[{{w |IPv6]]}}.

Стоит отметить, что долгое время проект ipset существовал вне основной ветки развития [[w:Ядро Linux (ядро)|ядра Linux]]. В частности, в четвертой версии ipset «ядерные» компоненты приходилось собирать отдельно, используя заголовочные файлы текущего ядра. Однако, после выхода пятой версии, в которой были учтены все предыдущие замечания, началась работа по включению ipset в основную ветку. Она [http://www.spinics.net/lists/netfilter-devel/msg17027.html завершилась успехом]: поддержка ipset присутствует в Linux начиная с 2.6.39. В ходе этих работ протокол взаимодействия ядерной и userspace-частей ipset подвергся значительной переработке, и окончательная версия [http://git.netfilter.org/cgi-bin/gitweb.cgi?p=ipset.git;a=commit;h=d6ee5bb4e5346b84efa33858091ba4add2b26de2 получила] номер 6.0. Таким образом, в современных ядрах поддержка ipset присутствует штатно, а пользователи более старых ядер могут воспользоваться реализациями ipset версий 4 и 5, включенными в набор [http://xtables-addons.sourceforge.net/ xtables-addons].

* Модули расширений для утилиты 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:Порт (TCP/IPкомпьютерные сети) |порты]] источника и/или получателя) на предмет нахождения или отсутствия в списке. Действие 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. -->

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

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

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

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

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

Большинство перечисленных типов данных можно разделить на две группы: полные перечни (map, bitmap) и выборочные перечни (hash, tree). Разница между этими типами состоит в следующем: если выборочный перечень сохраняет только те элементы, которые в него входят, то полный перечень представляет собой таблицу логических значений ([[{{w |бит]]}}ов) для всех элементов, которые могут входить в данный перечень, и вхождение конкретного элемента в перечень определяется значением соответствующего бита. Полный перечень всегда формируется на базе ''одного непрерывного'' диапазона значений.

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

Разработанный в рамках проекта [http://www.linuxvirtualserver.org/ Linux Virtual Server] инструментарий для балансировки входящих соединений на [[w:Транспортный уровень |транспортном уровне]], позволяющий создавать отказоустойчивые (highly available, HA) [[w:Кластер (группа компьютеров) |кластеры]] с балансировкой нагрузки. В структуру такого кластера входит один или несколько хостов-балансировщиков (front-end), а также группа хостов-обработчиков (back-end). Хост-балансировщик принимает входящие соединения и перенаправляет их на хосты-обработчики, причем выбор хоста-обработчика осуществляется по специальному алгоритму, обеспечивающему гибкое распределение нагрузки между обработчиками. В кластере также могут присутствовать дополнительные (резервные) балансировщики, которые вступают в игру в случае отказа основного балансировщика.

Как уже упоминалось выше, IPVS обеспечивает балансировку нагрузки на транспортном уровне, т.е. конфигурационной единицей IPVS является ''кластерная служба''. Она характеризуется адресом ([[{{w |IPv4]]}} или [[{{w |IPv6]]}}), протоколом транспортного уровня (на данный момент IPVS поддерживает протоколы [[{{w |TCP]]}}, [[{{w |UDP]]}} и [[{{w |SCTP]]}}) и номером [[w:Порт (TCP/IPкомпьютерные сети) |порта]]. Обычно для кластерных служб выделяется отдельный адрес, который присваивается активному (на данный момент) балансировщику. В случае его отказа, адрес автоматически передается резервному балансировщику, и кластер продолжает работу. Обратите внимание, что обеспечением отказоустойчивости занимается не IPVS, а keepalived. Впрочем, использование keepalived не является строго обязательным — существуют и альтернативные подходы, например, встраивание IPVS в кластерный стек [http://linux-ha.org/ Linux-HA] (см. [[:en:Heartbeat (program)|Heartbeat]]). В том случае, если отказоустойчивость не критична (требуется только балансировка нагрузки), можно вообще обойтись без дополнительного демона, выполняя всю настройку через ipvsadm.

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

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

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

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

Для отслеживания соединений к кластерным службам IPVS использует собственную систему трекинга соединений, более примитивную, но менее ресурсоемкую, нежели классический conntrack. При этом поддерживается экспорт информации о кластерных соединениях в conntrack, в целях обеспечения их корректной обработки фаерволом и трансляции адресов (при трансляции адресов используются штатные средства netfilter). Однако, для корректной обработки протоколов, использующих связанные соединения (например, [[{{w |FTP]]}}), IPVS использует возможности conntrack. Синхронизация таблицы соединений между основным и дублирующими балансировщиками полностью реализована на уровне ядра (для сравнения, в conntrack эту задачу выполняет userspace-демон conntrackd).

Важной особенностью iptables/[[{{w |netfilter]]}} является механизм определения состояний (connection tracking, nf_[[conntrack]]) — специальная подсистема, отслеживающая состояния соединений и позволяющая использовать эту информацию при принятии решений о судьбе отдельных пакетов. Наличие этого механизма делает netfilter полноценным stateful-фаерволом.

Определение состояния соединения порою бывает довольно сложной задачей. Скажем, в случае [[{{w |TCP]]}} все относительно просто — контроль состояний реализован средствами самого протокола, установлены специальные процедуры открытия и закрытия соединения. А вот в протоколе [[{{w |UDP]]}} для этого специальных процедур не предусмотрено, поэтому UDP-соединением с точки зрения [[conntrack]] является поток пакетов, следующих с интервалом, не превышающим заданный тайм-аут ([[{{w |sysctl]]}}-параметр <tt>net.netfilter.nf_conntrack_udp_timeout</tt>, по умолчанию 30 секунд), с одного и того же порта одного хоста, на один и тот же порт другого хоста.

Существует также понятие «связанных соединений». Например, когда в ответ на [[{{w |UDP]]}}-пакет с нашего хоста удаленный хост отвечает [[{{w |ICMP]]}}-пакетом icmp-port-unreachable, формально этот ответ является отдельным соединением, так как использует совсем другой протокол. [[{{w |netfilter]]}} отслеживает подобные ситуации и присваивает таким соединениям статус «связанных» (RELATED), позволяя корректно пропускать их через фильтры фаервола.

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

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

При помощи [[iptables#conntrack_2|критерия conntrack]] вы можете классифицировать пакеты на основании их отношения к соединениям. В частности, состояние NEW позволяет выделять только пакеты, открывающие новые соединения, состояние ESTABLISHED — пакеты, принадлежащие к установленным соединениям, состоянию RELATED соответствуют пакеты, открывающие новые соединения, логически связанные с уже установленными (например, соединение данных в пассивном режиме [[{{w |FTP]]}}). Состояние INVALID означает, что принадлежность пакета к соединению установить не удалось.

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

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

Кроме критерия conntrack, стоит упомянуть и его идеологического предшественника — [[iptables#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) и т. п.

Этот прием позволяет классифицировать соединение в целом на основании информации об отдельном пакете. Выделив этот пакет, вы применяете к нему действие CONNMARK, и выбранную вами маркировку автоматически приобретают все пакеты в соединении. Впоследствии вы можете, например, модифицировать эти пакеты каким-либо образом, или использовать эту маркировку для [[w:Маршрутизация |маршрутизации]] или [[w:Шейпинг (информатика) |шейпинга]] пакетов. Таким образом, вы оперируете с соединением как с единым целым. Более того, эта маркировка автоматически копируется и на соединения, связанные с текущим.

==== [[w:NAT |Трансляция сетевых адресов]] ====

Этот критерий рассмотрен ниже, в разделе [[iptables#Лимитирующие критерии|лимитирующие критерии]].

Используя критерий connlimit, вы можете ограничивать количество одновременно открытых [[{{w |TCP]]}}-соединений с каждого хоста или подсети на ваш сервер, что позволяет обеспечить эффективную защиту от [[w:DoS-атака |DoS-атак]] или просто некорректно работающего клиентского [[w:Программное обеспечение |ПО]].

Этот критерий рассмотрен ниже, в разделе [[iptables#Лимитирующие критерии|лимитирующие критерии]].

Пользователь (точнее, [[w:Root (суперпользователь)|системный администратор]]) или его процессы могут непосредственно наблюдать таблицу контроля состояний, считывать статистику по передаче данных, а также модифицировать эту таблицу (например, удалять из нее соединения). Для этого существуют специальные утилиты, такие как [[conntrack (Программа) | conntrack]] или [[iptstate]]. Впрочем, можно читать информацию и напрямую из псевдофайлов <tt>/proc/net/nf_conntrack</tt> и <tt>/proc/net/nf_conntrack_expect</tt>.

Как уже было сказано выше, каждое встроенное действие реализует какую-либо одну операцию, например, ACCEPT пропускает пакет, MARK меняет его маркировку, MASQUERADE обеспечиват [[{{w |маскарадинг]]}} соединения. Наиболее общими действиями являются:

Например, предположим, что нам нужно обеспечить доступ к определенным [[w:Порт (TCP/IPкомпьютерные сети) |портам]] нашего сервера для всех хостов из подсети 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.

Например, предположим, что у нас есть объединенная через один [[Сетевой_коммутатор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:Порт (TCP/UDPкомпьютерные сети) |порты]] ([[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:Порт (TCP/UDPкомпьютерные сети) |порты]] источника и назначения (31521 и 8080 соответственно), [[Typew:Тип ofобслуживания Service|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> определяет уровень важности лог-сообщения, от которого зависит, в частности, в какой именно из журналов будет записано это сообщение. За более подробными сведениями обратитесь к документации по вашему [[syslogw:Syslog |демону системного лога]].

<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>, соответствует обычной для [[iproute2w: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 вы можете прочитать [[iptables#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, см. [[iptables#Таблица 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.

Порой эта разница бывает довольно тонкой. Например, если действие NFQUEUE передает пакеты демону [[{{w |l7-filter]]}}-userspace (который занимается маркировкой пакетов на основе анализа их содержимого), то правильнее будет разместить вызов такого действия в таблице mangle. Если же оно передает пакеты демону [[nufw]] (который обеспечивает разрешение или запрещение трафика на основе авторизации пользователя), то логичнее разместить это действие в таблице filter.

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

* '''TOS''' — изменяет поле [[Type_of_Servicew:Тип обслуживания |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 представлен [[Iptables#Лимитирующие критерии|ниже]], в описании критерия connbytes.

Отметим, что, в соответствии с современными соглашениями, поле 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''' — изменяет поле [[Time_to_livew: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 |трассировщиков]].

* '''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:Шейпинг (информатика) |шейпинговой]] подсистемы [[iproute2w:Iproute2 |tc]] (лексема handle ''mark'' fw).

* '''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), тем самым нарушая работу процедуры [[MTUw:Maximum transmission unit#Технология Path MTU discovery |Path MTU discovery]].

С точки зрения клиента, эта проблема выглядит так: [[{{w |пинг]]}}и проходят нормально, но при попытке открыть какую-либо [[{{w |веб]]}}-страницу, [[{{w |браузер]]}} «подвисает». При этом с самого шлюза все работает нормально. В этом случае достаточно применить на шлюзе следующую команду

которая обеспечит автоматическую установку размера сегмента в 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]]}}-заголовках (последние два бита поля [[Typew:Тип ofобслуживания Service|TOS]]).

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

* '''TPROXY''' — реализует механизм полностью прозрачного [[w:Прокси-сервер |проксирования]]. Такой подход отличается от традиционно используемого «прозрачного» проксирования (действие REDIRECT [[iptables#Таблица 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.

В качестве примера можно привести простейший случай конфигурации iptables и iproute2 для обеспечения полностью прозрачного проксирования [[{{w |IPv4]]}} {{w [[|HTTP]]}}.

Предназначена для операций stateful-преобразования [[w:IP-адрес |сетевых адресов]] и [[Порт_w:Порт (TCP/IPкомпьютерные сети) |портов]] обрабатываемых пакетов.

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

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

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

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

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

Теперь, при обращении, например, хоста 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).

* '''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>).

Также определенный интерес представляют действия, предоставляемые модулями [http://xtables-addons.sourceforge.net/ xtables-addons] (в настоящее время этот проект уже [http://packages.debian.org/squeeze/xtables-addons-common включен] в [[{{w |Debian]]}} testing). Некоторые из них:

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

Предназначена для изменения маркировки безопасности (меток [[{{w |SELinux]]}}) пакетов и соединений.

Так как эта таблица появилась относительно недавно, ее редко можно увидеть на схемах следования пакетов через цепочки и таблицы [[{{w |netfilter]]}}'а. Поэтому стоит отметить, что все цепочки таблицы security пакеты проходят непосредственно после одноименных цепочек таблицы filter.

Данная таблица добавлена в ядро [[w:Ядро Linux (ядро)|Linux]] в версии 2.6.27. Ранее операции с метками безопасности выполнялись в таблице mangle, и в целях обратной совместимости все действия, разрешенные для таблицы security, можно использовать и в таблице mangle.

* '''SECMARK''' — устанавливает для пакета контекст безопасности [[{{w |SELinux]]}} (единственная допустимая опция <tt>--selctx</tt>).

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

: будет предписывать для всех соединений на [[{{w |TCP]]}}-[[w:Порт (TCP/IPкомпьютерные сети) |порт]] 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’ом). Например,

: Кроме того, идентификатор зоны можно задать для каждого интерфейса через [[{{w |sysfs]]}}, минуя iptables (псевдофайл <tt>/sys/class/net/имя_интерфейса/nf_ct_zone</tt>):

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

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

Данная таблица предназначена для выполнения операций «сырого» преобразования адресов (без использования информации о соединениях), которые не&nbsp;могут быть реализованы в рамках таблицы raw, а именно, для операции «сырой» подмены исходного адреса ([[{{w |маскарадинг]]}}а).

При указании протокола становится возможным использовать специфичные для него критерии. Например, для [[{{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]]}} =====

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

разрешит все входящие пакеты на 80 порт ([[{{w |HTTP]]}}).

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

будет препятствовать [[{{w |спуфинг]]}}у от нашего имени. Ведь если мы получаем пакет с установленными флагами SYN и ACK (такой комбинацией флагов обладает только ответ на SYN-пакет) по еще не открытому соединению, это означает, что кто-то послал другому хосту SYN-пакет от нашего имени, и ответ пришел к нам. Однако добавление такого правила в конфигурацию фаервола ''не рекомендуется'', поскольку стандартом также предусмотрено использование случайного начального номера последовательности для каждого нового TCP-соединения, как раз для предотвращения возможности спуфинг-атаки. Шансов угадать начальный номер у злоумышленника практически нет, тогда как наш ответ RST-пакетом на такой пакет может серьезно нарушить работоспособность некоторых систем защиты от DoS-атак, полагающихся на метод, называемый out-of-sequence ACK. В случае добавления этого правила в конфигурацию фаервола, системы защиты будут считать, что, раз уж мы отвечаем RST на out-of-sequence ACK, вы действительно пытались установить соединение с ресурсом, и пропустят все последующие поддельные пакеты злоумышленника, отправленные от вашего имени. В результате вы заметно облегчите злоумышленнику осуществление DoS-атаки от вашего имени, и при расследовании этого эпизода следы приведут к вам.

===== [[{{w |UDP]]}} =====

===== [[{{w |SCTP]]}} =====

===== [[{{w |DCCP]]}} =====

===== [[{{w |UDP Lite]]}} =====

Поддержка специфических опций протокола UDPLite (а именно, проверки портов источника и/или назначения) в netfilter реализована не вполне очевидным образом: через критерий multiport (см. раздел [[iptables#Вспомогательные критерии|вспомогательные критерии]]).

Если для обычного [[{{w |UDP]]}} соответствие номера порта проверялось выражением вида <tt>-p udp --dport ''номер_порта''</tt> (или <tt>-p udp --sport ''номер_порта''</tt>), то в случае UDPLite аналогичное выражение будет выглядеть как <tt>-p udplite -m multiport --dports ''номер_порта''</tt> (или <tt>-p udplite -m multiport --sports ''номер_порта''</tt>). Все опции критерия multiport для UDPLite поддерживаются в полном объеме.

==== [[{{w |IPv4]]}} ====

блокирует фрагменты [[{{w |ICMP]]}}-пакетов. Так как, в силу функционального назначения протокола, ICMP-пакеты должны быть очень небольшими и нормально укладываться в [[{{w |MTU]]}}, наличие их фрагментов обычно свидетельствует об ошибке или попытке атаки.

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

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

В качестве практического примера использования данного критерия можно привести простейшую защиту от [[{{w |спуфинг]]}}а:

Это правило заблокирует пакеты, которые пришли с внешних интерфейсов, но при этом в качестве обратного адреса у них указан один из адресов, принадлежащих нашему хосту (например, [[{{w |127.0.0.1]]}}).

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

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

<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>) указанному значению.

===== [[{{w |ICMP]]}} =====

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

==== [[{{w |IPv6]]}} ====

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

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

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

===== [[{{w |ICMPv6]]}} =====

==== [[{{w |IPsec]]}} ====

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

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

Возможность корректно обрабатывать пассивный режим FTP, как это было описано выше, из всех [[unix]]-фаерволов доступна только в iptables. В других фаерволах для решения данной проблемы используются различные «костыли». Например, в [[{{w |pf]]}} управляющие FTP-соединения [http://www.openbsd.org/faq/pf/ftp.html#client пропускаются] через специальную программу [http://www.openbsd.org/cgi-bin/man.cgi?query=ftp-proxy&sektion=8 ftp-proxy], которая анализирует трафик подобно conntrack и «на лету» добавляет правила для соединений данных. Однако даже подобные «костыли» существуют далеко не для всех протоколов. Поэтому можно утверждать, что в данном аспекте iptables находится вне конкуренции.

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

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

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

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

Заметим, что значения тайм-аута по умолчанию для разных протоколов, и даже для одного протокола на разных стадиях установки соединения, могут различаться. Например, для протокола [[{{w |TCP]]}} вводятся отдельные значения тайм-аутов для состояний SYN_SENT, SYN_RECV, ESTABLISHED (не путать TCP-состояние ESTABLISHED с conntrack-состоянием ESTABLISHED), FIN_WAIT, CLOSE_WAIT, LAST_ACK, TIME_WAIT, CLOSE. Для [[{{w |UDP]]}} существуют два тайм-аута: для соединений, не получивших статуса ASSURED (conntrack_udp_timeout) и для соединений, по которым передано достаточное количество данных в обе стороны для получения этого статуса (conntrack_udp_timeout_stream). Для [[{{w |ICMP]]}} тайм-аут только один.

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

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

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

В качестве практического примера использования меток пакетов и соединений рассмотрим улучшение работы [[{{w |l7-filter]]}}-userspace.

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 существенно различается.

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

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

Как показывает [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:Случайная величина |стохастической]] балансировки соединений между несколькими [[аплинк]]ами.

Допустим, у нас есть три провайдера, подключенных к интерфейсам eth0, eth1 и eth2 (это могут быть и [[{{w |VLAN]]}}-порты одного интерфейса, суть от этого не меняется, только названия), и их шлюзы имеются соответственно [[{{w |IP-адрес]]}}а 208.77.188.1, 208.77.189.1, 208.77.190.1.

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

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

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

Ввиду того, что выбор исходящего адреса для каждого нового соединения осуществляется на основании правил статической маршрутизации (таблица main), могут возникнуть ошибки. Например, если в маршруте по умолчанию (default) в таблице main указан интерфейс eth0, то все исходящие от нас во внешнюю сеть (интернет) соединения будут иметь в качестве исходного адреса первый адрес интерфейса eth0, и ответные пакеты пойдут именно на этот интерфейс. Чтобы избежать возникновения таких ситуаций, добавим [[{{w |маскарадинг]]}} для всех исходящих соединений (предполагается, что у всех провайдеров наши внешние адреса имеют вид 208.77.x.100):

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

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

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

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

будет заводить отдельную очередь для каждой подсети с маской 255.255.255.240 (подробнее про префиксы и маски см. [[{{w |CIDR]]}}).

Теперь очереди ограничений для подключения к службам [[{{w |FTP]]}} и [[{{w |rsync]]}} для нашего сервера будут вводиться независимо, то есть если какой-либо хост превысит предел подключений по FTP, то это никак не повлияет на подключения по rsync. Заметим, что в данном конкретном случае аналогичную функциональность можно реализовать, даже не используя разные хеши:

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

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

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

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

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

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

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

<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_structure|секции (chunks)]] вместе с их заголовками.

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

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

Если быть точным, recent запоминает не сами пакеты, а их количество, время поступления, адрес источника (в последних версиях iptables также может запоминать и адрес назначения), а также, при необходимости, [[Time_to_livew:Time to live |TTL]].

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

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

* Блокирование [[{{w |bruteforce]]}}-атак (подбор пароля вслепую) на [[{{w |SSH]]}} и аналогичные сервисы.

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

В данном случае сканированием портов считается обращение на порт 139/tcp ([[{{w |SMB]]}}). Впрочем, вы можете задать другой порт или, используя критерий multiport, даже список портов. В отличие от предыдущего примера, здесь производится автоматическая очистка списка [[{{w |IP-адрес]]}}ов: по прошествии суток с момента блокировки, первое же обращение с заблокированного адреса на наш сервер приводит к удалению этого адреса из нашего recent-списка. Однако, если это обращение вновь является попыткой сканирования портов, то есть направлено на порт 139/tcp, адрес тут же блокируется вновь. Именно поэтому процедура блокировки расположена «ниже по течению», чем процедура удаления адреса из списка.

Проводя аналогию с ныне почившим проектом [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]]}}.

Последовательный стук в порты можно организовать, например, утилитой [[{{w |netcat]]}}

Данный критерий предоставляет очень гибкий инструмент, позволяющий производить сложные операции по анализу содержимого пакета. Алгоритм обработки содержимого исследуемого пакета задается на специальном [[Язык программирования|языке программирования]], своеобразном «[[w:Язык ассемблера |ассемблере]]». Такой подход позволяет получить огромную гибкость, но при этом его изучение и использование может представлять определенные трудности для пользователей, не знакомых с основами [[Программирование|программирования]] и принципами работы [[Машина Тьюринга|машины Тьюринга]].

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

Другой не вполне очевидный момент — синтаксис операторов =, &, << и >>. Дело в том, что в качестве первого операнда указывается не само значение, а его ''адрес'' в пределах пакета, заданный смещением в байтах от текущего начального смещения. Например, <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#Пакет (датаграмма) |содержится]] информация о версии протокола, длине заголовка и [[Typew:Тип ofобслуживания Service|типе обслуживания]], которая нас сейчас не интересует), и проверить значение, формируемого оставшимися двумя байтами (это и есть полная длина пакета в байтах) на принадлежность диапазону от 0x100 (256 в десятичном счислении) до 0xFFFF (65535, максимально возможная длина пакета).

* Проверить, является ли данный пакет [[{{w |ICMP]]}}-пакетом с типом 0 (эхо-ответ). Учитывая переменную длину IP-заголовка, эта проверка требует несколько большего количества операций: <tt>--u32 "6 & 0xFF = 1 && 4 & 0x3FFF = 0 && 0 >> 22 & 0x3C @ 0 >> 24 = 0"</tt>

* Проверить, задают ли байты с восьмого по одиннадцатый полезной нагрузки [[{{w |TCP]]}}-пакета одно из значений: 1, 2, 5, 8. Достигается следующим кодом: <tt>--u32 "6 & 0xFF = 6 && 4 & 0x3FFF = 0 && 0 >> 22 & 0x3C @ 12 >> 26 & 0x3C @ 8 = 1,2,5,8"</tt>

== Параметры [[{{w |sysctl]]}}/[[{{w |procfs]]}} ==

==== [[{{w |TCP]]}} ====

==== [[{{w |UDP]]}} ====

==== [[{{w |ICMP]]}} ====

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

Часто используются параметры -n (во избежение медленных запросов [[{{w |DNS]]}}) и -v (для вывода более подробной информации).

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

Настоятельно не рекомендуется использовать имена, для разрешения которых требуется удаленный запрос, например по системе [[{{w |DNS]]}}.

Сравнение не IP источника пакета, а его [[{{w |ethernet]]}}-адреса

<tt>[!] --mac-source address</tt>. [[{{w |MAC-адрес]]}} должен быть указан в стандартном формате XX:XX:XX:XX:XX:XX.

Если нужна фильтрация по MAC-адресу в мостовых соединениях (например, pppoe), то можно воспользоваться утилитой [[{{w |ebtables]]}}, которая предназначена как раз для более низкоуровневой фильтрации пакетов.

* [http://www.netfilter.org/ — Сайт] проекта [[{{w |Netfilter]]}}

* [http://freshmeatfreecode.netcom/projects/flex-fw flex-fw — это гибкая надстройка над iptables для построения сервис-ориентированного statefull-фаервола с простым синтаксисом команд].

* [http://linux.die.net/{{Unix man/8/ |iptables linux.die.net/man/|8/iptables]}} {{ref-en}}

* [http://manpages.ubuntu.com/manpages/karmic/man8/gufw.8.html 'man gufw' /*ubuntu linux*/]{{ref-en}} [https://help.ubuntu.com/community/GufwIptablesHowTo (ubuntu community)]{{ref-en}}

* [https://help.ubuntu.com/9.10/serverguide/C/firewall.html 'ubuntu fierwall']- [https://wiki.ubuntu.com/UncomplicatedFirewall 'ufw utility'] [https://help.ubuntu.com/community/Firewall (ubuntu community)]UFW {{ref-en}}