RADIUS-ը OpenVPN-ում միացնելը՝ պլագին, թե սկրիպտ-կեռ?

Պլագինը դեռ խորհուրդ է տրվում ընթացիկ բիլդերից հին թեմաներում, և երեկ կոմպիլացված սերվերում այն ձախողվում է բեռնելիս։ Սա կոնֆիգուրացիայի այնպիսի սխալ չէ, որ ուղու միջոցով ուղղվի։ Պլագինը և սկրիպտ-կեռը նույն խնդիրը լուծում են տարբեր շերտերում, և մեկից մյուսին անցնելը փոխում է, թե ինչ պետք է տեղադրվի, ինչ է աշխատում սերվերի արտոնություններով, և ինչ է իրականում ասում ձախողված մուտքը։

Առասպելը՝ պլագինը աջակցվող ուղին է

Պլագինը համատեղ օբյեկտ է, որը բեռնվում է OpenVPN պրոցեսի մեջ, ուստի այն պետք է համապատասխանի այն ինտերֆեյսին, որը տրամադրում է այդ պրոցեսը։ Բիլդերը փոխվում են, փաթեթավորումը փոխվում է, և հին ինտերֆեյսի համար կոմպիլացված գրադարանը պարզապես հրաժարվում է բեռնվել։ Սերվերի կոնֆիգուրացիայում ոչինչ չի կարող լցնել այդ ճեղքը, դրա համար էլ «ուղղակի տեղադրեք radiusplugin» խորհուրդը ավարտվում է սերվերով, որը չի գործարկվում։

Սկրիպտ-կեռը դրա փոխարեն կանգնած է պրոցեսից դուրս։ OpenVPN-ը գործարկում է ծրագիր, տալիս է նրան մուտքի տվյալները և հետ կարդում դատավճիռ։ Հենց այդ անջատումն է, որ թույլ է տալիս նրան վերապրել թարմացումները, և այն նաև դարձնում է այն ձեր պատասխանատվությունը այնպես, ինչպես պլագինը երբեք չի եղել։

Ոչ մի մոտեցում իր կառուցվածքով ավելի անվտանգ չէ։ Մեկը օտար կոդ է աշխատեցնում դեմոնի ներսում, մյուսը՝ ձեր կոդը կողքին՝ մուտքի տվյալները ձեռքին։ Ճիշտ հարցն այն է, թե այս երկու ռիսկերից որը դուք իսկապես կարող եք կառավարել։

Ինչ էր կապում պլագինը

Պլագինն ուներ իր սեփական կոնֆիգուրացիայի ֆայլը՝ RADIUS հոսթով, համատեղ գաղտնիքով, կրկնությունների քանակով և ժամկետով, և սերվերի կոնֆիգուրացիան նրան հղում էր անում մեկ տողով։ Մուտքի տվյալների մշակումը մնում էր սերվերի պրոցեսի ներսում, ինչը նշանակում էր, որ գաղտնաբառը երբեք չէր հատում պրոցեսի այն սահմանը, որը ադմինիստրատորը պետք է ապահովեր։

Գինը կապվածությունն էր։ OpenVPN-ի յուրաքանչյուր թարմացում ռիսկի էր ենթարկում անհամատեղելի ինտերֆեյս, և յուրաքանչյուր դիստրիբուցիա, որը վերակառուցում էր փաթեթը, ռիսկի էր ենթարկում ստեղծել գրադարան, որն այլևս չի համապատասխանում։ Երբ դա տեղի է ունենում, ձախողումը բարձրաձայն և ակնթարթային է, և դա դիզայնի միակ ողորմությունն է։

Եթե նման պլագին դեռ բեռնվում է ձեր բիլդում, այն կարող է լինել ավելի փոքր գործառնական մակերես։ Հաստատեք այն ինտերֆեյսը, որի համար այն կառուցվել է, պահեք այն ամրացված ձեր փորձարկած բիլդին, և ցանկացած թարմացում դիտեք որպես փոփոխություն, որը պահանջում է ամբողջական մուտքի փորձարկում, այլ ոչ թե սովորական փաթեթի թարմացում։

Ինչի վրա է իրականում վստահում սկրիպտ-կեռը

Կեռը կարգավորվում է auth-user-pass-verify-ով և առաքման մեխանիզմով՝ միջավայրի փոփոխականներ կամ ժամանակավոր ֆայլ։ Միջավայրի ձևում OpenVPN-ը պահանջում է script-security 3՝ փաստաթղթավորված այն մակարդակը, որը թույլ է տալիս գաղտնաբառը բացահայտել սկրիպտներին։ Այդ մակարդակը լռելյայնի դիտավորյալ թուլացում է, և պետք է դիտվի որպես հիմնավորումով կցված թույլտվություն։

Ամեն ինչ, ինչին սկրիպտը դիպչում է, ժառանգում է այդ վստահությունը։ Այն պետք է լինի root-ի սեփականությունը, չլինի գրելի խմբի կամ այլոց կողմից, հղվի բացարձակ ուղով և զերծ լինի ցանկացած այնպիսի տեղից, որտեղ անվստահելի արժեքը հասնում է shell-ին։ Յուրաքանչյուր փոփոխական դրեք չակերտների մեջ, մերժեք անսպասելի նշանները և երբեք հրաման չկառուցեք տրված օգտանունից։ Սկրիպտը, որն ամեն մուտքի փորձի ժամանակ աշխատում է որպես root, արժանի է մեկ վերանայման հենց այդ չորս հատկությունների համար։

ls -l /usr/local/sbin/radius-auth.sh
stat -c '%U %a' /usr/local/sbin/radius-auth.sh

Ֆայլով առաքման ձևը խուսափում է միջավայրի ժառանգման խնդրից և մուտքի տվյալները սահմանափակ իրավունքներով ժամանակավոր ֆայլի միջոցով տալիս է սկրիպտին։ Եթե ձեր կլիենտը դա աջակցում է, սովորաբար սա ավելի լավ լռելյայն է, թեև ձախողման դեպքում ավելացնում է ևս մեկ մաքրելի օբյեկտ։

Ելքի կոդերը որոշում են՝ բաց ձախողվո՞ւմ եք

Սկրիպտի ելքի կարգավիճակը դատավճիռն է՝ զրոն ընդունում է, ոչ զրոն՝ մերժում։ Խնդիր առաջացնող ձևը shell-սկրիպտն է, որը ընդունում է միայն այն ժամանակ, երբ RADIUS-ի պատասխանը պարունակում է որոշակի ընդունման նշան, և մնացած ամեն ինչի համար վերադարձնում է ձախողում, որովհետև դա երեք տարբեր իրադարձություն միաձուլում է մեկ պատասխանի մեջ։ Սխալ գաղտնաբառը, անհասանելի սերվերը և աղավաղված պատասխանը բոլորը դառնում են նույն մերժումը։

Առանձնացրեք այդ դեպքերը սկրիպտում, նույնիսկ եթե կեռը կարող է վերադարձնել միայն ընդունում կամ մերժում։ Գրանցեք backend-ի արդյունքը առանձին, ահազանգեք ժամկետների և տրանսպորտի սխալների համար, և մոնիտորինգում պարզ դարձրեք, երբ նույնականացումը ձախողվում է ծառայության անջատված լինելու պատճառով, այլ ոչ թե օգտվողների սխալ մուտքագրելու։

Երկու սովորություն առողջ են պահում մնացածը։ Եթե RADIUS-ը իշխանությունն է, ապա այն պետք է լինի միակ տեղը, որտեղ գաղտնաբառ է ստուգվում, որովհետև ստվերային աղյուսակը նույն հարցին երկու պատասխան է ստեղծում, և երկրորդը հարձակման մակերես է, որին ոչ ոք չի հետևում։ Եվ հիշեք, որ կեռը կրկին կանչվում է ամեն նոր փորձի ժամանակ, ուստի դանդաղ սկրիպտը անհամբեր կլիենտի հետ դառնում է գաղտնաբառերի գուշակման ուժեղացուցիչ, եթե ուշացում կամ քաղաքականություն չավելացնեք RADIUS-ի կողմում։

Ինչից եք հրաժարվում, երբ վկայագիրը անհետանում է

Այս ձևի շատ տեղաբաշխումներ ամբողջությամբ անջատում են կլիենտի վկայագրի ստուգումը՝ թողնելով օգտանուն և գաղտնաբառ որպես կլիենտի ամբողջ պահանջ։ Այդ կարգավորումով անհետանում է վկայագրի վրա հիմնված ինքնությունը։ Ալիքը մնում է կոդավորված, բայց միակ բանը, որ անվանում է կլիենտին, RADIUS-ի դատավճիռն է։ Ամեն ինչ ներքևում, ինչ նախկինում հիմնված էր վկայագրի սուբյեկտի վրա, այժմ պետք է հիմնված լինի օգտանվան վրա։

Պահեք կառավարման ալիքի պաշտպանությունը, որպեսզի չնույնականացված զուգընկերը չկարողանա հետազոտել կամ ողողել ձեռքսեղմումը, և օգտագործեք username-as-common-name, երբ օգտվողական կոնֆիգուրացիան կախված է ընդհանուր անունից։ Կառավարվող դարպասները դա հաճախ լուծում են այլ կերպ՝ ավարտելով վկայագրի նույնականացումը դարպասում, որը EAP-TLS է խոսում RADIUS-ի հետ, և այդ դեպքում այս սերվերի հրահանգներից ոչ մեկը չի կիրառվում։ Պատճենեք այն մոդելը, որը փաստաթղթավորում է ձեր սեփական հարթակը, ոչ թե հարևան արտադրանքի մոդելը։ Կարևոր հրահանգները բավական տարբերվում են, որ դրանց խառնումը ստեղծում է կոնֆիգուրացիա, որը վերլուծվում է և հետո ոչ ոքի չի նույնականացնում։