Nftables sets: динамические списки IP без сотен правил

Когда список разрешённых или заблокированных адресов растёт, классический firewall быстро превращается в длинную цепочку однотипных правил. Каждое изменение требует найти правильное место, аккуратно заменить конфигурацию и убедиться, что промежуточное состояние не открыло доступ. В nftables эту задачу решают sets: правило остаётся коротким, а изменяется отдельный набор данных.

Такой подход полезен для allowlist административных адресов, временных блокировок, сетей партнёров, исключений мониторинга и пар «адрес + порт». Но set — не просто список. У него есть тип, ограничения размера, режим хранения диапазонов, время жизни элементов и правила совместимости, от которых зависит безопасность production-конфигурации.

Что такое set в nftables

Set — объект таблицы nftables, который хранит множество однотипных значений: IPv4- или IPv6-адресов, портов, имён интерфейсов, меток либо составных ключей. Правило проверяет, входит ли значение пакета в набор, и выполняет действие только при совпадении.

Простейший именованный набор выглядит так:

table inet ks_filter {
    set admin_v4 {
        type ipv4_addr
        elements = { 198.51.100.10, 203.0.113.0/28 }
        flags interval
    }

    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        iifname "lo" accept
        ip saddr @admin_v4 tcp dport 22 accept
    }
}

В цепочке остаётся одно правило для SSH. Добавление ещё одного адреса меняет содержимое admin_v4, но не создаёт новое правило и не влияет на его позицию. Официальное руководство Netfilter отмечает, что именованные sets можно изменять в любое время, тогда как анонимные наборы привязаны к правилу и после создания не обновляются.

Внутри ядро выбирает подходящую структуру данных с учётом типа и флагов набора. Администратору не следует обещать фиксированную сложность поиска для любой конфигурации: interval, timeout, memory policy и составные ключи предъявляют разные требования. Практический выигрыш здесь прежде всего архитектурный — данные отделяются от логики обработки пакета.

Когда set лучше отдельных правил

Set уместен, если много элементов ведут к одному решению. Например, десятки офисных адресов должны получать доступ к SSH, сотни узлов мониторинга — к exporter-порту, а известные источники сканирования — блокироваться на входе. В каждом случае условие различается только значением ключа.

Отдельные правила оправданы, когда действия действительно разные: один адрес разрешён только к SSH, второй — к PostgreSQL, третий должен перейти в отдельную цепочку с логированием. Не нужно объединять сущности лишь ради короткого файла. Set хорош там, где множество значений имеет одинаковый смысл и одинаковый жизненный цикл.

Полезный критерий: может ли владелец списка обновить его, не понимая порядок всех firewall-правил? Если да, отделение данных снижает операционный риск. Команда автоматизации управляет элементами, а базовый ruleset остаётся под контролем инженера безопасности.

Sets дополняют базовый firewall, но не заменяют его проектирование. Перед сложной автоматизацией стоит проверить минимальные правила, порядок обработки и путь аварийного доступа; этот фундамент подробно разобран в материале KingServers о минимальном firewall на VPS.

Именованные и анонимные наборы

Анонимный набор записывают прямо в выражении:

tcp dport { 22, 80, 443 } accept

Он удобен для небольшого неизменного перечня. У него нет имени, он существует вместе с правилом и не предназначен для последующего add element или delete element. Чтобы изменить такой список, требуется заменить правило.

Именованный set объявляют внутри таблицы и используют через префикс @:

set public_services {
    type inet_service
    elements = { 80, 443 }
}

tcp dport @public_services accept

Выбор зависит не от количества элементов, а от жизненного цикла. Даже два адреса лучше хранить в именованном set, если их меняет CI/CD, система реагирования на инциденты или дежурный инженер. И наоборот, три постоянных публичных порта нормально оставить анонимным набором.

Название должно описывать смысл: admin_v4, partner_networks_v4, temporary_block_v6. Имена вроде set1 или ips не объясняют, кто владелец данных, почему элемент добавлен и можно ли его удалить.

Типы, семейство inet и IPv4/IPv6

Ключ type задаёт базовый тип элементов. Для адресов применяются ipv4_addr и ipv6_addr, для TCP/UDP-портов — inet_service, для имён интерфейсов — ifname. Современный синтаксис также поддерживает typeof, позволяя вывести тип из выражения, например typeof ip saddr.

