Subversion prieglobos apribojimas VPN naudotojams su Apache 2.4

Nukreipus virtualų Subversion prieglobą į VPN adresą, pasikeičia tai, kuri svetainė atsako į užklausą, o ne tai, kam leidžiama ją siųsti. Prieigos patikra atliekama vėliau, pagal taisykles skyriuje, kuris atitiko URL, ir prieglobos pavadinimas niekada neįeina į tą sprendimą. Jei ServerName buvo vienintelis jūsų pakeitimas, saugykla pasiekiama lygiai taip pat kaip vakar. Konfigūracijoje reikia atsakyti į du atskirus klausimus: kuris lizdas priėmė ryšį ir kokią tapatybę nešė užklausa.

Ką ServerName iš tikrųjų nusprendžia

Vardu pagrįstas virtualus prieglobimas lygina Host antraštę su ServerName ir ServerAlias įrašais, parenka vieną prieglobą ir leidžia jai apdoroti užklausą. Pats ryšys buvo priimtas anksčiau serveriui priklausančio Listen lizdo, o ne prieglobos. Todėl privačiai atrodantis vardas nesuteikia jokios apsaugos: bet kuris klientas, pasiekiantis lizdą, gali siųsti tą Host antraštę. Vardas yra maršrutizavimo raktas, o maršrutizavimo raktus renkasi iškvietėjas.

Atvaizdavimą galite matyti neatspėdami. apachectl -S išspausdina kiekvieną prieglobą, jos prievadą ir vardus bei pažymi, kuri yra numatytoji adresui.

RequireAll yra konteineris, kuris abi patikras daro privalomas

Apache 2.4 apgaubia vieno skyriaus Require direktyvas numanomu RequireAny, todėl dvi plikos direktyvos reiškia, kad pakanka bet kurios. Pridėkite konteinerį ir reikšmė apsiverčia:

<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 reikalauja abiejų sąlygų: šaltinio adreso tunelio diapazone ir naudotojo, kurį saugykla priima. Tai turėtų reikšti tik-VPN Subversion URL atveju. mod_authz_core nuoroda dokumentuoja konteinerio taisykles. Palikite bloką esamame saugyklos Location ir palikite vietoje jau veikiančias DAV direktyvas, nes šis fragmentas nekeičia nei AuthType, nei slaptažodžių failo, nei kelio lygio autorizacijos.

Šaltinio patikra ateina iš mod_authz_host, todėl prieš derindami ką nors kita patvirtinkite, kad jis įkeltas: apachectl -M | grep authz_host.

Adresas, kurį Apache vertina, yra lizdo adresas

Require ip lygina su adresu, kurį Apache užfiksavo ryšiui, ir tai ne visada adresas, kurį klientas mano turįs.

Kai VPN maršrutizuoja savo adresus be vertimo, Apache mato tunelio adresą ir 10.8.0.0/24 atitinka. Kai tarpinė sistema verčia, Apache mato tarpinę sistemą ir taisyklė tyliai nieko neatitinka; tas pats vyksta už apkrovos balansuotojo, kuris užbaigia TLS prieš prieglobą. Tam atvejui egzistuoja mod_remoteip. RemoteIPHeader X-Forwarded-For kartu su balansuotojui skirtu RemoteIPTrustedProxy pakeičia užfiksuotą adresą, ir tik tada diapazonas turi su kuo lyginti.

Pasitikėti savavališka persiuntimo antrašte yra blogiau nei neturėti jokios taisyklės. Bet kuris klientas gali siųsti X-Forwarded-For su 10.8.0.9 ir atitikti diapazono patikrą, kuri niekada nebuvo pririšta prie patikimo šuolio.

Sluoksniuokite klausytoją ir saugyklos politiką

Susiejimas yra atskira kontrolė ir dažnai paprastesnė. Listen 10.8.0.1:443 nusprendžia, kurie lizdai egzistuoja, ir užklausa negali pasirinkti prieglobos lizde, kuris niekada nebuvo atidarytas. Kaina yra paleidimo tvarka: jei tunelio sąsaja išjungta, kai Apache paleidžiamas, susiejimas nepavyksta ir paslauga nepasikelia. Susiekite jį su vienetų tvarka arba susiekite su adresu, kuris egzistuoja nepriklausomai nuo tunelio.

Kelio teisės lieka AuthzSVNAccessFile. Galiojanti svetainės paskyra nėra tas pats leidimas kaip rašymo prieiga prie projekto kelio, ir tinklo taisyklė to nekeičia.

Stebėkite skyrių sujungimą, kai blokas yra įtrauktame faile. Apache sujungia autorizacijos konteinerius per įdėtus skyrius ir tiksliausiai atitinkantis skyrius gali pakeisti reikalavimą, o ne jį papildyti, todėl taisyklė /svn gali nepasiekti /svn/repo/trunk, kai siauresnis skyrius apibrėžia savąją.

Įrodykite abu atmetimus, prieš vadindami tai baigtu

Išbandykite keturias užklausas, o ne vieną. VPN viduje su galiojančia paskyra turėtumėte gauti saugyklos sąrašą. VPN viduje su neteisingu slaptažodžiu turėtumėte gauti 401, o ne sąrašą. Iš išorės VPN su galiojančiais prisijungimo duomenimis turėtumėte gauti 403, ir ta pati vieša užklausa į alternatyvų prieglobos vardą turi nepavykti taip pat.

Vienos komandos vienam atvejui pakanka: curl -sI -u user:pass https://svn.example.com/svn/repo/, tada perskaitykite būsenos eilutę. Pakartokite veikiantį atvejį ir su tikru klientu, nes svn info lavina DAV metodus, kuriuos naudos commit ir atnaujinimai.

Jei kuris nors iš keturių rezultatų neatitinka politikos, kurios ketinote, konfigūracija nebaigta, ir prieglobos pervadinimas to nepakeis.