Hvorfor en delt VPN-udgang udløser loginadvarsler, du ikke selv har forårsaget
En loginblokering er normalt en risikoscore, ikke en dom over din tunnel. Delte udgange ændrer, hvem der ellers indgår i den score, og hvad det koster dem.
Åbn et velkendt websted via en VPN og få en ekstra udfordring, og den nærliggende forklaring er, at tunnelen blev opdaget. Noget blev opdaget, men det var ikke dig. Webstedet scorede et sæt signaler, hvoraf ét er kildeadressen, og den adresse deles med fremmede, som måske genererede mislykkede logins et minut tidligere. At læse afgørelsen som en dom over din forbindelse misforstår, hvad scoren er til for.
Hvad en kildeadresse kan og ikke kan afgøre
En IP-adresse beskriver en vej gennem netværket på et givet tidspunkt. Den identificerer ikke en person, en enhed eller bare én konto, og med carrier-grade NAT eller en travl VPN-pulje kan den stå foran tusindvis af ubeslægtede sessioner på samme tid. Et websted, der behandler adressen som en identitet, behandler den i virkeligheden som et omdømme, hvilket er en statistisk udtalelse og ikke en kendsgerning.
To personer kan dele en udgang og producere modsatrettede beviser: den ene logger ind med en anden faktor, den anden prøver fyrre adgangskoder. Adressen er identisk, så enhver regel, der kun bygger på adressen, kan ikke skelne dem, og uanset hvilken reaktion den udløser, gælder den for begge.
Det er ikke et argument for at ignorere adresser. Det er et argument for at huske, hvad signalet måler, fordi det meste overraskende adfærd omkring VPN-logins kommer fra en kontrol, der anvendes på det forkerte detaljeringsniveau, snarere end fra en forkert observation.
Hvorfor blokering af udgangen straffer fremmede
En blokering på adresseniveau er billig at implementere og dyr at ramme. Dens radius er hver session bag den adresse, og derfor har delte adresser og NAT-adfærd deres egen historie i den operationelle dokumentation: samme ræsonnement optræder i IETF-arbejdet om delte kildeadresser og bivirkningerne ved adressebaseret 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 |
Overvej de to fejl, en blokering skaber. En legitim kunde bag den samme udgang får afvist service og indsender en supportbillet, der koster mere end misbruget. En egentlig angriber flytter til den næste udgang i en pulje af tusinder og fortsætter, uden at have brugt andet end en genopkobling.
Proportionalitet er det manglende skridt. Gentagne mislykkede logins, en byge af automatiserede anmodninger og en bekræftet tilladelsesovertrædelse er tre forskellige hændelser, og kun den anden er sandsynligvis et adresseformet problem. At anvende den samme netværksspærring for hele webstedet på alle tre er, hvordan en sikkerhedskontrol bliver til en supportkø.
Placer beslutningen, hvor beviserne er
Kontroller på kontoniveau følger kontoen på tværs af adresser, hvilket matcher den enhed, du faktisk bekymrer dig om. Hastighedsbegrænsning, ventetider efter gentagne fejl og trinvis autentificering til følsomme handlinger virker alle på kontoen eller handlingen snarere end på netværksvejen. Det passer bedre til den enhed, du faktisk beskytter. Det fjerner også angriberens incitament til at lede efter en frisk udgangsadresse.
NISTs vejledning om autentificering behandler disse som input til en risikovurdering og nævner adresse, geolocation og anmodningstidspunkt blandt signalerne, hvilket er præcis den ramme, der er værd at låne: et signal oplyser en beslutning, det erstatter ikke en autentifikator. Læs den liste som input, ikke som en menu af ting, der skal forbydes. Autentifikatoren udfører stadig beviset, og de andre signaler afgør kun, hvor meget friktion der skal lægges omkring den.
To designbegrænsninger forhindrer, at tilgangen på kontoniveau bliver sin egen afbrydelse. Hastighedsgrænser har brug for en sikker gennemgangsvej, så en bruger kan rapportere en forkert klassificering uden at offentliggøre legitimationsoplysninger, og trinvise udfordringer må ikke kunne besvares med en adgangskode eller en engangskode, der er givet til en uverificeret supportkontakt.
Hvordan en retfærdig politik ser ud udefra
Skriv ned, hvilken beslutning hver kontrol understøtter, og kontroller derefter, at kontrollens detaljeringsniveau passer. Adressekontroller besvarer spørgsmål om trafik fra et netværk; kontokontroller besvarer spørgsmål om en konto; applikationshændelser besvarer spørgsmål om adfærd efter autentificering. En politik, der nævner alle tre, kan revideres, og en, der kun nævner VPN-trafik, kan ikke.
Mål derefter resultatet i stedet for antallet af regler. Uautoriserede forsøg bør falde, legitime brugere bør beholde en understøttet vej, og antallet af supportkontakter pr. tusind logins bør ikke stige. En blokering, der forbedrer det første tal, mens den ødelægger de to andre, har flyttet problemet, ikke løst det.
At acceptere VPN-forbindelser og håndhæve misbrugskontroller er forenelige mål. Den version, der virker, behandler kildeadressen som ét input blandt flere, anvender den snæverste kontrol, der passer til beviserne, og efterlader en ærlig vej for den person, der blev fejlklassificeret. Den version, der fejler, behandler en adresse som en mistænkt og kalder det en politik.