RADIUS-u OpenVPN-ə qoşmaq: plagin, yoxsa skript çəngəli?

Plagin hələ də cari buraxılışlardan əvvələ aid müzakirələrdə tövsiyə olunur, lakin dünən kompilyasiya edilmiş serverdə yüklənmə mərhələsində uğursuz olur. Bu, yol ilə düzəldilə bilən konfiqurasiya səhvi deyil. Plagin və skript çəngəli eyni problemi müxtəlif qatarlarda həll edir və birindən digərinə keçmək nəyin quraşdırılmalı olduğunu, nəyin server səlahiyyətləri ilə işlədiyini və uğursuz girişin sizə əslində nə dediyini dəyişir.

Mif: plagin dəstəklənən yoldur

Plagin OpenVPN prosesinə yüklənən paylaşılan obyektdir, buna görə də həmin prosesin təqdim etdiyi interfeysə uyğun olmalıdır. Buraxılışlar dəyişir, paketləmə dəyişir və köhnə interfeys üçün kompilyasiya edilmiş kitabxana sadəcə yüklənməkdən imtina edir. Server konfiqurasiyasında heç nə bu boşluğu aradan qaldıra bilməz, buna görə də "sadəcə radiusplugin quraşdır" məsləhəti başlamayan bir serverlə bitir.

Skript çəngəli əvəzində prosesdən kənarda dayanır. OpenVPN proqram icra edir, ona etimad məlumatlarını verir və geri hökm oxuyur. Məhz bu ayrılma onu yeniləmələrdən sonra da işlək saxlayır və həm də onu plagində heç vaxt olmayan şəkildə sizin məsuliyyətinizə çevirir.

Heç bir yanaşma quruluşca daha təhlükəsiz deyil. Biri daemon daxilində yad kod işlədir; digəri sizin kodunuzu onun yanında, etimad məlumatları əlində işlədir. Düzgün sual budur: bu iki riskdən hansını həqiqətən idarə edə bilirsiniz.

Plagin nəyi birləşdirmişdi

Plagin RADIUS hostu, ortaq sirr, təkrar sayı və fasilə ilə öz konfiqurasiya faylını daşıyırdı və server konfiqurasiyası ona bir sətirlə istinad edirdi. Etimad məlumatlarının emalı server prosesinin daxilində qaldı, yəni parol administratorun qorumalı olduğu proses sərhədini heç vaxt keçmədi.

Qiyməti bağlılıq idi. Hər OpenVPN yeniləməsi uyğunsuz interfeys riski daşıyırdı və paketi yenidən quran hər distributiv artıq uyğun olmayan kitabxana yaratmaq riski daşıyırdı. Bu baş verəndə uğursuzluq səs-küylü və dərhal olur, dizaynın yeganə mərhəməti də budur.

Əgər belə bir plagin hələ də buraxılışınızda yüklənirsə, o, daha kiçik əməliyyat səthi ola bilər. Onun hansı interfeys üçün qurulduğunu təsdiqləyin, sınaqdan keçirdiyiniz buraxılışa bağlı saxlayın və hər yeniləməni adi paket yeniləməsi deyil, tam giriş testi tələb edən dəyişiklik kimi qəbul edin.

Skript çəngəli əslində nəyə güvənir

Çəngəl auth-user-pass-verify və çatdırılma mexanizmi ilə konfiqurasiya olunur: mühit dəyişənləri və ya müvəqqəti fayl. Mühit formasında OpenVPN script-security 3 tələb edir, bu, parolun skriptlərə açılmasına icazə verən sənədləşdirilmiş səviyyədir. Həmin səviyyə standartın bilərəkdən zəiflədilməsidir və ona əsaslandırma əlavə edilmiş icazə kimi yanaşmaq lazımdır.

