Hvorfor en delt VPN-utgang utløser påloggingsvarsler du ikke forårsaket
En påloggingsblokkering er vanligvis en risikoscore, ikke en dom over tunnelen din. Delte utganger endrer hvem andre som inngår i den scoren, og hva det koster dem.
Åpne et kjent nettsted via en VPN og få en ekstra utfordring, og den nærliggende forklaringen er at tunnelen ble oppdaget. Noe ble oppdaget, men det var ikke deg. Nettstedet scoret et sett signaler, hvorav ett er kildeadressen, og den adressen deles med fremmede som kanskje genererte mislykkede pålogginger et minutt tidligere. Å lese avgjørelsen som en dom over tilkoblingen din misforstår hva scoren er for.
Hva en kildeadresse kan og ikke kan avgjøre
En IP-adresse beskriver en vei gjennom nettverket på et gitt tidspunkt. Den identifiserer ikke en person, en enhet eller bare én konto, og med carrier-grade NAT eller en travel VPN-pool kan den stå foran tusener av ubeslektede økter samtidig. Et nettsted som behandler adressen som en identitet, behandler den egentlig som et omdømme, noe som er en statistisk uttalelse og ikke et faktum.
To personer kan dele en utgang og produsere motsatte bevis: den ene logger inn med en annen faktor, den andre prøver førti passord. Adressen er identisk, så enhver regel som bare bygger på adressen, kan ikke skille dem, og uansett hvilken reaksjon den utløser, gjelder den for begge.
Det er ikke et argument for å ignorere adresser. Det er et argument for å huske hva signalet måler, fordi det meste av overraskende atferd rundt VPN-pålogginger kommer fra en kontroll som brukes på feil detaljnivå, snarere enn fra en feil observasjon.
Hvorfor blokkering av utgangen straffer fremmede
En blokkering på adressenivå er billig å implementere og dyr å treffe. Dens radius er hver økt bak den adressen, og derfor har delte adresser og NAT-atferd sin egen historie i den operative dokumentasjonen: samme resonnement dukker opp i IETF-arbeidet om delte kildeadresser og bivirkningene 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å de to feilene en blokkering skaper. En legitim kunde bak samme utgang blir nektet tjeneste og sender inn en støttebillett som koster mer enn misbruket. En faktisk angriper flytter til neste utgang i en pool på tusener og fortsetter, uten å ha brukt noe annet enn en gjenoppkobling.
Proporsjonalitet er det manglende trinnet. Gjentatte mislykkede pålogginger, en byge av automatiserte forespørsler og en autentisert tillatelsesbrudd er tre forskjellige hendelser, og bare den andre er plausibelt et adresseformet problem. Å bruke den samme nettverkssperren for hele nettstedet på alle tre er hvordan en sikkerhetskontroll blir en støttekø.
Legg beslutningen der bevisene er
Kontroller på kontonivå følger kontoen på tvers av adresser, noe som samsvarer med enheten du faktisk bryr deg om. Hastighetsbegrensning, ventetider etter gjentatte feil og trinnvis autentisering for følsomme handlinger virker alle på kontoen eller handlingen snarere enn på nettverksveien. Det passer bedre med enheten du faktisk beskytter. Det fjerner også angriperens insentiv til å lete etter en fersk utgangsadresse.
NISTs veiledning for autentisering behandler disse som inndata til en risikovurdering og lister opp adresse, geolokasjon og forespørselstidspunkt blant signalene, som er nøyaktig det rammeverket som er verdt å låne: et signal opplyser en beslutning, det erstatter ikke en autentisator. Les den listen som inndata, ikke som en meny over ting som skal forbys. Autentisatoren gjør fortsatt beviset, og de andre signalene avgjør bare hvor mye friksjon som skal legges rundt den.
To designbegrensninger hindrer at kontonivåtilnærmingen blir sin egen avbrudd. Hastighetsgrenser trenger en sikker gjennomgangsvei slik at en bruker kan rapportere feil klassifisering uten å publisere legitimasjon, og trinnvise utfordringer må ikke kunne besvares med et passord eller en engangskode gitt til en uverifisert støttekontakt.
Hvordan en rettferdig policy ser ut utenfra
Skriv ned hvilken beslutning hver kontroll støtter, og kontroller deretter at kontrollens detaljnivå stemmer. Adressekontroller svarer på spørsmål om trafikk fra et nettverk; kontokontroller svarer på spørsmål om en konto; applikasjonshendelser svarer på spørsmål om atferd etter autentisering. En policy som nevner alle tre, kan revideres, og en som bare nevner VPN-trafikk, kan ikke.
Mål deretter resultatet i stedet for antall regler. Uautoriserte forsøk bør falle, legitime brukere bør beholde en støttet vei, og antallet støttekontakter per tusen pålogginger bør ikke øke. En blokkering som forbedrer det første tallet mens den ødelegger de to andre, har flyttet problemet, ikke løst det.
Å godta VPN-tilkoblinger og håndheve misbrukskontroller er forenlige mål. Versjonen som virker, behandler kildeadressen som ett inndata blant flere, bruker den snevreste kontrollen som passer til bevisene, og etterlater en ærlig vei for personen som ble feilklassifisert. Versjonen som feiler, behandler en adresse som en mistenkt og kaller det en policy.