Мастерство iptables: Глубокое погружение в архитектуру и администрирование Netfilter

Архитектура Netfilter и фундаментальные принципы работы iptables

Когда администратор вводит в консоли команду iptables -A INPUT -s 192.168.1.50 -j DROP, система мгновенно перестает отвечать на пинги с указанного адреса. Возникает иллюзия, что утилита iptables постоянно висит в оперативной памяти, перехватывает сетевой трафик, анализирует IP-адреса и уничтожает неугодные пакеты. Это одно из самых глубоких и распространенных заблуждений в системном администрировании. Утилита iptables не фильтрует ни одного байта трафика. Она вообще не работает с сетью напрямую. Если удалить исполняемый файл /sbin/iptables с сервера сразу после применения правил, сервер продолжит безупречно блокировать трафик.

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

Пространство ядра и пространство пользователя

Сетевой стек Linux — это сложный конвейер внутри ядра (kernel-space), который принимает электрические сигналы от сетевой карты, собирает их в кадры Ethernet, извлекает IP-пакеты, проверяет контрольные суммы и передает данные приложениям. Долгое время этот конвейер был закрытым: пакет либо достигал цели, либо отбрасывался из-за сетевых ошибок.

!Расти Рассел, создатель архитектуры Netfilter

В конце 1990-х годов разработчик Расти Рассел (Rusty Russell) спроектировал и внедрил в ядро Linux архитектуру Netfilter. Идея заключалась в том, чтобы сделать сетевой стек расширяемым. Netfilter — это набор специальных точек перехвата (хуков), аккуратно врезанных в исходный код сетевого стека ядра. Когда пакет проходит через такую точку, ядро приостанавливает его нормальное движение и проверяет, не зарегистрированы ли для этой точки какие-либо правила фильтрации или модификации. Если правила есть, ядро выполняет их, а затем (если пакет не был уничтожен) возвращает его на конвейер.

Утилита iptables — это всего лишь программа в пользовательском пространстве (user-space). Ее единственная задача — транслировать понятные человеку команды (с ключами -A, -p, -j) в бинарный формат и передать их ядру через системные вызовы. Как только ядро приняло эти правила и разместило их в своей памяти, работа iptables завершается. Всю тяжелую работу по побайтовому сравнению заголовков пакетов на скорости в миллионы пакетов в секунду выполняет ядро Linux посредством фреймворка Netfilter.

Анатомия перехвата: Пять хуков Netfilter

Сетевой пакет не материализуется в системе случайным образом. Он всегда имеет вектор движения. Пакет может прийти извне и предназначаться локальному процессу (например, веб-серверу Nginx). Он может быть сгенерирован самим Nginx и отправлен наружу. Либо сервер может выступать в роли маршрутизатора, принимая пакет на одном интерфейсе и отправляя через другой.

Чтобы контролировать трафик на всех этапах, Netfilter предоставляет ровно пять точек перехвата (хуков) для протокола IPv4. Понимание их физического расположения в коде ядра — ключ к диагностике любых сетевых проблем.

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

NF_INET_LOCAL_IN (Локальный вход). Если после этапа PRE_ROUTING таблица маршрутизации ядра определяет, что IP-адрес назначения пакета принадлежит одному из локальных интерфейсов сервера, пакет направляется вверх по стеку к приложениям. Прямо перед тем, как отдать данные приложению, срабатывает этот хук. Здесь происходит 90% блокировок входящего мусорного трафика.

NF_INET_FORWARD (Пересылка). Если сервер настроен как маршрутизатор (включен ip_forward), а IP-адрес назначения пакета принадлежит другой сети, пакет направляется транзитом. Он минует локальные приложения и попадает в этот хук. Пакеты, проходящие через FORWARD, никогда не попадают в LOCAL_IN или LOCAL_OUT.

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

NF_INET_POST_ROUTING (Пост-маршрутизация). Это последняя точка перед тем, как пакет будет передан драйверу сетевой карты для отправки в кабель. Сюда стекаются как транзитные пакеты (после FORWARD), так и локально сгенерированные (после LOCAL_OUT). Здесь ядро уже точно знает, через какой интерфейс уходит пакет, что делает этот хук единственно верным местом для подмены адреса источника (SNAT и Masquerade).

!Схема расположения хуков Netfilter в сетевом стеке ядра Linux

Критически важный архитектурный элемент, вокруг которого строятся хуки — это Routing Decision (Решение о маршрутизации). В сетевом стеке оно принимается дважды:

Первое решение (Pre-Routing Decision) происходит после хука PRE_ROUTING. Ядро смотрит на Destination IP и решает: отправить пакет наверх (в LOCAL_IN) или насквозь (в FORWARD).

Второе решение (Local Routing Decision) происходит перед хуком LOCAL_OUT. Когда локальный процесс создает пакет, ядро должно определить, через какой сетевой интерфейс его выпустить, чтобы он достиг цели.

Таблицы и Цепочки: Матрица обработки

Хуки ядра — это точки вмешательства. Но как организовать сами правила? Если свалить тысячи правил в одну кучу на каждом хуке, ядро будет тратить слишком много процессорного времени на их перебор. Для структурирования логики iptables вводит абстракции: Таблицы (Tables) и Цепочки (Chains).

Цепочки (Chains)

Цепочка — это прямой пользовательский аналог хука Netfilter. Их названия пишутся в верхнем регистре и жестко привязаны к точкам перехвата:

Хук NF_INET_PRE_ROUTING Цепочка PREROUTING

Хук NF_INET_LOCAL_IN Цепочка INPUT

Хук NF_INET_FORWARD Цепочка FORWARD

Хук NF_INET_LOCAL_OUT Цепочка OUTPUT

Хук NF_INET_POST_ROUTING Цепочка POSTROUTING

Таблицы (Tables)

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

Filter (Фильтрация). Таблица по умолчанию. Ее единственная задача — решать, пропустить пакет или уничтожить.

NAT (Network Address Translation). Используется исключительно для трансляции адресов (подмена IP источника или назначения) и проброса портов. Особенность таблицы NAT в том, что через нее проходит только первый пакет нового соединения. Остальные пакеты транслируются ядром автоматически на основе созданного состояния.

Mangle (Искажение). Применяется для сложной модификации пакетов: изменения поля TTL (Time To Live), изменения маркеров QoS (Quality of Service) или установки внутренних меток ядра для сложной маршрутизации.

Raw (Сырые данные). Позволяет работать с пакетами до того, как за них возьмется механизм отслеживания состояний (conntrack). Используется для освобождения определенного трафика от ресурсоемкого трекинга соединений.

Security. Узкоспециализированная таблица для установки контекстов безопасности SELinux на сетевые пакеты. В базовом администрировании применяется редко.

Пересечение таблиц и цепочек

Главная сложность iptables, вызывающая ступор у новичков — это понимание того, что не каждая таблица существует в каждой цепочке. Архитектура Netfilter строго регламентирует, где какая операция имеет смысл.

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

С другой стороны, таблица nat для подмены адреса назначения (DNAT) доступна в цепочке PREROUTING, но недоступна в INPUT. Если вы хотите пробросить порт, вы обязаны сделать это до принятия решения о маршрутизации, иначе ядро отбросит пакет, адресованный на закрытый порт, еще до того, как вы попытаетесь его перенаправить.

!Интерактивная трассировка пакета через таблицы и цепочки iptables

Анатомия правила: Критерии и Действия

Каждое правило в iptables, помещенное в конкретную таблицу и цепочку, состоит из двух логических частей: Match (Критерий совпадения) и Target (Действие).

Критерии (Matches)

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

Базовыми: протокол (-p tcp), IP источника (-s 10.0.0.5), IP назначения (-d 8.8.8.8), входящий интерфейс (-i eth0).

Расширенными (через модули): порт назначения (--dport 80), состояние соединения (-m state --state ESTABLISHED), лимиты скорости (-m limit --limit 10/sec), совпадение по содержимому пакета (-m string).

Если в правиле не указан ни один критерий (например, iptables -t filter -A INPUT -j DROP), оно становится абсолютным и применяется к любому пакету, попавшему в эту цепочку.

Действия (Targets)

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

Завершающие действия (Terminating Targets) немедленно прекращают прохождение пакета по текущей цепочке.

ACCEPT: Пакет признан легитимным. Он немедленно покидает текущую цепочку и передается дальше по конвейеру Netfilter. Ядро больше не проверяет его по нижестоящим правилам в этой цепочке.

DROP: Пакет молча уничтожается. Ядро освобождает память, выделенную под пакет, и не отправляет отправителю никаких уведомлений. Для отправителя это выглядит как черная дыра — запрос просто уходит в таймаут.

REJECT: Пакет уничтожается, но ядро активно формирует и отправляет отправителю ICMP-ответ (например, "Destination Port Unreachable"). Это вежливый отказ, который позволяет приложению на стороне клиента сразу закрыть соединение, а не ждать таймаута.

Незавершающие действия (Non-terminating Targets) выполняют операцию, но заставляют пакет продолжить движение по правилам ниже.

LOG: Записывает информацию о пакете в системный журнал ядра (dmesg/syslog). Пакет при этом не блокируется и переходит к следующему правилу.

MARK: Устанавливает внутреннюю метку на пакет для дальнейшей обработки утилитой iproute2.

Линейная обработка и Политика по умолчанию

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

Представьте цепочку INPUT таблицы filter, в которой 1000 правил. Поступает пакет. Ядро берет первое правило и проверяет критерии. Если совпадения нет, ядро переходит ко второму правилу. Если пакет совпадает с критериями на 500-м правиле и действие — DROP, пакет уничтожается, а правила с 501 по 1000 даже не рассматриваются.

Именно поэтому порядок правил имеет критическое значение. Если первым правилом в цепочке стоит блокировка всей подсети (-s 192.168.1.0/24 -j DROP), а вторым — разрешение для конкретного администраторского IP из этой же подсети (-s 192.168.1.50 -j ACCEPT), администратор никогда не получит доступ. Пакет будет уничтожен на первом же шаге.

Но что происходит, если пакет прошел через все 1000 правил в цепочке, и ни одно из них не подошло? Здесь вступает в игру Default Policy (Политика по умолчанию). Каждая стандартная цепочка имеет базовую политику, которая применяется к пакету, «выпавшему» из конца списка. Обычно это ACCEPT (разрешить все, что явно не запрещено) или DROP (запретить все, что явно не разрешено). Настройка политики по умолчанию в DROP для цепочек INPUT и FORWARD — это нулевой шаг в построении концепции "Default Deny" (запрет по умолчанию), на которой базируется безопасность любого современного сервера.

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

Автоматизация, сохранение конфигурации и интеграция правил в современные дистрибутивы Linux

Идеально выверенная архитектура межсетевого экрана, использующая сложные деревья пользовательских цепочек, метки conntrack и динамические списки IPset, обладает одним критическим свойством: она существует исключительно в оперативной памяти ядра. Любая перезагрузка сервера, падение питания или паника ядра мгновенно уничтожают конфигурацию, оставляя систему либо полностью открытой, либо недоступной (в зависимости от политик по умолчанию дистрибутива). Утилита iptables — это лишь инструмент доставки инструкций в Netfilter, она не занимается персистентным хранением данных на накопителе.

Переход от ручного ввода команд к автоматизированному управлению конфигурацией требует понимания того, как правила сериализуются, как ядро обрабатывает массовые обновления и как сетевой экран взаимодействует с системой инициализации (systemd) и высокоуровневыми оркестраторами контейнеров.

Анатомия сохранения: формат iptables-save и атомарные транзакции

Попытка сохранить правила путем записи последовательности команд iptables -A ... в bash-скрипт — распространенная архитектурная ошибка. Выполнение такого скрипта происходит последовательно. Если скрипт начинается с очистки правил (iptables -F), а затем добавляет сотни новых строк, возникает окно уязвимости (Race Condition). В течение тех миллисекунд или секунд, пока скрипт обрабатывается интерпретатором, сервер либо отбрасывает легитимный трафик, либо пропускает вредоносный. Более того, ошибка синтаксиса на середине скрипта оставит брандмауэр в полунастроенном, непредсказуемом состоянии.

Для решения этой проблемы созданы утилиты сериализации и десериализации: iptables-save и iptables-restore. Они работают не с отдельными командами, а с атомарными транзакциями.

Вывод iptables-save имеет строгую структуру, оптимизированную для машинного чтения и быстрой загрузки в ядро:

Разбор синтаксиса дампа:

Определение таблицы начинается со знака звездочки (filter, nat).

Декларация цепочек начинается с двоеточия (:ИМЯ ПОЛИТИКА [пакеты:байты]). Это позволяет сразу задать политики по умолчанию (Default Policy) и, при необходимости, восстановить счетчики трафика.

Правила записываются без вызова самого бинарника iptables и без указания таблицы (она уже определена блоком выше).

Ключевое слово COMMIT является триггером применения.

Когда iptables-restore читает этот файл, он не отправляет правила в ядро по одному. Он формирует единый блок данных и передает его подсистеме Netfilter через сокет Netlink. Ядро применяет весь набор правил одномоментно (атомарно). Сетевой стек переключает указатель с набора старых правил на новые за одну операцию. Пакет, проходящий через стек в этот момент, будет обработан либо полностью старым набором, либо полностью новым — промежуточных состояний не существует.

По умолчанию iptables-restore полностью очищает (flush) текущие правила перед применением новых. Если необходимо добавить правила из файла к существующим, используется ключ --noflush (или -n).

Безопасное применение правил: механизм iptables-apply

При удаленном администрировании серверов изменение правил фильтрации всегда сопряжено с риском отрезать себе доступ (например, опечатка в порту SSH или неверный IP-адрес администратора). Выполнение iptables-restore < rules.v4 применит правила атомарно, но если в них ошибка, SSH-сессия зависнет, и потребуется физический доступ к консоли сервера.

Для защиты от «выстрела в ногу» применяется утилита iptables-apply. Она работает по принципу подтверждения изменения настроек дисплея в операционных системах:

Утилита применяет новый файл конфигурации.

Выводит в консоль запрос: "Can you establish a connection to the server? (y/N)".

Запускает таймер (по умолчанию 10 секунд).

Если администратор нажимает y, правила фиксируются.

