את UFW המציאו כדי שאפשר יהיה להגדיר חומת אש בשלוש פקודות, ובזה הוא מצליח. הבעיה במקום אחר: ufw status מציג כוונות, לא תוצאות. כלל יכול להיות ברשימה ולא לסגור מאומה — משלוש סיבות שונות, וכולן צצות בשרתים אמיתיים באופן קבוע.

התחלה שאינה נועלת אתכם בחוץ

סדר הפקודות חשוב. תחילה התירו SSH, ורק אז הפעילו:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable

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

הביטו במצב המפורט; המקוצר מסתיר את מדיניות ברירת המחדל:

sudo ufw status verbose

טעות ראשונה: הכלל קיים והפורט פתוח לעולם

השורה הנפוצה ביותר בהגדרות של אחרים:

sudo ufw allow 3306

כך פותחים את MySQL «כדי שאוכל להתחבר מהבית» — ופותחים אותו לכל האינטרנט. יש שתי גרסאות נכונות ושתיהן טובות יותר:

sudo ufw allow from 203.0.113.25 to any port 3306

או, אמין עוד יותר, אל תוציאו את השירות החוצה כלל: bind-address = 127.0.0.1 בהגדרות MySQL, וגישה חיצונית דרך מנהרת SSH. חומת האש היא הקו השני; הראשון הוא שהשירות אינו מאזין בכתובת ציבורית. כלל ב-UFW עלול להימחק בטעות, בעוד bind-address אינו משתנה מעצמו.

טעות שנייה: IPv6

כלל כמו ufw allow from 203.0.113.25 חל על IPv4 בלבד. אם לשרת יש כתובת IPv6 — ולרוב ה-VPS יש, ומופעלת — השירות נשאר נגיש דרכה. הספק הקצה כתובת, אתם אינכם זוכרים אותה, והסורק כן.

בדקו שסינון v6 מופעל בכלל (IPV6=yes ב-/etc/default/ufw) ושהשירות אינו מאזין על :: ללא צורך:

ss -tulpn | grep ':::'

כללים שמציינים כתובת במפורש צריכים להיכתב בנפרד לכל גרסת פרוטוקול.

טעות שלישית: Docker

המרגיזה ביותר. Docker מפרסם פורטים בכך שהוא מוסיף כללים משלו לשרשראות iptables לפני אלה ש-UFW כותב. כתוצאה מכך מכולה שהופעלה עם -p 5432:5432 נגישה מהאינטרנט אף ש-UFW מדווח Status: active ומדיניות deny incoming. חומת האש אינה שבורה — פשוט לא מגיע תורה.

התרופה אינה ב-UFW אלא באופן שבו הפורט מפורסם:

ports:
  - "127.0.0.1:5432:5432"

קשירה לכתובת המקומית היא הפתרון הפשוט והאמין ביותר. החוצה צריך להביט רק מה שבאמת משרת מבקרים: בדרך כלל פורטים 80 ו-443 של פרוקסי הפוך.

סדר הכללים

UFW מחיל את הכלל הראשון שמתאים ועוצר שם. לכן איסור שנוסף אחרי היתר לא יעבוד: פשוט לא יגיע אליו התור. הביטו במספור והכניסו במקום הדרוש:

sudo ufw status numbered
sudo ufw insert 1 deny from 198.51.100.0/24
sudo ufw delete 7

כללים נמחקים לפי מספר, אבל המספרים זזים אחרי כל מחיקה — מחקו אחד-אחד וקראו את הרשימה מחדש.

בדיקה מבחוץ

פקודות מקומיות מציגות מה מוגדר. מה באמת יצא נראה רק ממכונה אחרת:

nmap -Pn -p- 203.0.113.25
nc -zv 203.0.113.25 3306

יתאים כל שרת אחר או המחשב הביתי שלכם. זו הבדיקה היחידה שאינה משקרת, ושווה להריץ אותה אחרי כל שינוי תצורה מורגש — במיוחד אחרי התקנה של משהו ש«מגדיר את הרשת בעצמו»: Docker, לוחות בקרה, VPN.

יומנים

כברירת מחדל UFW כמעט אינו כותב דבר. מפעילים את זה כך:

sudo ufw logging low

הרשומות הולכות ל-/var/log/ufw.log — אבל רק אם rsyslog קיים במערכת. ב-Debian 12 וב-Ubuntu 24.04 הוא עשוי להיעדר, ואז הכול הולך ליומן של systemd:

sudo journalctl -k | grep -i '\[UFW'

/var/log/ufw.log ריק אינו אומר דבר בפני עצמו — הביטו קודם ביומן.

מה לצפות מחומת אש

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