Firewalld basics sa Rocky o AlmaLinux VPS

Ano ang firewalld at kung bakit kasama ito sa Rocky at AlmaLinux

Ang firewalld ang firewall manager na naka-install bilang default sa Rocky Linux, AlmaLinux, at iba pang rebuild ng Red Hat Enterprise Linux (RHEL). Namana ng dalawang distribution ang default na ito sa halip na sila ang pumili nito. Mas mauunawaan ito kapag alam mo na kung paano ipinagpatuloy ng Rocky at AlmaLinux ang pagre-rebuild sa gawa ng Red Hat matapos magbago ng direksiyon ang CentOS. Hindi ito mismo nagsusuri ng mga packet. Nag-iimbak ito ng configuration at ginagawang nftables rules ang configuration na iyon. Ine-edit ito ng isang command, firewall-cmd, habang online ang server. Walang nagbabago sa gabay na ito para sa dalawang distribution dahil ang tunay na pagkakaiba ng Rocky at AlmaLinux ay ang compatibility promise at ang lawak ng mga CPU na sinusuportahan pa, hindi ang firewall.

Kung alam mo na kung paano gumagana ang ufw sa isang Ubuntu VPS, alam mo na ang pangunahing gamit nito. May dalawang konsepto ang firewalld na wala sa ufw. Una ang zones: isang pinangalanang policy kung saan pinagpapangkat ang mga packet. Ikalawa ang paghihiwalay ng live rules at saved rules. Ito ang tinutukoy ng --permanent flag at ito rin ang pinakamalaking pinagmumulan ng kalituhan sa tool na ito.

Ang lahat ng sumusunod ay mga command na pinapatakbo mo sa sarili mong server. Subukan ang bawat pagbabago mula sa pangalawang machine dahil maaaring mukhang tama ang isang rule sa server ngunit mali pa rin kapag sinusuri mula sa internet.

I-open ang SSH bago gawin ang iba pa

Karamihan sa Rocky at AlmaLinux installs ay mayroon nang firewalld at tumatakbo na ito, at ang configuration na kasama sa installation ay nagpapahintulot sa SSH. Inaalis ito ng ilang minimal cloud image. Suriin muna sa halip na manghula.

sudo dnf install -y firewalld
sudo systemctl enable --now firewalld
sudo firewall-cmd --state

Ang firewall-cmd --state ay nagpi-print ng running. Kung nakahinto ang service, sasagot ang bawat iba pang firewall-cmd call ng FirewallD is not running at mag-e-exit na non-zero. Ito ang unang dapat suriin kapag mukhang walang ginagawa ang isang command.

Ngayon, tingnan kung ano ang kasalukuyang pinapahintulutan.

sudo firewall-cmd --list-all

May ilan pang linya ang aktuwal na output. Ito ang mahahalaga:

public (active)
  target: default
  interfaces: eth0
  sources:
  services: cockpit dhcpv6-client ssh
  ports:
  rich rules:

Ang ssh sa linyang services: ang dahilan kung bakit gumagana pa ang session mo. Kung wala ito, idagdag ito bago galawin ang iba pa, dahil kapag nag-start ka ng firewall na walang SSH rule, matatapos ang session at hindi ka na makakabalik.

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

Nangangahulugan ang target: default na ang packet na walang tumutugmang rule ay tatanggihan gamit ang ICMP (internet control message protocol) host-prohibited reply, kaya makikita agad ng client na kumokonekta sa saradong port ang No route to host. Kapag itinakda sa DROP ang target, mananahimik ang server sa halip, at maghihintay ang mga scanner hanggang mag-timeout.

sudo firewall-cmd --permanent --zone=public --set-target=DROP
sudo firewall-cmd --reload

Alamin muna ang magiging epekto bago ito patakbuhin: pinipigilan din ng DROP ang server na sumagot sa ping, kaya tatahimik din ang sarili mong monitoring.

Bakit nawala ang rule ko? Ang --permanent flag

Dalawang configuration ang sabay na hinahawakan ng firewalld. Ang runtime configuration ang ipinapatupad ng kernel sa kasalukuyan. Ang permanent configuration ang naka-save sa /etc/firewalld/zones/public.xml at bumabalik matapos ang reload o reboot.

