نظرة عامة #
بروتوكول RADIUS، أو خدمة مصادقة المستخدم عن بُعد عبر الاتصال الهاتفي، هو بروتوكول شبكي يوفر إدارة مركزية لمصادقة المستخدمين والأجهزة، وتفويض الوصول إليها، وحسابها. ويُستخدم على نطاق واسع من قِبل مزودي خدمات الإنترنت والشركات للتحكم في الوصول إلى الإنترنت، والخدمات المحلية، والشبكات اللاسلكية عبر نقاط وصول الواي فاي، وغيرها.
يُطبَّق بروتوكول RADIUS في طبقة التطبيق باستخدام بنية خادم-عميل، حيث يمكن استخدام بروتوكول TCP أو UDP كطبقة نقل، ويتم التواصل من خلاله مع قاعدة بيانات المستخدمين مثل Active Directory أو خدمة LDAP أو نظام محاسبة Linux . ومن أشهر حلول RADIUS: FreeRadius وMicrosoft NPS Radius Server.
بروتوكول المراسلة RADIUS #
تعتمد رسائل البروتوكول على طلب العميل وطريقة استجابة الخادم كما هو موضح أدناه.
1. يرسل العميل طلب الوصول إلى الخادم لكل مستخدم أو جهاز ليتم مصادقته على منفذ الخادم TCP/UDP 1812 (ستستخدم إصدارات الخادم الأقدم 1645 (للمصادقة أيضًا).
2. يرد الخادم وفقًا للسياسة الوصول-القبول إذا تم السماح بالمصادقة، رفض الوصول إذا لم يُسمح بالوصول أو تحدي الوصول إذا كان الخادم يتطلب مزيدًا من المعلومات لتحديد الوصول (مثل التحقق الثاني: رقم التعريف الشخصي، وكلمة المرور، والشهادة، وما إلى ذلك)
ويمكن للعميل والخادم، اختيارياً، تبادل رسائل المحاسبة مثل Accounting-Request و Accounting-Response من أجل الحفاظ على معرف جلسة فريد.
3. يرسل العميل طلب المحاسبة إلى الخادم عبر المنفذ TCP/UDP 1813 لإدارة جلسة المحاسبة (ستستخدم إصدارات الخادم الأقدم 1646 (للمصادقة أيضًا).
4. يرد الخادم بـ المحاسبة-الاستجابة رسالة لتأكيد الجلسة الجديدة.
في بيئة RADIUS، ستكون هناك حاجة إلى خدمة إضافية لإدارة قاعدة بيانات المستخدمين وسيكون من المهم أخذها في الاعتبار في ظل التوفر العالي، والذي سيتم تناوله في مقالة محددة أخرى.
موازنة تحميل RADIUS وبيئة التوفر العالي #
قد تؤدي مشكلة تعطل خدمة RADIUS إلى خطر عدم تمكن المستخدمين من الوصول إلى شبكة الخوادم، أو تسجيل الدخول إلى تطبيق، أو عدم تمكنهم من فتح جلسة على جهاز، أو عدم تمكنهم من الحصول على إذن لاستخدام حق في عملية تجارية. لحل هذه الحالات، تهدف هذه المقالة إلى إعداد البيئة الموضحة أدناه.
RELIANOID سيُشارك رسائل بروتوكول RADIUS بين جميع خوادم RADIUS، سواءً كانت في مواقع مختلفة أو محلية. في الأقسام التالية، سنشرح تكوين هذا النوع من البيئات، وفحوصات السلامة المتقدمة لخدمات RADIUS، والتحديات الأمنية لهذا البروتوكول.
تكوين خدمة RADIUS الافتراضية #
تعتمد طبيعة بروتوكول RADIUS على حزم UDP، لذلك يتم بناء تكوين بيئة RADIUS موثوقة باستخدام مزرعة LSLB مع ملف تعريف L4xNAT في الطبقة 4، والمنفذين 1812 و 1813 ، ونوع البروتوكول UDP، و DNAT المفضل من أجل الشفافية والحصول على عنوان IP الخاص بالعميل في جانب الواجهة الخلفية (على الرغم من أن NAT يجب أن يعمل بشكل مثالي أيضًا).
في الخدمات ، لا حاجة إلى استمرارية افتراضياً إلا إذا كانت هناك حاجة إلى بعض الترابط بين العميل وخادم radius.
إذا تم استخدام بروتوكول RADIUS عبر TCP بدلاً من UDP، فيمكن تغيير ذلك في حقل نوع البروتوكول. كما يمكن ضبطه على "جميع البروتوكولات" للسماح باستخدام كل من TCP وUDP في الوقت نفسه من نفس عنوان IP الظاهري.
أخيرًا، قم بتكوين الخوادم الخلفية بدون منافذ مُهيأة (لأنها ستستخدم منفذ الوجهة لاتصال العميل) واختبر الاتصال. بعد اكتمال تهيئة خدمة RADIUS الافتراضية، يُمكننا ضبط فحص السلامة المتقدم لهذه الخدمة.
تكوين فحص الصحة المتقدم لـ RADIUS #
يتم تضمين الفحص المسبق في RELIANOID بالاسم check_radius تحت المجلد الافتراضي /usr/local/zenloadbalancer/app/libexec/.
يمكن إدراج مساعدة هذا الأمر في:
root@noid5# /usr/local/zenloadbalancer/app/libexec/check_radius --help اختبار لمعرفة ما إذا كان خادم RADIUS يقبل الاتصالات. الاستخدام: check_radius -H host -F config_file -u username -p password [-P port] [-t timeout] [-r retries] [-e expect] [-n nas-id] [-N nas-ip-addr] الخيارات: -h, --help طباعة شاشة تعليمات مفصلة -V, --version طباعة معلومات الإصدار --extra-opts=[section][@file] قراءة الخيارات من ملف ini. راجع https://www.monitoring-plugins.org/doc/extra-opts.html للاطلاع على الاستخدام والأمثلة. -H، --hostname=ADDRESS اسم المضيف أو عنوان IP أو مقبس يونكس (يجب أن يكون مسارًا مطلقًا) -P، --port=INTEGER رقم المنفذ (الافتراضي: 1645) -u، --username=STRING المستخدم الذي سيتم مصادقته -p، --password=STRING كلمة مرور المصادقة (خطر أمني) -n، --nas-id=STRING معرف NAS -N، --nas-ip-address=STRING عنوان IP لـ NAS -F، --filename=STRING ملف التكوين -e، --expect=STRING سلسلة الاستجابة المتوقعة من الخادم -r، --retries=INTEGER عدد مرات إعادة محاولة اتصال فاشل -t، --timeout=INTEGER الثواني قبل انتهاء مهلة الاتصال (الافتراضي: 10) يختبر هذا المكون الإضافي خادم RADIUS لمعرفة ما إذا كان يقبل الاتصالات. يجب تحديد الخادم الذي سيتم اختباره في الاستدعاء، بالإضافة إلى اسم المستخدم وكلمة المرور. قد يكون ملف التكوين موجودًا أيضًا. صيغته موصوفة في مصادر مكتبة radiusclient. يُمثل خيار كلمة المرور مشكلة أمنية جوهرية، إذ يُمكن تحديد كلمة المرور من خلال مراقبة سطر الأوامر بدقة في قائمة العمليات. ويتفاقم هذا الخطر لأن المكون الإضافي عادةً ما يُنفذ على فترات منتظمة ومتوقعة. يُرجى التأكد من أن كلمة المرور المستخدمة لا تسمح بالوصول إلى موارد النظام الحساسة.
أولاً، دعنا نتحقق مما إذا كان يعمل بشكل صحيح من خلال تنفيذ أمر المثال التالي (يرجى استخدام معلمات تكوين عميل radius الخاصة بك من RELIANOID):
root@noid5# cd /usr/local/zenloadbalancer/app/libexec/ root@noid5# ./check_radius -H -ص -و -ص -ف
سيتم إجراء الاختبار من RELIANOID جهاز إلى خادم RADIUS واحد مع تحقق وهمي من صحة المستخدم، واختياريًا، ملف تكوين عميل لمعلمات عميل محددة. لنختبر الأمر، ثم عندما نحصل على OK من الخادم و بالفشل عندما يكون معطلاً، يمكننا تكوين فحص الصحة المتقدم في الخدمات قسم من الخدمة الافتراضية التي أنشأناها للتو.
لا تنس استخدام ملف HOST الرمز المميز عند تكوين عمليات التحقق من الصحة المتقدمة في RELIANOID كما هو موضح أدناه.
check_radius -H HOST -P 1812 -u johndoe -p johnspass -F /etc/radius_client.cfg
انظر أدناه إلى إعدادات قسم الخدمات.
خيارات أمان RADIUS #
استخدم بروتوكول RADIUS تقليديًا خوارزميات MD5 للتحقق من صحة كل حزمة بيانات وفحص سلامتها عبر UDP. ولأن هاتين الخوارزميتين لا توفران أي تشفير أو حماية أمنية، فقد تمت دراسة عدة مناهج.
نشر RADIUS على أمن بروتوكول الإنترنت or أمان بروتوكول إنترنت تم نشرها على نطاق واسع، ولكن هناك بعض الصعوبات في هذا الخيار، حيث إن طبقة التطبيق لا تدرك سياسات الأمان، لأنها مُضمنة في طبقة الشبكة. لاستخدام هذا النهج مع RELIANOID يتطلب الأمر بعض التكوين اليدوي لأنه لم يتم دمجه بعد.
تتيح مواصفات DTLS أو أمان طبقة نقل البيانات توفير التشفير ومراقبة سياسات الأمان الخاصة بمثل هذه الحركة والتحكم فيها.
خيار آخر هو استخدام RADIUS عبر TLS الذي يوفر إمكانيات TCP من حيث الموثوقية وطبقة النقل بالترتيب.
بالنسبة لهذه الأنواع من الأساليب، أنشأت IANA مدخلاً رسمياً لـ RadSec ( أمان RADIUS ) لاستخدام منفذ UDP 2083 لتطبيقات RADIUS/TLS.
خيار آخر هو تحسين طبقة التجزئة والتفويض باستخدام بروتوكول المصادقة القابل للتوسيع ( EAP ) الذي لا يستخدم في طبقة إنشاء الرابط ولكن أثناء مرحلة مصادقة الاتصال، مما يتجنب استخدام التجزئة الضعيفة MD5.
بالإضافة إلى ذلك ، مع RELIANOIDيمكن حماية خدمات RADIUS باستخدام وحدة IPDS ضد الحزم والمضيفين الضارين وهجمات DoS ومحاولات القوة الغاشمة وغير ذلك الكثير.
إمكانيات وكيل RADIUS #
إذا تم نشر عدة خوادم RADIUS عبر مواقع مختلفة، فسيكون من المفيد توجيه اتصال العميل إلى الموقع الذي يدير بيانات المصادقة والتفويض والمحاسبة. حاليًا، RELIANOID لا يدعم إمكانيات بروكسي RADIUS، ولكن من المقرر إضافته قريبًا. ترقبوا آخر التطورات!
استمتع بخدمات الوصول إلى الشبكة المتاحة والقابلة للتطوير!
