گواهی VPN از بخش LDAP محافظت نمی‌کند

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

همین عدم تقارن مکانیزمی است که پشت ورودی قرار دارد که رمزنگاری‌شده به نظر می‌رسد و همچنان گذرواژهٔ bind را آشکار می‌فرستد.

دو اتصال، دو تصمیم اعتماد

نشست بیرونی همان چیزی است که کاربر می‌بیند: گواهی‌ای مقید به نام میزبان VPN، اعتبارسنجی‌شده توسط کلاینت، که تبادل احراز هویت را حمل می‌کند. نشست درونی از آنِ کلاینت دایرکتوری درون دروازه است که اتصال خودش را باز می‌کند و یا TLS را مذاکره می‌کند یا نمی‌کند. هر طرف طرف مقابل خود را با موادی از یک فایل پیکربندی متفاوت اعتبارسنجی می‌کند. بخش درونی بدپیکربندی‌شده از سمت کاربر نامرئی می‌ماند، چون بخش بیرونی دقیقاً همان‌طور که در نظر بود کار می‌کند.

به همین دلیل خرابی خاموش است نه پرصدا. دروازه‌ای که هرگز گواهی دایرکتوری را بررسی نمی‌کند، هنوز کاربران را درست احراز هویت می‌کند؛ فقط آن‌ها را از کانالی احراز می‌کند که آن را بررسی نکرده است.

StartTLS و LDAPS، انتخابی آگاهانه

StartTLS به‌صورت LDAP ساده باز می‌شود و در همان‌جا ارتقا می‌یابد، معمولاً روی درگاه 389. LDAPS پوشش TLS را همراه اتصال آغاز می‌کند، معمولاً روی 636. هر دو مشروع‌اند و آداپتور باید با آنچه دایرکتوری ارائه می‌دهد هماهنگ باشد. الزام StartTLS با امتحان کردنش و ادامه دادن وقتی ارتقا شکست می‌خورد متفاوت است، و همین تفاوت جایی است که گذرواژهٔ bind می‌تواند بیرون بزند. حالت سخت‌گیرانه را پیکربندی کنید و برای bind با گذرواژه هیچ مسیر جایگزین محافظت‌نشده‌ای را مجاز ندانید.

ldapsearch -H ldap://dc1.corp.example -ZZ -x -D "CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example" -W -b "DC=corp,DC=example" "(sAMAccountName=example-user)" dn

گزینهٔ -ZZ تمام نکته است: پرس‌وجو شکست می‌خورد به‌جای آنکه بی‌صدا بدون ارتقا ادامه دهد. نام‌ها و حساب‌های آن خط مثال‌اند. مستندات TLS در OpenLDAP تنظیمات اعتماد پشت آن را پوشش می‌دهد.

کتابخانهٔ کلاینت LDAP کدام مخزن اعتماد را می‌خواند؟

کتابخانهٔ کلاینت OpenLDAP پیکربندی اعتماد خودش را می‌خواند، چه از فایل سیستم و چه از تنظیمی مخصوص یک افزونه. دستور CA در VPN برای همتایان VPN اعمال می‌شود و شاهدی بر این نیست که کتابخانهٔ LDAP همان فایل را می‌خواند. از نام میزبان دایرکتوری که گواهی واقعاً پوشش می‌دهد استفاده کنید، به‌همراه زنجیرهٔ صادرکننده‌ای که کتابخانه به آن اعتماد دارد. در Active Directory، گواهی سرویس دایرکتوری را با کاربرد درست احراز هویت سرور مستقر کنید، نه با استدلال از یک نام نمایشی.

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

حساب bind مشکلی جداگانه می‌ماند

محافظت از انتقال چیزی را که حساب bind می‌تواند بکند کاهش نمی‌دهد. دامنهٔ جست‌وجوی دایرکتوری، مجوز گروهی و امتیازات حساب سرویس تصمیم‌های جداگانه‌اند، و یک حساب bind گسترده پس از فعال‌شدن TLS هم گسترده می‌ماند. تنگ‌ترین حساب سرویس و پایهٔ جست‌وجویی را که یکپارچه‌سازی نیاز دارد به کار ببرید و نقطهٔ پایانی، حالت TLS، مالک اعتماد و فرایند تمدید را همراه با پیکربندی VPN ثبت کنید.

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

دو اتصال، دو مالک، دو تاریخ تمدید. جدا نگه داشتن آن‌ها در مستندات همان چیزی است که ورود را صادق نگه می‌دارد.