ניהול firewalld ב-Rocky Linux ו-AlmaLinux: מדריך מעשי

מהו firewalld, ומדוע Rocky ו-AlmaLinux מפיצות אותו כברירת מחדל

firewalld הוא מנהל ה-firewall המותקן כברירת מחדל ב-Rocky Linux, ב-AlmaLinux ובשאר ההפצות המבוססות על Red Hat Enterprise Linux (RHEL). שתי ההפצות ירשו את ברירת המחדל הזו ולא בחרו בה באופן עצמאי, עובדה שמובנת יותר כאשר מכירים את האופן שבו Rocky ו-AlmaLinux החלו לבנות מחדש את עבודתה של Red Hat לאחר השינוי בכיוון של CentOS. הכלי אינו מבצע בדיקה של חבילות (packets) בעצמו. הוא שומר תצורה וממיר אותה לחוקי nftables. פקודה אחת, firewall-cmd, עורכת את התצורה בזמן שהשרת נשאר פעיל. דבר במדריך זה אינו משתנה בין שתי ההפצות, כיוון שהדברים שמפרידים בפועל בין Rocky ל-AlmaLinux הם הבטחת התאימות וטווח המעבדים הנתמכים, ולא ה-firewall.

אם אתם כבר מכירים את האופן שבו ufw עובד ב-Ubuntu VPS, אתם מכירים את התפקיד. firewalld מוסיף שני מושגים שאינם קיימים ב-ufw. הראשון הוא zones: מדיניות בעלת שם שאליה ממוינות חבילות. השני הוא הפרדה בין חוקים פעילים לבין חוקים שמורים, המתבצעת באמצעות הדגל --permanent, והיא המקור העיקרי לבלבול בכלי זה.

כל מה שמופיע להלן הוא פקודה שעליכם להריץ בשרת שלכם. בדקו כל שינוי ממכונה שנייה, כיוון שחוק שנראה תקין בתוך השרת עדיין עלול להיות שגוי מהאינטרנט.

פתח גישה ל-SSH לפני כל פעולה אחרת

רוב ההתקנות של Rocky ו-AlmaLinux כוללות את firewalld כשהוא מותקן ופעיל כברירת מחדל, והתצורה המגיעה עם המערכת מאפשרת SSH. עם זאת, חלק מתמונות המערכת המינימליות בענן מסירות אותו. אל תניח הנחות, בדוק זאת.

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

firewall-cmd --state מדפיס running. אם השירות אינו פעיל, כל קריאת firewall-cmd אחרת תחזיר FirewallD is not running ותסתיים עם קוד שגיאה (non-zero). זהו הדבר הראשון שיש לבדוק כאשר נראה שפקודה אינה מבצעת דבר.

כעת, בדוק אילו כללים מוגדרים כרגע.

sudo firewall-cmd --list-all

הפלט המלא כולל שורות נוספות. אלו השורות החשובות:

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

הנוכחות של ssh בשורת ה-services: היא הסיבה לכך שהסשן שלך עדיין פעיל. אם הוא חסר, הוסף אותו לפני שתבצע שינויים אחרים, שכן הפעלת חומת אש ללא כלל SSH תנתק את הסשן שלך ולא תאפשר לך להתחבר חזרה.

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

הערך target: default אומר שחבילה שאינה תואמת לאף כלל נדחית עם הודעת ICMP (פרוטוקול הודעות בקרה באינטרנט) מסוג host-prohibited, כך שלקוח המנסה להתחבר לפורט סגור יקבל מיד No route to host. הגדרת היעד ל-DROP תגרום לשרת להישאר שקט, וסורקים ימתינו עד ל-timeout.

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

היה מודע למחיר לפני שתריץ פקודה זו: DROP גם מונע מהשרת להשיב ל-ping, כך שגם כלי הניטור שלך יפסיקו לקבל תגובות.

מדוע הכלל שלי נעלם? השימוש בדגל --permanent

ל-firewalld יש שתי תצורות בו-זמנית. תצורת ה-runtime היא מה שה-kernel אוכף ברגע זה. התצורה הקבועה (permanent) היא מה שנשמר ב-/etc/firewalld/zones/public.xml ומה שנטען מחדש לאחר reload או אתחול.

