De ce o ieșire VPN partajată declanșează avertismente de autentificare pe care nu le-ați cauzat
O blocare a autentificării este de obicei un scor de risc, nu un verdict asupra tunelului dvs. Ieșirile partajate schimbă cine altcineva intră în acel scor și cât îi costă.
Deschideți un site cunoscut printr-o VPN și primiți o verificare suplimentară, iar explicația tentantă este că tunelul a fost detectat. Ceva a fost detectat, dar nu ați fost dvs. Site-ul a punctat un set de semnale, unul dintre ele fiind adresa sursă, iar acea adresă este partajată cu străini care poate generau autentificări eșuate cu un minut înainte. Citirea deciziei ca un verdict asupra conexiunii dvs. înseamnă înțelegerea greșită a scopului scorului.
Ce poate și ce nu poate stabili o adresă sursă
O adresă IP descrie o cale prin rețea la un anumit moment. Nu identifică o persoană, un dispozitiv sau măcar un singur cont, iar cu NAT la nivel de operator sau un pool VPN aglomerat poate reprezenta mii de sesiuni fără legătură simultan. Un site care tratează adresa ca identitate o tratează de fapt ca reputație, ceea ce este o afirmație statistică, nu un fapt.
Două persoane pot împărți o ieșire și pot produce dovezi opuse: una se autentifică cu succes cu un al doilea factor, cealaltă încearcă patruzeci de parole. Adresa este identică, așa că nicio regulă bazată doar pe adresă nu le poate distinge, iar orice reacție declanșată se aplică ambelor.
Asta nu este un argument pentru ignorarea adreselor. Este un argument pentru a ne aminti ce măsoară semnalul, pentru că cea mai mare parte a comportamentului surprinzător din jurul autentificărilor VPN provine din aplicarea unui control la granularitatea greșită, nu dintr-o observație greșită.
De ce blocarea ieșirii pedepsește străini
O blocare la nivel de adresă este ieftin de implementat și scump de țintit. Raza ei de acțiune este fiecare sesiune din spatele acelei adrese, și de aceea comportamentul adreselor partajate și al NAT are propria istorie în documentația operațională: același raționament apare în lucrările IETF despre adresele sursă partajate și efectele colaterale ale filtrării bazate pe adresă.
| Signal | What it provides evidence about | What it cannot settle |
|---|---|---|
| Source address and its reputation | The network path, and how that path behaved recently for others | Which account or person is behind the request |
| Authenticator result | Whether the account claim was proved at the required strength | Whether the account's owner initiated it |
| Request timing and volume | Whether the pattern looks automated or burst-like | Whether the intent was malicious or a shared client |
| Application event history | What this account has done while signed in | Anything about requests that never authenticated |
Luați în considerare cele două eșecuri pe care le creează o blocare. Unui client legitim din spatele aceleiași ieșiri i se refuză serviciul și deschide un tichet de suport care costă mai mult decât abuzul. Un atacator real se mută la următoarea ieșire într-un pool de mii și continuă, fără să fi cheltuit altceva decât o reconectare.
Proporționalitatea este pasul lipsă. Autentificările eșuate repetate, un val de cereri automatizate și o încălcare autentificată a permisiunilor sunt trei evenimente diferite, și doar al doilea este plauzibil o problemă în formă de adresă. Aplicarea aceleiași interdicții de rețea la nivel de site tuturor trei este modul în care un control de securitate devine o coadă de suport.
Puneți decizia acolo unde este dovada
Controalele la nivel de cont urmăresc contul prin adrese, ceea ce corespunde entității care vă interesează cu adevărat. Limitarea ratei, perioadele de așteptare după eșecuri repetate și autentificarea în trepte pentru acțiuni sensibile operează toate asupra contului sau acțiunii, nu asupra căii de rețea. Asta se potrivește mai bine entității pe care o protejați cu adevărat. De asemenea, elimină stimulentul atacatorului de a căuta o adresă de ieșire nouă.
Ghidurile NIST privind autentificarea tratează aceste elemente ca intrări ale unei evaluări de risc și enumeră adresa, geolocația și momentul cererii printre semnale, ceea ce este exact cadrul de împrumutat: un semnal informează o decizie, nu înlocuiește un autentificator. Citiți acea listă ca intrări, nu ca un meniu de lucruri de interzis. Autentificatorul face în continuare dovada, iar celelalte semnale doar decid câtă frecare se pune în jurul lui.
Două constrângeri de proiectare împiedică abordarea la nivel de cont să devină propria ei defecțiune. Limitele de rată au nevoie de o cale sigură de revizuire, astfel încât un utilizator să poată raporta o clasificare greșită fără a publica credențiale, iar provocările în trepte nu trebuie să poată fi rezolvate cu o parolă sau un cod de unică folosință dat unui contact de suport neverificat.
Cum arată de la exterior o politică corectă
Notați ce decizie susține fiecare control, apoi verificați dacă granularitatea controlului se potrivește. Controalele de adresă răspund la întrebări despre traficul dintr-o rețea; controalele de cont răspund la întrebări despre un cont; evenimentele aplicației răspund la întrebări despre comportamentul după autentificare. O politică ce le numește pe toate trei este auditabilă, iar una care numește doar trafic VPN nu este.
Apoi măsurați rezultatul, nu numărul de reguli. Încercările neautorizate ar trebui să scadă, utilizatorii legitimi ar trebui să păstreze o cale acceptată, iar numărul de contacte de suport la mie de autentificări nu ar trebui să crească. O blocare care îmbunătățește primul număr distrugându-le pe celelalte două a mutat problema, nu a rezolvat-o.
Acceptarea conexiunilor VPN și aplicarea controalelor de abuz sunt obiective compatibile. Versiunea care funcționează tratează adresa sursă ca o intrare între mai multe, aplică cel mai îngust control care se potrivește dovezilor și lasă o cale onestă pentru persoana clasificată greșit. Versiunea care eșuează tratează o adresă ca suspect și numește asta politică.