nftables у Linux: посібник з налаштування брандмауера, міграції з iptables та захисту серверів

Чому nftables — це новий стандарт брандмауера Linux

Якщо ви досі використовуєте iptables для захисту своїх Linux-серверів — час це визнати: інструмент офіційно застарілий. Так, ви правильно прочитали. Починаючи з 2022 року, всі основні дистрибутиви — Ubuntu 22.04+, Debian 11+, RHEL 9+, Fedora 35+ — перейшли на nftables як стандартну підсистему фільтрування мережевого трафіку. А та команда iptables, яку ви, ймовірно, досі запускаєте? Насправді це оболонка iptables-nft, що тихенько транслює старий синтаксис у правила nftables за лаштунками.

nftables — це не просто «нова версія iptables». Це принципово інша архітектура, яку команда Netfilter розробила для вирішення фундаментальних обмежень попередника. Замість чотирьох окремих утиліт (iptables, ip6tables, arptables, ebtables) ви отримуєте єдиний інструмент nft. Один інструмент — усі протоколи — один фреймворк.

Ключові переваги nftables над iptables

• Єдиний синтаксис — одна утиліта nft замість чотирьох різних інструментів для IPv4, IPv6, ARP та Ethernet
• Вища продуктивність — вбудовані множини (sets) та карти (maps) забезпечують пошук за O(1) замість лінійного O(n) проходження правил
• Атомарні оновлення — правила застосовуються через транзакції Netlink, що виключає race conditions під час перезавантаження конфігурації
• Відсутність предвизначених таблиць і ланцюжків — чиста архітектура, де ви створюєте лише те, що справді потрібно
• Вбудоване трасування — дебаг правил без сторонніх утиліт (і це, чесно кажучи, величезна перевага)
• Декларативний синтаксис — конфігурація читається як опис бажаного стану, а не як послідовність окремих команд

Архітектура nftables: таблиці, ланцюжки та правила

Перш ніж переходити до практики, розберемо структуру nftables. Повірте, витратити кілька хвилин на розуміння ієрархії — це інвестиція, яка окупиться, коли почнете писати власні правила.

Таблиці (Tables)

Таблиця — це простір імен верхнього рівня, який містить ланцюжки, правила, множини та інші об'єкти. Кожна таблиця має сімейство адрес (address family), що визначає, які типи пакетів вона обробляє:

• ip — лише IPv4 (за замовчуванням)
• ip6 — лише IPv6
• inet — IPv4 та IPv6 одночасно (рекомендований вибір для більшості випадків)
• arp — пакети ARP
• bridge — пакети, що проходять через мережевий міст
• netdev — вхідні пакети на рівні мережевого пристрою (найраніший етап обробки)

У переважній більшості сценаріїв вам знадобиться inet — він покриває і IPv4, і IPv6 в одній таблиці.

Ланцюжки (Chains)

На відміну від iptables, nftables не має вбудованих ланцюжків. Це означає, що пакети взагалі не обробляються, доки ви явно не створите ланцюжок і не прив'яжете його до певного хука (hook) стека Netfilter.

Існують два типи ланцюжків:

• Базові ланцюжки (Base chains) — точки входу для пакетів з мережевого стека, де вказується тип, хук та пріоритет
• Звичайні ланцюжки (Regular chains) — використовуються як цілі для переходу (jump), що допомагає організувати правила логічно

Основні хуки для сімейства inet:

• prerouting — до прийняття рішення про маршрутизацію
• input — вхідні пакети, призначені для локальної системи
• forward — пакети, що проходять через систему транзитом
• output — вихідні пакети від локальної системи
• postrouting — після прийняття рішення про маршрутизацію

Правила (Rules)

Правила складаються з виразів для зіставлення (match expressions) та дій (actions). І ось тут одна з приємних відмінностей від iptables — в nftables одне правило може містити кілька дій одночасно. Наприклад, можна і залогувати пакет, і відкинути його — одним рядком.

Встановлення та базове налаштування nftables

Отже, давайте перейдемо до справи. Встановлення nftables — процес досить тривіальний на будь-якому сучасному дистрибутиві.

Debian / Ubuntu

sudo apt update
sudo apt install -y nftables
sudo systemctl enable --now nftables

RHEL / CentOS / AlmaLinux / Fedora

sudo dnf install -y nftables
sudo systemctl enable --now nftables

Перевірка статусу

# Версія nftables
nft --version

# Поточний набір правил
sudo nft list ruleset

# Статус сервісу
sudo systemctl status nftables