Ang command na walang --permanent ay runtime lamang ang binabago. Agad itong gumagana, pero nawawala sa susunod na reload o boot. Ang command na may --permanent ay nagsusulat sa file at walang binabago sa kasalukuyang tumatakbo, kaya nananatiling sarado ang port hanggang mag-reload ka. Hindi bug ang alinman sa dalawang behavior. Nakalilito ang mga ito dahil pareho pa ring nagpi-print ang command ng success.

Palaging isulat ang pares.

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --reload

Mababasa mo ang dalawang configuration. Ito ang pinakamabilis na paraan para malaman kung alin sa dalawang pagkakamali ang nagawa mo.

sudo firewall-cmd --list-services
sudo firewall-cmd --permanent --list-services

Ang una ay nagpi-print ng kasalukuyang set. Ang ikalawa ay nagpi-print ng naka-save na set. Kung may service sa kasalukuyang set na wala sa naka-save na set, mawawala ang rule sa susunod na reload. Kung may service sa naka-save na set na wala sa kasalukuyang set, nakalimutan mong mag-reload. Kinokopya ng sudo firewall-cmd --runtime-to-permanent ang lahat ng kasalukuyang setting sa naka-save na file. Kapaki-pakinabang ito pagkatapos ng session ng mga pagsubok.

Pinananatili ng --reload ang connection tracking state, kaya nagpapatuloy ang SSH session mo. Nire-reload din ng --complete-reload ang kernel modules at nawawala ang state na iyon. Karaniwan nitong tinatapos ang lahat ng bukas na connection, kabilang ang sa iyo. Gamitin ang plain reload.

May built-in na safety net. Maaaring awtomatikong mag-expire ang runtime rule.

sudo firewall-cmd --add-service=http --timeout=5m

Awtomatikong inaalis ng rule na iyon ang sarili nito pagkalipas ng limang minuto. Hindi ito maaaring isabay sa --permanent, at iyon ang layunin nito: para ito sa pagsubok ng pagbabagong hindi ka sigurado. Mas mainam ang mas lumang safety net. Panatilihing bukas ang ikalawang SSH session habang ine-edit mo ang mga rule, at huwag itong isara hanggang mapatunayan ng bagong login na gumagana ang mga bagong rule.

Mga Zone, at kung bakit default zone lamang ang mahalaga sa isang VPS

Ang zone ay isang pinangalanang set ng mga permission na may kalakip na trust level. Inilalagay ng firewalld ang bawat incoming packet sa eksaktong isang zone. Itinutugma muna nito ang source address ng packet sa sources: list ng bawat zone. Kung walang tumugma, ginagamit nito ang zone kung saan naka-bind ang incoming interface. Kung walang zone na naka-bind sa interface, mapupunta ang packet sa default zone.

sudo firewall-cmd --get-default-zone
sudo firewall-cmd --get-active-zones

Sa VPS na may isang network interface, halos palaging public ang unang sagot, at iyon lamang ang zone na gagamitin mo. Ang firewall-cmd na walang argumentong --zone= ay kumikilos sa default zone. Kaya gumagana ang bawat maikling command sa gabay na ito kahit walang tinutukoy na zone.

Narito ang failure na maaaring magsayang ng isang hapon. Kung naka-bind ang interface sa ibang zone, mapupunta ang iyong mga rule sa public habang sa ibang lugar hinahandle ang traffic. Kaya walang epekto ang anumang idinagdag mo, at wala ring warning na lalabas. Ipinapakita ng --get-active-zones ang binding:

public
  interfaces: eth0

Kung lumilitaw ang interface sa ilalim ng ibang pangalan ng zone, isulat ang iyong mga rule doon gamit ang --zone=, o ilipat ang interface.

sudo firewall-cmd --permanent --zone=public --change-interface=eth0
sudo firewall-cmd --reload

Pinamamahalaan ng NetworkManager ang mga interface sa Rocky at AlmaLinux, at ibinabalik nito ang zone kapag umaakyat ang connection. I-set din ito roon para hindi mabago ng reboot ang iyong configuration. Kunin ang pangalan ng connection mula sa unang command, dahil bihira itong kapareho ng pangalan ng device.

sudo nmcli connection show
sudo nmcli connection modify "System eth0" connection.zone public

