Архитектура Iptables и Netfilter

A Межсетевой экран — это устройство безопасности (аппаратное/программное обеспечение), которое защищает сеть, фильтруя трафик и блокируя нежелательный/несанкционированный доступ к частным данным. Наличие надлежащего межсетевого экрана важно для защиты ваших серверов и инфраструктуры. Он может не только блокировать нежелательный трафик, но и предотвращать заражение системы вредоносным ПО.

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

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

Iptables и Netfilter

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

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

Перехватчики Netfilter

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

Вот перехватчики, представляющие различные четко определенные точки в сетевом стеке:

• NF_IP_PRE_ROUTING: этот перехватчик активируется любым входящим трафиком. Активация происходит до принятия какого-либо решения о маршрутизации относительно назначения пакета.

• NF_IP_LOCAL_IN: этот перехватчик активируется после маршрутизации входящего пакета. Пакет также должен быть предназначен для локальной системы.

• NF_IP_FORWARD: этот перехватчик также активируется после маршрутизации входящего пакета. Однако он срабатывает, если пакет должен быть перенаправлен на другой хост.

• NF_IP_LOCAL_OUT: любой локальный исходящий трафик активирует этот перехватчик, как только попадает в сетевой стек.

• NF_IP_POST_ROUTING: этот перехватчик активируется любым исходящим/пересылаемым трафиком после того, как произошла маршрутизация, до того, как пакет попадет в сеть.

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

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

Для организации своих правил межсетевой экран iptables использует таблицы. Таблицы классифицируют правила на основе типа принимаемых ими решений. Например, если правило относится к NAT (трансляции сетевых адресов), то оно помещается в таблицу nat. Аналогично, если правило определяет, разрешить или отклонить пакет, направляющийся к месту назначения, оно добавляется в filter таблицу.

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

Вот встроенные цепочки iptables. Интересно, что имена цепочек также отражают имя связанного netfilter хуков:

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

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

Таблицы iptables

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

• Таблица filter

В iptables , таблица filter является одной из самых популярных. Она используется для определения того, будет ли пакет допущен к месту назначения или нет. В терминологии брандмауэров этот процесс называется “фильтрацией” пакетов.

Именно к функциям таблицы filter обращаются люди, когда обсуждают брандмауэры (в большинстве случаев).

• Таблица nat

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

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

• Таблица mangle

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

Эта таблица также позволяет ставить внутреннюю метку ядра “mark” на пакет, которую другие таблицы и сетевые инструменты могут использовать для дальнейшей обработки. Эта метка не затрагивает сам пакет, а добавляет метку к представлению пакета в ядре.

• Таблица raw

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

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

• Таблица security

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

Метки SELinux могут применяться как к отдельным пакетам, так и к соединениям.

Цепочки, реализованные в каждой таблице

До сих пор мы говорили о таблицах и цепочках отдельно. Пришло время разобрать, какие цепочки доступны в каждой таблице. Эта тема расширяет обсуждение порядка оценки цепочек, зарегистрированных на одном и том же хуке. Например, что произойдет, если три таблицы имеют PREROUTING-цепочки? Каков порядок их оценки?

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

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

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

Хуки (столбцы), которые будет вызывать пакет, зависят от природы пакета (входящий/исходящий), принимаемых решений о маршрутизации и соответствия пакета критериям фильтрации.

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

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

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

• Входящие пакеты, предназначенные для локальной системы: PREROUTING >> INPUT

• Входящие пакеты, предназначенные для другого хоста: PREROUTING >> FORWARD >> POSTROUTING

• Локально сгенерированные пакеты: OUTPUT >> POSTROUTING

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

Правила Iptables

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

• Соответствие

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

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

• Цели

Цель — это действие, предпринимаемое, когда пакет соответствует критериям сопоставления правила. Как правило, цели делятся на две группы:

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

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

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

Пользовательские цепочки

Существует также особый класс непрерывающих целей: цель перехода (jump target). Цели перехода — это действия, выполняемые, когда обработка переходит от одной цепочки к другой для дополнительной обработки. До сих пор мы говорили о встроенных цепочках, которые тесно связаны с netfilter хуками, которые их вызывают. Однако iptables также позволяет администраторам создавать свои собственные цепочки.

Правила в пользовательских цепочках также похожи на правила во встроенных цепочках. Ключевое отличие заключается в том, что пользовательские цепочки доступны только путем “перехода” к ним из какого-либо правила. Это связано с тем, что пользовательские цепочки не связаны ни с какими netfilter хуками.

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

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

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

При обсуждении raw таблицы и критериев соответствия состояния соединения мы обсуждали систему отслеживания соединений, реализованную поверх netfilter архитектуры. Эта функция позволяет iptables  просматривать пакеты в контексте текущего соединения. Система отслеживания соединений также предоставляет iptables необходимым функционалом для выполнения операций с отслеживанием состояния (“stateful”).

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

Система проверяет каждый пакет на соответствие набору существующих соединений. При необходимости система обновит состояние существующих соединений или создаст новые. Пакеты, помеченные целью 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: Аналогично SNAT, это означает виртуальное состояние, когда адрес назначения изменяется операцией NAT. Система отслеживания соединений обрабатывает его так, чтобы знать, что нужно преобразовать адрес назначения обратно при маршрутизации ответных пакетов.

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

Заключение

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

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

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

Приятной работы!