Таблицы межсетевого экрана netfilter для чего они используются

Обновлено: 05.07.2024

Брандмауэры – важный инструмент, который может защитить ваш сервер и инфраструктуру. В экосистеме Linux iptables – широко используемый инструмент для настройки брандмауэра, который взаимодействует с базой фильтрации пакетов netfilter. Пользователи и администраторы, которые не понимают архитектуру этих систем, столкнутся при их настройке со многими трудностями, связанными со сложным синтаксисом и внутренними связями компонентов.

Данная статья расскажет вам об архитектуре iptables и поможет создать политику брандмауэра. Вы узнаете, как iptables взаимодействует с netfilter и как различные компоненты взаимодействуют, чтобы обеспечить комплексную систему фильтрации и обработки.

Что такое IPTables и Netfilter?

IPTables – это основное программное обеспечение брандмауэра, наиболее часто используемое в Linux. Брандмауэр iptables работает, взаимодействуя с хуками фильтрации пакетов в сетевом стеке ядра Linux. Эти хуки называются фреймворком netfilter.

Каждый пакет в сети (входящий или исходящий) будет запускать эти хуки по мере прохождения через стек, позволяя программам, которые регистрируют эти хуки, взаимодействовать с трафиком в ключевых точках. Модули ядра, связанные с iptables, регистрируют эти хуки, чтобы убедиться, что трафик соответствует условиям, установленным правилами брандмауэра.

Хуки netfilter

Программы могут регистрировать пять фильтров-хуков netfilter. По мере продвижения пакетов через стек, они будут запускать модули ядра, которые зарегистрировались в этих хуках. Хуки, которые запускает пакет, зависят от того, является ли пакет входящим или исходящим, был ли он отклонен в предыдущей точке, а также от места назначения пакета.

Следующие хуки представляют собой четко определенные точки в сетевом стеке:

Модули ядра, которые хотят зарегистрироваться на этих хуках, должны установить приоритет, чтобы определить порядок, в котором они будут вызываться при запуске хука. Это обеспечивает возможность подключения нескольких модулей (или нескольких экземпляров того же модуля) к каждому из хуков в определенном порядке. Каждый модуль будет вызываться по очереди и возвращать решение для фреймворка netfilter после обработки, которая определяет, что должно быть сделано с пакетом.

Таблицы и цепочки iptables

Брандмауэр iptables использует таблицы для систематизации правил. Эти таблицы классифицируют правила в соответствии с типом решений, которые они принимают. Например, если правило касается преобразования сетевых адресов, оно будет помещено в таблицу nat. Если правило используется для принятия решения о том, пропустить ли пакет к его цели, оно, вероятно, будет добавлено в таблицу filter.

В каждой таблице iptables правила организованы в отдельные цепочки. Таблицы определяют общую цель правил, а встроенные цепочки представляют собой хуки netfilter, которые запускают их. Цепочки в основном определяют, когда будут использоваться те или иные правила.

Имена встроенных цепей зеркально отражают имена хуков netfilter, с которыми они связаны:

  • PREROUTING: запускается хуком NF_IP_PRE_ROUTING.
  • INPUT: запускается с помощью NF_IP_LOCAL_IN.
  • FORWARD: запускается хуком NF_IP_FORWARD.
  • OUTPUT: запускается с помощью NF_IP_LOCAL_OUT.
  • POSTROUTING: запускается с помощью NF_IP_POST_ROUTING.

Цепочки позволяют администратору указать, где на пути доставки пакета будет оцениваться то или иное правило. Поскольку каждая таблица имеет несколько цепочек, она может влиять на пакет в нескольких точках обработки.

Существует только пять хуков ядра netfilter, поэтому на каждом из хуков регистрируются цепочки из нескольких таблиц. Например, в трех таблицах есть цепочки PREROUTING. Когда эти цепочки регистрируются на связанном хуке NF_IP_PRE_ROUTING, они задают свой приоритет – это определяет, в каком порядке вызываются цепочки PREROUTING из каждой таблицы. Сначала последовательно оцениваются все правила в цепочке PREROUTING с наивысшим приоритетом, а затем пакет может перейти к следующей цепочке PREROUTING.

Какие бывают таблицы iptables?

Давайте подробнее рассмотрим разные таблицы, которые предоставляет iptables. Эти таблицы представляют собой различные наборы правил, сгруппированные по цели.

Таблица filter

Таблица filter является одной из наиболее широко используемых таблиц в iptables. Она решает, следует ли передавать пакет в место назначения или следует отклонить его запрос. На языке брандмауэра это называется фильтрацией пакетов. Эта таблица обеспечивает основную функциональность брандмауэра.

Таблица NAT

Таблица nat используется для реализации правил преобразования сетевых адресов. Когда пакеты входят в сетевой стек, правила в этой таблице определяют, следует ли изменять исходные или целевые адреса пакета, чтобы повлиять на его маршрутизацию, и как это сделать. Эта таблица часто используется для маршрутизации пакетов в сети при отсутствии прямого доступа.

Таблица mangle

Таблица mangle используется для изменения IP-заголовков пакета. Например, вы можете настроить значение TTL (Time to Live) пакета, увеличивая или сокращая количество действительных сетевых переходов, которые может поддерживать пакет. Другие IP-заголовки можно изменить аналогичным образом.

Эта таблица также может маркировать пакет для дальнейшей обработки в других таблицах и других сетевых инструментах.

Таблица raw

Iptables – брандмауэр с отслеживанием состояний, то есть пакеты оцениваются в контексте их отношения к предыдущим пакетам. Функции отслеживания соединений, основанные на netfilter, позволяют iptables рассматривать пакеты как часть текущего соединения или сеанса, а не как поток дискретных несвязанных пакетов. Логика отслеживания соединений обычно применяется сразу после того, как пакет попадает в сетевой интерфейс.

Таблица raw имеет очень узкую функцию. Ее единственная цель – предоставить механизм для маркировки пакетов для отказа от отслеживания соединения.

