קבוצת אבטחה בענן ל-VPN: לפתוח את המאזין, לא הכול

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

תנו שם לפרוטוקול לפני הכלל

כלל הוא פרוטוקול, טווח פורטים ומקור. WireGuard מאזין ב-UDP, בדרך כלל 51820. OpenVPN הוא בדרך כלל UDP או TCP 1194 בהתאם לאופן שבו הוגדר. IPsec זקוק לחילופי IKE ב-UDP 500 ו-4500 וכן לפרוטוקול ESP עצמו, שהוא מספר פרוטוקול ולא פורט. ניחוש TCP מפני שהכללים האחרים הם TCP הוא הדרך לקבל כלל שנראה נכון ולא מתאים לשום דבר.

קראו את המאזין מהשירות שרץ, לא ממדריך. דמון שקשור לכתובת אחת לא יקבל תעבורה שמגיעה לכתובת אחרת.

הגבילו את המקור לטווח הלקוחות שהתכנון מתיר, ולא לכל האינטרנט.

קבוצות אבטחה הן בעלות מצב; ACL של תת-רשת אינן

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

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

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

חומת האש של המארח היא גבול נפרד

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

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

לכידה בממשק אומרת לכם איזה גבול השליך את המנה.

התרת המאזין אינה ניתוב הלקוחות

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

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

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

השאירו דרך חזרה, ואז צמצמו את הכלל

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

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

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