Nangunguna ang source matching kaysa interface matching. Dahil dito, maaaring magkaroon ng ibang policy ang isang address. Tumatanggap ng lahat ang built-in na trusted zone.

sudo firewall-cmd --permanent --zone=trusted --add-source=203.0.113.10/32
sudo firewall-cmd --reload

Mag-ingat sa zone na iyon. Binubuksan nito ang bawat port sa server para sa address na iyon, kabilang ang database na inakala mong private. Gumamit ng rich rule kung isang port lamang, at hindi isang host, ang gusto mong payagan.

Ano ang firewalld service?

Ang service ay isang pinangalanang bundle ng mga port na naka-package bilang XML file. Binubuksan ng --add-service=https ang 443/tcp dahil tinutukoy ng /usr/lib/firewalld/services/https.xml kung ano ang ibig sabihin ng https.

sudo firewall-cmd --get-services
sudo firewall-cmd --info-service=https

Ipinapakita ng --info-service ang mga port na nasa likod ng pangalan:

https
  ports: 443/tcp

Gamitin ang pangalan kapag may nakalaan na service definition. Malinaw itong basahin sa --list-all pagkalipas ng anim na buwan, at nag-i-install ang mga package gaya ng Cockpit ng sarili nilang service file. Gamitin ang --add-port para sa anumang walang definition.

Ang dapat bantayan ay ito: ang ssh service ay nangangahulugang 22/tcp lamang. Kung inilipat mo ang SSH sa ibang port habang pinatitibay ang SSH access sa server, hindi binubuksan ng --add-service=ssh ang port na aktuwal mong ginagamit.

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload

Sa isang RHEL rebuild, may pangalawang lock sa port na iyon. Nilalagyan ng SELinux (security-enhanced Linux) ng label ang mga port number, at hindi pinapayagan ang sshd na mag-bind sa port na wala sa mga label nito. Dahil dito, hindi ito nagsisimula at mababasa sa log ang error: Bind to port 2222 on 0.0.0.0 failed: Permission denied. Lagyan muna ng label ang port.

sudo dnf install -y policycoreutils-python-utils
sudo semanage port -a -t ssh_port_t -p tcp 2222

Paano ko makikita kung ano ang kasalukuyang bukas?

sudo firewall-cmd --list-all
sudo firewall-cmd --list-rich-rules
sudo nft list table inet firewalld | head -n 40

Iniuulat ng unang dalawang command kung ano ang nakikita ng firewalld. Binabasa naman ng ikatlong command ang mga rule na aktuwal na hawak ng kernel, sa table na pagmamay-ari ng firewalld. Dapat magtugma ang mga ito.

Hindi pa rin sapat na patunay ang mga iyon. Magsagawa ng test mula sa ibang machine:

nc -zv 203.0.113.20 443

Huwag patakbuhin ang test sa server mismo. Tinatanggap ng firewalld ang lahat ng dumarating sa loopback interface, kaya matagumpay ang curl http://localhost:8080 anuman ang nakasaad sa mga rule mo. Ipinapakita ng test na iyon na gumagana ang service. Wala itong sinasabi tungkol sa firewall.

Payagan ang isang web port

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-services

Dapat ilista na ngayon ng huling command ang http https kasama ng mga dati nang nakalista. Kung hindi pa rin sumasagot ang site, maaaring hindi firewall ang problema. Pinapadaan ng rule ang isang packet. Kailangan pa ring may process na nakikinig dito.

sudo ss -tlnp

Ang socket na ipinapakitang 0.0.0.0:443 o *:443 ay tumatanggap ng mga connection mula sa anumang address. Ang ipinapakitang 127.0.0.1:443 ay sumasagot lamang sa loopback, at walang firewall rule ang makakapagpaabot dito mula sa labas. Mas detalyadong ipinapaliwanag ng Mga port at listening socket sa Linux ang pagkakaibang ito.

Paano muling magsara ng port?

sudo firewall-cmd --permanent --remove-service=http
sudo firewall-cmd --reload

Nalalapat din dito ang --permanent rule, at mas malaki ang epekto nito sa ganitong direksiyon. Kung aalisin mo ang isang service sa runtime lamang, magmumukhang sarado ang port. Ngunit bubuksan itong muli ng susunod na reload o reboot mula sa naka-save na file. Butas ito na hindi mo mapapansin dahil pumasa ang isinagawa mong check.

