Fail2ban בשער VPN: מה הוא מתקן ומה לא

כל שירות חשוף מקבל את אותה עצה: שימו עליו fail2ban. עבור שער VPN העצה הזו אינה שגויה ואינה מספקת, והתייחסות אליה כאל תיבת סימון בקשוח היא בדיוק הדרך שבה אנשים נשארים עם כלא (jail) שלא חוסם שום דבר שימושי. Fail2ban קורא את רשומות הכשל שאליהן תפנו אותו ומבקש מ-backend אכיפה לחסום מקורות תואמים. כל הערך שלו תלוי במשטח האימות שהפיק את הרשומה, אם הכתובת שבה היא הלקוח האמיתי, ומה קורה לכל השאר מאחורי אותה כתובת.

מהו fail2ban מבחינה מכנית

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

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

מאזין המנהרה אינו טופס התחברות

מאזין OpenVPN המוגן ב-tls-auth או ב-tls-crypt מפיל חבילות שאין להן הגנת ערוץ הבקרה לפני שעיבוד TLS רגיל מתחיל. סורק שלעולם אין לו את המפתח אינו מייצר דבר שהמסנן שלך יכול לספור. אימות בתעודה מוסיף שער נוסף, כי אין סיסמה לניחוש. פרויקט Fail2ban מתעד מודל כללי מונחה יומנים, ומסנן VPN גנרי אינו הופך חבילה לא מאומתת לאירוע כשל משמעותי.

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

אז איזה משטח אתה מגן עליו?

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

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

ייחוס המקור הוא החוליה החלשה

חסימה טובה רק כמו הכתובת שהיא מכוונת אליה. כשהשירות יושב מאחורי proxy הפוך מקומי, כתובת הלקוח ביומן עשויה להיות ה-proxy, וחסימתו מסלקת את כולם. אמון בכותרת מועברת ממקור לא מהימן נותן לתוקף את היכולת לחסום כתובות שרירותיות. ב-UDP ניתן לזייף כתובות מקור, ולכן ספירתן ראויה ליתר זהירות מאשר ספירת התחברות TCP שהושלמה.

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

העלות הנלווית היא אנשים אחרים

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

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

מתי לאמץ אותו, ומתי לתקן משהו אחר

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

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