Subversioni hosti piiramine VPN-i kasutajatega Apache 2.4 abil

ServerName valib virtuaalhosti, kuid ei piira, kes ühendub. Nõudke VPN-i vahemikku ja tegelikku hoidla kasutajat ning tõestage mõlemad keeldumised.

Subversioni virtuaalhosti suunamine VPN-i aadressile muudab seda, milline sait päringule vastab, mitte seda, kellel on lubatud see saata. Juurdepääsukontroll toimub hiljem, URL-iga sobiva sektsiooni reeglite järgi, ja hosti nimi ei jõua kunagi sellesse otsusesse. Kui ServerName oli teie ainus muudatus, on hoidla täpselt sama kättesaadav kui eile. Konfiguratsioonis tuleb vastata kahele eraldi küsimusele: milline socket ühenduse vastu võttis ja millist identiteeti päring kandis.

Mida ServerName tegelikult otsustab

Nimipõhine virtuaalhosting võrdleb Host-päist ServerName- ja ServerAlias-kirjetega, valib ühe hosti ja laseb sellel päringut käsitleda. Ühenduse võttis varem vastu Listen-socket, mis kuulub serverile, mitte hostile. Seetõttu ei paku privaatne nimi mingit kaitset: iga klient, kes socketini jõuab, võib selle Host-päise saata. Nimi on marsruutimisvõti ja marsruutimisvõtmeid valib kutsuja.

Saate vastendust näha ilma oletamata. apachectl -S prindib iga hosti, selle pordi ja nimed ning märgib, milline on aadressi jaoks vaikimisi.

RequireAll on konteiner, mis muudab mõlemad kontrollid kohustuslikuks

Apache 2.4 mähkib ühe sektsiooni Require-direktiivid kaudsesse RequireAny-sse, seega kaks paljast direktiivi tähendavad, et kummastki piisab. Lisage konteiner ja tähendus pöördub ümber:

<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 nõuab mõlemat tingimust: lähteaadress tunnelivahemikus ja kasutaja, kelle hoidla vastu võtab. Seda peaks tähendama ainult-VPN Subversioni URL-i puhul. mod_authz_core viide dokumenteerib konteineri reeglid. Jätke plokk hoidla olemasoleva Location-i sisse ja jätke juba töötavad DAV-direktiivid paigale, sest see fragment ei asenda ei AuthType'i, paroolifaili ega tee-tasandi autoriseerimist.

Lähtekontroll pärineb mod_authz_host-ist, seega kinnitage, et see on laaditud, enne kui midagi muud silute: apachectl -M | grep authz_host.

Aadress, mida Apache hindab, on socketi aadress

Require ip võrdleb aadressiga, mille Apache ühenduse jaoks salvestas, ja see ei ole alati aadress, mille klient arvab endal olevat.

Kui VPN marsruudib oma aadresse ilma tõlketa, näeb Apache tunneliaadressi ja 10.8.0.0/24 sobib. Kui lüüs tõlgib, näeb Apache lüüsi ja reegel ei sobi vaikselt mitte millegagi; sama juhtub koormusjaoturi taga, mis lõpetab TLS-i hosti ees. Selle juhtumi jaoks on mod_remoteip. RemoteIPHeader X-Forwarded-For koos jaoturi jaoks mõeldud RemoteIPTrustedProxy-ga asendab salvestatud aadressi ja alles siis on vahemikul millega võrrelda.

Suvalise edastuspäise usaldamine on hullem kui üldse reegli puudumine. Iga klient võib saata X-Forwarded-For-i, mis sisaldab 10.8.0.9, ja rahuldada vahemikukontrolli, mis ei olnud kunagi usaldusväärse hüppe külge ankurdunud.

Kihitage kuulaja ja hoidla poliitika

Sidumine on eraldi kontroll ja sageli lihtsam. Listen 10.8.0.1:443 otsustab, millised socketid eksisteerivad, ja päring ei saa valida hosti socketil, mida kunagi ei avatud. Hinnaks on käivitusjärjekord: kui tunneliliides on Apache'i käivitumisel maas, ebaõnnestub sidumine ja teenus ei tõuse. Siduge see üksuste järjekorraga või siduge aadressiga, mis eksisteerib tunnelist sõltumatult.

Teeõigused jäävad AuthzSVNAccessFile-i. Saidile kehtiv konto ei ole sama luba kui projekti teele kirjutamise õigus, ja võrgureegel ei muuda seda.

Jälgige sektsioonide ühendamist, kui plokk on kaasatud failis. Apache ühendab autoriseerimiskonteinerid pesastatud sektsioonide vahel ja kõige spetsiifilisem sobiv sektsioon võib nõude asendada, mitte seda täiendada, seega reegel /svn-l ei pruugi jõuda /svn/repo/trunk-ni, kui kitsam sektsioon määratleb oma.

Tõestage mõlemad keeldumised, enne kui ütlete, et valmis

Testige nelja päringut, mitte ühte. VPN-i sees kehtiva kontoga peaksite saama hoidla loendi. VPN-i sees vale parooliga peaksite saama 401, mitte loendi. Väljastpoolt VPN-i kehtivate identimisandmetega peaksite saama 403, ja sama avalik päring alternatiivsele hostinimele peab samamoodi ebaõnnestuma.

Üks käsk juhtumi kohta on piisav: curl -sI -u user:pass https://svn.example.com/svn/repo/, seejärel lugege olekurida. Korrake töötavat juhtumit ka tegeliku kliendiga, sest svn info harjutab DAV-meetodeid, mida commit-id ja uuendused kasutavad.

Kui mõni neljast tulemusest ei vasta kavatsetud poliitikale, ei ole konfiguratsioon valmis ja hosti ümbernimetamine ei muuda seda.

Seotud artiklid