איך עובד זיהוי VPN ופרוקסי, והיכן הוא נכשל
רשימות IP, ממשקי API למוניטין וטביעות אצבע נכשלים בדרכים שונות. החליטו איזה ניצול לרעה אתם עוצרים, מדדו חיוביים שגויים, ואז אכפו עם קוד סיבה.
כשמישהו שואל איך לחסום משתמשי VPN, שלוש בקשות שונות מסתתרות במשפט: לעצור הונאה, לעצור גרידה, או לאכוף גבול רישוי. כל אחת סובלת שיעור שגיאה אחר, ואף אחת מהן לא נענית בידיעה אם כתובת שייכת למנהרה. מה שמסווג מחזיר הוא הסתברות לגבי תשתית, ולא הצהרה על האדם שמשתמש בה.
מה מסווג IP באמת מחשב
רוב השירותים משלבים ארבעה מקורות נתונים, והם מתיישנים בקצבים שונים. רשימות יציאה של Tor מגיעות מהקונצנזוס של המדריך והן כמעט שלמות כל עוד הוא מחזיק. רשימות פרוקסי פתוח חלקיות ומתיישנות בתוך ימים. רשימות יציאה מסחריות מפגרות אחרי ספקים חדשים כברירת מחדל, כי כתובות מסתובבות מהר יותר מכל ספק שיצליח לסרוק אותן. היוריסטיקת טווחי אחסון היא האות הזול והגס ביותר.
דווקא האחרונה היא המקום שבו נולדים רוב החיוביים השגויים. יציאות ארגוניות, דפדפנים המתארחים בענן, NAT קמפוס ושערי ספקי סלולר נראים כולם כמו אחסון או תשתית משותפת, וכל אחד מהם יכול להכיל לקוחות רגילים.
| Signal | What it shows | Typical failure |
|---|---|---|
| Tor exit consensus | A known exit relay | Good coverage, obvious to anyone who cares |
| Hosting or datacentre ASN | Infrastructure, not a home line | Flags corporate egress and cloud browsers |
| Commercial exit list | A provider's current ranges | Always behind new providers and rotations |
| Behavioural rate | What the client is doing | Needs tuning, but survives address changes |
IPv6 מסיר כל נוחות שנותרה. לקוח יכול להחזיק כתובת שונה לכל חיבור, וספק יכול לסובב קידומת בין בקשות, כך שכלל שמתייחס לכתובת כזהות מתמשכת ייסחף מהמציאות בתוך שבועות.
למה טביעות אצבע של פרוטוקול מתפוררות
הבדלי MSS ותזמון יכולים לזהות כמה תצורות OpenVPN, והטכניקה שברירית באמת. האות תלוי באפשרויות שהמשתמש שולט בהן, ב-MTU של המסלול ובקופסאות ביניים שאינן שלכם. שנה צופן אחד או מגבלת MSS אחת והטביעה זזה. ספק שמשיק ברירת מחדל חדשה עושה את אותו הדבר לכלל שלכם בין לילה.
לבדיקות הפוכות יש בעיה גרועה משבריריות: הן עוינות. סריקת פורטים של מבקר איטית, נחסמת בקלות על ידי אותה חומת אש ארגונית שהלקוחות שלכם יושבים מאחוריה, וקשה להגן עליה בסקירת פרטיות. ספי השהיה תופסים משתמשים רחוקים באותה אמינות כמו משתמשי מנהרה, כלומר הכלל שלכם הוא בעצם «חסמו אנשים רחוקים» עם תווית אחרת.
מה שתבחרו, עליכם להיות מסוגלים להסביר את זה לנציג תמיכה בשעה 2 בלילה. אות שאיש לא יכול לתאר הופך לחסימה שאיש לא יכול לבטל. כתבו את ההסבר לפני שאתם כותבים את הכלל, לא אחרי התלונה הראשונה.
זהות והתנהגות מנצחות ניחושים לגבי אנונימיות
מגבלות קצב, דרישות התחברות, בדיקות תשלום ומכסות לפי חשבון מטפלות בניצול לרעה בלי להעניש קוראים שאכפת להם מפרטיות. הן גם ממשיכות לעבוד כשהכתובת משתנה, כי הן נצמדות למשהו שהלקוח לא יכול לסובב בחינם.
אם הגבלה גיאוגרפית היא דרישת רישוי, אכפו אותה כמדיניות מתועדת עם הודעת שגיאה ברורה וסקירה תקופתית. זהו בקרה שונה מניחוש לגבי אנונימיות, ויש לתאר אותה אחרת בטקסט הפונה ללקוח. חסימת הפורטים שפרוטוקול VPN משתמש בהם עשויה להפחית ניצול לרעה אוטומטי, אבל היא גם שוברת גישה מרחוק לגיטימית וכל אדם נחוש עוקף אותה בקלות.
השיקו את זה קודם כמדידה
הריצו את המסווג במצב דוח בלבד במשך שבועיים. השוו את האוכלוסייה שהיה חוסם מול הרשמות, המרות ופניות תמיכה, ואז קבעו את תקציב החיוביים השגויים לפני שאתם קובעים את הסף.
בדקו מחדש מול קבוצה קטנה ומוכרת: חיבור ביתי, ספק סלולרי, יציאה ארגונית ו-VPN מסחרי. ארבעה מקרים חושפים את רוב השגיאות שאחרת יגיעו ללקוחות, והם עולים אחר צהריים אחד.
הפרידו בין האות הגולמי לבין החלטת האכיפה. תעדו את הניקוד גם כשהסף גבוה, נתבו את האמצע העמום לתור אנושי, ותייגו כל חסימה בקוד סיבה כדי שסקירת המדיניות הבאה תדע איזה אות הרוויח את מקומו.
מסלול הערעור הוא חלק מהבקרה
כל חסימה אוטומטית זקוקה למסלול אנושי: כתובת קשר, זמן תגובה מוצהר ובעלים נקוב לסקירה. בלי זה, חיובי שגוי הוא לקוח אבוד בשקט ופניית תמיכה שאיש לא יכול לטפל בה.
אמרו בבירור שהגישה עשויה להיות מוגבלת, מדוע וכיצד לבקש סקירה. הוסיפו גרסה למדיניות כדי שהתמיכה תוכל לומר איזה כלל חל בתאריך נתון. חסימה שאינכם יכולים להסביר, לבטל או למדוד אינה בקרה; היא ניחוש עם שורת יומן.