Întărirea VPN în Windows: reparați autentificarea înainte de tunel

Serverul dumneavoastră VPN din Windows cere un nume de utilizator și o parolă, iar acel singur dialog ascunde trei sarcini fără legătură între ele. Una dovedește cine este persoana, una împiedică pe cineva care supraveghează firul să reutilizeze dovada, iar una decide la ce adrese poate ajunge după aceea. Majoritatea implementărilor mici întăresc mai întâi tunelul și lasă primele două sarcini la valorile implicite, ceea ce este ordinea greșită.

Lucrați în ordinea în care lucrează atacatorul. Mai întâi ce se poate captura de pe fir. Apoi ce se poate reda mai târziu cu acea înregistrare. În final, la ce poate ajunge un atacator autentificat odată ce este înăuntru.

Trei sarcini, un singur dialog

Identitatea este partea la care se gândesc oamenii și reprezintă doar o treime din problemă. Dovada identității trebuie să reziste unui observator care înregistrează schimbul și reîncearcă mai târziu. Autorizarea este o decizie separată pe care serverul o ia după ce identitatea este stabilită, iar Windows o păstrează într-un serviciu diferit de cel care validează acreditările.

Când toate trei locuiesc într-o singură găleată mentală, rezultatul obișnuit este un server care autentifică puternic și apoi permite utilizatorului să ajungă la tot. Repararea acestui lucru mai târziu este mai grea decât stabilirea politicii acum, pentru că până atunci profilul de firewall, grupul de adrese și rutele codifică toate vechea presupunere.

Separați cele trei în notițele dumneavoastră înainte de a atinge vreo setare, apoi reparați-le de la cea mai slabă verigă în sus.

De ce MS-CHAPv2 nu trece un test de reluare

Dacă serverul acceptă încă PPTP cu MS-CHAPv2, tunelul nu protejează parola în niciun sens semnificativ. Provocarea și răspunsul pot fi capturate și atacate offline, iar în 2012 un serviciu public de spargere a demonstrat recuperarea dintr-o astfel de strângere de mână în aproximativ o zi pentru o parolă tipică. O parolă mai lungă și mai complexă crește costul; nu elimină materialul de care atacatorul are nevoie din rețea.

Proprietatea pe care o doriți este o acreditare care nu poate fi redată. EAP-TLS cu certificate de client oferă fiecărui dispozitiv identitatea proprie și vă permite să revocați exact un dispozitiv.

Implementarea certificatelor este muncă reală: o CA privată, o cale de revocare pe care clienții o verifică și un plan de reînnoire care supraviețuiește fluctuației de personal. Tratați acea muncă drept proiect și nu drept obstacol între dumneavoastră și un tunel funcțional. Bugetați-o așa cum ați bugeta o înlocuire de firewall. O parolă partajată este mai ieftină doar până la prima revocare.

O cheie pre-partajată autentifică perechea, nu persoana

L2TP/IPsec cu o cheie pre-partajată dovedește că două gateway-uri cunosc același secret. Nu spune nimic despre ce om se conectează și nu poate distinge un angajat de altul la acel nivel. Folosiți o valoare aleatoare lungă, mult peste cele zece caractere sugerate de unele ghiduri, pentru că cine capturează strângerea de mână poate ataca cheia offline.

Fiecare client din acel profil partajează secretul, așa că eliminarea unei persoane înseamnă redistribuirea lui tuturor celor rămași. Păstrați un pas separat de autentificare a utilizatorului deasupra secretului la nivel de mașină și treceți la certificate pe măsură ce populația de clienți crește. O cheie pre-partajată combinată cu MS-CHAPv2 sunt două straturi slabe, iar al doilea îl anulează pe primul.

Autorizarea aparține Network Policy Server

NPS din Windows decide cine se poate conecta și face asta după ce autentificarea a reușit deja. Acea separare este cel mai util control de întărire din produs, iar multe implementări îl lasă neatins.

Folosiți condiții de politică ce reflectă constrângeri reale: apartenența la grup, fereastra de timp în care suportul are personal și starea dispozitivului dintr-o verificare de sănătate. Adăugați un al doilea factor acolo unde datele justifică frecarea și rețineți că politica este evaluată la fiecare încercare de conectare, ceea ce o face un control viu și nu un document.

Contabilitatea RADIUS vă oferă și o înregistrare a cine s-a conectat și când. Acel jurnal este diferența dintre o analiză a incidentului și o presupunere și există indiferent dacă cineva îl citește vreodată.

Limitați la ce poate ajunge o autentificare reușită

Adaptorul VPN ar trebui să ajungă într-un profil de firewall care permite serviciile necesare rolului său și nu întreaga subrețea. Problema rutării este separată de filtrare. Un tunel complet protejează dispozitivul clientului și trimite fiecare octet prin legătura dumneavoastră superioară, în timp ce un tunel divizat păstrează traficul local local și expune dispozitivul oricărei rețele în care se află.

Niciuna dintre cele două alegeri nu este o valoare implicită de securitate. Ambele trebuie notate lângă profilul de firewall pe care îl presupun.

Verificați căile de eșec

Testați ce ar trebui să se rupă: o parolă greșită, un certificat expirat, un dispozitiv revocat, un utilizator din afara grupului. Fiecare ar trebui să eșueze într-un alt punct, iar jurnalul ar trebui să spună care a fost. Rulați setul mai întâi pe un cont de test, apoi repetați-l pentru un utilizator real. O respingere care ajunge în jurnalul de evenimente fără motiv merită reparată cu mult înainte de a avea nevoie de acea înregistrare.

Apoi confirmați ce porturi sunt publicate și de ce. PPTP are nevoie de TCP 1723 și de GRE ca protocol IP în loc de port, IKEv2 are nevoie de UDP 500 și 4500, iar L2TP are nevoie de UDP 1701 plus IPsec. Expunerea unei interfețe de administrare pentru ca un client să se conecteze nu este o reparație, este un al doilea incident care așteaptă să fie descoperit.

În final, decideți ce înregistrează serverul și pentru cât timp. Un punct final fără istoric de autentificare nu poate răspunde la prima întrebare după un incident, și anume dacă încercarea a fost vreodată autorizată.