אין tun0? התאימו IPsec מפוענח ב-nftables עם meta ipsec

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

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

שתי מנות, ממשק אחד

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

מה שמבדיל אותה הוא הקשר נתיב האבטחה הנכנס שמצורף למנה. nftables חושף אותו כ-meta ipsec exists, שהוא אמיתי כשהמנה הגיעה דרך נתיב אבטחה של IPsec. שלבו אותו עם מאגר הלקוחות, היעד והשירות, והכלל נעשה ספציפי מספיק כדי להיות בטוח.

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

כתבו את כלל ההעברה

נניח שירות גישה מרחוק IPv4 מאומת עם לקוחות ב-10.90.0.0/24 ויעד מאושר אחד ב-203.0.113.40. קטע כלל עבור הזרימה הזאת נראה כך.

meta ipsec exists ip saddr 10.90.0.0/24 \
  ip daddr 203.0.113.40 tcp dport 443 \
  oifname "eth0" counter accept

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

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

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

הקשר נכנס אינו הקשר יוצא

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

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

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

NAT אינו החלטה של חומת אש

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

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

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

אמתו את השירות הפנימי המדויק

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

תיעוד nftables מתעד את meta ipsec, rt ipsec ואת הביטויים הספציפיים לכיוון, ושם המקום לבדוק את התחביר מול הגרסה המותקנת שלכם. ושמרו על ההיקף מפורש: זו דוגמת IPv4, היא אינה אומרת דבר על IPv6, והיא אינה הופכת העברת פורטים ציבורית שרירותית לחלק משירות ה-VPN.