Wprowadzenie do Firewalld: Dynamiczne zarządzanie zaporą sieciową w Linux

Firewalld to demon zarządzania zaporą sieciową w przestrzeni użytkownika dla Linux, który zapewnia dynamiczny, oparty na strefach interfejs nad backendami filtrowania pakietów na poziomie jądra iptables i nftables. W przeciwieństwie do statycznych narzędzi zapory sieciowej, które wymagają pełnego restartu usługi w celu zastosowania zmian reguł, Firewalld modyfikuje reguły netfilter w locie — zachowując aktywne sesje TCP i eliminując przestoje podczas aktualizacji polityk.

Ten przewodnik obejmuje każdą warstwę operacyjną Firewalld: jego model architektoniczny, abstrakcje stref i usług, bogate reguły, konfigurację runtime w porównaniu z trwałą oraz dokładne polecenia potrzebne do bezpiecznego zarządzania serwerem produkcyjnym.

Dlaczego Firewalld zastąpił statyczne przepływy pracy iptables

Tradycyjne zarządzanie iptables oznacza zapisywanie reguł w skryptach powłoki lub płaskich plikach konfiguracyjnych, a następnie opróżnianie i przeładowywanie całego zestawu reguł za każdym razem, gdy potrzebna jest zmiana. Na zajętym serwerze ten cykl opróżniania i przeładowywania porzuca połączenia w trakcie transmisji i wprowadza krótkie okno, w którym żadne filtrowanie nie jest aktywne.

Firewalld rozwiązuje ten problem poprzez demon aktywowany przez D-Bus (firewalld), który przechowuje autorytatywny stan reguł i przekazuje zmiany do jądra przyrostowo. Rezultatem są atomowe aktualizacje reguł bez zakłócania połączeń — krytyczne dla każdego serwera obsługującego trwałe obciążenia, takie jak bazy danych, tunele VPN lub długotrwałe połączenia API.

Gdy konfigurujesz środowisko VPS Hosting i musisz je zabezpieczyć bez ponownego uruchamiania lub przerywania usług, Firewalld jest naturalnym wyborem operacyjnym w dystrybucjach z rodziny RHEL i wielu dystrybucjach z rodziny Debian.

Podstawowa architektura: jak Firewalld współdziała z jądrem

Zrozumienie stosu pod Firewalld zapobiega błędnej konfiguracji i pomaga debugować nieoczekiwane zachowanie.

User Space
┌─────────────────────────────────────────────┐
│ firewall-cmd / firewall-config / D-Bus API  │
└────────────────────┬────────────────────────┘
                     │ D-Bus
┌────────────────────▼────────────────────────┐
│              firewalld daemon               │
│  (zone engine, service definitions, rich    │
│   rule parser, direct rule passthrough)     │
└────────────────────┬────────────────────────┘
                     │ nftables / iptables backend
Kernel Space
┌────────────────────▼────────────────────────┐
│           netfilter (kernel module)         │
└─────────────────────────────────────────────┘

Od RHEL 8 i Fedora 32, Firewalld domyślnie używa backendu nftables. W starszych systemach lub jawnie skonfigurowanych środowiskach używa backendu iptables. Możesz sprawdzić lub nadpisać aktywny backend w /etc/firewalld/firewalld.conf za pomocą dyrektywy FirewallBackend.

Krytyczna pułapka: Nigdy nie mieszaj bezpośrednich poleceń iptables lub nft z Firewalld na tym samym interfejsie. Firewalld jest właścicielem tworzonych przez siebie tabel netfilter; reguły ręcznie wstawione poza demonem zostaną po cichu nadpisane przy następnym przeładowaniu.

Kluczowe koncepcje w Firewalld

Strefy

Strefa to nazwany poziom zaufania stosowany do interfejsu sieciowego lub zakresu adresów źródłowych. Każdy pakiet wchodzący do systemu jest dopasowywany do strefy przypisanej do jego interfejsu wejściowego, a zestaw reguł strefy określa, co jest dozwolone.

Firewalld jest dostarczany z następującymi predefiniowanymi strefami, uporządkowanymi od najbardziej do najmniej permisywnych:

Niuans architektoniczny: Strefa może być powiązana z interfejsem sieciowym (np. eth0) lub ze źródłowym CIDR (np. 192.168.1.0/24). Powiązanie oparte na źródle ma pierwszeństwo przed powiązaniem opartym na interfejsie, co pozwala stosować różne polityki do ruchu przychodzącego na tym samym fizycznym interfejsie z różnych podsieci — wzorzec powszechny w środowiskach wielodostępnych lub konteneryzowanych.

Usługi

Usługa w Firewalld to plik definicji XML przechowywany w /usr/lib/firewalld/services/ (domyślne systemowe) lub /etc/firewalld/services/ (nadpisania użytkownika). Każdy plik deklaruje porty, protokoły i opcjonalne moduły pomocnicze wymagane dla nazwanej aplikacji.

Na przykład definicja usługi https otwiera port TCP 443 i nie ładuje żadnych dodatkowych pomocników jądra. Usługa ftp otwiera port TCP 21 i ładuje pomocnik nf_conntrack_ftp do obsługi dynamicznej negocjacji portów kanału danych FTP.

Używanie nazw usług zamiast surowych numerów portów sprawia, że polityka zapory sieciowej jest samodokumentująca się i zmniejsza ryzyko literówek, które pozostawiają port nieumyślnie otwarty lub zamknięty.

Aby wyświetlić listę wszystkich dostępnych definicji usług w systemie:

firewall-cmd --get-services

Aby sprawdzić definicję XML konkretnej usługi:

cat /usr/lib/firewalld/services/https.xml

Bogate reguły

Bogate reguły rozszerzają model stref o logikę warunkową, której prosta abstrakcja usług/portów nie może wyrazić. Obsługują dopasowywanie na podstawie adresów źródłowych i docelowych, zakresów portów, protokołów, okien czasowych i stanu połączenia, a mogą wyzwalać akcje, w tym accept, drop, reject, log i audit.

Składnia bogatych reguł podąża za ustrukturyzowaną gramatyką:

rule [family="ipv4|ipv6"]
  [source address="addr[/mask]" [invert="true"]]
  [destination address="addr[/mask]" [invert="true"]]
  [service name="service-name"] | [port port="port" protocol="tcp|udp"]
  [log [prefix="prefix"] [level="level"] [limit value="rate/duration"]]
  [audit]
  [accept|drop|reject [type="reject-type"]]

Praktyczny przykład — ograniczenie prób logowania SSH do 3 na minutę z dowolnego pojedynczego źródła IPv4, a następnie rejestrowanie i porzucanie nadmiaru:

firewall-cmd --zone=public --add-rich-rule='
  rule family="ipv4"
  service name="ssh"
  log prefix="SSH_RATELIMIT " level="warning" limit value="3/m"
  accept' --permanent

firewall-cmd --zone=public --add-rich-rule='
  rule family="ipv4"
  service name="ssh"
  drop' --permanent

Przypadek brzegowy: Kolejność bogatych reguł ma znaczenie. Firewalld ocenia bogate reguły w kolejności, w jakiej zostały dodane w strefie. Jeśli dodasz szeroką regułę drop przed konkretną regułą accept, reguła accept nigdy nie zostanie osiągnięta. Zawsze najpierw dodawaj bardziej szczegółowe reguły.

Konfiguracja runtime a trwała

To jest najważniejsze operacyjnie rozróżnienie w Firewalld i źródło najczęstszych błędów produkcyjnych.

Najlepszy przepływ pracy dla zmian produkcyjnych:

1. Zastosuj regułę tylko w runtime (bez flagi --permanent) i sprawdź, czy działa zgodnie z oczekiwaniami.
2. Jeśli jest poprawna, zastosuj tę samą regułę z --permanent, aby zapisać ją na dysku.
3. Uruchom firewall-cmd --reload, aby zsynchronizować trwałą konfigurację ze stanem runtime i potwierdzić parytet.

Ten przepływ pracy zapobiega klasycznemu scenariuszowi, w którym administrator dodaje regułę --permanent, przeładowuje i odkrywa, że zablokował sobie dostęp do SSH — ponieważ test runtime ujawniłby problem, zanim stałby się trwały.

Instalacja i włączanie Firewalld

Firewalld jest instalowany domyślnie na RHEL, CentOS Stream, Fedora, AlmaLinux i Rocky Linux. Na Debian i Ubuntu musi być zainstalowany jawnie.

RHEL / CentOS Stream / AlmaLinux / Rocky Linux:

sudo dnf install firewalld

Debian / Ubuntu:

sudo apt-get update && sudo apt-get install firewalld

Uwaga dla użytkowników Ubuntu: Jeśli ufw jest aktywny, wyłącz go przed włączeniem Firewalld, aby uniknąć konfliktujących reguł netfilter:

sudo ufw disable
sudo systemctl disable ufw

Uruchom i włącz demona:

sudo systemctl start firewalld
sudo systemctl enable firewalld

Sprawdź, czy demon działa i backend jądra jest aktywny:

