VPN վկայագիրը չի պաշտպանում LDAP հատվածը

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

Այդ անհամաչափությունն է այն մեխանիզմը, որի հետևում է գաղտնագրված թվացող, բայց bind գաղտնաբառը բաց տեքստով ուղարկող մուտքը։

Երկու կապ, վստահության երկու որոշում

Արտաքին նստաշրջանն այն է, ինչ տեսնում է օգտվողը՝ VPN հոսթի անվանը կապված վկայագիր, որը վավերացվում է հաճախորդի կողմից և կրում է նույնականացման փոխանակումը։ Ներքին նստաշրջանը պատկանում է դարպասի ներսում գտնվող գրացուցակի հաճախորդին, որը բացում է իր սեփական կապը և կա՛մ բանակցում է TLS-ի շուրջ, կա՛մ ոչ։ Յուրաքանչյուր կողմ վավերացնում է այն զրուցակցին, ում հետ խոսում է՝ օգտագործելով այլ կարգավորման ֆայլից ստացված նյութ։ Սխալ կարգավորված ներքին հատվածը մնում է անտեսանելի օգտվողի կողմից, որովհետև արտաքին հատվածն աշխատում է ճիշտ այնպես, ինչպես նախատեսված էր։

Այդ պատճառով խափանումը լուռ է, ոչ աղմկոտ։ Դարպասը, որը երբեք չի ստուգում գրացուցակի վկայագիրը, միևնույն է ճիշտ նույնականացնում է օգտվողներին՝ այն պարզապես նույնականացնում է նրանց մի ալիքով, որը չի ստուգել։

StartTLS և LDAPS՝ ընտրված գիտակցաբար

StartTLS-ը բացվում է որպես սովորական LDAP և թարմացվում տեղում՝ սովորաբար 389 պորտում։ LDAPS-ը TLS-ը սկսում է կապի հետ միասին՝ սովորաբար 636-ում։ Երկուսն էլ օրինական են, և ադապտերը պետք է համապատասխանի այն ամենին, ինչ առաջարկում է գրացուցակը։ StartTLS պահանջելը տարբերվում է այն փորձելուց և թարմացման ձախողման դեպքում շարունակելուց, և հենց այդ տարբերության մեջ կարող է արտահոսել bind գաղտնաբառը։ Կարգավորեք խիստ ռեժիմը և թույլ չտաք գաղտնաբառով bind-ի համար անպաշտպան պահուստային ուղի։

ldapsearch -H ldap://dc1.corp.example -ZZ -x -D "CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example" -W -b "DC=corp,DC=example" "(sAMAccountName=example-user)" dn

-ZZ ընտրանքը հենց ամբողջ իմաստն է՝ հարցումը ձախողվում է՝ փոխարենը լուռ շարունակելու առանց թարմացման։ Այդ տողի անուններն ու հաշիվները օրինակներ են։ OpenLDAP-ի TLS փաստաթղթերը ընդգրկում են դրա հետևում գտնվող վստահության կարգավորումները։

Ո՞ր վստահության պահոցն է կարդում LDAP հաճախորդը։

OpenLDAP հաճախորդի գրադարանը կարդում է իր սեփական վստահության կարգավորումը՝ լինի դա համակարգի ֆայլից, թե հավելվածին հատուկ կարգավորումից։ VPN-ի CA հրահանգը վերաբերում է VPN գործընկերներին և ապացույց չէ, որ LDAP գրադարանը կարդում է նույն ֆայլը։ Օգտագործեք գրացուցակի այն հոսթի անունը, որն իրականում ծածկում է վկայագիրը, գումարած այն թողարկող շղթան, որին վստահում է գրադարանը։ Active Directory-ում տեղակայեք գրացուցակի ծառայության վկայագիր սերվերի նույնականացման ճիշտ կիրառմամբ՝ ցուցադրվող անունից ենթադրելու փոխարեն։

Խափանման պահին յուրաքանչյուր պահուստային նպատակակետ պետք է բավարարի նույն ինքնության քաղաքականությանը։ Այն միջավայրը, որտեղ առաջնայինը վավերացված է, իսկ երկրորդականը՝ ոչ, ավելի վատ է, քան առանց պահուստավորմանը, որովհետև թույլ ուղին բացահայտվում է միայն ընդհատման ժամանակ։

Bind հաշիվը մնում է առանձին խնդիր

Տրանսպորտի պաշտպանությունը չի նվազեցնում այն, ինչ կարող է անել bind հաշիվը։ Գրացուցակի որոնման շրջանակը, խմբային լիազորումը և ծառայության հաշվի արտոնությունները առանձին որոշումներ են, և լայն bind հաշիվը լայն է մնում նաև TLS-ը միացնելուց հետո։ Օգտագործեք ամենանեղ ծառայության հաշիվը և որոնման բազան, որոնք անհրաժեշտ են ինտեգրմանը, և գրանցեք վերջնակետը, TLS ռեժիմը, վստահության սեփականատիրոջը և նորացման գործընթացը VPN կարգավորման հետ միասին։

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

Երկու կապ, երկու սեփականատեր, երկու նորացման ամսաթիվ։ Դրանք փաստաթղթերում առանձին պահելն է, որ մուտքը պահում է ազնիվ։