Если таймер истекает (что означает потерю связи) или администратор нажимает N, утилита автоматически выполняет откат (rollback) к предыдущему состоянию.

Синтаксис использования: iptables-apply -t 20 /etc/iptables/new_rules.v4 (задаст таймаут в 20 секунд).

Интеграция с systemd в современных дистрибутивах

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

Семейство Debian/Ubuntu (netfilter-persistent)

В этих дистрибутивах стандартом де-факто является пакет iptables-persistent (который под капотом устанавливает netfilter-persistent).

При установке пакет создает директорию /etc/iptables/ с двумя файлами: rules.v4 и rules.v6. Systemd-сервис netfilter-persistent.service настроен на запуск на этапе network-pre.target. Это критически важно: правила загружаются в ядро до того, как сетевые интерфейсы (eth0, ens33) получат IP-адреса и поднимут линки. Это исключает утечку трафика в момент загрузки ОС.

Для сохранения текущей активной конфигурации в файл используется команда: netfilter-persistent save (или iptables-save > /etc/iptables/rules.v4).

Семейство RHEL/CentOS/Rocky Linux (iptables-services)

В экосистеме Red Hat по умолчанию работает высокоуровневый менеджер firewalld. Если администратор принимает решение использовать чистый iptables, firewalld необходимо полностью остановить и отключить (systemctl disable --now firewalld), иначе их правила будут конфликтовать, и firewalld периодически будет затирать пользовательские цепочки.

Вместо него устанавливается пакет iptables-services. Он предоставляет сервис iptables.service и хранит конфигурацию в файле /etc/sysconfig/iptables. Сохранение правил выполняется командой: service iptables save (или libexec/iptables/iptables.init save).

Оркестрация зависимостей: проблема старта IPset

Использование расширения IPset для хранения больших массивов адресов (O(1) при поиске) создает архитектурную проблему при загрузке системы. Списки IPset, как и правила iptables, живут только в оперативной памяти.

Возникает жесткая зависимость: если в iptables-save есть правило вида -A INPUT -m set --match-set BLACKLIST src -j DROP, то при выполнении iptables-restore ядро проверит наличие сета BLACKLIST. Если сет еще не создан, транзакция завершится с фатальной ошибкой iptables-restore: line X failed, и ни одно правило не будет применено. Сервер загрузится без защиты.

Следовательно, списки IPset должны быть восстановлены строго до старта сервиса iptables.

Реализация этого механизма требует создания собственного systemd-юнита. Сначала текущие сеты сохраняются на диск: ipset save > /etc/ipset.conf

Затем создается файл /etc/systemd/system/ipset.service:

Директива Before= гарантирует, что systemd выполнит ipset restore до того, как попытается загрузить правила Netfilter. Директива ExecStop= обеспечивает автоматическое сохранение динамически добавленных IP-адресов в списки (например, демоном fail2ban) при штатной перезагрузке сервера.

Симбиоз и конфликты с контейнеризацией (Docker)

Внедрение Docker на сервер с настроенным iptables часто приводит к разрушению логики маршрутизации. Демон Docker активно вмешивается в сетевой стек Linux. Он автоматически создает правила в таблице nat для проброса портов и в таблице filter (цепочка FORWARD) для изоляции сетей контейнеров.

Конфликт проявляется в двух сценариях:

Если перезапустить сервис iptables (или выполнить iptables-restore), все динамические правила Docker будут стерты. Контейнеры потеряют связь с внешним миром.

Если администратор пишет запрещающие правила в цепочку INPUT, они не защищают порты контейнеров. Docker пробрасывает порты через PREROUTING в FORWARD. Пакет, адресованный порту контейнера, маршрутизируется транзитом и вообще не попадает в хук INPUT.

Для корректной интеграции пользовательских правил и Docker используется специальная цепочка DOCKER-USER.

При старте Docker создает цепочку DOCKER-USER и помещает её в самое начало стандартной цепочки FORWARD. Docker гарантирует, что эта цепочка никогда не будет им очищена или изменена. Любые правила, которые администратор хочет применить к транзитному трафику контейнеров (например, ограничить доступ к опубликованному порту базы данных только с определенных внешних IP), должны помещаться именно сюда.

Политика по умолчанию для DOCKER-USER — RETURN. Это значит, что если пакет не совпал с правилами администратора, он возвращается в FORWARD и передается на обработку стандартным правилам изоляции Docker.

Пример защиты порта контейнера: iptables -I DOCKER-USER -p tcp --dport 5432 -s 198.51.100.0/24 -j RETURN iptables -A DOCKER-USER -p tcp --dport 5432 -j DROP

В этом сценарии трафик к PostgreSQL разрешен только из доверенной подсети. Все остальные пакеты отбрасываются до того, как Docker попытается их смаршрутизировать во внутреннюю сеть моста (bridge).

Трансляция абстракций: iptables-legacy против iptables-nft

Развитие ядра Linux привело к созданию подсистемы nftables, призванной заменить архаичный код Netfilter. Однако экосистема скриптов, панелей управления и знаний администраторов, завязанных на синтаксис iptables, оказалась слишком огромной, чтобы отказаться от неё одномоментно.

В современных дистрибутивах (начиная с Debian 10, RHEL 8, Ubuntu 20.04) при вводе команды iptables администратор на самом деле взаимодействует не с классическим Netfilter, а с транслятором iptables-nft.

Проверить текущий бэкенд можно с помощью ключа версии: iptables -V Вывод iptables v1.8.7 (nf_tables) означает использование транслятора. Вывод iptables v1.8.7 (legacy) означает работу с классическими модулями ядра.

Слой xtables-nft принимает привычные команды (например, -A INPUT -p tcp --dport 80 -j ACCEPT) и на лету компилирует их в байт-код nftables, загружая в ядро через API новой подсистемы. С точки зрения автоматизации и сохранения конфигурации, утилиты iptables-save и iptables-restore продолжают работать абсолютно прозрачно. Они генерируют и читают классический дамп, скрывая от администратора тот факт, что внутри ядра эти правила теперь представлены в виде таблиц и наборов nft.

Однако смешивание бэкендов недопустимо. Если часть правил загружена через iptables-legacy, а часть (например, демоном Docker) через iptables-nft, в ядре образуются два независимых набора хуков. Пакет будет проходить сначала через один межсетевой экран, затем через второй, что приведет к непредсказуемым блокировкам, дублированию NAT-трансляций и невозможности отладки через TRACE. Управление бэкендом осуществляется через систему альтернатив дистрибутива (например, update-alternatives --config iptables в Debian/Ubuntu).

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

Таблицы и цепочки: детальная логика и жизненный цикл пакета в стеке

Сетевой инженер настраивает сервер и сталкивается с аномалией: входящие пакеты на 80-й порт бесследно исчезают. Команда iptables -L показывает абсолютно пустую таблицу filter с политиками ACCEPT по умолчанию. Ни одного запрещающего правила нет, но трафик не проходит. Проблема кроется в том, что filter — это лишь одна из комнат в огромном лабиринте сетевого стека Linux. Пакет мог быть отброшен в таблице raw, изменён до неузнаваемости в mangle или перенаправлен в другой интерфейс таблицей nat ещё до того, как ядро вообще задумалось о фильтрации. Без понимания точного маршрута пакета через все таблицы и цепочки диагностика превращается в слепой перебор вариантов.

Архитектурная матрица: почему не всё доступно везде

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

| Таблица / Цепочка | PREROUTING | INPUT | FORWARD | OUTPUT | POSTROUTING | | :--- | :---: | :---: | :---: | :---: | :---: | | raw | Да | Нет | Нет | Да | Нет | | mangle | Да | Да | Да | Да | Да | | nat | Да (DNAT) | Да | Нет | Да (DNAT) | Да (SNAT) | | filter | Нет | Да | Да | Да | Нет | | security | Нет | Да | Да | Да | Нет |

Эта матрица диктует порядок обработки. Когда пакет попадает в определенный хук (например, PREROUTING), ядро не просто выполняет все правила подряд. Оно вызывает таблицы в строго зашитом приоритете. Для PREROUTING этот приоритет всегда таков: сначала raw, затем mangle, затем nat. Изменить этот порядок средствами пользовательского пространства невозможно.

!Полная схема прохождения пакета в Netfilter

Фаза Ingress: рождение пакета в стеке

Жизненный цикл любого пакета, пришедшего извне (через физический сетевой адаптер, виртуальный интерфейс или туннель), начинается с аппаратного прерывания, копирования в кольцевой буфер (Ring Buffer) и передачи в сетевой стек ядра. Как только ядро формирует структуру sk_buff (socket buffer), пакет попадает в первую точку перехвата — PREROUTING.

Здесь пакет проходит через три таблицы:

Таблица raw. Это самая ранняя точка вмешательства администратора. Главная и практически единственная задача этой таблицы — управление подсистемой Connection Tracking (conntrack). Если пакет совпадает с правилом, у которого действие (target) установлено как NOTRACK, ядро помечает этот пакет специальным флагом. В результате подсистема отслеживания состояний полностью проигнорирует его. Это критически важно для защиты от DDoS-атак: обработка пакета без создания записи в таблице состояний требует в разы меньше ресурсов CPU и оперативной памяти.

Скрытый этап: Conntrack. Сразу после таблицы raw, но до таблицы mangle, пакет попадает в невидимый для iptables обработчик. Ядро проверяет, принадлежит ли пакет уже известному соединению, или это начало нового. Если пакет не был помечен как NOTRACK на предыдущем шаге, ядро создает новую запись в таблице состояний (или обновляет таймеры существующей).

Таблица mangle. На этом этапе администратор может модифицировать IP-заголовки пакета. Изменение поля TTL (Time To Live), модификация битов TOS/DSCP для приоритизации трафика (QoS) или установка внутренних меток ядра (fwmark). Метка (MARK) не изменяет сам пакет, она существует только в памяти ядра (в структуре sk_buff) и используется на следующих этапах для сложной маршрутизации (Policy Routing).

Таблица nat (DNAT). Завершающий аккорд цепочки PREROUTING. Здесь принимается решение о трансляции адреса назначения (Destination NAT) или перенаправлении портов (Port Forwarding). Если правило меняет IP-адрес назначения с публичного на внутренний, пакет модифицируется прямо здесь.

Первый перекресток: Routing Decision

После выхода из цепочки PREROUTING пакет сталкивается с важнейшим механизмом ядра — маршрутизацией (Routing Decision). Ядро обращается к таблице маршрутизации (FIB — Forwarding Information Base) и задает один вопрос: «Является ли IP-адрес назначения этого пакета одним из IP-адресов локальной машины?»

Ответ на этот вопрос кардинально меняет дальнейшую судьбу пакета, разделяя поток на две непересекающиеся ветви: локальную (INPUT) и транзитную (FORWARD).

Ветвь А: Локальный трафик (INPUT)

Если пакет предназначен самому серверу (например, это HTTP-запрос к локальному Nginx или SSH-подключение), он направляется в цепочку INPUT.

mangle (INPUT). Последний шанс изменить заголовки или поставить метку перед тем, как пакет попадет в приложение.

filter (INPUT). Главный рубеж обороны сервера. Именно здесь принимается решение: пустить пакет к локальному сокету или уничтожить его (DROP / REJECT). Большинство правил файрвола для защиты самого хоста пишется именно в этой таблице.

security (INPUT). Специфическая таблица, используемая системами мандатного контроля доступа, такими как SELinux. Она позволяет назначать пакетам контексты безопасности (SecMark).

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

Если пакет успешно проходит все эти таблицы и не блокируется правилами filter, ядро передает его на транспортный уровень (TCP/UDP), а затем — в пользовательское пространство (user-space), где его считывает ожидающий процесс (например, веб-сервер).

Ветвь Б: Транзитный трафик (FORWARD)

Если сервер выполняет роль маршрутизатора, и IP-адрес назначения принадлежит другой сети, пакет направляется в цепочку FORWARD. Важно понимать: транзитный пакет никогда не попадает в цепочки INPUT или OUTPUT.

mangle (FORWARD). Модификация транзитного трафика. Часто используется для изменения TCP MSS (Maximum Segment Size) при маршрутизации через VPN-туннели, чтобы избежать фрагментации.

filter (FORWARD). Место, где администратор определяет, каким сетям разрешено общаться друг с другом. Если сервер является шлюзом между локальной сетью и интернетом, именно здесь настраиваются политики доступа для пользователей внутренней сети.

security (FORWARD). Назначение меток безопасности для транзитного трафика.

После цепочки FORWARD пакет сразу направляется к финальной стадии — цепочке POSTROUTING.

!Интерактивная трассировка пакета

Фаза Egress: локальная генерация и OUTPUT

Пакеты, сгенерированные локальными процессами (например, ваш сервер инициирует обновление через apt или отправляет ответный HTTP-пакет клиенту), имеют собственный путь. Они появляются внутри системы и сразу попадают в процесс маршрутизации.

Локально сгенерированный трафик проходит через две проверки маршрутизации.

Первая маршрутизация (Initial Routing Decision): Как только процесс отправляет данные в сокет, ядро должно определить, через какой сетевой интерфейс пакет покинет систему и какой IP-адрес источника ему присвоить. После этого пакет попадает в цепочку OUTPUT.

Порядок таблиц в OUTPUT самый длинный:

raw (OUTPUT). Возможность отключить отслеживание состояний для исходящего трафика (например, для локального DNS-резолвера, генерирующего тысячи запросов).

mangle (OUTPUT). Модификация заголовков исходящего пакета или установка fwmark.

nat (OUTPUT). Трансляция адреса назначения для локально сгенерированных пакетов. Например, если локальный процесс пытается обратиться к 8.8.8.8, правило в этой таблице может прозрачно перенаправить этот запрос на 127.0.0.1.

Вторая маршрутизация (Rerouting): Если в таблицах mangle или nat цепочки OUTPUT пакет был изменен (например, изменился IP назначения или добавилась метка маршрутизации), ядро обязано перепроверить маршрут. Пакет может потребовать отправки через совершенно другой интерфейс.

После перемаршрутизации пакет проходит оставшиеся таблицы цепочки OUTPUT:

