Укрепване на Linux защитна стена с nftables: Практическо ръководство за миграция и защита

Укрепване на Linux защитна стена с nftables: Практическо ръководство за миграция и защита

1. Въведение: Защо nftables замени iptables

Ако сте администрирали Linux сървъри през последните двадесет години, почти сигурно сте прекарали безброй часове с iptables. Аз лично имам спомени за нощни смени, в които дебъгвах верижни правила с iptables -L -v -n и се чудех защо пакетите не минават. Инструментът ни служеше добре, но честно казано — архитектурата му започна да показва своите пукнатини.

Дублиращите се инструменти (iptables, ip6tables, arptables, ebtables), липсата на атомарни обновявания и неефективното линейно обхождане на правилата са проблеми, с които всеки от нас се е сблъсквал. Нещата трябваше да се променят.

nftables е наследникът на iptables и е част от Linux ядрото от версия 3.13 (януари 2014 г.). Към 2026 г. nftables е стандартната подсистема за филтриране на пакети в почти всички основни дистрибуции — Debian 11+, Ubuntu 22.04+, RHEL 9+, Fedora 33+ и Arch Linux вече го използват като подразбиращ се бекенд. Дори когато изпълнявате команди чрез iptables-nft, зад кулисите работи nftables.

Важно: Ако все още разчитате изцяло на iptables за продуктивни сървъри през 2026 г., е крайно време за миграция. Класическият iptables-legacy вече не получава активна разработка, а поддръжката му в новите ядра постепенно намалява.

В това ръководство ще преминем през архитектурата на nftables, основния синтаксис, изграждането на укрепена защитна стена от нулата, защитата срещу DDoS и brute-force атаки, flowtables и миграцията от iptables. Да започваме.

2. Архитектура на nftables срещу iptables — какво точно се промени?

Преди да се хвърлим в конфигурациите, нека разберем какво прави nftables по-добър избор. Разликите не са козметични — те са фундаментални.

Единна рамка

При iptables използвахме отделни инструменти за различните протоколни семейства: iptables за IPv4, ip6tables за IPv6, arptables за ARP, ebtables за Ethernet мостове. В nftables всичко е обединено в един инструмент — nft — който работи с различни адресни семейства: ip, ip6, inet, arp, bridge и netdev. Това само по себе си е огромно опростяване.

Няма предефинирани таблици и вериги

Iptables идваше с вградени таблици (filter, nat, mangle, raw) и вериги (INPUT, OUTPUT, FORWARD). В nftables нищо не е предефинирано. Вие създавате собствени таблици и вериги, като посочвате техния тип и приоритет. Отначало може да ви се стори непривично, но бързо ще оцените пълния контрол над структурата.

Атомарни обновявания

Това е може би най-важното подобрение от гледна точка на сигурността. При iptables зареждането на нов набор от правила изискваше последователно изпълнение на множество команди — създавайки кратък прозорец, през който защитната стена можеше да бъде в непоследователно състояние. nftables поддържа атомарни транзакции — целият набор правила се прилага наведнъж или изобщо не се прилага.

Вградени структури от данни

nftables поддържа нативно множества (sets), карти (maps) и verdict maps, които позволяват ефективно съпоставяне на голям брой адреси, портове или други критерии без стотици отделни правила. Повярвайте ми — когато за пръв път замените 200 реда iptables правила с едно множество, ще се зарадвате.

Виртуална машина в ядрото

За разлика от iptables, който използва фиксирани модули за съвпадение, nftables работи чрез малка виртуална машина в ядрото (nf_tables), изпълняваща байткод. Това прави системата по-гъвкава и разширяема без промяна на кода на ядрото.

Сравнение в кратък вид

• Протоколни семейства: iptables — отделен инструмент за всяко; nftables — всичко в nft
• Предефинирани таблици: iptables — фиксирани (filter, nat, mangle); nftables — няма, създавате ги сами
• Обновяване на правила: iptables — последователно (не-атомарно); nftables — атомарни транзакции
• Структури от данни: iptables — ipset (външен инструмент); nftables — вградени множества, карти, verdict maps
• Синтаксис: iptables — аргументи в команден ред; nftables — по-четим, декларативен
• Производителност: iptables — линейно обхождане; nftables — оптимизация чрез вътрешни структури и flowtables

3. Инсталация и начална настройка

Нека започнем с инсталацията. Процесът е прост и зависи от дистрибуцията ви.

Debian / Ubuntu

# Инсталиране на nftables
sudo apt update
sudo apt install nftables

# Активиране и стартиране на услугата
sudo systemctl enable nftables
sudo systemctl start nftables

# Проверка на версията
nft --version

RHEL / Fedora / AlmaLinux

# nftables обикновено е предварително инсталиран в RHEL 9+ и Fedora
sudo dnf install nftables

# Деактивиране на firewalld ако ще конфигурирате nftables директно
sudo systemctl stop firewalld
sudo systemctl disable firewalld

# Активиране на nftables
sudo systemctl enable nftables
sudo systemctl start nftables