Таблица security

Таблица security используется для установки внутренних меток безопасности SELinux на пакеты, что влияет на то, как SELinux (или другие системы, которые могут интерпретировать контексты безопасности SELinux) обрабатывает пакеты. Эти метки могут применяться для каждого пакета или для каждого соединения.

Какие цепочки реализуют таблицы?

В следующей таблице слева направо перечислены все цепочки, доступные в каждой таблице iptables. Например, в таблице raw есть цепочки PREROUTING и OUTPUT. При чтении сверху вниз нижеприведенная таблица отображает порядок, в котором вызывается каждая цепочка при срабатывании соответствующего хука.

Следует отметить несколько вещей. Ниже таблица nat была разделена между операциями DNAT (которые изменяют адрес назначения пакета) и операциями SNAT (которые изменяют исходный адрес), чтобы более четко отобразить их порядок. Также здесь представлены точки, в которых принимаются решения о маршрутизации и включается отслеживание соединений, чтобы дать более целостное представление о происходящих процессах.

Таблицы↓/Цепочки→ PREROUTING INPUT FORWARD OUTPUT POSTROUTING
(решения о маршрутизации) ✓
raw ✓ ✓
(отслеживание подключений) ✓ ✓
mangle ✓ ✓ ✓ ✓ ✓
nat (DNAT) ✓ ✓
(решения о маршрутизации) ✓ ✓
filter ✓ ✓ ✓
security ✓ ✓ ✓
nat (SNAT) ✓ ✓

Поскольку пакет запускает хук netfilter, связанные цепочки будут обрабатываться в том порядке, в каком они перечислены в таблице выше сверху вниз. Хуки, которые запускает пакет, зависят от того, является ли он входящим или исходящим, соответствует ли он критериям фильтрации, а также от решения о маршрутизации.

Некоторые события приводят к тому, что цепочка таблицы во время обработки пропускается. Например, по правилам NAT будет оцениваться только первый пакет в соединении. Решение, принятое для первого пакета, будет применено ко всем последующим пакетам в соединении без дополнительной оценки.

Порядок обхода цепочек

При условии, что сервер знает, как маршрутизировать пакет, и что брандмауэр разрешил передавать его, возможны следующие пути:

Если объединить приведенную выше информацию с порядком, изложенным в предыдущей таблице, вы увидите, что входящий пакет, предназначенный для локальной системы, сначала будет оцениваться цепочками PREROUTING из таблиц raw, mangle и nat. Затем он будет перемещаться по цепочкам INPUT таблиц mangle, filter, security и nat, прежде чем будет доставлен на локальный сокет.

Правила IPTables

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

Критерий

Критерий – это выражение, которому должен соответствовать пакет для выполнения связанного действия (или цели).

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

Действие

Действие, или цель – это описание действия, которое запускается, если пакет соответствует критериям. Действия обычно делятся на две категории:

  • Терминальные – это действия, которые прерывают оценку пакета внутри цепочки и возвращают управление хуку netfilter. В зависимости от возвращаемого значения хук может сбросить пакет или позволить ему перейти на следующий этап обработки.
  • Нетерминальные выполняют действие и продолжают оценку в цепочке. Каждая цепочка должна в конечном итоге принять окончательное решение, но в ней может быть выполнено множество нетерминальных действий.

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

Переход к пользовательским цепочкам

Следует упомянуть особый класс нетерминальных действий – действия перехода. Они передают оценивание пакета другой цепочке для дополнительной обработки. Мы довольно много говорили о встроенных цепочках, которые тесно связаны с хуками netfilter. Однако iptables также позволяет администраторам создавать свои собственные цепочки.

Правила можно поместить в пользовательские цепочки таким же образом, как и во встроенных цепочках. Разница в том, что пользовательские цепочки могут быть достигнуты только путем перехода к ним из правила (они не регистрируются самим хуком netfilter).

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

Отслеживание соединений

Мы упоминали систему отслеживания соединений, реализованную на основе netfilter, когда обсуждали таблицу raw и критерии соединения. Отслеживание соединений позволяет iptables работать с пакетами, просматриваемыми в контексте текущего соединения. Система отслеживания соединений предоставляет iptables функциональность, необходимую для выполнения операций с отслеживанием состояния.

Отслеживание соединений применяется сразу после того, как пакеты входят в сетевой стек.

Система сравнивает каждый пакет с набором существующих соединений. В случае необходимости она обновит состояние подключения в своем хранилище и добавит новые подключения. Пакеты, отмеченные целью NOTRACK в одной из цепочек raw, обходят процедуры отслеживания соединений.

Отслеживаемые соединения будут находиться в одном из следующих состояний:

  • NEW: если поступающий пакет не связан с существующим соединением, но может рассматриваться в качестве первого пакета, в систему будет добавлено новое соединение с этой меткой. Это происходит как для протоколов TCP, так и для UDP.
  • ESTABLISHED: когда соединение получает ответ, состояние изменяется с NEW на ESTABLISHED. Для TCP-соединений это означает SYN/ACK, а для трафика UDP и ICMP это ответ, в котором меняются местами целевой и исходный адрес пакета.
  • RELATED: Пакеты, которые не являются частью существующего соединения, но связаны с соединением, уже находящимся в системе, помечены как RELATED. Это может быть вспомогательное соединение, как в случае с соединениями передачи данных по FTP, или ответ ICMP на попытки подключения другими протоколами.
  • INVALID: пакеты могут быть помечены как INVALID, если они не связаны с существующим соединением и не подходят для создания нового соединения, если их нельзя идентифицировать или маршрутизировать по другим причинам.
  • UNTRACKED: Пакеты могут быть помечены как UNTRACKED, если они были направлены в цепочку таблицы raw, чтобы обойти отслеживание.
  • SNAT: виртуальное состояние, которое устанавливается, когда исходный адрес был изменен операциями NAT. Это используется системой отслеживания соединений для того чтобы понимать, как изменить исходные адреса в ответные пакеты.
  • DNAT: виртуальное состояние, которое устанавливается, когда адрес назначения был изменен с помощью операций NAT. Оно используется системой отслеживания соединений для изменения адреса получателя при маршрутизации ответных пакетов.

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