Таблица семейства inet обслуживает правила IPv4 и IPv6, но не превращает два семейства адресов в один тип. Практичная конфигурация содержит два набора и два явных выражения:

table inet ks_filter {
    set admin_v4 { type ipv4_addr; }
    set admin_v6 { type ipv6_addr; }

    chain input {
        type filter hook input priority filter; policy drop;
        ip saddr @admin_v4 tcp dport 22 accept
        ip6 saddr @admin_v6 tcp dport 22 accept
    }
}

Не стоит хранить IPv4-mapped IPv6 addresses как универсальный обходной путь: представление адреса должно соответствовать выражению, которое извлекает поле из пакета. Явное разделение также упрощает аудит — отсутствие IPv6-элементов сразу заметно.

Для production полезно закрепить минимально поддерживаемые версии ядра и nft. Возможности развиваются отдельно в userspace и ядре; успешный разбор конфигурации на ноутбуке ещё не доказывает, что старое ядро сервера примет все выражения. На 20 августа 2026 года страница релизов Netfilter указывает nftables 1.1.6 как последний опубликованный релиз, однако дистрибутив может поставлять другую поддерживаемую версию.

Списки адресов и сетевые диапазоны

Чтобы set принимал CIDR и диапазоны, добавляют flags interval. Это подходит для офисных сетей, адресных пулов партнёра и агрегированных блок-листов:

set partner_v4 {
    type ipv4_addr
    flags interval
    auto-merge
    elements = {
        192.0.2.0/27,
        198.51.100.64-198.51.100.79
    }
}

auto-merge объединяет соседние и перекрывающиеся интервалы там, где это возможно. Без него загрузка пересекающихся диапазонов может завершиться ошибкой conflicting intervals specified. Это не повод автоматически включать агрегацию везде: при аудите иногда важна исходная граница каждого диапазона. Тогда лучше нормализовать список до генерации ruleset и отклонять пересечения в pipeline.

Для обычного списка одиночных адресов interval не требуется. Не добавляйте флаги «на будущее»: они влияют на доступные реализации и совместимость функций. Особенно важно, что текущая официальная man page указывает несовместимость interval с dynamic, то есть один set не следует одновременно использовать для диапазонов и добавления элементов из packet path.

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

Динамическое добавление и удаление элементов

Именованный set можно менять командами управления без перезагрузки всей таблицы:

nft add element inet ks_filter admin_v4 { 198.51.100.25 }
nft delete element inet ks_filter admin_v4 { 198.51.100.25 }
nft get element inet ks_filter admin_v4 { 198.51.100.25 }
nft list set inet ks_filter admin_v4

get element удобен для проверки членства, особенно когда set большой или содержит интервалы. Скрипт должен учитывать exit status, а не искать адрес в отформатированном текстовом выводе.

Для массового изменения лучше передать несколько команд одним файлом или через stdin. Так nftables собирает одну транзакцию: если команда в пакете некорректна, текущий ruleset не должен оказаться в наполовину обновлённом состоянии.

delete element inet ks_filter admin_v4 { 198.51.100.25 }
add element inet ks_filter admin_v4 { 203.0.113.25, 203.0.113.26 }

Операции add и create различаются поведением при существующем объекте. Для идемпотентной автоматизации заранее определите политику: повторное добавление допустимо, должно считаться ошибкой или сначала требуется получить текущее состояние. Не прячьте все ошибки через || true, иначе pipeline пропустит неверную таблицу, исчерпанный размер или несовместимый тип.

Timeout и временные блокировки

Set с flags timeout автоматически удаляет элементы после истечения срока. Можно задать timeout по умолчанию для набора и переопределить его у конкретного элемента:

set temporary_block_v4 {
    type ipv4_addr
    flags timeout
    timeout 30m
    gc-interval 1m
    size 65536
}

nft add element inet ks_filter temporary_block_v4 \
  '{ 198.51.100.44 timeout 10m, 203.0.113.77 timeout 2h }'