Забележка: В RHEL/Fedora firewalld по подразбиране използва nftables като бекенд. Ако предпочитате директно управление с nft, деактивирайте firewalld, за да избегнете конфликти. Иначе рискувате доста объркващи моменти при дебъгване.

Arch Linux

sudo pacman -S nftables
sudo systemctl enable nftables
sudo systemctl start nftables

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

Проверка на инсталацията

# Проверка на версията на nft
nft --version

# Проверка дали ядрото поддържа nftables
lsmod | grep nf_tables

# Преглед на текущия набор от правила (трябва да е празен или минимален)
sudo nft list ruleset

# Проверка на състоянието на услугата
sudo systemctl status nftables

4. Основи на синтаксиса на nftables

Сега идва забавната част — да научим как се пишат правилата. Ако идвате от iptables, синтаксисът ще ви се стори различен, но доста по-четим.

Семейства адреси (Address Families)

nftables поддържа следните семейства:

• ip — само IPv4 (подразбиращо се семейство)
• ip6 — само IPv6
• inet — IPv4 и IPv6 едновременно (за повечето случаи ще искате точно това)
• arp — ARP протокол
• bridge — Ethernet мост
• netdev — обработка на пакети на ниво мрежово устройство (за ранно филтриране)

Таблици (Tables)

Таблицата е контейнер за вериги и множества. Създаването на таблица е първата стъпка:

# Създаване на таблица от семейство inet (IPv4 + IPv6)
nft add table inet firewall

# Преглед на всички таблици
nft list tables

# Изтриване на таблица (заедно с всички вериги и правила в нея)
nft delete table inet firewall

Вериги (Chains)

Веригите биват два вида: базови вериги (base chains), които се закачат към определена точка в мрежовия стек, и обикновени вериги (regular chains), които се извикват от други вериги — нещо като функции.

# Базова верига за входящ трафик
nft add chain inet firewall input {
    type filter hook input priority 0; policy drop;
}

# Базова верига за изходящ трафик
nft add chain inet firewall output {
    type filter hook output priority 0; policy accept;
}

# Базова верига за препредаван трафик
nft add chain inet firewall forward {
    type filter hook forward priority 0; policy drop;
}

# Обикновена верига (извиква се с jump/goto)
nft add chain inet firewall tcp_checks

Кратко обяснение на параметрите: type определя функцията на веригата (filter, nat, route). hook определя точката на закачане. priority определя реда на изпълнение (по-малки стойности = по-ранна обработка). А policy задава действието по подразбиране за пакети, които не съвпадат с нито едно правило.

Правила (Rules)

Правилата се добавят в съществуващи вериги и определят какво да се случи с пакетите:

# Разрешаване на установени и свързани връзки
nft add rule inet firewall input ct state established,related accept

# Разрешаване на loopback интерфейс
nft add rule inet firewall input iifname "lo" accept

# Разрешаване на SSH от определена мрежа
nft add rule inet firewall input ip saddr 192.168.1.0/24 tcp dport 22 accept

# Разрешаване на HTTP и HTTPS чрез анонимно множество
nft add rule inet firewall input tcp dport { 80, 443 } accept

# Логване и отхвърляне на всичко останало
nft add rule inet firewall input counter log prefix "BLOCKED: " drop

Основни действия (Verdicts)

• accept — приема пакета
• drop — отхвърля пакета мълчаливо
• reject — отхвърля с ICMP съобщение за грешка
• jump — препраща обработката към друга верига
• goto — като jump, но без връщане обратно
• return — връща обработката към извикващата верига
• log — записва информация в системния журнал
• counter — увеличава брояча на съвпадения

5. Изграждане на укрепена сървърна защитна стена от нулата

Добре, стигнахме до най-практичната част. Следващата конфигурация представлява пълноценна, укрепена защитна стена за уеб сървър. Тя прилага принципа на минималните привилегии — забранява всичко по подразбиране и разрешава само необходимия трафик.

#!/usr/sbin/nft -f

# Изчистване на всички съществуващи правила
flush ruleset

