Kvifor ein delt VPN-utgang utløyser påloggingsvarsel du ikkje forårsaka
Ei påloggingsblokkering er vanlegvis ein risikoscore, ikkje ein dom over tunnelen din. Delte utgangar endrar kven andre som inngår i den scoren, og kva det kostar dei.
Opne ein kjend nettstad via ein VPN og få ei ekstra utfordring, og den nærliggande forklaringa er at tunnelen vart oppdaga. Noko vart oppdaga, men det var ikkje deg. Nettstaden scora eit sett signal, eitt av dei er kjeldeadressa, og den adressa vert delt med framande som kanskje genererte mislukka påloggingar eitt minutt tidlegare. Å lese avgjerda som ein dom over tilkoplinga di mistydar kva scoren er til for.
Kva ei kjeldeadresse kan og ikkje kan avgjere
Ei IP-adresse skildrar ein veg gjennom nettet på eit gitt tidspunkt. Ho identifiserer ikkje ein person, ein eining eller berre éin konto, og med carrier-grade NAT eller ein travel VPN-pool kan ho stå framfor tusental av urelaterte økter samstundes. Ein nettstad som handsamar adressa som ein identitet, handsamar henne i røynda som eit omdøme, noko som er ei statistisk utsegn og ikkje eit faktum.
To personar kan dele ein utgang og produsere motsette prov: den eine loggar inn med ein annan faktor, den andre prøver førti passord. Adressa er identisk, så kvar regel som berre byggjer på adressa, kan ikkje skilje dei, og same kva reaksjon ho utløyser, gjeld han for båe.
Det er ikkje eit argument for å ignorere adresser. Det er eit argument for å hugse kva signalet måler, fordi det meste av overraskande åtferd rundt VPN-påloggingar kjem frå ein kontroll som vert brukt på feil detaljnivå, snarare enn frå ein feil observasjon.
Kvifor blokkering av utgangen straffar framande
Ei blokkering på adressenivå er billeg å innføre og dyr å treffe. Radiusen hennar er kvar økt bak den adressa, og difor har delte adresser og NAT-åtferd si eiga historie i den operative dokumentasjonen: same resonnementet dukkar opp i IETF-arbeidet om delte kjeldeadresser og biverknadene av adressebasert filtrering.
| 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 |
Tenk på dei to feila ei blokkering skapar. Ein legitim kunde bak same utgang vert nekta teneste og sender inn ein støttebillett som kostar meir enn misbruket. Ein faktisk åtakar flyttar til neste utgang i ein pool på tusental og held fram, utan å ha brukt noko anna enn ei gjenoppkopling.
Proporsjonalitet er det manglande trinnet. Gjentekne mislukka påloggingar, ei byge av automatiserte førespurnader og eit autentisert tillatingsbrot er tre ulike hendingar, og berre den andre er plausibelt eit adresseforma problem. Å bruke den same nettverkssperra for heile nettstaden på alle tre er korleis ein tryggleikskontroll vert ein støttekø.
Legg avgjerda der prova er
Kontrollar på kontonivå følgjer kontoen på tvers av adresser, noko som svarar til eininga du faktisk bryr deg om. Fartsavgrensing, ventetider etter gjentekne feil og trinnvis autentisering for sensitive handlingar verkar alle på kontoen eller handlinga snarare enn på nettverksvegen. Det passar betre med eininga du faktisk vernar. Det fjernar òg åtakaren sitt insentiv til å leite etter ei fersk utgangsadresse.
NIST sine retningslinjer for autentisering handsamar desse som inndata til ei risikovurdering og listar opp adresse, geolokasjon og førespurnadstidspunkt blant signala, som er nøyaktig det rammeverket som er verdt å låne: eit signal opplyser ei avgjerd, det erstattar ikkje ein autentikator. Les den lista som inndata, ikkje som ein meny over ting som skal forbydast. Autentikatoren gjer framleis provet, og dei andre signala avgjer berre kor mykje friksjon som skal leggjast rundt han.
To designavgrensingar hindrar at kontonivåtilnærminga vert si eiga avbrot. Fartsgrenser treng ein trygg gjennomgangsveg slik at ein brukar kan rapportere feil klassifisering utan å publisere legitimasjon, og trinnvise utfordringar må ikkje kunne svarast med eit passord eller ein eingongskode gitt til ein uverifisert støttekontakt.
Korleis ein rettvis politikk ser ut utanfrå
Skriv ned kva avgjerd kvar kontroll støttar, og kontroller deretter at detaljnivået til kontrollen stemmer. Adressekontrollar svarar på spørsmål om trafikk frå eit nettverk; kontokontrollar svarar på spørsmål om ein konto; applikasjonshendingar svarar på spørsmål om åtferd etter autentisering. Ein politikk som nemner alle tre, kan reviderast, og ein som berre nemner VPN-trafikk, kan ikkje.
Mål deretter resultatet i staden for talet på reglar. Uautoriserte forsøk bør falle, legitime brukarar bør halde på ein støtta veg, og talet på støttekontaktar per tusen påloggingar bør ikkje auke. Ei blokkering som betrar det første talet medan ho øydelegg dei to andre, har flytta problemet, ikkje løyst det.
Å godta VPN-tilkoplingar og handheve misbrukskontrollar er sameinlege mål. Versjonen som verkar, handsamar kjeldeadressa som eitt inndata blant fleire, brukar den trongaste kontrollen som passar til prova, og lèt etter ein ærleg veg for personen som vart feilklassifisert. Versjonen som feilar, handsamar ei adresse som ein mistenkt og kallar det ein politikk.