Linux Hardening: UFW czy nftables? Nie wybieraj firewalla na podstawie tego, które polecenie łatwiej zapamiętać

W pewnym momencie każdy administrator Linuksa trafia na ten sam problem. System działa. SSH jest zabezpieczone. Niepotrzebne usługi zostały wyłączone. Aplikacja ma zostać wystawiona do Internetu. Pojawia się więc pytanie: czym właściwie zarządzać firewallem?

Na stole leżą trzy nazwy: iptables, nftables i ufw.

I tutaj zaczyna się bałagan.

W poradnikach internetowych można znaleźć wszystko. Jeden autor każe instalować UFW, drugi twierdzi, że prawdziwy administrator powinien pisać reguły nftables, trzeci nadal pokazuje konfigurację iptables, jakby czas zatrzymał się kilka lat temu.

Problem polega na tym, że te narzędzia nie są trzema równorzędnymi firewallami działającymi obok siebie. Są różnymi sposobami zarządzania mechanizmem filtrowania ruchu w jądrze Linuksa. Ubuntu opisuje Netfilter jako podstawowy mechanizm obsługujący filtrowanie pakietów, a nftables jako następcę iptables. UFW jest natomiast uproszczonym narzędziem administracyjnym, które ma ułatwić konfigurację firewalla.

To rozróżnienie jest ważniejsze niż sama składnia poleceń.

Najpierw zapomnij o nazwach narzędzi

Wyobraźmy sobie zwykły serwer Ubuntu.

Ma jeden interfejs sieciowy, publiczny adres IP i trzy usługi:

Internet
   |
   v
[ eth0 ]
   |
   +---- SSH : 22
   |
   +---- HTTPS : 443
   |
   +---- PostgreSQL : 5432

Administrator chce osiągnąć bardzo prosty cel:

SSH ma być dostępne dla administratora, HTTPS dla wszystkich, a PostgreSQL nie powinien być dostępny z Internetu.

To jest polityka bezpieczeństwa.

Dopiero później pojawia się pytanie, jak tę politykę zapisać.

I właśnie tutaj często popełniany jest pierwszy błąd: administrator zaczyna od narzędzia zamiast od polityki.

UFW: kiedy prostota jest zaletą

UFW powstało właśnie po to, żeby podstawowa konfiguracja firewalla nie wymagała studiowania całej architektury Netfilter.

Jeżeli chcę osiągnąć prostą politykę:

ALLOW 22/tcp
ALLOW 443/tcp
DENY everything else

nie potrzebuję kilkudziesięciu linijek konfiguracji.

Wystarczy:

sudo ufw default deny incoming
sudo ufw default allow outgoing

sudo ufw allow 22/tcp
sudo ufw allow 443/tcp

sudo ufw enable

Stan sprawdzę:

sudo ufw status verbose

Ubuntu nadal dokumentuje UFW jako narzędzie przeznaczone do prostego zarządzania hostowym firewallem. Jednocześnie dokumentacja wyraźnie zaznacza, że UFW nie ma zastępować pełnego mechanizmu konfiguracji Netfilter w bardziej złożonych przypadkach.

I właśnie dlatego UFW jest interesujące.

Jego największą zaletą nie jest to, że potrafi zrobić coś, czego nie potrafi nftables.

Jego zaletą jest to, że administrator może szybko zrozumieć, co zrobił.

Ale prostota ma swoją cenę

Załóżmy teraz, że serwer przestaje być prostym serwerem WWW.

Pojawia się Docker.

Następnie VPN.

Potem routing pomiędzy interfejsami.

Dochodzi IPv6.

Administrator chce ograniczyć ruch na podstawie interfejsu, źródłowego adresu IP, stanu połączenia i kilku innych warunków.

Nagle prosty model:

allow port
deny port

przestaje wystarczać.

Nie dlatego, że UFW jest „słabe”.

Po prostu problem stał się bardziej złożony niż interfejs, dla którego UFW zostało zaprojektowane.

nftables zaczyna mieć wtedy sens

nftables działa na znacznie niższym poziomie abstrakcji.

Zamiast myśleć wyłącznie:

otwórz port 443

możemy opisywać bardziej precyzyjnie, jaki ruch ma przejść przez system i pod jakimi warunkami.

Przykładowa minimalistyczna konfiguracja może wyglądać tak:

table inet filter {

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

        iif lo accept

        ct state established,related accept

        tcp dport 22 accept
        tcp dport 443 accept
    }
}

Już tutaj widać jedną istotną różnicę.

nftables pozwala administratorowi bezpośrednio modelować reguły w strukturach tabel, łańcuchów i wyrażeń. Sam projekt Netfilter opisuje nftables jako nowoczesny framework filtrowania pakietów, obsługujący zarówno filtrowanie bezstanowe, jak i stanowe, IPv4, IPv6 oraz NAT.

To daje ogromne możliwości.

Ale jednocześnie wymaga większej wiedzy.