# ============================================
# Основна таблица за филтриране
# ============================================
table inet firewall {

    # ----- Множества (Sets) -----

    # Доверени IP адреси за SSH достъп
    set ssh_allowed {
        type ipv4_addr
        flags interval
        elements = {
            192.168.1.0/24,
            10.0.0.0/8,
            203.0.113.50
        }
    }

    # Публично достъпни портове
    set web_ports {
        type inet_service
        elements = { 80, 443 }
    }

    # Черен списък с блокирани адреси
    set blocklist {
        type ipv4_addr
        flags interval, timeout
        timeout 24h
    }

    # Динамично множество за SSH brute-force защита
    set ssh_bruteforce {
        type ipv4_addr
        flags dynamic, timeout
        timeout 15m
    }

    # ----- Входяща верига -----
    chain input {
        type filter hook input priority 0; policy drop;

        # Отхвърляне на трафик от черния списък
        ip saddr @blocklist counter drop

        # Разрешаване на установени и свързани връзки
        ct state established,related accept

        # Отхвърляне на невалидни пакети
        ct state invalid counter drop

        # Разрешаване на loopback
        iifname "lo" accept

        # ICMP — разрешаване на ping с ограничение
        ip protocol icmp icmp type {
            echo-request,
            echo-reply,
            destination-unreachable,
            time-exceeded
        } limit rate 10/second accept

        # ICMPv6 — необходим за правилна работа на IPv6
        ip6 nexthdr icmpv6 icmpv6 type {
            echo-request,
            echo-reply,
            nd-neighbor-solicit,
            nd-neighbor-advert,
            nd-router-solicit,
            nd-router-advert,
            mld-listener-query,
            destination-unreachable,
            packet-too-big,
            time-exceeded,
            parameter-problem
        } accept

        # SSH с ограничение на скоростта и brute-force защита
        tcp dport 22 ip saddr @ssh_allowed \
            ct state new \
            limit rate 5/minute \
            accept

        # Уеб услуги (HTTP/HTTPS)
        tcp dport @web_ports ct state new accept

        # Логване на отхвърлен трафик (ограничено)
        limit rate 5/minute counter log prefix "nft-drop-input: " level info

        # Отхвърляне на всичко останало с ICMP съобщение
        reject with icmpx type admin-prohibited
    }

    # ----- Изходяща верига -----
    chain output {
        type filter hook output priority 0; policy accept;

        # Разрешаване на loopback
        oifname "lo" accept

        # Разрешаване на установени връзки
        ct state established,related accept

        # Разрешаване на DNS заявки
        tcp dport 53 accept
        udp dport 53 accept

        # Разрешаване на NTP синхронизация
        udp dport 123 accept

        # Разрешаване на HTTP/HTTPS (за обновяване на пакети)
        tcp dport { 80, 443 } accept

        # Разрешаване на SMTP изходящи (ако сървърът изпраща поща)
        tcp dport { 25, 587 } accept
    }

    # ----- Верига за препредаван трафик -----
    chain forward {
        type filter hook forward priority 0; policy drop;
        # Сървър, който не рутира — забрана на всичко
    }
}

Какво постигаме с тази конфигурация? Ето основните принципи:

• Политика drop по подразбиране за входящ и препредаван трафик — нищо не минава, освен ако изрично не е разрешено
• SSH достъп само от доверени мрежи (не подценявайте колко важно е това)
• Ограничаване на ICMP за предотвратяване на flood атаки
• Логване на отхвърлен трафик за последващ анализ
• Използване на множества за лесно управление
• Отхвърляне на невалидни пакети — основна стъпка срещу редица атаки
• Поддръжка на IPv4 и IPv6 чрез семейството inet

За да запазите конфигурацията и тя да се зарежда при рестарт:

# Запазване на конфигурацията
sudo cp /etc/nftables.conf /etc/nftables.conf.backup
sudo nft list ruleset > /etc/nftables.conf

# Или директно редактирайте файла и добавете шебанг реда:
# #!/usr/sbin/nft -f

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

# Активиране на автоматично зареждане при стартиране
sudo systemctl enable nftables

6. Разширени възможности: множества, карти и конкатенации

Тук нещата стават наистина интересни. Множествата и картите са една от причините, поради които nftables е толкова по-мощен от iptables.

Именувани множества (Named Sets)

Множествата позволяват групиране на стойности — IP адреси, портове, интерфейси — и препращане към тях от правила. Обновяват се атомарно и са несравнимо по-бързи от поредица отделни правила.

# Множество с интервали
nft add set inet firewall internal_nets {
    type ipv4_addr
    flags interval
    elements = { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 }
}

# Добавяне на елемент към съществуващо множество
nft add element inet firewall internal_nets { 100.64.0.0/10 }

# Изтриване на елемент
nft delete element inet firewall internal_nets { 100.64.0.0/10 }

# Множество с автоматично изтичане (timeout)
nft add set inet firewall temp_ban {
    type ipv4_addr
    flags timeout
    timeout 1h
}

# Добавяне с индивидуален timeout
nft add element inet firewall temp_ban { 198.51.100.5 timeout 30m }

# Преглед на съдържанието на множество
nft list set inet firewall temp_ban

Карти (Maps)

Картите позволяват съпоставяне на една стойност с друга. Например, може да определите различно действие според порта на дестинация:

# Verdict map — различно действие според порта
nft add map inet firewall port_policy {
    type inet_service : verdict
}

nft add element inet firewall port_policy {
    22 : accept,
    80 : accept,
    443 : accept,
    8080 : drop
}

# Използване в правило
nft add rule inet firewall input tcp dport vmap @port_policy

Verdict Maps за насочване към вериги

Verdict maps могат да насочват трафик към различни вериги въз основа на съвпадение. Ако имате сървър с множество интерфейси, това е невероятно удобно:

