نظرة عامة #

نصف القطر or خدمة مصادقة الاتصال الهاتفي عن بعد هو بروتوكول شبكة يوفر إدارة مركزية للمصادقة والتفويض والمحاسبة للمستخدمين والأجهزة. يستخدمه مزودو خدمات الإنترنت والشركات على نطاق واسع للتحكم في الوصول إلى الإنترنت والخدمات المحلية والشبكات اللاسلكية عبر نقاط وصول WiFi، وغيرها.

يتم تنفيذ بروتوكول RADIUS في طبقة التطبيق باستخدام بنية خادم العميل التي يمكنها استخدام TCP أو UDP كطبقة نقل وتتواصل مع قاعدة بيانات المستخدمين مثل نشط الدليل, خدمة LDAP or نظام المحاسبة لينكسالحلول الأكثر شيوعًا لـ RADIUS هي FreeRadius أو Microsoft NPS Radius Server.

بروتوكول المراسلة RADIUS #

تعتمد رسائل البروتوكول على طلب العميل وطريقة استجابة الخادم كما هو موضح أدناه.

1. يرسل العميل طلب الوصول إلى الخادم لكل مستخدم أو جهاز ليتم مصادقته على منفذ الخادم TCP/UDP 1812 (ستستخدم إصدارات الخادم الأقدم 1645 (للمصادقة أيضًا).
2. يرد الخادم وفقًا للسياسة الوصول-القبول إذا تم السماح بالمصادقة، رفض الوصول إذا لم يُسمح بالوصول أو تحدي الوصول إذا كان الخادم يتطلب مزيدًا من المعلومات لتحديد الوصول (مثل التحقق الثاني: رقم التعريف الشخصي، وكلمة المرور، والشهادة، وما إلى ذلك)

اختياريًا، يمكن للعميل والخادم تبادل رسائل المحاسبة مثل طلب المحاسبة و المحاسبة-الاستجابة من أجل الحفاظ على معرف جلسة فريد.

3. يرسل العميل طلب المحاسبة إلى الخادم عبر المنفذ TCP/UDP 1813 لإدارة جلسة المحاسبة (ستستخدم إصدارات الخادم الأقدم 1646 (للمصادقة أيضًا).
4. يرد الخادم بـ المحاسبة-الاستجابة رسالة لتأكيد الجلسة الجديدة.

في بيئة RADIUS، ستكون هناك حاجة إلى خدمة إضافية لإدارة قاعدة بيانات المستخدمين وسيكون من المهم أخذها في الاعتبار في ظل التوفر العالي، والذي سيتم تناوله في مقالة محددة أخرى.

موازنة تحميل RADIUS وبيئة التوفر العالي #

قد تؤدي مشكلة تعطل خدمة RADIUS إلى خطر عدم تمكن المستخدمين من الوصول إلى شبكة الخوادم، أو تسجيل الدخول إلى تطبيق، أو عدم تمكنهم من فتح جلسة على جهاز، أو عدم تمكنهم من الحصول على إذن لاستخدام حق في عملية تجارية. لحل هذه الحالات، تهدف هذه المقالة إلى إعداد البيئة الموضحة أدناه.

RELIANOID سيُشارك رسائل بروتوكول RADIUS بين جميع خوادم RADIUS، سواءً كانت في مواقع مختلفة أو محلية. في الأقسام التالية، سنشرح تكوين هذا النوع من البيئات، وفحوصات السلامة المتقدمة لخدمات RADIUS، والتحديات الأمنية لهذا البروتوكول.

تكوين خدمة RADIUS الافتراضية #

تعتمد طبيعة بروتوكول RADIUS على حزم UDP، لذا يتم إنشاء تكوين بيئة RADIUS الموثوقة باستخدام LSLB مزرعة مع L4xNAT الملف الشخصي في الطبقة 4، المنافذ 1812 و 1813، نوع البروتوكول UDP والمفضل DTA من أجل الحصول على الشفافية والحصول على عنوان IP للعميل في الجانب الخلفي (على الرغم من NAT ينبغي أن يعمل بشكل مثالي أيضًا).

في خانة رمز الخصم، أدخل TABBYDAY. الخدماتلا توجد حاجة إلى الثبات بشكل افتراضي إلا إذا كانت هناك حاجة إلى بعض الالتصاق بين خادم نصف قطر العميل.

إذا تم استخدام 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 or أمان طبقة نقل مخطط البيانات يسمح بتوفير التشفير ومراقبة والتحكم في سياسات الأمان لمثل هذه الحركة.

خيار آخر سيكون RADIUS على TLS الذي يوفر قدرات TCP من حيث الموثوقية وطبقة النقل بالترتيب.

بالنسبة لهذا النوع من الأساليب، ايانا تم إنشاء إدخال رسمي لـ RadSec (أمان RADIUS) لاستخدام UDP 2083 ميناء ل RADIUS/TLS التنفيذ.

خيار آخر هو تعزيز طبقة التلخيص والتفويض باستخدام EAP (بروتوكول المصادقة الموسعة) التي لا يتم استخدامها في طبقة إنشاء الرابط ولكن أثناء مرحلة مصادقة الاتصال، مما يتجنب استخدام خلاصات MD5 الضعيفة.

بالإضافة إلى ذلك ، مع RELIANOIDيمكن حماية خدمات RADIUS باستخدام وحدة IPDS ضد الحزم والمضيفين الضارين وهجمات DoS ومحاولات القوة الغاشمة وغير ذلك الكثير.

إمكانيات وكيل RADIUS #

إذا تم نشر عدة خوادم RADIUS عبر مواقع مختلفة، فسيكون من المفيد توجيه اتصال العميل إلى الموقع الذي يدير بيانات المصادقة والتفويض والمحاسبة. حاليًا، RELIANOID لا يدعم إمكانيات بروكسي RADIUS، ولكن من المقرر إضافته قريبًا. ترقبوا آخر التطورات!

استمتع بخدمات الوصول إلى الشبكة المتاحة والقابلة للتطوير!