Глубокое погружение в архитектуру Iptables и Netfilter

Firewalls - важный инструмент, который можно настроить для защиты ваших серверов и инфраструктуры. В экосистеме Linux + iptables + - это широко используемый инструмент брандмауэра, который взаимодействует с ядром `+ netfilter + 'инфраструктурой фильтрации пакетов. Для пользователей и администраторов, которые не понимают архитектуру этих систем, создание надежных политик брандмауэра может быть пугающим не только из-за сложного синтаксиса, но и из-за количества взаимосвязанных частей, присутствующих в платформе.

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

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

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

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

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

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

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

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

Как видите, имена встроенных цепочек отражают имена хуков + netfilter +, с которыми они связаны:

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

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

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

Мы говорили о таблицах и цепочках отдельно. Давайте рассмотрим, какие цепочки есть в каждой таблице. В этом обсуждении подразумевается дальнейшее обсуждение порядка оценки цепочек, зарегистрированных для одного хука. Если три таблицы имеют цепочки + PREROUTING +, в каком порядке они оцениваются?

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

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

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

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

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

Следует упомянуть специальный класс неконечной цели: цель прыжка. Цели перехода - это действия, в результате которых оценка перемещается в другую цепочку для дополнительной обработки. Мы довольно много говорили о встроенных цепочках, которые тесно связаны с хуками + netfilter + ', которые их вызывают. Однако `+ iptables + также позволяет администраторам создавать свои собственные цепочки для организационных целей.

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

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

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

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

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

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

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

Если вы хотите узнать больше о том, как выбирать эффективные политики + iptables +, ознакомьтесь с https://www.digitalocean.com/community/tutorials/how-to-choose-an-effective-firewall-policy-to- безопасные ваши серверы [это руководство].

Эти руководства помогут вам начать реализацию правил брандмауэра + iptables +: