הגדרת TCP Wrappers לשליטה בגישה לשירותים

TCP Wrappers: מדוע בקרת גישה לפי כתובות נשברת

בצומת ייצור sshd, מסד נתונים ומתווך תורים מאזינים בכל הממשקים, והגבלת גישה לפי כתובות נשענת על כמה שורות ב-hosts.allow, שנוספו לפי סכמת הכתובות הקודמת.

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

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

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

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

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

העוטפת TCP Wrappers עומדת בין החיבור הנכנס לבין השירות עצמו: הדימון בודק את כתובת הלקוח מול הכללים ב-/etc/hosts.allow ו-/etc/hosts.deny ורק אחר כך מעביר את השליטה לאפליקציה. הבדיקה מתבצעת לפני שהשירות מתחיל לנתח את הבקשה, ולכן חסימת הפניות קורית בכניסה, ולא אחרי אימות.

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

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

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

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

דרכים להגבלת גישה: השוואת גישות

גישה מגבילים בארבע רמות, והבחירה ברמה קובעת מה בדיוק אתם שולטים בו: שירות, מארח, כניסה לאפליקציה או נגישות של מקטע. TCP Wrappers פועלים ברמת השירות: הכלל «לאשר לתת-רשת, לאחרים לסרב» חל לפני עיבוד הבקשה, אך רק על דימונים שנבנו עם תמיכה בספריית העוטפת.

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

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

סדר הטמעת כללי גישה

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

1. מלאי שירותים. אוספים רשימה של דימונים שמאזינים לרשת ובודקים אילו מהם נבנו עם תמיכה בעוטפת: עבור האחרים הכללים לא יחולו, והגישה תישאר פתוחה למרות חסימה שהוגדרה פורמלית.
2. איסוף תמונת תעבורה. לפי יומנים וחיבורים פעילים מתעדים זוגות אמיתיים «שירות — כתובת»: מי פונה, מאיפה, באיזו תדירות. זה הבסיס לסכמת הגישה במקום הנחות.
3. תכנון סכמת גישה. מתארים הרשאות לפי עקרון «הכול אסור אלא אם הותר»: זוגות נקודתיים ב-allow, חסימה בסיסית ב-deny. מביאים בחשבון את סדר העיבוד — ההתאמה הראשונה היא שקובעת.
4. הגדרה ובדיקה של כללים. מריצים את הקונפיגורציה דרך tcpdmatch על זוגות ביקורת «שירות — כתובת» ובודקים איך הסירוב משתקף ביומן.
5. הפעלה מבוקרת. מכניסים את הכללים בחלון מוסכם, עוקבים אחרי סירובים בלוגים, ושומרים חזרה אחורה מוכנה: החזרת הקבצים הקודמים אורכת דקות.
6. מסירה לתפעול. הקבצים עוברים למערכת ניהול קונפיגורציה, סכמת הגישה וסדר הסקירה שלה מתועדים במסמכים.

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

קונפיגורציות, סכמות קשרים ונוהלי גישה

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

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

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

מקרה בוחן: כיצד סגרו גישה לשירותי מערכת

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

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

לפני ואחרי

• פניות שנדחו מכתובות לא מהימנות: כ-400 ביממה לפני העבודה — כעת הזרם נחסם בכניסה, ואין סירובים לגיטימיים בכללים.
• גישה לפורטים של שירותי מערכת: מכל כתובת — עד שני מקטעים מהימנים ו-Bastion.
• עריכת כלל גישה: פעם עשרות דקות לבנייה מחדש של מסנן הרשת ואישור, כעת 3–5 דקות לשורה ב-hosts.allow.

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

במה TCP Wrappers שונים מכללי חומת אש?

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

העוטפת, которую Wietse Venema הוסיף לשירותי מערכת, מוטמעת בדימון עצמו: ההחלטה מתקבלת לאחר יצירת החיבור, כשכבר ידוע גם שם הצומת.

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

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

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

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

ספקות טכניים: ניתוח שאלות נפוצות

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

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

באיזה סדר נבדקים הכללים?

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

כיצד מתנהגים קונטיינרים?

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

כיצד לחזור אחורה משינויים אם הגישה אבדה?

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

נדון במשימת בקרת הגישה

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

• רשימת השירותים שאליהם אנו מגבילים גישה (קונסולה מרחוק, דואר, שיתוף קבצים, מסדי נתונים), וכיצד הם מופעלים — ישירות או תחת סופר-שירות.
• הקבצים הנוכחיים /etc/hosts.allow ו-/etc/hosts.deny: אם הכללים כבר כתובים, מיד רואים מה עובר בירושה ומה מתנגש.
• רשימת רשתות וכתובות מהימנות — משרד, סניפים, מאגרי גישה מרחוק, כתובות קבלנים ומערכות ניטור.
• כיצד מוקצות כתובות ללקוחות: סטטית או ממאגר דינמי. מכאן נגזר אם להגדיר כלל לפי כתובת, לפי תת-רשת או לפי שם צומת.
• סכמת מעבר התעבורה: היכן מאזן העומס, היכן הפרוקסי ההפוך, והאם יש בהיקף המרת כתובות.
• דרישות לתיעוד סירובים: לאן נכתבים האירועים, תקופת שמירה, והאם נדרשת העברה לאיסוף יומנים מרכזי.
• חלון עבודה מותר וסדר חזרה לכללים הקודמים — אם מיישמים עריכות בקו הייצור.

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