Subversion-gazdagép korlátozása VPN-felhasználókra az Apache 2.4-gyel

Egy Subversion virtuális gazdagép VPN-címre irányítása azt változtatja meg, melyik oldal válaszol egy kérésre, nem azt, ki küldheti el. A hozzáférés-ellenőrzés később történik, az URL-lel egyező szakasz szabályai szerint, és a gazdagépnév soha nem kerül bele ebbe a döntésbe. Ha a ServerName volt az egyetlen változtatása, a tároló pontosan olyan elérhető, mint tegnap. Két külön kérdésre kell válaszolni a konfigurációban: melyik socket fogadta a kapcsolatot, és milyen identitást hordozott a kérés.

Mit dönt el valójában a ServerName

A névalapú virtuális hosztolás összeveti a Host fejlécet a ServerName és ServerAlias bejegyzésekkel, kiválaszt egy gazdagépet, és hagyja, hogy az kezelje a kérést. Magát a kapcsolatot korábban egy Listen socket fogadta, amely a kiszolgálóhoz tartozik, nem a gazdagéphez. Ezért a privátnak látszó név semmilyen védelmet nem nyújt: bármely kliens, amely eléri a socketet, elküldheti azt a Host fejlécet. A név útválasztási kulcs, az útválasztási kulcsokat pedig a hívó választja.

A leképezést találgatás nélkül is láthatja. A apachectl -S kiírja az egyes gazdagépeket, portjukat és neveiket, és megjelöli, melyik az alapértelmezett a címhez.

A RequireAll az a tároló, amely mindkét ellenőrzést kötelezővé teszi

Az Apache 2.4 egy szakasz Require utasításait egy implicit RequireAny-be csomagolja, így két csupasz utasítás azt jelenti, hogy bármelyik elég. Adja hozzá a tárolót, és a jelentés megfordul:

<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>

A RequireAll mindkét feltételt megköveteli: forrás-címet az alagút tartományán belül és olyan felhasználót, amelyet a tároló elfogad. Ezt kellene jelentenie a csak-VPN beállításnak egy Subversion URL esetében. A mod_authz_core referenciája dokumentálja a tároló szabályait. Tartsa a blokkot a tároló meglévő Location szakaszán belül, és hagyja a helyén a már működő DAV utasításokat, mert ez a részlet sem az AuthType-ot, sem a jelszófájlt, sem az útvonal szintű engedélyezést nem cseréli le.

A forrásvizsgálat a mod_authz_host modulból származik, ezért erősítse meg, hogy betöltődött, mielőtt bármi mást hibakeresne: apachectl -M | grep authz_host.

A cím, amelyet az Apache értékel, a socket címe

A Require ip ahhoz a címhez hasonlít, amelyet az Apache a kapcsolat számára rögzített, és ez nem mindig az a cím, amelyről a kliens azt hiszi, hogy rendelkezik vele.

Amikor a VPN fordítás nélkül irányítja a címeit, az Apache az alagút címét látja, és a 10.8.0.0/24 egyezik. Amikor egy átjáró fordít, az Apache az átjárót látja, és a szabály csendben semmihez nem illeszkedik; ugyanez történik egy terheléselosztó mögött, amely a gazdagép előtt fejezi be a TLS-t. Erre az esetre létezik a mod_remoteip. A RemoteIPHeader X-Forwarded-For az elosztóhoz tartozó RemoteIPTrustedProxy-gyel együtt lecseréli a rögzített címet, és csak ekkor van mihez hasonlítania a tartománynak.

Egy tetszőleges továbbítási fejléc megbízása rosszabb, mint egyáltalán nem rendelkezni szabállyal. Bármely kliens küldhet 10.8.0.9-et tartalmazó X-Forwarded-For fejlécet, és kielégíthet olyan tartomány-ellenőrzést, amelyet soha nem horgonyoztak megbízható ugráshoz.

Rétegezze a figyelőt és a tároló házirendjét

A kötés külön ellenőrzés, és gyakran az egyszerűbb. A Listen 10.8.0.1:443 eldönti, mely socketek léteznek, és egy kérés nem választhat gazdagépet olyan socketen, amelyet soha nem nyitottak meg. Az ár az indítási sorrend: ha az alagút interfésze le van állva az Apache indításakor, a kötés meghiúsul, és a szolgáltatás nem indul el. Párosítsa egység-sorrenddel, vagy kössön olyan címhez, amely az alagúttól függetlenül létezik.

Az útvonal-engedélyek az AuthzSVNAccessFile-ban maradnak. Az oldalhoz érvényes fiók nem ugyanaz a jogosultság, mint egy projektútvonal írási hozzáférése, és a hálózati szabály ezen nem változtat.

Figyeljen a szakaszok összevonására, amikor a blokk egy beillesztett fájlban van. Az Apache az engedélyezési tárolókat beágyazott szakaszokon át vonja össze, és a leginkább specifikus egyező szakasz lecserélheti a követelményt ahelyett, hogy hozzáadna hozzá, így a /svn-ra vonatkozó szabály esetleg nem éri el a /svn/repo/trunk-ot, amint egy szűkebb szakasz sajátot definiál.

Bizonyítsa mindkét elutasítást, mielőtt késznek nevezné

Négy kérést teszteljen, ne egyet. A VPN-en belül érvényes fiókkal a tároló listáját kell kapnia. A VPN-en belül rossz jelszóval 401-et kell kapnia lista helyett. A VPN-en kívülről érvényes hitelesítő adatokkal 403-at kell kapnia, és ugyanannak a nyilvános kérésnek egy alternatív gazdagépnévre ugyanúgy meg kell hiúsulnia.

Esetenként egy parancs elegendő: curl -sI -u user:pass https://svn.example.com/svn/repo/, majd olvassa el az állapotsort. Ismételje meg a működő esetet a valódi klienssel is, mert a svn info gyakorolja azokat a DAV-metódusokat, amelyeket a commitok és a frissítések használni fognak.

Ha a négy eredmény bármelyike ellentmond a szándékolt házirendnek, a konfiguráció nincs kész, és a gazdagép átnevezése ezen nem változtat.