ProtectHome ընդդեմ TOTP-սերմի. ինչու է VPN մուտքը ձախողվում

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

Երեք ձախողումներից ո՞րն է սա։

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

Տարանջատեք դրանք՝ կարդալով ծառայության մատյանը և համակարգի նույնականացման մատյանը մեկ ձախողված փորձի համար, ապա հաստատեք, թե որ PAM ծառայությունն է բեռնում հավելումը և որ մոդուլի տողն է օգտագործում այդ ծառայությունը։ Ընդհանուր նույնականացման ձախողման հաղորդագրությունը չի տարբերում դրանք, ինչպես և հաջող ձեռքով փորձարկումը, որովհետև ձեր shell-ը ծառայության միջավայրը չէ։

Միավորի ֆայլային համակարգի տեսքը սովորական մեղավորն է, երբ ձախողվում է միայն ծառայությունը։

systemctl show -p ProtectHome -p ProtectSystem -p ReadWritePaths [email protected]
ls -l /var/lib/vpn-otp/*/.google_authenticator 2>/dev/null | head -n 20

Տարբերակ A. գաղտնիքը տնից դուրս բերել

Երբ ծառայությունը թաքցնում է /home-ը, և դուք նախընտրում եք պահպանել այդ պաշտպանությունը, պահեք գաղտնիքը այնտեղ, որտեղ այն կարող է տեսնել։ Մոդուլը ընդունում է secret= ուղի և user= հաշիվ, որը կատարում է ֆայլային գործողությունները, ինչը թույլ է տալիս կենտրոնական պահոցին սպասարկել շատ ինքնություններ։

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

auth required pam_google_authenticator.so secret=/var/lib/vpn-otp/${USER}/.google_authenticator user=vpn-otp

Նախքան վստահելը ստուգեք երեք բան՝ հաշիվը գոյություն ունի, մոդուլի աշխատանքային գործընթացը կարող է անցնել դրան, և ֆայլերը պատկանում են նրան սահմանափակող ռեժիմներով։ Չօգտագործեք ~ կամ տնային փոփոխականի ուղի user=-ի հետ միասին, և մի անջատեք մոդուլի սեփականության ստուգումները՝ ուղին աշխատեցնելու համար։ Պահեք գաղտնաբառի փուլը և մնացած շերտը անձեռնմխելի։

Տարբերակ B. թողնել ֆայլը և բացել ուղի

Եթե գաղտնիքը պետք է մնա օգտվողի տնային գրացուցակում, միավորը պետք է տեսք, որը ներառում է այդ մեկ գրացուցակը՝ չբացահայտելով հյուրընկալողի բոլոր տները։ drop-in-ը կարող է ավելացնել նեղ սահմանափակ bind mount sandbox արված տան տակ։

Սա պահպանում է յուրաքանչյուր օգտվողի սեփականությունը որպես մոդել՝ միավորի փոփոխության հաշվին, որը պետք է վերանայվի ամեն անգամ, երբ փոխվում է sandbox-ը։

Երկու սահման հեշտ է բաց թողնել։ Sandbox-ի թաքցրած գրացուցակի տակ ավելացված միայն-կարդալու ուղին չի բացահայտում այն, որովհետև ծնողը պարզապես այնտեղ չէ։ Եվ ամրացումը պետք է գրելի լինի, եթե մոդուլը պետք է թարմացնի վիճակը, ինչը խաղի մեջ է բերում հաջորդ տարբերակը։ Գրեք drop-in-ը որպես առանձին ֆայլ, փոխարենը չխմբագրեք /usr/lib-ի տակ գտնվող փաթեթավորված միավորը, որպեսզի փաթեթի թարմացումը լուռ չչեղարկի այն։

Տարբերակ C. պահել sandbox-ը և ուղղել վիճակի գրառումները

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

Այդ ձախողումը հաջորդ փորձի ժամանակ վատ կոդի տեսք ունի, ոչ թե այս փորձի, ինչի պատճառով այն շփոթում են ժամացույցի շեղման հետ։

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

Ստուգեք որպես ծառայություն, ոչ թե որպես ինքներդ

Յուրաքանչյուր կարևոր ստուգում պետք է անցնի միավորի sandbox-ի ներսում՝ միավորի ինքնությամբ։

root-ով հաջողված հրամանը ձեզ ասում է, որ ֆայլը գոյություն ունի, և ոչ ավելին։ Իրական ծառայության միջով մուտքը ձեզ ասում է՝ արդյոք մոդուլը կարող է կարդալ գաղտնիքը, օգտագործել այն և հետ գրել այն, ինչ պետք է։

Վերջապես, պահեք պահանջը անձեռնմխելի։ Զրո-գաղտնաբառի տարբերակ ավելացնելը, միայն-կարդալու ձախողումները ընդունելը կամ sandbox-ը հեռացնելը բոլորը կվերացնեին ախտանիշը՝ փոխելով քաղաքականությունը։ Կոդ ներկայացնելու պարտավոր օգտվողը պետք է մերժվի նաև այն ժամանակ, երբ գաղտնիքն անհասանելի է։