Kapag nag-alis ka ng bagay na wala naman roon, ipi-print ang Warning: NOT_ENABLED: http at mag-e-exit pa rin ito gamit ang 0. Kapag dalawang beses mong idinagdag ang parehong bagay, ipi-print ang Warning: ALREADY_ENABLED: http. Ligtas ang dalawang sitwasyon. Iba ang maling spelling ng pangalan: nangangahulugan ang Error: INVALID_SERVICE na walang definition ang firewalld para sa pangalang iyon at walang anumang binago.

Kung ipinapakita ng iyong --list-all ang cockpit at hindi mo ginagamit ang Cockpit web console sa port 9090, alisin ito. Bawat bukas na port ay service na kailangan mong panatilihing may pinakabagong patch. Para sa mga port na pipiliin mong panatilihing bukas, maaaring mag-install ang dnf-automatic ng security updates ayon sa timer upang hindi nakadepende sa iyong pag-alala ang gawaing ito. Gayunman, hindi pareho ang pag-install ng patch at pagpapatakbo nito. Ipinapakita ng needs-restarting kung aling mga service ang gumagamit pa rin ng lumang libraries kapag na-install na ang mga update.

Limitahan ang isang port sa isang source address lang

Ang rich rules ang mahabang anyo ng rule para sa mga sitwasyong hindi sapat ang simpleng service name upang maipahayag ang kailangan mo. Ang paglilimita sa SSH sa isang office address ay nangangailangan ng dalawang command, at ang pangalawa ang madalas nakakalimutan ng mga tao.

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.10/32" service name="ssh" accept'
sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --reload

Ang isang zone ay set ng mga permission, hindi isang numbered list na humihinto sa unang tumugmang rule. Nagdaragdag ang rich rule ng accept para sa isang address. Wala itong dini-deny. Habang nasa services: line pa ang ssh, maaabot pa rin ng buong internet ang port 22 at walang nasusukat na pagbabago ang rich rule. Alisin ang malawak na entry; kung hindi, dekorasyon lamang ang mas makitid na rule.

Para sa port na walang service name, tukuyin na lang ang port.

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.10/32" port port="5432" protocol="tcp" accept'

Para i-drop ang maingay na network at magtala nito, ilagay ang log element bago ang action. Ito ang pagkakasunod-sunod na inaasahan ng rich rule language.

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="198.51.100.0/24" log prefix="fw-drop " level="info" limit value="3/m" drop'
sudo firewall-cmd --reload
sudo journalctl -k -g fw-drop

Pinipigilan ng value na limit na mapuno ang journal ng napakaraming packet. Bago mo i-lock ang SSH sa isang address lang, tiyaking stable ang address na iyon. Kapag nagbabago ang IP address ng home connection, maaari kang mawalan ng access sa araw na magbago ito. Kaya tiyaking nasubukan at gumagana muna ang console access ng provider mo.

ufw commands at ang katumbas na firewall-cmd

Pareho ang mga gawain, pero magkaiba ang tool. Bawat --permanent line ay nangangailangan ng sudo firewall-cmd --reload pagkatapos nito. Ito ang isang bagay na hindi maipapakita ng ganitong listahan.

• Ang sudo ufw enable ay nagiging sudo systemctl enable --now firewalld
• Ang sudo ufw disable ay nagiging sudo systemctl disable --now firewalld
• Ang sudo ufw status verbose ay nagiging sudo firewall-cmd --list-all
• Ang sudo ufw allow OpenSSH ay nagiging sudo firewall-cmd --permanent --add-service=ssh
• Ang sudo ufw allow 443/tcp ay nagiging sudo firewall-cmd --permanent --add-port=443/tcp
• Ang sudo ufw delete allow 443/tcp ay nagiging sudo firewall-cmd --permanent --remove-port=443/tcp
• Ang sudo ufw allow from 203.0.113.10 to any port 22 ay nagiging rich rule na ipinakita sa itaas
• Ang sudo ufw reload ay nagiging sudo firewall-cmd --reload
• Ang sudo ufw default deny incoming ay ganito na ang asal ng public zone, at ang --set-target=DROP ang silent na bersyon nito
• Ang sudo ufw logging on ay nagiging sudo firewall-cmd --set-log-denied=all

