Как ограничить доступ к SSH-порту только определёнными IP?

Нужно создать разрешающее правило для новых подключений, которое одновременно задаёт административный сервис, протокол, порт и разрешённые IP-адреса или подсети источников. SSH не следует открывать для всех, если доступ возможен только через VPN, bastion host или выделенные административные адреса. Для часто меняющихся источников лучше использовать именованную группу или набор адресов.

Нужны ли отдельные правила для IPv6, если есть белый список IPv4?

Да. IPv4-allowlist не ограничивает доступ по IPv6: это самостоятельный путь к сервису. Если сервис слушает IPv6 и правила созданы только для IPv4, он может остаться доступным неразрешённым клиентам. Нужно отдельно проверить правила для обоих семейств адресов и область действия правила в используемом firewall.

Почему разрешающее правило firewall не срабатывает?

Сначала опишите один конкретный поток: направление, IPv4 или IPv6, интерфейс, адреса источника и назначения, протокол, порт и состояние соединения. Затем проверьте не только правило нужного порта, но и широкие правила по подсети, интерфейсу, зоне, профилю, приложению и состоянию соединения. Дальнейшая проверка зависит от механизма. В iptables важны порядок правил в цепочке, переходы в пользовательские цепочки и политика цепочки. В nftables нужно учитывать hook, приоритеты, базовые и обычные цепочки, вызовы и вердикты. В firewalld проверьте зоны и policies, а в Microsoft Defender Firewall — активный профиль, область действия правил и источники политики. Если это предусмотрено конфигурацией, используйте счётчики и журналы: они показывают, какое правило увидело пакет. Исправляйте правило, которое действительно перекрывает поток, а не добавляйте в конец широкое разрешение. После изменения повторите проверку из разрешённого источника и отдельно убедитесь, что доступ не появился у неразрешённых клиентов.

DROP безопаснее REJECT?

Не всегда. DROP молча отбрасывает пакет, поэтому клиент ждёт тайм-аут или повторяет попытку. REJECT возвращает явный отказ и может ускорить диагностику для легитимного клиента. Для нежелательных подключений из недоверенной сети выбор зависит от требований к диагностике, поведения клиентов и допустимости ответного пакета; сам по себе DROP не защищает от сканирования или атак.

Почему старая SSH-сессия работает, а новая после смены правил не открывается?

Перед удалённым изменением firewall сохраните текущую конфигурацию и подготовьте аварийный доступ: консоль, BMC, провайдерскую консоль или другой согласованный способ восстановления. Зафиксируйте фактический канал управления: протокол, порт, реальные IPv4- и IPv6-адреса администратора, целевой интерфейс и необходимость VPN либо bastion host. Сначала добавьте узкое разрешение для нового административного подключения, а не временный доступ для всех адресов. Также предусмотрите loopback и обработку уже установленных допустимых соединений согласно модели используемого firewall. Только после этого открывайте вторую SSH- или RDP-сессию именно из разрешённой сети. Если новая сессия не устанавливается, не продолжайте ужесточение политики. Проверьте адрес источника, IP-версию, интерфейс, профиль или зону, порядок правил и путь обработки. Успешно работающая старая сессия не является проверкой: она могла сохраниться благодаря состоянию существующего соединения.

Firewall сервера: default deny, порядок правил и политика доступа

Q: Нужно ли блокировать весь ICMPv6 на сервере?

Нет. Нельзя без разбора блокировать весь ICMPv6, поскольку от его типов зависят Neighbor Discovery и Path MTU Discovery. Политика должна разрешать необходимый служебный ICMPv6 в нужных направлениях и ограничивать необоснованные типы с учётом роли сервера. Правила IPv6 нужно проверять отдельно от IPv4.

Политика межсетевого экрана по принципу запрета по умолчанию начинается с перечня разрешённых потоков, а не с набора команд. Для каждого потока определяют инициатора, сервис, протокол, источник, назначение и направление; всё, что не описано обоснованным разрешением, блокируют. Входящий, исходящий и транзитный трафик проектируют отдельно, ответные пакеты разрешают с учётом состояния соединения, а IPv4 и IPv6 проверяют как самостоятельные пути доступа.

Что собрать до создания правил firewall

