Чем отличается таблица межсетевого экрана iptables от цепочки
Основы iptables для начинающих. Часть 1. Общие вопросы
Когда говорят о брандмауэре в Linux-системах в первую очередь вспоминают iptables, однако это не совсем верно, брандмауэром в Linux является netfilter, а iptables - одна из утилит для его настройки. Тем не менее именно iptables является стандартом интерфейса брандмауэра в Linux, а также созданных на его основе системах, например, RouterOS от Mikrotik. Поэтому знание iptables является обязательным для Linux-администраторов несмотря на то, что в новых дистрибутивах осуществляется постепенный переход на более новый инструмент управления - nftables, который, тем не менее, сохраняет совместимость со своим предшественником.
Изначально iptables может показаться довольно сложным, особенно если браться за него без достаточной теоретической подготовки. Многие начинающие администраторы раз за разом допускают одни и те же типовые ошибки, что и побудило нас к написанию данной статьи.
Если подходить к вопросу упрощенно, то можно рассматривать iptables как брандмауэр - специализированное ПО для фильтрации сетевого трафика и нас прежде всего должна интересовать практическая сторона, а именно сам процесс фильтрации. Поэтому многие моменты мы оставим за кадром, уделив больше внимания практическому применению инструмента. Но любая практика должна основываться на твердой основе теоретических знаний, необходимому минимуму которых мы посвятим эту статью.
iptables структурно состоит из таблиц, в которые входят цепочки, в свою очередь содержащие наборы правил. Существует распространенное заблуждение, что цепочки содержат в себе таблицы, но это неверно и в ряде случаев может привести к ошибочному пониманию принципа действия тех или иных наборов правил. Следует помнить, что верхний уровень иерархии составляют именно таблицы, каждая из которых предназначена для своей цели. Всего имеется пять таблиц, рассмотрим их подробнее:
- raw - предназначена для обработки пакетов прежде, чем они будут переданы системе conntrack, которая занимается отслеживанием состояния соединений и принадлежностью пакетов этим соединениям. Содержит встроенные цепочки PREROUTING и OUTPUT.
- mangle - используется для модификации некоторых заголовков (TTL, TOS) и маркировке пакетов и соединений, содержит цепочки PREROUTING, INPUT, FORWARD, OUTPUT и POSTROUTING.
- nat - предназначен для преобразования адресов и портов источника и назначения пакетов, встроенные цепочки: PREROUTING, OUTPUT, POSTROUTING.
- filter - применяется, собственно, для фильтрации пакетов, является таблицей по умолчанию, т.е. если таблица не указана явно, то используется filter, имеет цепочки INPUT, FORWARD и OUTPUT.
- security - используется для работы совместно с системами принудительного контроля доступа, такими как SELinux. Встроенные цепочки INPUT, FORWARD, OUTPUT.
Обратите внимание, что названия таблиц всегда пишутся в нижнем регистре, а цепочек - в ВЕРХНЕМ.
На практике вы обычно будете использовать таблицы filter и nat, в некоторых случаях - mangle, поэтому таблицы raw и security мы далее рассматривать не будем.
Внутри таблиц находятся цепочки. Существуют встроенные и пользовательские цепочки. Последние создаются непосредственно пользователями и могут применяться для построения сложных конфигураций обработки трафика. В отличие от встроенных цепочек их названия также принято писать в нижнем регистре.
Внутренних цепочек также пять:
- PREROUTING - используется для всего входящего трафика до принятия первого решения о маршрутизации
- INPUT - применяется для входящего трафика текущего узла
- FORWARD - через нее проходит транзитный трафик узла
- OUTPUT - применятся для исходящего трафика текущего узла
- POSTROUTING - используется для всего исходящего трафика после принятия всех решений о маршрутизации
После инициализации все цепочки пустые и не содержат никаких правил. Но каждая цепочка имеет действие по умолчанию (стандартно - ACCEPT), которое будет применено к пакету, если он прошел всю цепочку и не попал под действие ни одного правила.
Задача администратора - наполнить цепочки правилами. Каждое правило состоит из трех составляющих: критерия, действия и счетчика. Если пакет удовлетворяет критериям, то к нему применяется действие и он учитывается счетчиком. Если не указан критерий, то действие применяется ко всем пакетам. В отсутствии критерия и действия будет работать только счетчик, который считает не только количество пакетов, но и их размер в байтах.
Критериев может быть несколько, они комбинируются по принципу логического И, допускается также условие с отрицанием - И-НЕ, такое выражение будет истинным, если истинными являются все условия. Таким образом правило сработает если пакет удовлетворяет всем перечисленным критериям. В качестве критериев используются различные свойства пакетов и/или соединений, наиболее часто используются интерфейсы, IP-адреса источника и назначения, порты.
Действие выполняет какую-либо одну операцию с пакетом, разные таблицы допускают применение разных наборов действий, например, действие MARK используется в таблице mangle, а MASQUERADE - в таблице nat. Наиболее общими действиями являются ACCEPT, DROP и REJECT. Первое из них пропускает пакет, а два последних блокируют, при этом REJECT сообщает источнику об отказе, а DROP нет, поэтому его чаще всего используют для блокировки внешних пакетов, чтобы не давать потенциальному злоумышленнику лишней информации о работе сети.
Все действия делятся на две категории: терминальные и нетерминальные. Терминальные действия прекращают прохождение пакета по цепочке, к ним относятся все специфичные действия для таблиц filter и nat, нетерминальными являются действия специфичные для таблицы mangle.
Попав в цепочку пакет последовательно проходит правила в порядке их перечисления до первого срабатывания. Дальнейшее его движение зависит от типа действия, если действие нетерминальное - пакет продолжит движение по цепочке, иначе - покидает ее.
Рассмотрим схему выше. Пакет попадает в цепочку и происходит срабатывание первого правила, но так как действие LOG является нетерминальным, то пакет продолжает движение по цепочке. Следующим срабатывает правило 3, действие ACCEPT терминальное и поэтому пакет покидает цепочку.
При построении последовательности правил важно понимать, что первична именно таблица, внутри которой находится цепочка, в которой мы уже выстраиваем нужную последовательность правил. При этом правила разных таблиц, но одинаковых цепочек могут идти вперемешку, но выполняться они все равно будут в последовательности таблица - цепочка - набор правил.
Между тем правилом хорошего тона в администрировании является группировка правил согласно их логическому смыслу и порядку прохождения через брандмауэр, это повышает читабельность правил и позволяет легко разобраться в конфигурации брандмауэра даже увидев ее в первый раз.
Здесь мы подошли к еще одной важной теме - стандартному порядку прохождения пакетов через брандмауэр, именно эта схема часто является источником многих заблуждений, но исторически сложилось изображать ее именно так.
Глядя на нее, можно подумать, что таблицы находятся внутри цепочек, это неверно, но стандартный порядок прохождения таков, что одноименные цепочки таблиц проходятся последовательно, поэтому на схеме их объединяют для лучшего понимания логики процесса.
Итак, входящий пакет прежде всего попадает в цепочку PREROUTING таблицы mangle, затем передается в PREROUTING таблицы nat. Здесь мы можем выполнить маркировку пакетов и преобразование адреса назначения - DNAT. Затем принимается решение о маршрутизации, в зависимости от того предназначен пакет хосту или является транзитным будут задействованы либо цепочки INPUT, либо FORWARD таблиц mangle и filter.
Все основные действия по фильтрации пакетов производятся именно в таблице filter, при этом фильтрация локального и транзитного трафика производится отдельно. При составлении правил фильтрации следует учитывать, что у пакета может быть изменен адрес и порт назначения вследствие прохождения цепочки PREROUTING таблицы nat. Это актуально при пробросе портов на нестандартные номера, скажем, пришедший на адрес внешнего интерфейса и нестандартный порт пакет после выполнения над ним действия DNAT попадет в таблицу filter уже со стандартным портом и адресом внутреннего узла в качестве адреса назначения.
Локальные пакеты после таблицы filter передаются локальным процессам, на этом путь входящего пакета в системе заканчивается. В ответ локальный процесс формирует исходящий пакет и после решения о маршрутизации передает его в цепочки OUTPUT таблиц mangle, nat и filter. И если таблицы mangle и filter понятны, то наличие между ними таблицы nat требует отдельных пояснений.
Обычно для преобразования сетевых адресов в таблице nat используются цепочки PREROUTING и POSTROUTING, которые закрывают большинство типовых задач. Но бывают ситуации, когда преобразование сетевых адресов нужно выполнить отдельно для исходящих пакетов по критериям, которым могут удовлетворять и пакеты транзитные. В этом случае можно и нужно использовать цепочку OUTPUT таблицы nat. Хотя это достаточно редкий сценарий и в большинстве типовых случаев цепочки OUTPUT могут совсем не содержать правил.
После принятия всех решений о маршрутизации как локальные, так и транзитные пакеты попадают в цепочки POSTROUTING таблиц mangle и nat, здесь производятся окончательная обработка исходящих пакетов. Наиболее часто используется таблица nat и действия SNAT и MASQUERADE, используемые для изменения адреса источника пакета. Никакой фильтрации пакеты после этого не проходят. Это также важно понимать при построении правил.
Вне зависимости от типа и направления трафика следует помнить, что преобразование адресов назначения всегда производится до того, как пакет попадает в таблицу filter брандмауэра, а преобразование адресов источника после ее прохождения. Непонимание этого момента приводит к использованию неправильных критериев и неработоспособности на первый взгляд "верных" правил.
И еще раз закрепим стандартный порядок прохождения пакетов через брандмауэр, для транзитного трафика он выглядит так:
Самое важное, что следует понять из этой схемы, что транзитный трафик никогда не попадает в цепочки INPUT и OUTPUT, а преобразование адреса назначения (DNAT) выполняется перед фильтрацией.
Для локальных пакетов стандартный порядок будет следующим:
Прежде всего следует запомнить, что локальный трафик никогда не попадает в цепочки FORWARD. Также, в отличии от транзитного трафика, локальный представлен двумя видами пакетов: входящими и исходящими. Путь входящего пакета ограничивается цепочками PREROUTING и INPUT, а исходящего OUTPUT и POSTROUTING, т.е. если нам нужно выполнить преобразование адреса назначения (DNAT) для локального пакета, то мы должны сделать это в цепочке OUTPUT, потому что в PREROUTING такой пакет никогда не попадет.
Тоже самое касается и маркировки пакетов, если мы хотим обрабатывать ответы на входящие пакеты по каким-то собственным критериям, то маркировать нужно не пакеты, а соединения. Потому как путь локального пакета заканчивается локальным процессом, однако и входящий и исходящий пакет будут принадлежать одному соединению. Это же касается и транзитного трафика, маркировка пакета будет учитываться только при прохождении в одну сторону, маркировка соединения - для прохождения в обоих направлениях.
Несмотря на то, что приведенная нами схема является упрощенной, надеемся, что она поможет получить базовые знания о работе iptables и не допускать грубых ошибок при составлении правил, а также лучше понимать уже готовые конфигурации брандмауэра, которые мы приводим в наших решениях.
Основы iptables 1. Правила, таблицы, цепочки и отношения цепочек таблиц
1. Основные понятия, связанные с межсетевым экраном iptables netfilter
На самом деле iptables не является настоящим брандмауэром. Мы можем понимать его как прокси-сервер клиента. Пользователь реализует настройки безопасности пользователя в соответствующей «структуре безопасности» через прокси-сервер iptables. Эта «структура безопасности» является настоящим брандмауэром , Имя этого кадраnetfilter。
Netfilter - это реальная структура безопасности брандмауэра, а netfilter находится в пространстве ядра.
iptables - это фактически инструмент командной строки, расположенный в пространстве пользователя.Мы используем этот инструмент для работы с реальной структурой.
netfilter / iptables (далее iptables) представляет собой брандмауэр с фильтрацией пакетов на платформе Linux. Как и большинство программного обеспечения Linux, этот брандмауэр с фильтрацией пакетов является бесплатным и может заменить дорогостоящие коммерческие брандмауэры для полной фильтрации и запечатывания пакетов. Такие функции, как перенаправление и преобразование сетевых адресов (NAT).
Netfilter - это модуль обработки пакетов данных на базовом уровне операционной системы Linux. Он выполняет следующие функции:
Переводчик сетевых адресов
Изменение содержимого пакета данных
И функция межсетевого экрана для фильтрации пакетов
Итак, хотя мы используем службу iptables start для запуска «службы» iptables, но, если быть точным, iptables не имеет процесса-демона, поэтому это не служба в истинном смысле, а функция, предоставляемая ядром.
Два, основы работы с iptables
Это может быть непросто понять. Начнем с самого начала.
Следовательно, согласно приведенному выше рисунку, мы можем представить себе поток пакетов в некоторых распространенных сценариях:
В-третьих, концепция цепи
В-четвертых, концепция стола
Давайте подумаем над другим вопросом. Мы помещаем ряд правил в каждую «цепочку», но эти правила в чем-то похожи. Например, правила типа A фильтруют IP или порты, а правила типа B изменяют отчеты. Вэнь, тогда можем ли мы составить правила, выполняющие ту же функцию? Это должно быть возможно.
Мы называем набор правил с одной и той же функцией "таблицами", поэтому мы можем помещать правила с разными функциями в разные таблицы для управления, а iptables определил для нас 4 таблицы, каждая из которых соответствует разным , И правила, которые мы определяем, не могут выйти за рамки этих 4 функций.Поэтому, прежде чем изучать iptables, мы должны сначала понять роль каждой таблицы.
iptables предоставляет нам классификацию следующих правил, другими словами, iptables предоставляет нам следующие «таблицы»
таблица фильтров: отвечает за функцию фильтрации, межсетевой экран; модуль ядра: iptables_filter
nat table: трансляция сетевых адресов, функция трансляции сетевых адресов; модуль ядра: iptable_nat
необработанная таблица: отключить механизм отслеживания соединений, включенный в таблице nat; iptable_raw
Другими словами, все правила, которые мы настраиваем, являются правилами этих четырех категорий, или, другими словами, все правила существуют в этих 4 «таблицах».
Пять, отношения цепочки часов
Но нам нужно обратить внимание на то, что определенные «цепочки» предназначены для того, чтобы не содержать «определенных типов правил», так же как определенные «уровни» по своей сути не оснащены определенными функциями, например, «уровень» отвечает только за борьбу с наземными врагами. Нет возможности противовоздушной обороны. «Уровень B» отвечает только за атаку противников в воздухе. У него нет способности защищаться от пехоты. «Уровень C» может быть больше NB. Он может защищаться как от воздушных, так и от наземных врагов. «Уровень D» является самым сложным. Оборона.
Давайте посмотрим, какими возможностями обладает каждый «уровень», или, другими словами, посмотрим, в каких «таблицах» существуют правила каждой «цепочки».
Давайте возьмем для примера картинку, давайте посмотрим, в каких таблицах существуют все правила в «цепочке» предварительной маршрутизации.
Примечание. Следующий рисунок используется только для иллюстрации, в каких таблицах существуют правила в цепочке предварительной маршрутизации, и не описывает порядок таблиц.
Что означает эта картинка? Это означает, что «цепочка» предварительной маршрутизации имеет только функции, соответствующие таблице nat, исходной таблице и таблице mangle, поэтому правила предварительной маршрутизации могут быть сохранены только в таблице nat, исходной таблице и таблице mangle.
Итак, основываясь на вышеизложенных идеях, давайте подытожим, какие функции выполняет каждый «уровень», или, другими словами, в каких «таблицах» существуют правила в каждой «цепочке».
Правила PREROUTING могут существовать в: raw table, mangle table, nat table.
Правила INPUT могут существовать в: таблице mangle, таблице фильтрации (также есть таблица nat в centos7, а не в centos6).
Правила FORWARD могут существовать в: таблице изменений, таблице фильтров.
Правила OUTPUT могут существовать в: таблице необработанных таблиц, таблице преобразования, таблице фильтрации.
Правила POSTROUTING могут существовать в: mangle table, nat table.
но, В процессе фактического использования мы часто используем "таблицу" в качестве входных данных. , который определяет правила , Причина, по которой iptables вводится в соответствии с описанным выше процессом, заключается в том, что его легче понять с точки зрения входа с точки зрения «уровней», но для более плавного понимания их при реальном использовании мы также добавим сюда «таблицы». Перечислены отношения с "цепочкой",
Таблица (функция) <--> Цепочка (крючок):
В каких цепочках можно использовать правила в исходной таблице: PREROUTING, OUTPUT
В каких цепочках можно использовать правила в таблице mangle: PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING
nat Какие цепочки могут использоваться правила в таблице: PREROUTING, OUTPUT, POSTROUTING (INPUT в centos7, а не в centos6)
filter Какие цепочки могут использоваться правила в таблице: INPUT, FORWARD, OUTPUT
Фактически, нам нужно обратить внимание еще на один момент, потому что, когда пакет данных проходит через «цепочку», все правила текущей цепочки будут согласованы, но при сопоставлении всегда есть порядок, мы должны совпадать одно за другим, и мы сказали: Правила одного и того же типа функции будут собраны в «таблицу». Затем, какие правила в «таблице» будут выполняться наверху «цепочки». В это время должен быть приоритетный вопрос. «Цепочка» предварительной маршрутизации показана в качестве иллюстрации.
Правила в цепочке предварительной маршрутизации хранятся в трех таблицах, и приоритет выполнения правил в этих трех таблицах следующий:
raw --> mangle --> nat
Но мы знаем, что iptables определяет для нас 4 «таблицы». Когда они находятся в одной «цепочке», приоритет выполнения следующий.
Приоритетный порядок (от большего к меньшему):
raw --> mangle --> nat --> filter
Но, как мы уже говорили ранее, некоторые цепочки по своей сути не могут использовать правила из определенных таблиц. Поэтому правила в 4 таблицах в настоящее время находятся в одной цепочке только для выходной цепочки, которая является легендарным уровнем, который можно защитить с моря, земли и воздуха.
Для более удобного управления мы также можем создать настраиваемую цепочку в таблице и поместить в эту настраиваемую цепочку правила, установленные для определенного приложения, но настраиваемую ссылку нельзя использовать напрямую, и ее можно только Цепочка по умолчанию вызывается как действие для работы. Мы можем представить себе, что пользовательская цепочка является относительно «короткой» цепочкой. Все правила этой «короткой» цепочки созданы для определенного приложения, но это Короткую цепочку нельзя использовать напрямую, но ее необходимо «приварить» к определенной по умолчанию цепочке iptables, прежде чем ее можно будет использовать в IPtables. Вот почему определенная по умолчанию «цепочка» должна ссылаться на «пользовательскую цепочку» как на «действие». . Об этом позже, мы поговорим об этом позже, мы сможем лучше понять это на практике.
6. Процесс прохождения данных через межсетевой экран.
Объединив все приведенные выше описания, мы можем суммировать поток пакетов данных, проходящих через межсетевой экран, как на следующем рисунке:
Когда мы пишем правила Iptables, мы всегда должны помнить об этой диаграмме последовательности маршрутизации и гибко настраивать правила.
Здесь мы переписываем часто используемые соответствия для удобства просмотра соответствующих легенд.
В каких таблицах хранятся правила цепочки (соответствие цепочки таблице):
Правила PREROUTING могут существовать в: raw table, mangle table, nat table.
Правила INPUT могут существовать в: таблице mangle, таблице фильтров (в centos7 есть также таблица nat, но не в centos6).
Правила FORWARD могут существовать в: таблице изменений, таблице фильтров.
Правила OUTPUT могут существовать в: таблице необработанных таблиц, таблице преобразования, таблице фильтрации.
Правила POSTROUTING могут существовать в: mangle table, nat table.
В каких цепочках можно использовать правила в таблице (соответствие от таблицы к цепочке):
raw Какие цепочки могут использоваться правила в таблице: PREROUTING, OUTPUT
В каких цепочках можно использовать правила в таблице mangle: PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING
nat Какие цепочки могут использоваться правила в таблице: PREROUTING, OUTPUT, POSTROUTING (INPUT в centos7, а не в centos6)
filter Какие цепочки могут использоваться правила в таблице: INPUT, FORWARD, OUTPUT
Статус таблицы nat в centos7 на рисунке ниже больше не отмечен.
Семь, концепция правил
После разговора я говорю об этом снова. В приведенном выше описании мы упоминали правила, но не вдавались в подробности. Теперь мы поговорим об этом.
Правила: постарайтесь сопоставить каждый проходящий здесь пакет в соответствии с указанными условиями сопоставления.После успешного сопоставления он будет обработан действием обработки, указанным после правила;
Правила состоят из условий сопоставления и действий обработки.
(1) Условия соответствия
Условия сопоставления делятся на базовые условия сопоставления и расширенные условия сопоставления.
Основные условия сопоставления:
IP-адрес источника, IP-адрес назначения
Приведенный выше контент можно использовать в качестве основных условий сопоставления.
Расширенные условия соответствия:
В дополнение к приведенным выше условиям, которые можно использовать для сопоставления, существует множество других условий, которые могут использоваться для сопоставления. Эти условия обычно называются расширенными условиями. Эти расширенные условия фактически являются частью netfilter, только в форме модулей. Если вы хотите использовать эти условия , Вам необходимо полагаться на соответствующий модуль расширения.
Порт источника, порт назначения
Вышеупомянутый контент может использоваться как расширенное условие соответствия
(2) Действия по обработке
Действия обработки называются целями в iptables (это неточно, мы пока будем называть их так), и действия также можно разделить на базовые действия и расширенные действия.
Вот несколько часто используемых действий, и в следующих статьях будут приведены их подробные примеры и резюме:
ACCEPT: Разрешить передачу пакетов данных.
DROP: Отбросить пакет данных напрямую, не давая никакой ответной информации.В это время клиент почувствует, что его запрос вышел в море, и ответит по истечении периода ожидания.
SNAT: Преобразование исходного адреса для решения проблемы пользователей интрасети, использующих один и тот же адрес общедоступной сети для доступа в Интернет.
MASQUERADE: Это особая форма SNAT, подходящая для динамического и временного изменения IP.
DNAT: Перевод целевого адреса.
REDIRECT: Сделайте сопоставление портов на этой машине.
LOG: Запишите информацию журнала в файл / var / log / messages, а затем передайте пакет данных следующему правилу, то есть не выполняйте никаких других операций с пакетом данных, кроме записи, и все же позвольте следующему правилу соответствовать.
В цикле 4 статьи:
IPTABLES является утилитой (!), а не непосредственно фаерволом. Роль фаервола в Linux играет пакет Netfilter (в Linux с версии 2.4).
IPTABLES представляет собой утилиту для конфигурирования Netfilter.
Структура IPTABLES
Структуру можно представить так:
iptables -> Tables -> Chains -> Rules
Пакет приходит на IPTABLES > далее на таблицы (Tables) > попадает в цепочки (Chains) > проходит по правилам (Rules).
Фактически, IPTABLES состоит из трёх основных частей:
таблицы: фактически, являют собой набор цепочек;
цепочки: набор правил;
Таблицы IPTABLES
У IPTABLES имеется 4 встроенных типа таблиц.
1. Filter Table
2. NAT table
Таблица nat используется главным образом для преобразования сетевых адресов (Network Address Translation). Через эту таблицу проходит только первый пакет из потока. Преобразования адресов автоматически применяется ко всем последующим пакетам. Это один из факторов, исходя из которых мы не должны осуществлять какую-либо фильтрацию в этой таблице.
- PREROUTING chain – преобразование адресов DNAT (Destination Network Address Translation), фильтрация пакетов здесь допускается только в исключительных случаях;
- POSTROUTING chain – выполняется преобразование адресов SNAT (Source Network Address Translation), фильтрация пакетов здесь крайне нежелательна;
- OUTPUT chain – NAT для локально сгенерированных пакетов;
3. Mangle table
Включает в себя такие цепочки:
- PREROUTING chain
- OUTPUT chain
- FORWARD chain
- INPUT chain
- POSTROUTING chain
4. Raw table
Цепочки IPTABLES
Существует 5 типов стандартных цепочек, встроенных в систему:
- PREROUTING — для изначальной обработки входящих пакетов;
- INPUT — для входящих пакетов адресованных непосредственно локальному процессу (клиенту или серверу);
- FORWARD — для входящих пакетов перенаправленных на выход (заметьте, что перенаправляемые пакеты проходят сначала цепь PREROUTING , затем FORWARD и POSTROUTING );
- OUTPUT — для пакетов генерируемых локальными процессами;
- POSTROUTING — для окончательной обработки исходящих пакетов.
Cписок цепочек в таблицах IPTABLES
Схематично путь пакетов через IPTABLES хорошо представлен на следующей схеме:
Прохождение пакетов через IPTABLES
Правила IPTABLES
Правила имеют следующую структуру:
правило > цель > счётчик
Цели (targets) IPTABLES
Правило может содержать одно из следующих целей (или действий):
Критерий так же может использовать состояние пакета для принятия решений:
Введение и история
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.
Примеры прохождения цепочек
Последовательность обработки входящего пакета, предназначенного для локального процесса:
- Просматривается цепочка PREROUTING
- Просматривается таблица raw
- Просматривается таблица mangle, далее происходит отслеживание соединений
- Просматривается таблица nat (используется для DNAT - модификация адреса получателя)
- Просматривается таблица mangle
- Просматривается таблица filter
Последовательность обработки пакета, уходящего с нашего хоста:
- Маршрутизация: определение исходящего адреса, адреса назначения, используемого интерфейса; если пакет маршрутизируется внутрь (для локального хоста), то переходим к предыдущей процедуре
- Просматривается цепочка OUTPUT
- Просматривается таблица raw
- Просматривается таблица mangle, фильтровать здесь не стоит, здесь же происходит отслеживание локально создаваемых соединений
- Просматривается таблица nat (NAT для локально сгенерированных пакетов)
- Просматривается таблица filter
- Просматривается таблица mangle
- Просматривается таблица nat (используется для SNAT - модификация адреса источника, фильтровать здесь не стоит)
Последовательность обработки проходящего пакета (начинается от п.2 первой процедуры):
- Просматривается цепочка FORWARD
- Просматривается таблица mangle
- Просматривается таблица filter
- Просматривается таблица mangle
- Просматривается таблица 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
Состояние соединения. Доступные опции:
- NEW (Все пакеты устанавливающие новое соединение)
- ESTABLISHED (Все пакеты, принадлежащие установленному соединению)
- RELATED (Пакеты, не принадлежащие установленному соединению, но связанные с ним. Например - FTP в активном режиме использует разные соединения для передачи данных. Эти соединения связаны.)
- INVALID (Пакеты, которые не могут быть по тем или иным причинам идентифицированы. Например, ICMP ошибки не принадлежащие существующим соединениям)
- и др. (более подробно в документации)
Действия над пакетами
Данный заголовок правильнее будет перефразировать в "Действия над пакетами, которые совпали с критериями отбора". Итак, для совершения какого-либо действия над пакетами, необходимо задать ключ -j (--jump) и указать, какое конкретно действие совершить.
Действия над пакетами могут принимать следующие значения:
Кроме указанных действий, существуют и другие, с которыми можно ознакомиться в документации (возможно, в скором времени я дополню статью в ходе освоения темы). У некоторых действий есть дополнительные параметры.
В таблице ниже приведены примеры и описания дополнительных параметров:
На этом закончим теорию о сетевом фильтре netfilter/iptables. В следующей статье я приведу практические примеры для усвоения данной теории.
Резюме
В данной статье мы рассмотрели очень кратко основные понятия сетевого фильтра в Linux. Итак, подсистема netfilter/iptables является частью ядра Linux и используется для организации различных схем фильтрации и манипуляции с сетевыми пакетами. При этом, каждый пакет проходит от сетевого интерфейса, в который он прибыл и далее по определенному маршруту цепочек, в зависимости от того, предназначен он локальной системе или "нелокальной". Каждая цепочка состоит из набора таблиц, содержащих последовательный набор правил. Каждое правило состоит из определенного критерия/критериев отбора сетевого пакета и какого-то действия с пакетом, соответствующего данным критериям. В соответствии с заданными правилами над пакетом может быть совершено какое-либо действие (Например, передача следующей/другой цепочке, сброс пакета, модификация содержимого или заголовков и др.). Каждая цепочка и каждая таблица имеет свое назначение, функциональность и место в пути следования пакета. Например для фильтрации пакетов используется таблица filter, которая содержится в трех стандартных цепочках и может содержаться в цепочках, заданных пользователем. Завершается путь пакета либо в выходящем сетевом интерфейсе, либо доставкой локальному процессу/приложению.
Читайте также:
- ip_conntrack_tcp_be_liberal