table inet firewall {
    chain input {
        type filter hook input priority 0; policy drop;
        ct state established,related accept
        iifname vmap {
            "lo" : accept,
            "eth0" : jump public_input,
            "eth1" : jump private_input
        }
    }

    chain public_input {
        tcp dport { 80, 443 } accept
        limit rate 5/minute log prefix "public-drop: " drop
    }

    chain private_input {
        ip saddr 10.0.0.0/8 tcp dport { 22, 3306, 5432 } accept
        drop
    }
}

Конкатенации (Concatenations)

Конкатенациите позволяват съпоставяне на комбинации от полета в един елемент — значително по-ефективно от отделно правило за всяка комбинация:

# Множество с конкатенация: IP адрес + порт
nft add set inet firewall allowed_services {
    type ipv4_addr . inet_service
    elements = {
        192.168.1.100 . 22,
        192.168.1.101 . 3306,
        10.0.0.50 . 5432
    }
}

# Правило, използващо конкатенация
nft add rule inet firewall input ip saddr . tcp dport @allowed_services accept

# Конкатенация с три полета: IP + протокол + порт
nft add set inet firewall complex_rules {
    type ipv4_addr . inet_proto . inet_service
    elements = {
        192.168.1.100 . tcp . 22,
        192.168.1.100 . tcp . 443,
        10.0.0.50 . udp . 53
    }
}

Тези структури правят nftables значително по-ефективен при комплексни набори от правила. Вместо стотици правила с линейно обхождане, множествата и картите дават търсене с времева сложност близка до O(1). На практика разликата в производителността е осезаема.

7. Ограничаване на скоростта и защита от DDoS атаки

Нека бъдем реалисти — ако сървърът ви е в интернет, той ще бъде атакуван. Въпросът не е дали, а кога. nftables ви дава солиден набор от инструменти за защита.

Защита от SYN Flood

SYN flood е една от най-разпространените DDoS атаки. Атакуващият изпраща огромен брой TCP SYN пакети, без да завършва тристранното ръкостискане, което изчерпва ресурсите на сървъра. Ето как се справяме:

table inet ddos_protection {
    chain input {
        type filter hook input priority -10; policy accept;

        # Отхвърляне на невалидни пакети
        ct state invalid drop

        # Защита от SYN flood чрез ограничаване на нови TCP връзки
        tcp flags syn ct state new \
            limit rate over 60/second burst 20 packets \
            counter drop

        # Ограничаване на фрагментирани пакети
        ip frag-off & 0x1fff != 0 counter drop

        # Защита от XMAS сканиране
        tcp flags & (fin|syn|rst|psh|ack|urg) == fin|syn|rst|psh|ack|urg drop

        # Защита от NULL сканиране
        tcp flags & (fin|syn|rst|psh|ack|urg) == 0x0 drop

        # Защита от невалидна комбинация SYN-FIN
        tcp flags & (syn|fin) == syn|fin drop

        # Защита от невалидна комбинация SYN-RST
        tcp flags & (syn|rst) == syn|rst drop

        # Ограничаване на нови TCP връзки от един IP
        tcp flags syn ct state new \
            meter syn_flood { ip saddr limit rate over 20/second burst 10 packets } \
            counter drop
    }
}

Ограничаване на броя връзки от един IP

# Максимум 50 едновременни връзки от един IP адрес
nft add rule inet firewall input \
    ct state new \
    meter connlimit { ip saddr ct count over 50 } \
    counter reject with icmpx type admin-prohibited

# Ограничение за HTTP
nft add rule inet firewall input \
    tcp dport 80 ct state new \
    meter http_connlimit { ip saddr ct count over 30 } \
    counter drop

# Ограничение за HTTPS
nft add rule inet firewall input \
    tcp dport 443 ct state new \
    meter https_connlimit { ip saddr ct count over 30 } \
    counter drop

Ограничаване по скорост (Rate Limiting)

# Глобално ограничение на нови връзки
nft add rule inet firewall input \
    ct state new \
    limit rate 200/second burst 50 packets accept

# Ограничение за ICMP (защита от ping flood)
nft add rule inet firewall input \
    ip protocol icmp \
    limit rate 5/second burst 10 packets accept

nft add rule inet firewall input \
    ip protocol icmp drop

Филтриране на ниво netdev за ранна защита

Семейството netdev позволява филтриране на пакети още преди те да достигнат мрежовия стек на ядрото. Това е изключително ефективно за DDoS защита — пакетите се отхвърлят максимално рано, с минимално натоварване на процесора.

table netdev early_filter {
    chain ingress {
        type filter hook ingress device "eth0" priority -500; policy accept;

        # Отхвърляне на пакети от известни зловредни мрежи
        ip saddr { 198.51.100.0/24, 203.0.113.0/24 } drop

        # Отхвърляне на невалидни TCP флагове при SYN пакети
        tcp flags syn tcp option maxseg size 1-535 drop

        # Защита от spoofing
        ip saddr 127.0.0.0/8 drop
        ip saddr 0.0.0.0/8 drop
    }
}

Съвет: Филтрирането на ниво netdev е особено полезно при сървъри, изложени на чести DDoS атаки. Комбинирайте го с филтриране на ниво inet за многослойна защита — именно тази комбинация дава най-добри резултати на практика.