filter (OUTPUT). Фильтрация исходящего трафика. Здесь можно запретить скомпрометированному серверу обращаться к командным центрам ботнетов.

security (OUTPUT). Применение политик SELinux к исходящим пакетам.

Финальный рубеж: POSTROUTING

Независимо от того, был ли пакет транзитным (прошел FORWARD) или локально сгенерированным (прошел OUTPUT), перед тем как покинуть сетевой стек ядра и отправиться в драйвер сетевой карты, он попадает в цепочку POSTROUTING.

Здесь работают всего две таблицы:

mangle (POSTROUTING). Финальная возможность изменить заголовки пакета перед отправкой в провод.

nat (SNAT). Критически важный этап для маршрутизаторов. Здесь выполняется Source NAT и Masquerade — подмена внутреннего серого IP-адреса источника на публичный IP-адрес маршрутизатора. Это делается в самый последний момент, когда ядро уже точно знает, через какой интерфейс уходит пакет.

Парадокс таблицы NAT и ловушка первого пакета

Один из самых сложных для понимания нюансов архитектуры Netfilter заключается в механике работы таблицы nat. В отличие от mangle или filter, которые скрупулезно проверяют каждый проходящий байт, таблица nat является «ленивой».

Правила в таблице nat (во всех её цепочках: PREROUTING, POSTROUTING, OUTPUT) вычисляются только для первого пакета в новом соединении (состояние NEW по классификации conntrack).

Рассмотрим классический сценарий проброса порта (DNAT). Внешний клиент подключается к публичному IP-адресу маршрутизатора на порт 8080. Маршрутизатор должен перенаправить этот трафик на внутренний сервер 192.168.1.100 на порт 80.

Приходит первый пакет (TCP SYN). Он попадает в PREROUTING, доходит до таблицы nat.

Ядро находит правило DNAT: «изменить IP назначения на 192.168.1.100:80».

Пакет модифицируется. Одновременно с этим подсистема conntrack записывает в свою внутреннюю таблицу: «Соединение X: входящие пакеты менять на 192.168.1.100:80, а ответным пакетам от 192.168.1.100 менять источник обратно на публичный IP маршрутизатора».

Приходит второй пакет этого же соединения (TCP ACK). Он попадает в PREROUTING. Таблицы raw и mangle обрабатывают его, но когда дело доходит до nat, ядро видит, что пакет принадлежит уже известному соединению. Таблица nat полностью игнорируется.

Вместо выполнения правил iptables, ядро просто применяет к пакету трансформацию, сохраненную в памяти conntrack на шаге 3.

Это архитектурное решение делает NAT в Linux невероятно производительным. Однако оно порождает частую ошибку администраторов: попытку использовать счетчики пакетов (iptables -t nat -vL) для подсчета всего транслированного трафика. Эти счетчики покажут только количество установленных соединений, а не реальный объем переданных данных, так как 99% пакетов пролетят мимо правил таблицы nat, полагаясь на кэш conntrack.

Интерфейс Loopback: короткое замыкание

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

Пакет генерируется приложением и проходит цепочку OUTPUT (со всеми её таблицами). После принятия решения о маршрутизации ядро понимает, что интерфейс назначения — это lo. Пакет виртуально «покидает» систему через POSTROUTING и мгновенно «возвращается» обратно через интерфейс lo, попадая в PREROUTING и затем в INPUT.

Таким образом, пакет, отправленный на 127.0.0.1, дважды проходит через таблицы mangle (в OUTPUT и PREROUTING/INPUT) и дважды подвергается фильтрации (в OUTPUT и INPUT). Если администратор по неосторожности применит жесткую политику DROP ко всему трафику в цепочке INPUT, не сделав исключения для интерфейса lo (-i lo -j ACCEPT), локальные сервисы (например, веб-сервер и локальная база данных) потеряют возможность общаться друг с другом, что приведет к полному отказу приложения, даже если внешняя сеть работает идеально.

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

Администратор вводит команду iptables -F, нажимает Enter, и консоль SSH мгновенно зависает, переставая реагировать на нажатия клавиш. Сессия оборвана, удаленный доступ потерян, и единственный способ вернуть контроль над сервером — физическая перезагрузка или KVM-консоль. Эта классическая авария происходит не из-за бага в ядре, а из-за непонимания того, как синтаксис утилиты взаимодействует с текущим состоянием сетевого стека. Утилита iptables не задает уточняющих вопросов и выполняет инструкции атомарно. Чтобы инструмент защищал инфраструктуру, а не разрушал ее связность, необходимо читать его синтаксис не как набор ключей, а как строгую логическую формулу.

Анатомия команды iptables

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

!Структура команды iptables

Общий вид формулы выглядит следующим образом: iptables [-t таблица] <команда> [цепочка] [критерии_совпадения] [-j действие]

Каждый блок выполняет строго определенную функцию:

Выбор таблицы (-t). Указывает, в каком пространстве имен будет произведена операция (filter, nat, mangle, raw, security). Если ключ -t опущен, утилита неявно подставляет -t filter. Это историческое наследие, так как фильтрация — самая частая задача.

Команда управления. Определяет, что именно нужно сделать: добавить, вставить, удалить, заменить правило или очистить цепочку.

Цепочка. Указывает точку привязки (хук), в которой будет работать правило: INPUT, FORWARD, PREROUTING и так далее.

Критерии совпадения (Matches). Набор условий, при выполнении которых пакет считается «совпавшим» с правилом. Это могут быть протоколы (-p tcp), IP-адреса (-s 192.168.1.0/24), порты (--dport 443) или физические интерфейсы (-i eth0). Если критерии не указаны, правило применяется абсолютно ко всем пакетам в цепочке.

Действие (Target). Указывается после ключа -j (Jump). Определяет судьбу пакета, совпавшего с критериями: ACCEPT, DROP, REJECT или переход в другую цепочку.

Чтение текущего состояния: аудит правил

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

Профессиональный стандарт аудита правил — комбинация ключей -n -v -L --line-numbers.

* -L (List) — выводит список правил в выбранной цепочке (или во всех цепочках таблицы). * -n (Numeric) — отключает обратное разрешение DNS (Reverse DNS lookup). Без этого ключа iptables пытается преобразовать каждый IP-адрес в правилах в доменное имя. Если DNS-сервер недоступен (например, из-за самих же правил firewall), команда iptables -L зависнет на несколько минут. Ключ -n заставляет выводить чистые IP-адреса и номера портов. * -v (Verbose) — включает детальный вывод. Добавляет счетчики пакетов и байтов, а также показывает входящие и исходящие сетевые интерфейсы. * --line-numbers — нумерует правила по порядку их следования в цепочке. Это критически важно для точного удаления или вставки.

Пример вывода команды iptables -n -v -L INPUT --line-numbers:

| num | pkts | bytes | target | prot | opt | in | out | source | destination | | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | | 1 | 154K | 12M | ACCEPT | all | -- | lo | * | 0.0.0.0/0 | 0.0.0.0/0 | | 2 | 45 | 2700 | DROP | tcp | -- | eth0 | * | 203.0.113.5 | 0.0.0.0/0 | | 3 | 8900 | 500K | ACCEPT | tcp | -- | eth0 | * | 0.0.0.0/0 | 0.0.0.0/0 tcp dpt:22 |

Разбор колонок детального вывода: * pkts / bytes: Счетчики. Показывают, сколько пакетов и суммарно байтов совпало с этим правилом с момента его создания или последнего обнуления. Если счетчики равны нулю, правило либо недавно создано, либо написано с ошибкой (трафик до него не доходит). * opt: Опции. Чаще всего пустует (--), но может содержать флаги, например ! для инверсии правила. in / out: Входящий и исходящий интерфейсы. Звездочка означает «любой интерфейс». В цепочке INPUT колонка out всегда будет *, так как пакет еще не прошел маршрутизацию наружу.

Управление правилами: добавление, вставка и замена

Порядок правил имеет решающее значение. Netfilter проверяет пакет последовательно, сверху вниз (от правила 1 к правилу ). Как только находится совпадение с завершающим действием (например, ACCEPT или DROP), проверка прекращается.

Добавление в конец (-A)

Команда -A (Append) добавляет правило в самый конец указанной цепочки. iptables -A INPUT -p tcp --dport 80 -j ACCEPT Если в цепочке уже есть 10 правил, новое получит номер 11. Это безопасно при первоначальной настройке, но может стать проблемой на работающем сервере. Если правило номер 10 звучит как «запретить всё остальное» (-j DROP), то добавленное 11-м правило для 80-го порта никогда не сработает — трафик будет отброшен на шаг раньше.

Вставка по номеру (-I)

Команда -I (Insert) позволяет вставить правило в конкретную позицию, сдвигая остальные вниз. iptables -I INPUT 1 -p tcp --dport 443 -j ACCEPT Эта команда поместит разрешающее правило для HTTPS на первую строчку. Бывшее правило 1 станет номером 2, номер 2 станет номером 3 и так далее. Если номер не указан (iptables -I INPUT ...), правило неявно вставляется на позицию 1.

!Интерактивная демонстрация сдвига индексов при вставке и удалении

Замена правила (-R)

Команда -R (Replace) позволяет изменить существующее правило, не меняя его порядкового номера и не затрагивая соседей. Допустим, правило номер 2 блокирует IP 203.0.113.5, а нам нужно изменить блокируемый адрес на 203.0.113.10. Вместо удаления старого и вставки нового (что требует двух команд и создает микро-окно уязвимости), используется замена: iptables -R INPUT 2 -p tcp -s 203.0.113.10 -j DROP Важный нюанс: при использовании -R счетчики пакетов и байтов для этой строки обнуляются.

Безопасное удаление правил

Удаление осуществляется ключом -D (Delete) и может быть выполнено двумя способами: по спецификации правила или по его номеру.

Удаление по спецификации: iptables -D INPUT -p tcp -s 203.0.113.10 -j DROP Утилита ищет в цепочке INPUT правило, которое в точности совпадает с переданным набором критериев и действий, и удаляет его. Это безопасно в автоматизированных скриптах, так как исключает удаление чужого правила, если индексы сместились. Однако набирать длинную спецификацию вручную неудобно.

Удаление по номеру: iptables -D INPUT 2 Удаляет второе правило в цепочке INPUT. Все правила ниже (3, 4, 5...) сдвигаются на одну позицию вверх. Здесь кроется опасная ловушка при ручном администрировании. Если нужно удалить правила 2 и 3, выполнение команд iptables -D INPUT 2 а затем iptables -D INPUT 3 приведет к ошибке. После удаления второго правила, старое третье правило сместится и станет вторым. Старое четвертое станет третьим. Вторая команда удалит совершенно не то правило, которое планировалось. Правильный подход при массовом удалении по номерам — удалять с конца (сначала номер 3, затем номер 2), чтобы сдвиг индексов не влиял на еще не удаленные целевые правила.

Глобальные операции: политики и очистка

Каждая стандартная цепочка имеет политику по умолчанию (Default Policy). Она применяется, если пакет прошел через все правила цепочки и ни с одним не совпал.

Установка политики выполняется ключом -P (Policy): iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT

Политика может быть только завершающей (ACCEPT или DROP). Нельзя установить политику REJECT или LOG.

Ключ -F (Flush) удаляет все правила из указанной цепочки (или из всех цепочек таблицы, если цепочка не указана). iptables -F INPUT

Именно комбинация -P и -F приводит к аварии, описанной в начале статьи. Если администратор установил политику по умолчанию для INPUT в DROP, а доступ по SSH обеспечивался разрешающим правилом внутри цепочки, то команда iptables -F мгновенно стирает это разрешающее правило. Пакеты SSH доходят до конца пустой цепочки, попадают под политику DROP и уничтожаются. Сессия зависает. Правильная последовательность полной очистки удаленного сервера:

iptables -P INPUT ACCEPT (временно разрешить всё)

iptables -P OUTPUT ACCEPT

iptables -P FORWARD ACCEPT

iptables -F (теперь очистка безопасна)

Для сброса счетчиков пакетов и байтов используется ключ -Z (Zero). iptables -Z INPUT обнулит статистику для всех правил в цепочке INPUT. Это полезно при диагностике: обнулив счетчики, можно отправить тестовый пакет и посмотреть, на каком именно правиле счетчик увеличится на единицу.

Пользовательские цепочки (User-defined chains)

Кроме пяти стандартных цепочек-хуков, администратор может создавать собственные. Пользовательские цепочки не привязаны к сетевому стеку ядра напрямую — пакет может попасть в них только в том случае, если из стандартной цепочки будет совершено перенаправление (Jump) с помощью ключа -j.

Зачем нужны пользовательские цепочки?

Оптимизация производительности. Если на сервере 1000 IP-адресов заблокированы за брутфорс SSH, проверка каждого веб-запроса (порт 80/443) через эти 1000 правил создаст колоссальную нагрузку на CPU (сложность ). Выделив проверки SSH в отдельную цепочку, мы избавляем легитимный веб-трафик от прохождения лишних проверок.

Логическое группирование. Сложные наборы правил (например, проброс портов для Docker-контейнеров) легче читать и удалять целиком, если они изолированы в отдельной цепочке.

Комплексные действия. В iptables нельзя одним правилом сделать и LOG (запись в системный журнал), и DROP. Пользовательская цепочка позволяет обойти это ограничение.

Создание и управление

Создание новой цепочки выполняется ключом -N (New): iptables -N LOG_AND_DROP

Переименование — ключом -E (Edit): iptables -E LOG_AND_DROP BAD_TRAFFIC

Удаление — ключом -X (Delete chain): iptables -X BAD_TRAFFIC Важное ограничение: удалить можно только пустую цепочку, на которую нет ссылок (переходов) из других правил. Сначала нужно удалить все правила внутри нее (-F BAD_TRAFFIC), затем удалить все правила в других цепочках, которые делали -j BAD_TRAFFIC, и только потом удалять саму цепочку.

Логика перехода и возврата

Переход в пользовательскую цепочку выглядит как обычное действие: iptables -A INPUT -p tcp --dport 22 -j SSH_CHECKS

!Логика перехода в пользовательскую цепочку и возврата

Когда пакет совпадает с критериями (TCP, порт 22), он покидает цепочку INPUT и начинает проверяться по правилам внутри SSH_CHECKS. В пользовательской цепочке возможны три исхода:

