Waarom een gedeelde VPN-uitgang inlogwaarschuwingen veroorzaakt die u niet hebt veroorzaakt
Een inlogblokkade is meestal een risicoscore, geen vonnis over uw tunnel. Gedeelde uitgangen veranderen wie nog meer in die score zit en wat het hun kost.
Open een vertrouwde site via een VPN en krijg een extra uitdaging, en de verleidelijke verklaring is dat de tunnel is gedetecteerd. Er is iets gedetecteerd, maar niet u. De site scoorde een reeks signalen, waarvan één het bronadres is, en dat adres wordt gedeeld met vreemden die misschien een minuut eerder mislukte aanmeldingen genereerden. De beslissing lezen als een vonnis over uw verbinding miskent waarvoor de score dient.
Wat een bronadres wel en niet kan beslechten
Een IP-adres beschrijft een pad door het netwerk op een bepaald moment. Het identificeert geen persoon, apparaat of zelfs één account, en met carrier-grade NAT of een drukke VPN-pool kan het duizenden ongerelateerde sessies tegelijk vertegenwoordigen. Een site die het adres als identiteit behandelt, behandelt het in werkelijkheid als reputatie, wat een statistische uitspraak is en geen feit.
Twee mensen kunnen een uitgang delen en tegengesteld bewijs leveren: de een meldt zich met succes aan met een tweede factor, de ander probeert veertig wachtwoorden. Het adres is identiek, dus geen enkele regel die alleen op het adres is gebaseerd kan hen onderscheiden, en welke reactie ook wordt uitgelokt, zij geldt voor beiden.
Dat is geen argument om adressen te negeren. Het is een argument om te onthouden wat het signaal meet, want het meeste verrassende gedrag rond VPN-aanmeldingen komt van een controle die op de verkeerde granulariteit wordt toegepast, niet van een verkeerde observatie.
Waarom het blokkeren van de uitgang vreemden straft
Een blokkade op adresniveau is goedkoop te implementeren en duur te richten. De impactradius is elke sessie achter dat adres, en daarom hebben gedeelde adressen en NAT-gedrag hun eigen geschiedenis in de operationele documentatie: dezelfde redenering verschijnt in het IETF-werk over gedeelde bronadressen en de neveneffecten van adresgebaseerde filtering.
| 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 |
Overweeg de twee mislukkingen die een blokkade veroorzaakt. Een legitieme klant achter dezelfde uitgang wordt service geweigerd en dient een supportticket in dat meer kost dan het misbruik. Een echte aanvaller verhuist naar de volgende uitgang in een pool van duizenden en gaat door, zonder iets anders dan een herverbinding te hebben uitgegeven.
Proportionaliteit is de ontbrekende stap. Herhaalde mislukte aanmeldingen, een golf van geautomatiseerde verzoeken en een geauthenticeerde rechtenovertreding zijn drie verschillende gebeurtenissen, en alleen de tweede is aannemelijk een adresvormig probleem. Dezelfde sitebrede netwerkban op alle drie toepassen is hoe een beveiligingscontrole een supportwachtrij wordt.
Leg de beslissing waar het bewijs is
Controles op accountniveau volgen het account over adressen heen, wat overeenkomt met de entiteit waar u echt om geeft. Snelheidsbeperking, wachttijden na herhaalde mislukkingen en getrapte authenticatie voor gevoelige acties werken allemaal op het account of de actie en niet op het netwerkpad. Dat past beter bij de entiteit die u werkelijk beschermt. Het haalt ook de prikkel weg voor de aanvaller om naar een vers uitgangsadres te zoeken.
De NIST-richtlijnen voor authenticatie behandelen deze als invoer voor een risicobeoordeling en noemen adres, geolocatie en verzoektijd onder de signalen, wat precies het kader is dat u moet lenen: een signaal informeert een beslissing, het vervangt geen authenticator. Lees die lijst als invoer, niet als een menu van dingen die verboden moeten worden. De authenticator levert nog steeds het bewijs, en de andere signalen bepalen alleen hoeveel wrijving eromheen wordt geplaatst.
Twee ontwerpbeperkingen voorkomen dat de accountbenadering een eigen storing wordt. Snelheidslimieten hebben een veilig beoordelingspad nodig zodat een gebruiker een verkeerde classificatie kan melden zonder inloggegevens te publiceren, en getrapte uitdagingen mogen niet kunnen worden beantwoord met een wachtwoord of een eenmalige code die aan een niet-geverifieerd supportcontact is gegeven.
Hoe een eerlijk beleid er van buitenaf uitziet
Schrijf op welke beslissing elke controle ondersteunt, en controleer dan of de granulariteit van de controle klopt. Adrescontroles beantwoorden vragen over verkeer van een netwerk; accountcontroles beantwoorden vragen over een account; applicatiegebeurtenissen beantwoorden vragen over gedrag na authenticatie. Een beleid dat alle drie noemt is controleerbaar, en een dat alleen VPN-verkeer noemt niet.
Meet dan het resultaat in plaats van het aantal regels. Onbevoegde pogingen zouden moeten dalen, legitieme gebruikers zouden een ondersteund pad moeten behouden, en het aantal supportcontacten per duizend aanmeldingen zou niet moeten stijgen. Een blokkade die het eerste getal verbetert terwijl zij de andere twee verwoest, heeft het probleem verplaatst, niet opgelost.
VPN-verbindingen accepteren en misbruikcontroles handhaven zijn verenigbare doelen. De versie die werkt behandelt het bronadres als één invoer naast meerdere, past de nauwste controle toe die bij het bewijs past, en laat een eerlijke route voor de persoon die verkeerd is geclassificeerd. De versie die faalt behandelt een adres als een verdachte en noemt dat beleid.