Begrens en Subversion-vert til VPN-brukere med Apache 2.4

ServerName velger en virtuell vert; det begrenser ikke hvem som kobler til. Krev VPN-området og en ekte depotbruker, og bevis deretter begge avvisningene.

Å peke en virtuell Subversion-vert mot en VPN-adresse endrer hvilket nettsted som svarer på en forespørsel, ikke hvem som har lov til å sende den. Tilgangskontrollen skjer senere, etter reglene i seksjonen som passet med URL-en, og et vertsnavn inngår aldri i den beslutningen. Hvis ServerName var den eneste endringen din, er depotet nøyaktig like tilgjengelig som i går. To separate spørsmål må besvares i konfigurasjonen: hvilken socket som tok imot forbindelsen, og hvilken identitet forespørselen bar.

Hva ServerName faktisk avgjør

Navnebasert virtuell hosting sammenligner Host-headeren med ServerName- og ServerAlias-oppføringer, velger én vert og lar den håndtere forespørselen. Selve forbindelsen ble tatt imot tidligere av en Listen-socket som tilhører serveren, ikke verten. Derfor gir et navn som ser privat ut ingen beskyttelse: enhver klient som når socketen, kan sende den Host-headeren. Navnet er en rutingnøkkel, og rutingnøkler velges av den som kaller.

Du kan se tilordningen uten å gjette. apachectl -S skriver ut hver vert, porten og navnene, og markerer hvilken som er standard for adressen.

RequireAll er beholderen som gjør begge kontrollene obligatoriske

Apache 2.4 pakker Require-direktivene i én seksjon inn i en implisitt RequireAny, så to bare direktiver betyr at ett av dem er nok. Legg til beholderen, og betydningen snus:

<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 krever begge betingelsene: en kildeadresse innenfor tunnelområdet og en bruker som depotet godtar. Det er hva bare-VPN bør bety for en Subversion-URL. Referansen for mod_authz_core dokumenterer beholderreglene. Hold blokken inne i den eksisterende Location for depotet og la DAV-direktivene som allerede virker, stå på plass, fordi dette fragmentet verken erstatter AuthType eller passordfilen eller autorisasjon på stinivå.

Kildetesten kommer fra mod_authz_host, så bekreft at den er lastet før du feilsøker noe annet: apachectl -M | grep authz_host.

Adressen Apache vurderer, er socketadressen

Require ip sammenligner med adressen Apache registrerte for forbindelsen, og det er ikke alltid adressen klienten tror den har.

Når VPN-en ruter adressene sine uten oversettelse, ser Apache tunneladressen, og 10.8.0.0/24 passer. Når en gateway oversetter, ser Apache gatewayen, og regelen passer stille på ingenting; det samme skjer bak en lastbalanserer som avslutter TLS foran verten. For det tilfellet finnes mod_remoteip. RemoteIPHeader X-Forwarded-For sammen med RemoteIPTrustedProxy for balanseren erstatter den registrerte adressen, og først da har området noe å sammenligne med.

Å stole på en vilkårlig videresendingsheader er verre enn å ikke ha noen regel i det hele tatt. Enhver klient kan sende X-Forwarded-For med 10.8.0.9 og oppfylle en områdekontroll som aldri var forankret i et klarert hopp.

Legg lytteren og depotpolitikken i lag

Binding er en separat kontroll og ofte den enkleste. Listen 10.8.0.1:443 avgjør hvilke sockets som finnes, og en forespørsel kan ikke velge en vert på en socket som aldri ble åpnet. Prisen er oppstartsrekkefølge: hvis tunnelgrensesnittet er nede når Apache starter, mislykkes bindingen, og tjenesten kommer ikke opp. Koble den til enhetsrekkefølge, eller bind til en adresse som finnes uavhengig av tunnelen.

Stitilganger blir i AuthzSVNAccessFile. En gyldig konto for nettstedet er ikke samme tildeling som skrivetilgang til en prosjektsti, og nettverksregelen endrer ikke det.

Følg med på seksjonssammenføyning når blokken ligger i en inkludert fil. Apache fletter autorisasjonsbeholdere på tvers av nestede seksjoner, og den mest spesifikke samsvarende seksjonen kan erstatte kravet i stedet for å legge til, så en regel på /svn når kanskje ikke /svn/repo/trunk når en smalere seksjon definerer sin egen.

Bevis begge avvisningene før du kaller det ferdig

Test fire forespørsler, ikke én. Inne i VPN-en med en gyldig konto bør du få depotets liste. Inne i VPN-en med feil passord bør du få 401 i stedet for en liste. Utenfor VPN-en med gyldige påloggingsdata bør du få 403, og den samme offentlige forespørselen mot et alternativt vertsnavn må feile på samme måte.

Én kommando per tilfelle er nok: curl -sI -u user:pass https://svn.example.com/svn/repo/, og les deretter statuslinjen. Gjenta også tilfellet som virker, gjennom den ekte klienten, fordi svn info øver på DAV-metodene som commits og oppdateringer vil bruke.

Hvis noen av de fire resultatene er uenige med policyen du hadde til hensikt, er konfigurasjonen ikke ferdig, og å gi verten nytt navn endrer ikke det.

Relaterte artikler