Заключение

Система фильтрации netfilter и iptables являются основой большинства средств для настройки брандмауэра на серверах Linux. Хуки ядра netfilter обеспечивают контроль над пакетами. Брандмауэр iptables использует эти возможности для предоставления гибкого, расширяемого метода создания политики. Узнав больше о взаимодействии этих компонентов, вы можете лучше использовать их для управления и защиты своих серверных сред.

Подсистема netfilter представляет собой средство пакетной фильтрации в ядре Linux (начиная с версии 2.4) [ 46 ] . Утилита iptables используется для управления netfilter.

Примечание: Netfilter/iptables кроме создание межсетевых экранов на основе пакетной фильтрации (в том числе и с учетом состояния соединения), также позволяет реализовать различные сложные схемы манипуляции сетевыми пакетами , в частности трансляцию сетевых адресов ( NAT ) для разделяемого доступа в Интернет и организации прозрачных прокси (см. "Обеспечение доступа в сеть Интернет" ).

Сетевые пакеты в подсистеме netfilter проходят последовательность цепочек (chain). Каждая цепочка включает заданный набор таблиц (table), содержащих упорядоченные списки правил. Каждое правило содержит параметры выбора и выполняемое действие при соответствии содержимого пакета параметрам.

Существует пять типов стандартных цепочек, встроенных в систему [ 47 ] :

  • PREROUTING — для изначальной обработки входящих пакетов
  • INPUT — для входящих пакетов, адресованных непосредственно локальному компьютеру
  • FORWARD — для проходящих (маршрутизируемых) пакетов
  • OUTPUT — для пакетов, создаваемых локальным компьютером
  • POSTROUTING — для окончательной обработки исходящих пакетов

Цепочки организованы в четыре таблицы рис. 11.1 [ 47 ] :

  • raw — просматривается до передачи пакета системе определения состояний. Содержится в цепочках PREROUTING и OUTPUT.
  • mangle — содержит правила модификации заголовка IP?пакетов. Среди прочего, поддерживает изменения полей TTL и TOS, и маркеров пакета. Содержится во всех стандартных цепочках.
  • nat — используется для трансляции сетевых адресов. Содержится в цепочках PREROUTING, OUTPUT, и POSTROUTING.
  • filter — основная таблица, предназначенная для фильтрации сетевых пакетов ; используется по умолчанию если название таблицы не указано. Содержится в цепочках INPUT, FORWARD, и OUTPUT.

Прохождение пакета в подсистеме netfilter (взято из wikipedia.org)

Следует отметить, что одноименные таблицы каждой цепочки независимы.

Далее возможны два варианта:

  1. Если целью пакета является этот компьютер, то пакет будет отправлен в цепочку INPUT ; после маршрутизации, он обрабатывается правилами цепочек INPUT. В случае прохождения цепочек пакет передается приложению.
  2. Если целью пакета является другой компьютер, то пакет фильтруется правилами цепочки FORWARD таблиц mangle и filter , а затем к нему применяются правила цепочки POSTROUTING. На данном этапе можно использовать SNAT/MASQUERADE (подмена источника/маскировка). После этих действий пакет будет отправлен в сеть.

Третий вариант - когда приложение на компьютере, отвечает на запрос или отправляет собственный пакет, то он обрабатывается цепочкой OUTPUT таблиц raw , conntrack и filter . Затем к нему применяются правила цепочки OUTPUT таблицы nat , для определения, требуется ли использовать DNAT (модификация адреса получателя), пакет фильтруется цепочкой OUTPUT таблицы filter и выпускается в цепочку POSTROUTING. В случае успешного прохождения POSTROUTING пакет выходит в сеть .

Непосредственно для фильтрации используются таблицы filter . Поэтому в рамках данной темы важно понимать, что для фильтрации пакетов, предназначенных данному узлу необходимо модифицировать таблицу filter цепочки INPUT, для проходящих пакетов — цепочки FORWARD, для пакетов, созданных данным узлом — OUTPUT.

Управление правилами iptables

Команда iptables позволяет редактировать правила таблиц netfilter . Каждое правило представляет собой запись , содержащую в себе параметры отбора (критерии), определяющие, подпадает ли пакет под данное правило, и действие, которое необходимо выполнить в случае соответствия параметрам отбора [ 48 ] .

В общем виде правила записываются в виде:

Примечание: для работы с iptables требуются права суперпользователя .

Для просмотра существующих правил, команда iptables используется с ключом -L . Так, для просмотра всех цепочек таблицы filter ( -v — для более детального отображения):

Примечание: Далее по тексту данной темы, если не названа таблица, то имеется в виду таблица filter .

Для просмотра цепочки FORWARD нужно указать имя цепочки:

Сбросить все правила (-F) и удалить определенные пользователем цепочки (-X) :

Для добавления правила в цепочку используется ключ -A . Например, чтобы добавить правило в цепочку POSTROUTING таблицы nat :

Для того, чтобы добавить правило в цепочку FORWARD:

Ниже в виде таблицы приведены основные параметры отбора пакетов [ 48 ] :

  • Одиночный хост: host.domain. tld , или IP адрес: 10.10.10.3
  • Пул-адресов ( подсеть ): 10.10.10.3/24 или 10.10.10.3/255.255.255.0

Состояние соединения . Доступно, если модуль 'state' загружен с помощью '-m state' . Доступные опции:

NEW (Все пакеты устанавливающие новое соединение)

ESTABLISHED (Все пакеты, принадлежащие установленному соединению)

RELATED (Пакеты, не принадлежащие установленному соединению, но связанные с ним. Например - FTP в активном режиме использует разные соединения для передачи данных. Эти соединения связаны.)

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

