הגדרת חומת אש ב-Linux: iptables, nftables, firewalld ממומחים

מדוע הגדרת חומת האש של Linux נכשלת בפרודקשן

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

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

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

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

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

מה נותן מערך אחיד של חוקי סינון תעבורה

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

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

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

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

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

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

מצבי סינון: מנות, אזורים וענן

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

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

סדר היישום: ממלאי מלא ועד לתקנון

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

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

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

מה מועבר לידיים: תרשימים, מדיניות, תקנונים

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

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

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

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

לפני: חוקים ללא בעלים

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

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

מה שינו

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

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

• שירותים הנגישים מבחוץ: 46 → 11, פי ארבעה פחות נקודות כניסה
• חוקים עם בעלים מאושר: 31% → 100%
• חסימות הדדיות: 9 מקרים ברבעון → 0
• שחזור תצורה לאחר תקלה: ~45 דקות ידנית → 6 דקות בפריסה מהמרשם
• בדיקת גישה לפני שחרור: 2 ימים → 20 דקות

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

במה שונה הגדרת סינון צומת מסינון פרימטר הרשת?

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

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

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

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

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

שאלות בנוגע לתאימות והחזרת חוקים

ליבת Linux מאפשרת דו-קיום של כלי סינון שונים: בעוד מערך חוקים אחד פועל, השני נבנה ונבדק במקביל. לכן מעבר בין iptables, nftables ו-firewalld אינו דורש חלון השבתה — חיבורים פתוחים ומסלולים אינם נשברים.

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

מה יקרה אם חוק חדש ינתק את הגישה לשרת?

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

האם צריך לעצור את השירות בזמן תיקונים?

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

כיצד לוודא את בטיחות החוק לפני יישום?

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

נדון במשימה: ננתח את התרשים ונחזור עם תוכנית

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

בתגובה נחזיר לא 'נסתדר במקום', אלא סט קונקרטי:

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

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