Default deny не означает «запретить всё и затем разбираться с отказами». Сначала нужно описать роль сервера: веб-узел, сервер базы данных, хост мониторинга, контроллер домена, промежуточный шлюз или иной компонент. От роли зависит, какие соединения сервер принимает, какие создаёт сам и пересылает ли он пакеты между сетями.

Минимальный реестр разрешённых потоков

Поле	Что зафиксировать	Пример
Направление	Входящий, исходящий или транзитный поток	Входящий TCP к веб-сервису
Инициатор	Кто начинает новое соединение	Пользовательский браузер, reverse proxy, администратор, агент мониторинга
Источник	IP-адрес, подсеть, группа адресов или интерфейс	Подсеть администраторов или адреса балансировщика
Назначение	Сервер, его интерфейс, подсеть либо внешний сервис	Публичный адрес веб-узла или имя/адрес API-зависимости
Протокол и порт	TCP, UDP, ICMP/ICMPv6 и нужный порт, если он применим	TCP к порту HTTPS; DNS-запросы к утверждённым резолверам
Обоснование и владелец	Зачем поток нужен, кто подтверждает его необходимость и срок пересмотра	«Доступ мониторинга, владелец: команда эксплуатации»
IPv4 и IPv6	Нужен ли доступ по каждому семейству адресов	Публичный HTTPS по IPv4 и IPv6; SSH — только из административных сетей обоих семейств

Правило фильтрации пакетов должно отражать этот поток: направление, протокол, адреса или группы источников и назначений, а для TCP и UDP — порты. В описании правила или отдельном реестре фиксируют сервис, владельца, основание и дату пересмотра. Это помогает отличить временное исключение от постоянной части политики.

Открыть TCP-порт для всех адресов и ограничить доступ к порту конкретными IP-адресами — разные решения. Первое публикует сервис для любого достижимого клиента; второе создаёт allowlist источников. Например, публичный веб-сервис может принимать HTTPS от всех, а SSH или RDP — только от сети VPN, bastion host либо выделенных административных адресов. Архитектуру VPN, bastion host и сегментацию рассматривает статья «Сегментация серверной сети: VPN, bastion host и защищённый административный доступ».

Что default deny означает для входящего, исходящего и транзитного трафика

Три независимых направления политики

Направление	Что считается новым потоком	Смысл default deny
Входящий	Удалённый узел начинает соединение с сервисом сервера	Разрешать только опубликованные сервисы и утверждённые источники; остальные новые подключения блокировать
Исходящий	Сам сервер начинает соединение с внешним узлом	Разрешать только подтверждённые зависимости, если для роли сервера требуется фильтрация исходящего трафика; запрет не является обязательным для каждого хоста
Транзитный	Пакет проходит через сервер между интерфейсами, но не предназначен локальному сервису	По умолчанию не пересылать трафик, если сервер не является маршрутизатором, VPN-шлюзом, NAT-узлом или firewall между сегментами

У обычного прикладного сервера транзитный трафик часто отсутствует, но это нужно подтвердить, а не предполагать. Если сервер должен маршрутизировать или NAT-трафик, для него составляют отдельную матрицу потоков: источник, сеть назначения, разрешённые протоколы и обратный путь. Разрешение локального входящего сервиса не должно автоматически становиться разрешением транзита.

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

Firewall — не единственный контроль

Firewall уменьшает доступную сетевую поверхность, но не подтверждает защищённость приложения и не заменяет обновления, аутентификацию, сегментацию, контроль привилегий и аудит. Связанный порядок мер описан в статье «Базовая защита сервера: как составить security baseline».

Stateful firewall и ответный трафик

Межсетевой экран с отслеживанием состояния сопоставляет пакеты с записями отслеживания соединений. В Netfilter для типовой stateful-политики используются состояния NEW, ESTABLISHED, RELATED, INVALID и UNTRACKED. Конкретные значения, их доступность и синтаксис проверки зависят от выбранного механизма и версии; при реализации сверяются с официальной документацией Netfilter и используемой утилиты.

Как состояния соединения применяют в политике

