Subversion հոսթի սահմանափակումը VPN օգտվողներով Apache 2.4-ով

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

Ինչ է իրականում որոշում ServerName-ը

Անվան վրա հիմնված վիրտուալ հոսթինգը համեմատում է Host վերնագիրը ServerName և ServerAlias գրառումների հետ, ընտրում է մեկ հոսթ և թույլ է տալիս նրան մշակել հարցումը։ Կապն ինքը ավելի վաղ ընդունվել է Listen սոքեթի կողմից, որը պատկանում է սերվերին, ոչ հոսթին։ Այդ պատճառով մասնավոր թվացող անունը ոչ մի պաշտպանություն չի տալիս. ցանկացած հաճախորդ, որը հասնում է սոքեթին, կարող է ուղարկել այդ Host վերնագիրը։ Անունը երթուղավորման բանալի է, և երթուղավորման բանալիներն ընտրում է կանչողը։

Կարող եք տեսնել քարտեզագրումը առանց գուշակելու։ apachectl -S-ը տպում է յուրաքանչյուր հոսթ, նրա պորտը և անունները և նշում, թե որն է հասցեի համար լռելյայնը։

RequireAll-ը այն տարան է, որը երկու ստուգումներն էլ պարտադիր է դարձնում

Apache 2.4-ը մեկ բաժնի Require հրահանգները փաթաթում է անուղղակի RequireAny-ի մեջ, ուստի երկու մերկ հրահանգ նշանակում է, որ դրանցից ցանկացածը բավարար է։ Ավելացրեք տարան, և իմաստը շրջվում է.

<Location /svn/repo>
    AuthType Basic
    AuthName "Subversion"
    AuthBasicProvider file
    AuthUserFile /etc/apache2/svn.htpasswd
    <RequireAll>
        Require ip 10.8.0.0/24
        Require valid-user
    </RequireAll>
</Location>

RequireAll-ը պահանջում է երկու պայմաններն էլ՝ թունելի տիրույթի ներսում գտնվող աղբյուր հասցե և օգտվող, որին պահոցն ընդունում է։ Սա է, ինչ պետք է նշանակի միայն-VPN-ը Subversion URL-ի համար։ mod_authz_core-ի տեղեկանքը փաստաթղթավորում է տարայի կանոնները։ Թողեք բլոկը պահոցի գոյություն ունեցող Location-ի ներսում և թողեք արդեն աշխատող DAV հրահանգները տեղում, քանի որ այս հատվածը չի փոխարինում ոչ AuthType-ը, ոչ գաղտնաբառի ֆայլը, ոչ ուղու մակարդակի լիազորումը։

Աղբյուրի ստուգումը գալիս է mod_authz_host-ից, ուստի հաստատեք, որ այն բեռնված է նախքան այլ բան վրիպազերծելը. apachectl -M | grep authz_host։

Այն հասցեն, որը Apache-ը գնահատում է, սոքեթի հասցեն է

Require ip-ն համեմատում է այն հասցեի հետ, որը Apache-ը գրանցել է կապի համար, և դա միշտ չէ այն հասցեն, որը հաճախորդը կարծում է, թե ունի։

Երբ VPN-ը երթուղավորում է իր հասցեները առանց թարգմանության, Apache-ը տեսնում է թունելի հասցեն, և 10.8.0.0/24-ը համընկնում է։ Երբ դարպասը թարգմանում է, Apache-ը տեսնում է դարպասը, և կանոնը լուռ ոչնչի հետ չի համընկնում. նույնը տեղի է ունենում հոսթի առջևում TLS-ը վերջացնող բեռնվածքի հավասարակշռիչի հետևում։ Այդ դեպքի համար գոյություն ունի mod_remoteip-ը։ Հավասարակշռիչի համար RemoteIPTrustedProxy-ի հետ միասին RemoteIPHeader X-Forwarded-For-ը փոխարինում է գրանցված հասցեն, և միայն այդ ժամանակ տիրույթն ունի ինչի հետ համեմատելու։

Կամայական փոխանցման վերնագրին վստահելը ավելի վատ է, քան ընդհանրապես կանոն չունենալը։ Ցանկացած հաճախորդ կարող է ուղարկել 10.8.0.9 պարունակող X-Forwarded-For և բավարարել տիրույթի ստուգում, որը երբեք խարսխված չի եղել վստահելի ցատկին։

Շերտավորեք լսողին և պահոցի քաղաքականությունը

Կապումը առանձին հսկողություն է և հաճախ ավելի պարզ։ Listen 10.8.0.1:443-ը որոշում է, թե որ սոքեթներն են գոյություն ունենում, և հարցումը չի կարող ընտրել հոսթ այն սոքեթի վրա, որը երբեք չի բացվել։ Գինը մեկնարկի հերթականությունն է. եթե թունելի ինտերֆեյսը անջատված է Apache-ի մեկնարկի պահին, կապումը ձախողվում է, և ծառայությունը չի բարձրանում։ Զուգակցեք այն միավորների հերթականության հետ կամ կապեք այն հասցեին, որը գոյություն ունի անկախ թունելից։

Ուղու թույլտվությունները մնում են AuthzSVNAccessFile-ում։ Կայքի վավեր հաշիվը նույն թույլտվությունը չէ, ինչ նախագծի ուղու գրելու հասանելիությունը, և ցանցի կանոնը դա չի փոխում։

Ուշադիր եղեք բաժինների միաձուլմանը, երբ բլոկը գտնվում է ներառված ֆայլում։ Apache-ը լիազորման տարաները միաձուլում է ներդրված բաժինների միջով, և ամենակոնկրետ համապատասխան բաժինը կարող է փոխարինել պահանջը՝ դրան ավելացնելու փոխարեն, ուստի /svn-ի կանոնը կարող է չհասնել /svn/repo/trunk-ին, երբ ավելի նեղ բաժինը սահմանում է իր սեփականը։

Ապացուցեք երկու մերժումները նախքան այն ավարտված անվանելը

Փորձարկեք չորս հարցում, ոչ թե մեկը։ VPN-ի ներսում վավեր հաշվով պետք է ստանաք պահոցի ցանկը։ VPN-ի ներսում սխալ գաղտնաբառով պետք է ստանաք 401, այլ ոչ ցանկ։ VPN-ից դուրս վավեր մուտքային տվյալներով պետք է ստանաք 403, և նույն հրապարակային հարցումը այլընտրանքային հոսթի անվանը պետք է նույն կերպ ձախողվի։

Յուրաքանչյուր դեպքի համար մեկ հրամանը բավական է. curl -sI -u user:pass https://svn.example.com/svn/repo/, ապա կարդացեք կարգավիճակի տողը։ Կրկնեք աշխատող դեպքը նաև իրական հաճախորդով, քանի որ svn info-ը վարժեցնում է այն DAV մեթոդները, որոնք կօգտագործեն commit-ները և թարմացումները։

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