Mahalagang sabihin nang malinaw ang isang pagkakaiba. Pinananatili ng ufw ang isang may numerong listahan, at maaari kang magpasok ng rule sa position 1. Walang rule numbers ang firewalld, kaya walang kahulugan rito ang “ilagay muna ang rule na ito.” Kapag mukhang nagkakasalungatan ang dalawang entry sa firewalld, nananaig ang malawak na accept dahil walang rule sa set na nagde-deny. Ikaw mismo ang mag-aalis ng malawak na entry.

Bakit naa-access ang Docker container ko kahit mukhang sarado ang firewall?

Dahil ang published container port ay hindi dumaraan sa bahaging kinokontrol ng iyong zone sa firewall. Sinasabi ng docker run -d -p 8080:80 nginx sa Docker na gumawa ng sarili nitong NAT (network address translation) at forwarding rules. Kapag dumating ang packet sa 8080, nire-rewrite ito at niruruta papunta sa container, kaya ipinapasa ito sa halip na ihatid sa host. Ang mga linyang services: at ports: sa iyong zone ang namamahala sa mga packet na inihahatid sa host. Ang mga rule ng Docker ang namamahala sa forward path, at ina-accept ng mga ito ang packet.

Ang resulta ay isang server kung saan walang port 8080 na ipinapakita ng sudo firewall-cmd --list-all, pero nakakakonekta pa rin ang nc -zv 203.0.113.20 8080 mula sa ibang machine. Tingnan kung ano ang ini-install ng Docker:

sudo iptables -t nat -L DOCKER -n

Nasa publish flag ang solusyon. I-bind ang port sa loopback at maglagay ng reverse proxy sa harap nito.

docker run -d -p 127.0.0.1:8080:80 nginx

Sasagot na ang container sa curl http://127.0.0.1:8080 sa server, at wala nang sasagot mula sa labas. Pareho ring nararanasan ito ng mga gumagamit ng Ubuntu, gaya ng inilalarawan sa bakit direktang nilalampasan ng Docker containers ang ufw kapag nagpa-publish ng ports. Ang rootful Podman, na kasama sa base repositories ng Rocky at AlmaLinux, ay nagpa-publish din ng ports gamit ang parehong NAT approach. Kaya mag-test mula sa ibang machine sa halip na umasa sa listahan ng zone. Ang overlap na ito rin ang dahilan kung bakit ang pag-install ng Docker Engine sa mga distribution na ito ay nangangailangan ng ilang hakbang na hindi binabanggit sa isang Ubuntu guide, simula sa pagkakaroon na ng Podman na kumokontrol sa docker command.

Pagpapanatiling gumagana nito matapos ang reboot, at mga error na makikita mo

sudo systemctl is-enabled firewalld
sudo systemctl status firewalld

enabled at active (running) ang kailangan mo. Pinoprotektahan ka ng firewall na tumatakbo pero hindi naka-enable hanggang sa unang reboot lamang. Dapat kasama ang pagsusuring ito sa listahang sinusundan mo sa unang sampung minuto sa isang bagong VPS, kasama ng SSH keys at updates.

Hindi dapat pagsamahin ang mga raw nftables command at firewalld. May table na tinatawag na inet firewalld ang firewalld. Binubura ito ng sudo nft flush ruleset, kaya nagiging bukas ang server sa lahat, habang ipinapakita pa rin ng firewall-cmd --list-all ang configuration na nilayon mo. Nangyayari ito dahil iniuulat ng firewalld ang pinaniniwalaan nitong configuration, hindi ang aktuwal na hawak ng kernel. Ibinabalik ng sudo firewall-cmd --reload ang mga rule. Gamitin ang firewall-cmd sa pagsulat ng mga rule para bumalik ang mga ito matapos ang reload.

Dalawang firewall manager sa isang server. Kapag nag-install ka ng ufw o iptables-services kasabay ng firewalld, dalawang program ang nagsusulat ng mga rule nang walang kaalaman sa isa’t isa. Depende sa kung aling service ang huling nagsimula kung alin ang mananaig. Pumili ng isa. Sa Rocky at AlmaLinux, ang firewalld ang may suporta ng distribution.

