Əvvəlcə EAP metodu: VPN hansı parol heşindən istifadə edə bilər
VPN sirri yoxlayır, veb heşi yox. Metodu oxuyun, sonra eyni parolların işləməyə davam edəcəyinə söz verməzdən əvvəl anbarın nə saxladığını yoxlayın.
Bir çox komandanın işləyən veb girişi və eyni cədvəldən gələn hər parolu rədd edən VPN-i olur. Veb tətbiqi özü hesabladığı heşi müqayisə edir, tunel isə müştəridən sirrə sahib olduğunu serverin yoxlaya biləcəyi şəkildə sübut etməsini tələb edir. Bunlar saxlanılan materiala qoyulan fərqli tələblərdir. Bu layihələrin çoxu məhz həmin boşluqda dayanır.
Əvvəlcə metodu, sonra sxemi oxuyun
Hər hansı sxemə baxmazdan əvvəl seçilmiş metodun tələb etdiyi sübutu yazın. Çağırış-cavab metodu serverin gözlənilən cavabı hesablaya biləcəyi materiala ehtiyac duyur ki, bu da praktikada parol və ya uyğun törəmə forması deməkdir. Parolu qorunan tunel daxilində daşıyan metod isə yoxlayıcıda parolun özünü tələb edir. Metod sənədini müştəri konfiqurasiyası üçün deyil, yoxlayıcı tələbi üçün oxuyun, çünki müştəri tələbləri adətən asan hissədir.
Müasir veb çərçivəsinin yaratdığı duzlanmış heş heç birini vermir. O, konkret bir müqayisəni yoxlayır və gəldiyi sirrə geri çevrilə bilmir.
Çağırış-cavab duzlanmış heşdən istifadə edə bilməz
MSCHAPv2 çağırış-cavab mübadiləsidir, buna görə server parolu heç vaxt almır və saxlanan sətri müqayisə edə bilmir. Gözlənilən cavabı artıq malik olduğu materialdan çıxarmalıdır, buna görə də uyğun saxlanan formalar bu qədər dardır. Hər istifadəçi üçün duzla bcrypt və ya Argon2 dəyəri elə birtərəflidir ki, mübadiləni tamamilə istisna edir. Aşağıdakı cədvəl metod adından deyil, saxlama formasından başlayır, çünki cavabı müəyyən edən saxlama formasıdır.
| What the store holds | What that material can verify | What has to change |
|---|---|---|
| A bcrypt or Argon2 value with a per-user salt | nothing challenge-response can use, and not the password either | re-enrol the users, or place a verifying service in front |
| An unsalted NT-hash | MSCHAPv2, and inner PAP through a TLS tunnel | nothing, as long as that store is the verifier |
| A client certificate with a revocation list | EAP-TLS only | move enrolment and revocation to the PKI owner |
Bu SQL plagin sənədləri strongSwan üçün konfiqurasiya və etimadnamələr üzrə öz sxemini müəyyən edir və layihə həmin plagini hələ də eksperimental kimi qeyd edir. Orada heç nə tətbiqin istifadəçi cədvəlinə uyğunlaşmır və saxlanan dəyəri hansı heşləmə sxeminin yaratdığını təxmin etmir. Odur ki, real variantlar keçidin istifadə edə biləcəyi anbara miqrasiya və ya mövcud anbarın qarşısında mübadiləni yerinə yetirə bilən autentifikasiya xidmətidir. Bundan başqa hər şey içində gizli fərziyyə daşıyan birləşdiricidir.
RADIUS işi yerini dəyişir, tələbi yox
EAP-ni RADIUS serverinə həvalə etmək yoxlamanın yerini dəyişir və adətən audit izini yaxşılaşdırır. O, birtərəfli heşdən parolu bərpa etmir, buna görə autentifikasiya xidməti yenə də dayandırdığı metoda uyğun materiala ehtiyac duyur. Komandalar bunu RADIUS yolunu qurduqdan və o biri tərəfdə eyni divara çıxdıqdan sonra öyrənir.
RADIUS serverinin uyğun etimadnamə saxlayan kataloqu oxuya bildiyi yerdə dizayn işləyir və VPN keçidi sadə qalır. Oxuya bilmədiyi yerdə dürüst cavab daha bir birləşdirici deyil, qeydiyyat dəyişikliyidir. Təminat və ləğvetmə kimliyə sahib olanın işidir, ona görə də dəstəklənən sinxronizasiya prosesi olmayan köçürülmüş cədvəl vahid giriş deyil, ikinci etimadnamə həyat dövrüdür. İnsanlar parolu yalnız bir yerdə sıfırlayan kimi ilk dəfə yoldan çıxır və bu sapma hər iki sistemdə mövcud olan hesab hər birində fərqli davranana qədər səssiz qalır.
Kataloqu oxuyan hesabı yalnız həmin oxuma ilə məhdudlaşdırın və onu keçidin öz konfiqurasiyası üçün istifadə etdiyi hesabdan ayrı saxlayın. Ortaq inzibati hesab yalnız-oxuma dizaynını daha geniş təsir radiusuna çevirir.
Hesab harada yaşamalıdır
Material məsələsi həll olunduqdan sonra iki arxitektura qalır. Keçid yalnız özünün oxuduğu kiçik etimadnamə anbarına sahib ola bilər, ya da korporativ kataloqun qarşısında duran autentifikasiya xidmətinə həvalə edə bilər.
Birincisi düşünmək üçün asandır və istifadəçi üçün pisdir, çünki ona saxlamalı ikinci parol qalır. İkincisi bir kimlik saxlayır və indi kimsə qoşula bilməzdən əvvəl işlək olmalı xidmətdən asılılıq əlavə edir. Heç biri səhv deyil, amma seçim keçidin konfiqurasiyasının yanında qeyd olunmalıdır, yoxsa növbəti mühəndis digərinin seçildiyini güman edəcək. Nə seçsəniz də, aşağıdakı iki əmr onu dəyişməzdən əvvəl mövcud vəziyyəti göstərənlərdir.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsHesab autentifikasiyası həm də avtorizasiyanı həll etmir. Qrup üzvlüyü, cihaz vəziyyəti və şəbəkə icazəsi istifadəçi tələb olunan kimliyi sübut etdikdən sonra yenə də açıq xəritələmə tələb edir. Mükəmməl autentifikasiya edib heç nəyə icazə verməyən bağlantı metodun səhvi deyil, siyasətin nəticəsidir.