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). Hindi nito direktang sinusuri ang mga packet. Pinapanatili nito ang naka-save na configuration at ginagawang nftables rules ang configuration na iyon. Mae-edit ito gamit ang isang command, firewall-cmd, habang online pa rin ang server.

Kung alam mo na kung paano gumagana ang ufw sa isang Ubuntu VPS, alam mo na ang layunin nito. May dalawang konsepto ang firewalld na wala sa ufw. Una ang zones: mga pinangalanang policy kung saan inaayos 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 nasa ibaba ay 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 ito kapag sinusuri mula sa internet.

Buksan ang SSH bago gawin ang iba

Karamihan sa Rocky at AlmaLinux installs ay mayroon at nagpapatakbo na ng firewalld, at pinapayagan ng kasamang configuration ang SSH. Inaalis naman ito sa ilang minimal cloud images. Mag-check sa halip na manghula.

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

Ipinapakita ng firewall-cmd --state ang running. Kung nakahinto ang service, sasagot ang bawat iba pang firewall-cmd call ng FirewallD is not running at mag-e-exit na may non-zero status. Ito ang unang dapat i-check kapag tila walang ginagawa ang isang command.

Ngayon, tingnan kung ano ang kasalukuyang pinapayagan.

sudo firewall-cmd --list-all

May ilan pang linya sa 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 rin ang session mo. Kung wala ito, idagdag ito bago galawin ang iba, dahil kapag nag-start 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 ire-reject gamit ang ICMP (internet control message protocol) host-prohibited reply, kaya agad makikita ng client na tumatama sa saradong port ang No route to host. Kapag itinakda ang target sa DROP, mananatiling tahimik ang server, at maghihintay ang mga scanner hanggang mag-timeout.

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

Alamin muna ang kapalit bago ito patakbuhin: pipigilan 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 pinamamahalaan ng firewalld. Ang runtime configuration ang kasalukuyang ipinapatupad ng kernel. Ang permanent configuration ang nasa /etc/firewalld/zones/public.xml at bumabalik pagkatapos ng reload o reboot.

Ang command na walang --permanent ay runtime lamang ang binabago. Agad itong gumagana, pero mawawala sa susunod na reload o boot. Ang command na may --permanent ay isinusulat sa file at walang binabago sa kasalukuyang tumatakbo, kaya mananatiling 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.

Isulat ang dalawang ito sa bawat pagkakataon.

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

Mababasa mo ang parehong 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 pangalawa 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.

Pinapanatili ng --reload ang connection tracking state, kaya mananatili ang SSH session mo. Nire-reload din ng --complete-reload ang mga kernel module 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 gamitin kasama ng --permanent, at iyon ang layunin nito: para sa pagsubok ng pagbabagong hindi ka sigurado. Mas mainam ang mas lumang safety net. Panatilihing bukas ang pangalawang 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 ang default zone lang ang mahalaga sa isang VPS

Ang zone ay isang pinangalanang set ng permissions na may kalakip na trust level. Inilalagay ng firewalld ang bawat incoming packet sa eksaktong isang zone. Ihinahambing muna nito ang source address ng packet sa sources: list ng bawat zone. Kung walang tumugma, ginagamit nito ang zone na kinabibilangan ng incoming interface. Kung walang zone ang interface, napupunta 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 lang ang zone na gagamitin mo. Ang firewall-cmd na walang --zone= argument ay kumikilos sa default zone. Kaya gumagana ang bawat maikling command sa gabay na ito nang hindi tumutukoy ng zone.

Narito ang problemang maaaring magsayang ng isang hapon. Kung nakatalaga ang interface sa ibang zone, napupunta ang iyong rules sa public habang sa ibang zone hinahandle ang traffic. Kaya walang epekto ang anumang idinadagdag mo, at walang warning na lumalabas. Ipinapakita ng --get-active-zones ang binding:

public
  interfaces: eth0

Kung lumilitaw ang interface sa ilalim ng ibang zone name, isulat ang iyong rules doon gamit ang --zone=, o ilipat ang interface.

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