За замовчуванням конфігурація nftables живе у файлі /etc/nftables.conf. Саме його завантажує сервіс при старті.

Побудова захисної конфігурації брандмауера крок за кроком

Ну що ж, тепер найцікавіше — практика. Ми побудуємо повноцінну конфігурацію брандмауера для продакшн-сервера, і я розберу кожен елемент окремо.

Базова конфігурація з політикою заборони за замовчуванням

Золоте правило мережевої безпеки: заборонити все, що явно не дозволено. Просто і ефективно. Ось мінімальна безпечна конфігурація:

#!/usr/sbin/nft -f

# Очищення існуючих правил
flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;

        # Дозвіл трафіку на loopback-інтерфейсі
        iif "lo" accept

        # Відстеження стану з'єднань
        ct state established,related accept

        # Відкидання недійсних з'єднань
        ct state invalid drop

        # Дозвіл ICMP (ping) з обмеженням швидкості
        ip protocol icmp icmp type echo-request \
            limit rate 5/second accept
        ip6 nexthdr icmpv6 icmpv6 type echo-request \
            limit rate 5/second accept

        # ICMPv6 — необхідні типи для роботи IPv6
        ip6 nexthdr icmpv6 icmpv6 type {
            nd-neighbor-solicit,
            nd-neighbor-advert,
            nd-router-solicit,
            nd-router-advert
        } accept

        # SSH (порт 22)
        tcp dport 22 accept

        # HTTP та HTTPS
        tcp dport { 80, 443 } accept
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

Зверніть увагу на policy drop; у ланцюжку input — це і є та сама «заборона за замовчуванням». Все, що не потрапляє під жодне правило accept, просто тихо відкидається.

Перевірка та застосування конфігурації

# Перевірка синтаксису без застосування
sudo nft -c -f /etc/nftables.conf

# Застосування конфігурації
sudo nft -f /etc/nftables.conf

# Перегляд активних правил
sudo nft list ruleset

Увага: завжди перевіряйте конфігурацію командою nft -c перед застосуванням, особливо при віддаленому доступі. Я знаю випадки, коли адміністратори заливали неперевірену конфігурацію на віддалений сервер і миттєво втрачали SSH-з'єднання. Доводилося їхати в дата-центр або звертатися до хостера за KVM-доступом.

Захист SSH за допомогою nftables: обмеження швидкості та автоматичне блокування

SSH — головна точка входу на будь-який Linux-сервер, і, відповідно, основна ціль атак методом грубої сили. Хороша новина: замість встановлення Fail2Ban можна реалізувати захист безпосередньо в nftables, на рівні ядра. Швидше, легше, без зайвих демонів.

Метод 1: обмеження швидкості підключень (Rate Limiting)

Найпростіший підхід — обмежити кількість нових SSH-з'єднань з однієї IP-адреси:

table inet filter {
    set ssh_limit {
        type ipv4_addr
        flags dynamic,timeout
        timeout 1m
    }

    chain input {
        type filter hook input priority 0; policy drop;

        # Базові правила
        iif "lo" accept
        ct state established,related accept
        ct state invalid drop

        # SSH з обмеженням: 3 з'єднання на хвилину з кожної IP
        tcp dport 22 ct state new \
            add @ssh_limit { ip saddr limit rate 3/minute burst 5 packets } \
            accept

        # Інші сервіси
        tcp dport { 80, 443 } accept
    }
}

Як це працює: для кожного нового SSH-з'єднання nftables додає IP-адресу джерела до динамічної множини ssh_limit з індивідуальним лічильником. Якщо з однієї адреси надходить більше 3 з'єднань за хвилину (з буфером у 5 пакетів), подальші з'єднання просто ігноруються. Запис видаляється автоматично через 60 секунд неактивності.

Метод 2: автоматичне блокування (Dynamic Blacklisting)

Більш агресивний варіант — автоматичний бан IP-адрес, що перевищують ліміт. По суті, це аналог Fail2Ban, але реалізований на рівні ядра, без жодних додаткових демонів чи парсерів логів:

table inet filter {
    set ssh_banned {
        type ipv4_addr
        flags timeout
        timeout 2h
    }

    chain input {
        type filter hook input priority 0; policy drop;

        iif "lo" accept
        ct state established,related accept

        # Негайне відкидання вже заблокованих IP
        ip saddr @ssh_banned drop

        # Виявлення brute force та автоматичне блокування
        tcp dport 22 ct state new \
            limit rate over 10/minute \
            add @ssh_banned { ip saddr timeout 2h } \
            counter drop

        # Легітимний SSH-трафік
        tcp dport 22 ct state new accept

        tcp dport { 80, 443 } accept
    }
}