В выводе nft list set атрибут timeout означает установленный срок, а expires — оставшееся время. Для ручного элемента обновление времени обычно выполняют удалением и повторным добавлением. При обновлении из packet path семантика add и update различается: update освежает timeout при повторном совпадении, add не делает этого.

gc-interval определяет период уборки истёкших элементов, а не их фактический срок. Слишком редкая сборка мусора способна временно удерживать истёкшие записи в учёте размера; слишком частая добавляет работу CPU. Выбирайте интервал по темпу изменений и наблюдайте фактический размер, не копируйте случайное значение.

Временный блок-лист должен иметь верхнюю границу size. Иначе ошибка логики или поток уникальных источников может превратить защитный механизм в потребителя памяти. Timeout также не делает адрес надёжной идентичностью: за NAT могут находиться разные пользователи, а атакующий может менять источники.

Обновление set из packet path

Nftables умеет добавлять ключ в динамический set непосредственно при прохождении пакета. Это основа per-source rate limit и временных реакций на превышение порога. Официальная man page требует для таких наборов size и timeout, чтобы число элементов не росло бесконечно.

Упрощённый учебный пример:

set ssh_flood_v4 {
    type ipv4_addr
    flags dynamic
    timeout 1m
    size 65536
}

chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    tcp dport 22 ct state new \
        update @ssh_flood_v4 { ip saddr limit rate 6/minute } accept
}

Этот фрагмент нельзя вставлять в production вслепую: окончательная логика зависит от порядка правил, ожидаемого числа новых соединений, NAT, monitoring probes и пути аварийного доступа. Сначала проверьте модель трафика, затем протестируйте в отдельном namespace или на canary-сервере.

Не смешивайте наборы разного назначения. Set, который хранит состояние rate limit, не должен одновременно быть ручным блок-листом SOC. Разные владельцы, timeout и процедуры очистки требуют разных объектов, даже если ключ у них одинаковый.

Составные ключи: адрес и порт

Concatenation соединяет несколько селекторов в один ключ через точку. Например, set может разрешать конкретному адресу только конкретный порт:

set partner_services_v4 {
    type ipv4_addr . inet_service
    elements = {
        198.51.100.10 . 443,
        203.0.113.20 . 8443
    }
}

ip saddr . tcp dport @partner_services_v4 accept

Один lookup проверяет пару целиком. Это точнее, чем два независимых набора partner_ips и partner_ports: независимые проверки создали бы декартово произведение и случайно разрешили каждому партнёру все порты.

Составной ключ может включать адрес источника, адрес назначения, протокол, порт или интерфейс, если типы поддерживаются. Но читаемость быстро падает. Для ключа из трёх-четырёх полей добавьте комментарий к set и тесты с положительными и отрицательными пакетами.

Интервалы в concatenations зависят от возможностей ядра и userspace. Официальная документация отмечает, что CIDR в concatenations требует как минимум Linux 5.6 и nftables 0.9.4. Для старых поддерживаемых систем лучше проверить совместимость в CI на том же поколении ядра, а не полагаться на синтаксическую проверку новой рабочей станции.

Maps и verdict maps

Set отвечает на вопрос «есть ли ключ?», map возвращает значение, а verdict map — решение nftables. Это позволяет заменить несколько почти одинаковых правил одним lookup:

map partner_policy_v4 {
    type ipv4_addr . inet_service : verdict
    elements = {
        198.51.100.10 . 443 : accept,
        203.0.113.20 . 22 : jump partner_ssh_audit
    }
}

ip saddr . tcp dport vmap @partner_policy_v4

Verdict map полезна, когда ключи ведут к разным цепочкам или решениям. Если результат у всех одинаковый, обычный set проще и понятнее. Не превращайте policy в трудночитаемую таблицу переходов только ради минимального числа строк.

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

При миграции с ipset утилита ipset-translate может преобразовать типы в nftables sets, часто используя concatenations. Но перевод — отправная точка, а не готовая архитектура. В nftables стоит пересмотреть прежние пары iptables + ipset и определить, где map или verdict map выражает намерение яснее.

Атомарные обновления без окна риска

Сценарий из последовательности отдельных shell-команд способен оставить firewall в промежуточном состоянии, если процесс завершится между удалением старых и добавлением новых элементов. Для полного ruleset используйте файл и транзакционную загрузку:

