O Introducere în Firewalld: Managementul Dinamic al Firewall-ului pe Linux

Firewalld este un daemon de gestionare a firewall-ului în spațiul utilizatorului pentru Linux, care oferă o interfață dinamică bazată pe zone peste backend-urile de filtrare a pachetelor la nivel de kernel iptables și nftables. Spre deosebire de instrumentele statice de firewall care necesită o repornire completă a serviciului pentru a aplica modificările regulilor, Firewalld modifică regulile netfilter din mers — păstrând sesiunile TCP active și eliminând timpul de nefuncționare în timpul actualizărilor de politici.

Acest ghid acoperă fiecare nivel operațional al Firewalld: modelul său arhitectural, abstractizările de zone și servicii, regulile complexe, configurația runtime față de cea permanentă și comenzile exacte de care aveți nevoie pentru a gestiona un server de producție în mod securizat.

De ce Firewalld a înlocuit fluxurile de lucru statice iptables

Gestionarea tradițională a iptables înseamnă scrierea regulilor în scripturi shell sau fișiere de configurare plate, apoi golirea și reîncărcarea întregului set de reguli ori de câte ori este necesară o modificare. Pe un server aglomerat, ciclul de golire și reîncărcare întrerupe conexiunile în curs și introduce o fereastră scurtă în care nu este activă nicio filtrare.

Firewalld rezolvă această problemă printr-un daemon activat prin D-Bus (firewalld) care deține starea autoritativă a regulilor și comunică modificările către kernel în mod incremental. Rezultatul este actualizări atomice ale regulilor fără nicio întrerupere a conexiunilor — esențial pentru orice server care rulează sarcini de lucru persistente, cum ar fi baze de date, tuneluri VPN sau conexiuni API de lungă durată.

Când provizionați un mediu de VPS Hosting și trebuie să îl securizați fără a reporni sau a întrerupe serviciile, Firewalld este alegerea operațională naturală pe distribuțiile din familia RHEL și pe multe distribuții din familia Debian.

Arhitectura de bază: Cum interacționează Firewalld cu kernel-ul

Înțelegerea stivei de sub Firewalld previne configurările greșite și vă ajută să depanați comportamentul neașteptat.

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)         │
└─────────────────────────────────────────────┘

Începând cu RHEL 8 și Fedora 32, Firewalld utilizează implicit backend-ul nftables. Pe sisteme mai vechi sau în medii configurate explicit, folosește backend-ul iptables. Puteți inspecta sau suprascrie backend-ul activ în /etc/firewalld/firewalld.conf prin directiva FirewallBackend.

Capcană critică: Nu amestecați niciodată comenzile directe iptables sau nft cu Firewalld pe aceeași interfață. Firewalld deține tabelele netfilter pe care le creează; regulile manuale inserate în afara daemon-ului vor fi suprascrise silențios la următoarea reîncărcare.

Concepte cheie în Firewalld

Zone

O zonă este un nivel de încredere denumit, aplicat unei interfețe de rețea sau unui interval de adrese sursă. Fiecare pachet care intră în sistem este comparat cu zona atribuită interfeței sale de intrare, iar setul de reguli al zonei determină ce este permis.

Firewalld vine cu următoarele zone predefinite, ordonate de la cea mai permisivă la cea mai puțin permisivă:

Nuanță arhitecturală: O zonă poate fi legată de o interfață de rețea (de ex., eth0) sau de un CIDR sursă (de ex., 192.168.1.0/24). Legarea bazată pe sursă are prioritate față de legarea bazată pe interfață, ceea ce vă permite să aplicați politici diferite traficului care sosește pe aceeași interfață fizică din subrețele diferite — un model comun în mediile multi-tenant sau containerizate.

Servicii

Un serviciu în Firewalld este un fișier de definiție XML stocat în /usr/lib/firewalld/services/ (valori implicite ale sistemului) sau /etc/firewalld/services/ (suprascrieri ale utilizatorului). Fiecare fișier declară porturile, protocoalele și modulele helper opționale necesare pentru o aplicație denumită.