Ручне керування заблокованими адресами:

# Перегляд заблокованих IP
sudo nft list set inet filter ssh_banned

# Ручне додавання IP на 24 години
sudo nft add element inet filter ssh_banned { 203.0.113.5 timeout 24h }

# Розблокування IP
sudo nft delete element inet filter ssh_banned { 203.0.113.5 }

Чесно кажучи, для більшості серверів саме цей метод є оптимальним вибором — він працює надійно і не вимагає жодного додаткового софту.

Метод 3: обмеження SSH до довірених мереж

Для максимальної безпеки можна обмежити SSH-доступ виключно визначеними мережами управління. Якщо ваша інфраструктура це дозволяє — рекомендую саме цей підхід:

table inet filter {
    set management_nets {
        type ipv4_addr
        flags interval
        elements = { 10.0.10.0/24, 192.168.100.0/24 }
    }

    chain input {
        type filter hook input priority 0; policy drop;

        iif "lo" accept
        ct state established,related accept
        ct state invalid drop

        # SSH — лише з мереж управління, з обмеженням швидкості
        tcp dport 22 ip saddr @management_nets \
            ct state new limit rate 10/minute accept

        tcp dport { 80, 443 } accept
    }
}

Робота з множинами та картами: потужність nftables

Множини (sets) та карти (maps) — це, мабуть, найкрутіша фіча nftables. Вони дозволяють замінити десятки окремих правил єдиною конструкцією з пошуком за хеш-таблицею. Результат? Менше правил, швидша обробка, простіша підтримка.

Іменовані множини (Named Sets)

# Множина дозволених IP для адміністративного доступу
set admin_ips {
    type ipv4_addr
    flags interval
    elements = {
        10.0.1.0/24,
        172.16.0.50,
        192.168.1.100
    }
}

# Множина заблокованих IP
set blocklist {
    type ipv4_addr
    flags interval,timeout
    auto-merge
}

# Множина дозволених портів
set allowed_tcp_ports {
    type inet_service
    elements = { 22, 80, 443, 8080 }
}

Verdict Maps — маршрутизація рішень

Verdict maps дозволяють зіставити значення з конкретними діями, замінюючи ланцюжки if-else. Це елегантно і ефективно:

table inet filter {
    map port_policy {
        type inet_service : verdict
        elements = {
            22 : jump ssh_chain,
            80 : accept,
            443 : accept,
            8080 : jump app_chain
        }
    }

    chain input {
        type filter hook input priority 0; policy drop;

        iif "lo" accept
        ct state established,related accept

        # Один рядок замість кількох правил
        tcp dport vmap @port_policy
    }

    chain ssh_chain {
        ct state new limit rate 3/minute accept
    }

    chain app_chain {
        ip saddr 10.0.0.0/8 accept
    }
}

Один рядок tcp dport vmap @port_policy замінює цілу купу окремих правил. Красиво, чи не так?

Конкатенації (Concatenations)

Конкатенації дозволяють зіставляти кілька полів одночасно — наприклад, IP-адресу та порт в одному виразі:

set allowed_access {
    type ipv4_addr . inet_service
    elements = {
        10.0.1.50 . 22,
        10.0.1.100 . 3306,
        10.0.2.0/24 . 443
    }
}

chain input {
    type filter hook input priority 0; policy drop;
    ip saddr . tcp dport @allowed_access accept
}

Це особливо зручно, коли різним IP потрібен доступ до різних портів — замість комбінаторного вибуху правил ви маєте одну компактну множину.

Міграція з iptables на nftables: покроковий план

Якщо ваша інфраструктура досі працює на класичних правилах iptables — не хвилюйтесь, міграція не така страшна, як може здатися. Ось практичний план дій.

Крок 1: аудит поточних правил

# Експорт поточних правил iptables
sudo iptables-save > /root/iptables-backup-$(date +%Y%m%d).txt
sudo ip6tables-save > /root/ip6tables-backup-$(date +%Y%m%d).txt

# Аналіз кількості правил
sudo iptables -L -n --line-numbers | wc -l

Перш за все — збережіть бекап. Завжди. Навіть якщо ви впевнені на 100%.

Крок 2: автоматична конвертація правил

Утиліта iptables-translate конвертує синтаксис iptables у nftables:

