Două verificări de autentificare nu sunt doi factori: VPN și RADIUS

Adăugarea unui al doilea backend de autentificare la o poartă VPN pare a adăuga un al doilea factor. De obicei adaugă o a doua verificare, care este un alt obiect cu alte moduri de eșec. Dacă ambele trebuie să reușească, ce demonstrează fiecare și ce se întâmplă când una nu este disponibilă sunt trei decizii separate. Greșiți-le și poarta devine mai strictă în demonstrație și mai slabă în timpul unei întreruperi.

Ce demonstrează de fapt un al doilea backend

O căutare în contul local demonstrează că un nume există într-o bază de date și că o parolă i-a corespuns. Un schimb RADIUS demonstrează că un server RADIUS a returnat Access-Accept pentru atributele primite. Niciuna dintre afirmații nu menționează un tip de factor, pentru că ambele verifică cunoașterea. Iar ghidul NIST privind identitatea digitală numără tipuri distincte de factori și autentificatorii lor, nu servere sau solicitări.

Există un design legitim în care participă ambele sisteme. Un serviciu central poate autentifica persoana, în timp ce poarta verifică independent dacă acel cont are dreptul la acest tunel. Aceasta este autorizare lângă autentificare, iar a o numi doi factori confundă o verificare de politică cu o dovadă de posesie.

RADIUS poate purta un al doilea factor real când stă în fața a ceva care verifică unul, cum ar fi o aprobare push sau un token hardware. Plicul nu spune ce autentificatori a prezentat utilizatorul, așa că citiți politica backendului, nu eticheta porții.

AND, OR și rezerva sunt produse diferite

Înainte de a compara implementări, decideți ce înseamnă ambele în cerința dumneavoastră. O politică AND cere ca fiecare verificare numită să treacă, o politică OR o acceptă pe cea care reușește, iar o rezervă o încearcă pe a doua doar în condiții de eșec declarate. Acestea trei se comportă opus în timpul unei întreruperi, iar de obicei doar una este ceea ce a intenționat revizuirea.

Adăugarea a două intrări de backend pe un ecran de configurare nu dezvăluie ce politică implementează produsul. Unele porți înlănțuie pluginuri în ordine și se opresc la primul refuz, ceea ce este AND doar când fiecare plugin este obligatoriu. Altele tratează contul local ca o suprascriere, ceea ce transformă o întrerupere centrală într-o ocolire. Răspunsul fiabil este un test negativ documentat pentru fiecare cale, rulat pe buildul pe care îl implementați.

Rezerva merită cea mai multă suspiciune, pentru că există ca să funcționeze în continuare când ceva este stricat. O rezervă care acceptă o parolă locală ori de câte ori RADIUS nu este accesibil a transformat o politică centrală într-o a doua ușă mai slabă.

Dubla verificare a OpenVPN este un caz concret

OpenVPN comunitar 2.6 cere atât un certificat de client, cât și scriptul auth-user-pass-verify configurat când ambele sunt activate. Este un AND documentat între verificarea certificatului și un script de acreditări, și sunt într-adevăr două verificări. Totuși nu sunt automat două tipuri de factori, deoarece scriptul poate valida doar o parolă.

Combinația lasă deschisă și întrebarea asocierii. Un certificat identifică de obicei un dispozitiv, în timp ce acreditările identifică o persoană, și nimic din fluxul implicit nu cere ca ambele să se refere la același principal. Decideți ce perechi sunt permise, apoi impuneți acea hartă în scriptul de verificare sau într-un pas de autorizare ulterior.

Modul doar certificat este o singură verificare, susținută de o cheie care poate sau nu să fie protejată de un PIN. Un PIN transformă aceeași acreditare în cunoaștere plus posesie doar dacă cheia nu poate fi folosită fără aceasta. Lăsarea cheii necriptate pe disc reduce a doua parte la o permisiune de fișier.

Producătorii de echipamente își construiesc propria instalație, adesea un modul PAM sau un plugin RADIUS în spatele unei console web. Comportamentul comunității este o referință pentru cum arată dublele verificări, nu o descriere a modului în care un echipament le combină.

Verificați combinația pe poarta dvs.

Citiți configurația înainte de a vă încrede în rezumatul consolei. Liniile care decid politica sunt modul certificatului, scriptul de acreditări și ordinea pluginurilor.

grep -E 'verify-client-cert|auth-user-pass-verify|plugin' /etc/openvpn/server.conf
openssl x509 -in /etc/openvpn/pki/issued/client01.crt -noout -subject -serial
radtest alice 'wrong-password' 127.0.0.1 0 testing123

grep arată dacă este necesar un certificat și ce script rulează după el, iar ordinea contează mai mult decât sugerează numele. Descărcarea certificatului dă identitatea pe care o va vedea poarta, inclusiv CN-ul și numărul de serie necesare pentru harta de asociere. Testul RADIUS este cazul negativ: o parolă greșită trebuie să dea Access-Reject, iar una corectă Access-Accept. Dacă o acreditare respinsă tot produce o sesiune, scriptul nu este deloc pe calea de autentificare.

Apoi rulați cazul de întrerupere pe o instanță de laborator: opriți backendul obligatoriu și conectați-vă cu acreditări valide. Rezultatul așteptat este un refuz, iar orice altceva este politica de rezervă pe care nimeni nu a documentat-o.

Scrieți cerința ca cazuri negative

O cerință utilizabilă numește dovezile, conturile permise să le prezinte și rezultatul când lipsește un verificator. Ea indică și împerecherea permisă între identitatea dispozitivului și identitatea persoanei. Este mai precisă decât numele produselor din comandă și poate fi testată.

Acceptarea ar trebui să includă patru refuzuri: un cont local nepotrivit, o dovadă obligatorie lipsă, un al doilea factor invalid și un backend obligatoriu inaccesibil. Fiecare refuz are nevoie de o linie de jurnal care îl distinge de celelalte, altfel următorul incident începe cu presupuneri. Înregistrați ce componentă a luat fiecare decizie, deoarece poarta, serverul RADIUS și directorul se vor învinui reciproc.

Rulați din nou cele patru refuzuri după orice modificare de plugin sau firmware. Sunt ieftine, iar politica pe care o protejează este partea pe care un atacator o sondează prima.