שמות VPN פרטיים נכשלים? הגנת rebind של DNS היא החשודה

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

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

קראו את התשובה לפני שאתם קוראים את המדיניות

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

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

מה ההגנה באמת עוצרת

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

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

צמצמו את החריגה למרחב השמות

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

# ask the resolver the VPN pushed, and show the full answer
dig +noall +answer db.corp.example @10.40.0.1
dig +short db.corp.example @10.40.0.1

# dnsmasq: what does the running configuration already allow?
grep -R 'rebind' /etc/dnsmasq.d /etc/dnsmasq.conf

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

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

בדקו שוב את המשאב ואת ההגנה

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

# the internal name and the public control should behave differently
dig +short db.corp.example @10.40.0.1
dig +short www.example.com @10.40.0.1

# and the service itself, with the certificate it presents
curl -sS -o /dev/null -w '%{http_code}\n' https://db.corp.example/health

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

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