# Конвертація окремого правила
iptables-translate -A INPUT -p tcp --dport 22 -j ACCEPT
# Результат: nft add rule ip filter INPUT tcp dport 22 counter accept

# Конвертація повного набору правил
iptables-restore-translate -f /root/iptables-backup.txt > /root/nftables-converted.nft

Важливо: автоматична конвертація охоплює не всі випадки. Обов'язково перевіряйте кожне правило вручну, особливо якщо використовуєте модулі -m string, -m owner або складні ланцюжки NAT. Конвертор робить хорошу роботу з простими правилами, але на складних конструкціях може спотикатися.

Крок 3: тестування на стейджинг-середовищі

# Завантаження конвертованих правил
sudo nft -c -f /root/nftables-converted.nft

# Тестове застосування з автоматичним відкатом
# (використовуйте at/cron для відновлення через 5 хвилин)
echo "sudo nft -f /root/iptables-fallback.nft" | at now + 5 minutes
sudo nft -f /root/nftables-converted.nft

# Перевірка з'єднань
ss -tlnp
curl -I http://localhost

Трюк з at now + 5 minutes — це класична страховка. Якщо нова конфігурація заблокує вам доступ, через 5 хвилин автоматично завантажиться стара. Спить спокійніше після цього, правда?

Крок 4: видалення залишків iptables

# Переконайтесь, що iptables-nft (не iptables-legacy) є активним бекендом
sudo update-alternatives --display iptables

# Перевірте, що немає змішування бекендів
sudo iptables -V  # має показати nf_tables

Критичне правило: ніколи не змішуйте iptables-legacy та iptables-nft одночасно. Це призводить до абсолютно непередбачуваної поведінки фільтрації, і дебажити такі проблеми — справжній кошмар.

nftables та Docker: як уникнути типових пасток безпеки

Docker — одна з найпоширеніших платформ для розгортання сервісів, і його взаємодія з брандмауером потребує особливої уваги. Ця тема, чесно кажучи, коштувала мені кількох безсонних ночей, коли я вперше зіткнувся з нею на продакшні.

Проблема: Docker обходить ваш брандмауер

Багато адміністраторів стикаються з неприємним сюрпризом: після запуску контейнера з прокинутим портом цей порт стає доступним з інтернету. Навіть якщо правила nftables або UFW мали б його блокувати.

Чому так? Docker вставляє NAT-правила, які обробляються до ваших правил фільтрації. Ваш ретельно налаштований брандмауер просто не бачить цей трафік.

Рішення 1: нативний бекенд nftables у Docker 29+

Docker 29.0.0 додав експериментальну підтримку нативного бекенду nftables. Для активації додайте у файл /etc/docker/daemon.json:

{
    "firewall-backend": "nftables"
}

# Перезапуск Docker
sudo systemctl restart docker

# Перевірка — повинні з'явитися таблиці docker-*
sudo nft list tables

Рішення 2: створення власних правил з правильним пріоритетом

Якщо ви використовуєте Docker зі стандартним iptables-бекендом, створіть окрему таблицю nftables з правилами, що виконуються до правил Docker:

table inet docker_filter {
    set allowed_docker_clients {
        type ipv4_addr
        flags interval
        elements = { 10.0.0.0/8, 172.16.0.0/12 }
    }

    chain forward {
        type filter hook forward priority -1; policy accept;

        # Блокувати зовнішній доступ до контейнерних портів
        iifname "eth0" oifname "docker0" \
            ip saddr != @allowed_docker_clients \
            tcp dport { 3306, 5432, 6379 } drop
    }
}

Зверніть увагу на priority -1 — це гарантує, що наші правила обробляються до стандартних правил Docker (які мають пріоритет 0).

Кращі практики Docker + nftables

• Прив'язуйте чутливі сервіси до 127.0.0.1 замість 0.0.0.0 у Docker Compose: ports: ["127.0.0.1:5432:5432"]
• Використовуйте внутрішні мережі Docker (internal: true) для ізоляції бекенд-сервісів
• Завжди перевіряйте відкриті порти з зовнішньої машини після розгортання контейнерів — не довіряйте тільки nft list ruleset
• Зберігайте правила фільтрації Docker у окремій systemd-юніті, що запускається після Docker

Журналювання та моніторинг: видимість мережевих подій

Брандмауер без журналювання — як замок без камер спостереження. Ви знаєте, що двері зачинені, але поняття не маєте, хто й скільки разів намагався їх відчинити.

Базове журналювання відхилених пакетів