פקודה ללא --permanent משנה רק את ה-runtime. השינוי נכנס לתוקף מיידית אך מתבטל ב-reload או ב-reboot הבא. פקודה עם --permanent כותבת לקובץ אך לא משנה דבר בתהליך הרץ, לכן הפורט יישאר סגור עד לביצוע reload. אף אחד מהמצבים אינו באג. שניהם מפתיעים משתמשים, כיוון שהפקודה מדפיסה success בכל מקרה.

יש להריץ את הפקודה פעמיים בכל פעם.

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

ניתן לקרוא את שתי התצורות, וזו הדרך המהירה ביותר לזהות איזו משתי הטעויות בוצעה.

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

הפקודה הראשונה מדפיסה את הסט הפעיל. השנייה מדפיסה את הסט השמור. אם הסט הפעיל מכיל שירות שהסט השמור אינו מכיל, הכלל יימחק ב-reload הבא. אם הסט השמור מכיל שירות שהסט הפעיל אינו מכיל, שכחת לבצע reload. הפקודה sudo firewall-cmd --runtime-to-permanent מעתיקה את כל הסט הפעיל לקובץ השמור, דבר שימושי לאחר סשן של ניסויים.

הפקודה --reload שומרת על מצב ה-connection tracking, כך שסשן ה-SSH שלכם שורד אותה. הפקודה --complete-reload טוענת מחדש גם את מודולי ה-kernel ומאבדת את המצב הזה, מה שבדרך כלל מנתק כל חיבור פתוח, כולל שלכם. השתמשו ב-reload הרגיל.

קיימת רשת ביטחון מובנית. כלל runtime יכול לפוג מעצמו.

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

הכלל הזה יוסר מעצמו לאחר חמש דקות. לא ניתן לשלב אותו עם --permanent, וזו בדיוק המטרה: הוא קיים לצורך בדיקת שינוי שאינכם בטוחים לגביו. רשת הביטחון הישנה יותר טובה: השאירו סשן SSH שני פתוח בזמן עריכת הכללים, ואל תסגרו אותו עד שחיבור חדש יוכיח שהכללים החדשים עובדים.

אזורים (Zones), ומדוע רק אזור ברירת המחדל רלוונטי בשרת VPS

אזור הוא קבוצה בעלת שם של הרשאות, המקושרת לרמת אמון מסוימת. firewalld משייך כל חבילת מידע נכנסת לאזור אחד בלבד. הוא משווה תחילה את כתובת המקור של החבילה לרשימת ה-sources: של כל אזור. אם אין התאמה, הוא משתמש באזור שאליו משויך ממשק הרשת הנכנס. אם הממשק אינו משויך לאף אזור, החבילה מועברת לאזור ברירת המחדל.

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

בשרת VPS עם ממשק רשת אחד, התשובה הראשונה היא כמעט תמיד public, וזהו האזור היחיד שבו תשתמשו. הפקודה firewall-cmd ללא ארגומנט --zone= פועלת על אזור ברירת המחדל; זו הסיבה שכל פקודה קצרה במדריך זה עובדת מבלי לציין שם אזור.

להלן הכשל שגורם לבזבוז זמן רב: אם הממשק משויך לאזור אחר, החוקים שלכם יתווספו ל-public בזמן שהתעבורה מטופלת במקום אחר. כתוצאה מכך, לכל מה שתוסיפו לא תהיה השפעה, ולא תקבלו שום התראה. הפקודה --get-active-zones מציגה את השיוך:

public
  interfaces: eth0

אם הממשק מופיע תחת שם אזור אחר, עליכם לכתוב את החוקים שלכם באותו אזור באמצעות --zone=, או להעביר את הממשק לאזור הנכון.

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

NetworkManager מנהל את הממשקים ב-Rocky וב-AlmaLinux, והוא מחיל מחדש את האזור בכל פעם שהחיבור עולה. הגדירו את האזור גם שם כדי שאתחול לא יבטל את עבודתכם. השתמשו בשם החיבור מהפקודה הראשונה, שכן הוא כמעט אף פעם אינו זהה לשם ההתקן (device name).

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