sudo firewall-cmd --state
sudo firewall-cmd --info-zone=public

Podstawowe polecenia Firewalld

Sprawdzanie bieżącego stanu

Sprawdź status demona:

sudo firewall-cmd --state

Wyświetl listę wszystkich aktywnych stref z przypisanymi interfejsami i źródłami:

sudo firewall-cmd --get-active-zones

Wyświetl kompletny zestaw reguł dla konkretnej strefy:

sudo firewall-cmd --zone=public --list-all

Wyświetl kompletny zestaw reguł dla wszystkich stref jednocześnie:

sudo firewall-cmd --list-all-zones

Zarządzanie domyślną strefą

Domyślna strefa jest stosowana do każdego interfejsu, który nie jest jawnie przypisany do innej strefy:

sudo firewall-cmd --get-default-zone
sudo firewall-cmd --set-default-zone=public

Przypisywanie interfejsu do strefy

sudo firewall-cmd --zone=internal --change-interface=eth1 --permanent
sudo firewall-cmd --reload

Pułapka: W systemach używających NetworkManager, przypisania interfejsów do stref dokonane przez firewall-cmd mogą być nadpisane przez profil połączenia NetworkManager przy ponownym połączeniu. Ustaw strefę trwale w połączeniu NetworkManager:

nmcli connection modify "Wired connection 1" connection.zone internal

Dodawanie i usuwanie usług

Zezwól na HTTP w strefie publicznej w runtime:

sudo firewall-cmd --zone=public --add-service=http

Uczyń to trwałym:

sudo firewall-cmd --zone=public --add-service=http --permanent

Usuń usługę:

sudo firewall-cmd --zone=public --remove-service=http --permanent

Otwieranie i zamykanie konkretnych portów

Otwórz port TCP 8080 w runtime:

sudo firewall-cmd --zone=public --add-port=8080/tcp

Otwórz zakres portów UDP trwale:

sudo firewall-cmd --zone=public --add-port=60000-61000/udp --permanent

Usuń port:

sudo firewall-cmd --zone=public --remove-port=8080/tcp --permanent

Listy dozwolonych i zablokowanych adresów IP

Zezwól na cały ruch z zaufanej podsieci zarządzania:

sudo firewall-cmd --zone=trusted --add-source=10.0.0.0/24 --permanent

Zablokuj cały ruch z konkretnego IP (porzucanie oparte na źródle):

sudo firewall-cmd --zone=drop --add-source=203.0.113.45/32 --permanent

Przekierowanie portów

Przekieruj zewnętrzny port TCP 2222 do wewnętrznego portu SSH 22 (przydatne do ukrywania domyślnego portu SSH bez zmiany sshd_config):

sudo firewall-cmd --zone=public --add-forward-port=port=2222:proto=tcp:toport=22 --permanent
sudo firewall-cmd --reload

Maskarada IP (NAT)

Włącz maskaradę w strefie zewnętrznej, aby umożliwić VPS działającemu jako brama NAT ruch z prywatnej podsieci:

sudo firewall-cmd --zone=external --add-masquerade --permanent
sudo firewall-cmd --reload

Przeładowanie i synchronizacja konfiguracji

Zastosuj wszystkie trwałe zmiany do działającego stanu bez przerywania połączeń:

sudo firewall-cmd --reload

Wykonaj pełny restart (porzuca wszystkie połączenia — używaj tylko w nagłych przypadkach):

sudo systemctl restart firewalld

Tworzenie niestandardowych stref i definicji usług

Niestandardowa strefa

sudo firewall-cmd --new-zone=management --permanent
sudo firewall-cmd --zone=management --add-source=10.10.0.0/16 --permanent
sudo firewall-cmd --zone=management --add-service=ssh --permanent
sudo firewall-cmd --zone=management --add-service=cockpit --permanent
sudo firewall-cmd --reload

Niestandardowa definicja usługi

Utwórz plik usługi dla niestandardowej aplikacji nasłuchującej na TCP 9200 (np. Elasticsearch):

sudo nano /etc/firewalld/services/elasticsearch.xml

<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>Elasticsearch</short>
  <description>Elasticsearch HTTP API and transport port</description>
  <port protocol="tcp" port="9200"/>
  <port protocol="tcp" port="9300"/>
</service>

sudo firewall-cmd --reload
sudo firewall-cmd --zone=internal --add-service=elasticsearch --permanent
sudo firewall-cmd --reload

Firewalld a alternatywy: wybór odpowiedniego narzędzia