Najważniejsza różnica nie brzmi „prosty kontra profesjonalny”

To bardzo popularny mit.

UFW nie jest „firewallem dla początkujących”, którego administrator powinien się pozbyć po zdobyciu doświadczenia.

Tak samo nftables nie staje się automatycznie bezpieczniejsze tylko dlatego, że konfiguracja wygląda bardziej technicznie.

Prawdziwe pytanie brzmi:

Jak skomplikowana jest polityka sieciowa, którą musisz wdrożyć?

Jeżeli odpowiedź brzmi:

„Mam serwer SSH i Nginx.”

UFW może być absolutnie wystarczające.

Jeżeli odpowiedź brzmi:

„Mam kilka interfejsów, routing, kontenery, VPN, NAT, segmentację i niestandardowe reguły.”

Wtedy bezpośrednia praca z nftables zaczyna być znacznie bardziej naturalna.

A gdzie w tym wszystkim jest iptables?

Tutaj warto uporządkować jeszcze jedną rzecz.

iptables nie zniknęło z dnia na dzień. W wielu systemach nadal znajdziesz polecenia iptables, dokumentację oraz aplikacje, które ich używają.

Problem polega na tym, że Linux przeszedł w stronę nftables.

Dokumentacja nftables wskazuje wprost, że nowy kod powinien korzystać z nftables zamiast starszej infrastruktury xtables. Jednocześnie istnieje warstwa kompatybilności pozwalająca uruchamiać polecenia iptables poprzez nftables.

Dlatego dzisiaj można spotkać sytuację, która dla początkującego wygląda absurdalnie:

iptables
   |
   v
compatibility layer
   |
   v
nftables
   |
   v
Netfilter
   |
   v
Linux kernel

Polecenie może więc wyglądać jak stare iptables, podczas gdy pod spodem system korzysta z infrastruktury nftables.

To jeden z powodów, dla których bezrefleksyjne kopiowanie starych poradników może prowadzić do nieporozumień.

Firewall nie jest magiczną tarczą

Jest jeszcze ważniejsza kwestia.

Administrator może stworzyć perfekcyjną konfigurację firewalla, a mimo to zostawić system podatny na atak.

Załóżmy:

Internet
   |
Firewall
   |
Nginx :443
   |
Aplikacja
   |
PostgreSQL

Firewall może perfekcyjnie blokować PostgreSQL z Internetu.

Ale jeśli aplikacja ma podatność typu SQL injection, atakujący może dostać się do bazy przez legalny ruch HTTPS.

Firewall widzi:

TCP 443
ALLOW

Aplikacja widzi:

złośliwe żądanie

To fundamentalna granica.

Firewall kontroluje przede wszystkim komunikację, a nie poprawność działania aplikacji.

Dlatego hardening musi obejmować kolejne warstwy:

                Internet
                   |
                   v
              Firewall
                   |
                   v
              Web Server
                   |
                   v
              Application
                   |
                   v
                Database

Każda warstwa ma inne zadanie.

Najgorszy firewall to taki, którego nikt nie rozumie

Widziałem konfiguracje, w których administrator po kilku miesiącach nie wiedział już, dlaczego konkretna reguła istnieje.

To jest znacznie większy problem niż wybór pomiędzy UFW a nftables.

Firewall powinien być możliwy do odczytania.

Jeżeli po otwarciu konfiguracji nie potrafisz odpowiedzieć:

• co jest dostępne z Internetu,
• co jest dostępne tylko lokalnie,
• które interfejsy są chronione,
• co dzieje się z ruchem wychodzącym,
• jak traktowany jest IPv6,
• co dzieje się z forwardingiem,

to masz problem niezależnie od używanego narzędzia.

Jeden firewall, jedna polityka

W praktyce bardzo ważna jest jeszcze jedna zasada: nie należy bezmyślnie budować kilku niezależnych warstw konfiguracji, których relacji nie rozumiesz.

Ubuntu wskazuje obecnie możliwość korzystania z UFW, nftables oraz iptables, a CIS Ubuntu Linux również dopuszcza różne mechanizmy filtrowania w zależności od wybranego profilu i potrzeb środowiska.

Nie oznacza to jednak:

„Włącz wszystko naraz, będzie bezpieczniej.”

Wręcz przeciwnie.

Jeżeli masz UFW, ręcznie zmienione reguły nftables, reguły Dockera i dodatkowe skrypty modyfikujące Netfilter, musisz dokładnie wiedzieć, jak wszystkie te elementy współdziałają.

W przeciwnym razie firewall staje się czarną skrzynką.

Jak wybrałbym narzędzie w praktyce?

Nie robiłbym tabeli typu „UFW 8/10, nftables 10/10”.

To byłoby bez sensu.

Zamiast tego patrzyłbym na środowisko.

Domowy komputer lub prosty VPS: UFW jest bardzo rozsądnym wyborem. Możesz jasno określić, jakie usługi mają być dostępne i nie komplikować konfiguracji bez powodu.

