OpenVPN માં RADIUS જોડવું: પ્લગઇન કે સ્ક્રિપ્ટ હૂક?

પ્લગઇન હજી પણ વર્તમાન બિલ્ડ કરતાં જૂની ચર્ચાઓમાં સૂચવવામાં આવે છે, અને ગઈકાલે કમ્પાઇલ કરેલા સર્વર પર તે લોડ થતી વખતે નિષ્ફળ જાય છે. આ એવી કન્ફિગરેશન ભૂલ નથી જે પાથ વડે સુધારી શકાય. પ્લગઇન અને સ્ક્રિપ્ટ હૂક એક જ સમસ્યાને જુદા જુદા સ્તરે હલ કરે છે, અને એકમાંથી બીજામાં જવાથી બદલાય છે કે શું ઇન્સ્ટોલ કરવું છે, શું સર્વર અધિકારો સાથે ચાલે છે, અને નિષ્ફળ લોગિન તમને ખરેખર શું કહે છે.

દંતકથા: પ્લગઇન જ સમર્થિત માર્ગ છે

પ્લગઇન એ 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 બોલતા ગેટવે પર સમાપ્ત કરે છે, અને તે કિસ્સામાં આ સર્વર નિર્દેશોમાંથી કોઈ પણ લાગુ પડતું નથી. તમારું પોતાનું પ્લેટફોર્મ જે મોડેલનું દસ્તાવેજીકરણ કરે છે તેની નકલ કરો, પડોશી ઉત્પાદનનું નહીં. મહત્વના નિર્દેશો એટલા અલગ છે કે તેમને ભેગા કરવાથી એવી કન્ફિગરેશન બને છે જે પાર્સ થાય છે અને પછી કોઈને પ્રમાણિત કરતી નથી.