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

מה כתובת מקור יכולה להכריע ומה לא

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

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

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

למה חסימת היציאה מענישה זרים

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

SignalWhat it provides evidence aboutWhat it cannot settle
Source address and its reputationThe network path, and how that path behaved recently for othersWhich account or person is behind the request
Authenticator resultWhether the account claim was proved at the required strengthWhether the account's owner initiated it
Request timing and volumeWhether the pattern looks automated or burst-likeWhether the intent was malicious or a shared client
Application event historyWhat this account has done while signed inAnything about requests that never authenticated

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

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

שימו את ההחלטה במקום שבו הראיות נמצאות

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

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

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

איך נראית מדיניות הוגנת מבחוץ

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

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

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

מאמרים קשורים