nft -c -f /etc/nftables.conf
nft -f /etc/nftables.conf

-c проверяет команды без применения. Затем -f передаёт пакет изменений ядру как одну транзакцию; официальная документация описывает замену без момента, когда активна только часть нового файла.

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

Для обновления только элементов сформируйте небольшой транзакционный файл. Не выполняйте flush set, а затем длительно добавляйте элементы отдельными процессами: между командами набор будет пуст. Если нужно полностью заменить большой список, подготовьте все команды заранее и примените их одной операцией.

Автоматизация из файла и CI/CD

Удобная схема разделяет стабильную логику и генерируемые данные. Основной /etc/nftables.conf подключает контролируемые файлы, а pipeline создаёт только фрагменты sets. Перед установкой временный файл проходит валидацию, diff, проверку числа элементов и тест на запрещённые сети.

Минимальный pipeline включает:

1. получение данных из доверенного источника;
2. нормализацию IPv4/IPv6 и удаление точных дублей;
3. проверку верхнего лимита и слишком широких CIDR;
4. генерацию нового файла без изменения активного;
5. nft -c -f на целевой версии;
6. просмотр diff и применение одной транзакцией;
7. функциональный probe и автоматический rollback при сбое.

Не подставляйте необработанный текст в shell-команду. Используйте строгий парсер IP/CIDR и генерируйте nft-синтаксис из валидированной структуры. JSON-вывод nft -j удобен для машинного чтения состояния; текстовый вывод ориентирован на человека и может изменять форматирование.

Секреты и персональные адреса не должны попадать в общедоступный репозиторий. Если allowlist содержит домашние IP сотрудников, ограничьте доступ к артефактам и журналам pipeline, установите срок пересмотра и храните обоснование отдельно от публичной документации.

Наблюдаемость и аудит изменений

Команда nft monitor подписывается на события ruleset. Фильтры позволяют следить за новыми и удалёнными правилами, sets и elements, а -j выдаёт JSON для обработки:

nft monitor
nft -j monitor ruleset
nft list set inet ks_filter temporary_block_v4

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

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

Для общего подхода к метрикам, логам и алертам пригодится руководство KingServers Observability vs Monitoring. События nftables стоит связывать с журналами SSH, reverse proxy и IDS, но автоматическая блокировка должна иметь ограниченный timeout и контролируемый rollback.

Безопасное тестирование и откат

Проверяйте firewall на уровне, соответствующем риску. Синтаксический nft -c ловит неизвестные объекты и несовместимые выражения, но не доказывает доступность сервиса. Network namespace или тестовая VM позволяют прогнать положительные и отрицательные сценарии без воздействия на production.

Минимальный набор тестов для allowlist:

• разрешённый IPv4 действительно проходит к нужному порту;
• соседний адрес той же сети блокируется, если не включён в CIDR;
• IPv6 обрабатывается отдельным ожидаемым правилом;
• established-соединения не разрываются неожиданно;
• удаление элемента закрывает новый доступ;
• timeout удаляет временную запись;
• после перезагрузки загружается та же политика.

Rollback должен быть подготовлен до изменения. Сохраните проверенный файл, команду возврата и способ выполнить её не через канал, который firewall может закрыть. Для удалённого сервера полезен таймер: изменение автоматически отменяется, если оператор не подтвердил успешный probe.

Не используйте flush ruleset как универсальный шаг восстановления: официальная man page предупреждает, что он удаляет все таблицы и оставляет систему без packet filtering. Возвращайте известный хороший ruleset транзакционно.

Ограничения и типичные ошибки

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

Вторая — не ограничивать динамический набор. Для packet-path updates обязательны разумные size и timeout; дополнительно нужен алерт до достижения лимита. Защитный механизм не должен исчерпывать память под управлением внешнего трафика.

Третья — объединять IPv4 и IPv6 мысленно, но настроить только первое семейство. Таблица inet не создаёт второе правило автоматически. Проверяйте оба пути или явно документируйте, что IPv6 отключён на всём сетевом контуре.

Четвёртая — использовать два независимых sets там, где политика требует конкретной пары. Для «партнёр A → порт X» нужен concatenation; иначе комбинации расширят доступ.