Действие, которое система выполнит, если пакет в одной из цепочек удовлетворяет условию, устанавливается с помощью ключа -j (-- jump ) . Можно также передать пакет в другую цепочку.

Введение и история

Netfilter — межсетевой экран (он же, брандмауэр, он же файерволл, он же firewall. ) встроен в ядро Linux с версии 2.4. Netfilter управляется утилитой iptables (Для IPv6 — ip6tables). До netfilter/iptables был Ipchains, который входил в состав ядер Linux 2.2. До ipchains в Linux был так называемый ipfw (IPV4 firewal), перенесенный из BSD. Утилита управления - ipfwadm. Проект netfilter/iptables был основан в 1998. Автором является Расти Расселл (он же руководил и прошлыми разработками). В 1999 г. образовалась команда Netfilter Core Team (сокращено coreteam). Разработанный межсетевой экран получил официальное название netfilter. В августе 2003 руководителем coreteam стал Харальд Вельте (Harald Welte).

Проекты ipchains и ipfwadm изменяли работу стека протоколов ядра Linux, поскольку до появления netfilter в архитектуре ядра не существовало возможностей для подключения дополнительных модулей управления пакетами. iptables сохранил основную идею ipfwadm — список правил, состоящих из критериев и действия, которое выполняется если пакет соответствует критериям. В ipchains была представлена новая концепция — возможность создавать новые цепочки правил и переход пакетов между цепочками, а в iptables концепция была расширена до четырёх таблиц (в современных netfilter - более четырех), разграничивающих цепочки правил по задачам: фильтрация, NAT, и модификация пакетов. Также iptables расширил возможности Linux в области определения состояний, позволяя создавать межсетевые экраны работающие на сеансовом уровне.

Архитектура Netfilter/iptables

Предварительные требования ( с )

Как уже говорилось выше, для работы Netfilter необходимо ядро версии 2.6 (ну или хотя бы 2.3.15). Кроме того, при сборке и настройке ядра необходимо наличие настроек CONFIG_NETFILTER, CONFIG_IP_NF_IPTABLES, CONFIG_IP_NF_FILTER (таблица filter), CONFIG_IP_NF_NAT (таблица nat), CONFIG_BRIDGE_NETFILTER, а также многочисленные дополнительные модули: CONFIG_IP_NF_CONNTRACK (отслеживание соединений), CONFIG_IP_NF_FTP (вспомогательный модуль для отслеживания FTP соединений), CONFIG_IP_NF_MATCH_* (дополнительные типы шаблонов соответствия пакетов: LIMIT, MAC, MARK, MULTIPORT, TOS, TCPMSS, STATE, UNCLEAN, OWNER), CONFIG_IP_NF_TARGET_* (дополнительные действия в правилах: REJECT, MASQUERADE, REDIRECT, LOG, TCPMSS), CONFIG_IP_NF_COMPAT_IPCHAINS для совместимости с ipchains, CONFIG_BRIDGE_NF_EBTABLES и CONFIG_BRIDGE_EBT_* для работы в режиме моста, прочие CONFIG_IP_NF_* и CONFIG_IP6_NF_*. Полезно также указать CONFIG_PACKET.

