Begræns en Subversion-vært til VPN-brugere med Apache 2.4

At pege en virtuel Subversion-vært mod en VPN-adresse ændrer, hvilket websted der svarer på en anmodning, ikke hvem der må sende den. Adgangskontrollen sker senere, efter reglerne i den sektion, der matchede URL'en, og et værtsnavn indgår aldrig i den beslutning. Hvis ServerName var din eneste ændring, er arkivet præcis lige så tilgængeligt som i går. Der skal svares på to separate spørgsmål i konfigurationen: hvilken socket der accepterede forbindelsen, og hvilken identitet anmodningen bar.

Hvad ServerName faktisk afgør

Navnebaseret virtuel hosting sammenligner Host-headeren med ServerName- og ServerAlias-poster, vælger én vært og lader den vært håndtere anmodningen. Selve forbindelsen blev accepteret tidligere af en Listen-socket, der tilhører serveren og ikke værten. Derfor giver et navn, der ser privat ud, ingen beskyttelse: enhver klient, der kan nå socketten, kan sende den Host-header. Navnet er en routingnøgle, og routingnøgler vælges af den, der kalder.

Du kan se tilknytningen uden at gætte. apachectl -S udskriver hver vært, dens port og dens navne og markerer, hvilken der er standard for adressen.

RequireAll er den beholder, der gør begge kontroller obligatoriske

Apache 2.4 pakker en sektions Require-direktiver ind i en implicit RequireAny, så to blotte direktiver betyder, at et af dem er nok. Tilføj beholderen, og betydningen vender:

<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 kræver begge betingelser: en kildeadresse inden for tunnelintervallet og en bruger, som arkivet accepterer. Det er, hvad kun-VPN bør betyde for en Subversion-URL. Referencen for mod_authz_core dokumenterer beholderreglerne. Behold blokken inde i den eksisterende Location for arkivet, og lad de DAV-direktiver, der allerede virker, blive stående, fordi dette fragment hverken erstatter AuthType eller passwordfilen eller autorisation på stiniveau.

Kildetesten kommer fra mod_authz_host, så bekræft, at den er indlæst, før du fejlfinder noget andet: apachectl -M | grep authz_host.

Den adresse, Apache vurderer, er socketadressen

Require ip sammenligner med den adresse, Apache registrerede for forbindelsen, og det er ikke altid den adresse, klienten tror, den har.

Når VPN'en ruter sine adresser uden oversættelse, ser Apache tunneladressen, og 10.8.0.0/24 matcher. Når en gateway oversætter, ser Apache gatewayen, og reglen matcher lydløst ingenting; det samme sker bag en load balancer, der afslutter TLS foran værten. mod_remoteip findes til det tilfælde. RemoteIPHeader X-Forwarded-For sammen med RemoteIPTrustedProxy for balanceren erstatter den registrerede adresse, og først da har intervallet noget at sammenligne med.

At stole på en vilkårlig videresendelsesheader er værre end slet ikke at have nogen regel. Enhver klient kan sende X-Forwarded-For med 10.8.0.9 og opfylde en intervalkontrol, der aldrig var forankret i et betroet hop.

Læg lytteren og arkivpolitikken i lag

Binding er en separat kontrol og ofte den enklere. Listen 10.8.0.1:443 afgør, hvilke sockets der findes, og en anmodning kan ikke vælge en vært på en socket, der aldrig blev åbnet. Prisen er opstartsrækkefølge: hvis tunnelinterfacet er nede, når Apache starter, mislykkes bindingen, og tjenesten kommer ikke op. Par den med unit-rækkefølge, eller bind til en adresse, der findes uafhængigt af tunnelen.

Stitilladelser bliver i AuthzSVNAccessFile. En gyldig konto til webstedet er ikke den samme bevilling som skriveadgang til en projektsti, og netværksreglen ændrer ikke det.

Hold øje med sektionsfletning, når blokken ligger i en inkluderet fil. Apache fletter autorisationsbeholdere på tværs af indlejrede sektioner, og den mest specifikke matchende sektion kan erstatte kravet i stedet for at føje til det, så en regel på /svn når måske ikke /svn/repo/trunk, når en snævrere sektion definerer sin egen.

Bevis begge afvisninger, før du kalder det færdigt

Test fire anmodninger, ikke én. Inde i VPN'en med en gyldig konto bør du få arkivets liste. Inde i VPN'en med en forkert adgangskode bør du få 401 i stedet for en liste. Udefra VPN'en med gyldige legitimationsoplysninger bør du få 403, og den samme offentlige anmodning mod et alternativt værtsnavn skal fejle på samme måde.

Én kommando pr. tilfælde er nok: curl -sI -u user:pass https://svn.example.com/svn/repo/, læs derefter statuslinjen. Gentag også det fungerende tilfælde gennem den rigtige klient, fordi svn info udøver de DAV-metoder, som commits og opdateringer vil bruge.

Hvis et af de fire resultater er uenigt med den politik, du havde til hensigt, er konfigurationen ikke færdig, og at omdøbe værten ændrer ikke det.