Состояние	Практический смысл	Решение в типовой политике
`NEW`	Пакет относится к попытке создать новый поток	Разрешать только там, где инициирование этого соединения обосновано: например, клиенту к опубликованному HTTPS или администратору к SSH
`ESTABLISHED`	Пакет относится к уже отслеживаемому соединению	Обычно разрешать как ответный трафик ранее допустимого потока
`RELATED`	Пакет относится к вспомогательному потоку, связанному с существующим соединением	Разрешать только после понимания, какие протоколы и функции сервиса действительно требуют такой связи
`INVALID`	Пакет не удалось корректно отнести к ожидаемому состоянию	Обычно не принимать как нормальный трафик; причину массовых совпадений исследовать до широких исключений
`UNTRACKED`	Поток исключён из отслеживания	Обрабатывать отдельными осознанными правилами, если такой режим вообще нужен

Разрешение ESTABLISHED,RELATED не открывает сервис всем источникам. ESTABLISHED позволяет пропускать последующие пакеты уже отслеживаемого соединения, а RELATED — предусмотренные политикой связанные потоки. Отдельное правило для NEW всё равно определяет, кому разрешено инициировать подключение. При этом запись connection tracking сама по себе не доказывает, что соединение было разрешено текущей версией политики: таблица состояний могла сохраниться после изменения правил. Поэтому не нужно создавать широкое правило вроде «разрешить любой входящий трафик с высоких портов» только ради ответов сервера.

Состояние — не доказательство легитимности приложения или пользователя. Оно описывает сетевой контекст пакета, а не заменяет TLS, аутентификацию или авторизацию. Кроме того, stateful-фильтрация потребляет ресурсы для ведения таблицы состояний; её возможности при объёмных атаках ограничены. Границы локальной фильтрации разобраны в статье «Защита сервера от DDoS: возможности firewall, фильтрация у провайдера и действия при атаке».

Почему порядок правил firewall меняет результат

Порядок обработки правил определяет, какое совпавшее правило межсетевого экрана повлияет на пакет. В простой последовательной модели раннее широкое разрешение может сделать поздний запрет недостижимым; ранний запрет — перекрыть позднее разрешение. Но нельзя переносить такую модель на любой инструмент без проверки его правил обработки.

Разные модели обработки правил требуют разной диагностики

Средство	На что смотреть при поиске перекрытия
iptables	Порядок правил в цепочке, переходы в пользовательские цепочки, возвраты и политика цепочки
nftables	Порядок правил в цепочках, вызовы и возвраты, тип базовой цепочки nftables, hook, приоритет и вердикты nftables
firewalld	Зоны, источники и интерфейсы, сервисы, rich rules, policies, а также различие runtime- и permanent-конфигурации
UFW	Направление правила, порядок сформированных правил и базовую политику; UFW управляет правилами Netfilter, а не образует отдельный сетевой стек
Microsoft Defender Firewall	Профиль сети, область действия правила, действие allow/block, параметры фильтров, локальную и доменную политику, правила с конфликтующей областью

В nftables пакет может обрабатываться несколькими базовыми цепочками, подключёнными к одному hook; значение имеют их приоритеты и итоговые вердикты. В Microsoft Defender Firewall итог зависит не от линейного списка, аналогичного одной цепочке iptables, а от применимых правил, профилей и правил разрешения конфликтов. У firewalld модель строится вокруг зон и политик. Официальные руководства nftables, iptables, firewalld, UFW и Microsoft Defender Firewall — обязательный источник для проверки этой семантики в конкретной версии.

Как найти правило, которое перекрывает другое

Метод подходит для анализа политики до её изменения и не зависит от синтаксиса конкретного firewall.

1
Опишите проверяемый поток
Зафиксируйте направление, IP-версии, интерфейс, протокол, адрес источника, адрес назначения, порт и состояние соединения. Ожидаемый результат — один конкретный поток, а не формулировка «не работает сеть».
2
Найдите все совпадающие правила
Ищите не только правило нужного порта: проверьте широкие правила по подсети, интерфейсу, зоне, профилю, приложению, состоянию соединения и правила блокировки. Если совпадает несколько правил, выпишите их действие и область.
3
Восстановите путь обработки
Для iptables проверьте цепочки, переходы и политику цепочки; для nftables — hook, приоритеты, базовые и обычные цепочки; для firewalld — зоны и политики; для Windows — активный профиль и источники политики. Ожидаемый результат — понятно, какое правило или итоговая политика принимает решение.
4
Проверьте счётчики и журналы, если они предусмотрены
Совпадение счётчика или запись журнала подтверждает, что поток дошёл до конкретного участка политики. Если подтверждения нет, повторно проверьте IP-версию, фактический адрес клиента, интерфейс и состояние соединения.
5
Исправьте наиболее узкое правило
Меняйте правило, которое действительно перекрывает поток, а не добавляйте широкое разрешение в конец набора. После изменения повторите проверку из того же разрешённого источника и убедитесь, что не появился доступ для неразрешённого источника.

