הגדרת UFW / firewalld / iptables / nftables: ביקורת ותצורה

התצורה של UFW: היכן סינון התעבורה נשבר

תצורת UFW נראית כמו כמה פקודות allow — ולכן סינון התעבורה על המארח לעתים קרובות הופך לדקורטיבי. UFW אינו מסנן עצמאי, אלא תוספת מעל iptables ו-nftables: הוא מרכיב שרשראות מקבצים ב-/etc/ufw ומחיל אותן במלואן בעת reload.

כשל הוא בדרך כלל לא "שכחו כלל", אלא מדיניות ברירת מחדל שגויה, סדר כללי הסינון או אובדן מצב לאחר אתחול.

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

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

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

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

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

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

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

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

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

תצורת UFW וחלופות: השוואת מצבי סינון

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

במכונה זמינים אמצעים מובנים: UFW כתוספת פשוטה עם פרופילי אפליקציה מוכנים, firewalld עם אזורי אמון והצמדת ממשקים, nftables לניתוב מורכב ותרגום כתובות, iptables במקומות שבהם נותרו מודולים שלא הועברו. מבחוץ התעבורה נחתכת על ידי קבוצת אבטחה של רשת הענן.

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

כאשר כללים משוכפלים בשני רבדים ומתפצלים, חיפוש סיבת הכשל מתארך — לכן מקבעים מקור אמת ומשווים את שני השכבות בכל שינוי.

שלבי העבודה: ביקורת כללים, תרשים, תצורה, בדיקה, מסירה

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

1. מלאי שירותים. אוספים רשימת פורטים מאזינים והצרכנים שלהם, כולל רשתות פנימיות ומשרד. כאן צפים פורטי ניהול וטווחים שנשכחו, פתוחים "ליתר ביטחון".
2. צילום כללים נוכחיים. מייצאים מערכים פעילים של ufw, firewalld, iptables או nftables, משווים להתנהגות בפועל של הצומת, מסמנים כפילויות וכללים שכבר לא משפיעים על דבר.
3. תרשים מעבר התעבורה. לכל מסלול מתעדים שרשרת "פרימטר — מאזן עומסים — אפליקציה — מסד נתונים" עם מקור, יעד ופורט. התרשים נעשה בסיס גם למדיניות וגם לניתוח אירועים.
4. תכנון מדיניות. איסור לפי ברירת מחדל, הרשאות ממוקדות לפי מסלולים מאושרים, אזורים נפרדים לרשתות שירות וסדר שבו כללים ספציפיים פועלים לפני כלליים.
5. הטמעה. מחילים בקבוצות — לפי שירות או מקטע, תחילה על צומת בדיקה, אחר כך על הסביבה היצרנית, בחלון מוסכם ועם חזרה מוכנה.
6. בדיקת כללים. מריצים תעבורה מבחוץ ומבפנים: הדרוש נגיש, המיותר סגור, סירובים נרשמים ביומן. בנפרד מוודאים שהכללים שורדים אתחול.
7. מסירת נהלים. מוסרים תצורות במערכת בקרת גרסאות, תרשים תעבורה, תיאור מדיניות וסדר אישור שינויים — כדי שהעריכה הבאה לא תתחיל מאפס.

מדיניות גישה, תצורות ונהלים בתוצר

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

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

המערך סגור בעצמו: לפיו אפשר לבצע ביקורת חוזרת ולראות מה השתנה מאז הפעם הקודמת.

מקרה בוחן: איך סגרו עקיפת סינון על מארח עם קונטיינרים

מה היה

מקרה הטמעה זה התחיל בסריקה חיצונית: על מארח עם סביבת קונטיינרים מבחוץ ענו 23 שירותים, אף שהחומת אש מוגדרת ומדיניות ברירת המחדל אסרה נכנסים. הסיבה התבררה לא כשגיאה בכללים, אלא בסדר עיבוד התעבורה: Docker בעת פרסום פורטים כותב שרשראות הפניה משלו, שפועלות לפני אלו של המשתמש. בסופו של דבר פאנל מדדים, ממשק הניהול של התור ומאגר התמונות הפנימי היו נגישים לכל מי שידע את הכתובת.

מה שינו

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

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

מדדים לפני ואחרי

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

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

מה לעשות אם כבר פרוס iptables והכללים חיים בבלגן

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

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

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

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

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

ספקות טכניים נפוצים לפני תחילת העבודה

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

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

איך אתם מנהלים גרסאות של כללים?

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

האם אתם מתחשבים בקונטיינרים בעת פרסום פורטים?

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

האם זה עובד עם כתובות מהדור החדש?

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

האם אתם מגבילים פאנלי ניהול?

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

נדון במשימה: ביקורת כללים ותוכנית שינויים

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

• גישות: איך נכנסים לצומת — מפתח או קונסול, האם יש מארח מתווך, האם יש מספיק הרשאות, מי עוד ניגש למכונה. מזה תלוי סדר העריכות, כדי לא לחתוך לעצמנו את הכניסה.
• תרשים רשת: ממשקים, כתובות ותת-רשתות, מאזן עומסים, VPN, פרוקסי הפוך. בלעדיו אי אפשר לתאר נכון מקורות תעבורה בכללים.
• רשימת שירותים: מה מאזין החוצה ומה נגיש רק בתוך הצומת, היכן TCP והיכן UDP, למי מבחוץ באמת נדרשת גישה.
• מצב נוכחי: פלטי תצורה, מוני הפעלות, סדר שרשראות ואזורים, האם שני מנהלי כללים פועלים בו-זמנית.
• מגבלות: דרישות ביקורת ונהלים פנימיים, חריגים מאושרים, שירותים שאסור לגעת בהם.
• חלון שינויים: השבתה מותרת, שעות עומס נמוך, תורן זמין, סדר חזרה לאחור.

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