De exemplu, definiția serviciului https deschide portul TCP 443 și nu încarcă niciun helper suplimentar de kernel. Serviciul ftp deschide portul TCP 21 și încarcă helper-ul nf_conntrack_ftp pentru a gestiona negocierea portului dinamic al canalului de date FTP.

Utilizarea numelor de servicii în loc de numere brute de porturi face ca politica dvs. de firewall să fie auto-documentată și reduce riscul de greșeli de tastare care lasă un port deschis sau închis neintenționat.

Pentru a lista toate definițiile de servicii disponibile pe sistemul dvs.:

firewall-cmd --get-services

Pentru a inspecta definiția XML a unui serviciu specific:

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

Reguli complexe

Regulile complexe extind modelul de zone cu logică condiționată pe care abstracția simplă serviciu/port nu o poate exprima. Acestea suportă potrivirea pe adrese sursă și destinație, intervale de porturi, protocoale, ferestre de timp și starea conexiunii, și pot declanșa acțiuni incluzând accept, drop, reject, log și audit.

Sintaxa regulilor complexe urmează o gramatică structurată:

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"]]

Un exemplu practic — limitarea ratei încercărilor de autentificare SSH la 3 pe minut din orice sursă IPv4 unică, apoi înregistrarea și eliminarea excesului:

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

Caz limită: Ordinea regulilor complexe contează. Firewalld evaluează regulile complexe în ordinea în care au fost adăugate într-o zonă. Dacă adăugați o regulă largă drop înaintea unei reguli specifice accept, regula accept nu va fi niciodată atinsă. Adăugați întotdeauna mai întâi regulile mai specifice.

Configurație runtime vs. permanentă

Aceasta este cea mai importantă distincție operațională în Firewalld și sursa celor mai frecvente greșeli în producție.

Flux de lucru recomandat pentru modificările în producție:

1. Aplicați regula doar la runtime (fără indicatorul --permanent) și verificați că se comportă conform așteptărilor.
2. Dacă este corectă, aplicați aceeași regulă cu --permanent pentru a o scrie pe disc.
3. Rulați firewall-cmd --reload pentru a sincroniza configurația permanentă în starea runtime și a confirma paritatea.

Acest flux de lucru previne scenariul clasic în care un administrator adaugă o regulă --permanent, reîncarcă și descoperă că s-a blocat din SSH — deoarece testul runtime ar fi dezvăluit problema înainte de a deveni permanentă.

Instalarea și activarea Firewalld

Firewalld este instalat implicit pe RHEL, CentOS Stream, Fedora, AlmaLinux și Rocky Linux. Pe Debian și Ubuntu trebuie instalat explicit.

RHEL / CentOS Stream / AlmaLinux / Rocky Linux:

sudo dnf install firewalld

Debian / Ubuntu:

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

Notă pentru utilizatorii Ubuntu: Dacă ufw este activ, dezactivați-l înainte de a activa Firewalld pentru a evita conflictele de reguli netfilter:

sudo ufw disable
sudo systemctl disable ufw

Porniți și activați daemon-ul:

sudo systemctl start firewalld
sudo systemctl enable firewalld

Verificați că daemon-ul rulează și că backend-ul kernel este activ:

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

Comenzi esențiale Firewalld

Inspectarea stării curente

Verificați starea daemon-ului:

sudo firewall-cmd --state

Listați toate zonele active cu interfețele și sursele lor atribuite:

sudo firewall-cmd --get-active-zones

Afișați setul complet de reguli pentru o zonă specifică:

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

Afișați setul complet de reguli pentru toate zonele simultan:

sudo firewall-cmd --list-all-zones

Gestionarea zonei implicite

Zona implicită este aplicată oricărei interfețe neatribuite explicit altei zone:

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

Atribuirea unei interfețe la o zonă

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

Capcană: Pe sistemele care utilizează NetworkManager, atribuirile interfață-zonă efectuate prin firewall-cmd pot fi suprascrise de profilul de conexiune NetworkManager la reconectare. Setați zona persistent în conexiunea NetworkManager:

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

Adăugarea și eliminarea serviciilor

Permiteți HTTP în zona publică la runtime:

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

Faceți-l permanent:

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

Eliminați un serviciu:

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

