Apache 2.4 ile bir Subversion ana bilgisayarını VPN kullanıcılarıyla sınırlayın

ServerName bir sanal ana bilgisayar seçer; kimin bağlandığını sınırlamaz. VPN aralığını ve gerçek depo kullanıcısını isteyin, ardından iki reddi de kanıtlayın.

Bir Subversion sanal ana bilgisayarını VPN adresine yönlendirmek, bir isteği hangi sitenin yanıtladığını değiştirir, kimin gönderme izni olduğunu değil. Erişim denetimi daha sonra, URL ile eşleşen bölümdeki kurallara göre yapılır ve ana bilgisayar adı bu karara hiçbir zaman girmez. Yalnızca ServerName'i değiştirdiyseniz depo dün olduğu kadar erişilebilirdir. Yapılandırmada iki ayrı soruya yanıt verilmelidir: bağlantıyı hangi soket kabul etti ve istek hangi kimliği taşıyordu.

ServerName gerçekte neyi belirler

Ada dayalı sanal barındırma, Host başlığını ServerName ve ServerAlias girdileriyle karşılaştırır, bir ana bilgisayar seçer ve isteği onun işlemesine izin verir. Bağlantının kendisi daha önce ana bilgisayara değil sunucuya ait bir Listen soketi tarafından kabul edilmişti. Bu yüzden özel görünen bir ad hiçbir koruma sağlamaz: sokete ulaşan her istemci o Host başlığını gönderebilir. Ad bir yönlendirme anahtarıdır ve yönlendirme anahtarlarını çağıran seçer.

Eşlemeyi tahmin etmeden görebilirsiniz. apachectl -S her ana bilgisayarı, bağlantı noktasını ve adlarını yazdırır ve adres için hangisinin varsayılan olduğunu işaretler.

RequireAll her iki denetimi zorunlu kılan kapsayıcıdır

Apache 2.4 bir bölümün Require yönergelerini örtük bir RequireAny içine sarar, dolayısıyla iki çıplak yönerge bunlardan birinin yeterli olduğu anlamına gelir. Kapsayıcıyı ekleyin ve anlam tersine döner:

<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 her iki koşulu ister: tünel aralığı içinde bir kaynak adres ve deponun kabul ettiği bir kullanıcı. Bir Subversion URL'si için yalnızca-VPN bunu ifade etmelidir. mod_authz_core başvurusu kapsayıcı kurallarını belgeler. Bloğu deponun mevcut Location bölümünde bırakın ve zaten çalışan DAV yönergelerini yerinde bırakın, çünkü bu parça ne AuthType'ı ne parola dosyasını ne de yol düzeyinde yetkilendirmeyi değiştirir.

Kaynak testi mod_authz_host'tan gelir, bu yüzden başka bir şeyi ayıklamadan önce yüklü olduğunu doğrulayın: apachectl -M | grep authz_host.

Apache'nin değerlendirdiği adres soket adresidir

Require ip, Apache'nin bağlantı için kaydettiği adresle karşılaştırır ve bu her zaman istemcinin sahip olduğunu sandığı adres değildir.

VPN adreslerini çeviri olmadan yönlendirdiğinde Apache tünel adresini görür ve 10.8.0.0/24 eşleşir. Bir ağ geçidi çevirdiğinde Apache ağ geçidini görür ve kural sessizce hiçbir şeyle eşleşmez; aynısı ana bilgisayarın önünde TLS'i sonlandıran bir yük dengeleyicinin arkasında da olur. O durum için mod_remoteip vardır. Dengeleyici için RemoteIPTrustedProxy ile birlikte RemoteIPHeader X-Forwarded-For kaydedilen adresi değiştirir ve ancak o zaman aralığın karşılaştıracak bir şeyi olur.

Rastgele bir yönlendirme başlığına güvenmek hiç kural olmamasından daha kötüdür. Her istemci 10.8.0.9 içeren X-Forwarded-For gönderip güvenilir bir sıçramaya hiç bağlanmamış bir aralık denetimini karşılayabilir.

Dinleyiciyi ve depo ilkesini katmanlayın

Bağlama ayrı bir denetimdir ve çoğu zaman en basitidir. Listen 10.8.0.1:443 hangi soketlerin var olduğunu belirler ve bir istek hiç açılmamış bir sokette ana bilgisayar seçemez. Bedeli başlangıç sırasıdır: Apache başlarken tünel arayüzü kapalıysa bağlama başarısız olur ve hizmet açılmaz. Bunu birim sırasıyla eşleştirin veya tünelden bağımsız olarak var olan bir adrese bağlayın.

Yol izinleri AuthzSVNAccessFile içinde kalır. Site için geçerli bir hesap, bir proje yoluna yazma erişimiyle aynı yetki değildir ve ağ kuralı bunu değiştirmez.

Blok dahil edilen bir dosyadaysa bölüm birleştirmesine dikkat edin. Apache yetkilendirme kapsayıcılarını iç içe bölümler boyunca birleştirir ve en belirgin eşleşen bölüm gereksinimi eklemek yerine değiştirebilir, bu yüzden /svn üzerindeki bir kural daha dar bir bölüm kendi kuralını tanımladığında /svn/repo/trunk'e ulaşmayabilir.

Bitmiş demeden önce iki reddi de kanıtlayın

Bir değil dört istek deneyin. VPN içinde geçerli bir hesapla depo listesini almalısınız. VPN içinde yanlış parolayla liste yerine 401 almalısınız. VPN dışından geçerli kimlik bilgileriyle 403 almalısınız ve alternatif bir ana bilgisayar adına yapılan aynı genel istek de aynı şekilde başarısız olmalıdır.

Her durum için bir komut yeterlidir: curl -sI -u user:pass https://svn.example.com/svn/repo/, ardından durum satırını okuyun. Çalışan durumu gerçek istemciyle de tekrarlayın, çünkü svn info commit ve güncellemelerin kullanacağı DAV yöntemlerini çalıştırır.

Dört sonuçtan herhangi biri amaçladığınız ilkeyle çelişiyorsa yapılandırma tamamlanmamıştır ve ana bilgisayarın adını değiştirmek bunu değiştirmez.

İlgili makaleler