DROP и REJECT: как выбрать действие

И DROP, и REJECT прекращают обработку нежелательного трафика, но делают это по-разному. DROP обычно молча отбрасывает пакет: клиент ждёт тайм-аут или повторяет попытку. REJECT возвращает отказ, например TCP reset для TCP либо ICMP-ответ для других применимых протоколов. Точный тип ответа и допустимость для конкретного протокола зависят от инструмента: их нужно сверять с официальной документацией используемого firewall.

Выбор между DROP и REJECT

Сценарий	Чаще подходит	Почему
Внутренний сервис, где важна быстрая и понятная диагностика отказа	`REJECT`	Клиент быстрее получает явный отказ, а не ждёт истечения тайм-аута
Нежелательные входящие попытки из недоверенной сети	`DROP` или `REJECT` после оценки риска	Выбор зависит от требований к диагностике, поведения клиентов и допустимости раскрывать факт фильтрации
Трафик, который не должен порождать дополнительный ответ	`DROP`	Не создаёт ответный пакет, но не является универсально «более безопасным» решением
Неверно сформированные или подозрительные пакеты	Обычно блокировка по политике конкретного механизма	Решение требует учёта протокола, журналирования и риска ложных срабатываний

Универсального правила «DROP всегда безопаснее REJECT» нет. REJECT может упростить эксплуатацию и сократить задержки для легитимного клиента; DROP может быть предпочтителен там, где ответ не нужен. В обоих случаях не стоит считать тип отказа защитой от сканирования или атак сам по себе.

Ограничение доступа по IP и политика IPv6

Чтобы ограничить доступ к сервису конкретными IP-адресами или сетями, правило должно одновременно описывать сервис и источник: например, «новые TCP-подключения к административному порту разрешены только из административной подсети». Если источников много и они регулярно меняются, их ведут как именованную группу, набор или объект политики, а не копируют десятки почти одинаковых правил. Владелец такого списка должен поддерживать его актуальность.

IPv4-allowlist не ограничивает IPv6 автоматически

IPv4 и IPv6 — отдельные пути доступа. Сервис, доступный по IPv6, может остаться опубликованным, если правило создано только для IPv4. В iptables традиционно используются раздельные конфигурации для IPv4 и IPv6; nftables может использовать семейство inet для общей логики, но адресные выражения всё равно должны учитывать оба семейства. UFW, firewalld и Microsoft Defender Firewall имеют собственные модели поддержки IPv6: перед применением проверьте по документации версии, распространяется ли правило на оба семейства и как задана область адресов.

Для IPv6 нельзя без разбора блокировать весь ICMPv6. Этот протокол нужен не только для диагностических сообщений: от его типов зависят механизмы Neighbor Discovery и Path MTU Discovery. Политика должна разрешать необходимый служебный ICMPv6 в нужных направлениях и ограничивать необоснованные типы с учётом роли сервера. Практическая реализация sets, IPv6 и диагностики приведена в статье «Настройка nftables: правила, sets, IPv6 и диагностика».

Журналирование и ограничение частоты — отдельные решения

Запрет входящих соединений не включает автоматически ни журналирование, ни ограничение частоты запросов. Логировать полезно события, которые помогают расследовать конкретный сценарий: новые подключения к административному сервису из неразрешённой сети, совпадение временного блокирующего правила, срабатывание правила для необычного протокола. Логирование каждого отброшенного пакета часто создаёт большой объём записей, скрывает важные события и само по себе может добавить нагрузку.

Ограничение частоты применяют к определённому событию: например, к новым соединениям на сервис, ICMP-сообщениям или событиям журналирования. Порог зависит от характера легитимного трафика и не должен подбираться наугад. Слишком низкий лимит создаст отказы для пользователей, мониторинга или proxy; слишком высокий может не дать ожидаемого эффекта. В nftables место правила, счётчики и limit влияют на результат; в Microsoft Defender Firewall параметры журналирования и профили также определяют, что попадёт в журнал. Возможности конкретного механизма сверяют с его официальной документацией.

