VPN հասցեին կապված NFS արտահանում՝ ինչ այն չի ապացուցում
Արտահանման կանոնը ստուգում է, թե որտեղից է եկել փաթեթը. AUTH_SYS-ը հայտարարում է տեղական UID, իսկ Kerberos-ը նույնականացնում է օգտատիրոջը։ Որոշեք, թե ձեր ֆայլային ծառայությանը որն է պետք։
Հոսթը գրացուցակ է արտահանում VPN հասցեին, միացումը հաջողվում է, և նախագիծը գրանցվում է որպես նույնականացված։ Սակայն այդ կանոնը իրականում սահմանափակում է միայն այն, թե որտեղից են փաթեթները կարծես գալիս։ Թե արդյոք ֆայլային գործողությունը ղեկավարող անձը հենց այն է, ում նա ներկայացնում է, կախված է NFS անվտանգության երանգից, և նման արտահանումների մեծ մասում ոչ ոք այն չի փոխել լռելյայնից։
Մեկ հարցման մեջ կարող են հայտնվել երեք ինքնություն
VPN զուգընկերը կրում է գրանցված ինքնություն, օրինակ՝ հաճախորդի վկայական կամ զուգընկերի բանալի։ Ներքին IP փաթեթը կրում է աղբյուրի հասցե։ Ֆայլային գործողությունը կրում է այն օգտատիրոջ հավատարմագրերը, որոնք տալիս է նրա NFS մեխանիզմը։ Այն նախագիծը, որը հասցեն դիտարկում է որպես երեքի փոխարինող, լուռ ենթադրել է հենց այն մասը, որը պետք էր ստուգել։
| Identity | What it proves | What it does not |
|---|---|---|
| VPN peer | Which peer was accepted by the tunnel | Which user runs on that machine |
| Inner source address | Where the packet appears to originate | That only the intended client can use it |
| NFS credential | What the file service believes about the caller | Anything, if the flavour only asserts local IDs |
Այդ երեք տողերի գրառումը ողջ վարժությունն է։ Արտահանումն անվտանգ է, թե ոչ՝ վեճի մեծ մասը փլուզվում է, հենց պարզ է դառնում, թե որ տողում է ապրում յուրաքանչյուր վերահսկողություն։
Հասցեի սեփականությունը իրականացման մանրամասն է
Դարպասը կարող է թունելի հասցե տրամադրել ընդունված զուգընկերոջը կամ նրա համար լիազորել երթուղավորված ենթացանց։ Թե արդյոք իրականացումը հետո մերժում է փաթեթ, որի ներքին աղբյուրը պատկանում է այլ հաճախորդի, այդ իրականացման հատկությունն է, և արժե ստուգել, ոչ թե ենթադրել։
Ավանդական Community OpenVPN օգտատիրոջ տարածության սերվերի կոդը, օրինակ, կարող է մերժել այլ հաճախորդի հետ կապված աղբյուրը, նախքան փաթեթը TUN սարքի միջով կհանձնվի։ Դա իրական արժեք ունեցող հասցեի սեփականության ստուգում է, և այն դեռ NFS օգտատիրոջ նույնականացում չէ, որովհետև ոչինչ չի ասում, թե որ հաշիվն է կատարում գործողությունը։
Աղբյուրի թարգմանությունը քայքայում է նույնիսկ դա։ NAT դարպասը կարող է յուրաքանչյուր հաճախորդի ներկայացնել որպես մեկ հասցե, և այդ ժամանակ արտահանման կանոնը չի կարող տարբերել նրա հետևում գտնվող մարդկանց։ Կանոնի ակնհայտ ճշգրտությունը այնուհետև դառնում է սխեմայով պահվող հորինվածք։ Եթե արտահանումը կարևոր է, պահեք հասցեավորումը բացահայտ, փոխարենը թույլ չտալով թարգմանչին որոշել, թե ով ում փոխարեն է հաշվվում։
Կարդացեք անվտանգության երանգը, նախքան արտահանմանը վստահելը
Red Hat-ի NFS ուղեցույցը առանձնացնում է sec=sys-ը, որն օգտագործում է տեղական UNIX UID և GID՝ AUTH_SYS-ի միջոցով, Kerberos ռեժիմներից։ krb5-ը ավելացնում է օգտատիրոջ նույնականացում, krb5i-ը՝ ամբողջականության պաշտպանություն, իսկ krb5p-ը՝ երթևեկության գաղտնիության պաշտպանություն։
AUTH_SYS հավատարմագրերը պարունակում են դաշտեր, ինչպիսիք են կանչողի UID-ն և խմբի նույնացուցիչները, և RFC 5531-ը բացահայտ զգուշացնում է, որ այս երանգն ինքնին անվտանգություն չի ապահովում և կախված է արտաքին պաշտպանությունից։ VPN-ի ներսում դրա աշխատեցումը պաշտպանություն է տալիս տրանսպորտին և ոչինչ չի փոխում փաթեթի ներսում եղած պնդման մեջ։
exportfs -v
showmount -e nfs.example.internalԿարդացեք երանգը այդ ելքում, նախքան հաճախորդների ցանկը կարդալը։ Սահմանափակ թվացող արտահանումը կարող է սահմանափակված լինել միայն հասցեով, մինչդեռ յուրաքանչյուր կանչող դեռ հայտարարում է ցանկացած UID։
Ընտրեք մոդելը, ապա պահեք թույլտվությունները
Ընտրեք ֆայլային ծառայության նույնականացման այն մոդելը, որը համապատասխանում է ձեր փաստացի կառավարած հաճախորդներին։ Kerberos-ը պահանջում է ինքնություն և ծառայության տեղակայում իր հետևում, ուստի մեկ միացման ընտրանքի փոփոխությունը միգրացիա չէ և պարզապես կձախողվի, քանի դեռ չկան Kerberos տիրույթը, պրինցիպալները և keytab-ները։
Երկու մոդելների դեպքում էլ պահեք արտահանման թույլտվությունները և ֆայլային համակարգի լիազորումը, որոնք սահմանափակում են, թե ինչ կարող է անել նույնականացված պրինցիպալը։ Նույնականացումը ասում է, թե ով է հարցնում՝ լիազորումը որոշում է՝ պատասխանը պետք է լինի այո, թե ոչ։ Այս երկուսը մեկ կարգավորման մեջ միավորելն այն ուղին է, որով միգրացիան ի վերջո տալիս է ավելին, քան տալիս էր հին կոնֆիգուրացիան։
Օգտագործեք հասցեի կանոնը իր իրական նպատակի համար
Ծառայությունը հաստատված ուղուն և աղբյուրներին սահմանափակելը դեռ արժեքավոր է, ներառյալ հոսթի մուտքի քաղաքականությունը, երբ VPN վերջնակետը և NFS սերվերը կիսում են մեքենան։ Փոխանցում կատարող կանոնները չեն կառավարում ուղղված հարցումները դեպի նույն հոսթի վրա տեղում աշխատող ծառայություն։ Այդ բացը բացատրում է զարմանալի թվով արտահանումներ, որոնք նախատեսված էին մասնավոր լինել։ Ստուգեք տեղական մուտքի քաղաքականությունը բացահայտ, փոխարենը ենթադրելով, թե թունելի կանոնները ծածկում են այն։
Ստուգեք, որ մեկ այլ ինտերֆեյս կամ աղբյուրի թարգմանություն կատարող դարպաս չի կարող անսպասելիորեն բավարարել կանոնը, և դա դիտարկեք որպես ծագումը հաստատելու պատճառ, ոչ թե պնդում, թե հասցեի կեղծումը երաշխավորում է աշխատող միացում։
Անցկացրեք ընդունման երեք դեպք՝ մեկի փոխարեն։ Սկսեք հաստատված հաճախորդով, որը հանդես է գալիս որպես հաստատված օգտատեր, ապա կրկնեք երբեք չհաստատված զուգընկերոջից, ապա փորձեք մի բան, ինչը հաստատված օգտատերը դեռ չի կարող անել։ Դրանից հետո հարցրեք, թե ինչ է փոխվում, եթե լիազորված հաճախորդը վտանգվի, որովհետև տրանսպորտի նույնականացումը այդ մեքենայի յուրաքանչյուր գործընթաց վստահելի չի դարձնում։ Գողացված վկայականը և հետաքրքրասեր տեղական հաշիվը տարբեր խնդիրներ են՝ տարբեր վերահսկողություններով։