Ang provider firewall sa harap ng server. Maraming VPS panel ang may hiwalay na network firewall. Kung ipinapakitang bukas ang isang port ng --list-all ngunit nabibigo pa rin ang koneksyon mula sa labas, suriin ang panel bago magbago ng anuman sa server. Gumagana rin ito sa kabaligtaran: walang epekto ang bukas na rule sa panel habang tinatanggihan ng firewalld ang packet.

Pagpapatakbo ng firewall-cmd nang walang sudo. Kailangan ng root ang bawat pagbabago. Kung wala ito, tinatanggihan ng authorization check ang request at walang nababago. Sa unang tingin, parang binalewala lamang ang command.

Karamihan sa pang-araw-araw na gawain ay sakop ng anim na command: --list-all para basahin ang state, --permanent --add-service o --add-port para magbukas ng isang bagay, --permanent --remove-service para magsara nito, --reload para ilapat ang naka-save na file, at --runtime-to-permanent matapos ang isang serye ng mga eksperimento. Ang zone ay public, ang flag ay --permanent, at ang tanging mapagkakatiwalaang pagsusuri ay mula sa ibang machine.

FAQ

Bakit nawala ang firewalld rule ko matapos ang reboot?

Napunta lamang ang rule sa runtime configuration. Agad na ina-apply ang sudo firewall-cmd --add-service=http, ngunit itinatapon ito sa susunod na reload o boot dahil hindi nabago ang saved configuration sa /etc/firewalld/zones/public.xml. Idagdag ang --permanent at pagkatapos ay patakbuhin ang sudo firewall-cmd --reload. Para mapanatili ang mga rule na mano-mano mo nang idinagdag, patakbuhin ang sudo firewall-cmd --runtime-to-permanent. Kokopyahin nito ang live set sa saved file.

Bakit walang nagbabago matapos akong magdagdag ng rule gamit ang --permanent?

Dahil isinusulat ng --permanent ang file ngunit hindi nito binabago ang tumatakbong firewall. Mananatiling sarado ang port hanggang i-load ng sudo firewall-cmd --reload ang saved configuration sa kernel. Ihambing ang sudo firewall-cmd --list-services sa sudo firewall-cmd --permanent --list-services. Kung may entry ang saved list na wala sa live list, kailangan mong mag-reload.

Dapat ko bang gamitin ang --add-service o --add-port?

Gamitin ang --add-service kapag may pangalan para sa serbisyong pinapatakbo mo. Nililinaw nito ang layunin, at ipinapakita ng sudo firewall-cmd --info-service=https kung aling mga port ang sakop ng pangalan. Gamitin ang --add-port kapag walang nagde-define sa iyong serbisyo o kapag nakikinig ito sa non-standard na port. Ang ssh service ay 22/tcp lamang, kaya ang SSH na inilipat sa 2222 ay nangangailangan ng --add-port=2222/tcp at SELinux label para sa port na iyon.

Bakit naaabot ang Docker container ko kahit ipinapakita ng firewall-cmd na sarado ang port?

Nire-rewrite ng sariling NAT rules ng Docker ang published port at ipinapasa ito sa container. Dahil dito, hindi naihahatid ang packet sa host, at ang service at port list ng isang zone ay sumasaklaw lamang sa mga packet na inihahatid sa host. Sumasagot ang container mula sa internet habang walang ipinapakita ang --list-all. I-publish ito sa loopback gamit ang docker run -d -p 127.0.0.1:8080:80 nginx, at maglagay ng reverse proxy sa unahan nito.

Maaari ba akong mag-install ng ufw sa Rocky Linux sa halip na firewalld?

Ang dalawang firewall manager sa iisang server ay nagsusulat ng mga rule nang hindi alam ang ginagawa ng isa’t isa. Nakadepende sa huling nag-start na service kung aling set ang mananatili. Ang firewalld ang suportadong tool sa Rocky Linux at AlmaLinux. Naka-install na ito, at ginagamit nito ang parehong nftables backend na gagamitin ng ufw. Alamin nang isang beses ang default zone at ang --permanent flag, at sapat na iyon para magamit ang buong tool.