Dla zespołów zarządzających Serwerami Dedykowanymi na dużą skalę, API D-Bus Firewalld umożliwia programowe zarządzanie regułami z narzędzi do zarządzania konfiguracją, takich jak Ansible (moduł ansible.posix.firewalld) lub Puppet, co jest znaczącą przewagą operacyjną nad utrzymywaniem surowych skryptów iptables.

Praktyczne wzorce utwardzania bezpieczeństwa

Zabezpieczanie serwera WWW

Typowa konfiguracja dla serwera obsługującego HTTPS z SSH ograniczonym do IP zarządzania:

# Set the default zone
sudo firewall-cmd --set-default-zone=public --permanent

# Allow HTTPS globally
sudo firewall-cmd --zone=public --add-service=https --permanent

# Allow HTTP only to redirect to HTTPS (optional)
sudo firewall-cmd --zone=public --add-service=http --permanent

# Restrict SSH to a specific management IP only
sudo firewall-cmd --zone=public --remove-service=ssh --permanent
sudo firewall-cmd --zone=public --add-rich-rule='
  rule family="ipv4"
  service name="ssh"
  source address="198.51.100.10/32"
  accept' --permanent

sudo firewall-cmd --reload

Jeśli uruchamiasz serwer WWW wraz z wdrożeniem Certyfikatów SSL, upewnienie się, że port 443 jest otwarty w odpowiedniej strefie przed wystawieniem certyfikatu (szczególnie dla wyzwań ACME HTTP-01 lub TLS-ALPN-01) jest krokiem wstępnym, który jest często pomijany.

Ochrona serwera pocztowego

Dla serwerów obsługujących stosy Hostingu Poczty E-mail (Postfix, Dovecot), wymagany zestaw usług to:

sudo firewall-cmd --zone=public --add-service=smtp --permanent
sudo firewall-cmd --zone=public --add-service=smtps --permanent
sudo firewall-cmd --zone=public --add-service=imap --permanent
sudo firewall-cmd --zone=public --add-service=imaps --permanent
sudo firewall-cmd --zone=public --add-service=pop3s --permanent
sudo firewall-cmd --reload

Rejestrowanie porzuconych pakietów dla celów kryminalistycznych

sudo firewall-cmd --zone=public --add-rich-rule='
  rule family="ipv4"
  log prefix="DROPPED_PUBLIC " level="warning" limit value="10/m"
  drop' --permanent
sudo firewall-cmd --reload

Logi pojawiają się w /var/log/messages lub dzienniku systemd (journalctl -k -g DROPPED_PUBLIC). Ogranicz częstotliwość logowania (jak pokazano powyżej), aby zapobiec zalewaniu logów w scenariuszu DDoS.

Firewalld na VPS zarządzanym przez cPanel

Jeśli używasz VPS z cPanel, pamiętaj, że cPanel instaluje i zarządza własną warstwą zapory sieciowej (domyślnie CSF/LFD). Uruchamianie Firewalld obok CSF bez jawnej koordynacji spowoduje konfliktujące reguły netfilter. Zalecanym podejściem jest wybranie jednej warstwy zarządzania zaporą sieciową na serwer i wyłączenie drugiej, lub użycie interfejsu bezpośredniego przekazywania reguł Firewalld do integracji z wymaganiami cPanel.

Rozwiązywanie typowych problemów z Firewalld

Problem: Reguła dodana z --permanent nie jest w mocy.

Przyczyna: Trwałe reguły wymagają przeładowania, aby wejść w stan runtime.

Rozwiązanie:

sudo firewall-cmd --reload

Problem: Połączenie SSH zostało przerwane po zmianie zapory sieciowej.

Przyczyna: Usługa SSH została usunięta z aktywnej strefy lub reguła bogate drop została dodana przed regułą accept.

Rozwiązanie: Uzyskaj dostęp do serwera przez konsolę out-of-band (konsola VNC/KVM dostawcy hostingu), a następnie przywróć usługę SSH:

sudo firewall-cmd --zone=public --add-service=ssh --permanent
sudo firewall-cmd --reload

Problem: firewall-cmd zwraca FirewallD is not running.

Przyczyna: Demon uległ awarii lub nigdy nie został uruchomiony.

Rozwiązanie:

sudo systemctl start firewalld
sudo journalctl -u firewalld -n 50

Problem: Reguły wyglądają poprawnie, ale ruch jest nadal blokowany.

Przyczyna: Istnieje konfliktująca reguła iptables lub nft poza zarządzanymi tabelami Firewalld, lub SELinux/AppArmor blokuje połączenie na warstwie aplikacji.