התאמה לפי כתובת מקור (source) גוברת על התאמה לפי ממשק; כך ניתן להחיל מדיניות שונה על כתובת ספציפית. האזור המובנה trusted מאשר את כל התעבורה.

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

היזהרו עם אזור זה. הוא פותח את כל הפורטים בשרת עבור אותה כתובת, כולל מסד הנתונים שחשבתם שהוא פרטי. השתמשו ב-rich rule כאשר אתם מעוניינים לפתוח פורט אחד בלבד, ולא להעניק גישה מלאה למארח אחד.

מהו שירות ב־firewalld?

שירות הוא אוסף בעל שם של פורטים, המופץ כקובץ XML. הפקודה --add-service=https פותחת את פורט 443/tcp כיוון ש־/usr/lib/firewalld/services/https.xml מגדיר מה המשמעות של https.

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

הפקודה --info-service מציגה את הפורטים המסתתרים מאחורי השם:

https
  ports: 443/tcp

השתמשו בשם כאשר הוא קיים. הדבר משפר את הקריאות של --list-all כעבור שישה חודשים, וחבילות כמו Cockpit מתקינות קובץ שירות משלהן. השתמשו ב־--add-port עבור כל דבר שאין לו הגדרה.

הפער שיש לשים לב אליו: השירות ssh משמעותו 22/tcp ותו לא. אם העברתם את SSH לפורט אחר במסגרת הקשחת הגישה ל-SSH בשרת, אזי --add-service=ssh לא יפתח את הפורט שבו אתם משתמשים בפועל.

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

