Subversion-Host mit Apache 2.4 auf VPN-Nutzer beschränken

ServerName wählt einen virtuellen Host; es beschränkt nicht, wer sich verbindet. Verlangen Sie den VPN-Bereich und einen echten Repository-Benutzer und belegen Sie dann beide Ablehnungen.

Einen virtuellen Subversion-Host auf eine VPN-Adresse zu zeigen ändert, welche Site eine Anfrage beantwortet, nicht, wer sie senden darf. Die Zugriffsprüfung erfolgt später, nach den Regeln in dem Abschnitt, der zur URL passte, und ein Hostname geht nie in diese Entscheidung ein. War ServerName Ihre einzige Änderung, ist das Repository genau so erreichbar wie gestern. Zwei getrennte Fragen müssen in der Konfiguration beantwortet werden: welcher Socket die Verbindung annahm und welche Identität die Anfrage trug.

Was ServerName tatsächlich entscheidet

Namensbasiertes virtuelles Hosting vergleicht den Host-Header mit ServerName- und ServerAlias-Einträgen, wählt einen Host und lässt ihn die Anfrage bearbeiten. Die Verbindung selbst wurde vorher von einem Listen-Socket angenommen, der zum Server gehört, nicht zum Host. Deshalb bietet ein privat klingender Name keinen Schutz: jeder Client, der den Socket erreicht, kann diesen Host-Header senden. Der Name ist ein Routing-Schlüssel, und Routing-Schlüssel wählt der Aufrufer.

Sie können die Zuordnung ohne Raten sehen. apachectl -S gibt jeden Host, seinen Port und seine Namen aus und markiert, welcher der Standard für die Adresse ist.

RequireAll ist der Container, der beide Prüfungen verbindlich macht

Apache 2.4 hüllt die Require-Direktiven eines einzelnen Abschnitts in ein implizites RequireAny, sodass zwei blanke Direktiven bedeuten, dass eine davon genügt. Fügen Sie den Container hinzu, und die Bedeutung kehrt sich um:

<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 verlangt beide Bedingungen: eine Quelladresse innerhalb des Tunnelbereichs und einen Benutzer, den das Repository akzeptiert. Das sollte nur-VPN für eine Subversion-URL bedeuten. Die mod_authz_core-Referenz dokumentiert die Containerregeln. Belassen Sie den Block im vorhandenen Location für das Repository und lassen Sie die DAV-Direktiven, die bereits funktionieren, an ihrem Platz, denn dieses Fragment ersetzt weder AuthType noch die Passwortdatei noch die Autorisierung auf Pfadebene.

Die Quellprüfung stammt von mod_authz_host, bestätigen Sie also, dass es geladen ist, bevor Sie irgendetwas anderes debuggen: apachectl -M | grep authz_host.

Die Adresse, die Apache auswertet, ist die Socket-Adresse

Require ip vergleicht mit der Adresse, die Apache für die Verbindung aufgezeichnet hat, und das ist nicht immer die Adresse, die der Client zu haben glaubt.

Wenn das VPN seine Adressen ohne Übersetzung routet, sieht Apache die Tunneladresse, und 10.8.0.0/24 passt. Wenn ein Gateway übersetzt, sieht Apache das Gateway, und die Regel passt still auf nichts; dasselbe passiert hinter einem Load Balancer, der TLS vor dem Host beendet. Für diesen Fall gibt es mod_remoteip. RemoteIPHeader X-Forwarded-For zusammen mit RemoteIPTrustedProxy für den Balancer ersetzt die aufgezeichnete Adresse, und erst dann hat der Bereich etwas zum Vergleichen.

Einem beliebigen Weiterleitungsheader zu vertrauen ist schlimmer, als gar keine Regel zu haben. Jeder Client kann X-Forwarded-For mit 10.8.0.9 senden und eine Bereichsprüfung erfüllen, die nie an einem vertrauenswürdigen Hop verankert war.

Schichten Sie den Listener und die Repository-Richtlinie

Die Bindung ist eine separate Kontrolle und oft die einfachere. Listen 10.8.0.1:443 entscheidet, welche Sockets existieren, und eine Anfrage kann keinen Host auf einem Socket auswählen, der nie geöffnet wurde. Der Preis ist die Startreihenfolge: ist die Tunnelschnittstelle beim Start von Apache unten, schlägt die Bindung fehl und der Dienst kommt nicht hoch. Koppeln Sie sie an die Unit-Reihenfolge, oder binden Sie an eine Adresse, die unabhängig vom Tunnel existiert.

Pfadberechtigungen bleiben in AuthzSVNAccessFile. Ein gültiges Konto für die Site ist nicht dieselbe Berechtigung wie Schreibzugriff auf einen Projektpfad, und die Netzwerkregel ändert daran nichts.

Achten Sie auf das Zusammenführen von Abschnitten, wenn der Block in einer eingebundenen Datei liegt. Apache führt Autorisierungscontainer über verschachtelte Abschnitte zusammen, und der spezifischste passende Abschnitt kann die Anforderung ersetzen statt sie zu ergänzen, sodass eine Regel auf /svn möglicherweise nicht /svn/repo/trunk erreicht, sobald ein engerer Abschnitt seine eigene definiert.

Belegen Sie beide Ablehnungen, bevor Sie es fertig nennen

Testen Sie vier Anfragen, nicht eine. Innerhalb des VPN mit einem gültigen Konto sollten Sie die Repository-Auflistung erhalten. Innerhalb des VPN mit einem falschen Passwort sollten Sie 401 statt einer Auflistung erhalten. Von außerhalb des VPN mit gültigen Anmeldedaten sollten Sie 403 erhalten, und dieselbe öffentliche Anfrage gegen einen alternativen Hostnamen muss genauso fehlschlagen.

Ein Befehl pro Fall genügt: curl -sI -u user:pass https://svn.example.com/svn/repo/, dann lesen Sie die Statuszeile. Wiederholen Sie den funktionierenden Fall auch über den echten Client, weil svn info die DAV-Methoden ausübt, die Commits und Aktualisierungen verwenden werden.

Wenn eines der vier Ergebnisse der beabsichtigten Richtlinie widerspricht, ist die Konfiguration nicht fertig, und ein Umbenennen des Hosts ändert das nicht.

Ähnliche Artikel