VPN adresine kilitlenmiş NFS dışa aktarımı: bunun kanıtlamadığı şey
Bir dışa aktarım kuralı paketin nereden geldiğini denetler; AUTH_SYS yerel bir UID ileri sürer ve Kerberos bir kullanıcıyı doğrular. Dosya hizmetinizin hangisine ihtiyaç duyduğuna karar verin.
Bir ana makine bir dizini VPN adresine dışa aktarır, bağlama başarılı olur ve tasarım kimliği doğrulanmış olarak kaydedilir. Bu kuralın gerçekte sınırladığı şey, paketlerin nereden geliyor göründüğüdür. Dosya işlemini yürüten kişinin gerçekten iddia ettiği kişi olup olmadığı NFS güvenlik türüne bağlıdır ve bu tür dışa aktarımların çoğunda kimse bunu varsayılandan değiştirmemiştir.
Tek bir istekte üç kimlik ortaya çıkabilir
VPN eşi, istemci sertifikası veya eş anahtarı gibi kayıtlı bir kimlik taşır. İç IP paketi bir kaynak adres taşır. Dosya işlemi, NFS mekanizmasının sağladığı kullanıcı kimlik bilgilerini taşır. Adresi üçünün de yerine koyan bir tasarım, doğrulanması gereken kısmı sessizce varsaymış olur.
| Identity | What it proves | What it does not |
|---|---|---|
| VPN peer | Which peer was accepted by the tunnel | Which user runs on that machine |
| Inner source address | Where the packet appears to originate | That only the intended client can use it |
| NFS credential | What the file service believes about the caller | Anything, if the flavour only asserts local IDs |
O üç satırı yazmak bütün alıştırmadır. Bir dışa aktarımın güvenli olup olmadığı tartışmasının çoğu, hangi denetimin hangi satırda yaşadığı netleştiğinde çöker.
Adres sahipliği bir uygulama ayrıntısıdır
Bir geçit, kabul edilen bir eşe tünel adresi atayabilir veya onun için yönlendirilmiş bir alt ağ yetkilendirebilir. Uygulamanın ardından iç kaynağı başka bir istemciye ait olan paketi reddedip reddetmediği o uygulamanın özelliğidir ve varsaymak yerine denetlemeye değer.
Geleneksel Community OpenVPN kullanıcı alanı sunucu kodu, örneğin paket TUN aygıtı üzerinden teslim edilmeden önce başka bir istemciyle ilişkili bir kaynağı reddedebilir. Bu, gerçek değeri olan bir adres sahipliği denetimidir ve hâlâ NFS kullanıcı kimlik doğrulaması değildir, çünkü işlemi hangi hesabın yaptığına dair hiçbir şey söylemez.
Kaynak çevirisi bunu bile aşındırır. Bir NAT geçidi her istemciyi tek bir adres olarak sunabilir ve o noktada bir dışa aktarım kuralı arkasındaki insanları ayırt edemez. Kuralın görünen kesinliği o zaman diyagramın sürdürdüğü bir kurguya dönüşür. Dışa aktarım önemliyse adreslemeyi açık tutun, kimin kimin yerine sayıldığına bir çevirmenin karar vermesine izin vermeyin.
Dışa aktarıma güvenmeden önce güvenlik türünü okuyun
Red Hat'in NFS kılavuzu, AUTH_SYS aracılığıyla yerel UNIX UID ve GID kullanan sec=sys ayarını Kerberos kiplerinden ayırır. krb5 kullanıcı kimlik doğrulaması ekler, krb5i bütünlük koruması ekler ve krb5p trafik için gizlilik koruması ekler.
AUTH_SYS kimlik bilgileri, çağıranın UID'si ve grup kimlikleri gibi alanlar içerir ve RFC 5531 bu türün tek başına güvenlik sağlamadığını ve dış korumaya bağlı olduğunu açıkça uyarır. Bunu bir VPN içinde çalıştırmak taşıma için koruma sağlar ve paketin içindeki iddiada hiçbir şeyi değiştirmez.
exportfs -v
showmount -e nfs.example.internalİstemci listesini okumadan önce o çıktıdaki türü okuyun. Sınırlı görünen bir dışa aktarım yalnızca adresle sınırlı olabilir, oysa her çağıran istediği UID'yi ileri sürmeye devam eder.
Modeli seçin, sonra izinleri koruyun
Gerçekten yönettiğiniz istemcilere uygun dosya hizmeti kimlik doğrulama modelini seçin. Kerberos arkasında bir kimlik ve hizmet dağıtımı gerektirir, bu yüzden tek bir bağlama seçeneğini değiştirmek geçiş değildir ve Kerberos alanı, asıl nesneler ve keytab dosyaları var olana kadar yalnızca başarısız olur.
Her iki modelde de kimliği doğrulanmış asıl nesnenin neler yapabileceğini sınırlayan dışa aktarım izinlerini ve dosya sistemi yetkilendirmesini koruyun. Kimlik doğrulama kimin sorduğunu söyler; yetkilendirme yanıtın evet olup olmaması gerektiğine karar verir. Bu ikisini tek bir ayarda birleştirmek, bir geçişin eski yapılandırmadan daha fazla yetki vermesiyle sonuçlanmasının yoludur.
Adres kuralını gerçek amacı için kullanın
Hizmeti onaylanmış yola ve kaynaklara sınırlamak hâlâ değerlidir; VPN uç noktası ile NFS sunucusu aynı makineyi paylaştığında ana makine giriş ilkesi de buna dahildir. Trafiği ileten kurallar, şu hedefe yönelen istekleri yönetmez: aynı ana makinede yerel olarak çalışan bir hizmet. Bu boşluk, özel olması gereken şaşırtıcı sayıda dışa aktarımı açıklar. Tünel kurallarının bunu kapsadığını varsaymak yerine yerel giriş ilkesini açıkça denetleyin.
Başka bir arayüzün veya kaynak çevirisi yapan bir geçidin kuralı beklenmedik biçimde karşılayamayacağını denetleyin ve bunu, adres sahtelemenin çalışan bir bağlama garantisi verdiği iddiası değil, kökeni ortaya koymak için bir neden olarak görün.
Bir yerine üç kabul durumu çalıştırın. Onaylanmış bir istemcinin onaylanmış kullanıcı olarak davrandığı durumla başlayın, ardından hiç onaylanmamış bir eşten yineleyin, sonra onaylanmış kullanıcının hâlâ izinli olmadığı bir şeyi deneyin. Ardından yetkili bir istemci ele geçirilirse neyin değiştiğini sorun, çünkü taşıma kimlik doğrulaması o makinedeki her süreci güvenilir kılmaz. Çalınmış bir sertifika ile meraklı bir yerel hesap, farklı kontroller gerektiren farklı sorunlardır.