У nftables журналювання та дія над пакетом об'єднуються в одному правилі. В iptables для цього потрібні два окремі правила — ще один плюс на користь nftables:

chain input {
    type filter hook input priority 0; policy drop;

    # Стандартні правила прийняття
    iif "lo" accept
    ct state established,related accept

    # Журналювання перед відхиленням SSH-спроб з невідомих мереж
    tcp dport 22 ip saddr != @management_nets \
        log prefix "[nft] SSH-DENIED: " level warn drop

    # Журналювання всіх інших відхилених пакетів
    log prefix "[nft] INPUT-DROP: " level info counter
}

Обмеження інтенсивності журналювання

Щоб уникнути переповнення логів при DDoS або інтенсивному скануванні портів, використовуйте динамічну множину для обмеження повторних записів:

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

chain input {
    type filter hook input priority 0; policy drop;

    # Пропуск вже зафіксованих IP (уникнення повторів протягом 1 хвилини)
    ip saddr @log_ratelimit counter drop

    # Журналювання нових відхилених IP та додавання до множини
    log prefix "[nft] DROP: " \
        add @log_ratelimit { ip saddr } counter drop
}

Без цього обмеження один агресивний сканер може легко згенерувати гігабайти логів за годину. Перевірено на практиці.

Перенаправлення логів у окремий файл через rsyslog

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

# Файл: /etc/rsyslog.d/nftables.conf
:msg, regex, "\\[nft\\]" /var/log/nftables.log
& stop

# Перезапуск rsyslog
sudo systemctl restart rsyslog