Пятая — обновлять список через flush и цикл команд. При ошибке или задержке set остаётся пустым либо неполным. Генерируйте транзакцию целиком.

Шестая — путать локальную блокировку с DDoS-защитой. Nftables может отфильтровать пакеты, дошедшие до сервера, но не вернёт уже занятую полосу канала. Объёмные атаки требуют мер выше по сети и координации с провайдером.

Практический шаблон для production

Ниже — каркас, который разделяет постоянный административный доступ и временные блокировки. Адреса примеров принадлежат документационным диапазонам и должны быть заменены вашей политикой.

table inet ks_filter {
    set admin_v4 {
        type ipv4_addr
        flags interval
        elements = { 198.51.100.0/28 }
    }

    set admin_v6 {
        type ipv6_addr
        flags interval
        elements = { 2001:db8:100::/56 }
    }

    set temporary_block_v4 {
        type ipv4_addr
        flags timeout
        timeout 30m
        gc-interval 1m
        size 65536
    }

    chain input {
        type filter hook input priority filter; policy drop;
        iifname "lo" accept
        ct state invalid drop
        ct state established,related accept

        ip saddr @temporary_block_v4 counter drop
        ip saddr @admin_v4 tcp dport 22 accept
        ip6 saddr @admin_v6 tcp dport 22 accept

        tcp dport { 80, 443 } accept
        ip protocol icmp accept
        ip6 nexthdr icmpv6 accept
    }
}

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

Порядок тоже важен. Established traffic принимается до проверки новых соединений, временный блок-лист расположен до публичных сервисов, а административный доступ ограничен одновременно адресом и портом. В вашей системе могут потребоваться DHCP, VPN, контейнерные цепочки или forwarding — добавляйте их из реальной карты потоков.

Чек-лист перед внедрением

Перед изменением production ответьте «да» на следующие вопросы:

• определены владелец, назначение и срок пересмотра каждого set;
• IPv4 и IPv6 разобраны отдельно;
• для диапазонов осознанно выбран interval, пересечения проверены;
• динамические наборы имеют size, timeout и мониторинг;
• составные разрешения представлены одним concatenated key;
• источник внешнего feed аутентифицирован и валидируется;
• изменения формируются одной транзакцией;
• nft -c -f выполняется на совместимой версии;
• есть тест разрешённого и запрещённого трафика;
• подготовлен независимый аварийный доступ и rollback;
• события и ошибки обновления попадают в аудит;
• локальная фильтрация не выдаётся за защиту канала от DDoS.

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

Как выбрать конструкцию под задачу

Для постоянного небольшого списка с одним действием используйте именованный set. Для нескольких неизменных портов внутри одного правила достаточно анонимного набора. Для CIDR и диапазонов нужен set с interval; для временных элементов — отдельный set с timeout; для обновления из packet path — dynamic, ограничение размера и время жизни.

Если решение зависит от пары полей, выбирайте concatenation. Если ключ должен вернуть значение или verdict, переходите к map либо verdict map. Такой порядок сохраняет простоту: более мощная конструкция появляется только тогда, когда обычный set уже не выражает политику без расширения доступа или дублирования правил.

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

Источники и версия материала

Материал проверен 20 августа 2026 года по официальной man page nftables, документации Netfilter о sets, concatenations, element timeouts, packet-path updates, atomic rule replacement, monitoring ruleset updates, migration from ipset и официальной странице релизов.

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

Итог: отделите политику от списка

Главная идея nftables sets проста: правило описывает решение, set хранит изменяемые данные. Благодаря этому allowlist из сотен адресов остаётся одним понятным условием, временная блокировка получает срок жизни, а разрешение «адрес + порт» выражается точной парой вместо двух независимых списков.

Начните с одного набора, который сегодня обновляется вручную чаще остальных. Опишите его тип и владельца, добавьте валидацию, применяйте изменения транзакционно и наблюдайте ошибки. Лишь затем подключайте внешние feeds, packet-path updates и verdict maps.

Для production-инфраструктуры важен не минимальный объём конфигурации, а предсказуемое изменение без потери доступа. Хорошо спроектированный set делает именно это: сокращает поверхность ручной ошибки, не скрывая смысл политики.