Локальные журналы firewall полезны для первичной проверки правила, но не заменяют защищённый централизованный сбор, корреляцию и процесс реакции. Эти вопросы вынесены в статью «Централизованный сбор журналов безопасности: события, корреляция и оповещения».

Как изменить firewall и не потерять SSH, RDP или другой доступ

Удалённая смена политики может заблокировать администратора

Не включайте запрет входящего трафика, пока не определены текущий канал управления, его реальный адрес источника, нужная IP-версия и путь аварийного восстановления. Существующая SSH- или RDP-сессия иногда сохраняется из-за состояния соединения, но это не доказывает, что после изменения получится открыть новую сессию.

Безопасная последовательность изменения политики firewall

Последовательность применима к SSH, RDP и другому административному каналу. Она описывает порядок действий, а не синтаксис конкретной утилиты.

1
Зафиксируйте исходное состояние
Сохраните текущую конфигурацию firewall, активные правила, политики по направлениям, адреса интерфейсов и используемый путь управления. Подготовьте доступ к консоли, BMC, провайдерской консоли или иной согласованный аварийный путь. Ожидаемый результат — есть способ вернуть состояние, если сеть станет недоступной.
2
Определите точный административный поток
Укажите протокол, порт, реальные IPv4- и IPv6-адреса или подсети администратора, целевой интерфейс и необходимость VPN или bastion host. Не используйте «временно разрешить всем», если можно указать подтверждённый административный источник.
3
Сначала добавьте узкое разрешение управления
Добавьте правило для нового административного подключения до включения итогового запрета. Одновременно предусмотрите loopback и обработку уже установленных допустимых соединений в соответствии с моделью выбранного firewall. Ожидаемый результат — административный сервис доступен из разрешённого источника.
4
Проверьте новую сессию
Откройте вторую SSH- или RDP-сессию именно из разрешённой сети. Успешная старая сессия не считается проверкой. Если новое подключение не проходит, не продолжайте ужесточение: разберите адрес, IP-версию, профиль или зону, порядок правил и журнал.
5
Примените остальные разрешения и запрет
Добавьте опубликованные сервисы, необходимые исходящие зависимости и, если нужно, транзитные правила. Затем включите default deny в нужном направлении. Если инструмент поддерживает автоматический откат по таймеру, используйте его только с понятной процедурой подтверждения и временем, достаточным для проверки.
6
Проверьте разрешённые и запрещённые сценарии
Проверьте сервис из разрешённого источника, попытку из неразрешённого источника, IPv4 и IPv6, а также исходящие зависимости, если они ограничиваются. При отклонении вернитесь к сохранённой конфигурации или аварийному каналу, а затем исправьте узкое правило, вызвавшее отказ.
7
Закрепите и задокументируйте изменение
Убедитесь, что правила переживают перезагрузку в модели выбранного инструмента: runtime и постоянная конфигурация могут различаться. Обновите реестр потоков, владельцев, исключений и порядок отката.

Для Linux не следует одновременно строить независимую политику через UFW, firewalld, ручные правила iptables/nftables и другие менеджеры: итоговый набор может быть перезаписан или стать труднообъяснимым. UFW и firewalld — высокоуровневые средства управления политикой. nftables предоставляет собственную модель правил Netfilter, а команда iptables в зависимости от системы может использовать legacy-backend либо совместимый nft-backend. Перед изменениями определите активный backend и средство, которое владеет конфигурацией. Практические сценарии выбора и настройки собраны в статьях «Настройка iptables: открыть порт, ограничить доступ и сохранить правила», «UFW и firewalld: настройка firewall в Ubuntu и RHEL» и «Настройка nftables: правила, sets, IPv6 и диагностика».

В Windows правила оценивают в контексте активного профиля и применимых локальных или доменных политик. Для серверов с RDP дополнительно проверяют оба транспорта, фактические источники и IPv4/IPv6. Практическая работа с правилами и журналированием описана в статье «Windows Defender Firewall: входящие правила, PowerShell и журналирование», а ограничения RDP — в статье «Защита RDP на Windows Server: NLA, MFA, ограничения доступа и перенаправлений».