8. Защита от SSH Brute-Force с динамични множества

SSH brute-force атаките са ежедневна реалност за всеки публично достъпен сървър. Ако не вярвате, проверете /var/log/auth.log на произволен сървър с отворен порт 22 — ще видите стотици (а понякога хиляди) опити на ден. С nftables можем да изградим ефективна многослойна защита:

table inet ssh_protection {

    # Множество за проследяване на неуспешни опити
    set ssh_offenders {
        type ipv4_addr
        flags dynamic, timeout
        timeout 15m
    }

    # Черен списък за повторни нарушители
    set ssh_blacklist {
        type ipv4_addr
        flags dynamic, timeout
        timeout 24h
    }

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

        # Незабавно блокиране на адреси в черния списък
        tcp dport 22 ip saddr @ssh_blacklist counter drop

        # Ако адресът вече е в нарушителите и прави нов опит —
        # премества се в черния списък за 24 часа
        tcp dport 22 ct state new \
            ip saddr @ssh_offenders \
            add @ssh_blacklist { ip saddr } \
            counter drop

        # Добавяне към нарушители при превишаване на лимита
        # (повече от 4 нови връзки за минута)
        tcp dport 22 ct state new \
            limit rate over 4/minute \
            add @ssh_offenders { ip saddr } \
            counter drop

        # Разрешаване на SSH в нормални граници
        tcp dport 22 ct state new accept
    }
}

Как работи този механизъм на практика:

1. Ако IP адрес е в ssh_blacklist — пакетът се отхвърля незабавно, без допълнителна обработка
2. Ако IP вече е в ssh_offenders и прави нов опит — автоматично отива в ssh_blacklist за 24 часа
3. Ако нов IP прави повече от 4 опита за минута — добавя се в ssh_offenders за 15 минути
4. Нормалните SSH връзки минават без ограничения

Елегантно, нали? Ето и командите за мониторинг и управление:

# Преглед на текущите нарушители
nft list set inet ssh_protection ssh_offenders

# Преглед на черния списък
nft list set inet ssh_protection ssh_blacklist

# Ръчно добавяне на IP в черния списък
nft add element inet ssh_protection ssh_blacklist { 198.51.100.25 timeout 48h }

# Ръчно изтриване на IP от черния списък
nft delete element inet ssh_protection ssh_blacklist { 198.51.100.25 }

# Изчистване на цялото множество
nft flush set inet ssh_protection ssh_offenders

9. Реализация на Port Knocking с nftables

Port knocking е интересна техника, при която достъпът до услуга (например SSH) се отключва само след последователно „почукване" на определени портове в правилния ред. Мога да кажа, че не е панацея, но като допълнителен слой защита — работи отлично за скриване на критични услуги от автоматизирани сканери.

С nftables реализацията е доста елегантна чрез динамични множества:

table inet port_knocking {

    # Етап 1: Изчакване на първо почукване
    set knock_stage1 {
        type ipv4_addr
        flags dynamic, timeout
        timeout 10s
    }

    # Етап 2: Изчакване на второ почукване
    set knock_stage2 {
        type ipv4_addr
        flags dynamic, timeout
        timeout 10s
    }

    # Етап 3: Достъпът е отключен
    set knock_allowed {
        type ipv4_addr
        flags dynamic, timeout
        timeout 60s
    }

    chain input {
        type filter hook input priority -5; policy accept;

        # Ако клиентът е преминал всички етапи — SSH е разрешен
        tcp dport 22 ip saddr @knock_allowed accept

        # Блокиране на SSH за всички останали
        tcp dport 22 drop

        # Етап 3: Почукване на порт 39456 след успешен етап 2
        tcp dport 39456 ip saddr @knock_stage2 \
            add @knock_allowed { ip saddr } \
            drop

        # Етап 2: Почукване на порт 27391 след успешен етап 1
        tcp dport 27391 ip saddr @knock_stage1 \
            add @knock_stage2 { ip saddr } \
            drop

        # Етап 1: Почукване на порт 15823
        tcp dport 15823 \
            add @knock_stage1 { ip saddr } \
            drop
    }
}

За отключване на SSH от клиентската страна:

# Почукване на портовете в правилния ред с nmap
nmap -Pn --host-timeout 100 --max-retries 0 -p 15823 server_ip
nmap -Pn --host-timeout 100 --max-retries 0 -p 27391 server_ip
nmap -Pn --host-timeout 100 --max-retries 0 -p 39456 server_ip

# Или с knock клиент (пакет knockd)
knock server_ip 15823 27391 39456

# Или с bash и /dev/tcp
for port in 15823 27391 39456; do
    (echo >/dev/tcp/server_ip/$port) 2>/dev/null
    sleep 0.5
done

# Сега SSH е достъпен за 60 секунди
ssh user@server_ip

Внимание: Port knocking не заменя силна SSH автентикация (ключове, многофакторна автентикация). Използвайте го като допълнителен слой. И си изберете портове, които не се сканират често от стандартните инструменти.

10. Flowtables за оптимизация на производителността

