כללי כניסה ל-SSH ול-VPN: מה רשימת ההיתרים באמת שולטת בו

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

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

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

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

העברה היא החלטה נפרדת

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

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

השלכה ודחייה הן פעולות, לא מדיניות

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

table inet admin {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        ip saddr 203.0.113.0/28 tcp dport 22 accept
        udp dport 51820 accept
        icmp type { destination-unreachable, time-exceeded } accept
    }
}

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

השאירו את תעבורת הבקרה שאתם באמת צריכים

חסימת כל ICMP היא ברירת מחדל פופולרית ששוברת את גילוי ה-MTU של המסלול, והתסמין הוא חיבור שמתבסס ואז נתקע בחבילות גדולות יותר. גילוי שכנים ב-IPv6 תלוי בסוגי ICMPv6 משלו, והשלכתם שוברת את הקישור לפני שנשאל כלל TCP כלשהו. שניהם שייכים לרשימת ההיתרים כתלויות בעלות שם ולא כהיתרים גורפים. מדיניות ששוברת גילוי בשקט גרועה מזו שמתירה קצת תעבורת אבחון.

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

הוכיחו התאוששות לפני שאתם מוציאים את המסלול הישן

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

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