סקירה כללית #
RADIUS או שירות משתמש חיוג-אין לאימות מרחוק הוא פרוטוקול רשת המספק אימות, הרשאה וחשבונאות של משתמשים ומכשירים וניהול מרכזי. הוא נמצא בשימוש נרחב על ידי ספקי שירותי אינטרנט וארגונים כדי לשלוט בגישה לאינטרנט, שירותים מקומיים ורשתות אלחוטיות דרך נקודות גישה WiFi וכו'.
פרוטוקול RADIUS מיושם בשכבת היישומים עם ארכיטקטורת לקוח-שרת שיכולה להשתמש ב-TCP או UDP כשכבת תעבורה ומתקשרת עם מסד נתונים של משתמשים כמו Active Directory , שירות LDAP או מערכת חשבונאות לינוקס . פתרונות RADIUS הפופולריים ביותר הם FreeRadius או Microsoft NPS Radius Server.
פרוטוקול העברת הודעות של RADIUS #
העברת הפרוטוקולים מבוססת על בקשת הלקוח ואופן תגובת השרת כפי שמוצג להלן.
1. הלקוח שולח בקשת גישה לשרת עבור כל משתמש או מכשיר להיות מאומתים ליציאת השרת TCP / UDP 1812 (גרסאות שרת מבוגר ישתמשו 1645 לאימות גם כן).
2. השרת עונה על פי המדיניות קבל גישה אם האימות מותר, גישה לדחייה אם הגישה אינה מותרת או גישה לאתגר אם השרת דורש מידע נוסף על מנת לקבוע את הגישה (כמו אימות שני: PIN, סיסמה, אישור וכו ')
באופן אופציונלי, הלקוח והשרת יכולים להחליף הודעות חשבונאיות כמו בקשת חשבונאות ותשובה לחשבונאות על מנת לשמור על מזהה סשן ייחודי.
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 אמור לעבוד בצורה מושלמת).
ב- Services , אין צורך בהתמדה כברירת מחדל אלא אם כן נדרשת דביקות מסוימת בין רדיוס הלקוח לשרת.
אם משתמשים ב-RADIUS דרך TCP במקום UDP, ניתן לשנות זאת בשדה סוג הפרוטוקול. ניתן להגדיר זאת גם כ- ALL הפרוטוקולים כדי לאפשר גם 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 שם משתמש -p סיסמה [-P port] [-t timeout] [-r מנסה שוב] [-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 המשתמש אל authenticate -p, --password=STRING סיסמה לאימות (SECURITY RISK) -n, --nas-id=STRING מזהה NAS -N, --nas-ip-address=STRING NAS כתובת IP -F, --filename= קובץ תצורה של STRING -e, --expect=STRING מחרוזת תגובה שיש לצפות מהשרת -r, --retries=INTEGER מספר הפעמים לניסיון חוזר של חיבור כושל -t, --timeout=INTEGER שניות לפני זמן קצוב החיבור (ברירת מחדל: 10) תוסף זה בודק שרת RADIUS כדי לראות אם הוא מקבל חיבורים. יש לציין את השרת לבדיקה בהזמנה, כמו גם שם משתמש וסיסמה. ייתכן שקיים גם קובץ תצורה. הפורמט של קובץ התצורה מתואר במקורות ספריית radiusclient. אפשרות הסיסמה מציגה בעיית אבטחה מהותית מכיוון שניתן לקבוע את הסיסמה על ידי צפייה זהירה בשורת הפקודה ברישום תהליך. הסיכון הזה מוגבר מכיוון שהתוסף יתבצע בדרך כלל במרווחי זמן קבועים הניתנים לחיזוי. אנא ודא שהסיסמה שבה נעשה שימוש אינה מאפשרת גישה למשאבי מערכת רגישים.
ראשית, בוא נבדוק אם הוא פועל כהלכה על ידי ביצוע הפקודה הבאה לדוגמה (אנא השתמש בפרמטרים משלך לתצורת לקוח רדיוס מ RELIANOID):
root@noid5# cd /usr/local/zenloadbalancer/app/libexec/ root@noid5# ./check_radius -H -פ -u -עמ' -פ
הבדיקה תיעשה מ 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 מעל IPsec or אבטחה פרוטוקול אינטרנט נפרסו באופן נרחב אך ישנם כמה קשיים של אפשרות זו מכיוון ששכבת היישום אינה מודעת למדיניות האבטחה, מכיוון שהיא מרומזת בשכבת הרשת. להשתמש בגישה זו עם RELIANOID נדרשת תצורה ידנית כלשהי מכיוון שהיא עדיין לא משולבת.
המפרט של DTLS או Datagram Transport Layer Security מאפשר לספק הצפנה, ניטור ובקרה של מדיניות האבטחה של תעבורה כזו.
אפשרות נוספת תהיה RADIUS על פני TLS המספקת יכולות TCP של אמינות ושכבת תעבורה לפי סדר.
עבור גישות מסוג זה, IANA יצרה ערך רשמי עבור RadSec ( RADIUS Security ) לשימוש ביציאת UDP 2083 עבור יישומי RADIUS/TLS .
אפשרות נוספת תהיה לשפר את שכבת התקציר והאימות באמצעות EAP ( Extensible Authentication Protocol ) שאינו משמש בשכבת יצירת הקישור אלא בשלב אימות החיבור, תוך הימנעות משימוש בתקצירים חלשים של MD5.
בנוסף, עם RELIANOID, ניתן להגן על שירותי RADIUS באמצעות מודול ה-IPDS מפני מנות זדוניות ומארחים, התקפות DoS, ניסיונות כוח גס ועוד הרבה יותר.
RADIUS יכולות פרוקסי #
אם מספר שרתי RADIUS פרוסים באתרים שונים, יהיה מעניין להעביר את חיבור הלקוח לאתר שמנהל את נתוני האימות, ההרשאות והחשבונאות שלהם. כַּיוֹם, RELIANOID אינו תומך ביכולות פרוקסי RADIUS אך הוא מתוכנן להיכלל בקרוב. צפו להתפתחויות האחרונות!
באפשרותך ליהנות משירותי הגישה לרשת שלך הזמינים והגדולים!