Зависимость от версии и реализации

Названия цепочек, зон и профилей, способ сохранения правил, доступные состояния connection tracking, типы REJECT и порядок обработки различаются между ОС, версиями ядра, firewall и утилитами управления. Семантику состояний, verdict, hooks, журналирования и limit проверяйте по официальному руководству nftables; особенности iptables и его расширений — в документации проекта Netfilter; зоны и policies — в документации firewalld; правила и поддержку IPv6 в UFW — в официальной странице руководства Ubuntu; приоритеты, профили и область правил Windows — в документации Microsoft Defender Firewall. Для установленной версии используйте соответствующую ей редакцию руководства. Проверяйте итоговую активную конфигурацию, а не только текст созданного правила.

Термины в статье

Allowlist: Allowlist — перечень разрешающих записей или правил: система допускает только те субъекты, объекты, действия или значения, которые им соответствуют.
Microsoft Defender Firewall: Microsoft Defender Firewall — встроенный в Windows межсетевой экран, фильтрующий входящие и исходящие соединения по правилам, профилям сети и параметрам трафика.
UFW: UFW — утилита упрощённого управления правилами межсетевого экрана в Linux, создающая правила Netfilter по командам высокого уровня.
firewalld: firewalld — служба управления межсетевым экраном в Linux, применяющая правила через зоны, сервисы и политики без прямого редактирования полного набора правил.
iptables: iptables — утилита Linux для управления правилами пакетной фильтрации Netfilter через таблицы, цепочки и цели; это не самостоятельный межсетевой экран.
nftables: nftables — подсистема Linux и интерфейс управления правилами Netfilter, использующие единый набор правил, выражения, множества и атомарное обновление конфигурации.
Базовая цепочка nftables: Базовая цепочка nftables — цепочка, привязанная к hook Netfilter и запускающая обработку пакетов на заданном этапе сетевого стека с указанным приоритетом.
Вердикт nftables: Вердикт nftables — управляющее значение, задающее решение по пакету или дальнейший ход выполнения правил в цепочках netfilter.
Запрет по умолчанию: Запрет по умолчанию — политика контроля доступа, при которой разрешаются только явно разрешённые правилами обращения или действия, а всё остальное блокируется.
Межсетевой экран: Межсетевой экран — средство контроля сетевого трафика, разрешающее или блокирующее его по правилам на границе или между сегментами сети.
Межсетевой экран с отслеживанием состояния: Межсетевой экран с отслеживанием состояния — межсетевой экран, который сопоставляет пакеты с состоянием отслеживаемых соединений и потоков и применяет правила с учётом их контекста.
Ограничение частоты запросов: Ограничение частоты запросов — механизм контроля нагрузки, ограничивающий число запросов от клиента или другого субъекта за заданный интервал.
Отслеживание соединений: Отслеживание соединений в Linux — механизм Netfilter, ведущий записи о потоках и их состояниях для фильтрации с учётом состояния, NAT и правил, зависящих от направления трафика.
Политика межсетевого экрана: Политика межсетевого экрана — набор правил обработки сетевого трафика, определяющий разрешённые и запрещённые взаимодействия между зонами, узлами, сервисами и интерфейсами.
Порядок обработки правил: Порядок обработки правил — механизм определения последовательности проверки правил политики, от которой зависит, какое совпавшее правило применит система безопасности.
Правило межсетевого экрана: Правило межсетевого экрана — элемент политики фильтрации, задающий условия сопоставления трафика и действие над пакетами или соединениями.
Состояние соединения: Состояние соединения — классификация пакета подсистемой отслеживания соединений: NEW, ESTABLISHED, RELATED, INVALID или UNTRACKED.
Фильтрация исходящего трафика: Фильтрация исходящего трафика — контроль соединений из защищаемой сети наружу, ограничивающий разрешённые назначения, протоколы, сервисы и источники исходящих пакетов.
Фильтрация пакетов: Фильтрация пакетов — способ контроля сетевого трафика по полям пакета и правилам, при необходимости дополненный отслеживанием состояния соединений.
Цепочка nftables: Цепочка nftables — упорядоченный контейнер правил обработки пакетов, запускаемый из точки перехвата сетевого стека (hook) или вызываемый из другой цепочки.