Minamanage 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 mabawi ng reboot ang iyong configuration. Kunin ang connection name mula sa unang command, dahil bihira itong kapareho ng device name.

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

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

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, pati ang database na inakala mong private. Gumamit ng rich rule kung isang port lang ang gusto mong payagan, hindi isang buong host.

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 mayroon nito. Mas 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 nakalagay 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 aktuwal na rules na hawak ng kernel, sa table na pagmamay-ari ng firewalld. Dapat magkatugma ang mga ito.

Wala sa mga iyon ang sapat na patunay. Mag-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 sinasabi ng iyong rules. Ipinapakita ng test na iyon na gumagana ang service. Wala itong sinasabi tungkol sa firewall.

Payagan ang 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 nauna. Kung hindi pa rin sumasagot ang site, maaaring hindi firewall ang problema. Pinapahintulutan ng isang rule ang packet. Kailangan pa ring may process na nakikinig para rito.

sudo ss -tlnp

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

Paano muling isara ang isang port?

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

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

Kapag nag-alis ka ng bagay na wala naman dati, magpi-print ito ng Warning: NOT_ENABLED: http at mag-e-exit pa rin gamit ang 0. Kapag dalawang beses mong idinagdag ang parehong bagay, magpi-print ito ng Warning: ALREADY_ENABLED: http. Pareho itong ligtas. Iba ang maling spelling ng pangalan: ang Error: INVALID_SERVICE ay nangangahulugang walang definition ang firewalld para sa pangalang iyon at walang anumang nabago.

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 isang service na kailangan mong panatilihing may pinakabagong patch.

Limitahan ang isang port sa isang source address

Ang rich rules ang mahabang anyo ng rules, para sa mga sitwasyong hindi maipahayag ng simpleng service name ang kailangan mo. Ang paglilimita sa SSH sa isang office address ay nangangailangan ng dalawang command, at ang pangalawa ang madalas nakalilimutan 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 permissions, hindi numbered list na humihinto sa unang match. Nagdaragdag ang rich rule ng accept para sa isang address. Wala itong dini-deny. Habang nasa services: line pa rin 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, palamuti lamang ang mas tiyak na rule.

Para sa port na walang service name, pangalanan 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 magtago ng record, ilagay ang log element bago ang action. Ito ang order 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 ng packets ang journal dahil sa flood. Bago mo i-lock ang SSH sa isang address lamang, tiyaking stable ang address na iyon. Kapag nagbabago ang IP address ng home connection, mawawalan ka ng access sa araw na magbago ito. Kaya tiyaking nasubukan at gumagana muna ang console access ng provider mo.

mga command ng ufw at katumbas ng mga ito sa firewall-cmd

Pareho ang gawain, pero magkaiba ang tool. Kailangang may sudo firewall-cmd --reload pagkatapos ng bawat linyang --permanent. 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
• Ganoon na mismo ang asal ng public zone sa sudo ufw default deny incoming, 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 ipaliwanag nang tuwiran ang isang pagkakaiba. Nagpapanatili ang ufw ng listahang may mga numero, at maaari kang magpasok ng rule sa position 1. Walang rule numbers ang firewalld, kaya walang saysay dito ang “ilagay muna ang rule na ito.” Kapag mukhang nagtatalo ang dalawang entry ng firewalld, mananaig ang malawak na accept dahil walang entry sa set na nagde-deny. Ikaw mismo ang mag-aalis ng malawak na entry.

Bakit naaabot ang aking Docker container kahit mukhang sarado ang firewall?

Dahil ang published container port ay hindi dumadaan 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 kumokontrol sa mga packet na inihahatid sa host. Ang mga rule ng Docker ang kumokontrol 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, ngunit kumokonekta pa rin ang nc -zv 203.0.113.20 8080 mula sa ibang machine. Tingnan kung ano ang na-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 ngayon ang container sa curl http://127.0.0.1:8080 sa server, at walang sasagot mula sa labas. Nararanasan din ito ng mga user ng Ubuntu, gaya ng inilalarawan sa bakit direktang inilalabas ng Docker containers ang mga port lampas sa ufw. Ang rootful Podman, na kasama sa base repositories ng Rocky at AlmaLinux, ay naglalabas din ng mga port gamit ang parehong NAT approach. Kaya magsagawa ng test mula sa ibang machine sa halip na umasa sa listahan ng zone.

