Waarom 'n gedeelde VPN-uitgang aanmeldingswaarskuwings veroorsaak wat jy nie veroorsaak het nie
'n Aanmeldingsblokkade is gewoonlik 'n risikotelling, nie 'n uitspraak oor jou tonnel nie. Gedeelde uitgange verander wie nog by daardie telling ingesluit word en wat dit hulle kos.
Maak 'n bekende webwerf deur 'n VPN oop en kry 'n ekstra uitdaging, en die aanloklike verklaring is dat die tonnel opgespoor is. Iets is opgespoor, maar dit was nie jy nie. Die webwerf het 'n stel seine gegradeer, waarvan een die bronadres is, en daardie adres word gedeel met vreemdelinge wat 'n minuut vroeër mislukte aanmeldings kon veroorsaak het. Om die besluit as 'n uitspraak oor jou verbinding te lees, misverstaan waarvoor die telling bedoel is.
Wat 'n bronadres wel en nie kan beslis nie
'n IP-adres beskryf 'n pad deur die netwerk op 'n bepaalde oomblik. Dit identifiseer nie 'n persoon, 'n toestel of selfs 'n enkele rekening nie, en met carrier-grade NAT of 'n besige VPN-poel kan dit duisende onverwante sessies gelyktydig verteenwoordig. 'n Webwerf wat die adres as 'n identiteit behandel, behandel dit eintlik as 'n reputasie, wat 'n statistiese stelling eerder as 'n feit is.
Twee mense kan 'n uitgang deel en teenoorgestelde bewyse lewer: een meld suksesvol aan met 'n tweede faktor, die ander probeer veertig wagwoorde. Die adres is identies, so enige reël wat net op die adres gegrond is, kan hulle nie onderskei nie, en watter reaksie dit ook al veroorsaak, geld vir albei.
Dit is nie 'n argument om adresse te ignoreer nie. Dit is 'n argument om te onthou wat die sein meet, want die meeste verrassende gedrag rondom VPN-aanmeldings kom daaruit dat 'n beheer op die verkeerde granulariteit toegepas word, eerder as uit 'n verkeerde waarneming.
Waarom die blokkering van die uitgang vreemdelinge straf
'n Blokkade op adresvlak is goedkoop om te implementeer en duur om te rig. Die impakgebied is elke sessie agter daardie adres, en daarom het gedeelde adresse en NAT-gedrag sy eie geskiedenis in operasionele dokumentasie: dieselfde redenasie verskyn in die IETF-werk oor gedeelde bronadresse en die bykomende gevolge 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 |
Oorweeg die twee mislukkings wat 'n blokkade veroorsaak. 'n Wettige kliënt agter dieselfde uitgang word diens geweier en dien 'n ondersteuningskaartjie in wat meer kos as die misbruik. 'n Werklike aanvaller skuif na die volgende uitgang in 'n poel van duisende en gaan voort, nadat hy niks anders as 'n herverbinding bestee het nie.
Proporsionaliteit is die ontbrekende stap. Herhaalde mislukte aanmeldings, 'n uitbarsting van outomatiese versoeke en 'n gemagtigde toestemmingsoortreding is drie verskillende gebeurtenisse, en net die tweede is waarskynlik 'n adresvormige probleem. Om dieselfde webwerfwyde netwerkverbod op al drie toe te pas is hoe 'n sekuriteitsbeheer 'n ondersteuningswaglys word.
Plaas die besluit waar die bewyse is
Rekeningvlakkontroles volg die rekening oor adresse heen, wat ooreenstem met die entiteit waarvoor jy werklik omgee. Tempo-beperking, wagperiodes ná herhaalde mislukkings en stapsgewyse verifikasie vir sensitiewe aksies werk almal op die rekening of die aksie eerder as op die netwerkpad. Dit pas beter by die entiteit wat jy werklik beskerm. Dit verwyder ook die aanvaller se aansporing om na 'n vars uitgangadres te soek.
NIST se verifikasieriglyne behandel dit as insette tot 'n risikobeoordeling en lys adres, geoligging en versoektydsberekening onder die seine, wat presies die raamwerk is om te leen: 'n sein lig 'n besluit in, dit vervang nie 'n verifieerder nie. Lees daardie lys as insette, nie as 'n spyskaart van dinge om te verbied nie. Die verifieerder doen steeds die bewys, en die ander seine bepaal net hoeveel wrywing daarom geplaas word.
Twee ontwerpbeperkings verhoed dat die rekeningvlakbenadering sy eie onderbreking word. Tempo-beperkings benodig 'n veilige hersieningspad sodat 'n gebruiker 'n verkeerde klassifikasie kan rapporteer sonder om geloofsbriewe te publiseer, en stapsgewyse uitdagings mag nie beantwoord word met 'n wagwoord of 'n eenmalige kode wat aan 'n ongeverifieerde ondersteuningskontak gegee is nie.
Hoe 'n billike beleid van buite lyk
Skryf neer watter besluit elke beheer ondersteun, en kontroleer dan of die beheer se granulariteit ooreenstem. Adresbeheer beantwoord vrae oor verkeer van 'n netwerk; rekeningbeheer beantwoord vrae oor 'n rekening; toepassingsgebeurtenisse beantwoord vrae oor gedrag ná verifikasie. 'n Beleid wat al drie noem, is ouditeerbaar, en een wat net VPN-verkeer noem, is nie.
Meet dan die uitkoms eerder as die aantal reëls. Ongemagtigde pogings behoort te daal, wettige gebruikers behoort 'n ondersteunde pad te behou, en die aantal ondersteuningskontakte per duisend aanmeldings behoort nie te styg nie. 'n Blokkade wat die eerste syfer verbeter terwyl dit die ander twee verwoes, het die probleem verskuif, nie opgelos nie.
Om VPN-verbindings te aanvaar en misbruikbeheer toe te pas, is versoenbare doelwitte. Die weergawe wat werk, behandel die bronadres as een inset onder verskeie, pas die engste beheer toe wat by die bewyse pas, en laat 'n eerlike roete vir die persoon wat verkeerd geklassifiseer is. Die weergawe wat misluk, behandel 'n adres as 'n verdagte en noem dit 'n beleid.