Пакет совпадает с правилом, имеющим действие ACCEPT или DROP. Обработка немедленно прекращается, судьба пакета решена.

Пакет доходит до конца пользовательской цепочки, не совпав ни с одним правилом. В отличие от стандартных цепочек, пользовательские не имеют политики по умолчанию (Default Policy). Вместо этого пакет автоматически возвращается в вызывающую цепочку (INPUT) на следующее правило после -j SSH_CHECKS.

Пакет совпадает с правилом, имеющим действие RETURN. Это принудительный досрочный возврат в вызывающую цепочку.

Пример реализации паттерна «Логировать и сбросить»: Создаем цепочку: iptables -N LOG_DROP Наполняем ее правилами: iptables -A LOG_DROP -j LOG --log-prefix "Dropped Packet: " iptables -A LOG_DROP -j DROP Теперь в любой стандартной цепочке, где нужно отбросить пакет с записью в syslog, достаточно указать: iptables -A INPUT -s 198.51.100.0/24 -j LOG_DROP Пакет перейдет в LOG_DROP, запишется в журнал (так как LOG не прерывает обработку), перейдет к следующему правилу и будет уничтожен.

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

Глубокое погружение в таблицу Filter: построение комплексной защиты сервера

В среднем 44 минуты требуется автоматизированным сканерам ботнетов, чтобы обнаружить новый IP-адрес, появившийся в глобальной сети, и начать перебор паролей по SSH или поиск известных уязвимостей в веб-сервисах. Сетевой стек Linux по умолчанию открыт для входящих соединений на прослушиваемых портах. Таблица filter — это основной инструмент администратора для изменения этого поведения. Именно здесь принимаются окончательные решения о том, имеет ли право конкретный пакет достичь локального процесса, пройти транзитом в другую сеть или покинуть сервер.

Парадигмы фильтрации: Чёрный и Белый списки

При проектировании архитектуры сетевого экрана в таблице filter администратор неизбежно сталкивается с выбором одной из двух фундаментальных парадигм: «Чёрный список» (Default ACCEPT) или «Белый список» (Default DROP).

Парадигма «Чёрного списка» подразумевает, что разрешено всё, что не запрещено явно. Администратор создает правила, блокирующие известные вредоносные IP-адреса, нестандартные порты или специфические виды атак. Этот подход кажется интуитивно простым на старте, но математически обречён на провал. Пространство возможных сетевых угроз и векторов атак стремится к бесконечности. Попытка описать все нежелательные состояния превращает набор правил в неподдерживаемую структуру, которая всегда будет отставать от реальных угроз.

Парадигма «Белого списка» работает по принципу: запрещено всё, что не разрешено явно. Сетевой экран закрыт по умолчанию. Администратор точечно описывает легитимный трафик, необходимый для работы конкретных сервисов. Пространство легитимного трафика всегда конечно и предсказуемо (например, только TCP-порт 443 для веб-сервера и TCP-порт 22 для определенной подсети администраторов). Любой пакет, не попавший под разрешающие правила, уничтожается.

!Сравнение парадигм фильтрации

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

Установить политику по умолчанию можно командой iptables -P INPUT DROP. Но если администратор случайно выполнит сброс всех правил (iptables -F), политика DROP сохранится, а разрешающее правило для SSH исчезнет. Сервер мгновенно отрежет администратора от консоли управления.

Более безопасный паттерн — оставить политику по умолчанию ACCEPT, но последним правилом в цепочке поставить явный запрет: iptables -A INPUT -j DROP

В этом случае при случайном сбросе правил (-F) удалится и само запрещающее правило. Политика останется ACCEPT, и SSH-сессия не прервётся, что даст шанс исправить ошибку.

Три рубежа обороны таблицы Filter

Таблица filter проецируется на три стандартные цепочки, каждая из которых защищает свой вектор:

INPUT — защита самого сервера. Сюда попадают пакеты, у которых IP-адрес назначения совпадает с одним из локальных адресов сервера. Здесь мы защищаем SSH, веб-серверы, базы данных, слушающие на локальных интерфейсах.

FORWARD — защита сетей, находящихся за сервером. Эта цепочка задействуется только в том случае, если сервер выполняет роль маршрутизатора (включен ip_forward). Пакеты здесь проходят сквозь ядро, не поднимаясь к локальным процессам.

OUTPUT — контроль исходящего трафика (Egress Filtering). Сюда попадают пакеты, сгенерированные локальными процессами самого сервера.

Многие администраторы концентрируются исключительно на INPUT, оставляя OUTPUT полностью открытым. Это серьезная архитектурная ошибка. Если злоумышленник найдет уязвимость в веб-приложении (например, RCE — Remote Code Execution), открытый OUTPUT позволит ему беспрепятственно скачать вредоносную нагрузку с внешнего сервера, подключиться к обратному командному центру (Reverse Shell) или начать рассылку спама. Жесткая фильтрация исходящего трафика превращает взломанный сервис в изолированную клетку: злоумышленник может выполнить команду, но не может выгрузить данные или загрузить инструментарий.

Построение базового набора правил (Baseline)

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

1. Доверие локальному интерфейсу

Самое первое правило всегда должно разрешать трафик внутри самого сервера через интерфейс loopback (lo). Множество внутренних служб (например, связь веб-приложения с локальной базой данных или кэширующим демоном) общаются через адрес 127.0.0.1. iptables -A INPUT -i lo -j ACCEPT

2. Поддержка состояний (Stateful Inspection)

Это важнейшее правило, которое должно стоять сразу после loopback. Сетевой трафик состоит из соединений, а не разрозненных пакетов. Если мы разрешили входящий запрос к веб-серверу, мы должны разрешить и исходящие пакеты ответа, а также последующие входящие пакеты в рамках этой же сессии.

Вместо того чтобы писать сложные симметричные правила для каждого порта, мы делегируем эту задачу подсистеме conntrack: iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Это правило говорит: «Разрешить любые пакеты, которые принадлежат уже установленным соединениям (ESTABLISHED) или связаны с ними (RELATED, например, ICMP-сообщения об ошибках для существующей TCP-сессии)».

Почему это правило должно быть вторым? В активно работающем сервере 99% пакетов принадлежат уже установленным соединениям. Если поместить это правило в начало, 99% трафика будет проходить проверку за один шаг — . Если опустить его в конец длинного списка из 100 правил, ядро будет вынуждено выполнять 100 проверок для каждого пакета в потоке данных — , что приведет к колоссальной деградации производительности под нагрузкой.

3. Отсечение невалидного трафика

Пакеты, которые не принадлежат ни одному известному соединению и при этом не являются корректными пакетами инициализации (например, TCP-пакет без флага SYN, пришедший из ниоткуда), классифицируются как INVALID. Их необходимо уничтожать немедленно, так как они часто используются для сканирования портов или исчерпания ресурсов. iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

4. Открытие публичных сервисов

Только теперь, когда базовые механизмы настроены, мы открываем порты для новых соединений (NEW). iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT iptables -A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT

5. Замыкающее правило

Всё, что не подошло под правила выше, должно быть отброшено. iptables -A INPUT -j DROP

Оптимизация архитектуры: Диспетчеризация через пользовательские цепочки

Представленный выше Baseline отлично работает для 5-10 правил. Но если сервер обслуживает десятки сервисов, имеет сложные списки доступа по IP-адресам, плоский список в INPUT становится неэффективным.

Представим, что у нас есть 50 правил для TCP, 30 для UDP и 10 для ICMP. UDP-пакет, пришедший на сервер, будет вынужден пройти через все 50 проверок TCP, прежде чем доберется до своей секции.

Для решения этой проблемы применяется паттерн «Диспетчер», использующий пользовательские цепочки. Главная цепочка INPUT перестает выполнять фильтрацию портов и становится маршрутизатором логики:

Создаем логические контейнеры:

iptables -N TCP_IN iptables -N UDP_IN iptables -N ICMP_IN

В INPUT после правил lo и ESTABLISHED настраиваем диспетчеризацию на основе протокола:

iptables -A INPUT -p tcp -j TCP_IN iptables -A INPUT -p udp -j UDP_IN iptables -A INPUT -p icmp -j ICMP_IN

Наполняем пользовательские цепочки:

iptables -A TCP_IN -p tcp --dport 22 -j ACCEPT iptables -A TCP_IN -p tcp --dport 80 -j ACCEPT

Теперь UDP-пакет сразу перепрыгнет в цепочку UDP_IN, минуя все проверки TCP-портов. Если пакет не совпал ни с одним правилом внутри TCP_IN, он возвращается обратно в INPUT (неявный RETURN) и попадает на финальное правило DROP.

!Диспетчеризация пакетов по пользовательским цепочкам

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

Обработка ICMP: Миф о невидимости

Одно из самых опасных заблуждений начинающих администраторов — стремление сделать сервер «невидимым» для сканеров путем полного блокирования протокола ICMP: iptables -A INPUT -p icmp -j DROP

Протокол ICMP (Internet Control Message Protocol) — это не только ping (Echo Request / Echo Reply). Это сигнальная система всего интернета. Полная блокировка ICMP ломает механизм Path MTU Discovery (PMTUD).

