RADIUS'u OpenVPN'e bağlamak: eklenti mi betik kancası mı?

Eklenti hâlâ güncel derlemelerden daha eski başlıklarda öneriliyor ve dün derlenmiş bir sunucuda yüklenirken başarısız oluyor. Bu, bir yolla düzeltilebilecek bir yapılandırma hatası değil. Eklenti ve betik kancası aynı sorunu farklı katmanlarda çözer ve birinden diğerine geçmek neyin kurulacağını, neyin sunucu ayrıcalıklarıyla çalıştığını ve başarısız bir girişin size gerçekte ne söylediğini değiştirir.

Mit: eklenti desteklenen yoldur

Eklenti, OpenVPN sürecine yüklenen paylaşımlı bir nesnedir, bu yüzden sürecin sunduğu arayüzle eşleşmelidir. Derlemeler değişir, paketleme değişir ve eski bir arayüz için derlenmiş kitaplık yüklenmeyi reddeder. Sunucu yapılandırmasında hiçbir şey bu boşluğu kapatamaz, bu yüzden "sadece radiusplugin kurun" tavsiyesi başlamayan bir sunucuyla biter.

Betik kancası bunun yerine sürecin dışında durur. OpenVPN bir program çalıştırır, ona kimlik bilgilerini verir ve bir karar okur. Bu ayrışma onu yükseltmelerden sağ çıkarır ve onu eklentinin hiç olmadığı biçimde sizin sorumluluğunuz yapar.

Hiçbir yaklaşım yapısı gereği daha güvenli değildir. Biri daemon içinde yabancı kod çalıştırır; diğeri kimlik bilgilerini elinde tutarak sizin kodunuzu yanında çalıştırır. Doğru soru, bu iki riskten hangisini gerçekten işletebileceğinizdir.

Eklenti neyi birbirine bağlıyordu

Eklentinin RADIUS ana bilgisayarı, paylaşılan sır, yeniden deneme sayısı ve zaman aşımı içeren kendi yapılandırma dosyası vardı ve sunucu yapılandırması ona tek satırla başvuruyordu. Kimlik bilgilerinin işlenmesi sunucu süreci içinde kalıyordu, yani parola yöneticinin güvenceye alması gereken bir süreç sınırını hiç geçmiyordu.

Bedeli bağlılıktı. Her OpenVPN yükseltmesi uyumsuz bir arayüz riski taşıyordu ve paketi yeniden derleyen her dağıtım artık eşleşmeyen bir kitaplık üretme riski taşıyordu. Bu olduğunda arıza yüksek sesli ve anidir ve bu, tasarımın tek merhametidir.

Böyle bir eklenti hâlâ derlemenizde yükleniyorsa, daha küçük işletim yüzeyi olabilir. Hangi arayüz için derlendiğini doğrulayın, test ettiğiniz derlemeye sabitleyin ve her yükseltmeyi rutin paket güncellemesi değil, tam giriş testi gerektiren bir değişiklik olarak ele alın.

Betik kancası gerçekte neye güvenir

Kanca auth-user-pass-verify ve bir teslim mekanizmasıyla yapılandırılır: ortam değişkenleri veya geçici dosya. Ortam biçiminde OpenVPN, parolanın betiklere açılmasına izin veren belgelenmiş düzey olan script-security 3'ü gerektirir. Bu düzey varsayılanın kasıtlı olarak zayıflatılmasıdır ve gerekçesi eklenmiş bir izin olarak ele alınmalıdır.

Betiğin dokunduğu her şey bu güveni devralır. root'a ait olmalı, grup veya diğerleri tarafından yazılamamalı, mutlak yolla belirtilmeli ve güvenilmeyen bir değerin kabuğa ulaştığı hiçbir yer bulunmamalıdır. Her değişkeni tırnak içine alın, beklenmeyen karakterleri reddedin ve asla verilen kullanıcı adından komut oluşturmayın. Her giriş denemesinde root olarak çalışan bir betik tam da bu dört özellik nedeniyle bir kez gözden geçirilmeyi hak eder.

ls -l /usr/local/sbin/radius-auth.sh
stat -c '%U %a' /usr/local/sbin/radius-auth.sh

Dosya teslim biçimi ortam mirası sorununu atlar ve kimlik bilgilerini kısıtlı izinlere sahip geçici bir dosya aracılığıyla betiğe verir. İstemciniz bunu destekliyorsa genellikle daha iyi varsayılandır, ancak arıza durumunda temizlenecek bir nesne daha ekler.

Çıkış kodları açık şekilde başarısız olup olmayacağınızı belirler

Betiğin çıkış durumu karardır: sıfır kabul eder, sıfır olmayan reddeder. Sorun çıkaran desen, yalnızca RADIUS yanıtı belirli bir kabul belirteci içerdiğinde kabul eden ve diğer her şey için hata döndüren bir kabuk betiğidir, çünkü bu üç farklı olayı tek yanıtta birleştirir. Yanlış parola, erişilemeyen sunucu ve bozuk yanıt hepsi aynı redde dönüşür.

Kanca yalnızca kabul veya red döndürebilse bile bu durumları betikte ayırın. Arka uç sonucunu ayrı günlüğe yazın, zaman aşımı ve taşıma hatalarında uyarın ve izlemede kimlik doğrulamanın hizmet kapalı olduğu için mi yoksa kullanıcılar yanlış yazdığı için mi başarısız olduğunu açık hale getirin.

İki alışkanlık geri kalanı sağlıklı tutar. RADIUS otorite ise, parolanın kontrol edildiği tek yer olmalıdır, çünkü gölge tablo aynı soruya iki yanıt üretir ve ikincisi kimsenin izlemediği bir saldırı yüzeyidir. Ve kancanın her denemede yeniden çağrıldığını unutmayın, bu yüzden yavaş bir betik ile sabırsız bir istemci, RADIUS tarafında gecikme veya politika eklemezseniz parola tahmini için bir yükseltici olur.

Sertifika gittiğinde neyden vazgeçersiniz

Bu biçimdeki birçok dağıtım, istemci sertifikası denetimini tamamen kapatır ve kullanıcı adı ile parolayı istemcinin tüm iddiası olarak bırakır. O ayarla kaybolan şey sertifika tabanlı kimliktir. Kanal şifreli kalır, ancak istemciyi adlandıran tek şey RADIUS kararıdır. Daha önce sertifika öznesine dayanan her şey artık kullanıcı adına dayanmalıdır.

Kimliği doğrulanmamış bir eşin el sıkışmayı inceleyememesi veya dolduramaması için denetim kanalı korumasını yerinde tutun ve kullanıcı başına yapılandırma ortak ada bağlı olduğunda username-as-common-name kullanın. Yönetilen ağ geçitleri bunu genellikle farklı çözer, sertifika kimlik doğrulamasını RADIUS ile EAP-TLS konuşan bir ağ geçidinde sonlandırır ve bu durumda bu sunucu yönergelerinin hiçbiri geçerli değildir. Komşu ürünün modelini değil, kendi platformunuzun belgelediği modeli kopyalayın. Önemli yönergeler yeterince farklıdır ki karıştırılmaları ayrıştırılan ve sonra kimseyi doğrulamayan bir yapılandırma üretir.