Skriptin toxunduğu hər şey bu etimadı miras alır. O, root-a məxsus olmalı, qrup və ya digərləri tərəfindən yazıla bilməməli, mütləq yol ilə göstərilməli və etibarsız dəyərin shell-ə çatdığı heç bir yerə malik olmamalıdır. Hər dəyişəni dırnağa alın, gözlənilməz simvolları rədd edin və heç vaxt verilən istifadəçi adından əmr qurmayın. Hər giriş cəhdində root kimi işləyən skript məhz bu dörd xüsusiyyət üçün bir dəfə nəzərdən keçirilməyə dəyər.

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

Fayl çatdırılma forması mühit mirası probleminindən qaçır və etimad məlumatlarını məhdud icazələrlə müvəqqəti fayl vasitəsilə skriptə verir. Əgər müştəriniz bunu dəstəkləyirsə, bu, adətən daha yaxşı standartdır, baxmayaraq ki, uğursuzluqda təmizlənməli daha bir obyekt əlavə edir.

Çıxış kodları açıq qalmağa qərar verir

Skriptin çıxış statusu hökmdür: sıfır qəbul edir, sıfırdan fərqli rədd edir. Problem yaradan nümunə, yalnız RADIUS cavabında müəyyən qəbul işarəsi olduqda qəbul edən və hər şey üçün uğursuzluq qaytaran shell skriptidir, çünki bu, üç fərqli hadisəni bir cavabda birləşdirir. Səhv parol, əlçatmaz server və qüsurlu cavab hamısı eyni rəddə çevrilir.

Çəngəl yalnız qəbul və ya rədd qaytara bilsə də, bu halları skriptdə ayırın. Backend nəticəsini ayrıca qeyd edin, fasilələr və nəqliyyat xətaları üçün xəbərdarlıq qurun və monitorinqdə autentifikasiyanın istifadəçilərin səhv yazması üzündən deyil, xidmətin işləməməsi üzündən uğursuz olduğunu aydın edin.

Qalanını iki vərdiş ağıllı saxlayır. Əgər RADIUS səlahiyyətdirsə, parolun yoxlanıldığı yeganə yer o olmalıdır, çünki kölgə cədvəli eyni suala iki cavab yaradır və ikincisi heç kimin izləmədiyi hücum səthidir. Və unutmayın ki, çəngəl hər təkrar cəhddə yenidən çağırılır, buna görə yavaş skriptlə səbirsiz müştərinin birləşməsi, gecikmə və ya RADIUS tərəfində siyasət əlavə etməsəniz, parol təxminləri üçün gücləndiriciyə çevrilir.

Sertifikat yox olanda nədən imtina edirsiniz

Bu formada bir çox yerləşdirmə müştəri sertifikatının yoxlanmasını tamamilə söndürür və müştərinin bütün iddiası olaraq istifadəçi adı ilə parolu qoyur. Bu parametrlə yox olan sertifikata əsaslanan kimlikdir. Kanal şifrəli qalır, lakin müştərini adlandıran yeganə şey RADIUS hökmüdür. Əvvəllər sertifikat subyektinə əsaslanan hər şey indi istifadəçi adına əsaslanmalıdır.

Nəzarət kanalının qorunmasını yerində saxlayın ki, autentifikasiya olunmamış həmkar əl sıxışmanı yoxlaya və ya daşdıra bilməsin və istifadəçi üzrə konfiqurasiya ümumi addan asılı olduqda username-as-common-name istifadə edin. İdarə olunan şlüzlər bunu çox vaxt başqa cür həll edir, sertifikat autentifikasiyasını RADIUS ilə EAP-TLS danışan şlüzda bitirir və bu halda bu server direktivlərindən heç biri tətbiq olunmur. Öz platformanızın sənədləşdirdiyi modeli kopyalayın, qonşu məhsulun modelini deyil. Vacib direktivlər kifayət qədər fərqlənir ki, onları qarışdırmaq təhlil olunan, sonra heç kəsi autentifikasiya etməyən konfiqurasiya yaradır.