בהפצות מבוססות RHEL קיים מנעול נוסף על אותה דלת. SELinux (ר"ת של Security-Enhanced Linux) מתייג מספרי פורטים, ו־sshd אינו מורשה להיקשר (bind) לפורט שאינו תואם את התוויות שלו. במקרה כזה הוא יסרב לעלות, ובלוג תופיע השגיאה error: Bind to port 2222 on 0.0.0.0 failed: Permission denied.. יש לתייג את הפורט תחילה.

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

כיצד ניתן לראות מה פתוח כרגע?

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

שתי הפקודות הראשונות מציגות את מה ש־firewalld מדווח עליו. הפקודה השלישית קוראת את החוקים שה-kernel מחזיק בפועל, בתוך הטבלה ששייכת ל־firewalld. עליהן להציג נתונים תואמים.

אף אחד מאלה אינו מהווה הוכחה. בצעו בדיקה ממכונה אחרת:

nc -zv 203.0.113.20 443

אל תריצו את הבדיקה על השרת עצמו. firewalld מקבל כל תעבורה שמגיעה דרך ממשק ה-loopback, לכן curl http://localhost:8080 יצליח ללא קשר לחוקים שהגדרתם. בדיקה זו מאשרת שהשירות פעיל, אך אינה מעידה דבר על מצב ה-firewall.

אישור פורט אינטרנט

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

הפקודה האחרונה אמורה כעת להציג את http https לצד מה שהיה שם קודם. אם האתר עדיין אינו מגיב, ייתכן שהבעיה אינה ב־firewall. חוק מאשר חבילת מידע, אך תהליך עדיין חייב להאזין לה.

sudo ss -tlnp

socket שמוצג כ־0.0.0.0:443 או *:443 מקבל חיבורים מכל כתובת. socket שמוצג כ־127.0.0.1:443 משיב ב־loopback בלבד, ושום חוק firewall לא יהפוך אותו לנגיש מבחוץ. המדריך פורטים ו־sockets בהאזנה ב־Linux מכסה את ההבדל הזה בפירוט רב יותר.

כיצד סוגרים פורט שוב?

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

הכלל --permanent תקף גם כאן, והוא משמעותי יותר בכיוון זה. הסרת שירות מהרצת הזיכרון בלבד גורמת לפורט להיראות סגור, אך טעינה מחדש או אתחול יפתחו אותו שוב על בסיס הקובץ השמור. זהו פרצת אבטחה שלא תבחינו בה, כיוון שהבדיקה שביצעתם עברה בהצלחה.

הסרה של רכיב שלא היה קיים מדפיסה Warning: NOT_ENABLED: http ומסתיימת בקוד יציאה 0. הוספה של אותו רכיב פעמיים מדפיסה Warning: ALREADY_ENABLED: http. שני המקרים בטוחים. שם שגוי הוא עניין אחר: Error: INVALID_SERVICE מציין של-firewalld אין הגדרה בשם זה ושום דבר לא השתנה.

אם ה---list-all שלכם מציג cockpit ואתם לא משתמשים בממשק הניהול Cockpit בפורט 9090, הסירו אותו. כל פורט פתוח הוא שירות שעליכם לדאוג לעדכוני האבטחה שלו, ועבור אלו שתחליטו להשאיר, ניתן להגדיר את dnf-automatic להתקנת עדכוני אבטחה מתוזמנים כדי שהמשימה לא תהיה תלויה בזיכרון שלכם. עם זאת, התקנת עדכון אינה זהה להרצתו, ו-הפקודה needs-restarting מציגה אילו שירותים עדיין משתמשים בספריות הישנות לאחר החלת העדכונים.

הגבלת פורט לכתובת מקור אחת

כללי Rich הם הדרך המפורטת להגדרה, עבור מקרים שבהם שם שירות פשוט אינו מספיק כדי להגדיר את כוונתכם. הגבלת גישת SSH לכתובת IP אחת של משרד דורשת הרצה של שתי פקודות, כאשר השנייה היא זו שאנשים נוטים לשכוח.

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

אזור (zone) הוא אוסף של הרשאות, ולא רשימה ממוספרת שנעצרת בהתאמה הראשונה. כלל ה-rich מוסיף אישור (accept) לכתובת אחת. הוא אינו חוסם אף אחד אחר. כל עוד ssh נמצא בשורת ה-services:, כל האינטרנט עדיין מגיע לפורט 22 וכלל ה-rich אינו משנה דבר שניתן למדוד. הסירו את ההגדרה הרחבה, אחרת ההגדרה המצומצמת היא קישוט בלבד.

עבור פורט שאין לו שם שירות, ציינו את מספר הפורט במקום.

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

כדי להשליך (drop) תעבורה מרשת רועשת ולשמור תיעוד, הציבו את רכיב ה-log לפני הפעולה, שכן זהו הסדר ששפת ה-rich rules מצפה לו.

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

הערך limit עוצר הצפה של חבילות הממלאות את ה-journal. לפני שאתם נועלים את ה-SSH לכתובת אחת בלבד, ודאו שכתובת זו יציבה. חיבור ביתי עם כתובת IP משתנה ינעל אתכם מחוץ לשרת ביום שבו הכתובת תתחלף, לכן ודאו תחילה שגישת ה-console של ספק השירות שלכם נבדקה ועובדת.

פקודות ufw והמקבילות שלהן ב-firewall-cmd

אותן משימות, כלי שונה. כל שורת --permanent דורשת sudo firewall-cmd --reload אחריה, וזהו הדבר היחיד שרשימה מסוג זה אינה יכולה להציג בפניכם.

• sudo ufw enable הופך ל-sudo systemctl enable --now firewalld
• sudo ufw disable הופך ל-sudo systemctl disable --now firewalld
• sudo ufw status verbose הופך ל-sudo firewall-cmd --list-all
• sudo ufw allow OpenSSH הופך ל-sudo firewall-cmd --permanent --add-service=ssh
• sudo ufw allow 443/tcp הופך ל-sudo firewall-cmd --permanent --add-port=443/tcp
• sudo ufw delete allow 443/tcp הופך ל-sudo firewall-cmd --permanent --remove-port=443/tcp
• sudo ufw allow from 203.0.113.10 to any port 22 הופך לכלל העשיר (rich rule) המוצג לעיל
• sudo ufw reload הופך ל-sudo firewall-cmd --reload
• sudo ufw default deny incoming הוא כבר האופן שבו אזור public מתנהג, ו---set-target=DROP הוא הגרסה השקטה שלו
• sudo ufw logging on הופך ל-sudo firewall-cmd --set-log-denied=all

הבדל אחד ראוי לציון מפורש. ufw שומר על רשימה ממוספרת וניתן להוסיף כלל במיקום 1. ב-firewalld אין מספרי כללים, לכן "הצב כלל זה ראשון" אינו בעל משמעות כאן. כאשר שני ערכי firewalld נראים כסותרים זה את זה, הכלל הרחב יותר (accept) הוא הקובע, מכיוון שאין בסט הכללים הגדרה של דחייה (deny). עליכם להסיר את הערך הרחב בעצמכם.

מדוע מכולת Docker נגישה למרות שה-firewall נראה סגור?

מכיוון שפורט של מכולה שפורסם (published) לעולם לא מגיע לחלק של ה-firewall שה-zone שלכם מנהל. docker run -d -p 8080:80 nginx מורה ל-Docker לכתוב חוקי NAT (תרגום כתובות רשת) וניתוב משלו. חבילה שמגיעה לפורט 8080 עוברת שכתוב וניתוב הלאה אל המכולה, ולכן היא מועברת (forwarded) במקום להימסר למארח (host). השורות services: ו-ports: ב-zone שלכם שולטות בחבילות שנמסרות למארח. החוקים של Docker שולטים בנתיב ה-forward, והם מאשרים את התעבורה.

התוצאה היא שרת שבו sudo firewall-cmd --list-all לא מציג את פורט 8080, אך nc -zv 203.0.113.20 8080 ממכונה אחרת מתחבר בכל זאת. בדקו מה Docker התקין:

sudo iptables -t nat -L DOCKER -n

הפתרון נמצא ב-flag של הפרסום. בצעו Bind לפורט אל ה-loopback והציבו לפניו reverse proxy.

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

המכולה כעת עונה ל-curl http://127.0.0.1:8080 בתוך השרת ולא לכלום מבחוץ. משתמשי Ubuntu נתקלים באותה בעיה, המתוארת ב-מדוע מכולות Docker מפרסמות פורטים ישירות מעבר ל-ufw. גרסת ה-rootful של Podman, שמגיעה כברירת מחדל במאגרים של Rocky ו-AlmaLinux, מפרסמת פורטים באותה גישת NAT, לכן בצעו בדיקה ממכונה אחרת במקום להסתמך על רשימת ה-zone. חפיפה זו היא גם הסיבה לכך ש-התקנת Docker Engine בהפצות אלו דורשת כמה צעדים שמדריך Ubuntu לעולם לא מציין, החל מכך ש-Podman כבר מחזיק בפקודה docker.

הבטחת עמידות לאחר אתחול, והשגיאות שסביר שתיתקל בהן

sudo systemctl is-enabled firewalld
sudo systemctl status firewalld

enabled ו-active (running) הם הכלים שאתה צריך. חומת אש שפועלת אך אינה מופעלת (enabled) תגן עליך רק עד האתחול הראשון. בדיקה זו צריכה להופיע ברשימת המשימות שאתה מבצע ב-עשר הדקות הראשונות ב-VPS חדש, לצד הגדרת מפתחות SSH ועדכונים.

פקודות nftables גולמיות ו-firewalld אינן עובדות יחד. ל-firewalld יש טבלה בשם inet firewalld. פקודת sudo nft flush ruleset מוחקת אותה, השרת נותר חשוף לכל, ו-firewall-cmd --list-all עדיין תציג את התצורה שביקשת, כיוון ש-firewalld מדווחת על מה שהיא סבורה שקיים ולא על מה שה-kernel מחזיק בפועל. sudo firewall-cmd --reload מתקינה מחדש את החוקים. כתוב חוקים באמצעות firewall-cmd כדי שיחזרו לאחר טעינה מחדש.

שני מנהלי חומת אש על שרת אחד. התקנת ufw או iptables-services לצד firewalld תגרום לשתי תוכנות לכתוב חוקים ללא מודעות זו לזו, והמנצחת תהיה זו שהשירות שלה עלה אחרון. בחר באחת. ב-Rocky וב-AlmaLinux, ל-firewalld יש תמיכה מובנית של ההפצה.

חומת האש של ספק השרתים. לרבים מלוחות הניהול של VPS יש חומת אש רשת נפרדת. אם --list-all מציגה פורט פתוח וחיבור מבחוץ עדיין נכשל, בדוק את לוח הניהול לפני שתשנה משהו בשרת. זה עובד גם הפוך: חוק פתוח בלוח הניהול לא יועיל אם firewalld דוחה את החבילה.

הרצת firewall-cmd ללא sudo. כל שינוי דורש הרשאות root. ללא הרשאות אלו, הבקשה נדחית על ידי מנגנון האימות ושום דבר לא משתנה, מה שנראה במבט חטוף כאילו הפקודה התעלמה מהבקשה.

שש פקודות מכסות את רוב צורכי היומיום: --list-all לקריאת המצב, --permanent --add-service או --add-port לפתיחת פורט, --permanent --remove-service לסגירתו, --reload להחלת הקובץ השמור, ו---runtime-to-permanent לאחר סבב ניסויים. ה-zone הוא public, הדגל הוא --permanent, והבדיקה האמינה היחידה מגיעה ממכונה אחרת.

FAQ

מדוע חוק ה-firewalld שלי נעלם לאחר אתחול?

החוק הוכנס לתצורה בזמן ריצה בלבד. sudo firewall-cmd --add-service=http מוחל באופן מיידי אך נמחק בטעינה מחדש או באתחול הבא, כיוון שהתצורה השמורה ב-/etc/firewalld/zones/public.xml לא עודכנה. הוסיפו את --permanent ולאחר מכן הריצו את sudo firewall-cmd --reload. כדי לשמור חוקים שכבר הוספתם ידנית, הריצו את sudo firewall-cmd --runtime-to-permanent, אשר מעתיק את סט החוקים הפעיל לקובץ השמור.

מדוע שום דבר לא משתנה לאחר הוספת חוק עם --permanent?

מכיוון ש---permanent כותב את הקובץ ואינו משנה את ה-firewall הפעיל. הפורט נשאר סגור עד ש-sudo firewall-cmd --reload טוען את התצורה השמורה לתוך ה-kernel. השוו בין sudo firewall-cmd --list-services לבין sudo firewall-cmd --permanent --list-services: אם הרשימה השמורה מכילה ערך שאינו מופיע ברשימה הפעילה, סימן שחסרה לכם טעינה מחדש.

האם עליי להשתמש ב---add-service או ב---add-port?

השתמשו ב---add-service כאשר קיים שם עבור השירות שאתם מריצים. הוא מצהיר על הכוונה, ו-sudo firewall-cmd --info-service=https מציג בדיוק אילו פורטים השם מכסה. השתמשו ב---add-port כאשר אין הגדרה לשירות שלכם, או כאשר הוא מאזין בפורט לא סטנדרטי. השירות ssh משמעו 22/tcp בלבד, לכן אם העברתם את SSH לפורט 2222, עליכם להשתמש ב---add-port=2222/tcp בצירוף תווית SELinux מתאימה לאותו פורט.

מדוע מכולת Docker שלי נגישה למרות ש-firewall-cmd מציג את הפורט כסגור?

פורט שפורסם עובר כתיבה מחדש על ידי חוקי ה-NAT של Docker ומועבר למכולה, כך שהחבילה (packet) לעולם לא מגיעה למארח (host), ורשימות השירותים והפורטים של ה-zone מכסות רק חבילות שמגיעות למארח. המכולה עונה מהאינטרנט בזמן ש---list-all לא מציג דבר. פרסמו ל-loopback במקום זאת, באמצעות docker run -d -p 127.0.0.1:8080:80 nginx, והציבו reverse proxy לפני המכולה.

האם ניתן להתקין ufw על Rocky Linux במקום firewalld?

שני מנהלי firewall על אותו שרת כותבים חוקים ללא מודעות זה לזה, והסט שיישאר תלוי בשירות שעלה אחרון. firewalld הוא הכלי הנתמך ב-Rocky Linux וב-AlmaLinux, הוא מותקן כברירת מחדל, והוא מנהל את אותו backend של nftables ש-ufw היה מנהל. למדו את ה-zone המוגדר כברירת מחדל ואת הדגל --permanent, ויהיה בידיכם הכלי המלא.