Если сервер отправляет большой пакет (например, 1500 байт), а где-то на маршруте есть узел с ограничением MTU в 1400 байт, этот маршрутизатор отбросит пакет и отправит обратно ICMP-сообщение Type 3 Code 4 (Fragmentation Needed and Don't Fragment was Set). Получив его, ядро сервера автоматически уменьшит размер отправляемых пакетов. Если сервер игнорирует ICMP, соединение просто «зависнет»: TCP-рукопожатие пройдет (пакеты маленькие), а передача данных остановится навсегда (пакеты большие и молча теряются).

Корректная фильтрация ICMP в парадигме «Белого списка» требует разрешения критически важных типов:

Type 8 (Echo Request) — если вы хотите, чтобы сервер пинговался (опционально, но рекомендуется для мониторинга).

Type 0 (Echo Reply) — ответы на ваши собственные пинги (обычно покрывается правилом ESTABLISHED,RELATED, но полезно знать).

Type 3 (Destination Unreachable) — необходимо для PMTUD и быстрого разрыва невозможных соединений.

Type 11 (Time Exceeded) — необходимо для работы утилиты traceroute.

Пример грамотной настройки: iptables -A ICMP_IN -p icmp --icmp-type 8 -j ACCEPT iptables -A ICMP_IN -p icmp --icmp-type 3 -j ACCEPT iptables -A ICMP_IN -p icmp --icmp-type 11 -j ACCEPT iptables -A ICMP_IN -j DROP

Защита от спуфинга и Bogon-трафика

Таблица filter также отвечает за базовую санитарию трафика на границе сети. Одна из задач — защита от IP-спуфинга (подделки адреса источника).

Если сервер смотрит интерфейсом eth0 в публичный интернет, на этом интерфейсе в принципе не может появиться валидный входящий пакет с адресом источника из приватных диапазонов (RFC 1918), таких как 10.0.0.0/8, 192.168.0.0/16 или 127.0.0.0/8. Появление такого пакета означает либо серьезную ошибку маршрутизации у провайдера, либо целенаправленную попытку обхода сетевого экрана.

Такой трафик называется Bogon-трафиком. Отсекать его следует в самом начале цепочки INPUT (или FORWARD, если это маршрутизатор), до проверки состояний соединений:

iptables -A INPUT -i eth0 -s 127.0.0.0/8 -j DROP iptables -A INPUT -i eth0 -s 10.0.0.0/8 -j DROP iptables -A INPUT -i eth0 -s 192.168.0.0/16 -j DROP

Примечание: Если сервер находится за NAT облачного провайдера и получает локальный IP на интерфейс eth0, блокировать этот конкретный диапазон нельзя. Это правило применяется строго для интерфейсов с белыми (публичными) IP-адресами.

Контроль исходящего трафика (Egress Filtering)

Возвращаясь к цепочке OUTPUT, рассмотрим, как реализовать парадигму «Белого списка» для самого сервера. Жесткий Egress Filtering требует понимания, куда именно серверу нужно обращаться.

Базовый набор для веб-сервера обычно включает:

Разрешение loopback (обязательно).

Разрешение ответов на входящие запросы (покрывается глобальным ESTABLISHED,RELATED).

Разрешение DNS-запросов (UDP/TCP порт 53) к конкретным DNS-серверам (например, 8.8.8.8).

Разрешение HTTP/HTTPS (порты 80, 443) для скачивания обновлений ОС.

Разрешение NTP (UDP порт 123) для синхронизации времени.

Логика построения цепочки OUTPUT зеркальна INPUT: iptables -A OUTPUT -o lo -j ACCEPT iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -p udp --dport 53 -d 8.8.8.8 -j ACCEPT iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT iptables -A OUTPUT -p udp --dport 123 -j ACCEPT iptables -A OUTPUT -j DROP

Если процесс, запущенный злоумышленником, попытается инициировать соединение на нестандартный порт (например, 4444 для Reverse Shell) или отправить данные по протоколу ICMP, пакет будет уничтожен ядром в цепочке OUTPUT.

Построение правил в таблице filter — это баланс между безопасностью, производительностью и доступностью. Использование явного запрета в конце цепочек вместо жестких политик спасает от потери доступа, правильное позиционирование проверки состояний экономит ресурсы CPU, а структурирование через пользовательские цепочки позволяет управлять сотнями правил без путаницы. Глубокое понимание протоколов, таких как ICMP, уберегает от создания «защищенных», но неработающих систем.

Механизмы NAT: реализация проброса портов, SNAT и маскарадинга

Вы настроили веб-сервер в локальной сети на адресе 192.168.1.10 и успешно пробросили 80-й порт на внешний публичный IP-адрес маршрутизатора 203.0.113.5. Клиенты из интернета открывают сайт без проблем. Но когда вы, находясь в той же локальной сети с ноутбука 192.168.1.20, вводите в браузере внешний адрес 203.0.113.5, соединение зависает по таймауту. Маршрутизатор корректно принимает пакет, правило проброса активно, сервер работает, но связи нет. Этот классический парадокс обнажает скрытую механику трансляции сетевых адресов (NAT) в Linux: изменение IP-адресов в заголовках пакетов неразрывно связано с таблицами маршрутизации ядра и подсистемой отслеживания состояний.

Анатомия трансляции: симбиоз с conntrack

Исторически NAT (Network Address Translation) создавался для решения проблемы исчерпания IPv4-адресов, позволяя скрыть целую подсеть за одним публичным IP. В архитектуре Netfilter эта задача решается через таблицу nat.

Фундаментальное правило, которое определяет логику работы этой таблицы: через цепочки таблицы nat проходит только первый пакет каждого нового соединения (состояние NEW). Ядро Linux не тратит процессорное время на пошаговое применение правил трансляции к каждому из тысяч пакетов в потоке видео или загрузке файла.

Когда первый пакет совпадает с правилом SNAT или DNAT, подсистема conntrack создает в оперативной памяти запись — кортеж (tuple), описывающий двунаправленную связь. В этой записи фиксируются исходные адреса и порты, а также то, на какие адреса и порты их нужно заменять. Все последующие пакеты этого соединения (состояния ESTABLISHED и RELATED), включая ответный трафик, вообще не попадают в таблицу nat. Трансляция для них выполняется ядром на лету, опираясь исключительно на кэшированную запись в таблице состояний conntrack.

Именно поэтому любые изменения в правилах iptables таблицы nat не применяются к уже установленным соединениям. Если вы удалите правило проброса портов, текущие сессии не оборвутся, пока не истечет их таймаут в conntrack или они не будут закрыты по TCP FIN.

Source NAT (SNAT): подмена источника и PAT

SNAT используется, когда пакеты покидают вашу сеть и отправляются во внешнюю среду. Его задача — заменить приватный IP-адрес источника (например, 192.168.1.50) на публичный IP-адрес маршрутизатора, чтобы ответные пакеты из интернета знали, куда возвращаться.

Операция SNAT выполняется исключительно в цепочке POSTROUTING. Это архитектурная необходимость: ядро должно изменить IP-адрес источника только после того, как подсистема маршрутизации (Routing Decision) определит, через какой сетевой интерфейс пакет покинет систему. Если бы мы попытались изменить адрес до маршрутизации, ядро могло бы подставить IP-адрес интерфейса eth0, тогда как таблица маршрутизации в итоге отправила бы пакет через eth1.

Синтаксис применения статического SNAT выглядит так: iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j SNAT --to-source 203.0.113.10

В этом правиле мы указываем, что для всего трафика из подсети 192.168.1.0/24, уходящего через интерфейс eth0, адрес источника должен быть заменен на 203.0.113.10.

Проблема коллизии портов (PAT)

Чистый NAT меняет только IP-адрес. Но что произойдет, если два разных компьютера в локальной сети (192.168.1.10 и 192.168.1.20) одновременно откроют соединение с одним и тем же внешним веб-сервером, и операционные системы обоих компьютеров случайно выделят для этого одинаковый исходящий порт, например, 45000?

После применения базового SNAT оба пакета получат одинаковый IP источника (203.0.113.10) и сохранят одинаковый порт источника (45000). Когда внешний сервер пришлет ответ на 203.0.113.10:45000, маршрутизатор не сможет определить, какому из двух локальных компьютеров предназначается пакет.

Поэтому действие SNAT в iptables по умолчанию работает как PAT (Port Address Translation). Netfilter анализирует таблицу conntrack. Если он видит, что требуемый порт источника уже занят другой сессией с тем же целевым сервером, он автоматически изменяет исходный порт (Source Port) пакета на свободный. В кортеж conntrack записывается не только подмена IP, но и подмена порта, что позволяет безошибочно демультиплексировать ответный трафик.

MASQUERADE: динамический SNAT и его цена

Действие MASQUERADE — это специализированная форма SNAT, созданная для соединений с динамическими IP-адресами (например, PPPoE или DHCP от провайдера).

Синтаксис отличается отсутствием явного указания внешнего адреса: iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o ppp0 -j MASQUERADE

Ядро само определяет текущий IP-адрес интерфейса ppp0 в момент прохождения пакета и использует его для трансляции. Кажется, что MASQUERADE удобнее использовать всегда, даже при статическом IP, избавляя себя от необходимости хардкодить адреса в скриптах. Однако это архитектурная ошибка, ведущая к деградации производительности.

Разница кроется в обработке событий сетевых интерфейсов. Когда интерфейс падает (link down) или теряет IP-адрес, логика MASQUERADE предполагает, что при следующем поднятии интерфейса IP-адрес изменится. Поэтому ядро немедленно сканирует всю таблицу conntrack и удаляет все записи о соединениях, связанных с этим интерфейсом.

Если у вас статический IP-адрес и кратковременно мигнул линк на коммутаторе, при использовании SNAT соединения останутся в таблице conntrack. Как только линк поднимется (до истечения TCP-таймаутов), сессии продолжат работу без разрывов. При использовании MASQUERADE кратковременное падение линка приведет к принудительному сбросу всех активных сессий, и клиентам придется переустанавливать TCP-соединения с нуля. Кроме того, на высоконагруженных маршрутизаторах с сотнями тысяч сессий операция массовой очистки conntrack вызывает заметный скачок потребления CPU.

Destination NAT (DNAT): публикация сервисов

В то время как SNAT скрывает локальную сеть от интернета, DNAT (Destination NAT) делает обратное: позволяет внешним клиентам обращаться к сервисам, скрытым за NAT. Это то, что в бытовых роутерах называется «пробросом портов» (Port Forwarding).

DNAT выполняется строго в цепочке PREROUTING. Пакет поступает на сетевой интерфейс, и ядро должно изменить его целевой IP-адрес до того, как будет принято решение о маршрутизации. Если пакет с публичным IP-адресом назначения дойдет до этапа Routing Decision без изменений, ядро решит, что пакет предназначен самому маршрутизатору, и отправит его в цепочку INPUT локального процесса, где он, скорее всего, будет отброшен.

!Динамика изменения IP-адресов при прохождении SNAT и DNAT

Правило проброса 80-го порта внешнего интерфейса на внутренний сервер 192.168.1.100 на порт 8080 выглядит так: iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 192.168.1.100:8080

Взаимодействие DNAT и таблицы filter

Самая частая ошибка при настройке DNAT — непонимание того, как транслированный пакет проходит через таблицу filter.

После того как пакет прошел цепочку PREROUTING таблицы nat, его целевой адрес уже изменен на 192.168.1.100. Далее пакет попадает в блок маршрутизации. Ядро видит, что адрес 192.168.1.100 не принадлежит самому маршрутизатору, а доступен через локальный интерфейс eth1. Следовательно, пакет направляется в транзитную цепочку FORWARD таблицы filter.

В этот момент пакет имеет исходный IP-адрес внешнего клиента (например, 203.0.113.99) и целевой IP-адрес 192.168.1.100, целевой порт 8080. Если в вашей таблице filter настроена политика по умолчанию DROP для транзитного трафика, пакет будет уничтожен.

Чтобы проброс заработал, необходимо добавить разрешающее правило в цепочку FORWARD. И здесь важно проверять именно транслированный адрес и порт: iptables -A FORWARD -i eth0 -o eth1 -p tcp -d 192.168.1.100 --dport 8080 -j ACCEPT

Проверять первоначальный публичный IP маршрутизатора в цепочке FORWARD бессмысленно — пакет уже мутировал.

Hairpin NAT (NAT Loopback): решение проблемы асимметрии

Вернемся к парадоксу из начала статьи. Почему клиент из локальной сети (192.168.1.20) не может достучаться до локального сервера (192.168.1.10), обращаясь к внешнему IP маршрутизатора (203.0.113.5)?

Разберем путь пакета по шагам.

Клиент 192.168.1.20 отправляет TCP SYN пакет на адрес 203.0.113.5.

Пакет попадает на маршрутизатор (внутренний интерфейс eth1).

В цепочке PREROUTING срабатывает правило DNAT: целевой адрес меняется на 192.168.1.10.

Маршрутизатор отправляет пакет серверу 192.168.1.10. Важно: исходный адрес пакета остался прежним — 192.168.1.20.

Сервер 192.168.1.10 получает SYN-пакет от 192.168.1.20, обрабатывает его и формирует ответный SYN-ACK.

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

Сервер отправляет ответный пакет напрямую клиенту через L2-коммутатор, минуя маршрутизатор.

Клиент 192.168.1.20 получает SYN-ACK от адреса 192.168.1.10. Но клиент ожидает ответа от 203.0.113.5! ОС клиента считает этот пакет нелегитимным (от неизвестного источника) и отправляет TCP RST (сброс соединения).

!Схема потока трафика при Hairpin NAT

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

Чтобы решить эту проблему, маршрутизатор должен заставить сервер отвечать не напрямую клиенту, а обратно маршрутизатору. Для этого требуется применить комбинацию DNAT и SNAT к одному и тому же пакету.

Помимо существующего правила DNAT, мы добавляем правило SNAT (или MASQUERADE) для трафика, который идет из локальной сети в локальную сеть: iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -d 192.168.1.10 -p tcp --dport 8080 -j SNAT --to-source 192.168.1.1

Теперь логика меняется:

Маршрутизатор делает DNAT (цель = 192.168.1.10).

Перед отправкой пакета серверу, в цепочке POSTROUTING маршрутизатор делает SNAT, подменяя адрес клиента на свой собственный локальный IP (192.168.1.1).

Сервер получает пакет от 192.168.1.1 и отправляет ответ на 192.168.1.1 (маршрутизатору).

Маршрутизатор получает ответ, conntrack распознает сессию, выполняет обратные преобразования (меняет источник на 203.0.113.5, а цель на 192.168.1.20) и отдает пакет клиенту.

Соединение успешно устанавливается. Этот механизм называется Hairpin NAT (NAT-шпилька) или NAT Loopback. Это вынужденный компромисс: трафик между двумя узлами в одной сети прогоняется через CPU маршрутизатора, удваивая нагрузку на локальный интерфейс, но обеспечивая бесшовный доступ по единому доменному имени как извне, так и изнутри сети.

Управление портами: рандомизация и UDP-трафик

При выполнении SNAT Netfilter по умолчанию старается сохранить исходный порт пакета неизменным. Если порт занят, выбирается новый порт из того же диапазона (привилегированные порты мапятся в порты , а непривилегированные — в диапазон ).

Однако в некоторых сценариях, особенно при защите от атак на предсказание портов или при специфических требованиях симметричного NAT для VoIP-протоколов, предсказуемость портов вредна. Для этого в iptables предусмотрен флаг --random. iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE --random При его использовании ядро будет принудительно назначать случайный исходный порт для каждого нового соединения, игнорируя попытки сохранить оригинальный порт.

Особого внимания при NAT требует протокол UDP. В отличие от TCP, где начало (SYN) и завершение (FIN/RST) сессии явно определены флагами в заголовке, UDP является протоколом без сохранения состояния (stateless). Ядро Linux не может знать, завершился ли обмен данными по UDP или клиент просто делает паузу.

Поэтому трансляция UDP-трафика целиком опирается на таймеры conntrack. Когда через NAT проходит первый UDP-пакет, создается запись с коротким таймаутом (обычно 30 секунд). Если в течение этого времени проходит ответный пакет, таймаут увеличивается (часто до 180 секунд). Если в течение 180 секунд по этому соединению не передано ни одного байта, ядро молча удаляет запись из таблицы трансляций.

Если после этого внутренний клиент отправит новый пакет с того же исходного порта, маршрутизатор создаст новую сессию в conntrack и, скорее всего, выделит новый внешний порт. Для внешнего сервера это будет выглядеть как подключение от нового клиента, что часто приводит к обрывам голосовых звонков (SIP/RTP) или разрывам VPN-туннелей (IPsec/WireGuard). Решение этой проблемы лежит не в плоскости iptables, а в настройке самих приложений: они должны регулярно отправлять пустые keep-alive пакеты (обычно каждые 20-30 секунд), чтобы сбрасывать таймер conntrack и удерживать NAT-привязку (UDP hole punching) в активном состоянии.

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

Таблицы Mangle и Raw: модификация заголовков и управление состоянием пакетов

При анализе причин отказа сети системные администраторы часто ищут проблему в правилах блокировки или ошибках маршрутизации. Однако существует класс отказов, при которых пакеты разрешены всеми правилами таблицы filter, корректно транслируются таблицей nat, но связь всё равно обрывается. Сервер может внезапно перестать отвечать на DNS-запросы при пиковой нагрузке, или SSH-сессия через IPsec-туннель «зависает» сразу после успешной авторизации. Эти аномалии невозможно устранить базовой фильтрацией. Их решение лежит на более глубоком уровне управления трафиком — в таблицах raw и mangle, которые позволяют вмешиваться в работу механизма отслеживания состояний и физически изменять служебные поля сетевых пакетов.

Таблица Raw: превентивное управление состояниями

Сетевой стек Linux по умолчанию является stateful-системой. Каждое новое соединение фиксируется подсистемой conntrack (Connection Tracking), которая выделяет память для хранения информации об IP-адресах, портах, таймаутах и текущем статусе сессии. Проверка по таблице состояний происходит за время , но сама таблица имеет жесткий лимит записей (параметр net.ipv4.netfilter.ip_conntrack_max). При превышении этого лимита ядро начинает отбрасывать новые пакеты с сообщением «nf_conntrack: table full, dropping packet».

Таблица raw существует исключительно для того, чтобы перехватить пакет до того, как он попадет в механизм conntrack. Она привязана только к двум хукам: PREROUTING (для входящего и транзитного трафика) и OUTPUT (для локально сгенерированного).

!Место таблицы raw в цепочке обработки пакета и обход conntrack

Основной инструмент в таблице raw — действие NOTRACK (в современных ядрах реализуется через модуль CT с ключом --notrack). Применение этого действия вешает на пакет специальный флаг, который приказывает подсистеме conntrack игнорировать его.

Защита высоконагруженных stateless-сервисов

Классический сценарий применения таблицы raw — защита публичного DNS-сервера. DNS-трафик (UDP порт 53) в большинстве случаев состоит из одиночных запросов и ответов. Отслеживать их состояние бессмысленно, так как после отправки ответа серверу больше не нужно помнить о клиенте. Однако при DDoS-атаке типа DNS Amplification злоумышленники генерируют сотни тысяч запросов в секунду. Conntrack покорно создает запись для каждого поддельного UDP-пакета, исчерпывает лимит памяти за несколько секунд и парализует весь сервер.

Отключение отслеживания для порта 53 решает эту проблему:

При такой конфигурации пакеты пройдут через сетевой стек как stateless-трафик. Важный нюанс: поскольку пакеты теперь не имеют состояния, в таблице filter для них не сработает правило -m state --state ESTABLISHED,RELATED. Разрешать такой трафик в цепочках INPUT и OUTPUT придется явными правилами, проверяющими порты и протоколы.

Оптимизация защиты от SYN-флуда

Таблица raw также применяется для раннего сбрасывания мусорного трафика. Если сервер подвергается SYN-флуду, нет смысла пропускать эти пакеты через conntrack, маршрутизацию и другие таблицы, чтобы заблокировать их в INPUT. Блокировка в PREROUTING таблицы raw экономит такты процессора:

Здесь отбрасываются пакеты, которые заявляют себя как новые (не принадлежат известному соединению), но при этом не имеют флага SYN. Обработка таких аномалий на самом раннем этапе — архитектурно правильный подход к построению эшелонированной защиты.

Таблица Mangle: хирургия сетевых пакетов

Если таблица raw предназначена для управления внутренними механизмами ядра, то таблица mangle (от англ. mangle — искажать, кромсать) создана для изменения самих пакетов и их метаданных. Она присутствует во всех пяти стандартных цепочках (PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING), что позволяет модифицировать трафик на любом этапе его жизненного цикла.

Действия в таблице mangle делятся на две принципиально разные категории: изменение реальных заголовков пакета (IP/TCP) и изменение внутренних структур данных ядра, привязанных к пакету.

!Разница между изменением IP-заголовка и установкой внутренней метки sk_buff

Внутренняя маркировка: действие MARK

В ядре Linux каждый сетевой пакет оборачивается в структуру данных sk_buff (socket buffer). Эта структура содержит не только сам пакет, но и служебную информацию: через какой интерфейс он пришел, к какому сокету относится и так называемую метку fwmark (firewall mark).

Действие MARK в таблице mangle изменяет именно это 32-битное поле в sk_buff, не трогая сам сетевой пакет. Метка существует только в оперативной памяти маршрутизатора и бесследно исчезает, как только пакет покидает сетевой интерфейс.

Главное назначение MARK — интеграция Netfilter с подсистемой маршрутизации (iproute2) и подсистемой управления трафиком (Traffic Control, tc). Стандартная маршрутизация принимает решение (Routing Decision) исключительно на основе IP-адреса назначения. Но что, если нужно направить весь HTTP-трафик через одного провайдера, а SMTP — через другого?

Здесь на помощь приходит Policy-Based Routing (PBR). Сначала iptables помечает пакеты:

Затем утилита ip rule перехватывает пакеты с этими метками и отправляет их в разные таблицы маршрутизации:

Маркировка позволяет создавать сложнейшие топологии, маршрутизируя трафик не по адресам, а по протоколам, времени суток или даже статистической вероятности (с использованием модуля statistic).

Модификация IP-заголовков: TTL и DSCP

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

Управление Time To Live (TTL) Поле TTL в IP-заголовке предотвращает бесконечное блуждание пакетов в сетях с петлями маршрутизации. Каждый маршрутизатор на пути обязан уменьшить TTL на единицу. Если TTL достигает нуля, пакет уничтожается, а отправителю посылается ICMP-сообщение Time Exceeded.

Частый сценарий использования действия TTL — скрытие факта использования маршрутизатора от интернет-провайдера (например, при раздаче мобильного интернета). Провайдер ожидает, что пакеты от смартфона будут иметь начальный . Если смартфон используется как точка доступа, он выступает в роли маршрутизатора, уменьшая TTL пакетов от подключенного ноутбука до 63. Провайдер видит это и блокирует трафик.

Таблица mangle позволяет жестко зафиксировать TTL перед отправкой пакета провайдеру:

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

Управление приоритетами: DSCP Поле DSCP (Differentiated Services Code Point) в IP-заголовке используется для обеспечения качества обслуживания (QoS). Оно указывает транзитным маршрутизаторам, какой приоритет имеет данный пакет.

Например, для VoIP-трафика критичны задержки и джиттер. С помощью таблицы mangle можно установить класс Expedited Forwarding (EF), который в шестнадцатеричном виде обозначается как 0x2e:

В отличие от MARK, метка DSCP сохраняется в пакете и передается по всей сети. Если транзитные провайдеры на пути следования пакета настроены на уважение DSCP-меток, голосовой трафик получит приоритет в очередях на каждом узле.

TCP MSS Clamping: спасение инкапсулированного трафика

Одна из самых изящных и жизненно важных функций таблицы mangle — модификация опции MSS (Maximum Segment Size) в заголовках TCP. Эта техника решает проблему «черных дыр» MTU (Path MTU Discovery Blackhole), которая массово возникает при использовании VPN, PPPoE и других туннельных протоколов.

Физика проблемы MTU

Стандартный размер пакета (MTU, Maximum Transmission Unit) в сетях Ethernet составляет 1500 байт. Когда устанавливается TCP-соединение, клиент и сервер обмениваются пакетами SYN. В этих пакетах они передают опцию MSS — максимальный размер полезной нагрузки, который они готовы принять. Размер MSS высчитывается по формуле: . Для стандартного Ethernet: байт.

Проблема возникает, когда на пути пакета появляется туннель (например, IPsec), который добавляет свои заголовки. Допустим, IPsec добавляет 50 байт оверхеда. Эффективный MTU внутри туннеля становится равным 1450 байт.

Если клиент и сервер не знают о туннеле, они договорятся об . Когда сервер отправит полный пакет (1500 байт), маршрутизатор с IPsec-туннелем не сможет его пропихнуть. По стандарту маршрутизатор должен отбросить пакет и отправить серверу ICMP-сообщение «Fragmentation Needed» (Type 3, Code 4), указав новый MTU. Сервер уменьшит размер пакета, и связь продолжится. Этот механизм называется Path MTU Discovery (PMTUD).

Однако в реальном интернете многие администраторы бездумно блокируют весь ICMP-трафик в таблице filter. Маршрутизатор отбрасывает большой пакет, отправляет ICMP-уведомление, но firewall сервера его блокирует. Сервер ничего не знает о проблеме и продолжает слать пакеты по 1500 байт. Клиент их не получает. Визуально это выглядит так: TCP-соединение устанавливается (мелкие SYN-пакеты проходят), но при попытке передать данные (например, загрузить сайт или выполнить команду ls -l по SSH) сессия намертво зависает.

Хирургическое вмешательство через TCPMSS

Поскольку мы не можем заставить чужие серверы разрешить ICMP, проблему приходится решать на нашем маршрутизаторе, терминирующем туннель. Мы можем перехватить TCP SYN пакет в момент установки соединения и подделать значение MSS в его заголовке.

!Влияние MTU туннеля на расчет оптимального значения TCP MSS

Для этого используется действие TCPMSS в таблице mangle, обычно в цепочке FORWARD:

Это правило работает следующим образом:

Оно перехватывает только пакеты с установленным флагом SYN (начало соединения).

Действие --clamp-mss-to-pmtu заставляет ядро автоматически вычислить правильный MSS на основе MTU исходящего интерфейса маршрутизатора. Если MTU туннеля 1450, ядро перепишет MSS в пакете на 1410 ().

Сервер получит подделанный SYN-пакет, решит, что клиент имеет ограничение сети, и никогда не отправит пакет больше 1450 байт.

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

Границы ответственности таблиц

При проектировании архитектуры Netfilter критически важно соблюдать семантику таблиц. Технически iptables позволяет выполнить действие MARK в таблице nat или сбросить пакет (DROP) в таблице mangle. Однако это считается грубым нарушением архитектуры.

Таблица nat обрабатывает только первый пакет соединения (в состоянии NEW). Если поставить метку MARK в таблице nat, она применится только к первому пакету. Все последующие пакеты этой сессии не получат метку, и Policy-Based Routing сломается: первый пакет уйдет через одного провайдера, а остальные — через дефолтный шлюз. Именно поэтому MARK применяется строго в mangle, которая добросовестно обрабатывает каждый пакет потока.

Аналогично, фильтрация (DROP) в таблице mangle усложняет аудит безопасности. Администратор, пришедший настраивать сервер, будет искать правила блокировки в таблице filter. Пакеты, исчезающие на этапе mangle, превратят диагностику сети в многочасовой квест. Таблицы raw и mangle — это специализированные инструменты: первая изолирует трафик от ресурсоемкого анализа состояний, вторая адаптирует пакеты под требования сложной маршрутизации и туннелирования.

Сетевой фильтр, принимающий решения на основе каждого отдельного пакета, слеп. Если администратор разрешает исходящий трафик на порт 80, ему приходится открывать входящий трафик с порта 80 на все непривилегированные порты сервера, чтобы получить ответ. Это оставляет зияющую дыру в безопасности: злоумышленник может запустить сканирование (например, Nmap ACK scan), отправляя пакеты с флагом ACK с 80-го порта, и stateless-брандмауэр беспрепятственно пропустит их внутрь сети, так как они формально подпадают под разрешающее правило. Настоящая безопасность начинается там, где ядро перестает видеть разрозненные пакеты и начинает видеть сессии. Эту трансформацию обеспечивает подсистема отслеживания состояний — conntrack.

Анатомия памяти: как ядро узнает соединения

Подсистема conntrack (connection tracking) — это независимый от iptables модуль ядра Linux, который анализирует проходящий трафик и выстраивает внутреннюю базу данных активных соединений. Эта база располагается в оперативной памяти и представляет собой хэш-таблицу.

Каждое соединение идентифицируется уникальным набором из пяти параметров, известным как 5-tuple (кортеж из пяти элементов). В него входят:

Протокол сетевого уровня (обычно IPv4 или IPv6).

IP-адрес источника.

IP-адрес назначения.

Протокол транспортного уровня (TCP, UDP, ICMP и др.).

Порты источника и назначения (или типы/коды для ICMP).

Когда пакет попадает в сетевой стек, хук PREROUTING (для входящего/транзитного трафика) или OUTPUT (для локально сгенерированного) передает его в conntrack сразу после обработки таблицей raw. Ядро вычисляет хэш от 5-tuple пакета и ищет соответствующую запись в таблице состояний.

!Структура хэш-таблицы conntrack и 5-tuple

Если запись найдена, пакету присваивается статус принадлежности к существующему соединению. Если нет — ядро создает новую запись. Важно понимать, что conntrack отслеживает соединения в обоих направлениях. Запись в таблице содержит два набора 5-tuple: оригинальный (в направлении инициатора) и ожидаемый ответный (где адреса и порты поменяны местами). Именно это позволяет фильтру безошибочно пропускать легитимные ответы, отсекая поддельные пакеты сканеров.

Матрица состояний: за пределами флагов TCP

В iptables для работы с conntrack используется модуль расширения state (или его более современный аналог conntrack). Он оперирует пятью базовыми состояниями, которые не следует путать с состояниями самого протокола TCP (такими как SYN_SENT или TIME_WAIT). Состояния conntrack — это абстракция ядра, применимая к любому протоколу.

NEW — пакет открывает новое соединение. Для TCP это обычно пакет с флагом SYN. Однако, если таблица conntrack была очищена, а TCP-сессия уже идет, первый же перехваченный пакет (даже просто с флагом ACK) получит статус NEW.

ESTABLISHED — ядро увидело двусторонний обмен трафиком. Как только на пакет со статусом NEW приходит ответ, совпадающий с инвертированным 5-tuple, соединение переходит в статус ESTABLISHED.

RELATED — пакет открывает новое соединение, но оно логически связано с уже существующим ESTABLISHED соединением.

INVALID — пакет не принадлежит ни одному известному соединению и не может начать новое. Причины: неверная контрольная сумма, TCP-пакет с флагами FIN/RST без предварительного SYN, или выход sequence-номеров далеко за пределы окна.

UNTRACKED — пакет был явно исключен из отслеживания в таблице raw действием NOTRACK.

Базовый паттерн stateful-фильтрации, который должен присутствовать на любом сервере, выглядит так: iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

Это позволяет ядру мгновенно пропускать легитимный трафик ( при проверке хэша) и отбрасывать мусор до того, как он дойдет до ресурсоемких проверок по портам и IP-адресам.

Иллюзия состояний: TCP, UDP и ICMP

Поведение conntrack радикально меняется в зависимости от транспортного протокола.

Строгий контроль TCP

TCP — протокол с сохранением состояния по своей природе. conntrack внимательно следит за флагами. При получении SYN создается запись со статусом NEW и внутренним таймером nf_conntrack_tcp_timeout_syn_sent (по умолчанию 120 секунд). Если приходит SYN-ACK, таймер обновляется до 60 секунд. После завершающего ACK соединение переходит в ESTABLISHED, а таймер взлетает до nf_conntrack_tcp_timeout_established — по умолчанию это невероятные 432000 секунд (5 суток).

!Связь состояний TCP и статусов conntrack

При получении пакета с флагом FIN conntrack не удаляет запись мгновенно, а переводит ее во внутреннее состояние TIME_WAIT с коротким таймером (120 секунд), чтобы обработать возможные задержавшиеся в сети пакеты.

Таймеры для UDP

UDP не имеет флагов, номеров последовательностей и процесса установки соединения. Как для него работает ESTABLISHED? Исключительно на основе времени. Когда сервер отправляет DNS-запрос (UDP порт 53), conntrack фиксирует 5-tuple, присваивает пакету статус NEW и запускает таймер nf_conntrack_udp_timeout (30 секунд). Если в течение этого времени приходит ответ от DNS-сервера, соединение становится ESTABLISHED, а таймер меняется на nf_conntrack_udp_timeout_stream (180 секунд). Каждое новое сообщение сбрасывает таймер. Если обмен прекращается, по истечении 180 секунд запись молча удаляется из памяти.

ICMP и эхо-ответы

ICMP также не имеет концепции сессий. Однако conntrack умеет связывать запросы и ответы по типам сообщений и идентификаторам. Пакет Echo Request (Type 8) получает статус NEW. Ответный Echo Reply (Type 0) с тем же ID распознается как ESTABLISHED.

Магия RELATED и модули-помощники

Состояние RELATED — это интеллектуальное ядро conntrack. Оно решает проблему сложных многоканальных протоколов, где управляющий трафик идет по одному порту, а данные — по другому, динамически согласованному.

Классический пример — протокол FTP в пассивном режиме. Клиент подключается к серверу на TCP порт 21 (управляющий канал, статус NEW -> ESTABLISHED). Когда клиент хочет скачать файл, он отправляет команду PASV. Сервер отвечает: «Я открыл для тебя случайный порт 50123, подключайся туда для передачи данных». С точки зрения строгой фильтрации, попытка клиента подключиться на порт 50123 — это абсолютно новое соединение, которое будет заблокировано политикой DROP.

Чтобы решить это, в ядре существуют модули-помощники (helpers), такие как nf_conntrack_ftp. Этот модуль постоянно сканирует полезную нагрузку (payload) пакетов внутри ESTABLISHED соединений на порту 21.

!Механизм работы FTP helper и создание expectation

Как только помощник видит в тексте пакета ответ сервера с номером динамического порта, он создает в памяти ядра структуру под названием Expectation (ожидание). conntrack теперь знает: в ближайшие секунды с IP-адреса клиента на IP-адрес сервера на порт 50123 должен прийти пакет с флагом SYN. Когда этот пакет действительно приходит, он получает статус не NEW, а RELATED. Правило --ctstate ESTABLISHED,RELATED -j ACCEPT пропускает его, и передача данных начинается без необходимости открывать весь диапазон непривилегированных портов.

Тот же механизм RELATED спасает диагностику сети. Если маршрутизатор отбрасывает пакет из-за превышения MTU, он генерирует ICMP-сообщение Fragmentation Needed (Type 3, Code 4). Это сообщение является отдельным пакетом, но conntrack заглядывает внутрь его заголовка, видит там кусок оригинального TCP/UDP пакета, находит его в своей хэш-таблице и присваивает ICMP-ошибке статус RELATED.

Память о маршрутизации: CONNMARK

Метка MARK, устанавливаемая в таблице mangle, живет только в структуре sk_buff конкретного пакета. Как только пакет покидает ядро, метка исчезает. Это создает колоссальную проблему при маршрутизации с несколькими провайдерами (Dual-WAN).

Если мы пометили первый пакет от клиента (SYN) меткой 0x1, чтобы направить его через Провайдера А, ответный пакет от сервера (SYN-ACK) придет без метки. Более того, следующий пакет от клиента (ACK) тоже придет без метки, и ядро может ошибочно отправить его через Провайдера Б, что приведет к разрыву соединения.

Здесь на помощь приходит CONNMARK — механизм переноса меток между пакетами и таблицей conntrack. Запись в conntrack персистентна для всей сессии. Логика работы с CONNMARK строится в два этапа:

Восстановление метки (PREROUTING):

При поступлении любого пакета мы проверяем, есть ли у его соединения сохраненная метка, и если да — копируем ее на пакет. iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark Если это пакет ESTABLISHED, он получает свою метку и корректно маршрутизируется. Если это NEW, метки в conntrack еще нет, и пакет остается без нее.

Сохранение метки (PREROUTING или POSTROUTING):

Для новых пакетов мы применяем сложную логику классификации (например, по IP источника или входящему интерфейсу), устанавливаем обычный MARK, а затем приказываем conntrack запомнить его для всей сессии. iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j CONNMARK --save-mark

Теперь каждый последующий пакет этого соединения, проходя через первый шаг (--restore-mark), автоматически получит нужную метку маршрутизации. Состояние соединения стало носителем инфраструктурной логики.

Пределы прочности: тюнинг и защита от переполнения

За отслеживание состояний приходится платить оперативной памятью. Каждая запись в таблице conntrack занимает около 300 байт в ядре (зависит от архитектуры).

Если сервер подвергается DDoS-атаке (например, SYN-флуду или UDP-флуду с рандомизированных IP-адресов), таблица стремительно заполняется. Когда достигается лимит, ядро начинает отбрасывать все новые пакеты с ошибкой в системном логе: nf_conntrack: table full, dropping packet. В этот момент сервер становится недоступен даже для легитимных пользователей, хотя CPU и канал могут быть свободны.

Максимальное количество записей контролируется параметром ядра net.netfilter.nf_conntrack_max. Его можно посмотреть или изменить через sysctl: sysctl -w net.netfilter.nf_conntrack_max=1048576

Однако просто увеличить лимит недостаточно. conntrack использует хэш-таблицу для быстрого поиска. Размер этой таблицы (количество корзин/buckets) задается параметром hashsize. Если лимит записей огромен, а корзин мало, в каждой корзине образуется длинный связанный список коллизий. Поиск записи деградирует от до , и ядро тратит процессорное время на перебор цепочек. Оптимальное соотношение, рекомендуемое разработчиками Netfilter: nf_conntrack_max должен быть равен hashsize × 8. Изменить hashsize на лету можно через интерфейс sysfs: echo 131072 > /sys/module/nf_conntrack/parameters/hashsize

Второй вектор оптимизации высоконагруженных серверов — агрессивное сокращение таймеров. Дефолтные 5 суток для ESTABLISHED TCP-соединений избыточны для современных веб-серверов. Если соединение разорвалось без отправки FIN/RST (например, клиент потерял сеть), запись будет висеть в памяти днями. Администраторы часто снижают этот таймер до 1 часа или даже 15 минут: sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=3600

Подсистема conntrack превращает брандмауэр из простого фильтра заголовков в интеллектуальную систему, понимающую контекст сетевого взаимодействия. Использование состояний NEW, ESTABLISHED и RELATED позволяет создавать лаконичные и непробиваемые наборы правил, где iptables выступает лишь интерфейсом управления, а всю тяжелую работу по анализу сессий, таймеров и протокольных нюансов берет на себя ядро.

Расширенные критерии фильтрации и использование модулей расширений (match/target)

Стандартные критерии iptables, такие как IP-адрес или номер порта, позволяют построить надежный, но довольно грубый забор вокруг сервера. Однако в условиях реальной эксплуатации администратор сталкивается с задачами, которые невозможно решить простым сопоставлением заголовков: как ограничить скорость перебора паролей по SSH, не блокируя легитимных пользователей? Как отсечь ботнет, атакующий специфическую строку в HTTP-запросе? Как динамически изменять правила в зависимости от поведения узла? Ответы кроются в модульной архитектуре расширений iptables.

Архитектура модулей расширения: Match и Target

Инструментарий iptables состоит из базового ядра и набора динамически загружаемых модулей. Это позволяет сохранять легкость основного кода и при этом бесконечно расширять функционал. Модули делятся на два типа:

Match-модули (критерии): вызываются ключом -m (или --match). Они расширяют логику проверки пакета. Если стандартный синтаксис проверяет только поля L3/L4, то модули могут заглядывать в полезную нагрузку (payload), анализировать временные интервалы или обращаться к внутренним словарям состояний.

Target-модули (действия): вызываются ключом -j (или --jump). Помимо стандартных ACCEPT и DROP, существуют расширенные действия, такие как TARPIT (удержание соединения в «липкой» ловушке), TEE (клонирование трафика) или SET (взаимодействие с наборами IPset).

Когда вы пишете -m limit, ядро подгружает библиотеку xt_limit.ko. Если модуль не загружен или отсутствует в системе, команда iptables вернет ошибку. Важно понимать, что использование каждого модуля увеличивает вычислительные затраты на обработку пакета, поэтому выбор расширения должен быть обоснован архитектурно.

Модуль Recent: динамические списки и защита от Brute-force

Один из самых мощных инструментов в арсенале системного администратора — модуль recent. Он позволяет создавать динамические списки IP-адресов прямо в оперативной памяти ядра и выполнять действия на основе того, как часто или как давно адрес попадал в этот список.

Типичный сценарий — защита SSH от перебора паролей. Обычное ограничение по IP неэффективно, если атака идет с распределенного ботнета, но recent позволяет реализовать логику «три попытки в минуту, иначе — бан на час».

Механика работы и параметры

Модуль управляет именованными списками. Основные флаги: * --set: добавить IP-адрес пакета в список (или обновить метку времени, если он уже там). * --update: проверить, есть ли адрес в списке, и обновить метку времени. * --check: просто проверить наличие адреса в списке без обновления метки. * --seconds: задать временное окно для проверки. * --hitcount: количество совпадений (пакетов) внутри временного окна. * --name: имя списка (по умолчанию DEFAULT). * --rttl: проверять TTL пакета (защита от спуфинга адреса в рамках списка).

Рассмотрим реализацию защиты SSH. Мы хотим разрешить не более 3 новых соединений в течение 60 секунд для одного IP:

В этой связке критически важен порядок. Первое правило проверяет: «Если этот IP уже есть в списке SSH_LIMIT и он за последние 60 секунд стучался 4 раза (включая текущий пакет), то сбросить его». Если условие не сработало, пакет переходит ко второму правилу, которое просто регистрирует попытку (--set) и пропускает её.

Управление списками через файловую систему

Списки модуля recent доступны в виртуальной файловой системе /proc/net/xt_recent/. Это позволяет администратору просматривать текущих «подозреваемых» или вручную удалять/добавлять адреса: * echo +1.2.3.4 > /proc/net/xt_recent/SSH_LIMIT — добавить адрес вручную. * echo -1.2.3.4 > /proc/net/xt_recent/SSH_LIMIT — удалить адрес. * echo / > /proc/net/xt_recent/SSH_LIMIT — полностью очистить список.

Лимиты модуля (количество записей в списке и количество отслеживаемых пакетов на адрес) задаются при загрузке модуля параметрами ip_list_tot и ip_pkt_list_tot. Если вы планируете отбивать массированные атаки, стандартного лимита в 100 адресов может не хватить.

Модуль Limit: управление интенсивностью

Модуль limit используется для ограничения скорости совпадения правил. В отличие от recent, он не идентифицирует конкретные IP-адреса, а работает глобально для правила, используя алгоритм «дырявого ведра» (Token Bucket).

Параметры Token Bucket

Логика limit опирается на два параметра:

--limit: средняя скорость (например, 3/minute или 5/second).

--limit-burst: «всплеск» или емкость ведра (по умолчанию 5).

Представьте ведро, в которое помещается 5 жетонов (burst). Каждое совпадение правила забирает один жетон. Жетоны восстанавливаются с заданной скоростью (limit). Если жетонов в ведре нет, правило перестает срабатывать (пакет идет дальше по цепочке).

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

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

Модуль String: фильтрация по содержимому

Иногда угроза кроется не в заголовках, а в теле пакета. Модуль string позволяет искать текстовые или бинарные последовательности в полезной нагрузке. Это простейшая форма DPI (Deep Packet Inspection).

Алгоритмы поиска

Модуль поддерживает два алгоритма: * bm (Boyer-Moore): эффективен для длинных строк. * kmp (Knuth-Pratt-Morris): эффективен для коротких строк.

Основные параметры: * --algo: выбор алгоритма (обязательно). * --string: искомая строка. * --hex-string: искомая последовательность в шестнадцатеричном формате (например, для поиска бинарных сигнатур). * --from и --to: смещение в байтах, где искать (оптимизация, чтобы не сканировать весь пакет).

Пример блокировки попытки эксплуатации уязвимости через специфический GET-запрос:

Нюанс производительности: Сканирование содержимого — самая дорогая операция. Чтобы минимизировать нагрузку, всегда комбинируйте -m string с другими критериями (-p tcp --dport 80) и ограничивайте область поиска (--to 100), если искомая сигнатура находится в начале пакета (как в случае с HTTP-заголовками).

Модуль Time: временные окна доступа

Модуль time позволяет активировать правила в зависимости от времени суток или дня недели. Это полезно для офисных сетей или регламентных работ.

Параметры: * --timestart и --timestop: время в формате HH:MM. * --weekdays: дни недели (Mon, Tue, Wed...). * --monthdays: числа месяца. * --datestart и --datestop: конкретные даты в формате ISO.

Пример: разрешить доступ к внешнему игровому серверу только в нерабочее время:

Важно: iptables по умолчанию использует время UTC. Если ваш сервер находится в другом часовом поясе, используйте флаг --kerneltz (использовать локальное время ядра), но будьте осторожны с переходом на летнее/зимнее время.

Модуль Connlimit: ограничение параллельных сессий

В то время как limit ограничивает скорость пакетов, connlimit ограничивает количество одновременно открытых TCP-соединений от одного клиента или целой подсети. Это классическая защита от "тяжелых" запросов, которые могут занять все воркеры веб-сервера.

Параметры: * --connlimit-above n: сработать, если количество соединений больше . * --connlimit-mask n: группировать клиентов по маске подсети (например, /24). * --connlimit-saddr / --connlimit-daddr: применять лимит к источнику или назначению.

Пример: ограничить количество SSH-сессий до двух с одного IP-адреса:

Использование REJECT с tcp-reset здесь предпочтительнее DROP, так как клиент сразу получит уведомление о разрыве и не будет пытаться удерживать полуоткрытую сессию.

Модуль Multiport: оптимизация правил

Если вам нужно открыть 10 разных портов, создание 10 отдельных правил неэффективно, так как пакет будет сравниваться с каждым по очереди (). Модуль multiport позволяет проверить до 15 портов (или диапазонов) в рамках одного правила.

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

Модуль Owner: контроль локальных процессов

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

* --uid-owner: ID пользователя. * --gid-owner: ID группы. * --socket-exists: пакет принадлежит существующему сокету.

Это критически важно для безопасности. Например, если ваш веб-сервер (пользователь www-data) не должен инициировать никаких соединений, кроме запросов к базе данных и DNS:

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

Модуль IPset: работа с огромными списками

Когда количество блокируемых IP-адресов исчисляется тысячами (например, списки стран или спам-базы), использование iptables -A для каждого адреса фатально для производительности. Каждое правило в цепочке — это последовательная проверка. 10 000 правил превратят обработку каждого пакета в пытку для процессора.

IPset — это внешняя по отношению к iptables утилита и подсистема ядра, которая хранит адреса в виде хэш-таблиц. Поиск по хэш-таблице выполняется за константное время , независимо от размера списка.

Связка iptables и ipset

Сначала создается сет в пространстве пользователя:

Затем в iptables добавляется одно-единственное правило, использующее модуль set:

Параметр src указывает, что мы ищем IP источника в этом сете. Если нужно проверить и источник, и назначение (например, для пар IP:Port), используются сеты типа hash:ip,port.

Модуль Statistic: балансировка и вероятностная фильтрация

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

Поддерживаются два режима:

random: правило срабатывает с заданной вероятностью.

nth: правило срабатывает каждый -й раз.

Пример балансировки исходящего трафика между двумя провайдерами (в сочетании с таблицей mangle и метками):

Здесь каждый первый пакет из двух помечается меткой 1, а каждый второй — меткой 2. Далее система маршрутизации (ip rule) направит их в разные каналы.

Расширенные Target-модули: за пределами ACCEPT и DROP

TEE: зеркалирование трафика

Модуль TEE позволяет клонировать пакет и отправить его копию на другой хост, при этом оригинал продолжает свой путь по цепочке. Это незаменимо для систем обнаружения вторжений (IDS), таких как Snort или Suricata.

NFLOG: продвинутое логирование

Вместо записи в системный журнал через LOG (что нагружает syslogd), NFLOG передает пакеты в специальную группу многоадресной рассылки Netlink. Утилиты вроде tcpdump или ulogd2 могут подписываться на эти группы и обрабатывать логи более эффективно.

SET: динамическое наполнение IPset

Действие SET (не путать с матчем -m set) позволяет динамически добавлять или удалять адреса из IPset прямо в процессе обработки пакета. Это делает iptables "самообучающейся" системой.

Комбинирование модулей: создание эшелонированной защиты

Сила iptables проявляется в синергии модулей. Рассмотрим комплексный пример: защита веб-сервера от HTTP-флуда.

Используем multiport для применения правила к 80 и 443 портам.

Используем connlimit для ограничения числа сессий с одного IP (не более 20).

Используем limit для ограничения скорости новых соединений.

Используем recent для временной блокировки тех, кто превысил лимиты.

В этой схеме пакет проходит через серию фильтров. Если он превышает лимит соединений или скорость, он попадает в цепочку ANTIFLOOD, которая заносит его в recent-список BLACKLIST и сбрасывает. При следующем обращении пакет будет отброшен в самом начале цепочки INPUT на основании записи в BLACKLIST.

Нюансы производительности и отладки

При использовании расширений важно помнить о порядке вычислений. iptables выполняет проверки слева направо. Если вы напишете: iptables -A INPUT -m string --algo bm --string "bad" -p tcp --dport 80 -j DROP Ядро будет запускать дорогой поиск строки для каждого входящего пакета (включая UDP, ICMP и т.д.).

Правильный подход: iptables -A INPUT -p tcp --dport 80 -m string --algo bm --string "bad" -j DROP Здесь поиск строки запустится только для TCP-пакетов на 80 порт. Сначала дешевые проверки (протокол, порт), затем дорогие (строки, состояния).

Для отладки сложных правил с модулями используйте счетчики: iptables -L -n -v Если вы видите, что счетчик пакетов у правила с limit или recent растет, значит, логика работает. Если пакеты "пролетают" мимо — проверьте порядок правил или специфические параметры модулей (например, соответствие UTC времени в модуле time).

Модульная система превращает iptables из простого пакетного фильтра в интеллектуальный брандмауэр, способный адаптироваться к нагрузке и характеру трафика. Глубокое понимание того, как работают recent, limit, ipset и owner, позволяет строить системы защиты, которые не просто блокируют трафик, а управляют качеством сетевой среды.

Методы диагностики, логирования и отладки цепочек сетевых правил

Сетевой пакет поступает на внешний интерфейс сервера. Утилита tcpdump отчетливо фиксирует его прибытие. Однако приложение, слушающее нужный порт, не получает никаких данных, а клиент отваливается по таймауту. Администратор проверяет правила командой iptables -L и видит разрешающее правило для этого порта. Начинается слепой перебор: отключение таблиц, сброс политик, перезапуск сервисов. Эта классическая ситуация возникает, когда понимание архитектуры Netfilter не подкреплено навыками инструментальной диагностики. Сетевой стек ядра Linux не является «черным ящиком», он предоставляет исчерпывающий набор механизмов для трассировки пакета на каждом этапе его жизненного цикла.

Анатомия тихих отбрасываний и работа со счетчиками

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

Команда iptables -nvL --line-numbers является базовым инструментом. Ключ -v (verbose) выводит столбцы pkts (количество пакетов) и bytes (объем данных). Ключ -n отключает разрешение DNS-имен, что критически важно для скорости вывода, а --line-numbers привязывает правила к их текущим индексам.

Счетчики позволяют выявить проблему «теневых правил» (Rule Shadowing). Если в цепочке INPUT правилом под номером 2 запрещен весь трафик от подсети , а правилом под номером 5 разрешен доступ по SSH от хоста , счетчики правила 5 всегда будут равны нулю. Пакет уничтожается до того, как ядро дойдет до пятой строки.

Однако нулевые счетчики на разрешающем правиле могут означать не только блокировку выше по списку. Пакет мог быть отброшен в другой таблице (например, mangle или raw), он мог не пройти проверку маршрутизации (Routing Decision) и уйти в цепочку FORWARD вместо INPUT, или подсистема conntrack пометила его как INVALID и отбросила до попадания в цепочку фильтрации. Для выяснения точной причины требуются активные методы трассировки.

Действие LOG и защита кольцевого буфера

Самый прямолинейный способ узнать судьбу пакета — заставить ядро написать о нем в системный журнал. В отличие от ACCEPT или DROP, действие LOG является незавершающим (Non-terminating target). Когда пакет совпадает с правилом -j LOG, Netfilter отправляет метаданные пакета в кольцевой буфер ядра (ring buffer), после чего пакет переходит к следующему правилу в цепочке.

Базовый синтаксис включает префикс для облегчения поиска в логах: iptables -A INPUT -p tcp --dport 22 -j LOG --log-prefix "SSH_DROP: " --log-level 4

Записи появятся в выводе dmesg или в journalctl -k (в зависимости от системы инициализации). В логе будут указаны интерфейсы (IN, OUT), MAC-адреса, IP-адреса источника и назначения, длина пакета, значения TTL и флаги TCP.

Главная опасность использования LOG — исчерпание ресурсов (Log Flooding). Если направить в лог весь отбрасываемый транзитный трафик на высоконагруженном маршрутизаторе, ядро начнет тратить процессорное время на форматирование строк и запись их на диск, что приведет к отказу в обслуживании (DoS). Для безопасного логирования действие LOG всегда комбинируют с модулем limit, который реализует алгоритм Token Bucket.

Пример безопасного логирования пакетов со статусом INVALID: iptables -A INPUT -m state --state INVALID -m limit --limit 1/sec --limit-burst 5 -j LOG --log-prefix "INV_PKT: " iptables -A INPUT -m state --state INVALID -j DROP

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

TRACE: Рентгеновский снимок сетевого стека

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

TRACE — это специальное действие, доступное только в таблице raw. Поскольку таблица raw обрабатывает пакеты в хуках PREROUTING и OUTPUT (до подсистемы conntrack и маршрутизации), маркировка пакета здесь гарантирует, что мы увидим каждый его шаг.

Для работы трассировки в современных ядрах необходимо активировать модуль логирования и указать ядру, какой бэкенд использовать для IPv4: modprobe nf_log_ipv4 sysctl -w net.netfilter.nf_log.2=nf_log_ipv4

Затем создается максимально узкое правило в таблице raw. Трассировать весь трафик категорически нельзя — это парализует сервер. iptables -t raw -A PREROUTING -p icmp -s 10.0.0.5 -j TRACE

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

TRACE: raw:PREROUTING:policy:2 IN=eth0 OUT= MAC=... SRC=10.0.0.5 DST=192.168.1.10 ... TRACE: mangle:PREROUTING:policy:1 IN=eth0 OUT= MAC=... SRC=10.0.0.5 DST=192.168.1.10 ... TRACE: filter:INPUT:rule:4 IN=eth0 OUT= MAC=... SRC=10.0.0.5 DST=192.168.1.10 ...

В этом выводе видно, что пакет прошел политику по умолчанию в таблице raw, затем в mangle, а в таблице filter цепочки INPUT он совпал с правилом номер 4. Если на этом трассировка обрывается, значит, правило номер 4 выполнило завершающее действие (например, DROP). Механизм TRACE исключает любые гадания при отладке сложных переплетений пользовательских цепочек и механизмов NAT.

NFLOG и интеграция с tcpdump

Текстовые логи ядра (LOG и TRACE) содержат только заголовки пакетов. Если для диагностики требуется заглянуть в полезную нагрузку (payload) отброшенного пакета, текстовых логов недостаточно. Здесь на помощь приходит действие NFLOG.

Вместо записи в кольцевой буфер ядра, NFLOG инкапсулирует пакет и отправляет его в пользовательское пространство (user-space) через специальный сокет Netlink. Это позволяет внешним приложениям перехватывать пакеты прямо из конвейера Netfilter.

Ключевым параметром является --nflog-group, который определяет номер канала (группы) Netlink: iptables -A FORWARD -p tcp --dport 80 -m string --algo bm --string "malicious_payload" -j NFLOG --nflog-group 5 iptables -A FORWARD -p tcp --dport 80 -m string --algo bm --string "malicious_payload" -j DROP

В этом сценарии пакеты, содержащие определенную строку, перед уничтожением копируются в группу Netlink номер 5. Самое мощное применение этого механизма — прямая интеграция с tcpdump. Утилита tcpdump умеет читать данные из интерфейсов nflog.

Запустив команду tcpdump -i nflog:5 -w dropped_http.pcap, администратор получает полноценный pcap-дамп только тех пакетов, которые были заблокированы конкретным правилом iptables. Это позволяет анализировать атаки или сбои протоколов в Wireshark без необходимости дампить весь гигабитный поток трафика на физическом интерфейсе.

Парадокс tcpdump: Где находится точка перехвата?

При отладке сетевых проблем часто возникает когнитивный диссонанс: tcpdump показывает, что пакет уходит с интерфейса, но счетчики iptables в цепочке OUTPUT молчат. Или наоборот: iptables блокирует пакет в INPUT, но tcpdump все равно видит его прибытие.

Чтобы правильно интерпретировать данные диагностики, необходимо понимать расположение хука AF_PACKET, который использует tcpdump (через библиотеку libpcap), относительно хуков Netfilter.

Для входящего трафика (Ingress): Сетевая карта Драйвер AF_PACKET (tcpdump) Netfilter (PREROUTING INPUT) Приложение.

Для исходящего трафика (Egress): Приложение Маршрутизация Netfilter (OUTPUT POSTROUTING) AF_PACKET (tcpdump) Драйвер Сетевая карта.

Это архитектурное решение диктует жесткие правила диагностики:

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

Если tcpdump не видит входящий пакет, проблема находится до сервера (маршрутизатор провайдера, коммутатор, физический линк). Искать ошибку в iptables бессмысленно.

Если tcpdump видит исходящий пакет, значит, пакет успешно прошел все цепочки iptables (включая OUTPUT и POSTROUTING) и был передан драйверу сетевой карты.

Если приложение отправило ответ, но tcpdump его не видит, значит, пакет был убит внутри Netfilter (например, политикой OUTPUT DROP) или ядро не смогло найти маршрут к получателю.

Понимание этой схемы позволяет локализовать проблему за пару минут, просто сопоставив наличие пакета в pcap-дампе и инкрементацию счетчиков в таблице raw.

Диагностика состояний: conntrack events

Некоторые пакеты отбрасываются ядром даже при наличии разрешающих правил ACCEPT. Чаще всего это происходит из-за несовпадения состояний в подсистеме отслеживания соединений (conntrack). Например, если пакет принадлежит к существующей TCP-сессии, но его Sequence Number выходит за пределы ожидаемого окна, conntrack пометит его как INVALID. Если в цепочке INPUT есть правило, сбрасывающее невалидные пакеты, соединение зависнет, а стандартные логи не дадут понимания причины.

Для отладки динамических состояний используется утилита conntrack в режиме мониторинга событий: conntrack -E

Эта команда подключается к ядру и в реальном времени выводит изменения состояний соединений (события NEW, UPDATE, DESTROY).

Пример вывода при попытке установить соединение, которое блокируется асимметричной маршрутизацией: [NEW] tcp 6 120 SYN_SENT src=10.0.0.2 dst=192.168.1.10 sport=45678 dport=80 [UNREPLIED] src=192.168.1.10 dst=10.0.0.2 sport=80 dport=45678 [UPDATE] tcp 6 60 SYN_RECV src=10.0.0.2 dst=192.168.1.10 sport=45678 dport=80 src=192.168.1.10 dst=10.0.0.2 sport=80 dport=45678 [DESTROY] tcp 6 src=10.0.0.2 dst=192.168.1.10 sport=45678 dport=80 src=192.168.1.10 dst=10.0.0.2 sport=80 dport=45678

Если после SYN_RECV сразу следует DESTROY, а не ESTABLISHED, это сигнализирует о том, что ядро получило TCP RST (сброс) или истек короткий таймаут из-за того, что ответные пакеты ушли через другой интерфейс и conntrack не смог связать их в единую сессию.

Анализ событий conntrack позволяет диагностировать проблемы с NAT, обрывы VPN-туннелей и некорректную работу модулей-помощников (например, FTP или SIP), когда управляющий канал устанавливается успешно, а динамические порты данных не открываются.

Комплексная отладка Netfilter требует последовательного сужения зоны поиска. Начиная с проверки счетчиков для выявления теневых правил, администратор переходит к перехвату трафика на границах сетевого стека с помощью tcpdump. Если пакет входит в систему, но исчезает, применяется TRACE для пошагового контроля хуков. А в случаях, когда требуется глубокий анализ отброшенной полезной нагрузки, NFLOG предоставляет мост между пространством ядра и инструментами DPI в пользовательском пространстве.