نام~~های خصوصی VPN کار نمی~~کنند؟ محافظت rebind در DNS مظنون است

در شبکه محلی دفتر، نام داخلی فوراً پاسخ می‌دهد. همان لحظه که VPN بالا می‌آید از کار می‌افتد، برنامه از پایان زمان پاسخ می‌گوید و خود تونل بدون گلایه ترافیک را عبور می‌دهد. چیزی که تغییر کرده ریزولور است و آن ریزولور درباره نشانی‌های خصوصی نظر خودش را دارد.

محافظت rebind برای متوقف کردن یک ترفند مشخص وجود دارد. نام خصوصی که عمداً منتشر شده به‌قدر کافی شبیه است که دفاع فعال شود.

پیش از خواندن سیاست، پاسخ را بخوانید

نام را از ریزولوری بپرسید که VPN واقعاً تحویل می‌دهد، نه از آنکه لپ‌تاپ شما در خانه استفاده می‌کند. پاسخ را با رکوردی که انتظار دارید مقایسه کنید و توجه کنید که پاسخ خالی است، رد شده است یا پر از نشانی‌های عمومی است که کسی برنامه‌ریزی نکرده بود.

نشانه‌ها هم‌پوشانی دارند، پس شکل پاسخ تشخیص را تعیین می‌کند. NXDOMAIN یعنی رکورد غایب، REFUSED یعنی قاعده دسترسی، نشانی عمومی برای یک نام داخلی یعنی خطای سیاست یا DNS تقسیم‌شده، و نشانی خصوصی درست که کلاینت نمی‌تواند استفاده کند مشکل کاملاً دیگری است. اتصال ردشده یا درخواست متوقف‌شده به‌تنهایی چیزی را ثابت نمی‌کند، به همین دلیل اولین فرمان در هر یک از این بلیت‌ها باید یک جست‌وجو باشد نه راه‌اندازی مجدد. پیش از تغییر هر چیزی پاسخ را بنویسید.

دفاع در واقع چه چیزی را متوقف می‌کند

rebind در DNS با تغییر اینکه یک نام پس از اعتماد کلاینت به کجا تجزیه می‌شود کار می‌کند. صفحه‌ای از نامی که مهاجم کنترل می‌کند بارگذاری می‌شود، پاسخ به یک نشانی خصوصی می‌چرخد و مرورگر فریب می‌خورد تا با چیزی در شبکه محلی صحبت کند که هرگز اتصال مستقیم به آن را نمی‌پذیرفت. دفاع این است که پاسخ‌هایی رد شوند که به فضای خصوصی اشاره می‌کنند، وقتی هرگز از ریزولور خواسته نشده فضای نام خصوصی را سرویس دهد. تمام حمله همان نامتقارنی است.

dnsmasq دقیقاً همین رفتار را مستند می‌کند، همراه با استثناها به تفکیک دامنه. صفحه راهنما آن rebind-domain-ok را راهی برای نام‌گذاری دامنه‌هایی می‌داند که به‌طور مشروع می‌توانند چنین نشانی‌هایی برگردانند. آن را نشانه‌ای بخوانید که اصلاح موردنظر یک اجازه محدود است، نه یک کلید سراسری.

استثنا را به فضای نام محدود کنید

ابتدا فضای نام را درست کنید، سپس استثنا را. تأیید کنید که نام ناموفق به دامنه‌ای تعلق دارد که سازمان کنترل می‌کند و رکورد عمداً نگه‌داری می‌شود. نشانی غیرمنتظره‌ای که فقط شبیه یک محدوده آشنای شبکه محلی است سزاوار بدگمانی است نه استثنا، پس پیش از نوشتن هر اجازه‌ای مالک منطقه را بررسی کنید.

# 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

سپس تنگ‌ترین اجازه‌ای را اضافه کنید که نام‌های موردنظر را پوشش می‌دهد: یک دامنه یا یک زیردامنه تفویض‌شده، در پیکربندی ریزولوری که کلاینت‌های VPN از آن می‌پرسند. خاموش کردن محافظت برای همه نام‌ها روی آن ریزولور، دفاع را یک‌جا از همه می‌گیرد، از جمله نام‌هایی که هرگز به آن نیاز نداشتند.

DNS تقسیم‌شده بخشی از همان تصمیم است. اگر فضای نام خصوصی باید فقط روی ریزولور داخلی پاسخ بگیرد، آن را همان‌جا منتشر کنید و نشت آن به ریزولورهای عمومی را متوقف کنید، تا استثنا یک مسیر را پوشش دهد نه همه مسیرها.

منبع و دفاع را دوباره آزمایش کنید

دوباره بپرسید، سپس به سرویس وصل شوید و ببینید کلاینت چه می‌بیند. پاسخ خصوصی درست با نشستی که کار می‌کند یعنی استثنا اعمال شده است. پاسخ درست با نشست متوقف‌شده یعنی مسیر یا هویت سرویس مظنون بعدی است.

# 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

یک نام عمومی را هم از همان ریزولور آزمایش کنید. محافظت باید برای نام‌های بیرون استثنا همچنان کار کند، و اگر آن بررسی شکست بخورد، تغییر گسترده‌تر از آن بود که می‌خواستید. اعتبارسنجی گواهی را در تمام مدت دست‌نخورده نگه دارید، چون نامی که درست تجزیه می‌شود باز هم باید با گواهی‌ای که سرویس ارائه می‌دهد مطابقت داشته باشد.

در بلیت، پاسخ ردشده، دامنه، ریزولور و اینکه سیاست از آنِ کیست را ثبت کنید. همان ثبت است که یک قطعی مرموز داخلی را به تغییری در پیکربندی تبدیل می‌کند که کسی می‌تواند بازبینی کند.