Flowtables са една от функционалностите на nftables, които наистина ме впечатлиха. Идеята е проста, но ефектът е значителен — установените потоци се обработват по „бърз път" (fast path), заобикаляйки пълния набор от правила. Вместо всеки пакет да преминава през цялата верига, установените потоци се обработват директно в мрежовия стек.

table inet firewall {

    # Дефиниране на flowtable
    flowtable ft {
        hook ingress priority 0
        devices = { eth0, eth1 }
    }

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

        # Установените потоци се обработват чрез flowtable
        ct state established,related flow add @ft accept

        # Нови връзки преминават през стандартната обработка
        ct state new tcp dport { 80, 443, 22 } accept

        # Отхвърляне на невалидни пакети
        ct state invalid drop
    }
}

Кога flowtables наистина правят разлика:

• Маршрутизатори с висок обем препредаван трафик — значително намалено натоварване на CPU
• Балансьори на натоварването, обработващи хиляди връзки в секунда
• VPN шлюзове, където всяка спестена микросекунда се отразява на крайната производителност
• Контейнерни хостове с голям брой мрежови връзки

Подобрението може да достигне 50-80% увеличение на пропускателната способност при препредаване на пакети. Звучи прекалено добре? Причината е, че пакетите в бързия път заобикалят conntrack и целия набор от nftables правила.

# Проверка на flowtable статистика
nft list flowtables
nft list flowtable inet firewall ft

# Мониторинг на потоци чрез conntrack
conntrack -L | wc -l
conntrack -S

# Проверка дали flowtable offload работи
cat /proc/net/netfilter/nf_flowtable

11. Миграция от iptables към nftables

Ако сте стигнали дотук и вече сте убедени, че nftables е правилният избор (а честно казано, би трябвало да сте), нека поговорим за миграцията. Linux предоставя инструменти за автоматична транслация, но ръчната оптимизация след това е силно препоръчителна.

Използване на iptables-translate

# Транслация на единично правило
iptables-translate -A INPUT -p tcp --dport 22 -j ACCEPT
# Резултат: nft add rule ip filter INPUT tcp dport 22 counter accept

# Транслация на правило с conntrack
iptables-translate -A INPUT -p tcp --dport 22 \
    -m conntrack --ctstate NEW -m limit --limit 3/min -j ACCEPT
# Резултат: nft add rule ip filter INPUT tcp dport 22 ct state new limit rate 3/minute counter accept

# Транслация на NAT правило
iptables-translate -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# Резултат: nft add rule ip nat POSTROUTING oifname "eth0" masquerade

# Транслация на ip6tables правило
ip6tables-translate -A INPUT -p tcp --dport 443 -j ACCEPT
# Резултат: nft add rule ip6 filter INPUT tcp dport 443 counter accept

Експортиране на цялата iptables конфигурация

# Запазване на текущите iptables правила в nftables формат
iptables-save | iptables-restore-translate > /etc/nftables_migrated.conf

# За ip6tables
ip6tables-save | ip6tables-restore-translate >> /etc/nftables_migrated.conf

# Преглед на транслираните правила
cat /etc/nftables_migrated.conf

Стъпки за безопасна миграция

1. Документирайте текущите правила:

iptables-save > /root/iptables_backup_$(date +%Y%m%d).txt
ip6tables-save > /root/ip6tables_backup_$(date +%Y%m%d).txt

2. Транслирайте правилата с iptables-restore-translate
3. Прегледайте и оптимизирайте ръчно: Транслираните правила не използват всички предимства на nftables. Преработете ги, за да използвате множества, карти и конкатенации
4. Тествайте в изолирана среда: Приложете правилата на тестов сървър или виртуална машина
5. Осигурете резервен достъп:

# Планирайте автоматично възстановяване след 5 минути
echo "nft flush ruleset && systemctl restart iptables" | at now + 5 minutes

# Приложете nftables правилата
nft -f /etc/nftables.conf

# Тествайте свързаността от друг терминал
# Тествайте достъпа до уеб услугите

# Ако всичко е наред — отменете аварийното възстановяване
atrm $(atq | awk '{print $1}')

6. Деактивирайте iptables услугите:

sudo systemctl stop iptables ip6tables
sudo systemctl disable iptables ip6tables
sudo systemctl mask iptables ip6tables

# Уверете се, че nftables ще стартира при зареждане
sudo systemctl enable nftables
sudo systemctl start nftables

# Проверете текущото състояние
sudo nft list ruleset

12. Логване, мониторинг и интеграция с fail2ban

Конфигуриране на логване

Логването в nftables е гъвкаво и дава подробен контрол. Но внимавайте — без rate limiting на логването, един DDoS може да ви запълни диска за минути.

# Основно логване с префикс
nft add rule inet firewall input ct state new tcp dport 22 \
    log prefix "SSH-NEW: " level info accept

# Логване с ограничение на скоростта
nft add rule inet firewall input \
    ct state invalid \
    limit rate 10/minute \
    log prefix "INVALID-PKT: " level warn \
    counter drop