Deschiderea și închiderea porturilor specifice

Deschideți portul TCP 8080 la runtime:

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

Deschideți un interval de porturi UDP permanent:

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

Eliminați un port:

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

Lista albă și lista neagră pentru adrese IP

Permiteți tot traficul dintr-o subrețea de management de încredere:

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

Blocați tot traficul de la un IP specific (eliminare bazată pe sursă):

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

Redirecționarea porturilor

Redirecționați portul TCP extern 2222 către portul SSH intern 22 (util pentru ascunderea portului SSH implicit fără a modifica sshd_config):

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

Masquerade IP (NAT)

Activați masquerade pe zona externă pentru a permite unui VPS care acționează ca gateway să efectueze NAT pentru traficul dintr-o subrețea privată:

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

Reîncărcarea și sincronizarea configurației

Aplicați toate modificările permanente la starea de rulare fără a întrerupe conexiunile:

sudo firewall-cmd --reload

Efectuați o repornire completă (întrerupe toate conexiunile — utilizați doar în situații de urgență):

sudo systemctl restart firewalld

Crearea de zone și definiții de servicii personalizate

Zonă personalizată

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

Definiție de serviciu personalizată

Creați un fișier de serviciu pentru o aplicație personalizată care ascultă pe TCP 9200 (de ex., 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 vs. alternative: Alegerea instrumentului potrivit

Pentru echipele care gestionează Servere Dedicate la scară, API-ul D-Bus al Firewalld permite gestionarea programatică a regulilor din instrumente de gestionare a configurației precum Ansible (modulul ansible.posix.firewalld) sau Puppet, ceea ce reprezintă un avantaj operațional semnificativ față de menținerea scripturilor brute iptables.

Modele practice de securizare

Securizarea unui server web

O configurație tipică pentru un server care rulează HTTPS cu SSH restricționat la un IP de management:

# 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

Dacă rulați un server web alături de o implementare de Certificate SSL, asigurarea că portul 443 este deschis în zona corectă înainte de emiterea certificatului (în special pentru provocările ACME HTTP-01 sau TLS-ALPN-01) este un pas prealabil care este frecvent trecut cu vederea.

Protejarea unui server de mail

Pentru serverele care rulează stive de Email Hosting (Postfix, Dovecot), setul de servicii necesar este:

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

Înregistrarea pachetelor eliminate pentru criminalistică

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

Jurnalele apar în /var/log/messages sau în jurnalul systemd (journalctl -k -g DROPPED_PUBLIC). Limitați rata de înregistrare (după cum se arată mai sus) pentru a preveni inundarea jurnalelor în scenariul unui atac DDoS.

Firewalld pe VPS gestionat cu cPanel

Dacă utilizați un VPS cu cPanel, rețineți că cPanel instalează și gestionează propriul strat de firewall (CSF/LFD implicit). Rularea Firewalld alături de CSF fără o coordonare explicită va produce reguli netfilter conflictuale. Abordarea recomandată este să alegeți un singur strat de gestionare a firewall-ului per server și să îl dezactivați pe celălalt, sau să utilizați interfața de trecere directă a regulilor Firewalld pentru a se integra cu cerințele cPanel.

Depanarea problemelor comune Firewalld

Problemă: Regula adăugată cu --permanent nu este în vigoare.

Cauză: Regulile permanente necesită o reîncărcare pentru a intra în starea runtime.

Soluție:

sudo firewall-cmd --reload

Problemă: Conexiunea SSH a fost întreruptă după modificarea firewall-ului.

Cauză: Serviciul SSH a fost eliminat din zona activă, sau o regulă complexă drop a fost adăugată înaintea regulii accept.

Soluție: Accesați serverul prin consola out-of-band (consola VNC/KVM a furnizorului dvs. de hosting), apoi restaurați serviciul SSH:

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

Problemă: firewall-cmd returnează FirewallD is not running.

Cauză: Daemon-ul s-a blocat sau nu a fost niciodată pornit.

Soluție:

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

Problemă: Regulile par corecte, dar traficul este în continuare blocat.

Cauză: Există o regulă conflictuală iptables sau nft în afara tabelelor gestionate de Firewalld, sau SELinux/AppArmor blochează conexiunea la nivelul aplicației.

Soluție: Verificați regulile manuale și refuzurile SELinux:

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

Problemă: Interfața nu este atribuită zonei așteptate după repornire.

Cauză: Profilul de conexiune NetworkManager suprascrie atribuirea interfeței de către Firewalld.

Soluție: Setați zona în profilul NetworkManager după cum este descris în secțiunea de atribuire a interfeței de mai sus.

Matrice de decizie și listă de verificare tehnică

Utilizați această listă de verificare înainte de a implementa Firewalld pe un server de producție:

• Confirmați că backend-ul activ de firewall (FirewallBackend în /etc/firewalld/firewalld.conf) corespunde suportului nftables/iptables al kernel-ului dvs.
• Verificați că niciun instrument de firewall conflictual (UFW, CSF, scripturi directe iptables) nu este activ pe aceleași interfețe.
• Atribuiți explicit fiecare interfață de rețea unei zone — nu vă bazați exclusiv pe zona implicită pentru serverele cu mai multe interfețe.
• Aplicați toate modificările la runtime mai întâi, verificați conectivitatea, apoi confirmați cu --permanent și --reload.
• Restricționați accesul SSH la IP-uri sursă specifice prin reguli complexe înainte de a elimina serviciul SSH din zona publică.
• Adăugați reguli complexe de limitare a ratei pentru toate serviciile de autentificare expuse public (SSH, SMTP, endpoint-uri de autentificare HTTPS).
• Activați înregistrarea pentru zona drop cu o limită de rată pentru a capta informații despre amenințări fără a inunda stocarea.
• Pentru serverele gestionate prin Panouri de Control VPS, confirmați că porturile necesare ale panoului de control sunt pe lista albă înainte de a aplica o politică implicită restrictivă.
• Testați configurația permanentă rulând firewall-cmd --reload și verificând imediat că toate serviciile critice rămân accesibile.
• Documentați fiecare zonă personalizată, regulă complexă și definiție de serviciu în controlul versiunilor alături de codul dvs. de infrastructură.

Întrebări frecvente

Care este diferența dintre --reload și sudo systemctl restart firewalld?

--reload aplică modificările de configurație permanente la daemon-ul în execuție fără a întrerupe conexiunile stabilite. systemctl restart repornește complet procesul daemon, ceea ce golește toate regulile netfilter și întrerupe temporar conexiunile active. Preferați întotdeauna --reload pe sistemele de producție.

Pot coexista Firewalld și iptables pe același server?

Nu în mod sigur pe aceeași interfață. Firewalld gestionează propriile lanțuri netfilter; comenzile directe iptables care modifică aceleași lanțuri vor fi suprascrise la următoarea reîncărcare Firewalld. Dacă trebuie să injectați reguli personalizate, utilizați în schimb interfața --direct a Firewalld sau regulile complexe.

Cum fac o regulă runtime permanentă fără a o retasta?

Nu există o comandă încorporată pentru a promova toate regulile runtime la permanente într-un singur pas. Fluxul de lucru corect este să aplicați fiecare regulă de două ori — o dată fără --permanent pentru testare, apoi cu --permanent pentru persistență — urmat de --reload. Alternativ, utilizați firewall-cmd --runtime-to-permanent (disponibil în Firewalld 0.9+) pentru a salva starea runtime curentă pe disc.

De ce atribuirea zonei mele este resetată după o reconectare NetworkManager?

NetworkManager stochează atribuirile de zone în propriile profiluri de conexiune. O atribuire firewall-cmd --change-interface este o suprascriere runtime pe care NetworkManager o poate suprascrie. Persistați atribuirea cu nmcli connection modify <profile-name> connection.zone <zone>.

Firewalld suportă IPv6?

Da. Firewalld gestionează simultan regulile netfilter IPv4 și IPv6. Regulile complexe necesită atributul family="ipv6" pentru a viza specific traficul IPv6. Regulile de zonă și servicii se aplică ambelor familii de adrese în mod implicit, cu excepția cazului în care definiția serviciului sau regula complexă restricționează domeniul de aplicare.