اتصال RADIUS به OpenVPN: افزونه یا قلاب اسکریپت؟
افزونه قدیمی RADIUS به نسخه سروری که برایش کامپایل شده گره خورده است. قلاب auth-user-pass-verify جای آن را میگیرد، اما اعتماد را به اسکریپت شما منتقل میکند.
افزونه هنوز در بحثهایی که قدیمیتر از نسخههای فعلی هستند توصیه میشود، و روی سروری که دیروز کامپایل شده هنگام بارگذاری شکست میخورد. این خطای پیکربندی نیست که با یک مسیر درست شود. افزونه و قلاب اسکریپت همان مشکل را در لایههای متفاوت حل میکنند، و جابهجایی از یکی به دیگری تغییر میدهد چه چیزی باید نصب شود، چه چیزی با اختیارات سرور اجرا میشود و ورود ناموفق واقعاً چه چیزی به شما میگوید.
افسانه: افزونه مسیر پشتیبانیشده است
افزونه یک شیء مشترک است که در فرایند OpenVPN بارگذاری میشود، پس باید با واسطی که آن فرایند ارائه میدهد سازگار باشد. نسخهها تغییر میکنند، بستهبندی تغییر میکند، و کتابخانهای که برای واسط قدیمیتر کامپایل شده بهسادگی از بارگذاری امتناع میکند. هیچ چیز در پیکربندی سرور نمیتواند این شکاف را پر کند، به همین دلیل توصیه «فقط radiusplugin را نصب کن» با سروری تمام میشود که بالا نمیآید.
قلاب اسکریپت بهجای آن بیرون از فرایند قرار دارد. OpenVPN برنامهای را اجرا میکند، اعتبارنامهها را به آن میدهد و حکمی را بازمیخواند. همین جداسازی است که به آن اجازه میدهد از ارتقاها جان سالم به در ببرد، و همان است که آن را به شکلی مسئولیت شما میکند که افزونه هرگز نبود.
هیچکدام از دو رویکرد بهخاطر ساختارش امنتر نیست. یکی کد بیگانه را درون دیمن اجرا میکند؛ دیگری کد شما را کنارش با اعتبارنامه در دست اجرا میکند. پرسش درست این است که کدامیک از این دو ریسک را واقعاً میتوانید اداره کنید.
افزونه چه چیزهایی را به هم میبست
افزونه فایل پیکربندی خودش را با میزبان RADIUS، راز مشترک، تعداد تلاش و مهلت زمانی داشت و پیکربندی سرور با یک خط به آن ارجاع میداد. پردازش اعتبارنامه درون فرایند سرور میماند، یعنی گذرواژه هرگز از مرز فرایندی که مدیر باید ایمن میکرد عبور نمیکرد.
هزینه، وابستگی بود. هر ارتقای OpenVPN خطر واسط ناسازگار را داشت و هر توزیعی که بسته را بازمیساخت خطر تولید کتابخانهای را داشت که دیگر سازگار نیست. وقتی این رخ میدهد، شکست پرصدا و فوری است و این تنها لطف طراحی است.
اگر چنین افزونهای هنوز روی نسخه شما بارگذاری میشود، میتواند سطح عملیاتی کوچکتری باشد. واسطی را که برایش ساخته شده تأیید کنید، آن را به نسخهای که آزمایش کردهاید سنجاق کنید و هر ارتقا را تغییری بدانید که آزمون کامل ورود میخواهد، نه بهروزرسانی روتین بسته.
قلاب اسکریپت واقعاً به چه چیزی اعتماد میکند
قلاب با auth-user-pass-verify و یک سازوکار تحویل پیکربندی میشود: متغیرهای محیطی یا یک فایل موقت. در شکل محیطی، OpenVPN سطح script-security 3 را میخواهد، سطح مستندشدهای که افشای گذرواژه به اسکریپتها را مجاز میکند. این سطح تضعیف عامدانه پیشفرض است و باید بهعنوان اجازهای با توجیه پیوست تلقی شود.
هر چیزی که اسکریپت لمس میکند آن اعتماد را به ارث میبرد. باید متعلق به root باشد، برای گروه یا دیگران قابل نوشتن نباشد، با مسیر مطلق ارجاع شود و از هر جایی که مقدار غیرقابلاعتماد به پوسته میرسد خالی باشد. هر متغیر را در گیومه بگذارید، نویسههای غیرمنتظره را رد کنید و هرگز از نام کاربری ارائهشده فرمانی نسازید. اسکریپتی که در هر تلاش ورود بهعنوان root اجرا میشود ارزش یک بازبینی را دقیقاً بهخاطر همان چهار ویژگی دارد.
ls -l /usr/local/sbin/radius-auth.sh
stat -c '%U %a' /usr/local/sbin/radius-auth.sh
شکل تحویل فایلی از مشکل وراثت محیطی پرهیز میکند و اعتبارنامهها را از طریق فایل موقت با مجوزهای محدود به اسکریپت میدهد. اگر کلاینت شما آن را پشتیبانی میکند، معمولاً پیشفرض بهتری است، هرچند در صورت شکست یک شیء دیگر برای پاکسازی اضافه میکند.
کدهای خروج تعیین میکنند آیا باز شکست میخورید
وضعیت خروج اسکریپت همان حکم است: صفر میپذیرد، غیرصفر رد میکند. الگویی که دردسر میسازد اسکریپت پوستهای است که فقط وقتی میپذیرد که پاسخ RADIUS توکن پذیرش مشخصی داشته باشد و برای بقیه شکست برمیگرداند، چون سه رویداد متفاوت را در یک پاسخ ادغام میکند. گذرواژه اشتباه، سرور دسترسیناپذیر و پاسخ بدشکل همه یک رد شدن میشوند.
این موارد را در اسکریپت جدا کنید حتی اگر قلاب فقط بتواند پذیرش یا رد برگرداند. نتیجه بکاند را جدا ثبت کنید، برای مهلتها و خطاهای انتقال هشدار بگذارید و در پایش روشن کنید وقتی احراز هویت شکست میخورد چون سرویس پایین است نه چون کاربران اشتباه تایپ میکنند.
دو عادت بقیه را سالم نگه میدارد. اگر RADIUS مرجع است، باید تنها جایی باشد که گذرواژه بررسی میشود، چون جدول سایه دو پاسخ به یک پرسش میدهد و دومی سطح حملهای است که کسی نمیپاید. و یادتان باشد قلاب در هر تلاش دوباره فراخوانی میشود، پس اسکریپت کند همراه با کلاینت بیحوصله به تقویتکننده حدس گذرواژه تبدیل میشود مگر اینکه تأخیر یا سیاستی در سمت RADIUS اضافه کنید.
وقتی گواهی میرود از چه چیزی دست میکشید
بسیاری از استقرارها در این شکل بررسی گواهی کلاینت را کاملاً خاموش میکنند و نام کاربری و گذرواژه را تمام ادعای کلاینت میگذارند. چیزی که با این تنظیم ناپدید میشود هویت مبتنی بر گواهی است. کانال رمزنگاریشده میماند، اما تنها چیزی که کلاینت را نام میبرد حکم RADIUS است. هر چیزی در پاییندست که پیشتر به موضوع گواهی تکیه میکرد اکنون باید به نام کاربری تکیه کند.
حفاظت کانال کنترل را نگه دارید تا همتای احرازنشده نتواند دستدادن را کاوش یا سیلآسا کند، و وقتی پیکربندی هر کاربر به نام مشترک وابسته است از username-as-common-name استفاده کنید. دروازههای مدیریتشده اغلب این را متفاوت حل میکنند و احراز هویت گواهی را در دروازهای تمام میکنند که با RADIUS به EAP-TLS صحبت میکند، و در آن صورت هیچیک از این دستورهای سرور اعمال نمیشود. مدلی را که پلتفرم خودتان مستند میکند کپی کنید، نه مدل یک محصول همسایه. دستورهایی که اهمیت دارند بهقدری متفاوتاند که مخلوط کردنشان پیکربندیای میسازد که تجزیه میشود و سپس هیچکس را احراز نمیکند.