# Ротація логів: /etc/logrotate.d/nftables
/var/log/nftables.log {
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

Тепер всі записи nftables акуратно потрапляють у /var/log/nftables.log, де їх зручно аналізувати grep'ом або будь-яким інструментом моніторингу.

Повна продакшн-конфігурація: збираємо все разом

А тепер — фінальний акорд. Ось комплексна конфігурація nftables для типового веб-сервера з усіма розглянутими методами захисту в одному файлі:

#!/usr/sbin/nft -f

flush ruleset

define WAN_IF = "eth0"
define SSH_PORT = 22
define WEB_PORTS = { 80, 443 }

table inet filter {

    # Множина довірених адміністративних мереж
    set admin_nets {
        type ipv4_addr
        flags interval
        elements = { 10.0.10.0/24, 192.168.100.0/24 }
    }

    # Динамічна множина для блокування brute force SSH
    set ssh_banned {
        type ipv4_addr
        flags timeout
        timeout 2h
    }

    # Динамічна множина для обмеження логів
    set log_limit {
        type ipv4_addr
        flags dynamic,timeout
        timeout 1m
        size 65536
    }

    # ---------- ВХІДНИЙ ТРАФІК ----------
    chain input {
        type filter hook input priority 0; policy drop;

        # Loopback
        iif "lo" accept

        # Відстеження з'єднань
        ct state established,related accept
        ct state invalid drop

        # Відхилення заблокованих IP
        ip saddr @ssh_banned \
            log prefix "[nft] SSH-BAN-HIT: " drop

        # ICMP з обмеженням
        ip protocol icmp icmp type echo-request \
            limit rate 5/second accept
        ip6 nexthdr icmpv6 icmpv6 type {
            echo-request,
            nd-neighbor-solicit,
            nd-neighbor-advert,
            nd-router-solicit,
            nd-router-advert
        } accept

        # SSH: лише з довірених мереж + rate limiting + auto-ban
        tcp dport $SSH_PORT ip saddr != @admin_nets drop
        tcp dport $SSH_PORT ct state new \
            limit rate over 10/minute \
            add @ssh_banned { ip saddr timeout 2h } \
            log prefix "[nft] SSH-BANNED: " counter drop
        tcp dport $SSH_PORT ct state new \
            limit rate 5/minute burst 3 packets \
            accept

        # Веб-трафік
        tcp dport $WEB_PORTS accept

        # Журналювання відхилених пакетів (з обмеженням)
        ip saddr @log_limit counter drop
        log prefix "[nft] INPUT-DROP: " \
            add @log_limit { ip saddr } counter drop
    }

    # ---------- ТРАНЗИТНИЙ ТРАФІК ----------
    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    # ---------- ВИХІДНИЙ ТРАФІК ----------
    chain output {
        type filter hook output priority 0; policy accept;
    }
}

Ця конфігурація покриває основні потреби безпеки: drop-by-default політика, захист SSH від brute force з автоматичним блокуванням, обмеження ICMP, і журналювання з rate limiting. Скопіюйте її як стартову точку і адаптуйте під свої потреби.

Резервне копіювання та автоматизація

# Резервне копіювання поточних правил
sudo nft list ruleset > /root/nftables-backup-$(date +%Y%m%d).conf

# Валідація нової конфігурації
sudo nft -c -f /etc/nftables.conf

# Безпечне застосування з автоматичним відкатом через 5 хвилин
echo "sudo nft -f /root/nftables-backup-$(date +%Y%m%d).conf" | at now + 5 minutes
sudo nft -f /etc/nftables.conf
# Якщо все працює, скасуйте відкат:
atrm $(atq | tail -1 | awk '{print $1}')

# Автоматичне резервне копіювання через cron (щоденно)
echo "0 2 * * * root nft list ruleset > /root/nft-backups/nftables-\$(date +\%Y\%m\%d).conf" | sudo tee /etc/cron.d/nftables-backup

Корисні команди для щоденної роботи з nftables

На завершення — компактна шпаргалка команд, які вам знадобляться найчастіше. Рекомендую зберегти собі кудись під рукою:

# Перегляд усіх правил
sudo nft list ruleset

# Перегляд конкретної таблиці
sudo nft list table inet filter

# Перегляд вмісту множини
sudo nft list set inet filter ssh_banned

# Додавання правила динамічно
sudo nft add rule inet filter input tcp dport 8443 accept

# Видалення правила (знайдіть handle спочатку)
sudo nft -a list chain inet filter input
sudo nft delete rule inet filter input handle 15

# Скидання лічильників
sudo nft reset counters

# Трасування правил (дебаг)
sudo nft add rule inet filter input meta nftrace set 1
sudo nft monitor trace

# Перевірка файлу конфігурації
sudo nft -c -f /etc/nftables.conf

Часті запитання (FAQ)

Чим nftables краще за iptables і чи варто мігрувати?

nftables перевершує iptables за кількома фундаментальними параметрами: єдиний інструмент замість чотирьох, атомарне оновлення правил, вбудовані множини та карти для O(1)-пошуку, і значно чистіший декларативний синтаксис. Міграція однозначно варта зусиль — iptables офіційно застарілий з 2022 року, а на сучасних дистрибутивах ваші команди iptables і так транслюються у nftables через шар сумісності. Краще контролювати цей процес напряму.

Чи можна використовувати nftables разом з UFW або firewalld?

Технічно — так, але є нюанси. UFW на Ubuntu 22.04+ вже використовує nftables як бекенд. Firewalld на RHEL 9+ теж працює поверх nftables. Проте категорично не рекомендується одночасно додавати правила через UFW/firewalld та напряму через nft — це майже гарантовано призведе до конфліктів. Оберіть один підхід і дотримуйтесь його.

Як nftables взаємодіє з Docker і чи обходить Docker мої правила брандмауера?

Коротка відповідь — так, обходить. Docker вставляє власні NAT-правила для прокидання портів контейнерів, і ці правила обробляються до ваших правил фільтрації. Порти контейнерів можуть бути доступні ззовні, навіть якщо ваш брандмауер мав би це заборонити. Рішення: або використовуйте нативний бекенд nftables у Docker 29+, або створюйте окрему таблицю з правилами forward з пріоритетом нижче Docker. І завжди прив'язуйте чутливі порти до 127.0.0.1.

Як захистити SSH від brute force без Fail2Ban, лише засобами nftables?

nftables підтримує динамічні множини з таймаутами — саме те, що потрібно. Створіть множину з прапорцем timeout, а потім використовуйте конструкцію limit rate over X/minute add @banned_set { ip saddr timeout Yh } drop. Такий підхід працює швидше за Fail2Ban, не потребує жодних демонів чи аналізу логів, і оперує безпосередньо в мережевому стеку ядра. Детальні приклади з робочим кодом наведені вище в розділі про захист SSH.

Чи підтримує nftables геоблокування за країною?

З коробки — ні, але рішення існують. Інструменти на кшталт nft-geo-filter та nftables-geoip завантажують IP-діапазони за країнами з баз даних (db-ip.com, IP2Location) та генерують відповідні множини nftables. Для найкращої продуктивності використовуйте хук prerouting з пріоритетом raw, щоб відхиляти пакети якомога раніше — ще до обробки conntrack. І не забудьте налаштувати cron-задачу для регулярного оновлення IP-списків, бо вони змінюються частіше, ніж можна подумати.