Omejite gostitelja Subversion na uporabnike VPN z Apache 2.4

ServerName izbere navideznega gostitelja, ne omejuje pa, kdo se poveže. Zahtevajte obseg VPN in resničnega uporabnika repozitorija, nato dokažite obe zavrnitvi.

Usmerjanje navideznega gostitelja Subversion na naslov VPN spremeni, katera stran odgovori na zahtevo, ne pa, kdo jo sme poslati. Preverjanje dostopa se zgodi pozneje, po pravilih v razdelku, ki se je ujemal z URL-jem, in ime gostitelja nikoli ne vstopi v to odločitev. Če je bil ServerName vaša edina sprememba, je repozitorij enako dosegljiv kot včeraj. V konfiguraciji je treba odgovoriti na dve ločeni vprašanji: katera vtičnica je sprejela povezavo in katero identiteto je nosila zahteva.

Kaj ServerName dejansko odloči

Navidezno gostovanje na podlagi imena primerja glavo Host z vnosi ServerName in ServerAlias, izbere enega gostitelja in mu dovoli obdelati zahtevo. Sama povezava je bila sprejeta prej na vtičnici Listen, ki pripada strežniku, ne gostitelju. Zato ime, ki izgleda zasebno, ne nudi nobene zaščite: vsak odjemalec, ki doseže vtičnico, lahko pošlje to glavo Host. Ime je usmerjevalni ključ, usmerjevalne ključe pa izbere klicatelj.

Preslikavo lahko vidite brez ugibanja. apachectl -S izpiše vsakega gostitelja, njegova vrata in imena ter označi, kateri je privzeti za naslov.

RequireAll je vsebnik, ki oba preverjanja naredi obvezna

Apache 2.4 ovije direktive Require enega razdelka v implicitni RequireAny, zato dve goli direktivi pomenita, da zadošča katera koli. Dodajte vsebnik in pomen se obrne:

<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 zahteva oba pogoja: naslov vira v obsegu predora in uporabnika, ki ga repozitorij sprejme. To bi moralo pomeniti samo-VPN za URL Subversion. Referenca mod_authz_core dokumentira pravila vsebnika. Pustite blok v obstoječem Location za repozitorij in pustite direktive DAV, ki že delujejo, na svojem mestu, ker ta delček ne nadomesti niti AuthType niti datoteke z gesli niti pooblastila na ravni poti.

Preizkus vira prihaja iz mod_authz_host, zato pred razhroščevanjem česa drugega potrdite, da je naložen: apachectl -M | grep authz_host.

Naslov, ki ga Apache ovrednoti, je naslov vtičnice

Require ip primerja z naslovom, ki ga je Apache zabeležil za povezavo, in to ni vedno naslov, za katerega odjemalec misli, da ga ima.

Ko VPN usmerja svoje naslove brez prevajanja, Apache vidi naslov predora in 10.8.0.0/24 se ujema. Ko prehod prevaja, Apache vidi prehod in pravilo tiho ne ujame ničesar; isto se zgodi za uravnavalnikom obremenitve, ki zaključi TLS pred gostiteljem. Za ta primer obstaja mod_remoteip. RemoteIPHeader X-Forwarded-For skupaj s RemoteIPTrustedProxy za uravnavalnik nadomesti zabeleženi naslov in šele takrat ima obseg s čim primerjati.

Zaupanje poljubni glavi posredovanja je slabše kot nimate nobenega pravila. Vsak odjemalec lahko pošlje X-Forwarded-For z 10.8.0.9 in izpolni preverjanje obsega, ki nikoli ni bilo zasidrano na zaupanja vrednem skoku.

Slojite poslušalca in politiko repozitorija

Vezava je ločena kontrola in pogosto enostavnejša. Listen 10.8.0.1:443 odloči, katere vtičnice obstajajo, in zahteva ne more izbrati gostitelja na vtičnici, ki ni bila nikoli odprta. Cena je vrstni red zagona: če je vmesnik predora ob zagonu Apacha izklopljen, vezava ne uspe in storitev se ne dvigne. Povežite jo z vrstnim redom enot ali jo vežite na naslov, ki obstaja neodvisno od predora.

Dovoljenja poti ostanejo v AuthzSVNAccessFile. Veljaven račun za spletno mesto ni isto pooblastilo kot pravica pisanja v pot projekta, in omrežno pravilo tega ne spremeni.

Pazite na združevanje razdelkov, ko je blok v vključeni datoteki. Apache združuje vsebnike pooblastil po gnezdenih razdelkih in najbolj natančen ujemajoči se razdelek lahko zahtevo nadomesti, namesto da bi jo dopolnil, zato pravilo na /svn morda ne doseže /svn/repo/trunk, ko ožji razdelek določi svojega.

Dokažite obe zavrnitvi, preden to razglasite za končano

Preizkusite štiri zahteve, ne ene. Znotraj VPN z veljavnim računom bi morali dobiti seznam repozitorija. Znotraj VPN z napačnim geslom bi morali dobiti 401 namesto seznama. Zunaj VPN z veljavnimi poverilnicami bi morali dobiti 403, in ista javna zahteva na nadomestno ime gostitelja mora spodleteti enako.

En ukaz na primer zadošča: curl -sI -u user:pass https://svn.example.com/svn/repo/, nato preberite vrstico stanja. Ponovite tudi delujoč primer skozi pravega odjemalca, ker svn info uri metode DAV, ki jih bodo uporabljali commiti in posodobitve.

Če se kateri od štirih rezultatov ne ujema z načrtovano politiko, konfiguracija ni končana, in preimenovanje gostitelja tega ne bo spremenilo.

Sorodni članki