Prosty serwer WWW: również UFW może być wystarczające. Jeżeli masz SSH i HTTP/HTTPS, nie ma nagrody za napisanie 150 linii nftables.

Serwer z bardziej rozbudowaną siecią: tutaj zaczyna wygrywać elastyczność nftables. Szczególnie gdy pojawiają się routing, wiele interfejsów, NAT, VPN, kontenery lub bardziej szczegółowe warunki filtrowania.

Router lub firewall Linux: bezpośrednia konfiguracja nftables staje się jeszcze bardziej naturalna, ponieważ system zaczyna pełnić funkcję urządzenia sieciowego, a nie tylko hosta.

Najważniejsze polecenie nie jest związane z żadnym z tych narzędzi

Jest nim:

ss -tulpn

Dlaczego?

Bo zanim napiszesz regułę firewalla, powinieneś wiedzieć, co właściwie próbujesz chronić.

Jeżeli zobaczysz:

0.0.0.0:22
0.0.0.0:80
0.0.0.0:443
0.0.0.0:5432

to problem nie polega wyłącznie na tym, jak zablokować port 5432.

Pytanie powinno brzmieć:

Dlaczego PostgreSQL w ogóle nasłuchuje na publicznym interfejsie?

Firewall może zamknąć drzwi.

Hardening powinien również sprawić, żeby niepotrzebnych drzwi nie było.

Firewall zaczyna się od architektury

To jest najważniejsza lekcja tego artykułu.

Nie zaczynaj od:

sudo apt install ufw

ani od:

sudo nft add table ...

Zacznij od narysowania przepływu ruchu.

                    INTERNET
                       |
                       v
                [ PUBLIC IP ]
                       |
                +------+------+
                |   FIREWALL |
                +------+------+
                       |
             +---------+---------+
             |                   |
             v                   v
          SSH :22             HTTPS :443
             |                   |
             v                   v
        ADMIN ACCESS        WEB SERVER
                                 |
                                 v
                              APP
                                 |
                                 v
                           DATABASE

Dopiero teraz można zdecydować, jak zapisać politykę.

To podejście jest znacznie bardziej uniwersalne niż pytanie:

„UFW czy nftables?”

Bo narzędzie jest implementacją polityki.

Polityka bezpieczeństwa jest ważniejsza od narzędzia, którym ją zapisujesz.

A co wybrałbym dzisiaj?

Dla prostego serwera Ubuntu zacząłbym od UFW i nie komplikowałbym sytuacji bez powodu.

Dla systemu, który pełni funkcję routera, firewalla, bramy VPN albo bardziej rozbudowanego hosta sieciowego, zainteresowałbym się bezpośrednią konfiguracją nftables.

Nie dlatego, że nftables jest „bardziej hakerskie”.

Dlatego, że kiedy rośnie złożoność sieci, potrzebujesz narzędzia, które pozwala opisać tę złożoność bez obchodzenia ograniczeń prostego interfejsu.

I właśnie tak powinien wyglądać wybór firewalla.

Nie:

„Które narzędzie jest bardziej profesjonalne?”

Tylko:

„Jaką politykę bezpieczeństwa muszę wdrożyć i które narzędzie pozwoli mi ją najczytelniej utrzymać?”

To pytanie jest znacznie trudniejsze.

Ale również znacznie bardziej użyteczne.

Przeczytaj również na Netbe.pl

Temat firewalla jest już mocno rozwinięty na Netbe, dlatego ten artykuł powinien działać jako część większego klastra, a nie jako kolejny identyczny poradnik konfiguracji:

• Firewall w Linuxie od podstaw do zaawansowanej konfiguracji — UFW, nftables, iptables — pełniejsze omówienie mechanizmów filtrowania i konfiguracji. (Netbe)
• Konfiguracja firewalla nftables na Linux – krok po kroku — praktyczna konfiguracja nftables. (Netbe)
• Konfiguracja firewalla UFW na Linux – krok po kroku — podstawowa konfiguracja UFW. (Netbe)
• Twarde zabezpieczanie Linuxa po instalacji – kompletny hardening serwera i desktopa — szerszy kontekst hardeningu Linuxa. (Netbe)
• Hardening Linuxa: Kompletny przewodnik po konfiguracji bezpieczeństwa serwerów i stacji roboczych — audyt, monitoring i izolacja usług. (Netbe)

Polecane wpisy

Jak skonfigurować serwer Samba w systemie Linux Debian

Jak skonfigurować serwer Samba w systemie Linux Debian Serwer Samba to popularne narzędzie umożliwiające udostępnianie plików i drukarek w sieci, Czytaj dalej

Fuzzing jądra Linuxa i modułów: techniki i narzędzia

Fuzzing jądra Linuxa i modułów: techniki i narzędzia Współczesny hacking defensywny i ofensywny nie może obyć się bez zaawansowanych technik Czytaj dalej