# Логване с допълнителни флагове
nft add rule inet firewall input tcp dport 22 ct state new \
    log prefix "SSH-ACCESS: " level info flags all \
    accept

# Логване на отхвърлени пакети от определена мрежа
nft add rule inet firewall input ip saddr 198.51.100.0/24 \
    limit rate 3/minute \
    log prefix "SUSPECT-NET: " level warn \
    counter drop

Логовете се записват чрез syslog. Препоръчвам да ги насочите към отделен файл:

# Създайте конфигурация за rsyslog
# /etc/rsyslog.d/nftables.conf
:msg, contains, "nft-" /var/log/nftables.log
:msg, contains, "SSH-" /var/log/nftables.log
:msg, contains, "INVALID-" /var/log/nftables.log
:msg, contains, "SUSPECT-" /var/log/nftables.log
& stop

# Рестартиране на rsyslog
sudo systemctl restart rsyslog

# Настройка на ротация на логовете
# /etc/logrotate.d/nftables
# /var/log/nftables.log {
#     daily
#     rotate 30
#     compress
#     missingok
#     notifempty
# }

Мониторинг в реално време

# Преглед на всички правила с броячи
nft list ruleset -a

# Мониторинг на промени в реално време
nft monitor

# Мониторинг само на правила и множества
nft monitor rules
nft monitor sets

# Преглед на статистика за конкретна верига
nft list chain inet firewall input

# Нулиране на броячите (полезно за тестване)
nft reset counters

# Наблюдение на активни връзки
conntrack -L -p tcp --dport 22 | wc -l
conntrack -E

Интеграция с fail2ban

fail2ban автоматично блокира IP адреси при повторни неуспешни опити за автентикация. Интеграцията с nftables работи добре, но изисква правилна конфигурация:

# /etc/fail2ban/jail.local
[DEFAULT]
banaction = nftables-multiport
banaction_allports = nftables-allports
chain = input

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
findtime = 600
bantime = 3600
banaction = nftables-multiport

[nginx-http-auth]
enabled = true
port = http,https
filter = nginx-http-auth
logpath = /var/log/nginx/error.log
maxretry = 5
findtime = 300
bantime = 7200

fail2ban автоматично създава nftables таблици и множества. Ето как да проверите:

# Преглед на блокирани адреси за SSH
sudo fail2ban-client status sshd

# Проверка на nftables правилата от fail2ban
nft list table inet f2b-table

# Ръчно разблокиране на адрес
sudo fail2ban-client set sshd unbanip 198.51.100.25

# Статистика на всички jails
sudo fail2ban-client status

За персонализирано действие с nftables и множества с timeout:

# /etc/fail2ban/action.d/nftables-custom.conf
[Definition]
actionstart = nft add table inet f2b
               nft add set inet f2b blocked_ '{ type ipv4_addr; flags timeout; }'
               nft add chain inet f2b  '{ type filter hook input priority -1; }'
               nft add rule inet f2b  ip saddr @blocked_ counter reject

actionstop = nft delete table inet f2b

actionban = nft add element inet f2b blocked_ '{  timeout s }'

actionunban = nft delete element inet f2b blocked_ '{  }'

[Init]
name = default

13. Полезни команди за ежедневна работа

Тази секция е нещо като „пищялка" — запазете я наблизо, ще ви трябва по-често, отколкото мислите.

# === Преглед и информация ===

# Целият набор от правила
nft list ruleset

# В JSON формат (удобно за скриптове)
nft -j list ruleset

# С хендъли на правилата (необходими за изтриване)
nft -a list ruleset

# Конкретна таблица
nft list table inet firewall

# Конкретна верига
nft list chain inet firewall input

# Конкретно множество
nft list set inet firewall blocklist

# === Запазване и зареждане ===

# Запазване на правилата
nft list ruleset > /etc/nftables.conf

# Зареждане от файл
nft -f /etc/nftables.conf

# Проверка на синтаксиса без прилагане
nft -c -f /etc/nftables.conf

# === Модификации ===

# Изчистване на всички правила
nft flush ruleset

# Изчистване на конкретна верига
nft flush chain inet firewall input

# Вмъкване на правило в началото на верига
nft insert rule inet firewall input position 0 ip saddr 198.51.100.0/24 drop

# Изтриване на правило по хендъл
nft -a list chain inet firewall input   # Показва хендълите
nft delete rule inet firewall input handle 15

# Замяна на правило
nft replace rule inet firewall input handle 15 tcp dport 443 accept

# === Множества ===

# Добавяне на множество елементи наведнъж
nft add element inet firewall blocklist { 198.51.100.0/24, 203.0.113.0/24 }

# Изтриване на елемент
nft delete element inet firewall blocklist { 198.51.100.0/24 }

# Изчистване на цялото множество
nft flush set inet firewall blocklist

# === Броячи и мониторинг ===

# Нулиране на всички броячи
nft reset counters

# Мониторинг в реално време
nft monitor

14. Контролен списък за най-добри практики