Rozwiązanie: Sprawdź ręczne reguły i odmowy SELinux:

sudo iptables -L -n -v
sudo ausearch -m avc -ts recent

Problem: Interfejs nie jest przypisany do oczekiwanej strefy po ponownym uruchomieniu.

Przyczyna: Profil połączenia NetworkManager nadpisuje przypisanie interfejsu Firewalld.

Rozwiązanie: Ustaw strefę w profilu NetworkManager, jak opisano w sekcji przypisywania interfejsów powyżej.

Macierz decyzyjna i lista kontrolna techniczna

Użyj tej listy kontrolnej przed wdrożeniem Firewalld na serwerze produkcyjnym:

• Potwierdź aktywny backend zapory sieciowej (FirewallBackend w /etc/firewalld/firewalld.conf) odpowiada obsłudze nftables/iptables przez jądro.
• Sprawdź, czy żadne konfliktujące narzędzia zapory sieciowej (UFW, CSF, bezpośrednie skrypty iptables) nie są aktywne na tych samych interfejsach.
• Przypisz każdy interfejs sieciowy jawnie do strefy — nigdy nie polegaj wyłącznie na domyślnej strefie dla serwerów wieloadresowych.
• Najpierw zastosuj wszystkie zmiany w runtime, sprawdź łączność, a następnie zatwierdź z --permanent i --reload.
• Ogranicz dostęp SSH do konkretnych źródłowych IP za pomocą bogatych reguł przed usunięciem usługi SSH ze strefy publicznej.
• Dodaj bogate reguły ograniczające częstotliwość dla wszystkich publicznie dostępnych usług uwierzytelniania (SSH, SMTP, punkty końcowe logowania HTTPS).
• Włącz rejestrowanie dla strefy drop z limitem częstotliwości, aby przechwytywać informacje o zagrożeniach bez zalewania pamięci masowej.
• Dla serwerów zarządzanych przez Panele Sterowania VPS, potwierdź, że wymagane porty panelu sterowania są na białej liście przed zastosowaniem restrykcyjnej domyślnej polityki.
• Przetestuj trwałą konfigurację, uruchamiając firewall-cmd --reload i natychmiast sprawdzając, czy wszystkie krytyczne usługi pozostają dostępne.
• Dokumentuj każdą niestandardową strefę, bogatą regułę i definicję usługi w kontroli wersji obok kodu infrastruktury.

FAQ

Jaka jest różnica między --reload a sudo systemctl restart firewalld?

--reload stosuje trwałe zmiany konfiguracji do działającego demona bez przerywania nawiązanych połączeń. systemctl restart w pełni restartuje proces demona, co opróżnia wszystkie reguły netfilter i krótko przerywa aktywne połączenia. Zawsze preferuj --reload w systemach produkcyjnych.

Czy Firewalld i iptables mogą współistnieć na tym samym serwerze?

Nie bezpiecznie na tym samym interfejsie. Firewalld zarządza własnymi łańcuchami netfilter; bezpośrednie polecenia iptables modyfikujące te same łańcuchy zostaną nadpisane przy następnym przeładowaniu Firewalld. Jeśli musisz wstrzyknąć niestandardowe reguły, użyj zamiast tego interfejsu --direct Firewalld lub bogatych reguł.

Jak uczynić regułę runtime trwałą bez jej ponownego wpisywania?

Nie ma wbudowanego polecenia do promowania wszystkich reguł runtime do trwałych w jednym kroku. Prawidłowy przepływ pracy polega na dwukrotnym zastosowaniu każdej reguły — raz bez --permanent do testowania, a następnie z --permanent dla trwałości — a następnie --reload. Alternatywnie użyj firewall-cmd --runtime-to-permanent (dostępnego w Firewalld 0.9+), aby wykonać migawkę bieżącego stanu runtime na dysk.

Dlaczego moje przypisanie strefy jest resetowane po ponownym połączeniu NetworkManager?

NetworkManager przechowuje przypisania stref we własnych profilach połączeń. Przypisanie firewall-cmd --change-interface to nadpisanie runtime, które NetworkManager może nadpisać. Utrwal przypisanie za pomocą nmcli connection modify <profile-name> connection.zone <zone>.

Czy Firewalld obsługuje IPv6?

Tak. Firewalld zarządza jednocześnie regułami netfilter IPv4 i IPv6. Bogate reguły wymagają atrybutu family="ipv6" do konkretnego targetowania ruchu IPv6. Reguły stref i usług domyślnie stosują się do obu rodzin adresów, chyba że definicja usługi lub bogata reguła ogranicza zakres.