Ограничавање Subversion домаћина на VPN кориснике помоћу Apache 2.4

ServerName бира виртуелног домаћина, али не ограничава ко се повезује. Захтевајте VPN опсег и стварног корисника репозиторијума, затим докажите оба одбијања.

Усмеравање виртуелног домаћина Subversion на VPN адресу мења то која страница одговара на захтев, а не коме је дозвољено да га пошаље. Провера приступа се дешава касније, према правилима у одељку који се поклопио са URL-ом, и име домаћина никада не улази у ту одлуку. Ако је ServerName била ваша једина измена, репозиторијум је једнако доступан као јуче. У конфигурацији треба одговорити на два одвојена питања: који сокет је прихватио везу и који идентитет је носио захтев.

Шта ServerName заправо одлучује

Виртуелни хостинг заснован на имену пореди заглавље Host са уносима ServerName и ServerAlias, бира једног домаћина и пушта га да обради захтев. Сама веза је раније прихваћена на Listen сокету који припада серверу, а не домаћину. Зато име које изгледа приватно не пружа никакву заштиту: сваки клијент који достигне сокет може послати то заглавље Host. Име је кључ рутирања, а кључеве рутирања бира позивалац.

Мапирање можете видети без нагађања. apachectl -S исписује сваког домаћина, његов порт и имена и означава који је подразумевани за адресу.

RequireAll је контејнер који обе провере чини обавезним

Apache 2.4 умотава Require директиве једног одељка у имплицитни RequireAny, па две голе директиве значе да је довољна било која. Додајте контејнер и значење се преокреће:

<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 захтева оба услова: изворну адресу унутар опсега тунела и корисника којег репозиторијум прихвата. То би требало да значи само-VPN за Subversion URL. Референца за mod_authz_core документује правила контејнера. Оставите блок унутар постојећег Location за репозиторијум и не дирајте DAV директиве које већ раде, јер овај фрагмент не замењује ни AuthType ни датотеку лозинки ни ауторизацију на нивоу путање.

Провера извора долази из mod_authz_host, па потврдите да је учитан пре него што било шта друго дебагујете: apachectl -M | grep authz_host.

Адреса коју Apache процењује је адреса сокета

Require ip пореди са адресом коју је Apache забележио за везу, а то није увек адреса за коју клијент мисли да је има.

Када VPN рутира своје адресе без превођења, Apache види адресу тунела и 10.8.0.0/24 се поклапа. Када мрежни пролаз преводи, Apache види пролаз и правило тихо не одговара ничему; исто се дешава иза балансера који завршава TLS испред домаћина. За тај случај постоји mod_remoteip. RemoteIPHeader X-Forwarded-For заједно са RemoteIPTrustedProxy за балансер замењује забележену адресу и тек тада опсег има са чиме да се пореди.

Веровати произвољном заглављу прослеђивања горе је него немати никакво правило. Сваки клијент може послати X-Forwarded-For са 10.8.0.9 и задовољити проверу опсега која никада није била усидрена на поуздан скок.

Сложите слушалац и политику репозиторијума

Везивање је одвојена контрола и често једноставнија. Listen 10.8.0.1:443 одлучује који сокети постоје, а захтев не може изабрати домаћина на сокету који никада није отворен. Цена је редослед покретања: ако је интерфејс тунела искључен када Apache креће, везивање не успева и услуга се не подиже. Упарите га са редоследом јединица или се вежите на адресу која постоји независно од тунела.

Дозволе путање остају у AuthzSVNAccessFile. Ваљан налог за страницу није исто овлашћење као право писања у путању пројекта, и мрежно правило то не мења.

Пазите на спајање одељака када блок стоји у укљученој датотеци. Apache спаја контејнере ауторизације кроз угњеждене одељке и најспецифичнији подударни одељак може заменити захтев уместо да га допуни, па правило на /svn можда неће достићи /svn/repo/trunk када ужи одељак дефинише своје.

Докажите оба одбијања пре него што то назовете готовим

Тестирајте четири захтева, не један. Унутар VPN-а са ваљаним налогом треба да добијете листу репозиторијума. Унутар VPN-а са погрешном лозинком треба да добијете 401, а не листу. Изван VPN-а са ваљаним акредитивима треба да добијете 403, а исти јавни захтев према алтернативном имену домаћина мора пасти на исти начин.

Једна команда по случају је довољна: curl -sI -u user:pass https://svn.example.com/svn/repo/, затим прочитајте статусну линију. Поновите и радни случај кроз стварни клијент, јер svn info увежбава DAV методе које ће користити комити и ажурирања.

Ако се било који од четири резултата не слаже са политиком коју сте намеравали, конфигурација није завршена, и преименовање домаћина то неће променити.

Повезани чланци