Файлы в каталоге /proc, отображающие информацию о работе netfilter (о некоторых из них - ниже по тексту):

  • /proc/net/ip_tables_names - список используемых таблиц
  • /proc/net/ip_tables_targets - список используемых действий
  • /proc/net/ip_tables_matches - список используемых протоколов
  • /proc/net/nf_conntrack (или /proc/net/ip_conntrack) - список установленных соединений и их состояний
  • /proc/sys/net/ipv4/netfilter/* - cодержит множество настроек системы conntrack, например:
    • ip_conntrack_tcp_be_liberal
      • 0 - все пакеты, не попадающие в окно, считаются INVALID
      • 1 - только RST пакеты, не попадающие в окно, считаются INVALID (пришлось поставить)

      Функциональность netfilter может расширяться с помощью модулей ядра. Головной модуль ядра называется iptable_filter, модуль поддержки утилиты iptables называется ip_tables, вспомогательные модули обычно имеют префикс "ipt_" (например: ipt_state, ipt_REJECT, ipt_LOG; хотя - ip_conntrack/nf_conntrack). Большинство модулей загружается автомагически, но некоторые всё же приходиться загружать вручную (ip_conntrack_ftp - иначе может не работать в режиме Active; ip_conntrack_irc - иначе может не работать отсылка файлов по DCC; ip_nat_ftp; ip_nat_irc; ip_conntrack_tftp/nf_conntrack_tftp на клиенте - иначе не будет работать TFTP).

      Схема работы

      Для начального понимания архитектуры Netfilter/iptables отлично подойдет иллюстрация из википедии, которую я несколько модифицировал для большей прозрачности и понимания материала:

      Архитектура netfiler/iptables в схеме

      Ахтунг, ниже в трех абзацах изложена основная мысль статьи и принцип работы сетевого фильтра, поэтому желательно вчитаться как можно внимательнее!

      Итак, давайте разберем данную схему работы netfilter. Сетевые пакеты поступают в сетевой интерфейс, настроенный на стек TCP/IP и после некоторых простых проверок ядром (например, контрольная сумма) проходят последовательность цепочек (chain) (обозначены пунктиром). Пакет обязательно проходит первоначальную цепочку PREROUTING. После цепочки PREROUTING, в соответствии с таблицей маршрутизации, проверяется кому принадлежит пакет и, в зависимости от назначения пакета, определяется куда он дальше попадет (в какую цепочку). Если пакет НЕ адресован (в IP пакете поле адрес получателя - НЕ локальная система) локальной системе, то он направляется в цепочку FORWARD, если пакет адресован локальной системе, то направляется в цепочку INPUT и после прохождения INPUT отдается локальным демонам/процессам. После обработки локальной программой, при необходимости формируется ответ. Ответный пакет пакет отправляемый локальной системой в соответствии с правилами маршрутизации направляется на соответствующий маршрут (хост из локальной сети или адрес маршрутизатора) и направляется в цепочку OUTPUT. После цепочки OUTPUT (или FORWARD, если пакет был проходящий) пакет снова сверяется с правилами маршрутизации и отправляется в цепочку POSTROUTING. Может возникнуть резонный вопрос: почему несколько раз пакет проходит через таблицу маршрутизации? (об этом - ниже).

      Каждая цепочка, которую проходит пакет состоит из набора таблиц (table) (обозначены овалами). Таблицы в разных цепочках имеют одинаковое наименование, но тем не менее никак между собой не связаны. Например таблица nat в цепочке PREROUTING никак не связана с таблицей nat в цепочке POSTROUTING. Каждая таблица состоит из упорядоченного набора (списка) правил. Каждое правило содержит условие, которому должен соответствовать проходящий пакет и действия к пакету, подходящему данному условию.

      Проходя через серию цепочек пакет последовательно проходит каждую таблицу (в указанном на иллюстрации порядке) и в каждой таблице последовательно сверяется с каждым правилом (точнее сказать - с каждым набором условий/критериев в правиле), и если пакет соответствует какому-либо критерию, то выполняется заданное действие над пакетом. При этом, в каждой таблице (кроме пользовательских) существует заданная по-умолчанию политика. Данная политика определяет действие над пакетом, в случае, если пакет не соответствует ни одному из правил в таблице. Чаще всего - это действие ACCEPT, чтобы принять пакет и передать в следующую таблицу или DROP - чтобы отбросить пакет. В случае, если пакет не был отброшен, он завершает свое путешествие по ядру системы и отправляется в сетевую карту сетевой интерфейс, которая подходит по правилам маршрутизации.

      Очень часто о таблицах и цепочках говорят в плоскости "таблицы содержат в себе наборы цепочек", но я считаю, что это неудобно и непонятно.

      Цепочки netfilter:

      • PREROUTING — для изначальной обработки входящих пакетов
      • INPUT — для входящих пакетов, адресованных непосредственно локальному компьютеру
      • FORWARD — для проходящих (маршрутизируемых) пакетов
      • OUTPUT — для пакетов, создаваемых локальным компьютером (исходящих)
      • POSTROUTING— для окончательной обработки исходящих пакетов
      • Также можно создавать и уничтожать собственные цепочки при помощи утилиты iptables.

      Цепочки организованны в 4 таблицы:

      • raw — пакет проходит данную таблицу до передачи системе определения состояний. Используется редко, например для маркировки пакетов, которые НЕ должны обрабатываться системой определения состояний. Для этого в правиле указывается действие NOTRACK. Содержитcя в цепочках PREROUTING и OUTPUT.
      • mangle — содержит правила модификации (обычно полей заголовка) IP‐пакетов. Среди прочего, поддерживает действия TTL, TOS, и MARK (для изменения полей TTL и TOS, и для изменения маркеров пакета). Редко необходима и может быть опасна. Содержится во всех пяти стандартных цепочках.
      • nat — предназначена для подмены адреса отправителя или получателя. Данную таблицу проходят только первый пакет из потока, трансляция адресов или маскировка (подмена адреса отправителя или получателя) применяются ко всем последующим пакетам в потоке автоматически. Поддерживает действия DNAT, SNAT, MASQUERADE, REDIRECT. Содержится в цепочках PREROUTING, OUTPUT, и POSTROUTING.
      • filter — основная таблица, используется по умолчанию если название таблицы не указано. Используется для фильтрации пакетов. Содержится в цепочках INPUT, FORWARD, и OUTPUT.

      Как я уже отметил, непосредственно для фильтрации пакетов используются таблицЫ filter. Поэтому в рамках данной темы важно понимать, что для пакетов, предназначенных данному узлу необходимо модифицировать таблицу filter цепочки INPUT, для проходящих пакетов — цепочки FORWARD, для пакетов, созданных данным узлом — OUTPUT.

      Примеры прохождения цепочек

      Последовательность обработки входящего пакета, предназначенного для локального процесса:

      1. Просматривается цепочка PREROUTING
        1. Просматривается таблица raw
        2. Просматривается таблица mangle, далее происходит отслеживание соединений
        3. Просматривается таблица nat (используется для DNAT - модификация адреса получателя)
        1. Просматривается таблица mangle
        2. Просматривается таблица filter

        Последовательность обработки пакета, уходящего с нашего хоста:

        1. Маршрутизация: определение исходящего адреса, адреса назначения, используемого интерфейса; если пакет маршрутизируется внутрь (для локального хоста), то переходим к предыдущей процедуре
        2. Просматривается цепочка OUTPUT
          1. Просматривается таблица raw
          2. Просматривается таблица mangle, фильтровать здесь не стоит, здесь же происходит отслеживание локально создаваемых соединений
          3. Просматривается таблица nat (NAT для локально сгенерированных пакетов)
          4. Просматривается таблица filter
          1. Просматривается таблица mangle
          2. Просматривается таблица nat (используется для SNAT - модификация адреса источника, фильтровать здесь не стоит)

          Последовательность обработки проходящего пакета (начинается от п.2 первой процедуры):

          1. Просматривается цепочка FORWARD
            1. Просматривается таблица mangle
            2. Просматривается таблица filter
            1. Просматривается таблица mangle
            2. Просматривается таблица nat (используется для SNAT и Masquerading, фильтровать здесь не стоит)

            Как видно, таблица nat и mangle может модифицировать получателя или отправителя сетевого пакета. Именно поэтому сетевой пакет несколько раз сверяется с таблицей маршрутизации.

            Механизм определения состояний (conntrack)

            Выше в тексте несколько раз указывалось понятие "определение состояний", оно заслуживает отдельной темы для обсуждения, но тем не менее я кратко затрону данный вопрос в текущем посте. В общем, механизм определения состояний (он же state machine, он же connection tracking, он же conntrack) является частью пакетного фильтра и позволяет определить определить к какому соединению/сеансу принадлежит пакет. Conntrack анализирует состояние всех пакетов, кроме тех, которые помечены как NOTRACK в таблице raw. На основе этого состояния определяется принадлежит пакет новому соединению (состояние NEW), уже установленному соединению (состояние ESTABLISHED), дополнительному к уже существующему (RELATED), либо к "другому" (неопределяемому) соединению (состояние INVALID). Состояние пакета определяется на основе анализа заголовков передаваемого TCP-пакета. Модуль conntrack позволяет реализовать межсетевой экран сеансового уровня (пятого уровня модели OSI). Для управления данным механизмом используется утилита conntrack, а так же параметр утилиты iptables: -m conntrack или -m state (устарел). Состояния текущих соединений conntrack хранит в ядре. Их можно просмотреть в файле /proc/net/nf_conntrack (или /proc/net/ip_conntrack).

            Чтобы мысли не превратились в кашу, думаю данной краткой информации для понимания дальнейшего материала будет достаточно.

            Управление правилами сетевой фильтрации Netfilter (использование команды iptables)

            Утилита iptables является интерфейсом для управления сетевым экраном netfilter. Данная команда позволяет редактировать правила таблиц, таблицы и цепочки. Как я уже говорил - каждое правило представляет собой запись/строку, содержащую в себе критерии отбора сетевых пакетов и действие над пакетами, которые соответствуют заданному правилу. Команда iptables требует для своей работы прав root.

            В общем случае формат команды следующий:

            Ниже приведены команды и параметры утилиты iptables:

            Критерии (параметры) отбора сетевых пакетов команды iptables

            Критерии отбора сетевых пакетов негласно делятся на несколько групп: Общие критерии, Неявные критерии, Явные критерии. Общие критерии допустимо употреблять в любых правилах, они не зависят от типа протокола и не требуют подгрузки модулей расширения. Неявные критерии (я бы из назвал необщие), те критерии, которые подгружаются неявно и становятся доступны, например при указании общего критерия --protocol tcp|udp|icmp. Перед использованием Явных критериев, необходимо подключить дополнительное расширение (это своеобразные плагины для netfilter). Дополнительные расширения подгружаются с помощью параметра -m или --match. Так, например, если мы собираемся использовать критерии state, то мы должны явно указать это в строке правила: -m state левее используемого критерия. Отличие между явными и неявными необщими критериями заключается в том, что явные нужно подгружать явно, а неявные подгружаются автоматически.

            Во всех критериях можно использовать знак ! перед значением критерия. Это будет означать, что под данное правило подпадают все пакеты, которые не соответствуют данному параметру. Например: критерий --protocol ! tcp будет обозначать, что все пакеты, которые не являются TCP-протоколом подходят под действие правила. Однако последние версии iptables (в частности, 1.4.3.2 и выше), уже не поддерживают этот синтаксис и требуют использования не --protocol ! tcp, а ! --protocol tcp, выдавая следующую ошибку:

            Ниже в виде таблицы приведены часто используемые параметры отбора пакетов:

            • Одиночный хост: host.domain.tld, или IP адрес: 10.10.10.3
            • Пул-адресов (подсеть): 10.10.10.3/24 или 10.10.10.3/255.255.255.0
            Настойчиво не рекомендуется использовать доменные имена, для разрешения (резольва) которых требуются DNS-запросы, так как на этапе конфигурирования netfilter DNS может работать некорректно. Также, заметим, имена резольвятся всего один раз — при добавлении правила в цепочку. Впоследствии соответствующий этому имени IP-адрес может измениться, но на уже записанные правила это никак не повлияет (в них останется старый адрес). Если указать доменное имя, которое резольвится в несколько IP-адресов, то для каждого адреса будет добавлено отдельное правило.

            Состояние соединения. Доступные опции:

            • NEW (Все пакеты устанавливающие новое соединение)
            • ESTABLISHED (Все пакеты, принадлежащие установленному соединению)
            • RELATED (Пакеты, не принадлежащие установленному соединению, но связанные с ним. Например - FTP в активном режиме использует разные соединения для передачи данных. Эти соединения связаны.)
            • INVALID (Пакеты, которые не могут быть по тем или иным причинам идентифицированы. Например, ICMP ошибки не принадлежащие существующим соединениям)
            • и др. (более подробно в документации)

            Действия над пакетами

            Данный заголовок правильнее будет перефразировать в "Действия над пакетами, которые совпали с критериями отбора". Итак, для совершения какого-либо действия над пакетами, необходимо задать ключ -j (--jump) и указать, какое конкретно действие совершить.

            Действия над пакетами могут принимать следующие значения:

            Кроме указанных действий, существуют и другие, с которыми можно ознакомиться в документации (возможно, в скором времени я дополню статью в ходе освоения темы). У некоторых действий есть дополнительные параметры.

            В таблице ниже приведены примеры и описания дополнительных параметров:

            На этом закончим теорию о сетевом фильтре netfilter/iptables. В следующей статье я приведу практические примеры для усвоения данной теории.

            Резюме

            В данной статье мы рассмотрели очень кратко основные понятия сетевого фильтра в Linux. Итак, подсистема netfilter/iptables является частью ядра Linux и используется для организации различных схем фильтрации и манипуляции с сетевыми пакетами. При этом, каждый пакет проходит от сетевого интерфейса, в который он прибыл и далее по определенному маршруту цепочек, в зависимости от того, предназначен он локальной системе или "нелокальной". Каждая цепочка состоит из набора таблиц, содержащих последовательный набор правил. Каждое правило состоит из определенного критерия/критериев отбора сетевого пакета и какого-то действия с пакетом, соответствующего данным критериям. В соответствии с заданными правилами над пакетом может быть совершено какое-либо действие (Например, передача следующей/другой цепочке, сброс пакета, модификация содержимого или заголовков и др.). Каждая цепочка и каждая таблица имеет свое назначение, функциональность и место в пути следования пакета. Например для фильтрации пакетов используется таблица filter, которая содержится в трех стандартных цепочках и может содержаться в цепочках, заданных пользователем. Завершается путь пакета либо в выходящем сетевом интерфейсе, либо доставкой локальному процессу/приложению.

            netfilter и iptables в Linux: принципы работы, настройка

            netfilter (встроенные в ядро linux в отличие от ipchains умеет отслеживать соединения (stateful packet filtering), при этом пакеты обязательно дефрагментриуются; цепочки правил объединяются в таблицы различного назначения (filter, nat, mangle), используются специальные модули для различных протоколов (в т.ч. прикладного уровня). Также позволяет менять заголовки пакетов и помечать пакеты для дальнейшего использования при маршрутизации и управлении трафиком. В основном, работает на межсетевом уровне TCP/IP, но захватывает транспортный уровень (TCP, UDP)и уровень доступа к сети (MAC адреса).Одновременное использование данных из 2 пакетов по-прежнему невозможно, для настоящей фильтрации на прикладном уровне пользуйтесь прокси серверами.

            В статье описываются:

            • предварительные условия использования netfilter
            • основные понятия (таблицы, цепочки, правила) и путь пакета
            • отслеживание соединений
            • утилита управления цепочками iptables
            • действия (target)
            • шаблоны (match)
            • утилиты iptables-save и iptables-restore
            • сервис в Red Hat Linux
            • примеры и советы


            Предварительные условия

            Для работы netfilter необходимо иметь ядро 2.3.15 или более новое,
            при генерации которого включены CONFIG_NETFILTER, CONFIG_IP_NF_IPTABLES, CONFIG_IP_NF_FILTER (таблица filter), CONFIG_IP_NF_NAT (таблица nat), CONFIG_BRIDGE_NETFILTER, а также многочисленные дополнительные модули: CONFIG_IP_NF_CONNTRACK (отслеживание соединений), CONFIG_IP_NF_FTP (вспомогательный модуль для отслеживания FTP соединений), CONFIG_IP_NF_MATCH_* (дополнительные типы шаблонов соответствия пакетов: LIMIT, MAC, MARK, MULTIPORT, TOS, TCPMSS, STATE, UNCLEAN, OWNER), CONFIG_IP_NF_TARGET_* (дополнительные действия в правилах:REJECT, MASQUERADE, REDIRECT, LOG, TCPMSS), CONFIG_IP_NF_COMPAT_IPCHAINS для совместимости с прочие CONFIG_IP_NF_* и CONFIG_IP6_NF_*.Полезно также указать CONFIG_PACKET.

            Наличие netfilter в ядре определяется по файлам /proc/net/ip_tables_names (список используемых таблиц), /proc/net/ip_tables_targets (2.6) и /proc/net/ip_tables_matches (2.6).

            Управление осуществляется с помощью утилиты iptables.

            Управление дополнительными модулями ядра осуществляется с помощью разделяемых библиотек(см. /lib/iptables/) для утилиты iptables. netfilter позволяет эмулировать ipfwadm и ipchains с помощью модулей ядра (с некоторых пор перестали включаться в стандартное ядро), при этом модуль ip_tables необходимо
            выгрузить.

            Таблицы, цепочки, путь пакета

            iptables_route.jpg

            Приблизительная схема обработки пакетов (взята из NAG2, по-моему, ради красоты
            картинки художник пожертвовал истиной: пропал маршрут из второй точки маршрутизации на localhost,он не проходит через FORWARD):

            В таблицах nat и mangle имеются цепочки PREROUTING и POSTROUTING.Правила цепочки PREROUTING применяется к пакетам сразу после получения пакета на входе интерфейса перед выбором маршрута, а правила цепочки POSTROUTING непосредственно перед выводом пакета через интерфейс. В таблице nat нет цепочек INPUT и FORWARD.

            Реальная последовательность обработки входящего пакета, предназначенного для локального процесса такова:

            1. просматривается цепочка PREROUTING таблицы mangle (используется для преобразования пакетов),здесь же происходит отслеживание соединений
            2. просматривается цепочка PREROUTING таблицы nat (используется для DNAT,
              фильтровать здесь не стоит)
            3. маршрутизация: если пакет надо маршрутизовать вовне, то переходим к обработке проходящего пакета
            4. просматривается цепочка INPUT таблицы mangle
            5. просматривается цепочка INPUT таблицы filter

            Реальная последовательность обработки пакета, уходящего с нашего хоста такова:

            1. маршрутизация: определение исходящего адреса, адреса назначения, используемого интерфейса; если пакет маршрутизируется внутрь, то переходим к предыдущей процедуре (п. 1 или 4?)
            2. просматривается цепочка OUTPUT таблицы mangle, фильтровать здесь не стоит,
              здесь же происходит отслеживание локально создаваемых соединений
            3. просматривается цепочка OUTPUT таблицы nat (NAT для локально сгенерированных пакетов)
            4. повторная маршрутизация, т.к. в таблицах mangle и nat пакет мог быть изменён; если пакет маршрутизируется внутрь, то переходим к предыдущей процедуре (п. 1 или 4?)
            5. просматривается цепочка OUTPUT таблицы filter
            6. просматривается цепочка POSTROUTING таблицы mangle
            7. просматривается цепочка POSTROUTING таблицы nat (используется для SNAT, фильтровать здесь не стоит)

            Реальная последовательность обработки проходящего пакета (от п.3 первой процедуры):

            1. просматривается цепочка FORWARD таблицы mangle
            2. просматривается цепочка FORWARD таблицы filter
            3. повторная маршрутизация, т.к. в таблице mangle пакет мог быть изменён;
              если пакет маршрутизируется внутрь, то переходим к первой процедуре (п. 1 или 4?)
            4. просматривается цепочка POSTROUTING таблицы mangle
            5. просматривается цепочка POSTROUTING таблицы nat (используется для SNAT и Masquerading, фильтровать здесь не стоит)

            Текст и иллюстрации документации netfilter имеют множество разночтений, оставляя свободу воли (то ли пакетов, то ли разработчиков ;). Автор iptables-tutorial рекомендует использовать тестовый набор правил, записывающий в журнал имя каждой пройденной пакетом цепочки и таблицы.

            Отслеживание соединений

            netfilter отслеживает соединения с помощью модуля ip_conntrack (имеет параметр hashsize, задающий размер хеша) и протоколозависимых модулей (icmp, tcp, ftp, tftp, irc, amanda, sctp) при обработке цепочки PREROUTING таблицы nat (для локально сгенерированных пакетов при обработке цепочки OUTPUT) и хранит их в специальной таблице. При этом все пакеты обязательно дефрагментируется. Соединения удаляются из таблицы по истечению интервала ожидания при отсутствии очередного пакета. При выгрузке модуля (см. IPTABLES_MODULES_UNLOAD в /etc/sysconfig/iptables-config) таблица соединений очищается. Рассматриваемый пакет может находиться с точки зрения настройки (у ядра своя таблица состояний) в одном из 4 состояний относительно ранее отслеженных соединений:

            Таблицу текущих соединений можно посмотреть в файле /proc/net/ip_conntrack

            • тип протокола
            • номер протокола
            • осталось секунд до удаления этого соединения из таблицы
            • [состояние-соединения-в-терминах-ядра]
            • исходящий адрес
            • адрес назначения
            • исходящий порт или ICMP-тип
            • порт назначения или ICMP-код
            • [ICMP-идентификатор]
            • [UNREPLIED] (соединение в состоянии ESTABLISHED, но ждёт подтверждения от протоколозависимого модуля, например, это был второй пакет при установлении TCP-соединения)
            • ожидаемые адреса и порты (ICMP-тип и код) ответного пакета
            • [ASSURED] (соединение перешло в состояние ESTABLISHED и протоколозависимый модуль подтвердил наличие соединения, например, завершён третий этап установления TCP-соединения)
            • use=1 (?)

            Управление цепочками производится с помощью программы iptables.

            После загрузки определены цепочки (все с политикой ACCEPT) INPUT, FORWARD и OUTPUT в таблице filter; PREROUTING, POSTROUTING и OUTPUT в таблице nat;
            PREROUTING, INPUT, FORWARD, OUTPUT и POSTROUTING в таблице mangle. Удалить их нельзя. Формат команды:

            Действия (target)

            Действия (действие в недопустимом месте эквивалентно DROP), при завершении
            просмотра текущей цепочки, производится просмотр следующих по порядку таблиц:

            Шаблоны

            Параметры модуля расширения tcp

            Параметры модуля расширения udp

            Параметры модуля расширения icmp

            Параметры модуля расширения mac

            Параметры модуля расширения mark

            Параметры модуля расширения limit (защита от DoS атак или ограничение записей в журнал; используется модель дырявого ведра: задаётся объём ведра и скорость его самоопустошения, шаблону соответствуют пакеты, помещающиеся в ведро):

            Параметры модуля расширения iprange (задание интервалов IP-адресов)

            Параметры модуля расширения multiport (список портов, до 15 портов)

            Параметры модуля расширения length (длина пакета)

            Параметры модуля расширения owner (только в цепочке OUTPUT, не всегда срабатывает)

            Параметры модуля расширения pkttype

            Параметры модуля расширения recent (динамическая генерация правил по событию;
            ведётся несколько именованных списков событий, для каждого события записывается время, исходящий адрес, исходящий порт, число пакетов, TTL)

            Параметры модуля расширения state (состояние соединения согласно conntrack):

            Параметры модуля расширения conntrack (расширение возможностей модуля state):

            Параметры модуля расширения helper (протоколозависимый модуль отслеживания
            соединений):

            Параметры модуля расширения tos (также имеются модуля dscp, ecn)

            Параметры модуля расширения tcpmss (Maximum Segment Size in TCP, только для
            пакетов с SYN или SYN/ACK)

            Параметры модуля расширения ttl

            Параметры модуля расширения ah (IPSec, необходимо также указать номер протокола 51)

            Параметры модуля расширения esp (IPSec, необходимо также указать номер протокола 50)

            <Утилиты iptables-save и iptables-restore

            Тщательно составленные и отлаженные цепочки необходимо сохранять с помощью утилиты iptables-save, выводит на stdout, параметры:

            • -c (выводить счётчики)
            • -t имя-таблицы (выводить только указанную таблицу)

            Сохранённые ранее цепочки можно загрузить в ядро с помощью утилиты
            iptables-restore (читает с stdin, по умолчанию восстанавливаемые таблицы сбрасываются, параметры):

            • -c (восстанавливать счётчики)
            • -n (не сбрасывать восстанавливаемые таблицы)

            Сервис в Red Hat Linux

            В дистрибутивах Red Hat Linux имеется сервис iptables (управляемый обычными chkconfig и service) в /etc/rc.d/init.d с функциями:

            Примеры и советы

            При настройке правил на удалённом хосте рекомендуется оставлять себе пути
            отступления, например, перед внесением изменений добавить в crontab строку, возвращающую настройки обратно, если что-то пойдёт не так (/sbin/service iptables stop).

            Часто используемые правила должны быть в начале цепочки. Для дальнейшей оптимизации цепочка разбивается на подцепочки (например, по типу протокола).

            Пример настройки рабочей станции или небольшого внутреннего сервера:

            Этот пост September 21, 2007 at 12:42 pm опубликовал smolokhov в категории Linux, Безопасность. Желающие могут оформить RSS подписку на комменты. Both comments and trackbacks are currently closed.

            Читайте также: