.ovpn dosyasını düzenlemek neden sunucuda MFA’yı açamaz

Bir profile auth-user-pass eklersiniz, yeniden bağlanırsınız ve istemci bir kullanıcı adı ile parola ister. MFA açık görünür. Sonra yanlış hesaptan bir kod ya da on dakika önce süresi dolmuş bir kod girersiniz ve tünel yine de açılır. Belirti budur: istemci değişti, sunucu değişmedi. Tek kullanımlık parola, ancak sunucudaki bir doğrulayıcı onu talep eden kimlik için geçerli olup olmadığına karar verdiğinde bir etkendir.

İstem yalnızca istemcinin sorduğunu kanıtlar, daha fazlasını değil

Bir .ovpn dosyası istemci tarafındaki bir belgedir. İstemciye kimlik bilgilerini istemesini, önbelleğe almasını veya bundan vazgeçmesini söyleyebilir. Ancak bir kullanıcıyı kaydedemez, bir PAM modülü kuramaz veya sunucuyu şu anda denetlemediği ikinci bir etkeni istemeye zorlayamaz.

Telefona bir kimlik doğrulama uygulaması kurmak da o ilişkiyi yaratmaz. Google Authenticator PAM projesi, OpenVPN arkasında durabilen bir OTP doğrulama bileşenidir; içe aktarılmış bir profile Google hesabı oturum açmasını yapıştırmanın yolu değildir.

Kayıt, bir profilin yapamadığı kısımdır

TOTP, kimlik doğrulama uygulaması ile doğrulayıcısı arasında paylaşılan kayıt malzemesine ihtiyaç duyar. Telefondaki altı rakam çıktıdır; arkalarındaki tohum sırdır ve tek bir kimliğe aittir.

Bu yüzden operatörün, doğru tohumu doğru VPN kimliğine bağlayan bir kayıt sürecine ve ayrıca kaybolan telefon için doğrulanmış bir değiştirme yoluna ihtiyacı vardır. Kullanıcıların kendi adlarına bir dosya yüklemesine izin vermek, kaydı bir hesap ele geçirme fırsatına dönüştürür ve yüklemenin şifrelenmesi bunu değiştirmez.

PAM tabanlı bir tasarımın her VPN kullanıcısı için ayrı bir Unix hesabı oluşturması gerekmez. Modül belgeleri alternatif sır yollarını ve dosya erişimi için ayrılmış bir hesabı destekler; bu bir dosya sistemi kimliğidir, doğrulanan oturum açma kimliği değildir.

Yaygın hata, tek kullanıcılı bir örnekten kopyalanmış, tek bir kullanıcı adıyla biten sabit bir sır yoludur. Bu, tek bir kimliğin gösterimidir, kullanıcı başına arama değildir ve her istek için kullanmak kimseye bağımsız olarak kaydedilmiş bir kimlik doğrulama uygulaması vermez. Kimlik eşlemesini yazın, tohum dosyalarını koruyun ve parola, sertifika ve hesap denetimlerini aynı kimlik doğrulama yığınında tutun.

PAM yığınını okuyun ve gerçekte neyin gerekli olduğunu görün

account required pam_permit.so gibi bir satır hesap uygunluğunu uygulamaz ve bir etken eklemez. O PAM hesap yönetimi aşamasına izin verir, bu bir aşama hakkında ifadedir, kullanıcılarınız hakkında değil.

Aynısı esnek kayıt seçenekleri için de geçerlidir. Kayıtlı sırrı olmayan kullanıcıları kabul etmek bilinçli bir kullanıma alma kararı olabilir, ancak MFA’nın zorunlu olduğunun kanıtı değildir ve bitiş tarihi olan geçici bir istisna olarak yazılmalıdır.

İstemcinin etkileşimini sunucunun tasarımına uydurun

auth-user-pass

Bu yönerge kullanıcı adı ve parola girişi ister. PAM’ı yapılandırmaz, bir kayıt kaydı oluşturmaz ve sunucuya parola alanında bir TOTP değeri olduğunu söylemez. Sunucu entegrasyonu ve istemci, dağıtımın gerçekten desteklediği bir etkileşim üzerinde anlaşmalıdır: bir meydan okuma, belgelenmiş birleşik kimlik bilgisi biçimi veya ürüne özgü bir akış.

İstemci tek bir alan gösteriyor diye parolaya kod eklemeyin. Bu yalnızca sunucunun eklentisinin tam olarak o biçimi beklediği yerde çalışır ve her yerde kafa karıştırıcı biçimde başarısız olur.

Tohumları ve QR malzemesini paylaşılan profillerden ve rutin tanılama günlüklerinden uzak tutun. Kimliği doğrulanmış oturum açma kanalından gönderilen bir kod, kontrollü kayıt sırasında verilen tohumla aynı nesne değildir ve ikisini bir destek kaydında karıştırmak sırların sızdığı yoldur.

Yeniden bağlanmalar, belirteçler ve işi bitiren test

İlk başarılı oturum açmadan sonra ne olacağını planlayın. Daha önce kabul edilmiş bir kod sonraki kimlik doğrulamada süresi dolmuş veya tekrar olarak reddedilmiş olabilir. auth-nocache kimlik bilgilerinin saklanmasını denetler ve MFA kurmaz, reneg-sec 0 ise forum başlıklarında ne kadar sık görünürse görünsün TOTP desteğinin tanımı değildir.

Bazı dağıtımlar ilk denetimden sonra kimlik doğrulama belirteçleri verir, böylece yeniden bağlanmalar yeniden sormaz. Bu, kendi geçerlilik penceresi ve kendi iptal geçmişi olan bir tasarım kararıdır, devraldığınız bir varsayılan değil.

Sonra kabul politikasını insanların gerçekten kullandığı istemciyle test edin. Doğru parola, sertifika ve güncel koda sahip kayıtlı bir kullanıcı bağlanabilmelidir. Yanlış kod, kaydı olmayan kullanıcı ve yasaklı hesap her biri başarısız olmalı ve neden sunucu günlüğünde görünmelidir. O reddedilmeleri görmeden elinizde bir istem var, politika değil.