Преди да обявите защитната стена за готова за продуктивна употреба, преминете през следния списък. Сериозно — не го пропускайте. Пропуснат чекбокс днес може да означава компрометиран сървър утре.

Основна конфигурация

• Използвате семейство inet за едновременна защита на IPv4 и IPv6
• Политиката по подразбиране за входящ трафик е drop
• Политиката за препредаван трафик е drop (ако сървърът не е маршрутизатор)
• Разрешени са само необходимите портове
• Loopback интерфейсът (lo) е изрично разрешен
• Установените и свързаните връзки са разрешени (ct state established,related)
• Невалидните пакети (ct state invalid) се отхвърлят

Защита на услугите

• SSH достъпът е ограничен по IP чрез множества
• Конфигурирана е защита от SSH brute-force
• ICMP трафикът е ограничен по скорост
• ICMPv6 необходимите типове са разрешени за IPv6
• Има ограничение на едновременни връзки от един IP

Защита от атаки

• Конфигурирана е защита от SYN flood с rate limiting
• Невалидните TCP флагове (XMAS, NULL, SYN-FIN, SYN-RST) се отхвърлят
• Има механизъм за динамично блокиране на зловредни адреси
• Разгледана е възможността за netdev филтриране
• Разгледана е възможността за port knocking
• Фрагментираните пакети се обработват правилно

Логване и мониторинг

• Отхвърленият трафик се логва (с rate limiting на логването!)
• Логовете се записват в отделен файл
• Конфигурирана е ротация на лог файловете
• fail2ban е интегриран с nftables
• Има процедура за редовен преглед на логовете

Оперативни процедури

• Конфигурацията е в /etc/nftables.conf и се зарежда при стартиране
• Услугата е активирана (systemctl enable nftables)
• Има резервно копие на работещата конфигурация
• Тествана е процедурата за аварийно възстановяване
• Синтаксисът е проверен с nft -c -f преди прилагане
• Flowtables са конфигурирани за високонатоварени среди
• Миграцията от iptables е завършена
• Промените се документират (например чрез git)

Скрипт за бърза проверка

#!/bin/bash
# nft_health_check.sh - Бърза проверка на състоянието на nftables
# Използване: sudo bash nft_health_check.sh

echo "=== Проверка на nftables ==="
echo ""

# Проверка дали nftables е активен
if systemctl is-active nftables &>/dev/null; then
    echo "[OK] Услугата nftables е активна"
else
    echo "[ГРЕШКА] Услугата nftables НЕ е активна!"
fi

# Проверка дали iptables-legacy не е активен
if systemctl is-active iptables &>/dev/null; then
    echo "[ПРЕДУПРЕЖДЕНИЕ] iptables все още е активен — възможен конфликт"
else
    echo "[OK] iptables не е активен"
fi

# Брой таблици
TABLE_COUNT=$(nft list tables 2>/dev/null | wc -l)
echo "[ИНФО] Брой таблици: $TABLE_COUNT"

# Проверка за drop политика на input
if nft list chain inet firewall input 2>/dev/null | grep -q "policy drop"; then
    echo "[OK] Входящата верига има политика drop"
else
    echo "[ПРЕДУПРЕЖДЕНИЕ] Входящата верига може да няма политика drop"
fi

# Брой правила
RULE_COUNT=$(nft -a list ruleset 2>/dev/null | grep -c "^[[:space:]]*.*accept\|drop\|reject")
echo "[ИНФО] Общ брой правила: $RULE_COUNT"

# Проверка за логване
if nft list ruleset 2>/dev/null | grep -q "log prefix"; then
    echo "[OK] Логването е конфигурирано"
else
    echo "[ПРЕДУПРЕЖДЕНИЕ] Няма конфигурирано логване"
fi

echo ""
echo "=== Проверката завърши ==="

Заключение

nftables вече не е „новият инструмент" — той е зрелият, доказан фреймуърк за защитна стена в Linux. Единният синтаксис, атомарните обновявания, вградените структури от данни и поддръжката на flowtables го правят очевидния избор за 2026 г.

Ако трябва да обобщя в няколко ключови точки:

1. Мигрирайте сега — процесът е добре поддържан с инструментите за транслация. Поддръжката на iptables-legacy намалява с всяко ново ядро
2. Прилагайте принципа на минималните привилегии — забранявайте всичко по подразбиране, разрешавайте само необходимото
3. Използвайте множества и карти — заменете стотиците отделни правила с елегантни структури от данни
4. Защитавайте се на множество нива — rate limiting, динамични множества, fail2ban и port knocking работят най-добре в комбинация
5. Оптимизирайте с flowtables — ако имате висок обем трафик, разликата е значителна
6. Логвайте и наблюдавайте — защитна стена, която не наблюдавате, е само илюзия за сигурност
7. Тествайте преди прилагане — винаги nft -c -f и винаги план за аварийно възстановяване

Защитата на Linux сървъри е непрекъснат процес. Редовно преглеждайте правилата, следете за нови уязвимости и адаптирайте конфигурацията си. С nftables имате на разположение всичко необходимо за изграждане на надеждна и високопроизводителна защитна стена.