Pagpapatuloy nito pagkatapos ng 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 check na ito sa listahang sinusundan mo sa unang sampung minuto sa bagong VPS, kasama ng SSH keys at updates.

Hindi dapat pagsamahin ang raw nftables commands at firewalld. May table na tinatawag na inet firewalld ang firewalld. Tinatanggal ito ng sudo nft flush ruleset, kaya nagiging bukas sa lahat ang server. Gayunman, ipinapakita pa rin ng firewall-cmd --list-all ang configuration na inaasahan mo, dahil iniuulat ng firewalld ang pinaniniwalaan nitong configuration, hindi ang aktuwal na nasa kernel. Ibinabalik ng sudo firewall-cmd --reload ang rules. Gamitin ang firewall-cmd sa pagsusulat ng rules upang bumalik ang mga ito pagkatapos ng reload.

Dalawang firewall manager sa iisang server. Kapag nag-install ka ng ufw o iptables-services kasabay ng firewalld, magkakaroon ka ng dalawang program na nagsusulat ng rules nang walang kaalaman sa isa’t isa. Depende sa huling nagsimulang service kung alin ang mananaig. Pumili ng isa. Sa Rocky at AlmaLinux, ang firewalld ang may distribution support.

Ang provider firewall sa harap ng server. May hiwalay na network firewall ang maraming VPS panel. Kung ipinapakita ng --list-all na bukas ang isang port pero nabibigo pa rin ang koneksyon mula sa labas, tingnan muna ang panel bago magbago ng anuman sa server. Gumagana rin ito sa kabaligtarang paraan: walang epekto ang bukas na panel rule habang nire-reject 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, magmumukhang hindi pinansin ang command.

Sapat na para sa karamihan ng araw-araw na gawain ang 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 pagkatapos ng serye ng mga experiment. Ang zone ay public, ang flag ay --permanent, at ang tanging mapagkakatiwalaang check ay mula sa ibang machine.

FAQ

Bakit nawala ang firewalld rule ko pagkatapos ng reboot?

Napunta lang ang rule sa runtime configuration. Agad na ina-apply ang sudo firewall-cmd --add-service=http at itinatapon sa susunod na reload o boot dahil hindi kailanman 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. Kinokopya nito ang live set papunta sa saved file.

Bakit walang nagbabago pagkatapos kong magdagdag ng rule gamit ang --permanent?

Dahil isinusulat ng --permanent ang file at hindi nito binabago ang tumatakbong firewall. Mananatiling sarado ang port hanggang i-load ng sudo firewall-cmd --reload ang saved configuration sa kernel. Ikumpara ang sudo firewall-cmd --list-services sa sudo firewall-cmd --permanent --list-services. Kung may entry ang saved list na wala sa live list, ang reload ang hindi mo pa nagagawa.

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 intent, at ipinapakita ng sudo firewall-cmd --info-service=https kung aling mga port ang saklaw ng pangalan. Gamitin ang --add-port kapag walang tumutukoy sa iyong serbisyo o kapag nakikinig ito sa non-standard na port. Ang ssh service ay para lamang sa 22/tcp, kaya ang SSH na inilipat sa 2222 ay nangangailangan ng --add-port=2222/tcp at SELinux label para sa port na iyon.

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

Isinusulat muli ng sariling NAT rules ng Docker ang published port at ipinapasa ito sa container. Dahil dito, hindi kailanman inihahatid ang packet sa host. Ang service at port lists ng isang zone ay sumasaklaw lamang sa mga packet na inihatid sa host. Sumasagot ang container mula sa internet kahit 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 harap 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 walang kaalaman sa isa't isa. Kung aling set ang mananatili ay nakadepende sa kung aling service ang huling nagsimula. 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. Matutunan mo nang isang beses ang default zone at ang --permanent flag, at sapat na iyon para sa buong tool.